When beginning an engagement with a client, so many times I discover that they have not run Averify regularly (sometimes even once) to maintain their Agile database. Averify is a critical maintenance tool for keeping your database consistent, identifying potential issues, and troubleshooting your Agile server. When submitting Services Requests to Oracle support for an AgilePLM system, one of the basic requests is usually a recent Averify report using the most recent version of Averify. The documentation is available from support.oracle.com: How to Download the Latest Version of Averify (Doc ID 571832.1).
A Little Background
According to Oracle Support, “Averify is a diagnostic tool to verify the referential integrity of the Agile PLM database schema. It checks for data anomalies that can adversely affect the normal operation of the system. Averify can be used as a reactive or proactive tool to keep the system running smoothly. Please refer to note: Best Practices for Maintaining an Agile Product Lifecycle Management (PLM) System (Doc ID 1522897.1) for more details.” That is from Agile Product Lifecycle Management (PLM) Master Index for Averify Solutions (Doc ID 1121926.1) and pretty well sums up the purpose of Averify.
Averify does NOT make any changes to the Agile schema but does use a number of Agile use cases to test the database and its various database objects. As a best practice, the AgilePLM application should be stopped whenever running Averify or any of the generic fix scripts. Averify produces a comprehensive report that identifies issues at four levels of severity, Critical, Error, Information and Warning. It also produces a list of non-Agile tables residing in the Agile schema that can be safely removed unless you have created custom tables for other processes. It is highly recommended that any custom tables being utilized by non-Agile processes be housed outside of the Agile schema to simplify refreshes and other database maintenance.
Repairing Averify Errors
Oracle has established a number of generic scripts to correct the most common issues found by Averify. The scripts are referred to as adt_generic in Oracle documentation and require the application be stopped when running them. Again, the most recent versions of the generic scripts should always be used to apply the generic fixes. The generic fixes and documentation for running them are available from support.oracle.com as: Agile Product Lifecycle Management (PLM) Master Index for Averify Solutions (Doc ID 1121926.1)
Prior to submitting a Service Request to Oracle support for Averify errors, be sure you are using the latest Averify version, clean-up generic errors using the latest version of the adt_generic scripts, and then rerun Averify to get a cleaner report for Support to work from. This will speed up the response to your request.
Oracle Document for Submitting Averify Errors: Mandatory Process To Follow For Opening Averify SRs (Doc ID 1618697.1)
Averify is not only critical to keeping your database in shape but is mandatory prior to attempting an upgrade. Upgrades to the Agile database tend to follow the old maxim of “Garbage in, Garbage out” resulting in strange upgrade behavior.
Was this guide helpful? Please share your comments below.
Author Bob McDuffee, Certified Ethical Hacker (CEH), has over 30 years experience and is a System Engineer for Zero Wait-State. He is responsible for installing software for clients and overseeing hosted and virtual environments. He provides configuration information for customers and debugs hardware issues both for clients and the company internally. His experience includes implementing, troubleshooting and upgrading PDM systems on Linux, Solaris and Windows servers utilizing both WebLogic and Oracle Application Server.
Zero Wait-State has products and services available to help you maintain your PLM system.
Click here to contact us.
