C. Migrating Vector Databases Between AMIs

You may want to do this if, for example, if you upgrade to a new Version of Vector in the AWS Cloud. This entails copying your databases from the previous version of the AMI to the new version.

Unless you specifically destroy the original database, you will end up with two identical databases having the same name and owner, in two different Vector AMIs.

If you want to change ownership of the databases at the same time, you can do so by editing the reload.ing script and changing the user name that follows the "-u" flag.

Objects that will NOT be copied (because they are not stored in your database) include:

• Object code: This generally is not a problem because applications can be recompiled on the target machine.

• Other compiled objects: This includes compiled forms or any objects referenced in OSL by the keywords "call subsystem". This note will offer some suggestions for keeping track of OSL source files when moving databases. See your query language reference manuals for details of the copyapp "-s" flag for moving source files that are not stored in the database.

This procedure assumes that you are moving a user database, as opposed to the iidbdb (master database).

2. Ensure that your environment is set up to run the installation FROM which you want to copy the database.

3. Create a temporary working directory, since the next few steps will create a number of files.

It is convenient to choose a directory path that you can duplicate on the target AMI because the “copy to” and “copy from” scripts created by the unloaddb utility contain explicit references to the directory path from which you execute unloaddb. Therefore, you might want to create a subdirectory under /tmp (since this directory will exist on the target AMI).

a. Execute unloaddb. It does not actually unload the database but creates two script files (unload.ing and reload.ing):

Because unload.ing copies out all your tables into files, it can take some time to run, depending on the number and size of the tables in your database.

Note: The "-c" flag copies out files in portable ASCII format. You will need this unless you are copying the database to another installation on this same machine or to a binary-compatible machine. If you are not sure, use the "-c" flag; however, using the "-c" flag affects the value of floating-point numbers. Precision of formated character output of floats is controlled with the "-f" flag.

5. Copy the entire contents of the unloaddb directory and the local source code directories to the corresponding working directories on the new AMI.

If the target machine shares a network with the source machine, you can use FTP or the UNIX scp command to copy the directories to the target node. The following example uses commands common to many UNIX machines.

The temporary working directory for the database unload files is /tmp/movedir on the first AMI. We will move the database to a machine called “ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com .” The remote copy command should look like this:

$ scp -r -i keyfile.pem /tmp/movedir actian@ec2-xxx-xxx-xxx-xxx.compute-1.amazonaws.com:/tmp

6. When the unloaded files have been successfully transferred, move to the target installation and change your environment so that you are properly set up to run the installation INTO which you would like to copy the database.

Your unloaddb files are now sitting in a temporary directory of the same name as the one from which you unloaded on the source machine, for example, /tmp/my_work_dir). Likewise, your source code files also are now located on the target machine in a directory of your choice.

Note: You may create the database with another name, but if you do this, you must also change the database name in the reload.ing script.

8. Ensure that you are in the temporary directory containing the transferred unloaddb files. For example, /tmp/my_work_dir.

This is the most time-consuming step, since all tables will be loaded and modified. You may also want to sysmod the database after reloading it:

You now have two databases in two installations. Unless you created your new database with a new name, you now have two separate databases with the same name and owner. If it is not important to keep both databases, we recommend you destroy the original. Remember that updates to the database in one installation will not be reflected in the other.