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

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

Reading the Backup Database (BROWSE versus STABLE Access)
Unlike databases protected by TMF, backup databases for RDF protection have no locks on rows
or records, even while these rows or records are being updated. Therefore, applications can read
the backup databases at any time; the data can, however, be inconsistent because reading and
updating can occur simultaneously.
Except immediately after a takeover operation, after the updaters have stopped as the result of
a STOP TMF command, or after the updaters have stopped as the result of a STOP UPDATE,
TIMESTAMP command (discussed further below), you only have the equivalent of BROWSE
ACCESS to the backup database. BROWSE ACCESS, a NonStop SQL/MP access option for
transaction consistency, provides immediate access to the data; however, the data can be
inconsistent because a transaction might not be completely applied to the backup database when
the query is in progress. This access provides the lowest consistency but the highest concurrency.
Immediately after a takeover operation or after the updaters have stopped as the result of a STOP
TMF or STOP UPDATE, TIMESTAMP command, you have the equivalent of STABLE ACCESS
to the backup database; at those points, the backup database is consistent with regard to all
transactions whose outcomes (commit or abort) are known at the backup system.
The following example shows the kind of data inconsistency that can occur if the backup database
is read while the database is being updated:
Suppose that a file named FILEA resides on $VOL1 on the primary system and that a file named
FILEB resides on $VOL2 on this primary system. Suppose transaction number 50 causes changes
to both FILEA and FILEB on the primary system.
Now suppose that the updater for $VOL1 has processed transaction 50, but the updater for
$VOL2 has not.
If the backup database is read at this point, the database reflects the incomplete updating for
transaction 50.
To read the backup database while RDF is running, your application should open the backup
files with SHARED READ-ONLY access.
Near Real Time Read Access to Updates on the Primary System
The receiver configuration option FASTUPDATEMODE (formerly known as SLOWMODE)
controls the frequency with which the receiver writes to the image trails and makes image trail
audit available to the updaters. With FASTUPDATEMODE OFF, the default value, the receiver
buffers the audit sent by the extractor and writes those buffers out to the image trails at the most
convenient time. This ensures that RDF can achieve the highest possible extractor-to-receiver
throughput, but it does delay the updaters in how quickly they are allowed to read and apply
the audit to the backup database. One can typically observe updater RTD times cycle from 1-20
seconds, although it may only take an updater a fraction of one second to apply 20 seconds worth
audit.
With FASTUPDATEMODE ON, as each receiver receives an extractor message, it buffers all the
audit sent in that message by the extractor, writes those buffers immediately to the image trails,
and then immediately makes that data available to the updaters. Depending on the value of the
UPDATERDELAY attribute in the global RDF configuration record, the updaters can then read
the image trails and apply the freshly written audit to the backup database immediately, thereby
keeping updater RTD times to the lowest possible value. Because the receiver writes the audit
immediately to the image trails after processing each extractor message, having
FASTUPDATEMODE set ON can also impact extractor-to-receiver throughput.
For a complete discussion of FASTUPDATEMODE, see the description for this attribute under
the SET RECEIVER command in
Chapter 8 “Entering RDFCOM Commands” . While having
FASTUPDATEMODE turned on does give you read access to data freshly committed on the
primary system as soon as possible, please note that the option still only provides you with
BROWSE access.
Reading the Backup Database (BROWSE versus STABLE Access) 149