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

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 are performed on the primary
system to generate a special Stop-RDF-Updater audit record in the MAT.
UPDATERNSASUSPEND set to OFF - Updaters Shutdown
When each updater on the backup system encounters the Stop-RDF-Updater audit record in the
image trail file, the corresponding updater logs either RDF event 733 or RDF event 931 and
subsequently shuts down. When all of the updaters are completed, RDF logs 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 issue a RDFCOM START UPDATE
command.
If RDF aborts while the updaters are in the process of shutting down, check whether RDF has
generated event 908. If Event 908 is generated, perform the following steps:
1. On the primary system, issue a START RDF, UPDATE OFF command.
2. On the backup system, perform the DDL operations.
3. On the primary system, issue a START UPDATE command.
If RDF is not aborted while the updaters are shutting down, or 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 you receive this message, issue either a START RDF command
(if RDF was aborted) or a START UPDATE command (if the non-updater processes are still running).
After issuing one of the commands, 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 rechecks
to see all the updaters have processed all image audit up to this special record. When the purger
RDF and NonStop SQL DDL Operations 141