metaload - Teradata Meta Data Services

Teradata Meta Data Services User Guide

Product
Teradata Meta Data Services
Release Number
15.00
Language
English (United States)
Last Update
2018-09-27
Product Category
Teradata Tools and Utilities

metaload

Purpose

The metaload program is a command line alternative for loading, unloading, or resynchronizing databases. The metaload program loads the Teradata metadata into the MDS repository Database Information Metamodel (DIM). The metaload program is Unicode-enabled. It will attempt to make a UTF-16 session character set connection to Teradata databases.

If the program can establish a UTF-16 connection, the program does not require that the MDS views be installed into the DBC database with the metaviews program.

If the program cannot establish a UTF-16 connection, it will run in a mode that requires that the MDS views be installed into the DBC database with the metaviews program.

Beginning with MDS 13.0, metaload offers the ability to limit the database objects that will have metadata extracted and loaded into the repository. Limiting the metadata can improve load time and decrease the amount of disk space required by the repository but it can also result in incomplete information. Setting LoadTypes is not available in the current version of MDS Repository Explorer, but is possible using tools described in “Set MetaLoad LoadTypes” in Chapter 3 of Teradata Metadata Services Administrator Guide (3118-071A), the documentation for the previous release of MDS.

Note: If the Teradata Database is Kanji-enabled, all Kanji character sets that will be used must be installed.

Syntax

