RDF System Management Manual for J-series and H-series RVUs (RDF 1.10)

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 again checks
RDF and NonStop SQL DDL Operations 143