Product install - connect_cdc_sqdata - Latest

Most customers utilize a special "sqdata_user" account established specifically for that purpose because it usually needs elevated privileges to read and apply data. If necessary have the system administrator create that account.

If Connect CDC (SQData) is going to be used to access any local databases, the user will need privileges to operate on those databases. Those privileges include SELECT, DELETE, INSERT, and UPDATE.

While there is no specific location that Connect CDC (SQData) must be installed, this section describes two platform dependent installation scenarios. The most important thing to consider when picking an install directory to make sure all the users that need to access the package have permission to access it. Depending on what type of environment our product is being used in (Production/Test/Development), there can be dramatically different security concerns from very stringent to everyone having administrative privileges on the machine. The first level of security is specifying file system access to executables.

On UNIX systems executables are typically installed in /opt under a directory named for the product. The /opt directory is usually owned by root, so administrator privileges would be required to create the /opt/sqdata directory and decompress the package into this location. To allow multiple users to access the installation without giving access to everyone, the system administrator can define an sqdata group and grant permissions on the directory to the group.

Alternatively, the product can be installed into the home directory of the user designated to run the capture/apply process, eg: /home/<sqdata_user>/sqdata. To install to this location no special privileges are required, and the user can grant permissions on the directory to a group of users without administrator privileges.

Locate the package needed for your platform. Once you have identified which package is to be installed, click on the appropriate link to download the compressed package to your desktop or directly to the Installation location previously selected.

The package is distributed as a compressed Tar file with the extension (bz2 or .gzip) representing the compression method. Refer to documentation on Tar for its many possible options. If you are installing the product from the command line in the installation working directory, the command for example could be:

$ tar -xvjf sqdata-<platform>-<version>.tar.bz2
or
$ tar -xvzf sqdata-<platform>-<version>.tar.gz

The decompression and extraction process will create a version labeled directory structure for the executables in the installation directory:

sqdata-<version>
sqdata-<version>/bin
sqdata-<version>/bin/dbg
sqdata-<version>/bnd  

The "release" version of the executables is found under /bin and the diagnostic version under /dbg. The release version has much of the code used for debugging excluded, making the code faster with fewer runtime instructions, but providing little diagnostics if something goes wrong. Some customers run the debug version in their test environment and the release version in their production environment. Other customers run the diagnostic (/dbg) code in both test and production because they see little difference in performance on their systems.

The /bnd directory contains the DBRM module to Bind when applying to Db2.

The Tar files for each version will remain in the installation directory along with their corresponding version numbered directory structure, facilitating both upgrade and regression testing.

A symbolic link should be created to the executable directory of the current version. When new maintenance is applied, do not remove the old directories; just install the new version (which will create a new directory with a new version number) and update the link to point to the new location. Any scripts or PATH variables that need to reference the location of executables can use this symbolic link and thus not be version specific. Here we create a symbolic link called "bin" under <SQDATA_DIR> which points to the current debug version of the code:

Precisely recommends that you run the application without fully qualifying executables by adding the symbolic link created in the last step to your PATH environment variable. Append the link to the existing PATH variable as follows:

$ export PATH="$PATH:<SQDATA_DIR>/bin" 

This setting will only affect the current shell or the current logged on user. If you would like to maintain this behavior for all new sessions, alter the <sqdata_user> profile. For example, in bash environments, add the export command to the user’s /home/<sqdata_user>/.bashrc file. If you edit the user’s profile, it must be resourced for the changes to take effect in the current session. Administrator privileges are not required for a user to alter its own PATH variable and are generally not required for a user to alter its profile.

Various environment variables can be used by Connect CDC (SQData). For example, if an Engine will Apply to Oracle, the environment variables ORACLE_SID and ORACLE_HOME need to be populated.

If an Engine will Apply to Db2/LUW (UDB), the environment variable DB2_INSTANCE needs to be populated by sourcing db2profile. Connect CDC (SQData) will use this information, together with the standard install locations for each product, to find and load the necessary drivers and libraries. If the products are not installed in a standard location, Connect CDC (SQData) looks for specific environment variables to override the defaults. For example, the LD_LIBRARY_PATH environment variable to find ODBC drivers. Usually, only database specific environment variables need to be populated as described above.

Environment variables can be set when a session starts by altering the sqdata_user profile. For example, to set the ORACLE_SID to "sqdata", add "export ORACLE_SID=sqdata" to the user's /home/sqdata/.bashrc file for bash environments.

The installation can now be verified by simply typing in the module name of interest at the command line. Generally, if you provide the module name without any arguments or provide either --help, -V, or -h, information about the product such as the command line syntax and/or version information is displayed. It is a good idea to run the following command from the command line to verify that the soft link and PATH variable has been updated correctly and that you are running the expected version of the code:

$ sqdata -V