ra_admin

Returns the names of Replication Agent system objects; creates them in the primary database, or removes them from the primary database.

For Oracle and Microsoft SQL Server, ra_admin verifies that permissions are valid for Replication Agent to obtain system data from the primary database. For Oracle, ra_admin also checks the condition of the primary database to determine whether archiving is turned on, and then loads the RASD with system data from the primary database.

Note: Use ra_admin and ra_locator instead of pdb_xlog, which has been deprecated.

Syntax

ra_admin [ { init | refresh | deinit[, force] | prepare | supplemental_logging_level[, { database | table } ] } ]

Parameters

init – the keyword for creating Replication Agent system objects in the primary database.
refresh – a keyword for reinitializing Replication Agent, creating, or reloading any required transaction log base components.
deinit – the keyword for removing a transaction log.
force – a keyword that refers to the deinit operation.
Note: The parameters prepare, supplemental_logging_level, database, and table are only used for Oracle.
prepare – the keyword for generating a script that is used for granting permissions to pds_username and turning on supplemental logging according to the supplemental logging level setting.
supplemental_logging_level – the keyword for the setting the supplemental logging level on a primary database.
database – the keyword for representing supplemental logging at database level.
table – the keyword for representing supplemental logging at table level.

Examples

Example 1 –
```
ra_admin init
```
This command initializes Replication Agent, creating any required transaction log base components.
Example 2 –
```
ra_admin refresh
```
This command reinitializes Replication Agent, creating or reloading any required transaction log base components.
Example 3 –
```
ra_admin deinit
```
This command removes any Replication Agent transaction log base components.
Example 4 –
```
ra_admin deinit, force
```
This command removes any Replication Agent transaction log base components and ignores any individual errors that occur during removal.
Example 5 –
```
ra_admin prepare
```
For a new Replication Agent instance, this command generates an SQL script to grant the required permissions to pds_username and turn on supplemental logging according to the supplemental logging level setting.
Example 6 –
```
ra_admin supplemental_logging_level,database
```
This command sets supplemental logging level to database level. For existing Replication Agent instances, this command also generates an SQL script that turns on database-level primary key and unique index supplemental logging.
Example 7 –
```
ra_admin supplemental_logging_level,table
```
This command sets supplemental logging level to table level. For existing Replication Agent instances, this command also generates an SQL script. The SQL script turns off supplemental logging at database level and turns on table-level primary key and unique supplemental logging of the required Oracle system tables, already marked user tables, and Replication Agent system tables.

Usage

When you invoke ra_admin with no option, it returns the actual names (not synonyms or aliases) of all Replication Agent system objects in the primary database. For Oracle and Microsoft SQL Server, if you have initialized Replication Agent, it returns the name of the component and the primary database instance name.

See the section for your specific primary data server in the Replication Agent Primary Database Guide for more information on Replication Agent object names.
If you invoke ra_admin with no option and the Replication Agent system objects do not exist in the primary database, or the RASD has not been initialized (for Oracle and Microsoft SQL Server), the command returns no information.
If you invoke ra_admin with the init keyword, the truncation point is moved to the end of the primary database transaction log.

Note: For Microsoft SQL Server, during the ra_admin init process, Replication Agent may connect to the Microsoft SQL Server using pds_dac_port_number. See the Replication Agent Primary Database Guide.
When you invoke ra_admin with the init keyword, Replication Agent:
- Generates a SQL script that creates the Replication Agent tables and procedures in the primary database.
- Saves the generated script in a file called partinit.sql in the RAX-15_5\inst_name\scripts\xlog directory, where inst_name is the name of the Replication Agent instance.
  
  Note: If the value of the pdb_auto_run_scripts configuration parameter is false, the partinit.sql script is saved but not executed. However, you cannot manually run the script. To complete initializing Replication Agent, first set pdb_auto_run_scripts to true, then re-run the ra_admin init command.
- Executes the script to create the Replication Agent system objects in the primary database (if the value of the pdb_auto_run_scripts configuration parameter is true).
- After the script completes successfully, moves the partinit.sql file to the RAX-15_5\inst_name\scripts\xlog\installed directory.
- If the create script fails, it is stored in a file (partinit.sql) in the RAX-15_5\inst_name\scripts\xlog directory and the transaction log is not created. You can examine the script by viewing the partinit.sql file.
If you invoke ra_admin with the init keyword and the Replication Agent objects already exist in the primary database or the RASD has been initialized (for Oracle and Microsoft SQL Server), ra_admin returns an error message.
If you invoke ra_admin with the refresh keyword, the truncation point is moved to the end of the log if Replication Agent is not already initialized. However, if Replication Agent is already initialized, the truncation point is not moved.

