Availability Guide for Application Design

Designing Applications for Change
Availability Guide for Application Design—525637-004
10-29
Physically Reconfiguring the Database
Without the HP Implementation
Without the HP implementation, a database can become unavailable for an
unacceptable period of time while physical database reconfiguration takes place. When
moving a partition, for example, you typically need to stop accessing the partition
before the move starts, and not start accessing it again until the move is finished.
The reasons why you cannot access the partition data while it is being moved are
twofold:
•
You cannot have transactions in progress when the move starts because you might
move dirty data to the new disk. That is, you might copy data blocks touched by
current transactions that subsequently would be aborted and backed out from the
source partition, leaving invalid data on the target disk.
•
Write operations to the part of the source partition that has already been copied do
not get copied to the target partition.
Traditionally, to perform this kind of reconfiguration, you must either commit or abort all
transactions against the source partition, take the partition offline, copy it to the new
partition, and recompile the application to access the new partition instead of the old.
With HP’s Implementation
With HP’s implementation, the time for which the database is unavailable due to
physical reconfiguration is short. Again consider the move partition operation:
1. The application continues to make read and write requests against the source
partition while the partition is copied to the new target disk. Once this phase is
finished, the source partition is still active and contains accurate data, while the
target partition contains dirty data.
2. NonStop SQL/MP invokes the transaction manager, TMF, to clean up the target
partition. It does this using the record of activity in the source partition kept in the
audit trail. Meanwhile, the application continues to make read and write requests to
the source partition; the target partition is still not synchronized with the source.
However, because this audit-trail scan is much quicker than the copy phase, the
contents of the two partitions are much closer to each other than they were after
the copy phase.
3. A second scan of the audit trail takes place while the source partition is locked.
After this phase, the source and target partitions are synchronized. This phase is
known as the commit phase. This phase is the only time that the database is offline
to the application.
The time required depends on the number and length of transactions accessing
the affected partition. To keep this time to a minimum, you should perform such
Note. Opens are invalidated during this phase causing all concurrent DML operations to
fail. You must either resolve names at execution time or use some form of recompilation
for the application to continue running.