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

The following guidelines apply to creating catalogs:
• If a catalog exists on a volume protected by RDF, this catalog should also be present on the
corresponding volume on the backup system.
• To avoid errors, create a catalog on the backup system before creating it on the primary
system. If audit data is generated for a primary catalog before the corresponding backup
catalog exists, every audit record for the catalog causes a file open error.
Updater processes check for catalog tables, which have a file code in the range 550 through 590
and 859 (ODBC catalogs). An updater does not apply any changes to a table that has a catalog
file code.
An update operation to a table that does not exist causes RDF to log an RDF error message 736,
citing file-system error 11, and the updater retries until the file is created by the user.
DDL Operations
Every NonStop SQL/MP or NonStop SQL/MX DDL operation performed on the primary system
must also be performed on the backup system by NonStop SQL/MP or NonStop SQL/MX if any
of the tables or catalogs reside on volumes protected by RDF.
Because RDF does not replicate DDL operations for SQL objects, you must perform those changes
yourself on the backup system. When it is safe for you to perform those changes on the backup
system without losing synchronization depends on how you performed the original operation on
the primary system. With the NonStop SQL products, you have two ways to perform DDL changes
- With Shared Access and without Shared Access - and the method you choose affects how you
manage the operation on the backup system.
With Shared Access
These operations, which are closely integrated with RDF operations, can be performed while your
applications are running. Specifically, when you commit the DDL operation, a special audit record
is generated. This record is sent by the extractor to the backup system, and each updater stops or
suspends (based on the value of the UPDATERNSASUSPEND attribute) when it reaches that record
and logs RDF event 733, if it is stopping or RDF event 932, if it is suspending because of Shared
Access DDL operation. The purger monitors the stopping updaters and examines the details of
each updater's stop. If all updaters reached the record and stopped accordingly, the purger then
logs the RDF event 908. At this point, it is now safe for you to replicate the DDL change manually
on the backup system. If the purger detects that some updaters had stopped prematurely (for
example, double CPU failure), then it logs RDF event 905 that warns you that you need to restart
updating. When restarted, the only updaters that do any work are those that terminated prematurely
last time. When they reach the special record, they stop and the purger then logs the event 908.
See the section “RDF and NonStop SQL DDL Operations” (page 140) for further discussion.
Without Shared Access
For all operations that do not include With Shared Access, you must stop your applications on
your primary system first because these operations are only allowed when all tables are closed.
To coordinate such DDL operations in an RDF environment, you must stop your applications and
then stop RDF when you are certain the updaters have applied all audit up to the point when you
stopped your applications. There are two safe ways to do this: stop TMF momentarily after stopping
your applications, or execute the STOP RDF, DRAIN command when you are certain your
applications have all stopped. With the Stop TMF method, RDF will shut down when it has reached
the stop-TMF audit record, thereby guaranteeing that all audit has been applied to the backup
database up to the stop point. With the DRAIN method, RDF shuts down when the updaters have
processed all audit up to the point where you issued the STOP RDF, DRAIN command, which must
be issued after you stopped your applications. If no updaters stopped prematurely, the purger logs
RDF event 852, and it now safe for you to perform the same DDL change on the primary and
backup systems before restarting RDF and your applications.
Making Changes to Database Structures 151