MultiSite Configuration,

Troubleshooting and Recovery Using

Oracle DB Synchronization
Technical Note

Overview
This document describes the steps to add a new site to an existing Multisite environment as well as
Oracle database synchronization details. Steps to recover a recover a site from a catastrophic failure are
also provided in Appendix C. We recommend that the ActiveVOS MultiSite Recovery technote be
consulted for detailed information, procedures and scripts.

Document Revision History

Revision Date Author Changes
2.0 October 2015 Informatica Second Release

Contents
References .................................................................................................................................................... 2
ActiveVOS MultiSite Configuration ............................................................................................................... 2
Configuring an existing MultiSite Environment ............................................................................................. 3
Procedure .................................................................................................................................................. 3
Getting the MultiSite Environment Up and Running ..................................................................................... 4
Appendix A: Troubleshooting Oracle Streams and DB Synchronization ...................................................... 8
Troubleshooting Oracle Streams ............................................................................................................... 8
Troubleshooting a Capture Process in a Replication Environment ........................................................... 8
Is the Capture Process Waiting for Redo? ............................................................................................ 8
Is the Capture Process Paused for Flow Control? ................................................................................ 9
Troubleshooting an Apply Process in a Replication Environment .......................................................... 10
Troubleshooting Specific Apply Errors .................................................................................................... 10
Appendix B - DB Synchronization ............................................................................................................... 11
Performing Point-in-Time Recovery on the Source in a Single-Source Environment ............................. 11
Performing Point-in-Time Recovery on a Destination Database ............................................................ 15
Appendix C - Recovering a site from failure ............................................................................................... 17
Procedure ................................................................................................................................................ 17
Detailed Instructions ................................................................................................................................ 17

Page 1 of 19
References
Reference Material

1) ActiveVOS MultiSite Concepts,

http://infocenter.activevos.com/infocenter/ActiveVOS/v92/index.jsp?topic=/doc.server_console/ht
ml/SvrUG6-11.html
2) ActiveVOS Server MultiSite Configuration,
http://infocenter.activevos.com/infocenter/ActiveVOS/v92/index.jsp?topic=/doc.server_install/webl
ogic/html/Configuration_MultiSite.html
3) Setting up MultiSite on Oracle WebLogic, http://www.activevos.com/cp/814/setting-up-
activevos-multisite-on-oracle-weblogic
4) ActiveVOS MultiSite Recovery, Dated 1 October 2015

3rd Party Reference Material

This document describes the steps to add a new site to an existing Multisite environment as
well as database synchronization details.
1) http://docs.oracle.com/cd/B28359_01/server.111/b28322/man_gen_rep.htm#i1016713

2) http://docs.oracle.com/cd/B28359_01/server.111/b28322/troub_rep.htm#CEGEEBCH

3) Oracle Streams - High Speed Replication and Data Sharing

By Madhu Tumma
Rampant TechPress
ISBN: 0-9745993-5-2
ISBN-13:978-0974599359

ActiveVOS MultiSite Configuration

ActiveVOS Server supports a site configuration, which allows a cluster of process servers to replicate its
database to other databases serving other sites. Each site has its own cluster of servers with a single
persistent database. All process instances are available for execution at each site. In the event of a
server failure at one site, a process that started execution on that site can complete on a different site.

In addition, most ActiveVOS server configuration properties are replicated from site to site. This means
you can configure server properties in one site’s server console, and they are automatically copied to
another site’s server console.

For more information on MultiSite setup, configuration as well as MultiSite properties please refers to our
help center documentation at the following (ActiveVOS 9.2) URLs:

 http://infocenter.activevos.com/infocenter/ActiveVOS/v92/index.jsp?topic=/doc.server_console/ht
ml/SvrUG6-11.html
 http://infocenter.activevos.com/infocenter/ActiveVOS/v92/index.jsp?topic=/doc.server_install/webl
ogic/html/Configuration_MultiSite.html

This technote describes steps to recover a site from a catastrophic failure. The database synchronization
procedures have also been added which can be helpful in resolving errors that might occur due to
replication issues in a MultiSite environment. It assumes that you are already familiar with various aspects

Page 2 of 19
of a typical MultiSite environment. For details on setting up a new MultiSite environment, readers may
refer to “Setting up MultiSite on Oracle WebLogic” technote available on Informatica’s ActiveVOS web
site.

Configuring an existing MultiSite Environment

