Owner manual

SDR Operations
HP NonStop SQL DDL Replicator Users Guide545799-005
4-4
DDL Capture Operation
$DATA.ZASDR004.AA000123. Marker files are managed automatically by SDR. They
occupy no disk space. SDR purges marker files when they are no longer needed.
DDL Capture Operation
You can perform DDL operations in an application program, in SQLCI, or in other
subsystems such as ODBC or DBA/m. In any of these cases, SDR is informed at
various points of the DDL processing and performs some additional operations as
described in this chapter.
DDL capture is completely independent of the RDF configuration. In the general case,
RDF need not be configured when the primary DDL operation occurs.
When a DDL operation occurs, SQL performs numerous catalog updates and file label
operations. It usually performs these as a single TMF transaction. During the DDL
processing, SDR captures the operation, including environmental information such as
DEFINEs and default subvolumes.
SQL eventually commits or aborts the transaction used to perform the DDL change. If
the transaction commits, SDR writes a description of the DDL to a depot file, which is
replicated by RDF to the RDF backup system(s). SDR also creates the marker file to
prevent the RDF Extractor from aborting.
Later, when RDF is replicating the catalog audit for the DDL, it will replicate the SDR
depot records and then encounter the SRU audit record and shut down the RDF
updaters. SDR processing from this point is described below.
Special cases
Create Catalog
User Transactions
Distributed Tables and Indexes
Unaudited Tables and Indexes
SQLCI DUP Utility
Create Catalog
In the DDL operation to create a catalog, SQL first creates all the audited catalog
tables, opens them, and inserts the initial catalog rows into the tables. This is all done
under a single transaction.
In the typical case, this causes RDF to stall if the catalog is not yet created on the
backup system. When the RDF updater processes the audited catalog inserts, it does
WARNING. Purging Marker files manually can cause RDF to abort with no possibility of
restart. You would need to reinitialize RDF to an audit location after the SRU record that
references the marker file, and likely lose database audit that keeps the backup database
synchronized.