This section contains the following topics:
Before you begin the upgrade, keep the HADB history files, management agent configuration files, log files and repository, and all the data devices outside the installation path. Use the following procedure to move the management repository and configuration files:
Stop all the old management agents and keep the HADB nodes running.
On each host, move the repository directory to the new location.
On each host, copy the dbconfig directory to the new location.
On each host, update the mgt.cfg file, and set the correct path for dbconfig and repository directory.
Start the management agents using the updated mgt.cfg file.
On Linux, uninstall HADB 4.4.1-6 before upgrading the Japanese version of Application Server Enterprise Edition 7 2004Q2 Update 2 to Application Server Enterprise Edition 7 2004Q2 Update 7.
The HADB version bundled with Application Server Enterprise Edition 7 2004Q2 Update 7 is 4.4.1-7.
Uninstalling HADB 4.4.1-6 after performing an in-place upgrade to 4.4.1-7 might not remove all RPMs, specially sun-hadb-i-4.4.1-6.
To remove sun-hadb-i-4.4.1-6, run the following command:
rpm -e --nodeps sun-hadb-i-4.4.1-6
To upgrade from HADB version 4.4.x to version 4.4.2-7, use the following procedure:
Perform the pre-upgrade tasks mentioned under Pre-upgrade Tasks/Data Migration.
Install HADB version 4.4.2-7 on all HADB hosts (on another path than that of version 4.4.x, for instance on /opt/SUNWhadb/4.4.2-7).
Install the HADB 4.4.2-7 version on the hadbm client hosts, if they are different than that of the HADB hosts.
Stop all management agents running on all HADB hosts.
Start the management agent processes using the HADB 4.4.2-7 software, with the old configuration files. In the remaining steps, use the hadbm command found in the HADB 4.4.2-7 /bin directory.
Register the package in the management domain (default package name becomes V4.4, so another package name may be required to avoid conflicts with existing packages having the same name):
hadbm registerpackage --packagepath=/opt/SUNWhadb/4.4.2-7 V4.4.2-7
Run the hadbm listpackages command and check that the new package is registered in the domain.
Restart the database with the new hadbm version 4.4.2-7. If it is necessary to move the devices and history files, run online upgrade combined with setting new paths for devices and history files in one single operation:
hadbm set packagename=V4.4.2-7,devicepath=new_devpath,historypath=new_histpath
If the devices and history files are already outside the installation directory, run the following command, which only does a rolling restart of the nodes:
hadbm set packagename=V4.4.2-7 database name
Check that the database status is "running" (using the hadbm status command) and that it functions normally, serving the client transactions.
If everything is working, the old installation can be removed later. Before unregistering the old package, remove all references to the old package from the ma repository. Otherwise, hadbm unregisterpackage will fail with "package in use" error message. A dummy reconfiguration operation, for instance, hadbm set connectiontrace=same as previous value will remove all references to the old package.
Unregister the old package:
hadbm unregisterpackage [--hosts=host-list] old pacakge name
Remove the old installation from the file system.
On Solaris, to test that the upgrade was successful, check that the upgrade was performed properly using the following procedure:
Ensure that the running processes use the new binaries. Check the following in all HADB nodes:
new path/bin/ma -v
new path/bin/hadbm -v
Check whether the database is running. The following command should show that all the HADB nodes are in a "running" state.
new path/bin/hadbm status -n
Ensure that the products using HADB have changed their pointers to point to the new HADB path.
The products using the HADB can run their upgrade tests to verify the HADB upgrade is also working.
After an online upgrade, if the new version does not work properly, go back to using the previous HADB version.
However, if there has been a change to the management agent repository, the HADB itself can be downgraded, but the new management agent must be kept running.