This section describes how a new site can be added to an existing site.

Suppose there are 2 sites running in a MultiSite environment. For some reason, Site 2 gets stops
functioning and it needs to be setup again with all new equipment. In the meantime, Site 1 continues to
run and service user requests. Once Site 2 is back on line, it needs to be brought in sync with Site1.

Procedure
Here are the general steps you can use to get the two sites in sync:

1) Install an Oracle database and setup an Oracle WebLogic cluster in your new environment
(Site2). Make sure the managed servers in WebLogic cluster have unique names.
2) Create a tablespace which should have the same name as the name of the tablespace on Site1
database.
3) Stop the deployments and the managed servers on Site1.
4) Update NAME, ADMINCONSOLEURL and SITESERVICEURL parameters in AESITE table with
values specific to Site2.
5) Export the ActiveVOS database residing on Site1 database. The oracle utility expdp has been
found to be particularly useful to complete this task. Sample screenshots showing expdp are
shown below:

Page 3 of 19
 6) Copy the dump file to Site2 environment and use impdp utility to import the tables and schema in
Site2 database.
7) On the Site2 database, update the SiteId column in AEMETAINFO table with a value specific to
Site2. For example, if the SiteId columns shows a value of ‘0’ on Site1 database, it should be set
to ‘1’ on Site2 database.
8) Setup and test Oracle Streams between the two databases.
9) Navigate to Site2. Start WebLogic managed servers and install ActiveVOS server and ActiveVOS
Central by running the installer utility (config_deploy). While running the utility, make sure you
“UNCHECK” the “Install Database Schema” option (since the ActiveVOS schema and tables
have already been replicated in Site2 database).
10) Once ActiveVOS Server and Central have been installed, login to the Oracle WebLogic admin
console and shutdown the two managed servers. This will complete the setting up of Site2.

Getting the MultiSite Environment Up and Running

1) Login to WebLogic admin console on Site1, start the managed server and the deployments.
Navigate to ActiveVOS console, for example,

http://site1:port/activevos

Navigate to Admin > Server Status > The ActiveVOS server should be in running state. Since this
is an existing site, the license should already be there. Navigate to Cluster > Cluster Status. The
two nodes (Server -0 and Server-1 ) should be in running state. If they are in "starting" state, you
will need to wait for some time until both the nodes are up. Also, if a particular node is stopped,
click on the node and click 'Start Engine'.

2) Login to WebLogic admin console on Site2, start the managed servers and the deployments.

Page 4 of 19
 Navigate to ActiveVOS console

http://site2:port/activevos

Navigate to Admin > Server Status > The ActiveVOS server should be in running state or in
starting state. Navigate to Cluster > Cluster Status. The two nodes ( Server-2 and Server-3 )
should be in running state. If they are in "starting" state, you will need to wait for some time until
both the nodes are up. Also, if a particular node is stopped, click on the node and click 'Start
Engine'.

3) After some time, both sites should be up and running with unique engine ID for each managed
server. The admin > MultiSite page should list both the sites as available as shown below:

Site1:

Page 5 of 19
and, Site2:

Page 6 of 19
In case a particular site appears as “Unavailable”, you may need to correct the Site URL under Site
Properties and Click Update.

Page 7 of 19
Appendix A: Troubleshooting Oracle Streams and DB
Synchronization
In this section, general methods to troubleshoot Oracle Streams and resynchronize databases are
described. These methods and procedures are well documented in Oracle documentation and readers
are encouraged to refer to these methods and procedures to resolve specific errors/issues they are
seeing in their environment.

Troubleshooting Oracle Streams

Oracle Streams is Oracle database’s method of data sharing. It provides a mechanism for the
propagation of database changes within the database or to the external database system. In a MultiSite
environment, Oracle Streams keeps track of all the database changes at Site1 database in terms of Data
Manipulation Language (DML) and Data Definition Language (DDL) commands. It then stages those
changes into queues and later moves them to the destination queues where they are applied to Site2’s
database objects.

In a MultiSite environment, users may encounter errors in Capture, Propagation and Apply processes.
Typically, critical errors may occur in Capture and Apply processes. These are discussed in the following
sections.

Troubleshooting a Capture Process in a Replication Environment

