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

Teradata RDBMS Database Administration - NCR

NCR Teradata RDBMS Database Administration - NCR , 2004. - 616 p.
Download (direct link): teradatadatabaseadmin2004.pdf
Previous << 1 .. 58 59 60 61 62 63 < 64 > 65 66 67 68 69 70 .. 218 >> Next

Overview of the Data Dictionary

How the Data Dictionary tables are protected

How to use the system views

Data Dictionary timestamping

How to maintain certain Data Dictionary tables and views

For more information on Data Dictionary tables and macros mentioned in this chapter, see Teradata RDBMS Data Dictionary.

Teradata RDBMS Database Administration

3 - 1 Chapter 4: Using Data Dictionary Tables and Views

Protected Data Dictionary Tables

Data Dictionary Overview

Data dictionary tables are present when you install the system. The system references some of these tables with SQL requests, while others are used for system or data recovery only. Data dictionary views reference data dictionary tables. Views and macros are created by running Database Initialization Program (DIP) scripts.

Some main points to remember about the data dictionary are:

The data dictionary consists of tables, views, and macros stored in user DBC.

Data dictionary tables store information about all created objects (except volatile temporary tables), including, for each object, the:

Ownership hierarchy

Implicitly and explicitly granted rights

Type (for example, parent or child)

Teradata RDBMS automatically updates the dictionary tables as you and other users create, modify, alter, or drop objects, and grant or revoke rights

You can access data dictionary tables with the system views created by DIP.

To access information about an object definition (such as a table or view) or content (such as a database), use the SHOW or HELP command.

To access information by object type, query the views.

This data dictionary component ... Contains .
data dictionary tables Object definitions, parameters, and/or attributes System event logs System message table Restart control tables and recovery journals Accounting information Access control tables
views of data dictionary tables Administrative Security Supervisory End User Operational
macros Generate utilization reports Reset accounting values Authorize secured functions

4 - 2

Teradata RDBMS Database Administration 4 - 13 Chapter 4: Using Data Dictionary Tables and Views

Protected Data Dictionary Tables

Protected Data Dictionary Tables

Fallback Protected Data Dictionary Tables

Most data dictionary tables are fallback protected.

Fallback protection means that a copy of every table row is maintained on a different AMP in the configuration. Fallback-protected tables are always fully accessible and are automatically recovered by the system.

Every database and user includes a dummy table named "ALL" (with an internal tableID of binary zeros). This table represents all the tables in a database or user when, for example, privileges are granted or disk space is summarized at the database level.

Non-Hashed Data Dictionary Tables

Some data dictionary tables contain rows that are not distributed using hash maps. Rows in these tables are stored AMP-locally. For example, the TransientJournalTable rows are stored on the same AMP as the row being modified.

User-defined table rows are always hash distributed, either with or without a fallback copy.

Teradata RDBMS Database Administration

4 - 13 Chapter 4: Using Data Dictionary Tables and Views

Protected Data Dictionary Tables

Updating Data Dictionary Tables

Whenever you submit a data definition (DDL) or data control (DCL) statement, Teradata system software automatically updates data dictionary tables.

For example, the name of the creator of another user or role, profile, database, table, or any other object, as well as the grantor, grantee, right and object or role granted, and the date and time the CREATE or GRANT statement was processed, are all recorded.

Dropping User Defaults

DROP statements also are recorded. However, the result of a DROP PROFILE, DROP DATABASE, or DROP ROLE statement is not cascaded to the user rows in DBC.Dbase, so the corresponding default setting for each affected user is not reset to NULL. When an affected user next logs on, no error or warning will be returned.

If you drop a default database, role, or profile, the default for each affected user is handled as follows:

I IF the dropped object is a . THEN Teradata .

default database uses the username space by default.

The user can use the SET SESSION DATABASE statement to reset the default during a session.

default role no longer uses that role by default for access rights checking

when the user logs on.

The user is still a member of the role and can use the SET ROLE statement to reactivate the role during a session

Note: .Use REVOKE to remove one or a few users from the membership of a role. Use DROP ROLE to remove all I members from a role.

profile uses by default the:

ACCOUNT, SPOOL, TEMP, and DEFAULT DATABASE specifications in the CREATE USER or latest MODIFY USER statement

Previous << 1 .. 58 59 60 61 62 63 < 64 > 65 66 67 68 69 70 .. 218 >> Next