Teradata ARC Locks During an Archive Operation - TARA/ABU

Teradata Archive/Recovery Utility Reference
Product
TARA/ABU
Release Number
15.00
Language
English (United States)
Last Update
2018-09-25
dita:id
B035-2412
lifecycle
previous
Product Category
Teradata Tools and Utilities

Teradata ARC Locks During an Archive Operation

A Teradata ARC operation locks objects that are being archived. To see where Teradata ARC places read utility locks during an archive, refer to Table 8.

 

Table 8: Read Locks During Archive

Object Being Archived

Action by Teradata Archive/Recovery Utility

Entire database

Places the read utility lock at the database level before it archives any tables

Individual table

Places the read utility lock on each table before it archives that table

If the RELEASE LOCK option is specified on the ARCHIVE statement, Teradata ARC releases the read utility lock when it successfully completes the archive of a database or table. Therefore, only a full database archive creates consistency among tables archived from the same database.

Group Read Lock

A group read HUT lock can be specified for tables that are defined with an after-image journal option. If the GROUP READ LOCK option is used to perform an online backup of a database-level object, define after-journaling for every table in the database. This restriction also applies to excluded tables; if a table is excluded as part of a database-level GROUP READ LOCK archive, it must still have an after-journal table defined so ARC can accept the GROUP READ LOCK option.

When a group read HUT lock is specified, the following events occur:

  • The AMPs first place an access HUT lock on the entire affected table to prevent users from changing the definition of the table (that is, DDL changes) while the table is being archived.
  • The AMPs then place a series of rolling read HUT locks on blocks of (approximately) 64,000 bytes of table data. Each AMP places a read HUT lock on a block of data while the AMP sends the data block across the IFP or PE to the client.

    • When a block transmission finishes, the AMP releases the read HUT lock on that block and places another read HUT lock on the next block of 64,000 bytes. The AMPs repeat this process until they archive the entire table.

    Concurrent Transactions: Archives and Updates

    When an archive with a group read HUT lock is finished, the archive may contain partial results of a concurrently executing update transaction. Consider the following example:

    1 The archive operation reads row 1 and sends it to the client.

    2 Transaction A reads and updates row 3.

    3 The archive operation reads row 2 and sends it to the client.

    4 Transaction A reads and updates row 1.

    5 Transaction A ends, releasing its HUT lock on rows 1 and 3.

    6 The archive operation reads row 3 and sends it to the client.

    The archive described above contains:

  • A copy of row 3 after an update by transaction A, and
  • A copy of row 1 before its update by the transaction.

    • For this reason, define an after-image permanent journal for tables to be archived using a group read HUT lock. After the archive finishes, archive the corresponding journal. The after-images on the journal archive provide a consistent view of any transaction that executes concurrently with the archive.

    Archiving Using a GROUP READ LOCK

    Archiving a table with a group read HUT lock at the same time users are updating it is allowed.

    Tables archived with the group read HUT lock option do not archive with secondary indexes. However, the secondary indexes can be rebuilt after that table is restored.

    Restoring a Group Read Lock Archive

    To restore tables that are archived under a group read HUT lock, define them with an after-image journal. Always follow the restore of an archived data set taken under a group read HUT lock by performing a rollforward operation, using the after-image journal that was created during the archive. Rollforward ensures that the data in the tables is consistent. To learn more about the rollforward operation, see “ROLLFORWARD” on page 246.

    An archive taken under a group read HUT lock does not archive secondary indexes defined for the tables being archived. Therefore, rebuilding the indexes after restoring the archive is required. If the NO BUILD option is not specified for the restore, Teradata ARC builds nonunique secondary indexes as part of the restore process. Teradata ARC does not rebuild unique secondary indexes. To learn more about the NO BUILD option, see “NO BUILD Option” on page 66.

    The Teradata ARC restore process marks all existing unique secondary indexes as invalid for the table being restored. Rebuild or drop all secondary indexes by doing one of the following:

  • Issue a BUILD DATA TABLES statement.
  • Drop and recreate the index.

    • Rebuild unique secondary indexes only after the rollforward of the data tables is complete.

    Restoring a GROUP READ LOCK Archive of Selected Partitions

    When specifying the GROUP READ LOCK option for an archive of selected partitions, use the next procedure to perform the restore. Ensure that the structure version of the tables being restored match the structure version of the tables stored on the backup file.

    1 Restore or copy the selected partitions to the target table using the NO BUILD option.

    2 Restore or copy journal tables of the journal backup associated with the time period of interest.

    3 Roll forward the restored tables using the USE RESTORED JOURNAL and PRIMARY DATA options.

    4 Submit a BUILD DATA TABLES statement to complete the build of the restored tables.

    During this procedure, an “out-of-range” error condition can occur if the selected partitions for the restore are inconsistent with the change rows being rolled forward (that is, the journal contains rows outside of the selected partitions for the restore). ROLL processing continues on the indicated table and the out-of-range changes are made to the target table.

    Notice:

    This procedure corrects the structural validity of the table. However, it does not reveal the nature of the updates applied by the ROLL operation that fall outside of the selected partitions for the restore. There might be significant partitions that were missed in the restore and that were only partially updated by the out-of-range changes. Audit the entire recovery process to ensure that no data is missing. If missing data is suspected, repeat the above procedure for the affected partitions.