(Excerpt from http://docs.oracle.com/cd/B28359_01/server.111/b28322/troub_rep.htm#autoId5)

If an enabled capture process is not capturing changes as expected, then the capture process might be
in one of the following states:

 WAITING FOR REDO

 PAUSED FOR FLOW CONTROL

To check the state each capture process in a database, run the following query:

COLUMN CAPTURE_NAME HEADING 'Capture Name' FORMAT A30

COLUMN STATE HEADING 'State' FORMAT A30
SELECT CAPTURE_NAME, STATE FROM V$STREAMS_CAPTURE;

The following sections provide information about troubleshooting capture process problems in a
replication environment when the capture process state is either WAITING FOR REDO or PAUSED FOR
FLOW CONTROL.

Is the Capture Process Waiting for Redo?

If the capture process state is WAITING FOR REDO, then the capture process is waiting for new redo log
files to be added to the capture process session. This state is possible if a redo log file is missing or if
there is no activity at a source database. For a downstream capture process, this state is possible if the
capture process is waiting for new log files to be added to its session.

Page 8 of 19
Additional information might be displayed along with the state information when you query the
V$STREAMS_CAPTURE view. The additional information can help you to determine why the capture
process is waiting for redo. For example, a statement similar to the following might appear for the STATE
column when you query the view:

WAITING FOR REDO: LAST SCN MINED 8077284

In this case, the output only identifies the last system change number (SCN) scanned by the capture
process. In other cases, the output might identify the redo log file name explicitly. Either way, the
additional information can help you identify the redo log file for which the capture process is waiting. To
correct the problem, make any missing redo log files available to the capture process.

Is the Capture Process Paused for Flow Control?

If the capture process state is PAUSED FOR FLOW CONTROL, then the capture process is unable to
enqueue logical change records (LCRs) either because of low memory or because propagations and
apply processes are consuming messages at a slower rate than the capture process is creating them.
This state indicates flow control that is used to reduce the spilling of captured LCRs when propagation or
apply has fallen behind or is unavailable.

If a capture process is in this state, then check for the following issues:

 An apply process is disabled or is performing slowly.

 A propagation is disabled or is performing poorly.
 There is not enough memory in the Streams pool.

You can query the V$STREAMS_APPLY_READER view to monitor the LCRs being received by the apply
process. You can also query V$STREAMS_APPLY_SERVER view to determine whether all apply servers
are applying LCRs and executing transactions.

Also, if the capture process does not use combined capture and apply, then you can query the
PUBLISHER_STATE column in the V$BUFFERED_PUBLISHERS view to determine the exact reason why the
capture process is paused for flow control.

To correct the problem, perform one or more of the following actions:

 If any propagation or apply process is disabled, then enable the propagation or apply process.
 If the apply reader is not receiving data fast enough, then try removing propagation and apply
process rules or simplifying the rule conditions.
 If there is not enough memory in the Streams pool at the capture process database, then try
increasing the size of the Streams pool.

Page 9 of 19
Troubleshooting an Apply Process in a Replication Environment

The following Oracle documentation links provide information about troubleshooting apply process
problems in a replication environment.

 Is the Apply Process Encountering Contention?

 Is the Apply Process Waiting for a Dependent Transaction?
 Is an Apply Server Performing Poorly for Certain Transactions?
 Are There Any Apply Errors in the Error Queue?

Troubleshooting Specific Apply Errors

You might encounter the following types of apply process errors for LCRs – refer to the respective Oracle
documentation links provided here for resolution:

 ORA-01031 Insufficient Privileges

 ORA-01403 No Data Found
 ORA-23605 Invalid Value for Oracle Streams Parameter*
 ORA-23607 Invalid Column*
 ORA-24031 Invalid Value, parameter_name Should Be Non-NULL*
 ORA-26687 Instantiation SCN Not Set
 ORA-26688 Missing Key in LCR
 ORA-26689 Column Type Mismatch*
 ORA-26786 A row with key column_value exists but has conflicting column(s)
column_name(s) in table table_name
 ORA-26787 The row with key column_value does not exist in table table_name

The errors marked with an asterisk (*) in the previous list often result from a problem with an apply
handler or a rule-based transformation.

Page 10 of 19
Appendix B - DB Synchronization
One way to synchronize databases is to perform point-in-time recovery which refers to the recovery of a
database to a specified noncurrent time, SCN, or log sequence number. The following sections discuss
performing point-in-time recovery in an Oracle Streams replication environment.

Performing Point-in-Time Recovery on the Source in a Single-Source

Environment
Refer to http://docs.oracle.com/cd/B28359_01/server.111/b28322/man_gen_rep.htm#autoId50.

A single-source Oracle Streams replication environment is one in which there is only one source
database for shared data. If database point-in-time recovery is required at the source database in a
single-source Oracle Streams environment, and any capture processes that capture changes generated
at a source database are running, then you must stop these capture processes before you perform the
recovery operation. Both local and downstream capture process that capture changes generated at the
source database must be stopped. Typically, database administrators reset the log sequence number of
a database during point-in-time recovery. The ALTER DATABASE OPEN RESETLOGS statement is an
example of a statement that resets the log sequence number.

The instructions in this section assume that the single-source replication environment has the following
characteristics:

 Only one capture process named strm01_capture, which can be a local or downstream capture
process
 Only one destination database with the global name dest.example.com
 Only one apply process named strm01_apply at the destination database

If point-in-time recovery must be performed on the source database, then you can follow these
instructions to recover as many transactions as possible at the source database by using transactions
applied at the destination database. These instructions assume that you can identify the transactions
applied at the destination database after the source point-in-time SCN and execute these transactions at
the source database.

As per Oracle recommendations, you should set the apply process parameter COMMIT_SERIALIZATION
to FULL when performing point-in-time recovery in a single-source Oracle Streams replication
environment.

Complete the following steps to perform point-in-time recovery on the source database in a single-
source Oracle Streams replication environment:

1. Perform point-in-time recovery on the source database if you have not already done so. Note
the point-in-time recovery SCN because it is needed in subsequent steps.
2. Ensure that the source database is in restricted mode.
3. Connect to the database running the capture process and list the rule sets used by the capture
process.

To list the rule sets used by the capture process, run the following query:

Page 11 of 19
 COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15

SELECT CAPTURE_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_CAPTURE;

Make a note of the rule sets used by the capture process. You will need to specify these rule sets
for the new capture process in Step 15.

4. Connect to the destination database and list the rule sets used by the apply process.

To list the rule sets used by the capture process, run the following query:

COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15

COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15

SELECT APPLY_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_APPLY;

Make a note of the rule sets used by the apply process. You will need to specify these rule sets
for the new apply process in Step 12.

5. Stop the capture process using the STOP_CAPTURE procedure in the DBMS_CAPTURE_ADM
package.
6. At the source database, perform a data dictionary build:

SET SERVEROUTPUT ON
DECLARE
scn NUMBER;
BEGIN

Page 12 of 19
 DBMS_CAPTURE_ADM.BUILD(
first_scn => scn);
DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/

Note the SCN value returned because it is needed in Step 15.

7. At the destination database, wait until all of the transactions from the source database in the
apply process queue have been applied. The apply processes should become idle when these
transactions have been applied. You can query the STATE column in both the
V$STREAMS_APPLY_READER and V$STREAMS_APPLY_SERVER. The state should be IDLE for the
apply process in both views before you continue.
8. Perform a query at the destination database to determine the highest SCN for a transaction that
was applied.

If the apply process is running, then perform the following query:

SELECT HWM_MESSAGE_NUMBER FROM V$STREAMS_APPLY_COORDINATOR

WHERE APPLY_NAME = 'STRM01_APPLY';

If the apply process is disabled, then perform the following query:

SELECT APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS
WHERE APPLY_NAME = 'STRM01_APPLY';

Note the highest apply SCN returned by the query because it is needed in subsequent steps.

9. If the highest apply SCN obtained in Step 8 is less than the point-in-time recovery SCN noted in
Step 1, then proceed to step 10. Otherwise, if the highest apply SCN obtained in Step 8 is greater
than or equal to the point-in-time recovery SCN noted in Step 1, then the apply process has
applied some transactions from the source database after point-in-time recovery SCN. In this
case complete the following steps:
1. Manually execute transactions applied after the point-in-time SCN at the source
database. When you execute these transactions at the source database, ensure that you
set an Oracle Streams tag in the session so that the transactions will not be captured by
the capture process. If no such Oracle Streams session tag is set, then these changes can
be cycled back to the destination database. Disable the restricted session at the source
database.
10. If you completed the actions in Step 9, then proceed to Step 14. Otherwise, if the highest apply
SCN obtained in Step 8 is less than the point-in-time recovery SCN noted in Step 1, then the
apply process has not applied any transactions from the source database after point-in-time
recovery SCN. In this case, complete the following steps:
1. Disable the restricted session at the source database.
2. Ensure that the apply process is running at the destination database.
3. Set the maximum_scn capture process parameter of the original capture process to the
point-in-time recovery SCN using the SET_PARAMETER procedure in the
DBMS_CAPTURE_ADM package.

Page 13 of 19
4. Set the start SCN of the original capture process to the oldest SCN of the apply process.
You can determine the oldest SCN of a running apply process by querying the
OLDEST_SCN_NUM column in the V$STREAMS_APPLY_READER dynamic performance
view at the destination database. To set the start SCN of the capture process, specify
the start_scn parameter when you run the ALTER_CAPTURE procedure in the
DBMS_CAPTURE_ADM package.
5. Ensure that the capture process writes information to the alert log by running the
following procedure:

BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'strm01_capture',
parameter => 'write_alert_log',
value => 'Y');
END;
/

