pdb_xlog

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

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

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

Syntax

pdb_xlog [{ init | create | remove } [, force ] | move_truncpt ]

Parameters

Examples

Usage

  • When you invoke pdb_xlog 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 pdb_xlog 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 pdb_xlog with the init keyword, the truncation point is established at the end of the primary database transaction log.

    Note: For Microsoft SQL Server, during the pdb_xlog init process, Replication Agent may connect to the Microsoft SQL Server using pds_dac_port_number. See the Replication Agent Primary Database Guide.
  • If you invoke pdb_xlog with the init, force keywords, 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 pdb_xlog init with the force keyword only when advised by Sybase Technical support.
  • If you invoke pdb_xlog with the move_truncpt keyword, the truncation point is moved to the end of the log without change or modification to any Replication Agent components. (for Oracle, this is the end of the current online redo log.) The move_truncpt option has no effect if Replication Agent has not been initialized.

    Note: To prevent Replication Server from requesting a log starting point that occurs earlier in the log than the location established by the move_truncpt option, Replication Server's LTM locator value for the primary connection must be zeroed. Execute Replication Server System Database (RSSD) command rs_zeroltm against the primary database connection to zero the LTM locator.

    If you move the secondary truncation point to the end of the primary database transaction log using pdb_xlog move_truncpt, you risk skipping over any DDL commands record in the log. The DDL commands might have been used by Replication Agent to update information stored within the Replication Agent System Database (RASD). If the RASD contents are incorrect due to skipping processing of some log records, you may force all of the schema information in the RASD to be refreshed using command pdb_xlog init, force. If only the schema for a single object stored in the RASD is of concern, you can unmark and remark just that single object, which forces the schema of the object to be reread into the RASD.

  • When you invoke pdb_xlog 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, and then re-run the pdb_xlog 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 pdb_xlog 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), pdb_xlog returns an error message.

  • When you invoke pdb_xlog with the remove keyword, Replication Agent:
    • For UDB, pdb_xlog remove uninstalls the JAR files from the primary database (the JARs are installed by the pdb_xlog init command). You must use pdb_xlog remove 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 Replication Agent 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 pdb_xlog remove 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 pdb_xlog with the remove 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 pdb_xlog with the remove 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), pdb_xlog returns an error message.

  • If you invoke pdb_xlog with the remove keyword and any objects in the primary database are still marked for replication, pdb_xlog 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 pdb_xlog with the remove keyword followed by the force keyword to unmark any marked objects, and then remove the transaction log objects.

  • If you invoke pdb_xlog with no option, the command is valid when the Replication Agent instance is in the Admin, Replicating, or Replication Down states.

  • If you invoke pdb_xlog with either the init or remove keyword, the command is valid only when the Replication Agent instance is in the Admin or Replication Down state.

  • The pdb_xlog 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 pdb_xlog init, a warning message is returned and logged in the Replication Agent log file.

  • 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.

Related reference
pdb_setrepcol
pdb_setrepproc
pdb_setreptable
ra_admin
ra_locator