contributed by John ("Tim") Bower
If you've ever encountered version number inconsistencies in your PeopleSoft database, you know how badly it hurts performance when application servers are unable to properly cache managed PeopleTools objects. In most PeopleTools releases prior to 8.53, the remedy for version number problems was to take the entire PeopleSoft system offline, and run the same VERSION application engine program that is used for upgrades. But until now, running VERSION was difficult and carried some risks:
* To successfully run VERSION AE the old way, all users had to be disconnected from the database. This included any users that might be accessing the database in 2- or 3-tier mode with Application Designer. This meant that a complete system outage was required. If VERSION was run with users connected, you would run the risk of making a minor version number problem worse than it was to begin with; and not remedying the original cache performance problem you were trying to resolve.
* When VERSION was run in this way, all version numbers in the system were reset to "1". This would mean that application servers would have to rebuild all memory and file cache from scratch. If shared file cache was being used, this required manually rebuilding the cache files. Otherwise, there would be, in effect, no caching on the application servers at all; again, resulting in terrible PeopleSoft performance.
For PeopleTools 8.53, a new and improved VERSION Application Engine was developed. With the new program, you should only rarely, if ever, need to run VERSION the old way. And best of all, the new VERSION AE is backwards compatible with all PeopleTools installations from PT 8.44. The program can now be run in one of 3 modes:
1) Report Only - This allows you to determine if you really do have a problem with version number inconsistency that needs to be corrected. No more guessing or looking at traces!
2) Enhanced Mode - This allows you to correct most version number inconsistencies while the system is running and users are logged on. In other words, you don’t need to disconnect users and shut down application servers to run in this mode. Version inconsistencies are repaired without just blindly resetting all version numbers in the system to "1". Instead the program selectively increments version numbers for the specific managed object types that can be detected to be in error. If you use dedicated file cache, the system will only need to re-cache objects whose version numbers have changed, and do so only when those objects are accessed. If you preload cache, then at worst, you will see the effects of repairing version numbers when PSAPPSRV processes recycle. But if you are using shared cache, of course you will still need to rebuild cache files manually,
3) Classic Mode - This is the same way that VERSION has run in the past. All access to the system will need to be disabled, and every version number will be changed to "1", forcing a complete rebuild of all application server file cache.
All of the details and the download of the new Version Application Engine can be found here:
Oracle Support Document 611565.1 (E-AS: Instructions Regarding the Use of the VERSION Application Engine Program)