6. Start the original capture process using the START_CAPTURE procedure in the
DBMS_CAPTURE_ADM package.
7. Ensure that the original capture process has captured all changes up to the
maximum_scn setting by querying the CAPTURED_SCN column in the DBA_CAPTURE
data dictionary view. When the value returned by the query is equal to or greater than
the maximum_scn value, the capture process should stop automatically. When the
capture process is stopped, proceed to the next step.
8. Find the value of the LAST_ENQUEUE_MESSAGE_NUMBER in the alert log. Note this
value because it is needed in subsequent steps.
9. At the destination database, wait until all the changes are applied. You can monitor the
applied changes for the apply process strm01_apply by running the following queries at
the destination database:

SELECT DEQUEUED_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_READER
WHERE APPLY_NAME = 'STRM01_APPLY' AND
DEQUEUED_MESSAGE_NUMBER = last_enqueue_message_number;

Substitute the LAST_ENQUEUE_MESSAGE_NUMBER found in the alert log in Step 8 for

last_enqueue_message_number on the last line of the query. When this query returns a
row, all of the changes from the capture database have been applied at the destination
database.

Also, ensure that the state of the apply process reader server and each apply server is
IDLE. For example, run the following queries for an apply process named strm01_apply:

SELECT STATE FROM V$STREAMS_APPLY_READER

