|
|
|
Upgrading using upgradedb transforms your database in-place from the original version to the new, without requiring an unload and reload.
To upgrade using upgradedb, use the following process.
Note: In this process, the notation [Each DB] means: "For each database, not including the iidbdb (master database), become the DBA for that database and perform this step." Do not include the iidbdb or Ingres Star distributed databases unless instructed. If using Ingres Star, remember to include the coordinator database in the list of databases.
For details on each step, see the following sections.
|
|
|
During the upgrade, the production system is not available for use. Make sure that users are not able to access the databases until the upgrade is complete.
|
|
|
The Remote Command Server component of Visual DBA must be disabled for the duration of the upgrade. The Remote Command Server uses the iidbdb database as a communications mechanism in versions of Ingres prior to 2.6, so it will interfere with upgrading.
Note: If you are upgrading from early versions of OpenIngres 1.x, and you do not see an entry in CBF for the Remote Command Server, skip this step.
To disable the Remote Command Server
|
|
|
You should perform a clean shutdown of Ingres, clearing all transactions from the transaction log, and then back up your system.
To perform a clean shutdown of Ingres
To back up your system
Note: Watch for symbolic links and cross-mounts; make sure real data is saved and not a symbolic link.
|
|
|
To ensure the integrity of the system catalogs, issue the following commands:
sysmod dbname
verifydb –mreport –sdbname dbname –odbms_catalog
The verifydb command may issue the following messages; you can ignore them.
S_DU1611_NO_PROTECTS iirelation indicates that there are protections for table (owner), but none are defined.
S_DU0305_CLEAR_PRTUPS Recommended action is to clear protection information from iirelation, and S_DU1619_NO_VIEW iirelation indicates that there is a view defined for table (owner), but none exists.
S_DU030C_CLEAR_VBASE Recommended action is to clear view base specification from iirelation.
You can also ignore the "patch warning" message that warns of the loss of user tables in "runinteractive" mode. This mode will not be used.
If verifydb issues warnings or errors other than those in Step 1, review the messages with Ingres Technical Support before upgrading that database, because there may be damage to the system catalog.
|
|
|
For each database, you will need to know information such as whether the database was journaled, where the database resides, and in what order the data locations were configured.
To record database information
infodb dbname >infodb.out
Save the output for later.
To find out, use the catalogdb command. Select Databases, and then enter the database name. The screen that appears has an Access field that indicates whether the database is public or private.
|
|
|
For each database, including the iidbdb, checkpoint each database and turn off journaling. Then save the configuration file.
To checkpoint and turn off journaling
Issue the following command:
ckpdb -d -j dbname
cp $II_DUMP/ingres/dmp/default/dbname/aaaaaaaa.cnf {somewhere secure}
|
|
|
Shut down Ingres with the ingstop command.
|
|
|
Files distributed as part of Ingres that you have customized will be lost during the upgrade. Any custom files you have added to the $II_SYSTEM directory tree will remain.
You must copy your customized files to a safe place. Do not copy them to /tmp or anywhere in $II_SYSTEM/ingres directory.
If local collation sequence files have been customized, save the original collation definition files and the compiled files that reside in $II_SYSTEM/ingres/files/collation.
|
|
|
The following files are typically customized:
|
|
|
If you cannot identify all your customized files, you can ensure that you preserve the necessary files by performing the following procedure. This procedure copies more files than necessary, but you can delete the copy after Ingres has been running live for a period.
To preserve necessary files
Note: Do not delete the copy immediately when the upgrade completes, because you may discover weeks later that you need the old version of a file (for example, a Vision template or keyboard map) from the original $II_SYSTEM/ingres directory.
UNIX: On UNIX, to copy these files, use commands similar to the following:
cd $II_SYSTEM/ingres
tar cf - bin files rep utility | (cd /someplace/safe;tar xf -) 
|
|
|
When upgrading, Visual DBA configuration files (.vdbacfg) are not upwardly compatible and must be recreated.
Note: Instead of using configuration files, you can use the vdba command with command line flags to start Visual DBA with, for example, certain windows open on given nodes. For details on the vdba command, see the Command Reference Guide.
|
|
|
Note: This step is optional but recommended.
The Ingres installation procedure on UNIX starts by extracting the install subdirectory from the Ingres distribution.
You should delete the old contents of that directory first, as follows:
cd $II_SYSTEM/ingres
rm –rf install
|
|
|
To install Ingres, see the Ingres installation instructions for your platform.
During the installation process, the DBMS Server setup asks whether all databases are to be upgraded; answer No. The installation procedure automatically upgrades the iidbdb. If the upgrade of iidbdb fails, see the chapter "Troubleshooting Upgradedb." It is better to complete the Ingres setup, and then use the upgradedb command to upgrade the user databases.
If you are upgrading from 6.4, and the 6.4 installation has Ingres Star databases, you must respond No to this prompt. At this point in the 6.4 upgrade, the Star Server is not yet set up.
After the iidbdb is upgraded, the DBMS Server setup attempts to upgrade imadb and install Remote Command Server objects into imadb. Some versions of upgradedb neglect to create imadb first, and you will get "Database does not exist: imadb" errors. These will be corrected in the next step.
|
|
|
Newer versions of Ingres distribute service packs. You can install service packs without having to install a base release of Ingres first.
UNIX: If you are upgrading to an older Ingres version that requires an overlay patch instead of a service pack, follow this procedure:
Setup now uses the fixed version.
|
|
|
Note: Perform this step only if you received "Database does not exist: imadb" messages during the DBMS setup phase of your Ingres install. This should only occur if you are upgrading from OpenIngres 1.x to Ingres 2.6 or older.
To create the imadb database, as the installation owner, execute these commands:
UNIX:
ingstart
cd $II_SYSTEM/ingres/vdba
createdb '-u$ingres' imadb –f nofeclients
sql '-u$ingres' imadb <makimau.sql
rmcmdgen
ingstop
Windows:
ingstart
cd %II_SYSTEM%\ingres\vdba
createdb -u$ingres imadb –f nofeclients
sql -u$ingres imadb <makiman.sql
rmcmdgen
ingstop
As the makimau or makiman SQL scripts run, you see a series of messages such as "E_US0AC1 'some-name' does not exist or is not owned by you." These are normal and can be ignored.
|
|
|
Refer to the save directory that was created in the step Preserve Site Modifications, and review any site-specific files that were overwritten by the upgrade.
|
|
|
If the checkpoint template file cktmpl.def has been modified, the modifications may need to be carried forward into Ingres. Your original cktmpl.def should not be used directly, because entries can be added or revised in new versions of Ingres. Compare your customized cktmpl.def with the newly installed file, and make necessary changes in the new cktmpl.def. For information about the checkpoint template, see the Database Administrator Guide.
|
|
|
Run ingstart to start Ingres.
|
|
|
Run the upgradedb utility to upgrade databases. You can upgrade databases one at a time or all at the same time. Log the upgradedb output to a file.
To upgrade one at a time:
upgradedb dbname
To upgrade all at the same time:
upgradedb –all
Example of logging upgradedb output to a file:
upgradedb -all |& tee upgradedb.log
If errors occur, see the chapter "Troubleshooting Upgradedb." Correct the errors and rerun the upgradedb utility.
|
|
|
The upgrade preserves your original Ingres installation parameters. You should review the configuration because some parameters may change from version to version. For information on parameters that changed, check the Readme for your new version of Ingres.
Review your parameter settings by running Configuration-By-Forms or Visual Configurator. Especially pay attention to major items such as startup counts and DBMS cache settings.
Note: If you disabled the Remote Command Server in an earlier step of the upgradedb process, use EditCount to restore its startup count to the original value.
|
|
|
Note: This step is required only if upgrading from OpenIngres 1.x or Ingres 6.4. Ingres computes additional metrics that those releases did not have.
To take advantage of the new metrics, regenerate the optimizer statistics using the procedures of your application system.
|
|
|
Checkpoints and journals from your original Ingres version will not work with the newer version, so do not omit or delay this step.
Checkpoint each database, including the iidbdb. If the database was journaled previously, use the +j flag to turn on journaling.
To know which databases were journaled, see the infodb output from the step Record Database Information.
The iidbdb should always be journaled, regardless of whether it was journaled in the original installation.
|
|
|
To perform the last step of the upgrade procedure: