Вы находитесь на странице: 1из 12

InfoSphere Data Replications Change Data Capture

for Oracle Configurations (IIDR 10.2.x)

Version 1.0

IBM Information
Management

Table of Contents
Table of Contents ............................................................................................................................ 2
Introduction ................................................................................................................................. 2
RAC ............................................................................................................................................ 3
ASM ............................................................................................................................................ 4
Archive only mode...................................................................................................................... 7
Read-only source support ........................................................................................................... 7
Remote log reading ..................................................................................................................... 8
Log shipping ............................................................................................................................... 9
Remote Apply ........................................................................................................................... 12

Introduction
This document discusses the different Oracle configurations supported by InfoSphere Data Replications
Change Data Capture (IIDR-CDC). It covers Real Application Clusters (RAC) and Automated Storage
Manager (ASM) options available with Oracle as well as remote log reading and apply options available
with IIDR-CDC. It provides a step-by-step approach to the specific tasks which need to be performed
while installing and configuring IIDR-CDC.

RAC
Considerations
One of the main reasons customers use a RAC environment is to enable failover capabilities. In order to
incorporate IIDR-CDC into the same concept there are two criteria that the configuration must allow:

Ability to restart IIDR-CDC from a different location that is, IIDR-CDC binaries, configuration
files and operational metadata need to be accessible from both locations.
Ability to connect to IIDR-CDC by external clients or processes (for example, for subscriptions
targeting the failed IIDR-CDC instance).

With this in mind here are some best practices to install IIDR-CDC on a RAC environment:

IIDR-CDC can be installed on a node of the cluster or outside of the cluster. It is preferable to
install outside the cluster to facilitate failover scenarios
IIDR-CDC should be installed on the mount point of a SAN
IIDR-CDC must have access to all archived and online redo logs generated by all nodes on the
RAC.

Steps
1. Install IIDR-CDC on a node inside or outside of the Oracle RAC but on the mount point of a SAN
2. Create an entry on /etc/hosts for each node involved in the configuration using a common
host_name entry and pointing to the corresponding IP. This way regardless of the node on which
IIDR-CDC is started, the host_name will be the same and hence configuration wont be affected.
Here is an example. Say we have NODE A and NODE B on the RAC:
/etc/host on NODE A
#cdc_host <IP address of NODE A>
/etc/host on NODE B
#cdc_host <IP address of NODE B>
3. Specify the global Oracle RAC node SID.
4. If the RAC environment contains inactive nodes IIDR 10.2 for Oracle requires InterimFix 3 and
above.
5. While creating the CDC instance the two items related specifically to RAC are:
ORACLE_HOME: Full path of the ORACLE_HOME
SERVICE NAME: tnsnames.ora entry name you created in step 2)

NOTE: if the Oracle RAC uses ASM then refer to the details under ASM configuration as well.

ASM
Considerations
There are special considerations while installing IIDR-CDC against an Oracle database where the logs
are managed by Automatic Storage Management (ASM):

IIDR-CDC requires an Oracle ASM connection (user name and password) which requires sysdba
and sysadm privileges.
o This is typically ASMs sys user
Physical access to the underlying RAW block device storage.
o Look for the raw device location by querying: select NAME, CREATE_DATE from
v$asm_disk
o Verify permissions: ls l <raw device directory>
o Validate Unix users permissions: id

IIDR-CDC can be configured to connect locally or remotely to ASM (in RAC and NON-RAC scenarios).
The configuration is slightly different in those scenarios:
Connecting to ASM locally1
1. Install IIDR-CDC on a server which can access ASM locally
2. Create an entry in /etc/hosts for each node involved in the configuration using a common
host_name entry and pointing to the corresponding IP
3. Specify the global Oracle Node SID
To verify the connectivity to the database as follows: from the command line run sqlplus
user/pass@SID_CDC and sqlplus user/pass@SID_ASM.
4. While creating the CDC instance, ensure the following items are entered correctly:
ORACLE_HOME:
Full path of the ORACLE_HOME
SERVICE NAME:
tnsnames.ora entry name you created in step 3)
ASM ORACLE_PATH: Full path for the ASM ORACLE_HOME
ASM USER:
User with sysdba and sysadm privileges
ASM PASSWORD:
Password for the ASM USER
IIDR 10.2.1 enhancement: If the customer does not wish to access ASM logs due to preference or
security purposes, providing ASM credentials is now optional. As an alternative there must be a nonASM destination accessible to CDC. This can be set up using multiplexed logs that is typically configured
for archive logs only.

Connecting to ASM remotely


Steps here are the same as above with two additional considerations.