WHERE APPLY_NAME = 'STRM01_APPLY';

SELECT STATE FROM V$STREAMS_APPLY_SERVER

Page 14 of 19
 WHERE APPLY_NAME = 'STRM01_APPLY';

When both of these queries return IDLE, move on to the next step.

11. At the destination database, drop the apply process using the DROP_APPLY procedure in the
DBMS_APPLY_ADM package.
12. At the destination database, create a new apply process. The new apply process should use the
same queue and rule sets used by the original apply process.
13. At the destination database, start the new apply process using the START_APPLY procedure in
the DBMS_APPLY_ADM package.
14. Drop the original capture process using the DROP_CAPTURE procedure in the
DBMS_CAPTURE_ADM package.
15. Create a new capture process using the CREATE_CAPTURE procedure in the
DBMS_CAPTURE_ADM package to replace the capture process you dropped in Step 14. Specify
the SCN returned by the data dictionary build in Step 6 for both the first_scn and start_scn
parameters. The new capture process should use the same queue and rule sets as the original
capture process.
16. Start the new capture process using the START_CAPTURE procedure in the
DBMS_CAPTURE_ADM package.

Performing Point-in-Time Recovery on a Destination Database

Refer to http://docs.oracle.com/cd/B28359_01/server.111/b28322/man_gen_rep.htm#autoId53.

If database point-in-time recovery is required at a destination database in an Oracle Streams

environment, then you must reapply the captured changes that had already been applied after the
point-in-time recovery.

For each relevant capture process, you can choose either of the following methods to perform point-in-
time recovery at a destination database in an Oracle Streams environment:

 Reset the start SCN for the existing capture process that captures the changes that are applied
at the destination database.
 Create a new capture process to capture the changes that must be reapplied at the destination
database.

Resetting the start SCN for the capture process is simpler than creating a new capture process. However,
if the capture process captures changes that are applied at multiple destination databases, then the
changes are resent to all the destination databases, including the ones that did not perform point-in-
time recovery. If a change is already applied at a destination database, then it is discarded by the apply
process, but you might not want to use the network and computer resources required to resend the
changes to multiple destination databases. In this case, you can create and temporarily use a new
capture process and a new propagation that propagates changes only to the destination database that
was recovered.

