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

(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 142) 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.
Adding a New Column
This is an operation that cannot be performed With Shared Access. To minimize application
downtime, you can coordinate the operation as follows. Stop the RDF updaters with a simple STOP
UPDATE command. When the updaters have stopped, add the column to your backup database
and then restart update. Note, at this point, the new column is in the backup database but not yet
on the primary. When the updaters update subsequent rows with the new column, the disk process
adds the default value to the new column. Next, you perform a switchover operation (detailed in
Chapter 5), start RDF on your backup system with update off, and then start your applications on
your backup system. Add the column to the database on your former primary system (it is now the
backup of your new RDF environment), and then START UPDATE. When RDF has caught up and
at your convenience, perform a new switchover operation to move your application processing
back to your primary system.
Guidelines for Create Index and Alter Table Move Operations
The following guidelines apply to NonStop SQL/MP and NonStop SQL/MX DDL operations:
• Creating an index or loading data into an added table partition does not interfere with RDF
protection. Although a CREATE INDEX or ALTER TABLE MOVE FROM FIRST KEY UP TO KEY
operation seems to create an audited index or partition within a transaction, only the updates
to the catalog and file labels are audited. The index or partition is created nonaudited, and
audit is not turned on until after the operation is complete. Performing either of these DDL
operations on the backup system for a corresponding DDL operation on the primary system
does not cause problems because the operation on the primary system proceeds internally:
1. Create a nonaudited table (index or partition).
2. Move the data without logging by TMF.
3. Issue an ALTER TABLE table-name AUDIT statement for the table.
It is safe to perform these operations just like other DDL operations on the primary system.
Example for CREATE INDEX With Shared Access
This example shows the SQLCI/MXCI commands for adding an index to a table and the order of
the operations:
1. Specify the default catalog for the primary system.
152 Maintaining the Databases