NonStop SQL DDL Replicator User's Guide (Update 7)

Configuring SDR
HP NonStop SQL DDL Replicator User’s Guide—545799-007
3-4
Configuring SDR Capture
By default, SDR allows the DDL operation to be performed on the primary table, even if
it cannot be captured for replication. But you can choose to make the DDL replication
mandatory by not allowing the DDL operation to succeed on the primary table if it
cannot be captured by SDR. This is done by setting the global parameter
DDLCAPTURE to REQUIRED (instead of the default ENABLED).
Obviously, mandatory DDL replication could have an adverse affect on applications
that perform DDL. But, if all DDL is performed using ad hoc SQLCI commands, it is a
useful safeguard against accidental corruption of the backup database.
Retaining Captured DDL
At the time you perform either primary database updates or DDL operations, you might
not have configured RDF yet, or even have a backup database. You can decide,
weeks after an application has started updating a database on the primary system, to
initialize RDF and replicate all the updates that were performed in past weeks to a
backup database. All you need to do is save the TMF audit trails.
Similarly, SDR captures and preserves the DDL being executed on a primary table,
with no knowledge of RDF. Indeed, DDL capture is completely independent of DDL
replication. This is very similar to the use of TMF that is independent of RDF.
The de-coupling of DDL capture from replication is why the DDL retention period is
important. It can be set to any value between 1 day and 60 days. The default is one
week. Set retention higher if you plan to initialize RDF to a date that goes back in time
more than one week. To change the default retention period, set the global parameter
RETENTION to the desired value.
Handling DDL Operations performed under a User
Transactions
Certain types of DDL operations can be done in a user-initiated transaction. For
example, you can DROP and CREATE a table as a single transaction; if the
transaction fails, the original table is still available. User transactions containing DDL
operations are rare, but they are allowed.
User transactions complicate the DDL replication. At the time SDR replicates the DDL,
the outcome of the user transaction is not known.
Note. SDR allows one extra day past the configured retention period when deleting old
records from SDRDEPOT files on the backup system. In the normal case, old records are
deleted on the primary system and those deletes are quickly replicated by RDF to the backup
system. The delay prevents the backup system from deleting old records before the primary
system has a chance to do so.If the backup SDR deletes records before the primary SDR,
RDF issues EMS message 700, error 11 on the SDRDEPOT file. This has no ill effect but is an
additional distraction for the operator.