One of the core features of Stat involves Patch Impact Analysis. With the large number of patches Oracle releases, it becomes increasingly hard to identify what is going to change and if it will affect how your customizations or applications work. Leveraging this functionality in Stat can greatly assist you in this endeavor. I am going to discuss how it works in Stat and what you need to do to take full advantage of it.
Patch impact analysis in Stat works the same as applying a patch and actually can be scheduled to be run at a future date automatically as well. The process actually invokes ADPatch just like if you were applying a patch with one change, APPLY_MODE=NO. This is also a great ‘dry run’ for the patch with the added benefit of deriving all the objects that will be over-written or added from the patch. The results of the patch impact analysis are shown in a list of objects that will be affected with the Stat value-add of identifying whether they will modify objects you have modified directly or indirectly. Many people ask what do you mean ‘indirectly?’ Indirect impact means that you have your own version of the Oracle seeded object in your own custom top. You are calling your own version and not Oracle’s, even though it is generally comprised mostly of the same code just with your own changes and extensions. Therefore if you see an ‘Indirect’ impact you know that you will want to take a look at your custom code and determine whether you need to port your changes into Oracle’s new one or theirs into yours. To let Stat know of the relationship your developers will need to create the objects using the ‘New Object’ button in the Object tab of the CSR and point to the original thereby alerting Stat to the relationship.
Once you determine that an object is going to be affected (directly or indirectly) you can then use Stat’s side-by-side comparison feature in the Compare/Merge Wizard to show what the object in the patch (that is not yet applied) looks like alongside the one in your environment, a version a developer is working on, or in your version in a custom top. One of the best parts about the comparison functionality in Stat is that it works for all seeded flat-file, AOL, functional setups, and Developer objects such as forms and reports (binaries.) The ability to compare those binaries side-by-side is extremely valuable not only in patch impact analysis but in everyday work as well. Once you decide what changes to make, you can version the object and migrate it the same as you normally would after the patch is applied. Now you have preserved your customizations and taken advantage of Oracle’s new fix or functionality.
In summary, Stat’s patch impact analysis can save you a lot of time while simultaneously mitigating risk to your environments. By running this process before a patch is introduced you can reduce some of the guess work of how it is going to affect your applications. The comparison functionality will accurately show what code is changing and different and help you determine the best course of action to take to preserve your developer’s work while taking advantage of the new fix or functionality Oracle has introduced.
Please feel free to ask me questions about this if you need more details.