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

Teradata RDBMS Database Administration - NCR

NCR Teradata RDBMS Database Administration - NCR , 2004. - 616 p.
Download (direct link): teradatadatabaseadmin2004.pdf
Previous << 1 .. 103 104 105 106 107 108 < 109 > 110 111 112 113 114 115 .. 218 >> Next


Data protection options include:

Fallback copies of primary data rows

PJ of before-image and/ or after-image primary data rows

Guidelines and advantages/disadvantages

For more information on data protection options, see Teradata RDBMS Performance Optimization.

Note: To display the links between journal tables and the data tables that write to them, use the DBC.Journals view. The restricted version of this view displays only those tables that the requesting user owns or has privileges on.

Teradata RDBMS Database Administration

7 - 15 Chapter 7: Protecting Data

Transient Journal (Tj) and DBC Space

Transient Journal (TJ) and DBC Space

The rows in TJ enable Teradata RDBMS to roll back any changes made to the database by a transaction that is aborted or fails to meet a condition. The full benefits of the TJ include:

Always in effect

Protects your data against transaction failures or aborts

Inserts a new row each time a user submits a statement that changes the information in an existing table.

Captures information about changes to the data rows and on the AMP. The TJ maintains:

Snapshots of rows in tables before a change is made (before image)

Row IDs of rows in tables after an insert is made (after-image notation)

Control records for dropped and created tables

BEGIN and END TRANSACTION images

The TJ is always in effect and is always maintained by the AMPs as follows:

Each AMP maintains its own TJ rows.

Change information is under the control of the same AMP as the data row.

An AMP background task periodically deletes TJ rows as soon as a transaction is either backed out or committed.

If a DML statement is part of a multi-statement transaction, the AMP does not delete the TJ blocks until one of the following is true:

Every statement making up that transaction is committed.

Rollback is complete for all processing performed when the transaction was active.

Determining Maximum TJ Size

It is vitally important that DBC always has enough space to hold all the change rows generated by the total number of applications that run simultaneously during peak workload hours. As the administrator, you need to know that:

The transient journal is maintained as a system table in database DBC.

DBC PERM space is used to dynamically allocate space to the TJ.

TJ data blocks are allocated as bytes of JournalDBSize. (Rows can be added to a TJ data block without a sector allocation. For details, see "DBS Control Utility" in Teradata RDBMS Utilities and "JournalDBSize" in Teradata RDBMS Performance Optimization).

If processing causes CurrentPerm of DBC to be exceeded, the transaction causing the overflow is not aborted due to lack of space. Thus, you have no way of knowing when TJ space is exhausted.

7 - 30

Teradata RDBMS Database Administration Chapter 7: Protecting Data

Transient Journal (TJ) and DBC Space

It is a good idea to determine how many rows the TJ will need to store during peak workload hours when the most jobs running simultaneously will be changing data). TJ entries and the statements that generate them are as follows:

Control records for CREATE and DROP

Before-image rows for UPDATE and DELETE

Row IDs for INSERT

BEGIN/END TRANSACTION images

Note: Only UPDATE and DELETE cause a full row to be inserted into the TJ.

Use your estimate to determine whether DBC has enough CurrentPerm to support a maximum-sized TJ.

If it does not, the only short-term solution is to free up space. (For instructions, see "Permanent Space Availability" on page 3-3.) If you often need to do this, you might want to consider expansion.

Teradata RDBMS Database Administration

7 - 31 Chapter 7: Protecting Data

AMP Clustering and Fallback

AMP Clustering and Fallback

Fallback protection is an optional data protection feature accomplished by grouping AMPs into clusters. Within a cluster, a fallback copy of each data row is distributed to a different AMP from the one containing the primary row.

If the primary AMP fails, the system can still access data on the fallback AMP. This ensures that one copy of a row is available if one or more hardware or software failures occur within one rank, an entire array, or an entire node.

The following figure illustrates eight AMPs grouped into two clusters of four AMPs each. In this configuration, if AMP 3 (or its vdisk) fails and stays off-line, its data remains available on AMPs 1, 2, and 4. Even if AMPs 3 and 5 fail simultaneously and remain off-line, the data for each remains available on the other AMPs in its cluster.

DSU/AMP 1

Primary Copy Area Fallback Copy Area

1, 9, 17

2, 3, 4

DSU/AMP 5

Primary Copy Area Fallback Copy Area

5, 13, 21

6, 7, 8

Cluster A

DSU/AMP 2 DSU/AMP 3

2, 10, 18 1, 11, 12

3, 11, 19 9, 10, 20

Cluster B

DSU/AMP 6 DSU/AMP 7

6, 14, 22 5, 15, 16

7, 15, 23 13, 14, 24
Previous << 1 .. 103 104 105 106 107 108 < 109 > 110 111 112 113 114 115 .. 218 >> Next