Move Databases
Use unloaddb to upgrade a database from its original to a new installation.
If the old and the new installations are on the same machine, it is necessary to have created a means of switching between the original and new installations. This section uses the setold and setnew scripts, which are described in
Create the New Development Installation.
This section assumes that all objects within the database are to be copied from the original to the new installation. If, for example, the data is not wanted, the copy.in and copy.out scripts can be edited. The same applies to any other database object.
To upgrade a database from the old to the new installation
1. Setold and cd to a directory with enough space to hold the unloaded databases in the installation.
2. Create a directory for each database that is to be unloaded.
3. Change directory to the directory of the database that is to be unloaded.
4. Execute unloaddb against the database that is to be unloaded.
Notes:
• If the database is to be reloaded on a machine architecture that is different from the original (for example, OpenVMS to Windows), use unloaddb with the –c flag.
• If you are upgrading to a Unicode-enabled database, use unloaddb with the –nvarchar flag.
5. Unload the database by executing the resulting script:
UNIX:
Use “tee,” or pipe as follows:
unload.ing | tee /temp/unload.log
or
unload.ing > /temp/unload.log
Windows:
Pipe the output to a file, as follows:
unload.bat > c:\temp\unload.log
VMS:
define/user sys$output unload.log
@unload.ing
deassign/user sys$output
6. Review the output file for problems. Problems indicate that the database has not been unloaded correctly. Fix the problems and rerun the unload before continuing.
7. Edit the copy.in scripts as follows:
Edit the copy.in file and remove the lines:
\include /ingXX/ingres/files/iiud.scr
\include /ingXX/ingres/files/iiud65.scr
Directory paths may be different.
9. Setnew to the new installation and create the new database. Check the copy.in scripts: if there are DROP statements before the CREATE TABLE statements for the system catalogs then:
createdb databasename
Otherwise use:
createdb databasename –f nofeclients
Note: If using -f nofeclients, edit the copy.in script to change the line "\nocontinue" to "\continue" to prevent each DROP statement from returning an error and causing the reload to fail.
10. If the database name is not the same as the original databasename, edit the reload script and change the databasename.
11. Run reload for the database. Capture the output of the reload script so that it can be checked for errors.
UNIX:
Use “tee,” or pipe as follows:
reload.ing | tee /temp/reload.log
reload.ing > /temp/reload.log
Windows:
Pipe the output to a file, as follows:
reload.bat > c:\temp\reload.log
VMS:
define/user sys$output reload.log
@unload.ing
deassign/user sys$output
12. Review the output from the reload for any problems. Problems indicate that the database has not been correctly built.
• If the errors can be corrected in the copy.in scripts, then fix them; otherwise go back to the original database and correct the errors.
• Destroy the database in the new installation.
• Restart the “Move Databases” procedure from the top.
13. If problems still occur, it may be necessary to contact technical support for assistance.
14. Having successfully moved the database, the front end catalogs in the database must be upgraded to the latest version. To do this run:
upgradedb databasename -tree
or
upgradefe databasename INGRES
15. Review the output from the upgrade for any problems. The existence of problems means that the database has not been correctly built. Handle the problems as in Step 11 above.