Performing Nonshared Access Ddl Operations; Performing Shared Access Ddl Operations - HP NonStop RDF J-series RVUs Management Manual

The only operations that must be performed WITH SHARED ACCESS are merge partitions and
move boundaries. It is recommended that you perform all other operations with nonshared
access.
NOTE: When you make DDL changes to your primary database, you can use the NonStop SQL
DDL Replicator product to replicate NonStop SQL/MP DDL changes to your backup database
automatically, instead of you having to perform those changes manually on the backup system.
Please note that the NonStop SQL DDL Replicator product does not replicate NonStop SQL/MX
changes.

Performing Nonshared Access DDL Operations

For DDL operations that do not include the WITH SHARED ACCESS option, you can minimize
outage for the primary system applications:
1. Stop the applications that use the database being protected by RDF.
2. Stop TMF on the primary system.
3. Wait for RDF to stop.
4. Start TMF.
5. Start RDF with updating disabled.
6. Perform the DDL operations on the primary system.
7. Restart the applications.
8. Perform the same DDL operations on the backup system.
9. Issue an RDFCOM START UPDATE command.
Database administrators with a clear understanding of the underlying TMF auditing issues might
elect to skip some of these steps as long as the DDL operations and other audited operations are
performed in the correct sequence on the primary and backup systems. For example, it is not
absolutely necessary to stop TMF (and thus RDF), but it is safest to do so. As long as application
processing is stopped and the display from a STATUS RDF command shows that the RTD time
for every updater process is zero, the DDL operations can be safely applied.

Performing Shared Access DDL Operations

DDL operations that include the WITH SHARED ACCESS option and are performed on the
primary system generate a special Stop-RDF-Updater audit record in the MAT. As each updater
on the backup system encounters that record in its image trail file, that updater logs either an
RDF Event 733 or 931 and then shuts down. When all of the updaters have done so, RDF logs a
Event 908 indicating that it is now safe to perform the same DDL operation on the backup system.
When you have performed the same DDL operation on the backup system, you can then issue
the RDFCOM START UPDATE command.
If RDF aborts while the updaters are in the process of shutting down, check the RDF log to see
if RDF generated event 908. If it did, then:
1. Issue a START RDF, UPDATE OFF command on the primary system.
2. Perform the DDL operation(s) on the backup system.
3. Issue a START UPDATE command on the primary system.
Whether or not RDF aborted while the updaters were shutting down, if one or more updaters
did not generate event 733, the purger process logs RDF event 905 indicating that you must not
perform the DDL operation on the backup system. If that happens, issue either a START RDF
command (if RDF was aborted) or a START UPDATE command (if the non updater processes
are still running). When you do this, only those updaters that did not log the RDF event 733 are
started. When they reach the Stop-RDF-Updater record, they shut down, and the purger once
152 Critical Operations, Special Situations, and Error Conditions