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

NonStop SQL/MP or NonStop SQL/MX Databases
For NonStop SQL/MP or NonStop SQL/MX databases, changes you need to perform manually
on the backup system include:
• Catalog changes
• Results of DDL operations, including creating or altering tables and views
• Partition key changes
• Table purges
Catalog Changes
RDF regards NonStop SQL/MP and NonStop SQL/MX DDL operations like updates to SQL catalogs.
Although SQL catalogs are audited tables, RDF does not replicate catalog changes. The reason
for this is that catalog data has embedded data that contains system name and number information
as well as volume and subvolume information. When an operation on the primary system also
involves changing a catalog there, RDF cannot replicate that audited operation because it would
require that RDF transform the internal information within the data of the audit records, replacing
the system name and number information as well as perform volume mapping if required. The RDF
product does not perform data transformations, and therefore RDF does not create catalogs or
replicate catalog changes.
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 can be performed while your applications are running and they are closely
integrated with RDF operations. 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 when it reaches that record and logs RDF event 733 to inform you that it is stopping due to
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
Making Changes to Database Structures 151