We have seen performance implications as a result of connecting to ASM remotely. An alternative


and preferred approach is to multiplex or ship the archive logs outside of ASM. CDC can then be

Local ASM configuration requires IIDR 10.2 IF9 and above

configured with archive log only mode using remote log reading or log shipping. See the
configuration details in their corresponding sections of this document.

Specify Archive log only mode

To allow access to the ASM devices, IIDR-CDC must be installed on the same SAN as Oracle ASM.

During the configuration of the instance specify any mount point overrides configured for the ASM
devices as they appear in the PATH column of the V$ASM_DISK view.
1. Install IIDR-CDC on a server which shares the same SAN used by Oracle ASM.
2. Create an entry on /etc/hosts for each node involved in the configuration using a common
host_name entry and pointing to the corresponding IP
3. If SCAN listener is used no modifications to listener.ora are required. Otherwise, open listener to
allow remote connection to ASM. Add ASM_SID to the static list in the listener.ora file of the
server
SID_LIST_<listener name> =
(SID_LIST =
(SID_DESC =
(SID_NAME = <a db SID>)
(ORACLE_HOME = <ORACLE HOME>)
)
(SID_DESC =
(SID_NAME = <ASM SID Name>) +---> new entry for ASM instance
(ORACLE_HOME = <ORACLE HOME>)
)
)
Then add the name to tnsnames.ora at the client:
<ASM NAME> =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST=<ASM host IP>)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SID = +ASM1)
)
)
4. A similar approach has to be taken for the tnsnames.ora configuration. In this setting we need to
create two tnsnames.ora entries:
One for the database (note that if RAC is been used, then the SID_DB should correspond to the
SID of one node, not the global one):
SID_CDC=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST=cdc_host)(PORT=1521))
(CONNECT_DATA=(server=DEDICATED)
(SERVICE_NAME=SID_DB)
)
)
And one for the ASM:
SID_ASM=
(DESCRIPTION=

(ADDRESS=(PROTOCOL=TCP)(HOST=cdc_host)(PORT=1521))
(CONNECT_DATA=(server=DEDICATED)
(SERVICE_NAME=SID_ASM)
)
)
To verify that the entries are properly defined, verify the connectivity to the database as follows:
from the command line run sqlplus user/pass@SID_CDC and sqlplus user/pass@SID_ASM.
5. While creating the CDC instance ensure the following items are configured correctly:
ORACLE_HOME
Full path of the ORACLE_HOME where the tnsnames.ora containing the
connections strings can be found.
SERVICE NAME
tnsnames.ora entry name you created on step 3) for the database
ASM ORACLE_PATH Full path for the ASM ORACLE_HOME where the tnsnames.ora
containing the connections strings can be found.
ASM USER
User with sysdba and sysadm privileges
ASM PASSWORD
Password for the ASM user
6. If running on Linux platform and ASM uses asmLib (a Linux library set produced by Oracle to
manage raw devices on Linux platform we need this extra parameter configured. Normally you
can obtain this from the PATH column in v$ASM_DISK but in this specific case its content will be
ORCL: To get the value to populate the system parameter, run "oracleasm status" command.
An example of its output would be:
> /etc/init.d/oracleasm status
Checking if ASM is loaded: yes
Checking if /dev/oracleasm is mounted: yes
The second line indicates the PATH we were looking for. Set the ORCL path to the path
appearing in the second line of the above output with /disks appended to the value.
To check the hard disk WWID
/sbin/scsi_id -g -u -s /block/<disk name>

7. Specify the global ASM SID in the advanced properties of the remote configuration using the
entry in tnsnames for ASM (SID_ASM).

Note: Oracle dba and system/storage administrators are responsible for finding out which raw devices are
used by ASM to mange redo log files (IIDR-CDC only needs redo log files, not data files), and make those
raw devices available to IIDR-CDC while meeting the requirements stated. This section is just to provide
some hints on how to achieve that objective.

Archive only mode


Considerations
Online logs are a source of disk contention in that both Oracle and IIDR-CDC can access them
simultaneously. Therefore, the operating system must share the underlying device between reader
(CDC) and writer (Oracle). In this case, if the physical disks do not have sufficient IO operations per
second, both products will be constrained. Oracle will find that writes will queue and take longer to
complete, and CDC will stall on disk reads. If this is problematic in your environment, IIDR-CDC can be
configured to only read archive logs. Be aware that this will affect latency.
Steps
1. The archive log only option is now configured in the dmconfigurets tool. In the command line
version specify y for archive log only. In the GUI interface select the Archive only mode
checkbox. The system parameter oracle_archive_logs_only has been deprecated in IIDR
10.2 and above.

Read-only source support


Considerations
Use this configuration when the user is not allowed write access to the source database.
To configure this feature you must:
Create a read-only user in the Oracle source database
Enable table-level supplemental logging for tables which will be replicated in your database
before installing and configuring IIDR-CDC.
Only use this instance of IIDR-CDC as a source datastore
Steps
1. Create a read-only user.2
2. Enable table-level supplemental logging3
3. While configuring the IIDR-CDC instance select the read-only database option.
Notes:
IIDR-CDC will check at startup if supplemental logging is configured. As users must configure this
themselves for a read-only instance, it is possible that this is done in a manner unexpected by IIDR-CDC
and this check will fail. To avoid this sanity check (at your own risk), the system parameter
read_only_check_supplemental_logging can be set to false.

Refer to the createuser-ora-readonly.sql sample script found in the <CDC install directory>/samples/
directory
3
In Oracle 10g and above supplemental logging can be enabled for all columns using the sql command: ALTER
TABLE <tablename> ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

Remote log reading


Considerations
Use this configuration when:
IIDR-CDC has no direct access to the Oracle online redo log files and archived log files because
it is installed on a separate server.

Source server is overloaded and cannot accommodate the additional resources IIDR-CDC
requires.

This configuration can work either in regular mode (online and archived) or archived only mode.
Steps
1. Install IIDR-CDC on a server different from the database server
2. Create an entry on /etc/hosts for the database server pointing to the corresponding IP. I.e.
#db_host <IP address of database host>
3. Create a tnsnames.ora entry pointing to the remote database. I.e.:
SID_CDC=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST= db_host)(PORT=1521))
(CONNECT_DATA=(server=DEDICATED)
(SERVICE_NAME=SID)
)
)
To verify that the entries are properly defined, verify the connectivity to the database as follows:
from the command line run sqlplus user/pass@SID_CDC.
4. While creating the IIDR-CDC instance, ensure the following fields are set correctly:
ORACLE_HOME Full path of the oracle client on the local box where tsnnames.ora can be
found.
SERVICE NAME tnsnames.ora entry name you created in step 3
5. While configuring the IIDR-CDC instance select the Remote log reading mode. If the location
name where the logs (online and archived) are available on the local host does not match the
location on the database server, select the Advanced Configuration and specify the mount points
and their overrides. The system parameter oracle_archive_dir has been deprecated in
IIDR 10.2 and above.
6. If the logs IIDR-CDC will read are from a different OS than the server where IIDR-CDC is installed,
then system parameter mirror_redo_log_format should be set indicating the OS on which
the log files were created. Possible values are: HPUX, SUN, AIX (big endian) and LINUX, WIN32
(little endian). Note that both platforms must share the same endianess.

