in black and white
Main menu
Share a book About us Home
Biology Business Chemistry Computers Culture Economics Fiction Games Guide History Management Mathematical Medicine Mental Fitnes Physics Psychology Scince Sport Technics

Teradata RDBMS Database Administration - NCR

NCR Teradata RDBMS Database Administration - NCR , 2004. - 616 p.
Download (direct link): teradatadatabaseadmin2004.pdf
Previous << 1 .. 93 94 95 96 97 98 < 99 > 100 101 102 103 104 105 .. 218 >> Next

1 Query the DBC.AccLogRules view to display the list of BEGIN LOGGING statements currently in effect: select * from dbc.acclogrules;
2 Submit an END LOGGING statement for each BEING LOGGING statement in the list. Note: To stop log activity completely, you need to issue one END LOGGING statement for every rule displayed (and then complete this procedure).
3 Issue a DROP MACRO for DBC.AccLogRule macro.
4 Do a TPA reset to set the change.

Caution: If you do not issue END LOGGING statements for every rule currently shown by the DBC.AccLogRules view, access logging will continue even after you have dropped the DBC.AccLogRule macro and reset the database.

Use the following system views to find information about the entries in DBC.AccLogRuleTbl and DBC.AccLogTbl:

This system view . Contains . Based on the underlying .
DBC.AccLogRules current rules generated by BEGIN LOGGING statements. These entries determine what access checks should be performed. DBC.AcctLogRuleTbl
DBC.AccessLog log entries (if DBC.AccLogRule macro exists) generated as a result of applying the rules. Each entry indicates a privilege check performed against a Teradata SQL request, based on the criteria defined by a BEGIN LOGGING statement. DBC.AcctLogTbl Note: To control space consumption, empty this table regularly using the DBC.DeleteAccessLog view.

6 - 46

Teradata RDBMS Database Administration 6 - 45 Chapter 7:

Protecting Data

This chapter discusses how to take advantage of the wide variety of automatic and optional data protections features provided by Teradata RDBMS. The following topics are discussed:

Automatic data protection for both hardware and software

Using referential integrity, batch referential integrity, and Referential Constraints

Transaction data protection

2-Phase Commit (2PC) protocol

Crashdumps and FALLBACK protection

Teradata RDBMS Database Administration

7 - 1 Chapter 7: Protecting Data

Automatic Data Protection Mechanisms

Automatic Data Protection Mechanisms

The Teradata system offers a variety of methods to protect data. Some methods are automatically activated when particular events occur in the system. Other data protection methods require that you set options when you create tables. Each data protection technique offers different types of advantages under different circumstances.

The Transient Journal (TJ) automatically protects data by storing the image of an existing row before a change is made, or the ID of a new row after an insert is made. It enables the snapshot to be copied back to, or a new row to be deleted from, the data table if a transaction fails or is aborted. (For details, see "Transient Journal (TJ) and DBC Space" on page 7-30.)

Fallback protection is an optional data protection feature that creates a copy of each row on another AMP in the same cluster. (For details, see "AMP Clustering and Fallback" on page 7-32).

The Down AMP Recovery Journal supports fallback protection and automatically recovers data when an AMP is out of service or fails.

Redundant array and independent disks (RAID) technology provides different types of data protection. They include:

RAID 0: No RAID protection.

RAID 1: Pairs of disk drives contain mirrored data. For critical fault-tolerant transaction processing.

RAID 5: Reconstructs missing data. Requires less disk space than RAID 1, but reconstructing data takes longer than using RAID 1 and switching to a mirrored disk.

RAID S: Used in EMC.

Transient Journal (TJ)

The TJ protects against failures that may occur during transaction processing. To safeguard the integrity of your data, the TJ stores:

A snapshot of a row before an UPDATE or DELETE is made

The row ID after an INSERT is made

A control record for each CREATE and DROP statement

If a transaction is aborted or fails, the TJ enables the database to be restored to the state it was in before the transaction began. Its contents are used to:

Copy snapshot rows back into their tables

Remove inserted rows

Delete partially created objects, or rebuild and, if necessary, repopulate dropped objects

7 - 2

Teradata RDBMS Database Administration Chapter 7: Protecting Data

Automatic Data Protection Mechanisms

Fallback Protection

FALLBACK is an optional data protection feature that you define with the CREATE/MODIFY USER/DATABASE and CREATE/ALTER TABLE commands. Fallback-protected tables occupy twice the permanent space in your system as non-fallback tables, but the advantages in continued operation and data integrity may be well worth the space.

Fallback provides data protection at the table level by automatically creating a copy of each permanent data row on a fallback AMP. If a disk fails, Teradata can access the fallback copy and continue operation. If you cluster your AMPs, fallback also provides for automatic recovery of the down AMP once you bring it back online.

For details on how recovery with fallback is accomplished, see "Down AMP Recovery Journal" on page 7-4. For details of how to set up your configuration to achieve even more protection, see "Clustering AMPs" in the following section and "AMP Clustering and Fallback" on page 7-32.
Previous << 1 .. 93 94 95 96 97 98 < 99 > 100 101 102 103 104 105 .. 218 >> Next