Data Dictionary
V2R4.1
B035-1092-061A
June 2001
The product described in this book is a licensed product of NCR Corporation.
BYNET is an NCR trademark registered in the U.S. Patent and Trademark Office.
CICS, CICS/400, CICS/600, CICS/ESA, CICS/MVS, CICSPLEX, CICSVIEW, CICS/VSE, DB2, DFSMS/MVS, DFSMS/
VM, IBM, NQS/MVS, OPERATING SYSTEM/2, OS/2, PS/2, MVS, QMS, RACF, SQL/400, VM/ESA, and VTAM are
trademarks or registered trademarks of International Business Machines Corporation in the U. S. and other countries.
DEC, DECNET, MICROVAX, VAX and VMS are registered trademarks of Digital Equipment Corporation.
HEWLETT-PACKARD, HP, HP BRIO, HP BRIO PC, and HP-UX are registered trademarks of Hewlett-Packard Co.
KBMS is a trademark of Trinzic Corporation.
INTERTEST is a registered trademark of Computer Associates International, Inc.
MICROSOFT, MS-DOS, MSN, The Microsoft Network, MULTIPLAN, SQLWINDOWS, WIN32, WINDOWS,
WINDOWS 2000, and WINDOWS NT are trademarks or registered trademarks of Microsoft Corporation.
SAS, SAS/C, SAS/CALC, SAS/CONNECT, and SAS/CPE are registered trademarks of SAS Institute Inc.
SOLARIS, SPARC, SUN and SUN OS are trademarks of Sun Microsystems, Inc.
TCP/IP protocol is a United States Department of Defense Standard ARPANET protocol.
TERADATA and DBC/1012 are registered trademarks of NCR International, Inc.
UNICODE is a trademark of Unicode, Inc.
UNIX is a registered trademark of The Open Group.
X and X/OPEN are registered trademarks of X/Open Company Limited.
YNET is a trademark of NCR Corporation.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS-IS” BASIS, WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED
WARRANTIES, SO THE ABOVE EXCLUSION MAY NOT APPLY TO YOU. IN NO EVENT WILL NCR CORPORATION (NCR) BE
LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR
LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
The information contained in this document may contain references or cross references to features, functions, products,
or services that are not announced or available in your country. Such references do not imply that NCR intends to
announce such features, functions, products, or services in your country. Please consult your local NCR representative
for those features, functions, products, or services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may
be changed or updated without notice. NCR may also make improvements or changes in the products or services
described in this information at any time without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization,
and value of this document. Please e-mail: info.products@SanDiegoCA.ncr.com
or write:
Information Engineering
NCR Corporation
100 North Sepulveda Boulevard
El Segundo, CA 90245-4361
U.S.A.
Any comments or materials (collectively referred to as “Feedback”) sent to NCR will be deemed non-confidential. NCR
will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display,
transform, create derivative works of and distribute the Feedback and derivative works thereof without limitation on
a royalty-free basis. Further, NCR will be free to use any ideas, concepts, know-how or techniques contained in such
Feedback for any purpose whatsoever, including developing, manufacturing, or marketing products or services
incorporating Feedback.
Date Description
June 2000 The new features added to this book for this release include the
following:
• Stored procedures, called Persistent Stored Modules (PSM) in
the ANSI SQL-99 specifications, are created in the user’s
database space as tables. A stored procedure consists of a set
of control and condition-handling statements that make SQL a
computationally complete programming language.
• Ability to preserve the same table version number when only
journaling options are used on the RDBMS to allow suitable
backup and recovery operations.
• Increased macro and view text limits to 26000 bytes based on
new 64KB row size.
Date Description
December 1999 This book has been redesigned for this release. Changes made to
this book include the following:
• Reorganization and consolidation of the listings of views and
view columns to add hypertext links and eliminate
redundancy.
• Added information on which tables are referenced by each
view.
• Addition of new chapter on tables that lists the tables and
columns of the DBC, noting the primary and secondary index
columns, data type, and format.
• Deletion of Appendix A that lists the differences between the
TOS and Teradata RDBMS versions of the Data Dictionary.
Purpose
This book describes the Teradata RDBMS Data Dictionary and contains
information about system views that allow different types of users to access
underlying table information stored in Teradata RDBMS.
This includes specific information about the following:
• Database objects
• Sessions
• Resource usage
Audience
This book is intended for system administrators, database administrators, and
other technical personnel responsible for maintaining the Teradata Relational
Database Management System (RDBMS). More specifically, the manual
provides information for the following types of users:
• End users
• Supervisory users
• Teradata RDBMS database administrators
• Teradata RDBMS security administrators
• Operations control users
Prerequisites
You should be familiar with relational databases in general and the Teradata
RDBMS in particular.
It may be helpful to review the following books:
• Introduction to Teradata RDBMS
• Teradata RDBMS Database Design
• Teradata RDBMS SQL Reference, Volume 1
• Teradata RDBMS Database Administration
List of Acronyms
This book uses acronyms, which the following table lists in alphabetical order:
DD Data Dictionary
HI Hash Index
HW Hardware
ID Identifier/Identification
I/O Input/Output
JI Join Index
KB Kilobytes
OS Operating System
PC Personal Computer
PE Parser Engine
PJ Permanent Journal
RI Referential Integrity
SW Software
TP Transaction Processor
VM Virtual Machine
Preface
Chapter 1:
Teradata RDBMS Data Dictionary Overview
What is the Data Dictionary?......................................................................................... 1–2
Data Dictionary Users.................................................................................................. 1–2
Accessing the Data Dictionary.................................................................................... 1–3
Updating the Data Dictionary .................................................................................... 1–3
How the System Uses Data Dictionary Information............................................... 1–4
Organization of the Data Dictionary ............................................................................ 1–5
What are System Views? ................................................................................................ 1–6
Granted Rights on System Views............................................................................... 1–6
Extending View Privileges .......................................................................................... 1–6
System View Versions Non-X and X ......................................................................... 1–7
Views for Special Users .................................................................................................. 1–8
Security Logging Views............................................................................................... 1–9
Administrator Views.................................................................................................. 1–10
Operations and Recovery Control Views ............................................................... 1–11
Supervisory User Views ............................................................................................ 1–12
End User Views .......................................................................................................... 1–12
Querying the Data Dictionary ..................................................................................... 1–14
Special Keywords ....................................................................................................... 1–14
Querying X Versus Non-X Views ............................................................................ 1–14
Example for Non-X View Query .............................................................................. 1–15
Example for X View Query ....................................................................................... 1–15
Dictionary Information Using HELP and COMMENT ........................................ 1–16
Stored Procedures ......................................................................................................... 1–17
What Is a Stored Procedure?..................................................................................... 1–17
Relationship with DD ................................................................................................ 1–17
Chapter 2:
System Views
Users of DD Views .......................................................................................................... 2–2
X Version Views............................................................................................................... 2–3
System Views Reference ................................................................................................. 2–4
System View Columns Reference ............................................................................... 2–22
Chapter 3:
System Views: Usage and Examples
AccessLog ......................................................................................................................... 3–2
AccLogRules..................................................................................................................... 3–4
AccountInfo[X]................................................................................................................. 3–7
AllRights ........................................................................................................................... 3–8
AllSpace[X] ..................................................................................................................... 3–10
AllTempTables[X] ......................................................................................................... 3–12
All_RI_Children............................................................................................................. 3–14
All_RI_Parents ............................................................................................................... 3–15
AMPUsage...................................................................................................................... 3–16
Association ..................................................................................................................... 3–17
CharSets .......................................................................................................................... 3–19
CharTranslations ........................................................................................................... 3–20
Children[X] ..................................................................................................................... 3–22
Collations ........................................................................................................................ 3–23
Chapter 4:
System Tables
Creating System Tables .................................................................................................. 4–2
Special Table Information .............................................................................................. 4–3
DBC.ALL Table ............................................................................................................. 4–3
DBC.TVM Table............................................................................................................ 4–3
DBC.TVFields Table ..................................................................................................... 4–3
Stored Procedures......................................................................................................... 4–3
ResUsage Tables ........................................................................................................... 4–4
Non-Hashed Tables......................................................................................................... 4–5
Data Dictionary FALLBACK Tables............................................................................. 4–6
Chapter 5:
Macros
TwoPCRule Macro .......................................................................................................... 5–2
Creating the TwoPCRule Macro ................................................................................ 5–2
TwoPCRule and the Resolver Base Module ............................................................. 5–2
ResUsage Macros............................................................................................................. 5–3
DIPVIEW Macros ............................................................................................................ 5–4
ARC_NonEmpty_List Macro...................................................................................... 5–4
ClearAccounting Macro............................................................................................... 5–5
ClearPeakDisk Macro................................................................................................... 5–6
CollAddStandard Macro ............................................................................................. 5–6
CollInstallMulti Macro................................................................................................. 5–7
DIPMarkNS10 Macro ................................................................................................... 5–7
LogonRule Macro ......................................................................................................... 5–8
Index.......................................................................................................................... Index–1
This chapter describes the Teradata RDBMS Data Dictionary (DD) and provides
information about the following topics:
• What the Data Dictionary consists of
• How the Data Dictionary is organized
• What views are and who uses them
• How to perform queries on the Data Dictionary
• What are stored procedures
• Monitoring system use
• DIPVIEW script
• Tracking system events
• System calendar
• Maintaining system logs
• Other system objects
• Columns with Hex Unicode constants
The Teradata RDBMS Data Dictionary is composed of tables and views that
reside in the system database called DBC. These tables and views are reserved
for use by the system and contain information about the system’s associated
data. DD system tables include current definitions, control information, and
general information about the following:
• Databases
• Character Sets
• Users
• Accounts
• Tables
• Views
• Columns
• Indices
• Sessions and Session Attributes
• Triggers
• Access Rights
• Journal Tables
• Disk space
• Events
• Resource Usage
• Macros
• Stored Procedures
approved query uses the DD information, along with all other available
statistics, to devise the best method of accessing the data.
approved request executes the macro according to the definition stored in the
that references a DD.
macro name
approved request assembles the view according to the definition stored in the
that references a view Data Dictionary, and returns data rows retrieved from the
name underlying tables or views to the user.
Data Dictionary entries are stored in system tables in a special database, named
DBC. Information in these system tables can be examined directly or through a
series of views.
System views are pre-defined views that provide users with a way to retrieve
frequently used data from underlying system tables. Views do not contain data
and are stored as entries in the data dictionary. Views, which look like tables to
users, display data in columns and rows only when a user submits an SQL
statement that uses them. View names, such as “DiskSpace, “Users” and
“Columns”are based on entries contained in the underlying tables.
The set of views that are available to a user is determined by the Teradata
RDBMS administrator. Specialized views are designed to meet the needs of the
following individuals:
• Teradata RDBMS security administrator
• Teradata RDBMS and system administrator
• A user who supervises other Teradata RDBMS users and accounts
• An end user or client logged on to a Teradata RDBMS session
• An operator using the database window of the Administration Workstation
(AWS) or responsible for running client utilities such as the
Archive/Recovery or Archive Storage Facility2 (ASF2)
References to specific views for certain users are described in detail later in this
chapter.
System views are part of the Teradata RDBMS Data Dictionary and reside in the
space owned by the system user DBC. View definitions are stored in the table
DBC.TVM.View column information is stored in DBC.TVFields.
The Teradata RDBMS system administrator loads the views for a site by
running the Database Initialization Program (DIP) from the Database Window
(DBW). For more information on running DIP from the DBW, see Teradata
RDBMS Utilities. DIP is used to execute one or more of the standard DIP SQL
scripts packaged with the Teradata RDBMS.
Supplied views allow the system administrator to provide a consistent image of
the data stored in the Data Dictionary. In most instances, only the Teradata
RDBMS administrator is allowed to update or delete a Data Dictionary view or
its underlying system tables.
Example
For example, assume user Jones enters a query against the standard TableSize
view, as follows:
SELECT * FROM DBC.TableSize;
This query returns size information for every data table in the Teradata
RDBMS.
To limit the response, Jones could query the X version of the view. For example,
if Jones submits the following query:
SELECT * FROM DBC.TableSizeX;
then information is returned only for those tables that Jones created or is
otherwise associated with.
Some views are generally available only to special system users, and are not
normally available to PUBLIC, although this depends solely on the privileges
that are granted to each user. The following table describes who typically uses
certain types of views:
Security Logging The security logs, which store information about access rules
and events, are populated as a result of executing BEGIN
LOGGING and END LOGGING statements.
These statements may be executed only if the AccLogRule
special security macro has been installed on the Teradata
RDBMS server.
The system administrator should create a security
administrator user, and grant to that user at least the SELECT
privilege on the access logging views.
For more information, see Teradata RDBMS Security
Administration.
The following sections describe the particular views that can be valuable to
different types of users.
View Definition
Logging will not occur on the following access statements unless a logging rule
specifies the view or macro used:
• SELECT . . . FROM View1_of_Table1
• EXECUTE MACRO1
(Where Macro1 contains the statement SELECT . . . FROM Table1)
Note: The behavior of not logging indirect access to underlying tables when
views or macros are executed was introduced with Teradata RDBMS Version
2.0. In prior releases, if underlying tables had logging rules, then rows were
added even if access was through a view or macro.
Note: It is strongly recommended that you not install the macro unless your
site requires such security, since the logging feature extracts a performance
penalty even if little or no logging is performed.
Administrator Views
Data Dictionary views of specific interest to a Teradata RDBMS administrator
and a system administrator could include, but are not limited to the following:
View Description
AllSpace[X] How much disk storage space or spool space is being used
by a given table, database/user, or account, on all AMPs or
specific AMPs?
DiskSpace[X] How much disk storage space or spool space is being used
by a given database/user or account on all AMPs? On
specific AMPs?
View Description
TableSize[X] What is the current and peak disk space usage (not
including spool) for a given database/user, data table,
journal table, or account on all AMPs? On a specific AMP?
Note: When you are logging view accesses, only the access of the top view in a
hierarchy is logged. Actions based on base views or tables are not logged.
View Description
Events_Configuration[X] Archive and restore activity that did not affect all
AMPs.
View Description
View Description
View Description
Special Keywords
Three special keywords are used in queries of dictionary views. Although they
appear as database names in information returned from a view, these keywords
are not databases. Rather, they are character strings that serve as placeholders,
appearing only as special “database names” in the queries of certain views.
The three special keywords are:
• ALL
• DEFAULT
• PUBLIC
These keywords must be enclosed in quotation marks when they are used.
For example, the following query uses ALL as a keyword and returns the
logging rules that apply to all users:
SELECT * FROM DBC.AccLogRules WHERE UserName = ’ALL’;
Assuming that both the X and non-X versions of the views are installed, and
that the SELECT privilege is granted to PUBLIC on both versions, the
information returned by an unconditional SELECT depends on the specified
viewname, as follows:
DBC.viewname all objects for which entries exist in the underlying table.
Note: Unconditional SELECTs on non-X views may cause
the result to exhaust the available spool space of the user.
Stored Procedures
Relationship with DD
Information pertaining to stored procedures is included in the following
Teradata RDBMS DD tables:
• DBC.TVM
• DBC.TVFields
• DBC.AccLogRuleTbl
The privileges relating to stored procedures are CREATE PROCEDURE,
EXECUTE PROCEDURE, and DROP PROCEDURE.
See Chapter 4: “System Tables” for more specific information on tables affected
by stored procedures.
PM/API Queries
MONITOR-Related Queries
Queries related to the Performance Monitor are made in a manner similar to
other Data Dictionary queries.
The following queries provide information about MONITOR-related activities:
To determine who is using the monitor, enter the following:
SELECT UserName, IFPNo FROM DBC.SessionInfo
WHERE Partition = ’MONITOR’ ;
Queries regarding the use of system monitoring can be made much like other
SELECT queries. For example, to determine what users have the privilege to
force other users off the system, enter the following:
SELECT DISTINCT UserName FROM DBC.AllRights
WHERE AccessRight = ’AS’ ;
The ‘AS’ indicates the ABORT SESSION privilege.
To find out what users have been forced off the system in the past two days,
enter the following:
SELECT DISTINCT UserName FROM DBC.LogOnOff
WHERE Event = ’Forced Off’
AND LogDate > DATE - 3 ;
AMPUsage View
The AMPUsage view supplies information about AMP CPU time consumed,
and the number of AMP to DSU read and write operations generated by a
given user or account.
This view also tracks the activities of any console utilities. A row is returned for
each AMP in the system unless aggregate figures are specified.
When you ask for resource usage logging, data about CPU overhead, user
service, and user execution is collected by vproc type and by node.
You can use the AMPUsage, AllSpace, DiskSpace, and TableSize views to
summarize resource usage for all AMPs, or for AMPs on which data is stored.
Example 1
To obtain a list (in the order of the amount of space used) of those databases
currently using more than 80% of their permanent space allocation, submit the
following statement:
SELECT DatabaseName, SUM(CurrentPerm)
FROM DBC.DiskSpace
GROUP BY DatabaseName
HAVING (SUM(CurrentPerm)/NULLIFZERO(SUM(MaxPerm))) >.8
ORDER BY SUM(CurrentPerm) DESC;
You can also use the AMPUsage and DiskSpace views to compile and maintain
usage statistics that can later be selected and analyzed as described in the
following sections.
Example 2
The DBC.AMPUsage, which is a view for the DBC.Acctg system table, provides
information about the usage of each AMP for each user and account.
For example, the CPU time in a given row is the cumulative CPU time of the
user since logon plus the cumulative previous logon time for that user. The I/O
entry in a row records the total I/O accesses for the user during any reporting
logon period.
The following occurs to DBC.Acctg, which is a non-fallback and non-hashed
system table when an AMP is down:
• Data rows on the down AMP are not available, and DML statements such
as SELECT, INSERT, UPDATE, and DELETE do not apply to the down
AMP.
• Resource accounting information for the down AMP temporarily
disappears until the AMP is back online.
• Any aggregate query on the DBC.Acctg includes only the online AMPs.
• No resource accounting information is recorded during the down AMP
recovery.
• The down AMP recovery is not associated with any particular user.
However, the resource accounting associated with the Transient Journal (TJ)
rolling back for the down AMP is charged to the user. (That is, no resource
accounting is charged to the user while the down AMP recovers from
offline to online except when the updates on the TJ apply to the down
AMP.)
• A system restart may impact the cumulative totals in the DBC.Acctg. (That
is, any accounting data accumulated in the cache since the last time the
cache was flushed before the restart will be lost completely and will not
contribute to the totals in DBC.Acctg resulting from the loss of cache
memory.)
Step Action
1 Select statistics from the AMPUsage view and insert them in the history table.
This procedure may be carried out using the following BTEQ script:
.LOGON username, password
The units in which Disk I/O are measured represent data block accesses. CPU
time is measured in seconds.
Refer to the DiskSpace View to see how you can use the DiskSpace view to
build and maintain a table of disk space usage.
After a collection period, you may select AMPUsage and DiskSpace statistics
from the history tables using BTEQ to archive the data on the client system.
BTEQ stores the selected data in sequential data sets on the host computer for
subsequent analysis.
A BTEQ script can be used to achieve the following:
• Creates a client-resident file (in this case, the client is MVS),
• Uses the BTEQ .EXPORT command to save the data being selected into that
file, and then
• Selects all rows from the DiskSpace history table
The following example shows how such a BTEQ job is used to select data from
the DiskSpace history table:
//JOBNAME JOB jobcard
//EXTRACT EXEC PGM=ITBMAIN
//STEPLIB DD DSN=TERADATA.APPLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SAVEDATA DD DSN=ACC.SAVEDATA.DATA,DISP=(NEW,CATLG)
// UNIT=SYSDA,SPACE=(TRK,(1,1),RLSE),
// DCB=(LRECL=80,RECFM=FB,BLKSIZE=800)
//SYSIN DD DATA,DLM=##
.LOGON somebody,password
.EXPORT DATA DDNAME=SAVEDATA
SELECT * FROM DiskSpaceHist
ORDER BY CollectDate,CollectTime;
.QUIT
##
Once selected and stored, historical data can be used for analysis, as follows:
• Client-resident software packages such as SAS can be used to perform trend
analysis and other statistical manipulation on the data.
• Graphic software packages can be used to display the data.
Additional Information
The following references provide additional information on resource usage:
DIPVIEW Script
Tracking Privileges
The UserRights view provides information about the privileges that have been
granted to any user.
See the description of the GRANT statement in the Teradata RDBMS SQL
Reference, Volume 4, for an explanation of the types of privileges and how they
are granted.
If a more detailed audit trail is necessary, this information may be
supplemented by log entries that provide an audit trail of the results of checks
against requests to access table data. See also Teradata RDBMS Security
Administration.
Sys_Calendar
The DIPCAL SQL script must be run from the DIP utilities by the administrator
to create the SYS_CALENDAR database and CALENDAR view.
The primary key of the calendar is the SQL “DATE” data type. The calendar
dates range from 1900 to 2100 and are stored in a table in the SYS_CALENDAR
database.
For more information on how to use the OLAP Calendar capabilities, see the
section on Data Definitions in Teradata RDBMS SQL Reference, Volume 1.
The resource usage logs and the tables underlying the AMPUsage, AccessLog,
LogOnOff, and Software_Event_Log views are not purged automatically by the
system.
Outdated information in these tables should be deleted periodically by an
authorized user such as a security, database, or system administrator, or by
NCR support personnel.
Because the errors and events that comprise Software_Event_Log information
are scrutinized in order to enhance the product, this information is often
maintained by NCR field support personnel.
The following system objects are not covered in detail in this manual:
The columns listed in the following tables are stored with a CharType based on
the system’s support of Japanese Language (see ”System Initializer Utility” in
Teradata RDBMS Utilities).
Constants are converted to the _Unicode’..’XC format if they would otherwise
not be sharable (see Teradata SQL Reference, Volume 3, "Data Types and Literals").
System Views
This chapter serves as a reference for users of system views and consists of the
following:
• A brief description of the various types of users that have access to the
system DBC views.
• A reference table describing the DBC views, the tables referenced by each
view, the columns selected by that view, and the typical user of that view.
• A reference table that lists and describes all the columns referenced by the
system views in alphabetical order including the data type and format of
each column.
In the online document, hypertext links for the system views table exist that
allow you to go to the columns table and get the detailed information on any
column that you select for a specified view.
Users of DD Views
Many of the views in the Teradata RDBMS Data Dictionary may be restricted to
special types of users, while others are accessible by all users. The ability to
access views is controlled by granting of access rights by the system
administrator. The following table defines the information needs of various
types of users:
X Version Views
In views that include an X version, the additional tables that are referenced by
the X version of the same view are preceded by an X as the examples on this
page show.
Note The DBC.UserDB and DBC.OwnerDB system views will not be covered
in this section because they are not usually referenced directly by users. These
views are used only to join other system tables and views (especially the X
version of views).
View Name and Description Referenced Tables User Type Columns Selected
The following table lists all the views included in the database DBC and
includes a brief description of how the view is used, the referenced tables, and
columns selected by that view.
You can view detailed information for a specific column in the view by using
the index in this book, or online by clicking on the blue hypertext link for
column name in the system views table, which automatically links you to that
column description in the columns table.
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
Referenced Tables
View Name and Description User Type Columns Selected Referenced column(s)
and Views
The following columns table describes the columns of each of the system views
in the DBC in alphabetical order. In addition, it includes information on which
views select that column, and the data type and format of the column.
Using the information included in the view columns table, you can write a
SELECT statement that will return the information you want.
CollInstall Returns the install flag for the CHAR X(1) Collations
collation. The option returns NOT NULL
Y (yes) if the collation is
installed when the Teradata
RDBMS is started and N (no)
if the collation is not installed
when the Teradata RDBMS is
started. This flag applies only
to multinational collation.
Other collations are never
installed.
PasswordLastMod Returns the date that the user DATE YY/MM/DD Users
Date password was last modified.
PasswordLastMod Returns the time that the user INTEGER 99:99:99 Users
Time password was last modified.
Type Description
I IN parameter
B INOUT parameter
O OUT parameter
This chapter explains the purpose of each of the DBC Data Dictionary system
views. The views are presented in alphabetical case-insensitive order by view
name and include the following information:
• View form (a view that has an X version is shown in the form
“ViewName[X]”)
• Columns that the view selects from the system table
• Corresponding system tables
• Usage notes about special information or uses of the view
• Examples, where available, of the results returned by a SELECT request on
the view. If applicable to the type or quantity of information being selected,
the example shows the X version of the view in the statement reference.
• Other Teradata RDBMS documents that can provide additional information
about this view
Note: The results shown in the examples are for illustration purposes only.
Utilities and tools, such as BTEQ, or other third-party products, may be used to
enter queries and will format the results differently.
AccessLog
Purpose
Returns logging entries generated by the application of access logging rules
(see “AccLogRules”).
Usage Notes
Each row AccessLog displays indicates the results of a privilege check.
Whether a privilege check is logged depends on the presence and the criteria of
an access logging rule (see “AccLogRules”).
Example
The following SELECT retrieves the name of the submitting user from the
AccessLog, the type of request, and the request text of each request that caused
a privilege check to be logged on a specific date. The response shows that one
request caused a privilege check to be logged on that date. (The statement text
column has been truncated in the results.)
AccLogRules
The AccLogRules view provides information about logging rules that are
currently in effect on the system. The underlying table is populated as a result
of successfully processed BEGIN LOGGING statements.
Usage Notes
The underlying table of this view is populated only if the security macro is
installed and the Teradata RDBMS or security administrator has executed one
or more BEGIN LOGGING statements.
Each row in the underlying table defines a rule controlling what privilege check
is to be logged when a specific user attempts to access a specific object.
When a request is submitted that involves any of the rule criteria, the details of
the involvement are recorded in the access log (see “AccessLog”).
In AccLogRules, each Access Rule (Acr...) column is named for a particular
privilege, which is also associated with an access action and a SQL statement.
In each column, each character position represents the frequency with which
checks performed on that privilege are to be logged, as follows:
1 Position 1 (every privilege check) indicates how often to log checks on this
privilege when performed against any requests (submitted by a specified
user) that attempt to access the specified object. Possible values that could
appear in each position are as follows:
• B Both FIRST and LAST occurrences are to be logged.
• E Each occurrence is to be logged.
• F FIRST occurrence is to be logged.
• L LAST occurrence is to be logged.
• blank No logging.
3 Position 3 (save text of request) indicates whether to record the text of the
requests that cause a check on this privilege.
• - Save text only for Denial entries.
• + Save text for all entries.
• = Save text for all entries (specified in multiple BEGIN LOGGING
statements).
• blank No WITH TEXT option specified.
Example
If the following statements are submitted, a SELECT statement retrieving the
AccLogRules entries for User1 returns the rows as shown:
• In the first row, the UserName “Jones”, the DatabaseName “Jones”, and the
“E” in the first position of the CTB column indicate that a log entry is to be
made each time a check for the CREATE TABLE privilege is performed in
response to a request by Jones to create a table in his own space.
• In the second row, the UserName “Jones”, the DatabaseName “Personnel”,
and the “F” in the second position of the CDB column indicate that a log
entry is to be made the first time a check for a CREATE DATABASE
privilege that results in a denial is performed in response to a request by
Jones to create a database in the Personnel database. The “-” in the third
position of the CDB column indicates that the text of the denied statement
is to be saved in the log entry.
AccountInfo[X]
The AccountInfo view provides information about valid accounts for the
specified user(s).
Example
==> SELECT UserName, AccountName FROM DBC.AccountInfo
WHERE UserName IN (’Bob’,’G417’) ;
UserName AccountName
Bob 7654
Bob Temp Work Area
G417 137
G417 $HGAVE
Additional Information
See Teradata RDBMS Database Design for more information on controlling
access, space, and ownership.
AllRights
The AllRights view provides information about all users who have been
explicitly or automatically granted privileges, and the objects on which the
privileges were granted including: databases, users, tables, views, stored
procedures, and macros.
Usage Notes
The AllRights view does not return information about implicit privileges for a
user, only explicit rights granted on the object. The explicit rights include the
following:
• AS = ABORT SESSION
• CD = CREATE DATABASE
• CG = CREATE TRIGGER
• CM = CREATE MACRO
• CP = CHECKPOINT
• CT = CREATE TABLE
• CU = CREATE USER
• CV = CREATE VIEW
• D = DELETE
• DD = DROP DATABASE
• DG = DROP TRIGGER
• DM = DROP MACRO
• DP = DUMP
• DT = DROP TABLE
• DU = DROP USER
• DV = DROP VIEW
• E = EXECUTE
• I = INSERT
• IX = INDEX
• MR = MONITOR RESOURCE
• MS = MONITOR SESSION
• PC = CREATE PROCEDURE
• PD = DROP PROCEDURE
• PE = EXECUTE PROCEDURE
• RO = REPLICATION OVERRIDE
• R = RETRIEVE/SELECT
• RF = REFERENCE
• RS = RESTORE
• SS = SET SESSION RATE
• SR = SET RESOURCE RATE
• U = UPDATE
Example
The following SELECT statement displays the privileges user Jones has on
tables.
AllSpace[X]
The AllSpace view provides AMP-by-AMP information about disk space usage
(including spool) for each database, data table, or journal table.
Usage Notes
When a database, user, or table is created, allocated disk space is divided
evenly among all AMPs. The AllSpace view returns one row of usage
information for each AMP in the Teradata RDBMS configuration (or for all
AMPs if the SUM aggregate is used).
When a database is created, a space row is added to each AMP, with the
processor field in each row initialized to 0. The first time the space row is
updated (such as when a table is created in the database, or when the system is
restarted), the processor field in each row is updated to indicate the actual
processor number.
When a query applies a SUM aggregate to either of those columns without a
WHERE clause, or with a WHERE clause that references only one tname or
dbname, the returned values will be double the desired result.
For example, the following query, which returns the correct amount of space
allocated to Peterson, also returns twice the amount of space currently being
used by Peterson (see DiskSpace and TableSize views).
Example
The following SELECT statement displays how the space currently used by the
data table named Department is distributed on each AMP.
==> SELECT DatabaseName,TableName,AMP,CurrentPerm FROM
DBC.AllSpace
WHERE TableName=’Department’ ORDER BY 1,2,3 ;
AllTempTables[X]
Usage Notes
A materialized temporary table is different from a permanent table in the
following ways:
• It is always empty at the start of a session
• The contents of the materialized table cannot be shared by other
sessions.
• It can optionally be emptied at the end of each transaction.
• It is automatically dropped at the end of each session.
Example
After a global temporary table definition is created, you can use the INSERT
statement to create a local instance of the global temporary table for use during
the session.
The following statement shows all temporary tables materialized by the login
user in the system.
==> SELECT * FROM DBC.AllTempTablesX
All_RI_Children
Usage Notes
The All_RI_Children view is designed for use in a SELECT statement with a
WHERE clause to narrow the selection criteria.
The All_RI_Children view is similar to the RI_Child_Tables view but returns
the database, table, and column names instead of the IDs for access control
purposes. The administrator can control who has access to internal ID numbers
by limiting the access to the RI_Child_Tables view while allowing more (or all)
users to access the names via the All_RI_Children view.
All_RI_Parents
Usage Notes
The All_RI_Parents view is designed for use in a SELECT statement with a
WHERE clause to narrow the selection criteria.
The All_RI_Parents view is similar to the RI_Parent_Tables view but returns the
database, table, and column names instead of the IDs for access control
purposes. The administrator can control who has access to internal ID numbers
by limiting the access to the RI_Parent_Tables view while allowing more (or all)
users to access the names via the All_RI_Parents view.
AMPUsage
The AMPUsage view provides information about the usage of each AMP for
each user and account.
AMPUsage monitors logical I/Os explicitly requested by the AMP database
software or file system that is running in the context of an AMP worker task for
the purpose of executing a step in the user query. I/Os done by UNIX for
swapping are not included in AMPUsage, nor are the I/Os caused by parsing
the user query.
A logical I/O is charged even if the requested segment is cached and no
physical I/O is done.
Example
The following SELECT statement is used to display, for a given account, total
CPU time and total DSU accesses for all AMPs.
==> SELECT AccountName,SUM(CPUTime),SUM(Diskio)
FROM DBC.AMPusage WHERE AccountName=’7654’
Additional Information
See Teradata RDBMS Database Design for more information on controlling
access, space, and ownership.
Association
The Association view allows the user to retrieve information about an object
that was imported from another Teradata RDBMS.
Usage Notes
The Association view contains information about entities that were restored
using the Archive and Recovery COPY utility. If a copied object is subsequently
dropped, then the information is deleted and is no longer available.
Example
The following SELECT statement selects information about tables copied into
the Personnel database.
==> SELECT Original_DatabaseName,Original_TableName,TableName
FROM DBC.Association WHERE DatabaseName = ’Personnel’;
Additional Information
The following references provide additional usage information on recovery
control.
CharSets
The CharSets view returns the names assigned to user-defined character sets. If
the view does not exist, or if no rows are found, then no special character sets
are currently available.
Usage Notes
The Teradata RDBMS can support many user-defined character sets (see the
“CharTranslations”). A maximum of six character sets can be installed at any
given time. The CharSets view Returns the names of character sets that are
currently installed and thus can be specified at the session level. If the view
does not exist or no rows are found, then no user-defined character sets are
available.
Each name shown in CharSets can be used as the identifier in the BTEQ [.]SET
SESSION CHARSET <’name’> command or the CLIv2 call CHARSET <name>.
However, the specified character set should be compatible with the internal
code of the logon client system.
If a CharSetName is ambiguous as to its compatibility with the logon client
system of the viewer session, consult the Teradata RDBMS administrator.
Example
The following example shows that two user-defined character sets are available
for the requesting user.
==> SELECT * from DBC.CharSets ;
CharSetName
French_EBCDIC
Swedish_EBCDIC
CharTranslations
Usage Notes
The underlying table of this view is populated by the Teradata RDBMS system
administrator or other responsible user. Each row in the table comprises a
translation table for one character set. The amount of character sets that can be
defined is limited only by the disk space available for the table. However, a
maximum of 12 sets can be installed as currently available at any one time.
The Teradata RDBMS must be reset to install the rows containing a Y in the
InstallFlag field. If the value of InstallFlag is Y in 12 rows or less, each Y row is
loaded. If InstallFlag is Y in more than 12 rows, then the CharSetName values
are sorted in ascending ASCII sequence, and rows are loaded in alphabetical
order until 12 sets are installed or the names are exhausted.
If client system connections are to use the defined character sets, the Teradata
RDBMS system administrator specifies which character set is assigned to which
client system (see DBC.HostsInfo view). Otherwise, the standard default is
used. Also, the user may specify a defined character set after a session is started
(see “CharSets”).
When specifying a character set for a session, the choice should be compatible
with the internal code of the logon client system; that is, an
EBCDIC-compatible character set for sessions initiated from an IBM
mainframe, ASCII-compatible sets for all others. It is suggested, therefore, that
Example
The example below shows that the hexadecimal translation tables for 6
character sets have been defined, and that two of these are flagged for loading.
==> SELECT * FROM DBC.CharTranslations;
Char Install
CharSetName Set Id Flag E2I
Children[X]
The Children view lists the names of databases and users and their parents in
the hierarchy.
Example
The following SELECT statement displays databases and users that are owned
by the Finance database.
==> SELECT Parent, Child FROM DBC.Children
WHERE Parent = ’Finance’;
Parent Child
Finance Personnel
Finance Jones
Finance Accounting
Collations
The Collations view provides definitions for standard Swedish and Norwegian
collations as well as custom collation sequence definitions. The Collations view
provides a view on all columns of the DBC.CollationTbl.
Usage Notes
The DBC.Collation table initially contains two rows, SWEDISH_STANDARD
and NORWEGIAN_STANDARD. Database administration can redefine the
MULTINATIONAL collation sequence to meet other specific language collation
needs.
Using the MULTINATIONAL option, for example, in SET SESSION
COLLATION MULTINATIONAL, is the same. The final collation order,
however, is changed according to the defined collation sequence.
Database administration runs the CollInstallMulti macros to set the collation
sequence to MULTINATIONAL, SWEDISH_STANDARD, or
NORWEGIAN_STANDARD. The Teradata RDBMS must be reset (initialized)
before the new collation sequence can take effect.
When you define a new collation with a name other than ’MULTINATIONAL’,
you should set the CollInstall flag to N to avoid extra processing during
startup.
Example
The following statement returns the collation information for all collation
sequences defined in the collation table:
SELECT CollName
FROM DBC.Collation ;
The result is the following list:
CollName
SWEDISH_STANDARD
NORWEGIAN_STANDARD
MULTINATIONAL
Columns[X]
The Columns view provides information from the DBC.TVFields table about
stored procedures, join indexes, the parameters of macros and stored
procedures, and the columns of any table or view that the user owns or has
SELECT privileges on.
Usage Notes
When querying DBC.Columns for a view, information on column attributes
(length, type, etc.) will be null. Because column attributes correspond to the
table for which they were defined, they are not stored in the dictionary and are
not accessible through this view. Information on the columns of views can be
obtained with the HELP COLUMN statement.
Example 1
This example shows a statement that selects from DBC.Columns the name,
format, null status, and data type of all columns in the Personnel.Employee
table:
==> SELECT ColumnName,ColumnFormat,Nullable,ColumnType
FROM DBC.Columns WHERE DatabaseName=’Personnel’
AND TableName = ’Employee’;
EmpNo 9(5) N I
Name X(12) N CV
DeptNo 999 Y I
JobTitle X(12) Y CV
Salary zzz,zz9.99 Y D
YrsExp z9 Y I
. . . .
. . . .
. . . .
Example 2
This example shows a statement that selects any available commentary about
columns in the Employee table:
==> SELECT ColumnName,CommentString FROM DBC.Columns
WHERE DatabaseName=’Personnel’ AND
TableName=’Employee’
ORDER BY Columnid;
ColumnName CommentString
ColumnStats
This view helps obtain statistical information on the columns of a table, for
which the statistics are available.
When statistics are collected on a column of a data table, the information is
saved into DBC.TVFields.FieldStatistics. The dictionary table TVFields is not
accessible to PUBLIC. Through this view, all users can access the column
statistics.
Usage Notes
This view is used by the client tools Teradata System Emulation Tool (TSET)
and Teradata Visual Explain, besides any client application that requires the
statistical information. TSET exports the statistical information for data tables
as part of Target Level Emulation.
The information returned includes the Field Statistics for each column, table
name and database name, and the sequence number of the column. The
SeqNumber is derived from the FieldID. The output is sorted in the order of the
SeqNumber.
Example
The following statement selects statistical information about the columns in the
table ‘Query’, provided that the statistics have been collected:
==> SELECT *
FROM DBC.ColumnStats
WHERE DatabaseName = 'QCD'
AND
TableName = 'Query'
ORDER BY SeqNumber;
Databases[X]
The Databases view provides information about both databases and users from
the DBC.DBase table.
Usage Notes
The indicators in the JournalFlag column depend on the following:
• the FALLBACK and JOURNAL settings for the database, which serve as the
default for all tables created in that database
• any FALLBACK and JOURNAL settings defined in the CREATE TABLE
and ALTER TABLE statements
Settings defined for an individual table override the database defaults.
Example
The statement shown in the following screen selects information about the
Personnel database.
==> SELECT AccountName,ProtectionType,PermSpace,SpoolSpace
FROM DBC.Databases WHERE DatabaseName = ’Personnel’;
Databases2
Usage Notes
The Databases2 view is similar to the Databases view but, for access control
purposes, returns the ID of the database instead of the various names other
information associated with the database. See the columns of the Databases
view for comparison.
The administrator can control who has access to internal ID numbers by
limiting the access to the Databases2 view while allowing more (or all) users to
access the names via the Databases view.
Database_Default_Journals[X]
Usage Notes
A journal table does not need to reside in the database which it serves.
Example
The following SELECT statement selects the information on each database
accessible by the requesting user for which a default journal table is defined.
==> SELECT * FROM DBC.Database_Default_JournalsX;
DBCInfo
Usage Notes
Two attributes are maintained in DBCInfo. They are:
• VERSION—Version of the software currently running on the Teradata
RDBMS
• RELEASE—Release level of the software currently running on the Teradata
RDBMS
Example
The following SELECT statement retrieves the version and release of the
current Teradata RDBMS software.
InfoKey InfoData
VERSION V2R.nn.nn.nn.nn
RELEASE nn.nnx.nn.nn
DeleteAccessLog[X]
Usage Notes
The access log contains entries according to the application of the access
logging rules (see “AccessLog” and “AccLogRules”).
The DeleteAccessLog view purges entries from the log that are more than 30
days old.
The view also may be used to display information about records that are
eligible for deletion before the delete operation is performed.
Example
The following SELECT statement deletes entries logged against databases
owned by the requesting user that were entered more than 30 days before the
current calendar date.
==> DELETE FROM DBC.DeleteAccessLogX ALL;
DeleteOldInDoubt
Usage Notes
The DeleteOldInDoubt view purges entries from the in-doubt transaction log
that are more than 30 days old. Before a delete operation is performed the view
may also be used to display information about records eligible for deletion.
Example
The following statement deletes entries logged against in-doubt transactions
that were entered more than 30 days before the current calendar date.
==> DELETE FROM DBC.DeleteOldInDoubt ALL;
DiskSpace[X]
Usage Notes
When a database or user is created, allocated disk space is divided evenly
among all AMPs. The DiskSpace view returns one row of usage information for
each AMP in the Teradata RDBMS (or for all AMPs if the SUM aggregate is
used).
When a database is created, a space row is added on each AMP, with the
processor field in each row initialized to 0. The first time the space row is
updated, such as when a table is created in the database or the system is
restarted, the processor field in each row is updated to reflect the actual
processor number.
You can use the DiskSpace view to build and maintain a table of disk space
usage statistics for each username/accountname.
To create the history table, enter the following statement:
CREATE TABLE DiskSpaceHist ( DataBaseName VARCHAR(30),
AccountName VARCHAR(30),
MaxPerm FLOAT,
MaxSpool FLOAT,
CurrentPerm FLOAT,
PeakPerm FLOAT,
PeakSpool FLOAT,
CollectDate DATE,
CollectTime FLOAT )
PRIMARY INDEX (DataBaseName, AccountName);
Periodically, you can collect usage statistics using the following procedure:
Step Action
1 Select statistics from the DiskSpace view and insert them in the history table.
Note: The maximum and peak DiskSpace counters are reset to zero using the
ClearPeakDisk macro, which is provided on the release tape. Execute the
ClearPeakDisk macro provided in the Teradata RDBMS Data Dictionary, to
reset to zero the maximum and peak DiskSpace counters.
This procedure can be carried out using the following BTEQ script.
.LOGON username, password
EXECUTE DBC.ClearPeakDisk;
.QUIT
Example
The following SELECT statement displays the permanent disk space across all
AMPs.
==> SELECT DISTINCT AMP,DatabaseName,CurrentPerm,MaxPerm FROM
DBC.DiskSpace;
. . . .
0-0 stst14 0 125,000
0-0 ud12 0 125,000
1-0 atest 1,536 125,000
1-0 a1 0 247,500
1-0 btest 3,584 5,000
1-0 b2test 49,664 250,000
. . . .
. . . .
1-1 atest 1,536 125,000
1-1 a1 0 247,500
1-1 btest 3,584 5,000
1-1 b2test 50,688 250,000
. . . .
. . . .
1-2 atest 1,536 125,000
Events[X]
Usage Notes
The Events view returns a row for each archive or recovery activity. The types
of event rows are as follows:
• Checkpoint Event Row—A row is created for each journal checkpointed.
• Delete Event Row—A row is created for each journal deleted.
• Dump Event Row—A row is created for each database or table dumped.
• Restore Event Row—A row is created for each database or table restored.
• Rollback Event Row—A row is created for each database or table rolled
back.
• Rollforward Event Row—A row is created for each database or table rolled
forward.
The Events view contains the following standard and optional fields:
EventNum DataSetName
CreateDate TableName,
CreateTime CheckpointName
UserName LinkingEventNum
EventType LockMode
DatabaseName JournalUsed
ObjectType JournalSaved
AllAMPsFlag IndexPresent
RestartSeqNum DupeDumpSet
OperationInProcess
The CreateDate and CreateTime fields are updated by the PE on which the
session is running; thus, all events for a given session are timestamp-ordered.
However, if multiple or concurrent sessions are running on different PEs, any
discrepancy in AMP clocks may be reflected in the timestamp sequence. This
may also occur if a Teradata RDBMS connects to more than one client system
and the client system clocks are not synchronized.
Example
The following SELECT statement selects information associated with the
requesting user from the DBC.EventsX view.
==> SELECT CreateDate, CreateTime, EventType, JournalUsed FROM
DBC.EventsX;
Events_Configuration[X]
Usage Notes
The Events_Configuration view contains rows for each archive activity that
does not affect all AMPs in the Teradata RDBMS configuration.
If the activity is for all AMPs and there are AMPs off-line, a row is inserted for
each off-line AMP. If the activity is for specific AMPs, a row is inserted for each
AMP that is specified and on-line.
The CreateDate and CreateTime fields are updated by the PE on which the
session is running; thus, all events for a given session are timestamp-ordered.
However, if multiple or concurrent sessions are running on different PEs, any
discrepancy in AMP clocks may be reflected in the timestamp sequence. This
may also occur if a Teradata RDBMS is connected to more than one client
system and the client system clocks are not synchronized.
Example
The statement on the following screen selects information concerning the
requesting user from the DBC.Events_ConfigurationX view.
==> SELECT CreateDate, CreateTime, EventNum, EventType
FROM DBC.Events_ConfigurationX;
Events_Media[X]
Usage Notes
The CreateDate and CreateTime fields are updated by the PE on which the
session is running; therefore, all events for a given session will be
timestamp-ordered. However, if multiple or concurrent sessions are running on
different PEs, any discrepancy in AMP clocks may be reflected in the
timestamp sequence.
This may also occur if a Teradata RDBMS is connected to more than one client
system and the client system clocks are not synchronized.
Example
In this example, the requesting user is researching the Events_Media view for
events associated with the user named ’PAL’.
==> SELECT DataSetName,VolSerialId,DupeDumpSet
FROM DBC.Events_Media WHERE UserName = ’PAL’ ;
BRM.DBC.TEXT1 000469 N
BRM.DBC.TEXT1 000469 N
BRM.DBC.TEXT2 000469 N
BRM.DBC.TEXT2 000469 N
BRM.DBC.TEXT1 BRM001 Y
BRM.DBC.TEXT1 BRM002 Y
BRM.DBC.TEXT2 BRM001 N
BRM.DBC.TEXT2 BRM002 N
Hardware_Event_Log
Usage Notes
Returned information from this view can help to diagnose where the failure
may originate for different types of events.
HostsInfo
The HostsInfo view displays information about any user-defined character sets
assigned by the Teradata RDBMS system administrator as the default for the
client systems in the Teradata RDBMS configuration (also see the “CharSets”
and “CharTranslations”).
Usage Notes
If this view does not exist or no rows are found, the default character set of each
logon client system is in effect.
Example
The following SELECT statement selects any character sets assigned by the user
as the defaults for the client systems in the Teradata RDBMS configuration.
==> SELECT * FROM DBC.HostsInfo;
136 VM Norwegian_EBCDIC
137 LAN ASCII
Indices[X]
The Indices view provides information about each indexed column from the
DBC.Indexes table.
Usage Notes
One row is returned from the Indices view for each column in each index.
Therefore, a query on an index made up of multiple columns will return
multiple rows.
Example
The following SELECT statement displays index information for all the tables
in the Personnel database.
==> SELECT TableName,ColumnName,ColumnPosition,IndexType,
UniqueFlag FROM DBC.Indices
WHERE DatabaseName= ’Personnel’
ORDER BY TableName,ColumnPosition ;
Charges Proj_id 1 S N
Charges EmpNo 1 P N
Charges Proj_id 2 P N
Department DeptNo 1 P Y
Employee EmpNo 1 P Y
Employee Name 1 S N
Project Proj_id 1 P Y
IndexStats
This view helps obtain statistical information on the indexes defined on a table,
for which the statistics are available.
When statistics are collected on the indexes of a data table, the information is
saved into DBC.Indexes.IndexStatistics. The dictioanry table Indexes is not
accessible to PUBLIC. Through this view, all users can access the index
statistics.
Usage Notes
This view is used by the client tools Teradata System Emulation Tool (TSET)
and Teradata Visual Explain, besides any client application that requires the
statistical information.
The information returned includes the Index statistics, table name and database
name, and the index number. The output is sorted in the order of the index
number.
Example
The following statement selects statistical information about the indexes on the
table T1.
==> SELECT *
FROM DBC.IndexStats
WHERE DatabaseName = 'Test'
AND
TableName = 't1'
ORDER BY IndexNumber;
D10706130F271613
0100000000000000
0000000012000100
00000000000 TEST T1 4
InDoubtLog
Journals[X]
The Journals view provides information about the journal table for each data
table that uses journal protection. The restricted version of the view displays
only those objects that the requesting user either owns or holds access rights to.
Example
The statement on the following screen selects information from the Journals
view for the table named PriceA.
==> SELECT TableName,Tables_DB,Journals_DB,JournalName
FROM DBC.Journals WHERE Tablename = ’PriceA’ ;
LogOnOff
The LogOnOff view supplies information about logon and logoff activity,
including attempted logons.
Usage Notes
Event data is useful in determining why a logon attempt was not successful.
Information about logon and logoff activity is also maintained on the client
system.
LogonSource Example
The following example shows logons from both network-attached and channel-
attached clients:
LogonSource Values
Logons from network- (TCP/IP) C079 153.64.69.48 756 01 LSS
attached clients (TCP/IP) A401 153.64.69.48
Example
The following SELECT statement displays information about the logon and
logoff activity of a specific user for a particular date:
Additional Information
See Teradata RDBMS Database Design for more information on controlling
access, space, and ownership.
LogonRules
Usage Notes
The LOGON rules can be used to redefine the Teradata RDBMS defaults. See
"GRANT LOGON" documentation for more information.
The initial defaults are that all users can log on from all client systems and that
every logon string must contain a password.
In V2R4.1, Teradata RDBMS, running on Windows 2000, provides the
capability of integrating with the Windows logon, so that users only need to
identify themselves to Windows. Teradata RDBMS can then use this
information to log clients on. Single Sign On is enabled by granting permission
to log on "with null password" from the appropriate network, identified by host
ID.
RCC_Configuration[X]
The RCC_Configuration view is the product of a join on the Events table and
the Configuration table (see “Events[X]” and “Events_Configuration[X]”). It
provides information about checkpoint statements and client system utility
functions that did not affect all AMPs.
Usage Notes
The RCC_Configuration view contains rows for each client system utility
function or CHECKPOINT statement that was executed on a subset of the AMP
processors.
Example
The following SELECT statement selects event and processor information from
the RCC_Configuration view.
==> SELECT EventNum, LogProcessor, PhyProcessor
FROM RCC_Configuration;
RCC_Media[X]
The RCC_Media view is produced by a join on the Events table and the Media
table. It provides information about a client system utility dump or restore
function that created or used removable media.
Example
The following SELECT statement selects all rows and all columns from the
RCC_Media view.
==> SELECT * FROM DBC.RCC_Media;
21 KAZ002 1 N
76 RDB003 1 N
66 RDB007 1 N
19 KAZ002 1 N
66 RDB008 2 N
37 MET001 1 N
77 RDB003 1 N
. . . .
. . . .
RI_Child_Tables
Usage Notes
The RI_Child_Tables view is similar to the All_RI_Children view but returns
the IDs of databases, tables, and columns instead of the names for access
control purposes. The administrator can control who has access to internal ID
numbers by limiting the access to the RI_Child_Tables view while allowing
more (or all) users to access the names via the All_RI_Children view.
RI_Distinct_Children
RI_Distinct_Parents
RI_Parent_Tables
Usage Notes
The RI_Parent_Tables view is similar to the All_RI_Parents view but returns the
IDs of databases, tables, and columns instead of the names for access control
purposes.
The administrator can control who has access to internal ID numbers by
limiting the access to the RI_Parent_Tables view while allowing more (or all)
users to access the names via the All_RI_Parents view.
SecurityDefaults
The SecurityDefaults view describes the password features selected for the site.
Additional Information
For more information on controlling access, space, and ownership, see the
following manuals:
• Teradata RDBMS Database Design
• Teradata RDBMS Security Administration
• Teradata RDBMS Database Administration
SecurityLog[X]
Note: Note that the column named DatabaseName was previously named
ObjectName.
Usage Notes
For an explanation of the BEGIN/END LOGGING statements, please refer to
Teradata RDBMS SQL Reference.
SessionInfo[X]
The SessionInfo view provides information about users who are currently
logged on.
Usage Notes
Information about current session pools, which are a collection of sessions that
are logged on to the Teradata RDBMS under the same logonid, may be accessed
by entering the DISPLAY POOL command.
Example
The following SELECT statement displays information on all current sessions.
==> SELECT UserName, SessionNo, DefaultDatabase, LogonSource
FROM DBC.SessionInfo;
LogonSource Example
The following screen displays LogonSource information from the current
sessions:
LogonSource
0438 hex = 1080 decimal <---- winddi via ODBC from TD Manager
0448 hex = 1096 decimal <---- dmteq PID = 251 from PC
0491 hex = 1169 decimal <---- bteq PID = 893 from unix
ShowColChecks
ShowTblChecks
Software_Event_Log
Usage Notes
For Database Query Manager, the following fields are not used:
• Stacktrace
• Error_Data
• Category
• Severity
• PMA
• Vproc
• Partition
• Task
• Function
• SW_Version
Example
The following statement requests the software event log information for any
event with a severity level of 50 (unrecoverable user error, no user restart):
SELECT TheDate, TheTime, Category, Severity
FROM Software_Event_Log
Where Severity = ‘50’ ;
The result has the following form:
TheDate TheTime Category Severity
92/08/20 10:10:30 4 50
Table_LevelConstraints
Tables[X]
The Tables view provides information about tables, views, stored procedures,
join indexes, and macros.
The DBC.TVM table contains one row for each table, view, or macro in the
database.
Corresponding system tables for this view include the following:
• DBC.AccessRights
• DBC.TVM
• DBC.DBase
• DBC.Owners
Usage Notes
The RequestText data reflects the definitions specified by the user. This may not
always match the data returned by the SHOW TABLE statement, which reflects
the reconstructed definitions as they exist in the Teradata RDBMS Data
Dictionary.
For example, when obsolete syntax that is still supported is converted
internally to current syntax, RequestText returns the submitted (obsolete)
syntax, while SHOW TABLE returns the converted (current) syntax.
Example
The following SELECT statement displays information about tables, views, and
macros in the Personnel database.
==> SELECT TableName,CreatorName,TableKind,ProtectionType FROM
DBC.Tables WHERE DatabaseName = ’Personnel’ ;
NewEmp GREENE M F
EmployeeInfo GREENE V F
Employee DBC T F
Department DBC T F
Project JONES T F
Charges JONES T F
Tables2
TableSize[X]
Usage Notes
When a database or table is created, the allocated disk space is divided evenly
among all AMPs. The TableSize view returns one row of usage information for
each AMP in the Teradata RDBMS (or for all AMPs if the SUM aggregate is
used).
Example
The following SELECT statement is used to contrast the total disk space
currently being used by the Employee table with its peak usage figure.
==> SELECT SUM(PeakPerm), SUM(CurrentPerm)
FROM DBC.TableSize WHERE TableName=’Employee’ ;
Sum(PeakPerm) Sum(CurrentPerm)
260,608 260,608
Triggers
Usage Notes
A trigger is defined by a CREATE TRIGGER data modification statement. An
INSERT, UPDATE or DELETE statement on the specified table or view causes
the database to execute the trigger.
Triggers can be of two types: ROW or STATEMENT. When a triggered
statement fires a trigger, cascading ensues that can, in some instances, fire other
triggers and become triggering statements.
The REFERENCING clause must be used when referencing subject tables that
are qualified with old or new table values. In addition, all subject table columns
must use new or old correlation names.
Example 1
The following example defines two triggers on a parent table. These triggers
ensure that the changes made to the parent table are propagated to the child
table.
CREATE TABLE Parent_Tab (PrimKey int, Col2 int, Col3 int);
CREATE TABLE Child_Tab (PrimKey int, ForKey int, Col3 int);
UserGrantedRights
Example
The following SELECT statement displays all rights that the current user has
granted to other users.
==> SELECT DatabaseName,TableName,Grantee,AccessRight
FROM DBC.UserGrantedRights;
UserRights
The UserRights view provides information about objects on which the user has
explicitly or automatically been granted privileges including the following:
tables, views, join indexes, columns, stored procedures, or macros.
Usage Notes
To display the privileges that the user has been granted on database D, the
SELECT statement must specify:
WHERE DatabaseName = ’D’ AND TableName = ’All’ ;
If privileges have been granted on the database, a row is returned for
each privilege.
The UserRights view does not return information about implicit privileges for a
user (for example, the GRANT privilege on each database owned by the user).
Example
The following SELECT statement displays information about all tables in the
Personnel database on which rights were granted to the requesting user.
==> SELECT * FROM DBC.UserRights
WHERE DatabaseName=’Personnel’
AND TableName = ’All’ ;
Users
The Users view provides information about username space that the requesting
user created or owns.
Example
The following SELECT statement displays information about all users owned
or created by the current user, Jones.
==> SELECT UserName,CreatorName,PermSpace,SpoolSpace
FROM DBC.Users;
Additional Information
See Teradata RDBMS Database Design for more information on controlling
access, space, and ownership.
User_Default_Journals[X]
Usage Notes
A journal table need not reside in the user space that it serves.
Example
The following SELECT statement selects information on each user database to
which the requesting user has access, and for which a default journal table is
defined.
==> SELECT * FROM DBC.User_Default_JournalsX;
System Tables
The primary focus of this chapter is to provide a detailed listing of all the
fallback protected system tables of the Data Dictionary including: the columns
returned, the column data types, and the primary and secondary index
columns of each table.
In addition, this chapter explains the use of the DBC.ALL table, the TVM and
TVFields tables, describes the non-hashed non-fallback protected tables, stored
procedures, and briefly describes the ResUsage tables. For a detailed
description of the ResUsage tables, see Teradata RDBMS Resource Usage Macros
and Tables.
The Data Dictionary System tables are generated during system initialization
(SysInit) and/or by the Table Initialization Program. They store information
about the DBC database that can be examined directly or through the system
views.
DBC.ALL Table
The purpose of the DBC.ALL table is provide the user with a table name for a
zero table ID. This can occur when a GRANT is performed to give an access
right on a database without mention of a table. In this case, DBC.ALL will
appear as the table name.
It is necessary for the DBC.ALL table to exist to allow a join between the access
rights tables and the TVM table.
DBC.TVM Table
The DBC.TVM table contains one row for each table, view, trigger, stored
procedure, join index, or macro in the database.
DBC.TVFields Table
The DBC.TVFields table contains one row for each occurrence of the following
in every view and table in the database:
• Column, except when the view contains more than 51 columns
• Join index
• Macro
• Stored procedure
Stored Procedures
The information pertaining to a stored procedure object is stored in the
DBC.TVM, DBC.TVFields, DBC.AccessRights, and DBC.AccLogRulesTbl tables
of the DD.
The column, SPObjectCodeRows, in the DBC.TVM table references information
on the status of the stored procedure. The value of this column indicates the
following stored procedure creation-time attributes:
• Session mode
• Server platform
• Print option
• SPL text storage option
• Teradata Stored Procedure (TDSP) version number
The column SPParameterType in the DBC.TVFields table contains information
on the parameters of the stored procedure. Parameter types for this column
include IN, INOUT, or OUT.
ResUsage Tables
ResUsage tables store data that is gathered from specified data collection and
logging phases of Teradata RDBMS sub-systems. This data is then used by
ResUsage macros to provide resource usage statistics. User-written queries or
macros may also be used to generate reports from this data.
ResUsage tables, primarily of interest to NCR development, support, and field
engineers, are described in appendices of Teradata RDBMS Resource Usage
Macros and Tables.
Non-Hashed Tables
The following table lists and describes the non-hashed and NO FALLBACK
Data Dictionary Tables:
Only tables without suffixes are used by the RDBMS (for example,
DBC.AcccessRights; therefore, only tables without suffixes are covered in this
chapter.
Tables with suffixes (for example, DBC.AcccessRights_V2R2), are not used by
the RDBMS and are not covered in this chapter.
The following table lists all of the FALLBACK protected tables of the system
DBC, except for the ResUsage tables that are explained in detail in the Teradata
RDBMS Resource Usage Macros and Tables book.
Unique Primary Indexes (UPIs), Non-Unique Primary Indexes (NUPIs),
Unique Secondary Indexes (USIs) and Non-Unique Secondary Indexes (NUSIs)
are indicated for each table.
Macros
In order to load macros and other views, specific SQL scripts must be executed
using the DIP utility. Examples of these include the DIPSYSFE utility for SQL
scripts for System FE Macros and the DIPRUM utility for SQL scripts for
ResUsage macros.
In order to load all the views, tables, and macros, the DIPALL script must be
run.
This chapter contains information about the following system macros:
• TwoPCRule macro
• ResUsage macros
• DIPVIEW macros
The following macros are not covered in this manual:
TwoPCRule Macro
Note: The TDP userid in the preceding CREATE and GRANT statements can
be changed with the INITIAL USER clause in the TDP parameter dataset.
Note: The CREATE USER statement for the TDP userid must include the
ACCOUNT=$H priority attribute.
ResUsage Macros
Like other Teradata RDBMS macros, ResUsage macros consist of one or more
Teradata Structured Query Language (SQL) statements stored in the Teradata
RDBMS and executed by a single EXECUTE statement.
Usage Notes
ResUsage macros allow you to analyze key operational statistics, ResUsage
data, that you can use to evaluate the performance of your system. You must
have the EXECUTE privilege to use this macro.
In addition to the name of the macro, the EXECUTE statement for ResUsage
macros can include optional parameters to specify the following:
• Starting and ending dates and times
• Starting and ending nodes of a range of nodes
• A specific single node
Example
The following statement executes the ResCPUByAMP macro, producing a
report for the period beginning 8:00 a.m. on December 25, 1997, and ending
12:00 p.m., midnight, on December 31, 1997. It includes data for nodes 123-02
through 125-04.
EXECUTE ResCPUByAmp('1997-12-25', '1997-12-31', '08:00:00',
'24:00:00', '123-02', '125-04');
where:
DIPVIEW Macros
This section provides a brief description of each of the above macros including
any necessary parameters. If you need to see the macro itself, refer to the
DIPVIEW script.
ARC_NonEmpty_List Macro
This macro returns the names of the databases or users, owned by the indicated
database, that contain the specified objects.
Parameter Description
ParentDb This parameter is the name of the database containing the objects
returned by this macro.
TKinds (VARCHAR(100), UPPERCASE) )
This parameter indicates the types of tables returned.
The possible values include the following:
Value Meaning
T Table
V View
M Macro
J Journal
I Join Index
P Stored Procedure
G Trigger
Usage Notes
Although this macro is designed for the person responsible for archiving data,
its access rights are PUBLIC.
The macro can return database names for which the executing user does not
have access rights.
Example
The following statement returns the names of the tables, journals, join indexes,
views, and macros in the NewEmp2 database:
EXEC DBC.ARC_NonEmpty_List (NewEmp2, ‘TJIVM’);
ClearAccounting Macro
This macro resets the CPU and IO columns of the DBC.Acctg table.
Usage Notes
This macro resets resource usage counters back to zero.
Examples
The following example shows the definition of the ClearAccounting macro:
REPLACE MACRO DBC.ClearAccounting
AS ( UPDATE Acctg SET CPU = 0, IO = 0 ALL;
UPDATE Acctg SET CPU = 0, IO = 0 ALL; );
The following scenarios illustrate how the ClearAccounting macro can be used:
ClearPeakDisk Macro
This macro resets to zero the following columns of the DISKSPACE
information:
• PEAKPERM
• PEAKSPOOL
• PEAKTEMP
Usage Notes
You are able to determine the maximum amount of permanent space, the
maximum amount of spool space, and the maximum amount of temporary
space used at any one time by the database for a specified AMP (or all AMPs if
the SUM aggregate is specified) since the last time the ClearPeakDisk macro
was run.
Example
To run the ClearPeakDisk macro, issue the following:
EXEC DBC.ClearPeakDisk();
CollAddStandard Macro
This macro defines the standard collation sequences supplied with the Teradata
RDBMS and places them into the DBC.CollationTbl.
Usage
If the existing standard collations in the DBC.TranslationTbl have been
corrupted or removed, this macro replaces them. Also, when we provide
additional standard collations, you can add them using this macro.
Example
The following macro places the supplied collations into DBC.CollationTbl:
EXEC DBC.CollAddStandard();
CollInstallMulti Macro
This macro installs an NCR-supplied standard collation or a user-defined
collation from the DBC.CollationTbl as the definition for Multinational
collation.
This macro has the following parameter.
Parameter Description
Usage Notes
The name assigned to the collation can be any valid name except
“MULTINATIONAL.”
To install the supplied standard collation, you must run the macro
DBC.CollAddStandard before you run the CollInstallMulti macro.
You must run this macro before any users have logged onto the system. The
redefinition of Multinational collation takes effect after a full Teradata RDBMS
restart.
Example
The following statement redefines the Multinational collation sequence as the
SWEDISH_STANDARD collation:
EXEC DBC.CollInstallMulti (‘SWEDISH_STANDARD’);
This next statement redefines the Multinational collation sequence as the
user-defined collation, “MULTINATIONAL_USER”:
EXEC CollInstallMulti (‘MULTINATIONAL_USER’);
DIPMarkNS10 Macro
The DIPMarkNS10 macro is an empty, parameterless macro in database DBC
which acts as a release marker to indicate a valid dictionary.
The Teradata RDBMS uses the presence or absence of this macro to determine
whether a conversion originates from an NCR System 3600 or DBC/1012 to the
Teradata RDBMS.
Usage Notes
When you restore database DBC from an NCR System 3600 or DBC/1012 to the
Teradata RDBMS, the DIPMarkNS10 macro is deleted before the conversion
begins and is recreated at the end of the conversion process.
If the conversion was not successful, the macro is not created, and you see a
message instructing you to run the necessary conversion script.
LogonRule Macro
This macro determines who has execute privileges for the GRANT/REVOKE
LOGON statements.
When database administration grants the execute privilege on this macro to a
user, that user can then use the GRANT/REVOKE logon statements.
See Teradata RDBMS Security Administration for complete information on using
this macro.
Many additional macros exist for determining system efficiency. These resource
usage macros are described in Teradata RDBMS Resource Usage Macros and
Tables.
K M
Keywords Macro
special Data Dictionary DBC.AccLogRule
ALL 1–14 auditing access 1–9
DEFAULT 1–14 Macros
PUBLIC 1–14 ARC_NonEmpty_List 5–4
Kind column 2–47 ClearAccounting 5–5
ClearPeakDisk 5–6
CollAddStandard 5–6
CollInstallMulti 5–7
U
UniqueFlag column 2–65
UnnamedTblCheckExist column 2–65
UnResolvedReferences tabl 4–40
UnResolvedRICount column 2–66
UpperCaseFlag column 2–66
Usage statistics
compiling 1–22