Log shipping
Considerations
There are two main reasons for using this feature:
Avoid overloading the source server moving the processing to another server.
Avoid log retention dependencies on the source system
To use this feature, IIDR-CDC for Oracle databases must be configured to only use Oracle archive logs.
Be aware that this configuration will affect latency of the overall system. You can ship your database logs
with:
Oracle Data Guard log transport services
A customized log shipping process that you develop and maintain.
Note that the endianess of the server where IIDR-CDC is installed must match the endianess of the
system where the logs were created.

Steps:
1. Configure the read archive log only mode when the instance is first created.
2. Select the Manual log shipping or Log shipping with Data Guard configuration mode in the
configuration tool.
3. Put in place the log shipping mechanism by selecting the Advanced Configuration options and
select the desired log shipping method:
a. If shipping the logs using Oracle Data Guard, then you need to set up the following extra
settings:
i.
Spe cify the location where IIDR-CDC can read the shipped logs. This is the local
directory (on the machine where IIDR-CDC is installed) to which the logs are shipped.
If the system involves a RAC environment then logs of individual nodes must be
placed in subdirectories called after the node thread id.
ii.
If the directory may change, then a user exit can be written to return the directory
which IIDR-CDC will look in to find the next archive log. In order to use this user exit,
system parameter oracle_log_path_userexit has to be set pointing to the
PATH where the userexit can be located.
iii.
Specify the naming convention for the archive logs on the standby location by setting
the Log name pattern in the configuration tool. It must contain the %t (thread id)
variable and %s (sequence number) variable in order to identify which logs are
associated with each node. This is required whether in a RAC or non-RAC
environment. IIDR-CDC will fail with an error if those variables are not specified.
iv.
Specify the destination id that Oracle Data Guard will use to ship the logs (DEST_ID
column on V$ARCHIVED_LOG view where DEST_ID is the Oracle Archiver
process that sends archived logs to the oracle standby database)
v.
In IIDR 10.2.1 and above there is an additional optional setting to specify a database
connection to the Physical Standby database. The additional connection to the
Physical Standby database will offload more intensive database queries to the
standby location. The log dependency information will also be based on the status of
the standby database. The bequeath connection requires the sys as sysdba user
credentials. Note that the database connection to the primary database is still
required. Select the Connect to physical standby database option that appears in
the Advanced configuration display