metaload -s systemname [-n dsn] [-l user] [-p password] 
{-m metasu's password | -S superuser -P superuser password}
 [-d database | -f file | -x file | -r | -u database | -U file]
         [-L label] [-t loadtypesname] [-c profile] [-o] 
         [-q [on | off | list <listfile>] | -evalrels] [-h] [-norls
 

Table 13: Metaload Input Parameters 

Parameter

Description

Required/Optional

Circumstances

-s systemname

User-defined system name for this Teradata Database System. Multiple Teradata Databases can be loaded into the MDS repository, each distinguished by its system name.

Required

 

-n dsn

 

The ODBC System Data Source Name (DSN) for MDS to use to connect to the Teradata Database System to be loaded.

 

Required

If the system object is not defined

 

Optional

If the system object is already defined

-l user

 

 

The Teradata user name for MDS to use to connect to the Teradata Database System to be loaded.

If you specify the -l parameter, metaload will use the value specified in the command line parameter instead of the environment variable and system object settings.

 

 

Required

  • If the system object is not already defined
  • Single Sign On (SSO) is not supported by the ODBC driver and the Teradata Database System
  • The MDSMETALOADUSER environment variable is not set
  • Optional

  • If the system object is already defined
  • Single Sign On (SSO) is supported by the ODBC driver and the Teradata Database System
  • The MDSMETALOADUSER environment variable is set
  • Not needed for an unload

    -p password

     

     

    The Teradata password for MDS to use to connect to the Teradata Database to be loaded.

    If you specify the -p parameter, metaload will use the value specified in the command line parameter instead of the environment variable and system object settings.

     

     

    Required

  • If the system object is not already defined
  • Single Sign On (SSO) is not supported by the ODBC driver and the Teradata Database System
  • The MDSMETALOADPWD environment variable is not set
  • Optional

  • If the system object is already defined
  • Single Sign On (SSO) is supported by the ODBC driver and the Teradata Database System.
  • The MDSMETALOADPWD environment variable is set.
  • Note: Using the environment variable prevents the password from being exposed to users running the ps command on Linux while metaload is running.

    Not needed for an unload

    -m metasu’s password

    Password of the MDS Administrator.

    If the -S, -P, and -m parameters are all provided the -m parameter is ignored.

    If you specify the -m parameter, and the -S and -P parameters are not provided metaload will use the value specified in the command line and ignore the environment variable.

    Required

    If the -S and -P parameters are not provided

    or

    If the password is not set in the environmental variable MDSMETASUPWD

    Note: Using the environment variable prevents the password from being exposed to users running the ps command on Linux while metaload is running.

    Optional

    If the -S and -P parameters are provided

    or

    If the password is set in the environmental variable MDSMETASUPWD

    -S superuser

    Specifies the name of an MDS Administrator. The -S parameter can specify metasu.

    Required

    If the -m parameter information is not provided

    Optional

     

    -P superuser password

    Specifies the password of the MDS Administrator given by the -S parameter.

    Required

    If the -S parameter is provided

    -d database

    Limits the load (or resync) to the specified database.

    If the database name contains special characters, the database name must be enclosed in double quotes.

    Optional

    If this is the initial load of the system and the -d or -f options are not specified, all databases will be loaded.

    If this is a resync of the system and the -d or -f options are not specified, all databases which have previously been loaded will be synchronized and all other databases will be loaded.

    -f file

    Limits the load (or resync) to the databases listed in the specified file. The names of the databases to be loaded (or resynchronized) are read from the file.

    See File Formats for file format information.

    Optional

    If this is the initial load of the system and the –d or –f options are both omitted, all databases will be loaded.

    If this is a resync of the system and the –d or –f options are omitted, all databases that have previously been loaded will be synchronized and all other databases will be loaded.

    -x file

    Loads all databases except those databases specified in the file.

    If a database name in the file has already been loaded, it will be skipped and a warning message appears.

    To unload a database you must use the unload option.

    See File Formats for file format information.

    Optional

     

    -r

    Resyncs all databases that have previously been loaded.

    Optional

    -u database

    Unloads the specified database

    Optional

    -U file

    Unloads the databases listed in the specified file.

    See File Formats for file format information.

    Optional

     

    -c profile

    Specifies the security profile to assign to the DIM objects being loaded.

    Optional

     

    -o

    Use the override option to run metaload to complete loading of a previously aborted system load.

    Metaload sets a “loading” flag to prevent multiple metaload processes from attempting to load the same system simultaneously. If a running metaload process is aborted, this flag is not reset.

    Optional

     

    -L label

    Specifies a label name to be applied to the loaded system. The label should not be currently defined. If the label is currently defined, metaload verifies that the label is not currently attached to entries in the repository.

    Optional

     

    -t loadtypesname

    Provides the name of an entry in the MetaloadLoadTypes class. The entry defines the data types (tables, views, macros, and so on) that will be loaded for the system. If this parameter is used with an existing system, and resync is being done, it will replace the loadtypes entry currently associated with the system. If this parameter is not present with a new system, then all supported types will be loaded. If this parameter is not present with an existing system, that is, a resync is being done, then the system's currently associated entry will be used. Note: a system will always be associated with an entry in the MetaloadLoadTypes class

    Optional

     

    -evalrels

    Specifies that on a resync the relationships for all objects in the loaded system should be re-evaluated, even if the SynchronizationLevel for the object is already set to 1.

    This parameter cannot be used with the -q parameter

    Optional

     

    -h

    Displays a message describing the metaload parameters and then exits.

    Database names specified with the -d and -u parameters may not be given in U& format.

     

    -q or
    -q on

    This parameter requests a QuickLoad. QuickLoad only captures information from the DBC data dictionary tables. This means that all of the interrelationships between tables, views, macros, stored procedures, UDTs, and UDFs are not set. A QuickLoad loads the definitions of the tables, views, macros, and so on for each database as well as the associated columns or parameters, but that is all. For view columns, the information loaded is very limited because the data dictionary tables only provide the name and comments for a view column; information on the column data type does not appear.

    Optional

    This option is only applicable with databases that are not currently loaded; a currently loaded database that is not QuickLoaded cannot be changed to a QuickLoaded database. Use this option when your intent is to only see the contents of each database. This parameter cannot be used with the -evalrels parameter.

    -q off

    This parameter requests that any QuickLoaded database processed by this command should be processed normally. All relationships that are not established for a QuickLoaded database will now be evaluated. Any currently loaded database affected by this option can never revert to a QuickLoaded state.

    Optional

    This parameter cannot be used with the -evalrels parameter.

    -q list <listfile>

    This parameter generates a file, <listfile>, with a listing of the databases in the system that are QuickLoaded, and then exits. The file is in the format used as input for the -f option.

    Optional

    Metaload exits after generating the file. This parameter cannot be used with the -evalrels parameter.

    -norls

    This parameter prevents the loading or resyncing of the security constraints for a system.

    Optional

     

    File Formats

    If the -f file, -x file, or -U file parameters are specified to load, resynchronize, or unload databases as listed in a file, the required format of this file is:

    <DB>
    databasename
    </DB>
    <DB>
    databasename
    </DB>

    The heading tag <DB> and the trailing tag </DB> must each be on a separate line. There is no limit to the number of database names that can be included in the file. The special format is used to enable specification of the special characters (such as a newline) that Teradata allows to be used in a database name. If the database name contains leading spaces these must be included. Trailing spaces in the name are optional. Database names are not case sensitive but special characters must match exactly.

    You can also give the database name by using the U& format. For example, U&"#0044#0042#0043" uescape '#'. This lets you include non-printing characters in the name.

    Warning Messages

    It is possible for Teradata to contain views that reference columns in tables that no longer exist. If metaload detects this situation, it will log warnings into the MDS error log indicating which views reference invalid columns.

    It is not a requirement that all databases in a Teradata Database System be loaded into the MDS repository. Because of this, you can get the following warning messages:

  • If the owner database of a database being loaded has not been loaded, you will get a warning message similar to this:
  • Could not create the DBOwnsDB Collection for DB[metaadm] because the OwnerDB[dbc] is not loaded in MDS
  • If a view in the database being loaded references a table located in a database that has not been loaded, you will get a warning message similar to this:
  • Could not create the ViewHasTableColumn Collection for View [myview1] because systemname:dbname.tablename is not loaded in MDS

    If you run metaload again to resynchronize the database after the owner database or the database with the view table columns has been loaded, MDS will set up these relationships.

    Functionality of QuickLoad

    QuickLoad is a feature of metaload intended to provide baseline information about a database’s contents as quickly as possible. The baseline information is obtained from a system’s DBC data dictionary tables. What is missing is what the data dictionary currently does not provide: the interrelationships between tables, views, macros, stored procedures, and so on. Generating the interrelationships, although sometimes necessary, is the most time-consuming work done by metaload. Measurements have shown that for databases with significant numbers of views, macros, and stored procedures, 80-90% percent of metaload’s time can be used to generate the interrelationships. QuickLoad provides a way to prevent that, when only baseline information is needed.

    The information currently provided by metaload for a QuickLoaded database includes:

  • The SynchronizationLevel property of the database object is set to -2.
  • For tables, it loads the table, all of the table’s columns, constraints, and indexes as normal. If a column is defined as using a UDT, the ColumnHasUDT relationship is established. If a column is defined as an identity column, the identity column definition is not set because it requires extended processing. The SynchronizationLevel property of the table can be set to one (1) if there is no identity column, but is set to -2 if there is an identity column.
  • For views, it loads the view and all of its columns, but each view column only has its name and column position set because that is the only information in the data dictionary. The IsRecursive property of the view is not determined because it requires extended processing. All relationships other than ViewHasColumns cannot be set because they require extended processing. The SynchronizationLevel property of the view is set to -2.
  • For macros, it loads the macro and all of its parameters. If a parameter is defined as using a UDT, the MacroParameterHasUDT relationship is established, but other than MacroHasParameters, no other relationships can be set. The SynchronizationLevel property of the macro is set to -2.
  • For stored procedures, it loads the stored procedure and all of its parameters. If a parameter is defined as using a UDT, the SPParameterHasUDT relationship is established, but other than SPHasParameters, no other relationships can be set. The SynchronizationLevel property of the stored procedure is set to -2.
  • For triggers, it loads the trigger definition and sets the TableHasTriggers relationship. All other relationships cannot be set because they require extended processing. The SynchronizationLevel property of the trigger is set to -2.
  • For hash indexes and join indexes, it loads the index and all of its contained subindexes. The SynchronizationLevel property is set to -2 because all other information requires extended processing.
  • For UDTs, they are loaded normally and the SynchronizationLevel property is set to one (1).
  • For functions, the function and its parameters are loaded. If a parameter is defined as using a UDT, the FunctionParameterHasUDT relationship is established. If the function is a constructor or method for a UDT, the UDTHasFunctions relationship is established. The SynchronizationLevel property of the function is set to -2.
  • QuickLoad and DIM Update

    The DIM Update processes are aware of QuickLoaded objects. When a DDL being processed by DIM Update references an existing object that has a SynchronizationLevel property set to -2, the current object being processed is considered out-of-sync and its SynchronizationLevel property set to zero. The database containing the object is put out-of-sync and its SynchronizationLevel property set to -1.

    The nightly resync has two steps. The first step is to individually resync the databases that are known to require resyncing. It does not process all databases that are out-of-sync. The resync only processes databases that the DIM Update knows are out-of-sync with Teradata because Teradata could not send one or more DDLs for the database to be processed by DIM Update. The databases being processed can have any possible SynchronizationLevel property. Those objects with a SynchronizationLevel property of -2 receive normal processing, the full complement of relationships is established, and the database is no longer considered QuickLoaded. None of the databases processed by this step remain QuickLoaded; any later processing by metaload invokes normal processing and the setting of all known relationships.

    The second step is to resync all databases that still have a SynchronizationLevel property of -1 after the first step has finished. Unlike the previous step, this step does not process QuickLoaded databases. A QuickLoaded database remains in that state until DIM Update cannot successfully process a new DDL sent by Teradata or the database is marked by Teradata as having unsent DDLs. This defers the possibly lengthy processing of a once QuickLoaded database until circumstances require it.