HP NonStop RDF, Руководство по управлению

Страница: 160 / 478

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 (for example, double CPU failure), then it logs RDF event 905 that warns you that
160 Maintaining the Databases