Document ID: 38113.1
Subject: Replication Setup - What To Check When It Fails
Author: toscroft
Last Revision Date: 13 May 1996
Introduction
------------
It is essential that every detail is correct to ensure that the initial
setup of Symmetric Replication succeeds. A frequent problem is for the
creation of the replicated schema and the generation of replication support
on each object to go smoothly but, after 'dbms_repcat.add_master_database()'
is run, entries stay in repcatlog on the masterdef site with a status of
'AWAITING CALLBACK' and on the master site with a status of 'READY'.
If this should happen when you first set up Symmetric Replication, check
the following:
1. Database Links
--------------
It is important for every user involved in Symmetric Replication to be
able to connect via a database link to its counterpart on the other site.
The users who should be considered are:
a. Surrogate Replication Administrator (referred to here as REPSYS):
This user allows some of the replication activities to be performed
as SYS, and has a subset of SYS's privileges.
b. Replication Administrator (referred to here as REPADMIN):
This user configures the replicated environment and performs
administration of all replicated schemas.
c. Schema Owner (referred to here as REPUSER):
This user can be the same or separate to REPADMIN. If separate, REPUSER
can be granted privileges to administer the replicated objects in his
own schema.
d. End Users:
These users must be able to access the objects in the replicated
schema, but have no administration privileges.
During setup of Symmetric Replication it is essential that the correct
database links are setup for REPSYS, REPADMIN and REPUSER. These links
should be:
Masterdef Master
SYS -> REPSYS
REPSYS <- SYS
REPADMIN -> REPADMIN
REPADMIN <- REPADMIN
REPUSER -> REPUSER
REPUSER <- REPUSER
A public database link is usually setup between the two sites, in both
directions, to allow transactions initiated by end users to be replicated.
NOTE
====
GLOBAL_NAMES MUST BE SET TO TRUE IN THE INIT<SID>.ORA AT ALL SITES.
2. The Listener
------------
The SQL*Net v2 listener must be running. If the listener configuration
files (tnsnames.ora and listener.ora) are not in the default location
($ORACLE_HOME/network/admin) then the environment variable, TNS_ADMIN,
must be set to point to the location where they are stored.
3. Naming of Replication Users
---------------------------
For setup to succeed, the main users MUST have identical names before 7.3.
This is because the names of these users are passed over as arguments to
remote procedure calls.
The users who must have identical names on both sites are:
a. Surrogate Replication Administrator
b. Replication Administrator
c. Schema Owner
4. Correct Arguments To Replication Procedures
-------------------------------------------
It is important to fully qualify the database name when using it as
an argument to dbms_repcat.add_master_database(). By this, we mean that
the database name should be that retrieved if the following query is
performed on the master (target) site:
SQLPLUS> select * from global_name;
5. Finally ....
------------
Repeated attempts to setup Symmetric Replication can leave old entries
in the replication tables. Before doing any setup, make sure that these
are clean by executing the following procedures:
At the masterdef:
execute dbms_repcat.drop_master_repschema('<SCHEMA>');
At the masterdef and all master sites:
execute dbms_repcat.purge_master_log(sname => '<SCHEMA>');
(See Reference Section of Distributed Systems Manual for exact syntax).
NOTE
====
These must be run and the setup of Symmetric Replication started again
if steps are taken to correct any errors found after following the
checklist above.
If, after checking the points above, you are still having problems setting
up Symmetric Replication, please call ORACLE Worldwide Support.