5 years of The PeopleSoft Administrator Podcast!
This week on the podcast, Kyle and Dan celebrate 5 years of podcasting and then take a detour into PeopleTools Patching. They discuss what rolling back a PeopleTools Patch would look like and share some thoughts on how to make PeopleTools Patch testing easier.
Show Notes
- 5 Years @ 1:30
- CPU Patching @ 4:30
- PeopleTools Patch Rollback Planning @ 9:30
- Testing PeopleTools Patches @ 27:00
We version our
PS_CFG_HOMEdirectories, so we can have a/opt/psft/cfg/85624alongside an/opt/psft/cfg/85805. (We only run one database per server, but you could include a database component in the path if you want to have domains for several databases on one server.) We also versionPS_HOME, but notPS_APP_HOMEorPS_CUST_HOME. This lets us prepare the new PIA and Tux domain configurations before patching and outside the maintenance window.Then the patch window is stop old domains, run ChangeAssistant to apply the tools patch to the database, update our bash profiles to point to the new pre-prepared PS_CFG_HOME and PS_HOME while CA is running, and then start the new domains when CA finishes.
But I don’t think I have the courage to try to back out a PeopleTools patch once it has been applied to the database. In the non-prod databases we can get a database restore point taken before the patch and hold onto it for a few days in case something terrible happens. We get the restore point for prod updates also, but realistically it’s infeasible to rollback production more than a few hours. The prod restore point is protection in case the patch blows up right away during or immediately after the maintenance window.
Before starting tools patch 1) export mvprdexp (see in scripts directory) or have dba’s backup the tables (you could also a cold database backup if your database is small) 2) backup PS_HOME,PS_APP_HOME,PS_CFG_HOME . If and when tools patching failed while doing in production, reverting the above two steps to the pretools patch would do the trick.