Information Technology Reference
In-Depth Information
by quiescing updates by transactions accessing the relation during index construc-
tion:
1. Begin a system transaction T .
2. S-lock relation r for T for commit duration.
3. Scan the tuples in r in primary-key order, extract the index records .y;x;p/,and
write them to a file.
4. Sort the file on the unique key .Y; X /.
5. Build the secondary index from the sorted file of index records, logging all index-
record insertions with redo-undo log records and structure modifications with
redo-only log records.
6. Update the system catalog with information about the new index.
7. Commit T .
With the above solution, the index is created on a transaction-consistent state
of the relation r , because of the commit-duration S lock. A major problem is that
while the index construction is in progress, updates are quiesced : the relation r
is only accessible for reading, while transactions that want to update the relation
must wait for the release of the S lock on r , which only happens at the end of the
index construction, meaning a very long wait in the case of a large relation. Another
problem is related to restartability of a failed index construction: in the event of
a system crash, the entire system transaction T is rolled back, after which index
construction must be restarted from the beginning.
We present a solution with which updates are not quiesced during index
construction: transactions can update the relation while the index construction is in
progress (Fig. 11.2 ). Naturally, transactions may not use the index being constructed
until it is completed. Thus the tuples in the relation must be accessed via access paths
that exist and are declared available in the system catalog.
Fig. 11.2
Online construction of a secondary index
 
Search WWH ::




Custom Search