vi.

If Oracle Data Guard is disabled temporarily the user can choose to manually register
the logs on the standby database using the SQL command. E.g alter database
register logfile '/var/arch/arch_1_101.arc. CDC will detect the availability of the logs
if the physical standby settings are configured

b. If shipping the logs using a Custom Solution, the archive logs can be shipped as they are
created or on a periodic basis using a cron job. Select the Manual log shipping method. In
a RAC environment the script could be run on EACH node. Here is an example pseudo code
for the script that is to be run on each node:
Query v$archived_log to find out which archives have been completely
written by Oracle by checking STATUS = A and THREAD# = <The node you
are running on>
For each new archive log file loop
Perform a CRC check (cksum <local filename>) on the local file. Save
the CRC checksum for the local file.
Ship the file to the remote server using ftp, sftp, or scp. Ensure
that the name of the file remains unchanged. Depending on the node
number make sure you ship it to /archivelog/mycdcsystem/<node number>
Using a remote shell (rsh) perform a CRC check (cksum <remote
filename>) on the remote file. Check to ensure that the checksum
matches the local one. If not then resend the file.
Inform CDC that the archive log file is available using remote shell
(rsh) by calling this command:
dmarchivelogavailable I <instance name> -t <node number> -f <archive
log file name>
End loop

Register the archive logs after they have been successfully transported to the remote location.
dmarchivelogavailable
Use this command to specify the shipped Oracle archive logs are ready to be read by IIDRCDC. You should run this command only after the complete Oracle archive log file has been
shipped from the system where your Oracle database is installed.
Syntax
dmarchivelogavailable I <INSTANCE_NAME> [-t thread_number] d <file name>
Note: For RAC environments IIDR-CDC will read the archive logs from subdirectories that are
named using the thread number. For example, /archivelog/mycdcsystem/1 for thread 1 and
/archivelog/mycdcsystem/2 for thread 2.
In a two node RAC environment, ship the archive logs for node 1 to this directory
<oracle_archive_dir>/1
Similarly, ship the archive logs for node 2 to this directory
<oracle_archive_dir>/2
Create a script on the remote server to periodically remove the archive logs that are no
longer required by CDC. There are two CDC commands you can use to accomplish this:
dmshowlogdependency
Use this command to display information about the database logs that are used by CDC and
are required for replication. Use this command to implement a log retention policy.
Syntax
dmshowlogdependency -I <INSTANCE_NAME> -A -i

Example output:
/archivelog/dmc9264/arch_1_22781,Available,Exists
/archivelog/dmc9264/arch_1_22781,Not Available,Missing
dmarchivelogremoved
Use this command to specify the shipped Oracle archive logs that are no longer required by
IIDR-CDC. You should run this command before removing a shipped Oracle archive log. You
should run this command to cleanup the CDC metadata which holds the list of all archive logs
that are available. CDC is not responsible for physically removing the log files.
Syntax
dmarchivelogremoved -I <INSTANCE_NAME> -d <file name> [-a]

Note: System parameters oracle_log_shipping, oracle_archive_dir,


log_archive_format, oracle_using_log_transport_services,
oracle_using_log_transport_services have been deprecated in IIDR 10.2 and
above.

Remote Apply
Considerations
This IIDR-CDC configuration is used when the target database server resides on a different server than
IIDR-CDC.
Steps
1. Install IIDR-CDC on a server different from the target database server
2. Create an entry on /etc/hosts for the IIDR-CDC server pointing to the corresponding IP. i.e.
#db_host <IP address of target database host>
3. Create a tnsnames.ora entry pointing to the remote target database. I.e.:
SID_CDC=
(DESCRIPTION=
(ADDRESS=(PROTOCOL=TCP)(HOST= db_host)(PORT=1521))
(CONNECT_DATA=(server=DEDICATED)
(SERVICE_NAME=SID)
)
)
4. While creating the CDC instance, ensure the following fields are set correctly:
ORACLE_HOME Full path of the oracle client on the local box where tnsnames.ora can be
found.
SERVICE NAME tnsnames.ora entry name you created in step 3

Вам также может понравиться