Note: Use ra_admin refresh only when advised by Sybase Technical support.
When you invoke ra_admin with the deinit keyword, Replication Agent:
- For UDB, ra_admin uninstalls the JAR files from the primary database (the JARs are installed by the ra_admin init command). You must use ra_admin deinit to deinitialize Replication Agent for UDB and remove the truncation stored procedures and JARs from the database.
- Generates a SQL script that deletes the tables and procedures required for the system objects in the primary database.
- Saves the generated script in a file called partdeinit.sql in the RAX-15_5\inst_name\scripts\xlog directory, where inst_name is the name of the Replication Agent instance.
  
  Note: If the value of the pdb_auto_run_scripts configuration parameter is false, the partdeinit.sql script is saved but not executed automatically. You cannot manually run the script. To complete deinitializing Replication Agent, first set pdb_auto_run_scripts to true, then re-run the ra_admin deinit command.
- Executes the script to delete the Replication Agent objects from the primary database (if the value of the pdb_auto_run_scripts configuration parameter is true).
- After the script completes successfully, moves the partdeinit.sql file to the RAX-15_5\inst_name\scripts\xlog\installed directory.
- If the script fails, it is stored in a file (partdeinit.sql) in the RAX-15_5\inst_name\scripts\xlog directory and the Replication Agent objects are not deleted from the primary database. You can examine the script by viewing the partdeinit.sql file.
When you invoke ra_admin with the deinit keyword followed by the force keyword, the partdeinit.sql script continues executing, even if errors occur. The force keyword may be useful when a previous remove operation failed and the partdeinit.sql script terminated with an error.
If you invoke ra_admin with the deinit keyword, and Replication Agent objects do not exist in the primary database or the RASD has not been initialized (for Oracle or Microsoft SQL Server), ra_admin returns an error message.
If you invoke ra_admin with the deinit keyword and any objects in the primary database are still marked for replication, ra_admin returns an error message.

You can use the pdb_setrepproc and pdb_setreptable commands to determine which stored procedures and tables in the primary database are still marked. You also can use the pdb_setrepddl command to determine if DDL is enabled.

Even if objects are marked in the primary database, you can use ra_admin with the deinit keyword followed by the force keyword to unmark any marked objects, and then remove the transaction log objects.
If you invoke ra_admin with no option, the command is valid when the Replication Agent instance is in the Admin, Replicating, or Replication Down states.
If you invoke ra_admin with either the init or deinit keyword, the command is valid only when the Replication Agent instance is in the Admin or Replication Down state.
The ra_admin init command verifies that these privileges have been granted to pds_username:
- EXECUTE_CATALOG_ROLE
- SELECT ON V_$LOGMNR_CONTENTS
- SELECT ON V_$LOGMNR_LOGS
These privileges are necessary for the ra_dumptran and ra_helpop commands to function properly. These privileges are not required for replication, only for using the ra_dumptran and ra_helpop commands, which are used in debugging and troubleshooting. If these privileges have not been granted at the time you invoke ra_admin init, a warning message is returned and logged in the Replication Agent log file.
To return the status of supplemental logging level, use ra_admin supplemental_logging_level, without the database or table keywords. By default, the supplemental logging level value is set to database.
If you run ra_admin supplemental_logging_level, {database | table} to set the supplemental logging level value, and if the value you specify is same as the current supplemental logging level value, the command returns a message. The message indicates that the current supplemental logging level is already set to the specified value.
For new Replication Agent instances, the supplemental logging level value is set to database by default. Every time you run ra_admin supplemental_logging_level, {database | table} to set the supplemental logging level value, you must run the ra_admin prepare command that generates an SQL script. The database administrator must run this script to initialize the primary database. For database-level supplemental logging, the generate script turns on minimal supplemental logging and database-level primary key and unique index supplemental logging. For table-level supplemental logging, the generate script turns on minimal supplemental logging and turns on table-level primary key and unique index supplemental logging of all required Oracle system tables.
For existing Replication Agent instances, run ra_admin supplemental_logging_level, {database | table} to switch from current supplemental logging level to another. The command sets the supplemental logging level and also generates an SQL script. When you switch from database level to table level, the script turns off database-level primary key and unique index supplemental logging and turns on table-level primary key and unique supplemental logging of required Oracle system tables, already marked user tables, and Replication Agent system tables. When you switch from table level to database level, the script turns on database-level primary key and unique index supplemental logging.
For supplemental logging at table level, the script generated from either ra_admin prepare for a new instance, or from ra_admin supplemental_logging_level, table, turns on table-level supplemental logging of these Oracle system tables:
- SYS.ARGUMENT$
- SYS.ATTRIBUTE$
- SYS.COLLECTION$
- SYS.COLTYPE$
- SYS.DEFERRED_STG$
- SYS.INDCOMPART$
- SYS.INDPART$
- SYS.INDSUBPART$
- SYS.LOB$
- SYS.LOBCOMPPART$
- SYS.LOBFRAG$
- SYS.MLOG$
- SYS.NTAB$
- SYS.OPQTYPE$
- SYS.PROCEDUREINFO$
- SYS.RECYCLEBIN$
- SYS.SEQ$
- SYS.SNAP$
- SYS.TABPART$
- SYS.TABCOMPART$
- SYS.TABSUBPART$
- SYS.TYPE$
For more information about the Replication Agent transaction log, see the section for your specific primary data server in the Replication Agent Primary Database Guide.