Remove Aries Container

[Mark Nierth]

i'd like some feedback on what steps are needed to remove Aries containers and just run a normal 11.31 server running Oracle. We have 10 bl860c i4 servers, each configured with 1 container. Because of issues with Oracle, we want to remove Aries. I've seen the doc on stoping and deleting the container, but what about files on the containter that i need to move back to the host. I'm thinking i need to preserve /etc/passwd, /etc/group, crontabs, fstab, inittab, oratab, /sbin/init.d from the container. Any information would be helpful.

[Matti_Kurkela]

"Aries container" implies that you are running a PA-RISC version of Oracle in a Itanium system.

To have a supported Oracle configuration without containers, you would probably have to switch to native Itanium version of Oracle: I don't think Oracle recommends running a non-containerized PA-RISC version of Oracle in a Itanium system. That means installing a completely new set of Oracle binaries - essentially a complete re-installation of Oracle, then bringing in the old databases in some way or other.

The reason you are currently running Aries containers might be that you're running a legacy version of Oracle that is not available for Itanium. That might force you to perform an Oracle version upgrade while migrating... and then you might need to update the clients too.

If the UIDs/GIDs used within the container are from an older version of HP-UX, you are likely to find that 11.31 now contains some new system users that may conflict with the old UIDs/GIDs. In that case, you must reassign the Oracle UIDs/GIDs, and the preserved /etc/passwd and /etc/group will only be useful as a guideline on what users/groups you will need to re-create.

A new oratab should be created as a natural result of such a re-installation, so the preserved version is only useful for checking that all the databases have been migrated.

For a regular Oracle installation, there should be nothing added in /etc/inittab.

Any custom crontabs and/or /sbin/init.d scripts might be useful to migrate, although they would need some review to ensure they are still applicable in the Itanium environment.

Your DBA should verify the requirements for a PA-RISC -> Itanium migration at the Oracle level.

If the migration needs to be done with a full export from the old database & full import to the new one, this is a chance to re-architect the storage of your databases.

For example, if the old databases are using raw disk LUNs of inconveniently small size, you could now choose disk sizes that are more appropriate for modern storage systems. Or if you test it and find that the performance difference between filesystem-based database and raw disks is negligible, you might even transition to filesystem-based databases for easier disk space management.

If the on-disk format of the old databases is suitable for a direct migration to Itanium, you might only need to have the disks presented to the host directly, instead of to the container. Copying the legacy fstab from the container to the host wholesale might not be wise: you should review the fstab file and only copy the important entries to the host fstab. If you had to reassign the UIDs/GIDs, you may also need to change the file owners/groups on disk to match the new UIDs/GIDs.