The following sections provide instructions for each task:

 Resetting the Start SCN for the Existing Capture Process to Perform Recovery

Page 15 of 19
  Creating a New Capture Process to Perform Recovery

If there are multiple apply processes at the destination database where you performed point-in-time
recovery, then complete one of the tasks in this section for each apply process.

Neither of these methods should be used if any of the following conditions are true regarding the
destination database you are recovering:

 A propagation propagates persistent LCRs to the destination database. Both of these methods
reapply only captured LCRs at the destination database, not persistent LCRs.
 In a directed networks configuration, the destination database is used to propagate LCRs from a
capture process to other databases, but the destination database does not apply LCRs from this
capture process.
 The oldest message number for an apply process at the destination database is lower than the
first SCN of a capture process that captures changes for this apply process. The following query
at a destination database lists the oldest message number (oldest SCN) for each apply process:

SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;

The following query at a source database lists the first SCN for each capture process:

SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;

 The archived log files that contain the intended start SCN are no longer available.

If any of these conditions are true in your environment, then you cannot use the methods described in
this section. Instead, you must manually resynchronize the data at all destination databases.

It should be noted that if you are using combined capture and apply in a single-source replication
environment, and the destination database has undergone point-in-time recovery, then the Oracle
Streams capture process automatically detects where to capture changes upon restart, and no extra
steps are required for it.

Page 16 of 19
Appendix C - Recovering a Site from a Catastrophic Failure
Suppose there are 2 sites running in a MultiSite environment. For some reason Site 2 gets wiped out and
it needs to be re-built so that it can continue to function with Site 1.

We assume that databases for the two sites are being backed up regularly.

Detailed Instructions
Detailed information, procedures and scripts for the above are available in the “ActiveVOS Multisite
Recovery” technote.

Procedure
Step 1. Assume that the site # 2 needs to be re-built. Stop site # 1. Restore site # 2 database from
backup. This will be used for site # 2. It should be noted that the following tables are not replicated in a
multisite environment:

 AeCounter
 AeMetaInfo
 AeLock
 AeURNValues

The AeMetaInfo and AeURNValues can be left at existing values. In case of AeLock, if there are any
locks, they need to be deleted before starting site 2. The counter values in AECOUNTER table will need
to be updated with appropriate values.

The general procedure to find counter value to be put in AECOUNTER table on site B is the following:

a. Run the following query:

Select <Parameter_ID> from <Parameter table>

WHERE Mod( Parameter_ID,128)=SITE_ID_FOR_SITE_B
ORDER BY 1 DESC;

Note down the highest value retrieved by this query.

b. Use the following formula:

Counter Value ( rounded to nearest whole integer) = (Highest Value retrieved in Step #
1)/128 + 1

Assuming the AeCounter table in site B has the following values:

Page 17 of 19
One thing to note is that this table can have more counter entries (such as AeB4PTaskParameter,
PlanId, AeQueuedReceivedId etc.) though the ones listed above are the ones for which counter values
are needed.

Assuming that the SiteId for site B is 1. To find the counter value for the ProcessId parameter,

So, counter value = (257/128) + 1 =3

As another example, to find the counter value for ContributionId use:

So, counter value = (257/128) + 1 =3

Similarly, the counter values for other parameters can be found.

Step 2. Setup and test Oracle Streams between the two databases.

Step 3. Install ActiveVOS on site 2 by running the installer utility (config_deploy). While running the utility,
make sure you “UNCHECK” the “Install Database Schema” option.

Step 4. Once ActiveVOS Server and Central have been installed, login to the Oracle WebLogic admin
console and shutdown the two managed servers. This will complete the setting up of Site 2.

Page 18 of 19
Worldwide Headquarters, 2100 Seaport Blvd, Redwood City, CA 94063, USA Phone: 650.385.5000 Fax: 650.385.5500

Toll-free in the US: 1.800.653.3871 informatica.com linkedin.com/company/informatica twitter.com/InformaticaCorp

Copyright © 1993-2015 Informatica LLC. All rights reserved. Informatica® and Put potential to work™ are trademarks or registered
trademarks of Informatica

Corporation in the United States and in jurisdictions throughout the world. All other company and product names may be trade
names or trademarks.

Page 19 of 19