Because Teradata Database metadata is a central part of the MDS repository, it is vital to the use of MDS that the information be kept up to date and dynamically reflect any changes in the Teradata active data warehouse. The Automatic DIM Update feature dynamically keeps the MDS repository synchronized with the Teradata Database system it describes.
The following figure shows the processes that support Automatic DIM updates.
| Feature | Description |
|---|---|
| Relay Services Gateway (RSG) | RSG is a Teradata vproc that relays messages between the Teradata Database and the DDL Gateway. Whenever a Teradata Database system processes a DDL statement, it sends the statement to the RSG, which sends it on to the DDL Gateway. The DDL Gateway then updates the metadata in the MDS repository. An example of a DDL is: create table mytable (c1 int); An RSG vproc must be running on every Teradata node of the Teradata Database system. The RSG communicates with the DDL Gateway via TCP/IP. Starting with Teradata Database 14.0, Teradata and the RSG vproc cannot be installed on a Windows system unless the enterprise contains multiple Teradata systems, in which case the older systems can run on Windows.
|
| DDL Gateway | The DDL Gateway consists of one client, one server, and one or more Integrity Server processes that keep the metadata in the MDS repository synchronized with Teradata. MDS can track changes to multiple Teradata systems. The DDL Gateway is also responsible for maintaining the audit trail of the DIM changes for each processed statement. If the Audit Log Flag is set to On, an entry is inserted into the audit trail for each update to the DIM. The DDL Gateway can be installed on an application node of the Teradata Database system or on a separate Windows or Linux machine. Only one instance of the MDS DDL Gateway is allowed. |
| MDS Action Processor | The MDS Action Processor polls the Audit Log for expired entries and purges them. The MDS Action Processor also sends messages to the DDL Gateway to initiate scheduled recovery. The MDS Action Processor runs on Windows or Linux. Only one MDS Action Processor can be run. The Action Poll Rate defined in the MetaManager System-Wide Parameters defines how often the MDS Action Processor rereads the Teradata Database system settings to pick up changes to the Audit Flag, Audit Trail Expiration Days, and DIM Update Recovery Schedule for each Teradata Database system object. The default setting for the Action Poll Rate is 5 minutes. The Action Poll Rate can be increased to a maximum of 1440 minutes (24 hours). The MDS Action Processor polls the Audit Trail every 24 hours at 1:30 a.m. local time to remove expired entries in the Audit Trail. A Recovery Schedule is configured in MDS for each Teradata Database system. The MDS Action Processor monitors the schedule times for each Teradata Database system and sends a message to the Gateway Server when scheduled recovery is to be performed on each system. |
| MDS Recovery Tables | For the Automatic DIM Update feature to be enabled on each Teradata Database system loaded into the MDS repository, an MDS Recovery Table must exist on each of the Teradata Database systems. Teradata Database systems automatically contain an MDS Gateway Recovery Table. The table has a fixed name (mdsrecoverytbl) and location (DBC). |
| Database Connection Information | When you create a Teradata Database system with Automatic DIM Updates enabled, you must use MetaManager to specify a DSN, user name, and password so the DDL Gateway can connect to the system. The Gateway Server process uses these settings to resynchronize a database during recovery and to access the MDS Recovery Table. The Integrity Servers use these settings to connect to the system to get information from the DBC tables. |
| DDL Gateway User Accounts | On Windows, the DDL Gateway uses the Teradata user names specified in the MetaManager system configuration to connect to Teradata Database systems. On Linux, the DDL Gateway uses the Teradata user name specified in mdsconfig to connect to the MDS repository. On Windows, the DDL Gateway runs as a service. A service can run as the LocalSystem Account or as a specified account name and password. If the MDS repository Database Configuration is configured for Teradata Single Sign On (SSO) where no username and password is specified, the Gateway Service must not be configured to run with the LocalSystem Account. If the MDS repository Database configuration is configured for SSO where no username and password is specified, there must be a Teradata user account with the same name as the user account in which the DDL Gateway is run. |