About Recovering from an Out of Sync Condition

The MDS repository can be out of sync with a Teradata Database system for the following reasons:

One or more of the following systems or services is reset:
- Teradata Database
- Relay Services Gateway (RSG)
- DDL Gateway
An error occurs and an Integrity Server cannot commit a transaction to the repository.
The DDL Gateway goes down and does not come back up right away. In this case the Teradata Database system is processing DDL statements and not forwarding them to MDS, but is writing the database names to the MDS Recovery Table.
The Integrity Servers have a backlog of transactions that have not yet been processed.

When the Automatic DIM Update feature is enabled, the task of keeping track of DDL transactions is divided among the three components: Teradata Database, RSG, and Gateway Server.

Feature	Description
Teradata Database system	When the DDL Gateway is down, the Teradata Database system processes DDL statements, but writes the names of all “Affected” databases to the MDS Recovery Table. There is one MDS Recovery Table for each Teradata Database system. When the Gateway Server comes up, if the Recovery on Startup flag is checked, it reads the MDS Recovery Table and resynchronizes the repository for each database name listed in the table.
RSG	The RSG keeps track of in-progress DDL transactions. These are DDL statements that the Gateway Server has not yet recorded in its log and has not responded to the Teradata Database system to complete the transaction. When the RSG detects that the DDL Gateway has gone down or receives a reset message from the Gateway Server, the RSG aborts the in-progress transactions with the Teradata Database system.
Gateway Server	The Gateway Server keeps track of the database names of all DDL transactions for which it has received messages. It tracks the transaction in a backlog list and in a log file. The log is combined with the MDS Recovery Table to resynchronize the repository. Only databases that are out of sync are resynchronized during recovery. The Gateway Server performs recovery: On startup of the DDL Gateway On startup, the Gateway Server looks in the MDS Recovery Table and in its own log to determine which databases need recovery. If the Teradata Database system is configured in MDS to have the “Recovery On Startup” flag enabled, the Gateway begins recovery for that system. If the flag is not set, recovery is deferred until the scheduled time. When the DDL Gateway receives a “Recover now” message from the MDS Action Processor Scheduled recovery only occurs once per day for each Teradata Database system based on the schedule configured for that system in MDS. The schedule configuration also specifies the days of the week to perform scheduled recovery. When the Gateway Server performs a recovery, it does the following: Sends a message to the Teradata Database to stop sending DDL statements to RSG and to log “Affected” databases in the MDS Recovery Table Reads and deletes entries from MDS Recovery Table, reads the backlog list, and compiles a list of database names to resynchronize Calls the metaload utility to resynchronize each database name Reads and deletes the MDS Recovery Table again to resynchronize databases that might have been affected by DDL statements during the resynchronization process Sends a message to the Teradata Database to start sending DDL statements to RSG

Feature

Description

Teradata Database system

When the DDL Gateway is down, the Teradata Database system processes DDL statements, but writes the names of all “Affected” databases to the MDS Recovery Table. There is one MDS Recovery Table for each Teradata Database system.

When the Gateway Server comes up, if the Recovery on Startup flag is checked, it reads the MDS Recovery Table and resynchronizes the repository for each database name listed in the table.

RSG

The RSG keeps track of in-progress DDL transactions. These are DDL statements that the Gateway Server has not yet recorded in its log and has not responded to the Teradata Database system to complete the transaction. When the RSG detects that the DDL Gateway has gone down or receives a reset message from the Gateway Server, the RSG aborts the in-progress transactions with the Teradata Database system.

Gateway Server

The Gateway Server keeps track of the database names of all DDL transactions for which it has received messages. It tracks the transaction in a backlog list and in a log file. The log is combined with the MDS Recovery Table to resynchronize the repository.

Only databases that are out of sync are resynchronized during recovery.

The Gateway Server performs recovery:

On startup of the DDL Gateway
On startup, the Gateway Server looks in the MDS Recovery Table and in its own log to determine which databases need recovery. If the Teradata Database system is configured in MDS to have the “Recovery On Startup” flag enabled, the Gateway begins recovery for that system. If the flag is not set, recovery is deferred until the scheduled time.
When the DDL Gateway receives a “Recover now” message from the MDS Action Processor
Scheduled recovery only occurs once per day for each Teradata Database system based on the schedule configured for that system in MDS. The schedule configuration also specifies the days of the week to perform scheduled recovery.

When the Gateway Server performs a recovery, it does the following:
1. Sends a message to the Teradata Database to stop sending DDL statements to RSG and to log “Affected” databases in the MDS Recovery Table
2. Reads and deletes entries from MDS Recovery Table, reads the backlog list, and compiles a list of database names to resynchronize
3. Calls the metaload utility to resynchronize each database name
4. Reads and deletes the MDS Recovery Table again to resynchronize databases that might have been affected by DDL statements during the resynchronization process
5. Sends a message to the Teradata Database to start sending DDL statements to RSG

About Recovering from an Out of Sync Condition - Teradata Meta Data Services

Teradata Meta Data Services