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

CREATE, PURGE (if REPLICATEPURGE is enabled), PURGEDATA, ALTER MAXEXTENTS (used
only for increasing MAXEXTENTS).
• For NonStop SQL files only, performs the following DDL operation: PURGEDATA
An updater cannot always respond immediately to the STOP UPDATE and STOP RDF commands.
If an updater has audit records queued for the disk process, the updater must wait until all of that
information is processed before it can shut down.
You specify the primary and backup CPUs for each updater. If the original backup process has to
take over because the primary CPU failed, this backup process runs by itself. When it determines
that the primary CPU has come back up, it creates a new backup process in that CPU. When it
has to take over, the original backup process becomes the primary process, and remains so even
after it creates a new backup process; that is, the updater does not switch back to the original
CPU configuration after the new backup process is created. If you stop the updaters by way of a
STOP RDF or STOP UPDATE command, however, when you restart the updaters, your original
configuration is once again used.
The updaters will shut down if any of the following occurs:
• You issue a STOP RDF or STOP UPDATE command on the primary system.
• You issue a STOP RDF command on the backup system when the communications lines between
the two systems are down.
• You issue a STOP TMF command on the primary system.
• The monitor detects the unexpected termination of any RDF process and sends out abort RDF
messages.
• You perform a NonStop SQL DDL operation on the primary system that includes the WITH
SHARED ACCESS option for an RDF-protected file. For more information, see “Performing
Shared Access DDL Operations” (page 141).
If you perform a NonStop DDL operation WITH SHARED ACCESS on a table or index that is
not configured for RDF protection by your current RDF subsystem, then this current RDF subsystem
does not shut down.
• A takeover operation completes on the RDF backup system.
Audited Database Files
All database files on the backup system are audited files.
Each updater maintains a file status table to keep track of the files it has open. An updater closes
any database file that has not been updated recently. Updaters also close database files when a
STOP RDF or STOP UPDATE command is issued, or when the updater restarts because of error
conditions. Additionally, if you alter the updater's OPENMODE while UPDATE is ON, then the
updater closes all its file and then reopens them with the new OPENMODE.
The UPDATERFOPENTHRESHOLD attribute enables you to set a threshold limit, using the SET RDF
or ALTER RDF command, on the number of files that can be opened by an RDF Updater process,
when RDF is not running. The default value for this attribute is 2400. When the Updater exceeds
the threshold value of the number of files open and needs to open a new file, it returns the EMS
event 933 and continues normal processing. This EMS event has no effect on the Updater processing
or on performance. When event 933 is generated, you must stop RDF immediately and rebalance
the number of audited files on the primary and backup volume of the affected Updater, so that
you have no more than the specified threshold number of audit files on that volume. Irrespective
of the UPDATERFOPENTHRESHOLD value, an Updater process can have up to 3000 files open
simultaneously. When RDF Updater process has the maximum number of files open and needs to
open another file, it first determines if any files have not been accessed recently and closes just
them. If all of the open files have been accessed recently, then the updater closes all the files before
38 Introducing RDF