AIX 7.1 various SP levels
Update to SP9 on DB systems with Oracle 10 or 11G
Steps:
Apply SP9 update
Bring down databases
shutdown -Fr
Check system health - AIX
Bring up databases
Confirm functionality
Would applying the update while the databases are up cause problems with either the SP update or the Oracle databases?
I've looked for a definitive answer on the web, and asking others, to no avail. The conservative approach is to do the SP update after the databases are down. However, if the SP update can be done before, it would streamline the over all process.
What is your backout plan? What if your SP is not consistent and you have to go back to the original OS and SP level?
The answer is you always create an alternative disk (of rootvg) and upgrade that disk, without impacting anything on the current running environment.
For this you need to have an additional disk, if you cannot get an additional disk, then you can also use multibos on the same disk to achieve the similar result (but make sure the root disk have enough space for multibos operation). But, never ever go directly without a backup copy.
But you want to be sure that the new SP is compatible with existing oracle version, so throw that question to oracle DBA team, ask them to find out oracle compatibility with that new SP version.
ibmtech, thank you for the reply. I like the alternative disk suggestion. I'll look into that
Sorry, my steps are a bit sparse. I'll give a bit more detail for my item of 'Apply SP9 update'.
mksysb is the backout plan
I always do the following before applying the update:
If any of these checks reveal something amiss, it is corrected before proceeding:-
Check available space for the mksysb and update processing
check exclude.rootvg
generate the mksysb - smitty mksysb
verify the mksysb - lsmksysb -f
oslevel -s
instfix -i|grep ML
installp -C
lppchk -v
installp -s
installp -c all if some packages are not committed
emgr -P to determine if there are any efixes which may cause a conflict
If a DB server, ps -ef|grep smon and agent to verify the DBs are down
I run the update from a NIM - smitty nim , using the preview only option
If all looks good, then I proceed with the actual update, access the system, redo all the pre checks to confirm current status, shutdown -Fr , redo all the checks again to ensure it all came up healthy
I do have the DBA team verify the oracle version is compatible with the intended OS update. I also read up to determine myself.
I'm curious if applying the SP while the databases are still up would cause issues. The oracle is 11G, on AIX 7 TL1 SP9. I'd try it in a test area, if I could.
Those are all good, but make sure you use alternate disk install
To summarize
You need to have a free disk (equal to greater in size of rootvg)
smitty --> Software Installation and Maintenance --> Alternate Disk Installation -->
Clone the rootvg to an Alternate Disk
[TOP] [Entry Fields]
* Target Disk(s) to install [hdisk1] +
Phase to execute all +
image.data file [] /
Exclude list [] /
Bundle to install [update_all] +
-OR-
Fileset(s) to install []
Fix bundle to install []
-OR-
Fixes to install []
Directory or Device with images [/export/aix71/tl01sp09]
(required if filesets, bundles or fixes used)
installp Flags
COMMIT software updates? yes +
SAVE replaced files? no +
AUTOMATICALLY install requisite software? yes +
EXTEND file systems if space needed? yes +
OVERWRITE same or newer versions? no +
VERIFY install and check file sizes? no +
ACCEPT new license agreements? yes +
Customization script [] /
[MORE...5]
This will 1st copy the existing mksysb to new disk, then it will update the OS, all your setting will remain the same.
If your Tl01SP09 binaries are on NIM server, you can export that directory to the client and use that location.
You seem to come from a different flavour of Unix, so maybe a bit of background information about Alternate Disk Migration is in order. To expand on what ibmtech already explained:
One usually has a mirrored rootvg, which means that you have two identical disks carrying identical copies of the OS. ADM now does the following: it breaks up the mirror. Then you apply the update (or the installation - there is not only Alternate Disk Migration but also Alternate Disk Installation) to one of these copies. Then you reboot into this newly installed/updated environment.
If everything turns out OK you destroy the unchanged copy and remirror, so that you now have two copies of the new system images. If some problem occurs you reboot back into the old environment from the still existing (and unchanged) disk, destroy the new installation and remirror, arriving at the point you started from again.
Most of these steps are done behind the scenes by the provided procedures, but it helps to have a working picture of what is going on.
NOTE: at the end of the procedure do not forget to apply the bosboot command and maintain the system bootlist with bootlist command.
Thank you both for the information. I understand the concept, the procedure sounds straight forward. Knowing what is done behind the scenes is always desired, thanks for that.
Most of my background is with AIX, then some years with RHEL as well. My AIX background was mostly in a small shop, 3 stand alone systems. I am now in a sizeable shop, 2,000+ systems, with exposure to greater depth of the technology.
I'll try out the alternate disk update on one of the next test systems up for SP9. I'll post back how it went.
Thanks again
NIM ADM is by far the preferred method if you have a suitable NIM environment, DON'T forget you can provision a new lun for rootvg and three way mirror on to it, then use it for the NIMADM leaving the original mirrored rootvg intact in case of any problems...
HTH