Teradata 2800 Data Warehouse Appliance Implementation Guide

From an administrative client configured in Chapter 4: “Setting Up Teradata Clients,” log

Security Administration, B035-1100

160 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

Creating User DBADMIN

on to Teradata Administrator as user DBC.

Create the database administrator as follows:

a b

From the menu, click Tools>Create>User.

Specify values for the following fields and controls:

Note: Do not enter values at this time for fields not listed.

Field

User Name

Owner

Password

Description

Required. The name of the database administrator user.

Recommendation: All administrative procedures in this publication use the name DBADMIN for the principal administrator.

The owner of user DBADMIN, that is, DBC.

Required. The temporary password for DBADMIN.

Recommendation: Any simple password will work that follows the default system password controls. Each user is prompted to change the temporary password to a permanent, private password at first logon.

Note: Be sure to review the default password control values to determine whether they conform to your site security requirements.

For information on password control options, see Security Administration,

B035-1100.

Permanent

Space

Spool Space Optional. The spool space specification is only a limit to the amount of space available for intermediate query results or formatted answer sets to queries and volatile tables. The system borrows spool space for a user from unused permanent space anywhere in the system.

Recommendation: Spool space specification is not normally needed. Spool is already allocated in the DBADM profile.

Default

Database

Required. The space in bytes that contains all objects that user DBADMIN creates or owns. Because user DBADMIN will create and own nearly all Teradata databases and tables, assign it the majority of space on the system.

Recommendation: 60-65% of available system (DBC) space. For information

on how to determine DBC space, see step 1 on page 155

Profile

Optional. The user or database containing the space in which the Teradata

Database stores or searches for new or target objects unless a different database is specified in the transaction SQL.

Recommendation: Specify DBADMIN.

Required. The name of the profile in which the user has membership. A user can be a member of only one profile.

Recommendation: Enter DBADM, the profile created for user DBADMIN in

“Creating the DBADM Profile” on page 158 .

Teradata Data Warehouse Appliance 2800 Implementation Guide 161

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

Field

FALLBACK

Description

Optional. Specification of FALLBACK automatically creates a duplicate of each table stored in the user space, in addition to the duplicates already created by disk mirroring, to which the system can revert in the event of a failure.

Recommendation: Uncheck Fallback. FALLBACK is only recommended for individual mission-critical tables or tables so large that their size prevents timely backup to tape or external disk.

Note: You can adjust the space assignments if required, using the Modify User GUI.

Click Create.

The Query Window pops up and displays the generated CREATE USER statement, for example:

CREATE USER "DBADMIN" FROM "DBC"

AS PERM = perm_space

PASSWORD = "temp"

SPOOL = spool_space

PROFILE = DBADM

STARTUP = ''

NO FALLBACK

NO BEFORE JOURNAL

NO AFTER JOURNAL

Note: Some options appear in the SQL that are not specified in the procedure. These are system defaults and should remain as they are. For example Before Journal and

After Journal are checked No by default.

From the Query window, click the Run Query button .

Close the Query window and the Create User dialog box.

Keep the Teradata Administrator utility open for use in the

“Granting Database Privileges to User DBADMIN” on page 163 , or close the utility by clicking File>Exit.

Note: After you create the administrative user DBADMIN, do not log on as user DBC to perform subsequent administrative activities except during activities that only user DBC can perform.

162 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

Reference Information

Reference topics are arranged according to the first step in which the topic appears.

For step...

Information on...

1 log on to Teradata Administrator

2 user types and characteristics syntax and options for the

CREATE USER statement guidelines for managing of space

Is available in...

“Configuring Default Administrative Settings” on page 151

Chapter 5: “Creating Users and Granting

Privileges,” in Security Administration, B035-

1100

SQL Data Definition Language Syntax and

Examples, B035-1144

Chapter 4: “Space,” in Database Administration,

B035-1093

Chapter 6: “Managing Database Passwords,” in

Security Administration, B035-1100 the default password control values and how to change them

Granting Database Privileges to User DBADMIN

Log on to Teradata Administrator as user DBC.

Grant object access privileges to system tables and other objects owned by user DBC.

From the main window, click Tools>Grant/Revoke>Object Rights.

Specify values for the following fields:

Field

Database Name

Object Type

To/From User

Normal

Grant

Description

The name of the user or database that owns the objects on which the privileges are being granted.

Select DBC from the Database Name drop-down list.

The object on which the privileges are given.

Select Database from the Object Type drop-down list.

The name of the user that receives the privileges.

Select DBADMIN from the To/From User drop-down list.

Specifies the privileges granted to the user. Check the following boxes:

•

Execute

•

Select

Specifies that the user is granted the WITH GRANT OPTION privilege, that is the user can grant the privileges to other users.

Check the Grant box.

Click the Grant button.

Teradata Data Warehouse Appliance 2800 Implementation Guide 163

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

The Query window appears and displays the generated GRANT statement:

GRANT EXECUTE, SELECT ON "DBC" TO "DBADMIN" WITH GRANT OPTION.

3 d a

From the Query window, click the Run Query button .

Close the Query window.

Grant object-level database privileges to the database administrator on all objects subsequently created in DBADMIN space.

From the main window, click Tools>Grant/Revoke>Object Rights.

Specify values for the following fields:

Field

Database Name

Object Type

To/From User

All

Grant

Description

The name of the user or database that owns the objects on which the privileges are being granted.

Select DBADMIN from the Database Name drop-down list.

The object on which the privileges are given. Includes all databases and all objects created in the database(s).

Select Database from the Object Type drop-down list.

The name of the user that receives the privileges.

Select DBADMIN from the To/From User drop-down list.

Specifies all rights for all objects created in DBADMIN space.

Check the All box.

Specifies that the user is granted the WITH GRANT OPTION privilege, that is the user can grant all included privileges to other users.

Check the Grant box.

Click the Grant button.

The Query window appears and displays the generated GRANT statement.

GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, STATISTICS, DUMP,

RESTORE, CHECKPOINT, SHOW, EXECUTE PROCEDURE, ALTER PROCEDURE,

EXECUTE FUNCTION, ALTER FUNCTION, ALTER EXTERNAL PROCEDURE, CREATE

OWNER PROCEDURE, CREATE TABLE, CREATE VIEW, CREATE MACRO, CREATE

DATABASE, CREATE USER, CREATE TRIGGER, CREATE PROCEDURE, CREATE

FUNCTION, CREATE EXTERNAL PROCEDURE, CREATE AUTHORIZATION, DROP

TABLE, DROP VIEW, DROP MACRO, DROP DATABASE, DROP USER, DROP

TRIGGER, DROP PROCEDURE, DROP FUNCTION, DROP AUTHORIZATION ON

"DBADMIN" TO "DBADMIN" WITH GRANT OPTION;

4 d

From the Query window, click the Run Query button .

Close the Query window.

Grant object-level privileges on DBC tables and views to DBADMIN.

164 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

a b

From the main window, click Tools>Grant/Revoke>Object Rights.

Specify values for the following fields:

Field

Database Name

Object Type

To/From User

Access

Grant

Description

The name of the user or database that owns the objects on which the privileges are being granted.

Select DBC from the Database Name drop-down list.

The object on which the privileges are given. Includes all databases and all objects created in the database(s).

Select Database from the Object Type drop-down list.

The name of the user that receives the privileges.

Select DBADMIN from the To/From User drop-down list.

Specifies privileges for all DBC tables and views.

Check the Access box.

Specifies that the user is granted the WITH GRANT OPTION privilege, that is the user can grant all included privileges to other users.

Check the Grant box.

Click the Grant button.

The GRANT statement generates and automatically submits the following SQL statements without previewing them.

GRANT EXECUTE, SELECT, STATISTICS, SHOW ON "DBC" TO "DBADMIN" WITH

GRANT OPTION

5 d

From the Query window, click the Run Query button .

Close the Query window.

Grant additional system-level privileges not included with the object-level privileges granted in

step 4 :

Deselect the Preview Mode button at the top of the main screen. The sub-procedure that follows generates a compound SQL statement that cannot be submitted from

Preview Mode.

From the main window, click Tools>Grant/Revoke>System Rights.

Specify values for the following fields:

Field

To/From User

Description

The name of the user that receives the privileges.

Select DBADMIN from the To/From User drop-down list.

Teradata Data Warehouse Appliance 2800 Implementation Guide 165

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

Field

All

Grant

Description

Specifies all rights for all objects created in DBADMIN space.

Check the ALL box.

Specifies that the user is granted the WITH GRANT OPTION privilege, that is the user can grant all included privileges to other users.

Check the Grant box.

Click the Grant button.

The GRANT statement generates and automatically submits the following SQL statements without previewing them.

GRANT MONRESOURCE, MONSESSION, ABORTSESSION, SETSESSRATE,

SETRESRATE, REPLCONTROL, CREATE PROFILE, CREATE ROLE, DROP PROFILE,

DROP ROLE TO "DBADMIN" WITH GRANT OPTION;

GRANT UDTTYPE, UDTMETHOD ON SYSUDTLIB TO DBADMIN WITH GRANT OPTION;

Close the Grant/Revoke System dialog box.

Grant additional system-level privileges not covered by GRANT shown in step 5

Click the Query button, the lowest button on the left edge of the main screen to open the Teradata SQL Assistant query window. This allows you to construct and submit an

SQL statement without using the GUI interface.

Enter the following SQL statement:

GRANT CTCONTROL ON "DBADMIN" TO "DBADMIN" WITH GRANT OPTION;

7 c

Click the Run Query button .

Grant privileges on Sys_Calendar, which contains tables and views for date-related system functions.

Click the Preview Mode button to enable previewing SQL statements before submitting them.

From the main window, click Tools>Grant/Revoke>Object Rights.

Specify values for the following fields:

Field

Database Name

Object Type

Description

The name of the user or database that owns the objects on which the privileges are being granted.

Select Sys_Calendar from the Database Name drop-down list.

The object on which the privileges are given. Includes all databases and all objects created in the database(s).

Select Database from the Object Type drop-down list.

166 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 5: Setting up Administrative Users

Setting Up the Database Administrator User

Field

To/From User

Normal

Grant

Description

The name of the user that receives the privileges.

Select DBADMIN from the To/From User list.

Allows specification of rights for the named objects.

Check the Select, Insert, Update, and Delete boxes.

Specifies that the user is granted the WITH GRANT OPTION privilege, that is the user can grant all included privileges to other users.

Check the Grant box.

Click the Grant button. The Query window appears and displays the generated SQL statement.

GRANT SELECT, INSERT, UPDATE, DELETE ON "Sys_Calendar" TO "DBADMIN"

WITH GRANT OPTION;

8 e a

From the Query window, click the Run Query button .

Close the Query window and the Grant/Revoke Object dialog box.

Click File>Define Data Source. The ODBC Data Source Administrator box appears.

On the System DSN tab select the data source, that is, the system name.

Click the Configure button. The ODBC Driver Setup for Teradata Database dialog box appears.

Change the value of the Username parameter to DBADMIN.

Change the value of the password to the temporary password for DBADMIN specified

in step b of

“Creating User DBADMIN” on page 161 .

Note: User DBADMIN will be prompted to change the temporary password to a permanent, private password at first logon.

Click Yes to store the password, then click OK.

Click OK to exit the ODBC Data Source Administrator dialog box.

Click File>Exit to close Teradata Administrator.

Immediately reopen Teradata Administrator, which logs on to Teradata Database as

DBADMIN using the temporary password specified in Step 9 sub step d

Note: You do not need to execute a GRANT LOGON statement for user DBADMIN or any other user created in the database. All users automatically have the right to log on to the database from any connected client, unless a REVOKE LOGON statement is issued.

When prompted, create a private password for user DBADMIN. This client is now configured for use by user DBADMIN. Conduct all future administrative tasks as user

DBADMIN or another administrative user.

Exit Teradata Administrator by entering File>Exit, or continue to

“Setting Up Database

Administrator Access to Teradata Viewpoint” on page 168

Teradata Data Warehouse Appliance 2800 Implementation Guide 167

Chapter 5: Setting up Administrative Users

Checkpoint

Reference Information

Reference topics are arranged according to the first step in which the topic appears.

For step...

Information on...

Is available in...

logon to Teradata Administrator

“Configuring Default Administrative Settings” on page 151

system tables and views user privileges

Data Dictionary, B035-1092

Chapter 5: “Creating Users and Granting

Privileges” in Security Administration, B035-

1100

SQL Data Control Language, B035-1149 2 through 6 syntax and options for GRANT

(SQL form) and (Role form)

10 password format rules Chapter 6: “Managing Database Passwords,” in

Security Administration, B035-1100

Setting Up Database Administrator Access to Teradata Viewpoint

DBADMIN and other administrative users can benefit from using Teradata Viewpoint to monitor and manage the database during implementation.

Set up administrator client computers as shown in

Clients.”

Chapter 4: “Setting Up Teradata

Create Teradata Viewpoint administrative users and assign roles, as shown in

Teradata Viewpoint Users” on page 287 .

“Setting Up

Checkpoint

Before leaving Chapter 5: “Setting up Administrative Users,” make sure that:



Result

The Teradata Administrator GUI is set up on the principal administrative client.

The PasswordExpire parameter is reset and the database restarted to apply the new values.

Crashdumps has perm space assigned to it.

There is a spool space reserve.

Reference

“Setting Up the Teradata Administrator

GUI” on page 151

“Changing the PasswordExpire

Parameter” on page 153

“Assigning Perm Space to Crashdumps” on page 156

“Creating the Spool Space Reserve” on page 155

168 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 5: Setting up Administrative Users

Checkpoint



Result

An administrative user called DBADMIN, exists in the database and has:

•

A profile

•

The database privileges necessary to carry out database administrator duties

User DBADMIN has access to Teradata

Viewpoint.

Reference

“Setting Up the Database Administrator

User” on page 158

“Setting Up Database Administrator

Access to Teradata Viewpoint” on page 168

If you do not have these results, return to the section in the Reference column and review/ rerun that procedure.

Teradata Data Warehouse Appliance 2800 Implementation Guide 169

Chapter 5: Setting up Administrative Users

Checkpoint

170 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 6

Creating the Database Structure

This section describes the methodology for creating the primary database structure, that is, databases, data tables, and views.

Database Implementation Overview

Create the top-level databases that contain all other database objects. See “Working with

Databases” on page 171 .

Design and create tables to contain data. See

“Working with Tables” on page 179

Design and create views to provide user access to data while limiting access to data tables.

See

“Working with the Basic Teradata Query Utility” on page 195 .

Optionally use the Basic Teradata Query Utility (BTEQ) for database object creation. See

About the Database Structure

In Teradata Database, you must create database objects to contain other objects such as data tables, indexes, views, and macros, as well as users and other lower level databases. The disk space that you assign to a database determines the size and number of objects it can contain.

Databases implicitly own and have privileges on all objects created within their assigned space.

Individual objects contained in a database do not require a space allocation, but you can specify space limits for some objects.

Working with Databases

About Top-Level Databases

To ensure data integrity, Teradata recommends that only administrators and high-level users have the privilege to access data tables. All other database activity should be done in views.

Teradata recommends that you create top-level databases to separate tables and views You can create additional lower level databases within the top-level databases as required by site security policy and user access needs.

Teradata Data Warehouse Appliance 2800 Implementation Guide 171

Chapter 6: Creating the Database Structure

Working with Databases

Database

Tables_Database(s)

Views_Database(s)

Description

•

Owns perm space.

•

Contains all tables and data.

•

Normally accessible only to privileged administrative and batch users for:

•

Creating and modifying database objects

•

Performing data loads and updates

•

Requires minimal perm space because it does not contain data.

•

Contains views of the tables in the Tables_Database.

•

Exists primarily to provide SELECT access to the data for all users.

Note: Where security policy requires it, you can designate a layer of views for load and update operations so that even batch users do not need to directly access data tables.

Creating the Tables Database

Use the following procedure to create the Tables Database that will contain all data tables.

Start Teradata Administrator and log on as user DBADMIN.

From the main screen, click the Preview Mode button to display generated SQL.

Click Tools>Create>Database. The Create Database dialog box appears.

Specify values for the following database parameters.

Syntax Element

Database Name

Owner

Explanation

Required. The name of the master database containing all tables and data.

Recommendation: Use a name that provides a hint about the function of the database, for example, Tables, Tables_Database, or TBL_DB.

Required. The name of the user or database that owns the space in which the object is being created.

Recommendation: Enter the name of the primary administrative user,

DBADMIN, previously set up in “Creating User DBADMIN” on page 161 .

172 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Databases

Syntax Element

Permanent

Explanation

Required. The permanent space in bytes allocated to contain tables and other objects created in the database.

Perm space can also be specified with a constant expression resulting in a numeric value in bytes. This allows you to specify perm space per AMP, which is useful when porting applications from a smaller test system to a production system.

Recommendation: For the Tables database, enter a value equivalent to 80% of permanent space allocated to user DBADMIN.

If you create child databases within the Tables database, divide the Tables database perm space among them according to the size of the tables each database contains.

Note: Tables do not have perm space allocations. They automatically take the space required to contain their data from the owning database.

Spool Recommendation: Not applicable. Queries running against the Tables database draw spool from the spool reserve of the user.

Temporary Space Not applicable. Required only when using global temporary tables and other advanced features.

Specifying temporary space requires that you develop a strategy for use of the advanced features that need such space. If necessary, you can add a temporary space specification later with a MODIFY DATABASE statement.

Account

Default Journal

Comment

Before Journal

Not applicable.

Recommendation: Specify accounts at the profile or user level. For information

on using accounts, see “Working with User Accounts” on page 251 .

The default location for journal images of tables created in the new or modified database.

Recommendation: Specify only if you use journaling. See the syntax elements

Before Journal and After Journal in this table.

Optional. You can enter text to describe the database.

Specifies journaling for “before” change row images as follows:

•

Yes - specifies a single journal.

•

No - specifies no journal.

•

Dual - specifies dual journals.

These are actual journaling requirements when specified in the Create Database dialog box.

This option is not normally specified for the initial database implementation.

Teradata Data Warehouse Appliance 2800 Implementation Guide 173

Chapter 6: Creating the Database Structure

Working with Databases

Syntax Element

After Journal

FallBack

Explanation

Specifies journaling for “after” change row images as follows:

•

Yes - specifies a single journal on a different AMP from changed row.

•

No - specifies no journal.

•

Dual - specifies dual journals.

•

Local - specifies a single journal on the same AMP as changed row. The

Local option is only available for non-FallBack tables.

These are actual journaling requirements when specified on the Create

Database dialog box.

This option is not normally specified for the initial database implementation.

Not applicable, but enabled by default. Specifies that the system will automatically create a duplicate of each table stored in the database space, to provide backup in the event of a failure.

Recommendation: Uncheck the FallBack box. Fallback is required only for individual mission-critical tables or tables so large that their size prevents timely backup to tape or external disk.

Note: This example is the minimum recommended specification for creating the

Tables_Database. You can specify additional options later using the MODIFY DATABASE statement.

Click the Create button to create the database. The Query Window displays a generated

CREATE DATABASE statement similar to the following:

CREATE DATABASE "Tables_Database" FROM "DBADMIN"

AS PERM = 104857600

NO FALLBACK

NO BEFORE JOURNAL

NO AFTER JOURNAL

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Create Database dialog box.

You can optionally create additional child databases within the Tables database to group tables by function or department, but it is not required.

Reference Information

For step...

Information on...

All options for setup and operation of

Teradata Administrator

Is available in...

Teradata Administrator User Guide, B035-

2502

174 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Databases

For step...

Information on...

3 and 4 syntax and options for:

•

CREATE DATABASE

•

DELETE DATABASE

•

DROP DATABASE

•

MODIFY DATABASE

4 guidelines for determining database space requirements guidelines for use of journaling

Is available in...

•

SQL Data Definition Language Syntax

and Examples, B035-1144

•

SQL Data Definition Language Detailed

Topics, B035-1184

Database Administration, B035-1093

Creating the Views Database

Use the following procedure to create one or more Views Databases to contain all the views

and macros required by the users. For information on creating individual views, see “Working with Views” on page 191

Start Teradata Administrator and log on as user DBADMIN.

From the main screen, click the Preview Mode button

SQL.

to specify display of generated

Click Tools>Create>Database. The Create Database dialog box appears.

Teradata Data Warehouse Appliance 2800 Implementation Guide 175

Chapter 6: Creating the Database Structure

Working with Databases

Specify values for the following database parameters.

Syntax Element Explanation

Database Name The name of the master database containing user-accessible views. To make data more easily accessible you can create several Views databases according to the needs of various departments or user groups, for example:

•

Views by department

•

Finance_Views

•

Personnel_Views_and_Macros

•

Purchasing_Views

•

Views by user type

•

General_User_Views

•

Update_User_Views

•

Batch_User_Views

You can also create Views databases by functional layer, for example:

•

A layer of read-write views where each view mirrors a table, usable for batch loads and updates without direct access to data tables

•

A layer of read-only views that contain selected columns from one or more tables to combine related information from multiple tables or restrict access

For information on the creation of views, see “Working with Views” on page 191

For a description of user types, see “About User Requirements” on page 249 .

Owner

Permanent

Space

Required. The name of the user or database that owns the space in which the object is being created.

Recommendation: Enter the name of the primary administrative user,

DBADMIN, previously set up in

“Creating User DBADMIN” on page 161 .

The permanent space in bytes allocated to contain space-consuming objects created in the database.

Recommendation: The Views database is not meant to contain data, but it is the best place to locate stored procedures that access the views. You can allocate a small amount of permanent space for stored procedures, for example 100 MB, and then adjust the allocation later using the MODIFY DATABASE statement.

Spool Space

Temp Space

Account

Not applicable. Queries running in the Views database take spool space from the

Spool_Reserve database.

Not applicable.

Recommendation: Specify account at the profile or user level.

For information on using accounts, see

Grant access privileges to the Views database, as shown in “Working with Table Access

Default Journal

Comment

Not applicable.

Recommendation: Not applicable, because journaling is not specified for views.

Optional. You can enter text to describe the database.

176 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Databases

Syntax Element

Before Journal

After Journal

FALLBACK

Explanation

Not applicable.

Not applicable. Fallback is required only for individual mission-critical tables or tables so large that their size prevents timely backup to tape or external disk, and this database contains only views of the data tables.

Recommendation: Uncheck Fallback box.

Note: This example is the minimum recommended specification for creating a

Views_Database. You can specify additional database options in the initial CREATE

DATABASE statement, or add them later using the MODIFY DATABASE statement.

Click the Create button to create the database. The Query Window displays a generated

CREATE DATABASE statement similar to the following:

CREATE DATABASE "Views" FROM "DBADMIN"

AS PERM = 0

NO FALLBACK

NO BEFORE JOURNAL

NO AFTER JOURNAL

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Create Database dialog box.

Privileges for Views” on page 178 . After completing the procedure, return to this section

and continue with the remaining tasks.

Reference Information

For step...

Information on...

All

3-5 options for setup and operation of

Teradata Administrator

•

CREATE DATABASE

•

DELETE DATABASE

•

DROP DATABASE

•

MODIFY DATABASE an overview of SQL procedures and how they are stored in the database

Is available in...

Teradata Administrator User Guide, B035-

2502

•

SQL Data Definition Language Syntax

and Examples, B035-1144

•

SQL Data Definition Language Detailed

Topics, B035-1184

SQL Stored Procedures and Embedded SQL,

B035-1148

Teradata Data Warehouse Appliance 2800 Implementation Guide 177

Chapter 6: Creating the Database Structure

Working with Databases

Working with Table Access Privileges for Views

You must grant table access privileges to all views databases to allow the views within each database to access tables in the Tables database.

Note: When table access privileges are granted to a Views database, the individual views inherit the right to access tables in the Tables database from the parent Views database.

Granting Table Access to Each Views Database

Start Teradata Administrator and log on as user DBADMIN.

4 f

On the main screen, click the Preview Mode button

SQL.

Click Tools>Grant/Revoke>Object Rights.

In the Grant/Revoke Objects dialog:

to allow display of generated

From the Database Name drop-down menu, select the Tables database. This is the object the privileges are granted on.

From the Object Type drop-down menu, select Database.

Click the To/From User tab and select a Views database. The privileges are granted to this object.

In the Normal field, check the following to select the privileges being granted:

•

For read-only views: Check Select.

•

For updatable views: Check Select, Insert, Update, and Delete.

Check the Grant box in the lower right-hand corner of the screen to give the database the privilege of extending the defined privileges to other databases. This specifies the

WITH GRANT OPTION clause.

Click the Grant button. The Query Window displays the generated GRANT statement, for example:

•

For read-only Views databases:

GRANT SELECT ON "Tables_Database" TO "database_name" WITH GRANT

OPTION

•

For the updatable Views databases:

GRANT SELECT, INSERT, UPDATE, DELETE ON "Tables_Database" TO

"database_name" WITH GRANT OPTION

5 g

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Grant/Revoke Objects dialog box.

Log off Teradata Administrator or go on to “About Access Logging” on page 273 .

178 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Tables

Reference Information

For Step...

Information on...

4 syntax and options for the GRANT

(SQL form) statement database privileges, including those conferred by object ownership

Is available in...

SQL Data Control Language, B035-1149

Security Administration, B035-1100

Working with Tables

About Teradata Tables

The Teradata CREATE TABLE statement is similar to other ANSI-compliant databases, but there are differences, so you must convert existing table definitions to Teradata SQL.

The following example shows how a table definition written in Oracle SQL differs from the same definition written in Teradata SQL. Note that Teradata SQL does not use extents, table spaces, or storage definitions, and may require changes in data type specifications.

CREATE TABLE statement in Oracle:

CREATE TABLE Table1

( Col1 NUMBER,

Col2 NUMBER,

Col3 NUMBER )

TABLESPACE Tablespace1

STORAGE (INITIAL 6144 NEXT 6144

MINEXTENTS 1 MAXEXTENTS 5 );

The corresponding CREATE TABLE statement in Teradata:

CREATE MULTISET TABLE Table1, FALLBACK,

NO BEFORE JOURNAL,

NO AFTER JOURNAL

(Col1 INTEGER,

Col2 INTEGER,

Col3 INTEGER)

PRIMARY INDEX (Col1);

For more about CREATE TABLE, see

“Creating Tables” on page 185 .

To ensure data integrity and system security, consider the following general rules when implementing tables:

•

Create individual tables in the Tables_Database.

•

Set privileges so that general users cannot directly access or modify the data tables. Provide general user access to table data using views and macros.

•

Provide direct table access only to designated administrative users who perform updates to the table definitions or table data.

Teradata Data Warehouse Appliance 2800 Implementation Guide 179

Chapter 6: Creating the Database Structure

Working with Tables

Table Implementation Overview

Using the example provided, become familiar with Teradata table structure and how it may differ from table structure in your current database. See

“About Teradata Tables” on page 179 .

Convert the table definitions for your existing database into Teradata table definitions. See

“Converting Existing Database Tables to Teradata Tables” on page 180

Become familiar with primary index concepts and requirements. See

Indexes” on page 182

“About Primary

Define the primary index for each table. See “About Primary Indexes” on page 182

Generate tables using the CREATE TABLE statement. See

“Creating Tables” on page 185 .

After creating and populating a table, monitor perm skew to assess whether the primary

index requires modification. See “Validating Primary Index Selection” on page 190

Converting Existing Database Tables to Teradata Tables

This procedure uses Oracle as an example to show how you might convert tables created in an

ANSI-compliant database to Teradata.

Identify each Oracle schema/user and all database objects (for example, tables, indexes, views, and materialized views) contained in each schema.

Oracle uses schemas to group database objects into functional groupings that are created and owned by users.

In Teradata, database objects are created and organized within the owning database or user:

•

A database is a collection of related database objects. A database also contains an allotment of space from which users can create and maintain their own objects, or other users or databases.

•

A user is similar to a database, having a space allocation and the capacity to contain objects. However, a user also has a password and can log on to the system, whereas a database cannot.

Identify the schemas that have objects you want to migrate to Teradata.

Create Teradata databases that correspond to the Oracle schemas and map the schemas to the corresponding Teradata databases.

Identify the DDL for each schema object.

Map Oracle data types to Teradata data types. See “About Teradata Data Types” on page 393 .

Map Oracle table elements to Teradata table elements. See “Creating Tables” on page 185

for a description of common Teradata table options.

Oracle and Teradata tables have some common elements:

•

All tables have names.

•

All tables contain columns with data types.

•

Tables can be partitioned.

180 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Tables

In Oracle, you must create tablespaces to store table data. You can partition a table and distribute specific partitions for storage in specific tablespaces.

In Teradata, the system uses the Primary Index (PI) to distribute table rows across

units of parallel execution (AMPs). See “Choosing a Primary Index” on page 184

You can achieve further partitioning of the data rows within each AMP by defining a

Partitioned Primary Index (PPI) for the table, which is similar to the type of partitioning that Oracle tables perform. However, it is easier to define PPI schemes in

Teradata because the partitioning is a logical organization of data within the database file system, and it requires no knowledge of table space definitions or physical disks.

For more information, and

“Partitioned Primary Indexes” on page 182 .

•

Constraints can be defined on table columns.

•

Referential integrity can be defined.

•

Global temporary tables are supported.

•

The data block size can be defined to optimize the storage of row data.

•

Freespace can be defined to retain room after loading for future data growth.

•

Triggers can be defined. See “About Triggers” on page 407

Teradata has a number of additional table options, including:

•

Primary index - used for data distribution, data access, table joins, and aggregations.

For details, see

“About Primary Indexes” on page 182

•

FALLBACK option - allows mirroring of table data for recovery scenarios.

•

Journaling options - stores an image of each data row that has been changed to provide data protection in case of a failure.

Also, in Oracle you must enable a table to be accessed with parallel query processes, whereas parallel query process are automatically accepted in Teradata.

Translate the DDL for each schema object to Teradata DDL.

The DDL for creating tables differs between Oracle and Teradata primarily in how space utilization is defined for the tables.

In Oracle, database objects are created and stored in tablespaces. Tables can have space utilization parameters describing how they will use space in tablespaces.

In Teradata, database objects are created and stored in databases or users. The database or user definition also defines a space allocation. See

“Working with Databases” on page 171

The system automatically transfers space from a database or user to owned tables as needed, so Teradata table definitions do not include database storage management clauses.

Recommendation: To facilitate loading data from your Oracle table into the new Teradata table, define the column names of the Teradata table to be the same as the column names of your Oracle table. You may use the ALTER TABLE statement to rename any of the columns in the Teradata table after loading the data into the table.

For details on using the CREATE TABLE statement, see

“Creating Tables” on page 185 .

Teradata Data Warehouse Appliance 2800 Implementation Guide 181

Chapter 6: Creating the Database Structure

Working with Tables

About Primary Indexes

Defining the primary index (PI) for a table is the most critical aspect of table design.

The system uses the PI to assign each data row to an Access Module Processor (AMP). A well chosen PI balances the distribution across AMPs and helps optimize the performance of queries that access the table. PIs also enable efficient joins and aggregations.

Note: A Teradata Database query does not use a PI for access unless all columns in the index are in an equality predicate or an IN LIST.

After you identify the PI requirements for a table you must specify the PI, and whether it is unique, as part of the CREATE TABLE statement.

No Primary Index (NoPI) Tables

You can create tables without a primary index (NoPI). The performance of FastLoad and

Teradata Parallel Data Pump (TPump) Array INSERT operations can be enhanced by using

NoPI staging tables.

You can use NoPI tables as intermediate work tables where PI access is not a consideration.

The system automatically balances the distribution of NoPI tables across AMPs.

NoPI tables are designed for temporary use. In all other circumstances, Teradata recommends that you specify a primary index when you create a table.

Unique and Nonunique Primary Indexes

You can define the primary index as unique (UPI) or nonunique (NUPI), depending on whether duplicate values are allowed in the indexed column set.

UPIs provide optimal data distribution and are typically assigned to the primary key for a table. However, the primary key is not necessarily always the best candidate for a primary index. For a comparison of primary keys and primary indexes, see

“How PIs Relate to Primary

Keys and Foreign Keys” on page 183

When a table is designed with a NUPI, consider assigning a uniqueness constraint such as

PRIMARY KEY or UNIQUE to the primary or other alternate key of the table. This both enforces uniqueness and enhances retrieval for applications where the primary or other alternate key is frequently used as a selection or join criterion.

Partitioned Primary Indexes

Primary indexes can be partitioned or nonpartitioned. A partitioned primary index (PPI) permits rows to be assigned to user-defined data partitions on the AMPs. A PPI is defined to be either single-level or multilevel. Multilevel partitioning allows each partition to be subpartitioned.

The greatest potential gain in partitioning a primary index is the ability to access only the rows of the qualified partitions while skipping partitions that do not contain rows meeting the search conditions of a query.

A PPI increases query efficiency by avoiding full table scans without the overhead and maintenance costs of secondary indexes. A multilevel PPI provides multiple access paths to the

182 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Tables rows in the base table and can improve query performance through partition elimination at each of the various levels or combination of levels.

PPIs are designed to optimize range queries while also providing efficient PI join strategies. A range query requests data that falls within specified boundaries. A common example of this is queries that involve date ranges.

Recommendation: Consider defining a table with a PPI to support either of the following workload characteristics:

•

A majority of the queries in the workload specify range predicates on some column, particularly a date column, of the PPI table.

•

A majority of the queries in the workload specify an equality predicate on some column of the PPI table, and that column is either:

•

Not the only column in the primary index column set or

•

Not a primary index column

How PIs Relate to Primary Keys and Foreign Keys

A primary key defines a column, or columns, that uniquely identify a row in a table. The values defining a primary key for a table:

•

Must be unique

•

Should not change

•

Cannot be null

The following table summarizes the differences between logical primary keys and physical primary indexes:

Primary Key

Important element of logical data model.

Used to maintain referential integrity.

Must be unique to identify each row.

Values should not be changed if you want to maintain data integrity and preserve historical relations among tables.

Cannot be null.

Does not imply access path.

Required by Teradata Database only if referential integrity checks are to be performed.

Primary Index

Not used in logical data model.

Used to distribute and retrieve data.

Can be unique or nonunique.

Values can change.

Can be null.

Defines the most common access path.

Defined for most production tables. (Some staging tables may not have a primary index.)

Teradata Database uses a unique primary or secondary index to enforce a primary key; therefore, the primary key can affect how Teradata Database distributes and retrieves rows.

Teradata Data Warehouse Appliance 2800 Implementation Guide 183

Chapter 6: Creating the Database Structure

Working with Tables

Although the primary key is often used as the primary index for a table, it may or may not be the best column set to choose as a primary index. You should base your primary index decision on physical database design considerations that may favor columns other than those of the primary key.

A foreign key identifies table relationships. They model the relationship between data values across tables. A foreign key defines a column, or combination of columns, in a table. The foreign key column(s) must exist in the referenced tables as a primary key or a UNIQUE alternate key.

Teradata Database uses primary and foreign keys to maintain referential integrity between tables. Foreign keys are also used in join conditions.

Choosing a Primary Index

There are three essential factors to consider when choosing a PI:

•

Uniform data distribution (the most important consideration)

•

Optimal access to the data

•

The volatility of indexed column values

Use the following guidelines for selecting columns to be used as primary indexes:

•

Select columns that consist mainly of unique, distinct values.

This is the most important consideration. Columns with distinct values distribute data rows evenly across all AMPs in the configuration. This maximizes parallel processing by allowing all the processors to participate in processing the data rows for a request.

Avoid using columns with a small number of distinct values that are repeated frequently or columns that have many nulls. This will cause uneven distribution of data rows resulting in some AMPs having more rows to process than others, and will increase the potential for performance bottlenecks.

Recommendation: Select columns having significantly more distinct values than the number of AMPs in the configuration.

•

Select columns that are most frequently used in equality predicate conditions.

•

Select columns that are most frequently used to access rows.

The PI provides the most efficient method to access data in a table. Therefore, choosing the PI on the most frequently used access path provides for optimal data access. For example, if the table is frequently joined with a specific set of tables, consider defining the

PI on the column set that is typically used as the join condition.

Equality conditions permit direct access to the row. Inequality conditions require additional processing.

•

Select columns that do not have any of the following data types: BLOB, CLOB, Period,

UDT, ST_Geometry, MBR.

•

Choose as few columns as possible for the PI to optimize its generality.

•

Select primary indexes so that query plans use AMP-local processing and avoid row redistributions.

•

Select columns that are not volatile.

184 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Tables

Volatile columns force frequent row redistribution because Teradata Database assigns table rows to AMPs based on the PI values.

Note: Several DBSControl values, including those for AMP buffer size, affect actual row distribution.

Recommendation: Select a PI column set that will never be (preferred) or rarely be updated.

You may encounter conflicts when selecting the optimum primary index for a table. For example, choosing a PI that gives good distribution of data across the AMPs must be balanced against choosing a PI that reflects the most common usage pattern of the table. Also, some applications might favor one type of primary index, while other applications might perform optimally using a different primary index.

Recommendation: Make even data distribution, not data access patterns, the main priority when selecting a primary index. Tables and queries change. Access patterns change. However, data distribution does not. You can always add additional non-primary indexes, such as secondary and join indexes, to facilitate particular applications. See

“Using Indexes to

Improve Query Performance” on page 240 for information on optimizing indexes.

Reference Information

Information on...

indexing:

•

primary indexes

•

partitioned primary indexes

•

secondary indexes

•

join indexes (materialized views) no primary index tables referential integrity

Is available in...

•

Introduction to Teradata, B035-1091

•

SQL Fundamentals, B035-1141

•

Database Design, B035-1094

•

“Using Indexes to Improve Query Performance” on page 240

Database Design, B035-1094

SQL Fundamentals, B035-1141

Creating Tables

The following procedure shows how to create tables using BTEQ, but you can also use

Teradata Administrator or SQL Assistant. For a comparison of BTEQ and SQL Assistant, see

“Using SQL Assistant to Submit a Query” on page 219 .

Log on to Teradata Database as user DBADMIN using BTEQ. See

“Starting BTEQ in

Interactive Mode” on page 195

Create one or more tables using the CREATE TABLE statement. For example:

CREATE SET TABLE database_name.table_name, FALLBACK

(column_name data_type,

column_name data_type,

column_name data_type)

UNIQUE PRIMARY INDEX (primary_index_column); where:

Teradata Data Warehouse Appliance 2800 Implementation Guide 185

Chapter 6: Creating the Database Structure

Working with Tables

Syntax Element Explanation

MULTISET

SET

database_name data_type

A MULTISET table allows duplicate rows in compliance with the ANSI

SQL:2008 standard. A SET table does not allow duplicate rows.

If there are uniqueness constraints on any column or set of columns in the table definition, then the table cannot have duplicate rows even if it is declared as

MULTISET.

The name of the database where the table will be created if it is different from the current database.

Recommendation: The database should be the Tables_Database or a database

located within the Tables_Database. See “Working with Databases” on page 171

If database_name is not specified, the system creates the table in the default database for the current session.

The name of the table to be created.

table_name

[NO] FALLBACK Specifies that the system will automatically create a duplicate copy of the current image of every row in this table to provide backup in case of a failure.

NO FALLBACK is the default.

To specify FALLBACK for all tables in a database, use FALLBACK in the

CREATE DATABASE statement.

Recommendation: Specify FALLBACK for mission-critical tables or tables so large that their size prevents timely backup to tape or external disk.

column_name

Specifies the name of one or more columns, in the order in which they and their attributes are to be defined for the table.

Up to 2,048 columns can be defined for a table. Note that other limits or feature restrictions may apply before you reach the column limit. For example, you can have no more than 32 large object (LOB) columns per table.

Specifies a single data type for each column.

Some data types have different names in Teradata than in other databases. For more information, see

“About Teradata Data Types” on page 393 .

[UNIQUE]

PRIMARY

INDEX

primary_index_ column

Specifies the primary index. A table can have no more than one primary index.

If you do not explicitly assign a primary index, Teradata Database will choose a default primary index (unless you specify NO PRIMARY INDEX).

Recommendation: Explicitly define a PRIMARY INDEX or UNIQUE

PRIMARY INDEX because the default selected by Teradata Database may not be optimal for the table.

Specifies the column(s) that define a primary index. If you specify more than one column, the index is created on the combined values of each column. You can specify up to 64 columns.

Recommendation: Choose columns that primarily have unique values, are frequently accessed, and have values that do not change. See

“Choosing a

Primary Index” on page 184 .

186 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Tables

Note: The example is the minimum recommended specification for creating a table. You can specify additional options, or add them later using the ALTER TABLE statement, see

“Optional Table-Level and Column-Level Elements” on page 187 .

To automate the creation of data tables by using BTEQ scripts, see “Using BTEQ Scripts to

Create Database Objects” on page 196 .

Set privileges on the table so that only designated administrative users can access the table directly. See

Chapter 10: “Setting Up Users.”

Collect statistics on the newly created, empty table. This defines the columns, indexes, and partitions for a PPI table, as well as the synoptic data structures for subsequent collection of statistics and demographics. See

“Using COLLECT STATISTICS to Optimize Query

Performance” on page 233

Optional Table-Level and Column-Level Elements

The following are common optional table-level elements you can specify in the CREATE/

ALTER TABLE statement. For details about these table options and for a complete description of all table options, see SQL Data Definition Language Syntax and Examples, B035-1144.

Syntax Element Explanation

GLOBAL TEMPORARY Creates a global temporary table. Global temporary tables have a persistent definition but do not have persistent contents across sessions. Each user session can materialize up to 2,000 global temporary tables at a time.

JOURNAL Specifies a Permanent Journal (PJ) for the table, which stores an image of each data row that has been changed with an INSERT, UPDATE, or DELETE statement. PJ images can reflect row values as they appeared before the change, after the change, or both.

To specify a PJ for all tables in a database, use the JOURNAL clauses in the

CREATE DATABASE statement.

Recommendation: Specify journaling for tables that need an additional level of data protection after you have analyzed data protection needs.

FREESPACE Specifies the percent of free space that remains on a cylinder during loading operations. The reserved free space allows table data to expand on current table cylinders, preventing data migration operations which can impact system performance. You can control this space at the global and table level.

Recommendation: If little or no table expansion is expected (the table is read-only), set FREESPACE to 0. Otherwise, choose a percentage that reflects the growth rate of your table (INSERTs minus DELETEs). Common settings are 5 to 15%. The maximum allowed is 75%.

Teradata Data Warehouse Appliance 2800 Implementation Guide 187

Chapter 6: Creating the Database Structure

Working with Tables

Syntax Element

DATABLOCKSIZE = n

[UNIQUE] INDEX

PARTITION BY

Explanation

Specifies the maximum data block size for blocks that contain multiple rows. Larger block sizes enhance full table scan operations by selecting more rows in a single I/O. Smaller block sizes are best for transaction-oriented tables to minimize overhead by retrieving only what is needed. You can control the data block size at the global and table level.

Recommendation: Use a larger value if the database is used primarily for strategic work (decision support/complex queries). Use a smaller value if the database is used primarily for tactical work (OLTP).

Note: Teradata recommends that 2800 appliances running Release 15.0 enable 1 MB Data Blocks, which allows more information in each I/O and improves response times. For more information, see Release Summary for

Teradata Database 15.0.

Specifies secondary indexes for the table. Secondary indexes (SI) allow quick access to table data using an alternate, less frequently used path than the primary index. SIs improve performance by avoiding full table scans. See

“Using Indexes to Improve Query Performance” on page 240 .

Specifies that the primary index is partitioned based on the value of the specified partitioning expression. A partitioned primary index (PPI) permits rows to be assigned to user-defined data partitions, enabling enhanced performance for range queries while providing efficient PI join

strategies. See “Partitioned Primary Indexes” on page 182 .

The following are common optional column-level elements you can specify in the CREATE/

ALTER TABLE statement. For details about these column-level options and for a complete description of all table options, see SQL Data Definition Language Syntax and Examples, B035-

1144.

Syntax Element Explanation

data_type_attributes

If you specify attributes for a column, you must define its data type before you define its attributes. The following attributes are supported:

•

NOT NULL

•

UPPERCASE

•

[NOT] CASESPECIFIC

•

FORMAT

•

TITLE

•

NAMED

•

DEFAULT or WITH DEFAULT

•

CHARACTER SET

•

WITH TIME ZONE

Recommendation: Teradata highly recommends that you specify the NOT

NULL attribute for columns that will never be null.

188 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Tables

Syntax Element

COMPRESS

CONSTRAINT

Explanation

Specifies a set of distinct values in a column that is to be compressed to zero space. Column compression can enhance storage capacity, improve response time for table scans, and reduce disk I/O traffic.

Recommendation: For best results, use multivalue compression where:

•

Enough rows contain a compressible value (null, zero, blank, or constant value) in the compressed field to exceed the break even point.

•

The shortened row size eliminates one or more data blocks.

Specifies column-level contraints. The following constraints are supported:

•

UNIQUE

•

PRIMARY KEY

•

FOREIGN KEY

•

CHECK

•

REFERENCES

Recommendation: Specify a name for the constraint specification.

Example CREATE TABLE Statement

This table definition creates the Employee table in the database named Tables_Database:

CREATE SET TABLE Tables_Database.Employee, FALLBACK

(Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB DATE,

Job_Title

Dept_No

VARCHAR(25),

SMALLINT,

Marital_Status CHAR,

No_Of_Dependents BYTEINT)

UNIQUE PRIMARY INDEX (Associate_Id);

Using BTEQ script, see “Using BTEQ Scripts to Create Database Objects” on page 196 .

See

“Loading Data from an External ODBC Database” on page 370

and “Loading Data from an External Flat File” on page 375 for sample Teradata Parallel Transporter (PT) load job

scripts that load data into this table.

See

“Exporting Data to an External Flat File” on page 380 for a sample Teradata PT export job

script that exports data from this table to an external flat file.

Reference Information

Information on...

an overview of tables, including global temporary and volatile tables

Is available in...

•

SQL Fundamentals, B035-1141

•

Database Administration, B035-1093

Teradata Data Warehouse Appliance 2800 Implementation Guide 189

Chapter 6: Creating the Database Structure

Working with Tables

Information on...

•

syntax, options, and required privileges for:

•

CREATE TABLE

•

ALTER TABLE

•

DROP TABLE

•

RENAME TABLE the default database data protection using:

•

FALLBACK

•

Permanent Journal data types and data type attributes

•

primary indexes

•

partitioned primary indexes

•

secondary indexes

•

join indexes (materialized views) using the FREESPACE option to manage performance, and guidelines for calculating a

FREESPACE value using the DATABLOCKS option to manage performance and specifying a DataBlockSize value compressing column values column-level and table-level constraints

Is available in...

SQL Data Definition Language Syntax and Examples, B035-

1144

SQL Fundamentals, B035-1141

Database Administration, B035-1093

SQL Data Types and Literals, B035-1143

•

“About Primary Indexes” on page 182

•

“Using Indexes to Improve Query Performance” on page 240

“FreeSpacePercent” in:

•

Utilities: Volume 1 (A-K), B035-1102

•

Utilities: Volume 1 (A-K), B035-1102

•

“Using Multi-Value Compression (MVC)” on page 294

Database Design, B035-1094

Validating Primary Index Selection

A well chosen PI balances workload processing evenly among AMPs, leading to parallelism, efficient data access, and optimal performance. When a PI is poorly chosen, the workload processing is not balanced (skewed) and performance suffers.

After you create and populate a table, you can use the Teradata Viewpoint Space Usage portlet to check the PI by monitoring the amount of perm skew (uneven distribution of data) for the

table. See “Identifying and Correcting Space Problems” on page 296 .

Note: If a table shows high skew, you can drop the table and recreate it with a new PI.

190 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Views

Database views are created from one or more base tables or from other views. They are virtual tables that you can use to retrieve data from the underlying views or tables. A view does not contain data so it does not use any space. Only the view definitions are stored in the Data

Dictionary.

A view may present only a subset of the columns and rows in the base table or tables. In addition, a column defined in a view can be derived and does not need to exist in the underlying base tables. For example, you can display summed or averaged data in a view column.

Views are generally used to:

•

Allow users to access only the rows and columns they need in a table.

•

Enforce security by restricting table access and updates.

•

Provide well-defined, well-tested, high-performance access paths to data.

•

Provide logical data independence, which minimizes the need to modify your applications if you restructure base tables.

•

Format the output of the data for reports.

•

Specify locking, such as specifying a less restrictive ACCESS lock.

To ensure data integrity and system security, Teradata recommends the following:

•

Set privileges so that general users cannot access or modify data tables directly.

•

Create views which allow general users to access or modify only the table data they need.

Use views to restrict users to performing specific queries and update functions.

•

Create views in a Views Database. See “Working with Databases” on page 171 .

For information on materialized views, see

“Join Indexes” on page 245

Creating Views

You can use the following utilities to create views in Teradata:

•

BTEQ

•

SQL Assistant

BTEQ and SQL Assistant allow you to submit CREATE VIEW DDL statements to Teradata

Database. For a comparison of BTEQ and SQL Assistant, see “Using SQL Assistant to Submit a

Query” on page 219

The following procedure shows how to create views using BTEQ:

Log on to Teradata Database as user DBADMIN using BTEQ. See

Teradata Query Utility” on page 195

“Working with the Basic

Create one or more views using the CREATE VIEW statement. For example:

CREATE VIEW database_name.view_name (column_name, column_name) AS

SELECT clause;

Teradata Data Warehouse Appliance 2800 Implementation Guide 191

Chapter 6: Creating the Database Structure

Working with Views where:

Syntax Element

database_name view_name column_name

Explanation

The name of the database where the view will be created if it is different from the current database.

Recommendation: The database should be a Views Database or a database located within a Views Database. See

“Working with Databases” on page 171 .

If database_name is not specified, the system creates the view in the default database for the current session.

The name of the view to be created.

The name of a view column. If more than one column is specified, list their names in the order in which each column is to be displayed for the view.

LOCKING clause The specified lock is placed on the underlying base table set each time the view is referenced in an SQL statement.

Recommendation: Create views with a LOCKING FOR ACCESS modifier to allow concurrent access of the data to read-only users and users who will modify the data. This prevents deadlocks and increases performance.

ACCESS locking is a tool that can be used to reduce the isolation of a user request allowing that request to access valid, but uncommitted data that is subject to change.

This allows users that are interested in a broad, statistical snapshot of the data, but that do not require precise results, to attain access to data while modifications to that data are occurring. This can greatly improve performance, because those users do not have to wait unnecessarily for the write operation to complete. For more information on the LOCKING clause,

see “Working with Database Locks” on page 227 .

SELECT clause The SELECT statement which obtains the data for the view. The following are some of the options and clauses you can use:

DISTINCT option

Returns only one row from any set of duplicate rows in the SELECT result.

SELECT clause

(continued)

ALL option

Returns all rows, including duplicate rows in the SELECT result. This is the default.

TOP n or TOP m PERCENT option [WITH TIES]

Restricts a view to only n rows or m percent of the rows in an underlying base table. If you do not specify an ORDER BY clause, then a TOP n clause only specifies that any n base table rows be returned, not the TOP n.

This option provides a fast method to obtain a restricted, non-statistically random sample of table rows.

FROM clause

Specifies the set of base tables or views from which data for the view are selected.

192 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with Views

Syntax Element Explanation

WHERE clause

Specifies a conditional expression by which rows for the view are selected.

GROUP BY clause

Groups result rows by the values in one or more columns or by various extended GROUP BY operations on specified column expressions.

HAVING clause

Specifies a conditional expression by which the groups defined by a GROUP

BY clause are selected.

QUALIFY clause

Specifies a conditional ordered analytical function by which rows for the view are selected.

WITH CHECK OPTION clause

Integrity constraint option that restricts the rows in the table that can be affected by an INSERT or UPDATE statement to those defined by the WHERE clause. This option only pertains to updatable views.

Recommendation: Specify a WITH CHECK OPTION clause in all your updatable view definitions to prevent unauthorized modification of data rows.

ORDER BY clause

Specifies the order in which result rows are to be sorted. You can only specify an ORDER BY clause for a view definition if you also specify either the TOP n or the TOP m PERCENT option.

Note: The example lists the major options for creating a view. You can modify your view definition by using the REPLACE VIEW statement.

To automate the creation of views by using BTEQ scripts, see “Using BTEQ Scripts to

Create Database Objects” on page 196 .

Set privileges on the view as follows:

•

Provide general users read-only access so they can use the view to query data.

•

Provide privileged users read and write access so they can use the view to update data in the underlying tables.

See

Chapter 10: “Setting Up Users,”

for information about granting privileges on the view to users.

Example 1: Creating a View to Limit User Access

The following statement creates a view of the Employee table so that it provides access only to the names and job titles of the employees in department 300:

Teradata Data Warehouse Appliance 2800 Implementation Guide 193

Chapter 6: Creating the Database Structure

Working with Views

CREATE VIEW Views_Database.Dept300 (Associate_Name, Job_Title) AS

SELECT Associate_Name, Job_Title

FROM Tables_Database.Employee

WHERE Dept_No = 300

WITH CHECK OPTION;

The WITH CHECK OPTION prevents using this view to insert a row into the Employee table, or to update any row of the Employee table where Dept_No is not 300.

Example 2: Creating a View to Generate a Report

The following statement creates a view which calculates the minimum, maximum, and average salary of each department and displays only those rows with an average salary of

$35,000 or higher.

Because the view definition specifies an ACCESS lock for the table, the view returns valid, but uncommitted data that is subject to change, particularly if the view selects data at the same time another user attempts to modify the salary data in the Employee table.

This view is designed for users who need quick access to data, but do not need precise results.

CREATE VIEW Views_Database.Dept_Salary (Dept_No, MinSal, MaxSal, AvgSal)

AS LOCKING TABLE Tables_Database.Employee FOR ACCESS

SELECT Dept_No, MIN(Salary), MAX(Salary), AVG(Salary)

FROM Tables_Database.Employee

GROUP BY Dept_No

HAVING AVG(Salary) >= 35000;

Reference Information

For step...

Information on...

overview of views

•

syntax, options, and required privileges for:

•

CREATE VIEW/REPLACE

VIEW

•

DROP VIEW

•

RENAME VIEW the default database the SELECT statement, including usage of the options and clauses

•

rules for creating, replacing, and using views

•

updatable views

•

WITH CHECK OPTION clause

Is available in...

•

SQL Fundamentals, B035-1141

•

Database Administration, B035-1093

SQL Data Definition Language Syntax and

Examples, B035-1144

SQL Fundamentals, B035-1141

SQL Data Manipulation Language, B035-

1146

SQL Data Definition Language Syntax and

Examples, B035-1144

194 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Working with the Basic Teradata Query Utility

For step...

Information on...

•

deleting rows using views

(DELETE, Basic/Searched Form)

•

updating rows using views

(UPDATE)

2 specifying locking in views

2 CREATE RECURSIVE VIEW and

REPLACE RECURSIVE VIEW

Is available in...

SQL Data Manipulation Language, B035-

1146

•

“Working with Database Locks” on page 227

•

SQL Request and Transaction Processing,

B035-1142

SQL Data Definition Language Syntax and

Examples, B035-1144

Working with the Basic Teradata Query Utility

Basic Teradata Query Utility (BTEQ) is a general-purpose, command-based application that allows users to:

•

Perform administrative tasks, including creation of database objects such as databases, tables, and views, using SQL DCL, DDL, and DML requests.

•

Format reports for both print and screen output.

You can use BTEQ interactively or you can create and run BTEQ scripts. See “Using BTEQ

Scripts to Create Database Objects” on page 196

For those familiar with Oracle, BTEQ is similar to SQL*Plus.

Starting BTEQ in Interactive Mode

To start BTEQ on a Windows client and log on to Teradata Database:

Click Start>Programs>Teradata Client>Teradata BTEQwin.

In the Session Charset Dialog box, select the client character set for your session.

The system will open a BTEQ window with the following BTEQ prompt:

Enter your logon or BTEQ command:

Log on to Teradata Database.

.LOGON tdpid/userid where:

•

tdpid is the name by which the appliance is known to the network.

•

userid is the user id of the user who is logging on.

For example:

.LOGON tdat1/DBADMIN

Submit the password associated with userid when prompted. If the logon is successful, the system will display:

Teradata Data Warehouse Appliance 2800 Implementation Guide 195

Chapter 6: Creating the Database Structure

Working with the Basic Teradata Query Utility

•

Teradata Database release and version

•

Transaction semantics for the session

•

Character set for the session

•

The following BTEQ prompt:

BTEQ -- Enter your DBC/SQL request or BTEQ command:

A successful logon establishes a BTEQ session on the Teradata Database system. At this point, you can enter your SQL request or BTEQ command.

To log off Teradata Database or exit BTEQ, enter one of the following commands:

•

.LOGOFF - ends the current Teradata Database sessions without exiting BTEQ.

•

.EXIT or .QUIT - ends the current Teradata Database sessions and exits BTEQ or exits

BTEQ if you are not logged on to Teradata Database.

Reference Information

For step...

Information on...

2, 5 setting session character sets

All

5 options for setup and operation of

BTEQ session transaction semantics

Is available in...

Database Administration, B035-1093

Basic Teradata Query Reference, B035-2414

“About Session Modes and Transaction

Processing” on page 216

Using BTEQ Scripts to Create Database Objects

You can automate the creation of tables, views, and other database objects using BTEQ scripts.

The following example procedure uses a BTEQ script to create the sample table from

“Working with Tables” on page 179 .

Create a text file named Create_Emp_Table.sql with the following contents:

.LOGON tdpid/UserName,Password

CREATE SET TABLE Tables_Database.Employee, FALLBACK

(Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB DATE,

Job_Title VARCHAR(25),

Dept_No SMALLINT,

Marital_Status CHAR,

No_Of_Dependents BYTEINT)

UNIQUE PRIMARY INDEX (Associate_Id);

.quit

where:

•

tdpid is the name by which the appliance is known to the network.

•

UserName is the name used to log on to Teradata, such as DBADMIN.

•

Password is the password associated with UserName.

196 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 6: Creating the Database Structure

Checkpoint

Create a batch file named Create_Emp.bat with the following contents: bteq < Create_Emp_Table.sql > Create_Emp_Table.log 2>&1 where:

2>&1 redirects the error messages to Create_Emp_Table.log to be printed along with the output messages.

Place Create_Emp.bat and Create_Emp_Table.sql in the same folder.

Execute Create_Emp.bat to create the Employee table in the database, Tables_Database.

Create_Emp.bat invokes BTEQ using Create_Emp_Table.sql as the input file. BTEQ executes the commands and statements in the Create_Emp_Table.sql file and writes its output and any errors to the Create_Emp_Table.log file.

Reference Information

Information on...

starting and exiting BTEQ running batch jobs to submit BTEQ commands and Teradata SQL

Is available in...

“Working with the Basic Teradata Query Utility” on page 195

Basic Teradata Query Reference, B035-2414

Checkpoint

Before leaving Chapter 6: “Creating the Database Structure,” make sure that:



Result

You have the following databases:

•

Tables, which contains all data tables

•

Views, which contains all views and macros

•

Your pre-existing ANSI-compliant tables are converted to Teradata and are empty, awaiting data loading.

•

You have new tables created in Teradata that have a primary index.

You have views created in the Views database.

Reference

“Working with Databases” on page 171

“Working with Tables” on page 179

“Converting Data Types to Teradata Data Types” on page 200

If you do not have these results, return to the section in the Reference column and review that procedure.

Teradata Data Warehouse Appliance 2800 Implementation Guide 197

Chapter 6: Creating the Database Structure

Checkpoint

198 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 7

Converting Queries to Teradata SQL

When converting existing SQL queries to Teradata SQL, you must to address the differences between your existing database and Teradata Database. The topics in this chapter show some of the main differences, using conversion from Oracle as an example. Conversions from other databases involve similar considerations.

Always test converted queries thoroughly before moving them to a production environment.

Compare the query results in your current system to the query results in Teradata Database to verify that the converted queries run as expected.

Recommendation: You can convert existing SQL as written and translate it directly to

Teradata SQL. However, this approach may not fully use the benefits that Teradata provides.

The best approach for some query types may be to migrate your business rules and logical framework into Teradata and then create new queries that are optimized for the Teradata

Database environment.

Query Conversion Overview

When converting existing queries to Teradata SQL, make sure to consider the requirements in each of the following topics:

•

•

“Converting Built-in SQL Functions” on page 200

•

“Converting Hierarchical Joins” on page 203

•

“Converting Outer Joins” on page 204

•

“Checking the Use of NULLs in Queries” on page 205

•

“Converting Nested Aggregate Operations” on page 205

•

“Converting External Tables to Table Functions” on page 206

•

“Converting Queue Tables” on page 206

•

“Converting Queries to Set Processing” on page 207

•

“Converting PL/SQL Functions” on page 209

•

“General Considerations for Using Teradata SQL” on page 210

Teradata Data Warehouse Appliance 2800 Implementation Guide 199

Chapter 7: Converting Queries to Teradata SQL

Converting Data Types to Teradata Data Types

Some data types supported in your current database may function the same in Teradata

Database, while other data types must be converted to Teradata data types. For details, see

“About Teradata Data Types” on page 393 .

Also, be aware of possible differences in the rules for converting data from one type to another, especially in the case of implicit data type conversions.

Teradata Database permits the assignment and comparison of some types without requiring the types to be explicitly converted. Teradata also performs implicit type conversions on some argument types (for example, SQRT) passed to macros, procedures, and SQL functions.

You can explicitly convert one data type to another using the CAST function. For example:

CAST (expression AS ansi_sql_data_type|data_definition_list) where:

Syntax Element

expression

Explanation

An expression with known data type to be converted to a different data type.

ansi_sql_data_type

The new data type for expression.

data_definition_list

The new data type or data attributes or both for expression.

Reference Information

Information on...

Teradata data types data type conversions

Is available in...

•

“About Teradata Data Types” on page 393

•

SQL Data Types and Literals, B035-1141

Chapter 17: “Data Type Conversions” in SQL

Functions, Operators, Expressions, and Predicates

Converting Built-in SQL Functions

Oracle SQL includes a collection of data manipulation functions, some of which are uniquely required by Oracle to support its ability to compare stored data to literal values, or to convert external data values to a data type that Oracle may store. Some Oracle SQL functions may be directly translated to the equivalent Teradata SQL function, but others may not.

If you use built-in SQL functions that are specific for your database, you must convert those functions so that they can be used in Teradata. You have the following options:

•

Replace the built-in function with an equivalent Teradata SQL function. See “About

Oracle-Equivalent Teradata UDFs” on page 201

200 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 7: Converting Queries to Teradata SQL

Converting Built-in SQL Functions

•

Translate the function into Teradata SQL and incorporate it into a converted SQL query or

save it as a procedure (in Teradata, referred to as a stored procedure). See “Translating

Built-in SQL Functions to Teradata SQL” on page 202 .

•

Create a new Teradata user-defined function (UDF) that provides the same functionality

as the existing built-in function. See “Reference Information” on page 204 for a list of

documents with information about UDF creation and use.

About Oracle-Equivalent Teradata UDFs

The Teradata Developer Exchange provides user-defined functions (UDFs) that emulate the most commonly used Oracle built-in SQL functions, including:

•

ADD_MONTHS

•

ASCII

•

BITAND

•

CEIL

•

CHR

•

DECODE

•

FLOOR

•

GREATEST

•

GREPC

•

INITCAP

•

INSTR

•

LAST_DAY

•

LEAST

•

LENGTH

•

LPAD

•

LTRIM

•

MONTHS_BETWEEN

•

NVL

•

REPLACE

•

ROUND

•

ROUND_TEST

•

RPAD

•

RTRIM

•

SIGN

•

TO_CHAR

•

TO_DATE

•

TO_NUMBER

•

TRANSLATE

•

TRUNC

•

UNICODE

After you install these UDFs, when Teradata Database encounters a call to an Oracle built-in

SQL function, it invokes the corresponding UDF to process the function call.

For additional information on Teradata UDFs, see

Installing Oracle-Equivalent Teradata UDFs

Verify that your Teradata system has a C or C++ compiler on the node used to compile the

UDFs.

Go to the Teradata Developer Exchange at: http://developer.teradata.com and use the search function to find “Teradata UDFs for Popular Oracle Functions.”

Download the UDFs (oraudfs_v_4.zip).

Open oraudfs_v_4.zip and extract the files, specifying the folder where you want the files extracted and selecting the option to extract the files using folder names.

Open the extracted ReadMe.txt file and follow the instructions to install the UDFs.

Make sure the default database for the session is the database in which you want the UDFs installed. Teradata Database provides a public database called SYSLIB for installing global functions.

IMPORTANT: Teradata provides these UDFs only for customer convenience. Although the UDFs are proven to work in many situations, Teradata does not support the UDFs, does not guarantee that the UDFs will work in all environments, and assumes no responsibility if the UDFs do not produce the expected results. Customers who implement

Teradata Data Warehouse Appliance 2800 Implementation Guide 201

Chapter 7: Converting Queries to Teradata SQL

Converting Built-in SQL Functions the UDFs are responsible for testing UDF results against the corresponding Oracle function results to ensure that the UDFs work as expected.

Using Oracle-Equivalent Teradata UDFs

Grant users who invoke the UDFs the EXECUTE FUNCTION privilege on the functions or on the database containing the functions. For example, if you installed the UDFs in the

SYSLIB database, the following SQL statement provides user blink with privileges to invoke the UDFs:

GRANT EXECUTE FUNCTION ON SYSLIB TO blink;

Use the UDFs anywhere you would use the corresponding Oracle built-in SQL functions.

Each subfolder that was created when you extracted the ZIP file contains a .btq file that provides an example of how to use a particular UDF.

Translating Built-in SQL Functions to Teradata SQL

If you do not want to use the Teradata UDFs for Oracle, you can rewrite the Oracle built-in functions using Teradata SQL and Teradata built-in functions. The following table shows how some of the Oracle functions can be translated to Teradata SQL.

Oracle

DECODE(a,b,c,d)

GREATEST(a,b)

LEAST(a,b)

SIGN(a)

NVL(a,b)

INSTR(s,c)

LENGTH(s)

LPAD(a,n)

LTRIM(a,c)

LTRIM(RTRIM(a,c))

RTRIM(a,c)

TO_CHAR(x[, f])

TO_DATE(x[, f])

TO_NUM(BER)(x[, f])

Teradata

CASE a WHEN b THEN c ELSE d END

CASE WHEN a >= b THEN a ELSE b END

CASE WHEN a <= b THEN a ELSE b END

CASE a WHEN > 0 THEN 1

WHEN < 0 THEN -1

ELSE 0 END

COALESCE(a, b) or

ZEROIFNULL(n)

INDEX(s,c)

CHAR_LENGTH(s)

CAST (a AS CHAR(n) )

TRIM (LEADING c FROM a)

TRIM (BOTH c FROM a)

TRIM (TRAILING c FROM a)

CAST (x AS CHAR(n) [FORMAT 'f'] )

CAST (x AS DATE|TIMESTAMP [FORMAT 'f'] )

CAST (x AS NUMERIC(n,m) [FORMAT 'f'] )

202 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 7: Converting Queries to Teradata SQL

Converting Hierarchical Joins

Oracle

TRUNC

MONTHS_BETWEEN(d,e)

Reference Information

Teradata

CAST (x AS DATE FORMAT 'f')

ABS (CAST ((d - e) MONTH(4) AS INTEGER))

Information on...

UDFs

Procedures and external procedures

Supported functions in Teradata Database

Teradata built-in functions

CASE and COALESCE expressions

•

using ZEROIFNULL to convert data from null to 0

•

using ABS to compute the absolute value of an argument

TRIM and INDEX string functions using CHAR_LENGTH to get the length of a string either in logical characters or in bytes explicit data type conversions using CAST using the FORMAT phrase to control the display of expressions, column data, and conversions between data types

Is available in...

“About Procedures and External Procedures” on page 404

SQL Functions, Operators, Expressions, and Predicates,

B035-1145

Converting Hierarchical Joins

Teradata supports hierarchical queries, but the syntax for coding hierarchical queries in

Teradata may differ from the syntax used in your current database. Therefore, you may need to rewrite existing hierarchical queries using Teradata syntax.

The following example shows an Oracle hierarchical query. This query returns the employee

IDs of the people who work for the manager whose employee ID is 801. The results returned include all the employees that work directly for employee 801, as well as all the people that work within the management hierarchy of the organization that employee 801 belongs to.

SELECT Employee_Id FROM

( SELECT Employee_Id FROM Employee start with Employee_id = 801 connect by prior Employee_Id = Manager_Id

Teradata Data Warehouse Appliance 2800 Implementation Guide 203

Chapter 7: Converting Queries to Teradata SQL

Converting Outer Joins

)

WHERE Employee_Id ^= 801

ORDER BY Employee_Id;

You can create the same query in Teradata as follows:

WITH RECURSIVE Temp_Table (Employee_Number) AS

( SELECT Root.Employee_Number

FROM Employee Root

WHERE Root.Manager_Employee_Number = 801

UNION ALL

SELECT Indirect.Employee_Number

FROM Temp_Table Direct, Employee Indirect

WHERE Direct.Employee_Number = Indirect.Manager_Employee_Number

)

SELECT * FROM Temp_Table ORDER BY Employee_Number;

Reference Information

Information on...

the concept of recursive queries use of the WITH [RECURSIVE] Request

Modifier in a query

Is available in...

SQL Fundamentals, B035-1141

SQL Data Manipulation Language, B035-1146

Converting Outer Joins

Teradata supports Left, Right, and Full outer joins, but the syntax for coding outer joins in

Teradata SQL may differ from the syntax used in querying your current database. Therefore, you may have to rewrite your outer joins using the Teradata SQL syntax.

The following example shows the outer join syntax for Teradata. This is also the standard, suggested outer join syntax for Oracle.

The query returns a sorted report of department IDs and names of employees that work in those departments. All employees appear in the returned list. If the Dept_ID of an employee is not present in the Department table, then the Dept_ID shown for that employee is null.

SELECT A.Dept_ID, B.Name

FROM Department A LEFT OUTER JOIN Employee B

ON A.Dept_ID = B.Dept_ID

ORDER BY A.Dept_ID, B.Name;

Oracle also supports this older outer join syntax, which is not supported in Teradata:

SELECT A.Dept_ID, B.Name

FROM Department A, Employee B

WHERE A.Dept_ID = B.Dept_ID(+)

ORDER BY A.Dept_ID, B.Name;

Queries written using this old outer join syntax must be rewritten to use the Teradata syntax.

204 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 7: Converting Queries to Teradata SQL

Checking the Use of NULLs in Queries

Reference Information

Information on...

outer joins

Is available in...

SQL Data Manipulation Language, B035-1146

Checking the Use of NULLs in Queries

In Teradata Database, the keyword NULL is not the same as an empty string. A null is a place holder indicating that no value is present. An empty string (' ') is a real value.

For example, given the following statements:

INSERT INTO String_Table VALUES ('', 'TestString');

INSERT INTO String_Table VALUES (NULL, 'TestString');

SELECT Column1, Column2 FROM String_Table;

In Oracle, the output from the SELECT statement is:

Column1 Column2

-------------

TestString

TestString where '?' is the default value displayed for a null by the application that executed the query.

Note that the empty string is interpreted as a null in Oracle.

In Teradata Database, the output from the SELECT statement (using SQL Assistant) displays an empty string corresponding to the first INSERT statement, and a null for the second

INSERT statement.

Column1 Column2

-------------

TestString

Reference Information

Information on...

nulls character string literals

Is available in...

SQL Fundamentals, B035-1141

SQL Data Types and Literals, B035-1143

Converting Nested Aggregate Operations

Aggregate operations cannot be nested in Teradata Database.

Teradata Data Warehouse Appliance 2800 Implementation Guide 205

Chapter 7: Converting Queries to Teradata SQL

Converting External Tables to Table Functions

For example, in Oracle, the following is valid:

SELECT MIN(SUM(…))

In Teradata, you must use syntax such as:

SELECT MIN(T.C) FROM (SELECT SUM(…)) as T(C);

Aggregates can be nested in aggregate window functions. The following statement is valid in

Teradata Database and includes an aggregate SUM function nested in a RANK window function:

SELECT region

,product

,SUM(amount)

,RANK() OVER (PARTITION BY region ORDER by SUM (amount))

FROM table;

Reference Information

Information on...

aggregates aggregate window functions

Is available in...

SQL Functions, Operators, Expressions, and Predicates, B035-1145

Converting External Tables to Table Functions

Oracle External Tables must be converted to Table Functions in Teradata Database. A table function is a type of UDF, which is invoked in the FROM clause of an SQL SELECT statement and which returns a table a row at a time in a loop to the SELECT statement. The function can produce the rows of a table from the input arguments passed to it or by reading an external file or message queue.

The number of columns in the rows that a table function returns can be specified dynamically at runtime in the SELECT statement that invokes the table function.

Reference Information

Information on...

UDFs

Is available in...

Teradata set processing. See “Converting Queries to Set Processing” on page 207 .

Converting Queue Tables

The queue tables supported in non-Teradata databases often have similar functionality to

Teradata queue tables, but there may be differences in the way the tables are created and

206 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 7: Converting Queries to Teradata SQL

Converting Queries to Set Processing manipulated. For example, Teradata queue tables are created using DDL and manipulated using SQL. Oracle queue tables are created and manipulated using PL/SQL, JMS, and Oracle

APIs.

You must translate existing queue table requirements and management into Teradata queue tables and processes.

Reference Information

Information on...

syntax and options for CREATE TABLE

(Queue Table Form) strategy for using queue tables manipulating data in queue tables using:

•

INSERT (push)

•

SELECT AND CONSUME (pop)

•

SELECT (peek)

•

DELETE, UPDATE, or MERGE

Is available in...

SQL Data Definition Language Syntax and Examples,

B035-1144

SQL Data Definition Language Detailed Topics, B035-

1184

SQL Data Manipulation Language, B035-1146

Converting Queries to Set Processing

For non-Teradata database systems, business processes often are broken into multiple, simple

SQL queries that use sequential, row-at-a-time, cursor processing. Although coding this type of SQL query is easier, it may not be the most efficient processing method.

Teradata Database uses parallel architecture and set processing to simultaneously update sets of rows, which is not possible using row-at-a-time cursor processing.

When migrating queries to Teradata or developing new queries, use SQL constructs that take advantage of Teradata parallel processing.

Instead of using...

IF statements nested loops nested procedures or functions

Use...

CASE operations or predicates joins joins or subqueries

Teradata Data Warehouse Appliance 2800 Implementation Guide 207

Chapter 7: Converting Queries to Teradata SQL

Converting Queries to Set Processing

Example 1 Conditional Insert

The following example uses a cursor to insert data into the Depositors table. The INSERTs are processed one row at a time.

cursor A is SELECT Acct, Name, Amt FROM Deposits;

FOR A_Rec IN A LOOP BEGIN

IF A_Rec.Amt > 0 THEN

IF A_Rec.Name = ' ' THEN A_Rec.Name = ‘UNKNOWN’;

END IF;

INSERT INTO Depositors (Account, Name) VALUES

(A_Rec.Acct, A_Rec.Name);

END IF;

END;

The SQL in the previous example can be rewritten using a CASE statement. CASE expressions help increase performance by returning multiple results in a single pass over the data rather than making multiple passes over the data.

INSERT INTO Depositors (Account, Name)

SELECT A.Acct, CASE A.Name

WHEN ' '

THEN ‘UNKNOWN’

FROM Deposits A

WHERE A.Amt > 0;

END

ELSE A.Name

Example 2 IF… ELSIF… ELSE

The following example uses a FOR loop and an IF...ELSIF...ELSE statement to set the value for

GL_Acct. This serial operation INSERTs data into the Gen_Ledger table one row at a time.

cursor Dep is SELECT Amt, D_date, AcctNum FROM Deposits;

BEGIN

FOR Deposits_Rec IN Dep LOOP BEGIN acct_num := Deposits_Rec.AcctNum;

IF acct_num = '999999990' THEN

GL_Acct := 'SLUSH';

ELSIF acct_num = '999999991' THEN

GL_Acct := 'MY SWISS BANK ACCT';

ELSIF acct_num = '999999992' THEN

GL_Acct := 'BLDG FUND';

ELSE

GL_Acct := 'CUST DEPOSIT';

VALUES (Deposits_rec.Amt, GL_Acct, Deposits_rec.D_date);

END LOOP;

END;

END IF;

INSERT INTO Gen_Ledger (Amount, Acct, DDate)

You can rewrite the SQL using a CASE statement, which simultaneously processes multiple rows.

INSERT INTO Gen_Ledger (Amount, Acct, DDate)

SELECT

DEP.Amt

,CASE WHEN DEP.AcctNum = '999999990' THEN 'SLUSH'

WHEN DEP.AcctNum = '999999991' THEN 'MY SWISS BANK ACCT'

208 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 7: Converting Queries to Teradata SQL

Converting PL/SQL Functions

WHEN DEP.AcctNum = '999999992' THEN 'BLDG FUND'

END

ELSE 'CUST DEPOSIT'

,DEP.D_date

FROM Deposits DEP;

Example 3 Nested Loop

The following Oracle SQL uses a nested FOR loop to update the Accts table. This serial operation cycles through the loops one row at a time.

acct_bal NUMBER(9,2); acct_num CHAR(9); cursor TXN_CUR is SELECT Amt, AcctNum

FROM Acct_Transactions

WHERE AcctNum = acct_num; cursor ACCT_CUR is SELECT AcctNum, acct_balance FROM Accts;

BEGIN

FOR acct_rec IN ACCT_CUR LOOP BEGIN acct_num := acct_rec.AcctNum; acct_bal := acct_rec.acct_balance;

FOR txn_rec IN TXN_CUR LOOP BEGIN acct_bal := acct_bal + txn_rec.Amt;

WHERE AcctNum = acct_num;

END LOOP;

END;

END LOOP;

UPDATE Accts SET acct_balance = acct_bal

You can rewrite the SQL using a subquery, which processes multiple rows simultaneously.

UPDATE Accts

SET acct_balance = acct_balance + Txn_Sum.total_amt

FROM ( SELECT AcctNum, SUM(Amt) FROM Acct_Transactions

GROUP BY 2

) Txn_Sum (acct, total_Amt)

WHERE Accts.AcctNum = Txn_Sum.acct

Reference Information

Information on...

CASE expressions

SQL predicates joins subqueries

Is available in...

SQL Functions, Operators, Expressions, and Predicates, B035-1145

SQL Data Manipulation Language, B035-1146

SQL Fundamentals, B035-1141

Converting PL/SQL Functions

Teradata can process complex relational requests in parallel, so it may be possible to convert a large number of PL/SQL processes to just a few Teradata SQL statements or procedures.

Teradata Data Warehouse Appliance 2800 Implementation Guide 209

Chapter 7: Converting Queries to Teradata SQL

General Considerations for Using Teradata SQL

Consolidation of PL/SQL processes into parallel Teradata SQL can result in a reduction in data processing time, resource usage, and the quantity of code to maintain.

You can migrate Oracle PL/SQL to Teradata by translating it directly to Teradata SQL, and embedding it into the proper vehicle for query execution. You should also convert the SQL to

The following options are available for converting PL/SQL functions for use in Teradata:

•

Translate the function into Teradata SQL and incorporate it into your SQL query.

•

Create a Teradata UDF that provides the same functionality as the PL/SQL function.

•

Translate the function into Teradata SQL and save it as a stored procedure or macro.

Reference Information

Information on...

Is available in...

set processing

UDFs

“Converting Queries to Set Processing” on page 207

“About Procedures and External Procedures” on page 404

Procedures and External Procedures

creating and using macros

“About Primary Indexes” on page 182

General Considerations for Using Teradata SQL

•

Teradata does not use a primary index or unique secondary index to process a query unless all of the indexed columns are in the predicate. Partial index access is supported for join indexes and for nonunique secondary indexes.

•

Updating or deleting the most current fetched cursor row using the UPDATE/DELETE …

WHERE CURRENT OF statement is valid in ANSI session mode, but not in Teradata session mode.

•

The COMMIT statement is supported in ANSI session mode only. An error is returned if the COMMIT statement is issued in Teradata session mode.

•

You cannot close a cursor that is not open. Any attempt to close a cursor that is already closed results in an error.

•

The result rows from a query are returned in unsorted order unless you specify the

ORDER BY clause. There is no default sequence for result rows.

•

Be aware of Reserved Word differences between your current database and Teradata.

•

Be aware of differences in the rules for naming database objects.

•

Be aware of possible migration issues related to Unicode characters.

•

Convert Oracle SQL*Plus scripts to BTEQ scripts.

•

Convert Oracle SQL*Loader (sqlldr) scripts to Teradata PT job scripts.

•

ODBC considerations:

210 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 7: Converting Queries to Teradata SQL

Checkpoint

•

Verify that all ODBC functions in an existing application are supported by Teradata

ODBC.

•

Test all DAO or ADO functions used in both Visual Basic and C++ programs.

Reference Information

Information on...

indexing

Is available in...

•

•

“Using Indexes to Improve Query Performance” on page 240

SQL Stored Procedures and Embedded SQL, B035-

1148

•

updating the most current fetched cursor row (UPDATE (Positioned Form))

•

deleting the most current fetched cursor row (DELETE (Positioned Form))

•

closing an open cursor (CLOSE)

ANSI session mode and Teradata session mode

COMMIT statement

ORDER BY clause

Teradata Database reserved words naming database objects

Unicode support

BTEQ scripts

“About Session Modes and Transaction Processing” on page 216

SQL Data Manipulation Language, B035-1146

SQL Fundamentals, B035-1141

Teradata PT job scripts using the ODBC Driver for Teradata with custom and off-the-shelf ODBC applications

International Character Set Support, B035-1125

“Using BTEQ Scripts to Create Database Objects” on page 196

Chapter 15: “Moving Data to and from Teradata

Database Tables”

ODBC Driver for Teradata User Guide, B035-2509

Checkpoint

Before leaving Chapter 7: “Converting Queries to Teradata SQL,” make sure that:



Result

Pre-existing data types are converted to Teradata data types.

Built-in functions specific to another RDBMS are converted to Teradata functions.

Reference

“Converting Data Types to Teradata

Data Types” on page 200

“Converting Built-in SQL Functions” on page 200

Teradata Data Warehouse Appliance 2800 Implementation Guide 211

Chapter 7: Converting Queries to Teradata SQL

Checkpoint



Result

Hierarchical queries are rewritten in Teradata

SQL syntax.

Queries with outer joins are rewritten using

Teradata SQL syntax.

You know how the NULLS and empty strings in your queries will be interpreted in Teradata.

Nested aggregate operations are converted to

Teradata SQL syntax.

Oracle external tables are converted to Teradata

Database table functions.

Queue tables from another RDBMS are converted into Teradata SQL.

The migrated SQL is taking full advantage of the parallel processing power of Teradata.

PL/SQL is converted to Teradata SQL and takes advantage of the parallelism and set processing features available in Teradata.

You have reviewed and acted upon other SQL application considerations.

Reference

“Converting Hierarchical Joins” on page 203

“Converting Outer Joins” on page 204

“Checking the Use of NULLs in

Queries” on page 205

“Converting Nested Aggregate

Operations” on page 205

“Converting External Tables to Table

Functions” on page 206

“Converting Queue Tables” on page 206

“Converting Queries to Set Processing” on page 207

“Converting PL/SQL Functions” on page 209

“General Considerations for Using

Teradata SQL” on page 210

If you do not have these results, return to the section shown in the Reference column and review that procedure.

212 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 8

Querying the Database

The tasks presented in this chapter, although not specifically required, represent best practices for querying the database. For best results you should read and consider the information presented. You can perform the tasks that apply to your implementation in any order.

Working with SQL Queries

Invoking SQL Statements

Teradata Database offers the following ways to invoke an executable SQL statement:

•

Interactively from a terminal

•

Embedded within an application program

•

Dynamically created within an embedded application

•

Embedded within an SQL procedure (a procedure that is written using SQL statements)

•

Embedded within an external procedure (a procedure that is written using C, C++, or

Java)

•

Dynamically created within an SQL procedure

•

Submitted in a BTEQ script as a batch job

•

Via a trigger

•

Embedded within a macro

Note: Teradata refers to a procedure as a stored procedure.

Reference Information

Information on...

•

SQL procedures (written using

SQL statements)

•

external procedures (written using C, C++, or Java) embedded SQL using dynamic SQL:

•

with embedded applications

•

in SQL procedures

Is available in...

“About Procedures and External Procedures” on page 404

SQL Stored Procedures and Embedded SQL, B035-1148

Teradata Data Warehouse Appliance 2800 Implementation Guide 213

Chapter 8: Querying the Database

Working with SQL Queries

Information on...

BTEQ scripts triggers macros

Is available in...

“Using BTEQ Scripts to Create Database Objects” on page 196

“About Triggers” on page 407

statements as a single request. See “Executing Multiple SQL Statements in Parallel” on page 220

Using Single- and Multistatement Requests

In Teradata Database, a request consists of one or more SQL statements and can span any number of input lines:

•

A single-statement request is treated as a solitary unit of work.

•

A multistatement request consists of two or more SQL statements that are treated as a single unit of work. If one statement in the request fails, the entire request fails and the system rolls back the entire request.

How you specify a multistatement request depends on the application you use to submit the query.

For example, in BTEQ, a Teradata request terminates with a semicolon (;) character at the end of a line. A semicolon placed at any other point in the request does not terminate it. You can use this property to stack multiple SQL statements within a single request either by placing intermediate semicolons at the beginning of a subsequent line or in the middle of a line.

Example 1 Single-Statement Request in BTEQ

BTEQ submits the following statements to the Teradata Database as three single-statement requests:

SELECT * FROM Employee;

DELETE FROM Employee

WHERE Associate_Name = 'Winter' AND Associate_Id = 394;

SELECT Associate_Name FROM Employee;

Example 2 Multistatement Request in BTEQ

To submit the three statements in Example 1 as a single multistatement request, enter:

SELECT * FROM Employee

; DELETE FROM Employee

WHERE Associate_Name = 'Winter' AND Associate_Id = 394

; SELECT Associate_Name FROM Employee;

In SQL Assistant, the semicolon position of the request is ignored. You can enter multiple SQL statements in the Query Window, then use the Execute Parallel command to submit the

The multistatement request improves performance for a variety of applications that can package more than one SQL statement at a time, such as BTEQ, CLI, and the SQL preprocessor.

214 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with SQL Queries

Multistatement requests improve system performance by reducing processing overhead. By performing a series of statements as one request, performance for the client, the Parser, and the Database Manager are all enhanced.

Because of this reduced overhead, using multistatement requests also decreases response time.

A multistatement request that contains 10 SQL statements could be as much as 10 times more efficient than the same 10 statements entered as separate requests (depending on the types of statements submitted).

There are a few restrictions on multistatement requests. For example, DDL statements are not valid in a multistatement request. Multistatement requests are non-ANSI standard.

Reference Information

Information on...

multistatement requests submitting single-statement and multistatement requests using BTEQ submitting single-statement and multistatement requests using SQL

Assistant

Is available in...

SQL Fundamentals, B035-1141

Basic Teradata Query Reference, B035-2414

•

“Using SQL Assistant to Submit a Query” on page 219

•

Teradata SQL Assistant for Microsoft Windows User

Guide, B035-2430

About Differences Between Teradata SQL and ANSI SQL

Teradata tries to conform to the ANSI SQL standard whenever possible. However, to create innovative features and capabilities, Teradata has also developed SQL language elements that do not conform to the ANSI SQL standard. Often, this was because a standard did not exist when the feature was designed.

Teradata SQL features conform to industry standards in the following ways:

•

The feature is fully ANSI SQL:2008 compliant

•

The feature is partially ANSI SQL:2008 compliant

•

The feature is a Teradata extension to the ANSI SQL standard

•

The feature is ANSI SQL:2008 compliant, but also has some options or capabilities that are

Teradata extensions to the ANSI SQL standard

•

The feature is ISO SQL/MM Spatial compliant

•

The feature is partially ISO SQL/MM Spatial compliant

Teradata Data Warehouse Appliance 2800 Implementation Guide 215

Chapter 8: Querying the Database

Working with SQL Queries

In the cases where the existing Teradata SQL dialect differs from the ANSI SQL standard,

Teradata adheres to the following policy:

•

If the difference between the Teradata SQL dialect and the ANSI SQL standard for an SQL feature is slight, the ANSI SQL is added to the Teradata SQL feature as an option.

•

If the difference between the Teradata SQL dialect and the ANSI SQL standard for an SQL feature is significant, both syntaxes are offered, and the user has a choice of:

•

using the Teradata SQL dialect by operating in Teradata session mode.

•

using the ANSI SQL standard by operating in ANSI session mode.

Reference Information

Information on...

•

SQL features available in Teradata, and which features are ANSI SQL compliant and which features are Teradata extensions

•

Terminology differences between ANSI

SQL and Teradata

Is available in...

SQL Fundamentals, B035-1141

About Session Modes and Transaction Processing

Teradata Database supports two session modes:

•

ANSI

•

Teradata

In ANSI session mode:

•

Transaction processing follows the rules defined by the ANSI SQL:2008 standard.

•

For Teradata SQL features that support both the ANSI SQL standard syntax and the

Teradata SQL dialect, the ANSI SQL standard syntax is used. See

“About Differences

Between Teradata SQL and ANSI SQL” on page 215

•

The default case specification for character data is CASESPECIFIC.

•

When a character string requires truncation, the excess pad characters are truncated without reporting an error. Truncation of characters other than trailing nonblank characters results in a truncation exception.

•

Cursors are always positioned. Updating or deleting the most current fetched cursor row using the UPDATE/DELETE … WHERE CURRENT OF statement is valid.

•

The default table type is MULTISET, which allows duplicate rows.

•

The TRIM function trims both leading and trailing pad characters by default.

In Teradata session mode:

•

Transaction processing follows the rules defined by Teradata before the emergence of the

ANSI SQL standard. These rules largely conform with ANSI semantics, but in some cases differ in important ways from the ANSI semantics.

216 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with SQL Queries

•

For Teradata SQL features that support both the ANSI SQL standard syntax and the

Teradata SQL dialect, the Teradata SQL syntax is used. See

“About Differences Between

Teradata SQL and ANSI SQL” on page 215 .

•

The default case specification for character data is NOT CASESPECIFIC. The exception is character data of type GRAPHIC, which is always CASESPECIFIC.

•

When a character string requires truncation, the string is truncated silently with no truncation notification given. This is true for truncation of pad or non-pad characters.

•

Cursors are never positioned. Updating or deleting the most current fetched cursor row using the UPDATE/DELETE … WHERE CURRENT OF statement is not valid.

•

The default table type is SET, which does not allow duplicate rows.

•

The TRIM function trims only trailing pad characters by default.

Note: Case specificity does not apply to CLOBs.

A transaction is a logical unit of work. The statements nested within the transaction either execute successfully as a group or do not execute. A Teradata SQL transaction can be a single

Teradata SQL statement, or a sequence of Teradata SQL statements.

Transaction Processing in ANSI Session Mode

In ANSI mode, transactions are always implicitly started and explicitly closed.

A transaction initiates when one of the following happens:

•

The first SQL request in a session executes

•

The first request following the close of a previous transaction executes

The COMMIT or ROLLBACK/ABORT statements close a transaction.

If a transaction includes a DDL statement (including DATABASE and SET SESSION, which are considered DDL statements in this context), it must be the last statement in the transaction other than the transaction closing statement.

If an error is found in a request, then that request is aborted. Normally, the entire transaction is not aborted; however, some failures will abort the entire transaction. Locks placed by erroneous statements are not released.

Sessions in ANSI mode do not support BEGIN TRANSACTION/END TRANSACTION statements.

Transaction Processing in Teradata Session Mode

In Teradata mode, transactions can be either implicit or explicit.

A request that is not enclosed by the BEGIN TRANSACTION and END TRANSACTION statements is treated as an implicit transaction.

An implicit transaction can be one of the following:

•

A single DML statement

•

A macro or trigger

•

A multistatement request

Teradata Data Warehouse Appliance 2800 Implementation Guide 217

Chapter 8: Querying the Database

Working with SQL Queries

DDL statements are not valid in a multistatement request and are therefore not valid in an implicit transaction composed of a multistatement request.

Explicit transactions contain one or more statements enclosed by BEGIN TRANSACTION and END TRANSACTION statements. The first BEGIN TRANSACTION initiates a transaction and the last END TRANSACTION terminates the transaction. Explicit transactions can contain multistatement requests.

When multiple statements are included in an explicit transaction, you can specify only a DDL statement if it is the last statement, and is immediately followed by END TRANSACTION.

If an error occurs, the request fails, the entire transaction is aborted and all locks are released.

Sessions in Teradata mode do not support the COMMIT statement. The END

TRANSACTION statement terminates a transaction with commit, while the ABORT and

ROLLBACK statements terminate a transaction with a rollback.

Setting the Session Mode

A system parameter specifies the default transaction mode for a site. You can override the default transaction processing mode for a session using one of the following:

•

SessionMode field of the DBS Control Record

•

BTEQ command .SET SESSION TRANSACTION

•

Preprocessor2 TRANSACT() option

•

Session Mode field of the Teradata ODBC Driver Options

•

JDBC TeraDataSource.setTransactMode() method

•

SQL Assistant when defining a .NET data source

Reference Information

Information on...

•

transaction, request, and statement processing

•

transaction processing in ANSI and

Teradata session mode

SQL statements for processing transactions:

•

BEGIN TRANSACTION/END

TRANSACTION

•

COMMIT

•

ABORT

•

ROLLBACK setting the SessionMode field of the DBS

Control Record using the SESSION TRANSACTION BTEQ command

Is available in...

SQL Request and Transaction Processing, B035-1142

SQL Data Manipulation Language, B035-1146

Utilities: Volume 1 (A-K), B035-1102

Basic Teradata Query Reference, B035-2414

218 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Using SQL Assistant to Submit a Query

Information on...

setting the Session Mode field in the Teradata

ODBC Driver Options dialog box setting the Session Mode field when defining a .Net data source using SQL Assistant

Is available in...

ODBC Driver for Teradata User Guide, B035-2509

Teradata SQL Assistant for Microsoft Windows User

Guide, B035-2430

Using SQL Assistant to Submit a Query

You can use Teradata SQL Assistant to compose an ad hoc SQL query, submit it to Teradata

Database, and view the results from your Windows client. In addition to querying the database, you can use SQL Assistant to create database objects, such as databases, tables, views, and users.

If you have many SQL statements in a file and you want to run it as a batch job, Teradata recommends that you use BTEQ instead. With BTEQ, you can scan saved query output for errors. You can also use BTEQ to submit end-user queries.

When deciding which program to use for submitting queries, consider the following comparisons:

BTEQ Capabilities

•

Allows use of conditional logic.

•

Creates reports, which you can format and print.

•

Requires you to store queries in outside files, which must be retrieved for reuse.

•

Can load only 64K per LOB.

SQL Assistant Capabilities

•

Does not allow use of conditional logic.

•

Returns results to a spreadsheet that can be manipulated online or saved to Excel, HTML,

PDF, or another format.

•

Keeps a history of previously used queries, which you can select for reuse.

•

Can load any LOB data that the database can store.

•

Can display pictures as part of the result set.

For more information on BTEQ, see “Working with the Basic Teradata Query Utility” on page 195

and

“Appendix C Advanced Features” .

Prerequisites

You must install the following software before using Teradata SQL Assistant:

•

Microsoft .NET Framework. See

“Installing Microsoft .NET Framework” on page 140

•

.NET Data Provider for Teradata. See

“Installation Guidelines” on page 138

•

ODBC Driver for Teradata. See “Working with ODBC Data Sources” on page 145

, which also describes how to define a Teradata data source (connection to the database).

Teradata Data Warehouse Appliance 2800 Implementation Guide 219

Chapter 8: Querying the Database

Using SQL Assistant to Submit a Query

Executing a Query Using SQL Assistant

To start Teradata SQL Assistant, select:

Start > Programs > Teradata Client > Teradata SQL Assistant

On the toolbar, select ODBC from the drop-down list located next to the Connect button

Click the Connect button (or select Tools > Connect).

Select the Teradata data source “Setting up Teradata as an ODBC Data Source” on page 145 .

Enter your Username and Password. For example, log on as user DBADMIN.

Do one of the following:

•

Enter an SQL statement in the Query Window.

•

Drag and drop a file from Windows Explorer into the Query Window.

Click the Execute button (or right-click in the Query Window and select Execute).

Executing Multiple SQL Statements in Parallel

You can run an entire query as a single request, allowing the database to execute all the statements in parallel. To do this:

Enter multiple SQL statements in the Query Window.

Click the Execute Parallel button

Reference Information

(or select Tools > Execute Parallel).

Information on...

setting query options setting formatting options for a query executing multiple SQL statements in a single request

Is available in...

Teradata SQL Assistant for Microsoft Windows User Guide,

B035-2430

“Using Single- and Multistatement Requests” on page 214

220 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with Commonly Used Queries

The most commonly used and useful SQL queries include:

•

SELECT

•

INSERT

•

UPDATE

•

DELETE

For more details, including the complete syntax, see SQL Data Manipulation Language.

Using the SELECT Statement

The SELECT statement retrieves stored data from a table. All rows, specified rows, or specific columns of all or specified rows can be retrieved. The FROM, WHERE, ORDER BY,

DISTINCT, WITH, GROUP BY, HAVING, and TOP clauses provide for a fine detail of selection criteria.

To obtain data from specific rows of a table, use the WHERE clause of the SELECT statement.

That portion of the clause following the keyword WHERE causes a search for rows that satisfy the condition specified.

Example 1: SELECT Request With a WHERE Clause

The following SELECT request returns the last name of the employee who is employee number 1023, works in department 501, and was hired in 2006.

SELECT last_name

FROM Employee

WHERE employee_number = 1023

AND dept_number = 501

AND hire_date BETWEEN DATE '2006-01-01' AND DATE '2006-12-31';

Example 2: SELECT Request With a Subquery

The following SELECT request uses a subquery to return the names of the employees who have the highest salary in each department.

SELECT name

FROM personnel p

WHERE salary = (SELECT MAX(salary)

FROM personnel sp

WHERE p.department=sp.department);

Teradata Data Warehouse Appliance 2800 Implementation Guide 221

Chapter 8: Querying the Database

Working with Commonly Used Queries

Using the INSERT Statement

Example 1: INSERT Request

You can use the INSERT statement to add a new row to a table. The following INSERT request creates a local instance of global temporary table globdb.gt1 and populates it with a single row having the following values: f1=1, f2=980101, f3=11.1

INSERT globdb.gt1 (1, 980101, 11.1);

Example 2: INSERT...SELECT Request

You can use the INSERT … SELECT form of the statement to perform a bulk insert of rows by retrieving the new row data from another table. The following INSERT...SELECT request copies all the rows from table t3 and inserts them into table t1:

INSERT t1 SELECT * from t3;

Using the UPDATE Statement

You can use the UPDATE statement to modify data in one or more rows of a table. In the

UPDATE statement, you must specify the column name of the data to be modified along with the new value. You can also use a WHERE clause to qualify the rows to change.

After you create the following table and insert values into it:

CREATE SET TABLE t1 ( a INTEGER, b INTEGER)

PRIMARY INDEX (a);

INSERT INTO t1 VALUES (1,1);

INSERT INTO t1 VALUES (1,2); in the following UPDATE example, you update the table by decreasing the value of b by 1 whenever a =1.

UPDATE t1

SET b = b - 1

WHERE a = 1;

Using the DELETE Statement

The DELETE statement allows you to remove an entire row or rows from a table. A WHERE clause qualifies the rows that are to be deleted.

The following example counts how many books by a publisher exist in the library. If the answer is 0, the request deletes the row for that publisher.

DELETE FROM Publisher

WHERE 0 = (SELECT COUNT(*)

FROM book, publisher

WHERE book.PubNum=Publisher.pubnum);

222 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with Macros

Reference Information

Information on...

the INSERT, SELECT UPDATE, and

DELETE statements

Is available in...

SQL Data Manipulation Language

Working with Macros

Teradata Database supports macros, which consist of one or more SQL statements that are stored as a database object.

When you execute the macro, Teradata Database runs the SQL statements within the macro as a single request. Therefore, the system processes either all of the SQL statements successfully or none of the statements. Users do not receive responses to individual statements contained in the macro body until all the statements have been completed successfully.

Macros do not use any space. Only the macro definitions are stored in the Data Dictionary.

You can create a macro for your own use, or grant execution authorization to others.

Macros provide the following benefits:

•

Easy execution of simple, frequently-used SQL operations.

•

Useful for enforcing data integrity rules.

•

Useful for enforcing data security.

•

Multistatement requests can provide a performance benefit.

•

Can be used to define an appropriate level of locking.

To ensure data integrity and system security, Teradata recommends the following:

•

Set privileges so that general users cannot access or modify data tables directly.

•

Create macros which allow general users to access or modify only the table data they need.

Use macros to restrict users to performing specific queries and update functions.

•

Create macros in a Views Database. See “Working with Databases” on page 171

Instead of using macros, you may want to use procedures to execute more complex queries.

Procedures can process control and condition handling statements, as well as SQL statements.

See “About Procedures and External Procedures” on page 404 and “Differences between

Macros and Procedures” on page 404

Creating Macros

The following procedure shows how to create macros using BTEQ:

Log on to Teradata Database as user DBADMIN using BTEQ. See

Teradata Query Utility” on page 195

“Working with the Basic

Create one or more macros using the CREATE MACRO statement. For example:

Teradata Data Warehouse Appliance 2800 Implementation Guide 223

Chapter 8: Querying the Database

Working with Macros

CREATE MACRO database_name.macro_name

(parameter_name data_type,

parameter_name data_type,

parameter_name data_type) AS

(SQL_statement;

SQL_statement;

SQL_statement;); where:

Syntax Element

database_name macro_name parameter_name data_type

SQL statement

Explanation

The name of the database where the macro will be created if it is different from the current database.

Recommendation: Specify the Views Database or a database located in the

Views Database. See “Working with Databases” on page 171

If database_name is not specified, the system creates the macro in the default database for the current session.

The name of the macro. The name must be unique within the database where it is created. Two identically named objects, for example, a macro named Test and a table named Test, cannot coexist in the same database.

The name of a parameter used for passing a value to the macro during execution. Parameters cannot be used for database object names. When referenced in the macro body, you must prefix a parameter name with the colon (:) character.

The data type of the parameter value.

A valid SQL statement to be executed when the macro is performed. The following rules apply:

•

A macro can include an EXECUTE statement that executes another macro.

•

For security reasons, the CREATE AUTHORIZATION or REPLACE

AUTHORIZATION statements are not allowed within a macro.

•

A data definition statement is allowed in a macro if it is the only SQL statement in that macro.

Unqualified references to database objects in a data definition statement are not resolved when the macro is created. They are resolved using the default database for the user submitting the EXECUTE statement when the macro is performed.

Unqualified references to database objects in DML statements are resolved using the default database for the user submitting the CREATE MACRO statement when the macro is created.

Recommendation: Fully qualify all references to database objects in the macro body for clarification.

Note: The example is the minimum recommended specification for creating a macro. You can specify additional macro options in the initial CREATE MACRO statement, or add them later using the REPLACE MACRO statement.

224 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with Macros

The following are common optional macro elements that you can specify in the CREATE/

REPLACE MACRO statement.

Syntax Element

data_type_attributes

USING modifier

LOCKING modifier

Explanation

The data type attributes, such as NOT NULL, UPPERCASE, or TITLE.

Not all of the data attributes that can be specified for table columns can be specified in macros. For example, the following attributes cannot be used with macro parameters:

•

CHECK constraints

•

COMPRESS phrase

Defines one or more parameters used to retrieve data from an external source such as a client data file.

Specifies the type of lock placed on a database, table, view, or row hash referenced by the subsequent SQL statement. Object referenced by a request are locked until the macro transaction is complete.

Recommendation: Use the LOCKING FOR ACCESS modifier to prevent deadlocks and increase performance, allowing concurrent access by read-only users and users who are modifying the data.

ACCESS locking is a tool that can be used to reduce the isolation of a user request, allowing that request to access valid, but uncommitted data that is subject to change.

Users that do not require precise results can access the data while modifications to the data are occurring. This can greatly improve performance because the users do not have to wait for the write operation to complete. For more information on the LOCKING clause,

see “Working with Database Locks” on page 227 .

To automate the creation of macros by using BTEQ scripts, see “Using BTEQ Scripts to

Create Database Objects” on page 196 .

Set privileges on the macro as follows:

•

Provide general users read-only access so they can use the macro to query data.

•

Provide privileged users with access so they can use the macro to modify data and database objects.

See

Chapter 10: “Setting Up Users,”

for information about granting privileges on the macro to users.

Example Macro

You can create macros to perform specific, narrow functions, such as adding a new employee into the database. By using a macro to perform this function, you limit the user to performing only the actions in the macro, which reduces the chance for errors. Also, the task is simpler to perform: executing the macro is easier than coding the INSERT statement.

The following request creates the New_Employee macro which inserts a row for a new employee in the Employee table, then performs a SELECT to verify that the information was

Teradata Data Warehouse Appliance 2800 Implementation Guide 225

Chapter 8: Querying the Database

Working with Macros entered correctly. If the user does not provide a value for Dept_No, the macro automatically inserts the value 300 as the default department number.

CREATE MACRO Views_Database.New_Employee

(Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB DATE,

Job_Title VARCHAR(25),

Dept_No SMALLINT DEFAULT 300,

Marital_Status CHAR,

No_Of_Dependents BYTEINT) AS

(INSERT INTO Tables_Database.Employee (Associate_Id, Associate_Name,

Salary, DOB, Job_Title, Dept_No, Marital_Status, No_Of_Dependents)

VALUES (:Associate_Id, :Associate_Name, :Salary, :DOB, :Job_Title,

:Dept_No, :Marital_Status, :No_Of_Dependents);

-- The following SELECT verifies the INSERT

SELECT *

FROM Tables_Database.Employee

WHERE Associate_Id = :Associate_Id; );

The example uses the -- comment construct to include a comment in the macro. Text appearing after -- and up to the end of the line is not performed.

After you create the macro, execute it as follows:

EXECUTE New_Employee (126, 'Taylor', 78000.00, '1978-12-29', 'Engineer',

400, 'S', 0);

You must have EXECUTE privilege on the macro.

Reference Information

For step...

2, 4

Information on...

overview of macros syntax, options, required privileges for:

•

CREATE MACRO/REPLACE MACRO

•

RENAME MACRO

•

DROP MACRO executing macros the default database data types and data type attributes

USING request modifier

Is available in...

•

Database Administration, B035-1093

•

SQL Fundamentals, B035-1141

SQL Data Definition Language, B035-

1184

SQL Data Manipulation Language,

B035-1146

SQL Fundamentals, B035-1141

•

“About Teradata Data Types” on page 393

•

SQL Data Types and Literals, B035-

1143

SQL Data Manipulation Language,

B035-1146

226 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with Database Locks

For step...

Information on...

LOCKING request modifier

Is available in...

“Working with Database Locks” on page 227

optimizing query performance with macros Database Design, B035-1094

Working with Database Locks

About Locks and Lock Levels

Teradata Database may use a different transaction isolation model than your current database.

You should review the transaction isolation needs of your queries and ensure that you have chosen the proper isolation level and method when migrating to Teradata.

The Teradata Lock Manager imposes concurrency control by locking the database object being accessed by each transaction and releasing those locks when the transaction either commits or rolls back its work.

The Lock Manager can lock an object at the following levels:

Lock Level

Database

Table

View

Row Hash

Description

Applies to all tables and views in the database.

All rows of all tables and their associated secondary index subtables are locked.

All rows in a base table and in any associated secondary index and fallback subtables are locked.

All underlying tables accessed by the view, including associated secondary indexes and fallback subtables are locked.

The primary copy of rows sharing the same row hash value are locked.

A row hash lock permits other users to access other data in the table. It is applied to the set of rows that shares the same hash code. It does not necessarily lock only one row.

A row hash lock is applied whenever a table is accessed using a unique primary index (UPI). For an update that uses a unique secondary index

(USI), the appropriate row of the secondary index subtable is also locked.

It is not necessary to lock the fallback copy of the row, nor any associated row, of a nonunique secondary index (NUSI) subtable.

The available lock severities, from most restrictive to least restrictive, are listed in the following table. The CHECKSUM and ACCESS locking severities are at the same level of restrictiveness.

Teradata Database always makes an effort to lock database objects at the least restrictive level and severity possible, to ensure database integrity while maintaining maximum concurrency.

Teradata Data Warehouse Appliance 2800 Implementation Guide 227

Chapter 8: Querying the Database

Working with Database Locks

Lock Severity

EXCLUSIVE

WRITE

READ

CHECKSUM

ACCESS

Description

Placed only on a database or table when the object is undergoing structural changes or when a database is being restored, copied, rolled back, rolled forward, or built by an Archive/Recovery utility command.

An EXCLUSIVE lock restricts access to the object by any other user.

Placed in response to an INSERT, UPDATE, or DELETE request or when a set of database objects is being recovered or restored by an Archive/Recovery utility command.

A WRITE lock enables a single user to modify the data and restricts access to the object by any other user, including those who want to read the object. However, if you are not concerned with data consistency, you can override the WRITE lock and read the data using an ACCESS lock.

Placed in response to a read operation such as a SELECT request. Archive requests can also place READ locks on database resources.

Multiple users can concurrently hold a READ lock on a base table. As long as a

READ lock is in place, no modification of the object is allowed.

Placed in response to a user-specified LOCKING FOR CHECKSUM modifier when using cursors in embedded SQL and procedures.

CHECKSUM locking is identical to ACCESS locking except that it adds checksums to the rows of a spool file to allow a test of whether a row in the cursor has been modified by another user or session at the time an update is being made through the cursor.

Placed in response to a user-specified LOCKING FOR ACCESS modifier, or by setting the session default isolation level to READ UNCOMMITTED using the

SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL statement.

An ACCESS lock does not restrict access by another user except when an

EXCLUSIVE lock is required.

ACCESS locking can be used to reduce the isolation of a user request. It permits a user to have READ access to an object that might already be locked for READ or

WRITE. Because the data selected using an ACCESS lock might be modified concurrently while the object is being read, any query that requests an ACCESS lock will return valid, but uncommitted data that is subject to change. Therefore, the ACCESS lock is sometimes referred to as a dirty READ lock.

When using ACCESS locks, it is the responsibility of the database designer and the data requester to ensure the proper level of data consistency for each user.

This gives the designer a wide degree of flexibility in determining how data can be accessed.

Recommendation: To prevent deadlocks and improve performance, use

ACCESS locks whenever you are interested in a broad, statistical snapshot of the data, but you do not require precise results.

Changing the Default Lock Level

The Lock Manager imposes locks automatically. You can use the SQL LOCKING request modifier to override the default lock severities. You can use LOCKING with DML statements

228 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Working with Database Locks and with most DDL, DCL, SHOW, and HELP statements. In particular, you can use

LOCKING with the CREATE INDEX and COLLECT STATISTICS statements to prevent deadlocks. You can also use the LOCKING request modifier when defining views.

For example:

LOCKING lock_level object_name FOR lock_severity [NOWAIT] SQL_request; where:

Syntax Element Explanation

lock_level

Keyword specifying the level of the lock to be placed. The available lock levels are: DATABASE, TABLE, VIEW, and ROW.

The keyword ROW indicates that a row-hash level lock should be used.

Recommendation: Always specify the appropriate keyword. This clarifies which database object should be locked in case you have two database objects with the same name (for example, you have both a table and a database named Accounts).

object_name lock_severity

Specifies the name of the database, user, table, or view to be locked.

Specifies the severity level of the lock to be used. The available lock severities are:

ACCESS, READ, WRITE, EXCLUSIVE, and CHECKSUM.

NOWAIT

SQL_request

If the indicated lock cannot be obtained, the request should be aborted.

Recommendation: Specify this option for situations in which it is not desirable to have a request wait for resources, and possibly tie up resources another request could use.

Specifies a valid SQL request.

The specified lock will be used instead of the default lock while processing this

SQL request. The lock will remain for the duration of the transaction containing this SQL request.

The following rules apply:

•

You can specify an EXCLUSIVE lock for a DELETE, INSERT, MERGE,

SELECT, SELECT AND CONSUME, or UPDATE statement.

•

You can specify a WRITE, READ, or ACCESS lock for a SELECT statement.

•

You can specify a CHECKSUM lock only when using cursors in embedded

SQL or procedures.

•

You cannot specify LOCKING with the CALL statement.

•

You can specify LOCKING with most DDL, DCL, SHOW and HELP statements.

When a view is defined with a LOCKING modifier, the specified lock is placed on all underlying base tables each time the view is referenced in an SQL request. For example, if a view refers to tables t1 and t2, then a lock on that view would apply to both tables.

Example 1: Using the LOCKING Clause

The following LOCKING clause can be used to select data from the Employee table while it is being modified. This allows users quick access to the data without having to wait for any write

Teradata Data Warehouse Appliance 2800 Implementation Guide 229

Chapter 8: Querying the Database

Working with Database Locks operation to complete, and is perfect for users who need a statistical sample of the data, but do not require precise results.

LOCKING TABLE Tables_Database.Employee FOR ACCESS

SELECT Associate_Name, Salary

FROM Tables_Database.Employee

WHERE salary < 25000;

Example 2: LOCKING Multiple Objects

Multiple LOCKING modifiers can precede a request if it is necessary to lock more than one object at the same time, for example:

LOCKING TABLE Employee FOR ACCESS

LOCKING TABLE Department FOR ACCESS

SELECT Associate_Name, Location

FROM Employee, Department

WHERE (Associate_Id = Manager_Id);

Example 3: Converting FOR UPDATE to a Locking Modifier

In Oracle, the FOR UPDATE clause of the SELECT statement allows you to lock the selected rows so that other users cannot modify the rows until your transaction ends.

You can use the LOCKING modifier to get the same result in Teradata:

LOCKING ROW FOR WRITE

SELECT ...

Monitoring and Managing Locks

You can use the following tools to monitor and manage locks:

•

EXPLAIN request modifier

Use EXPLAIN with your SQL request to determine what locks are set when the request is executed.

•

Lock Display (lokdisp) utility.

•

The DBQL Lock Log

You can access the DBQL lock log through the Teradata Viewpoint Lock Viewer portlet or query the system table DBC.DBQLXMLLOCKTbl or the view DBC.QrylockLogXMLV.

•

Lock Viewer portlet in Teradata Viewpoint allows you to view lock data such as transaction, session, and lock object identifiers, and global deadlocks. You can get a report based on the DBQL Lock Log or Locking Logger utility data from the Lock Viewer portlet

You can locate locks:

•

In a specific database

•

Within a time frame

•

Caused by a specified user

•

That are blocking a specified user

230 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 8: Querying the Database

Checkpoint

Reference Information

Information on...

managing locks locking and transaction processing syntax and options for the LOCKING request modifier guidelines for changing default lock assignments syntax and options for the SET SESSION

CHARACTERISTICS AS TRANSACTION

ISOLATION LEVEL statement session isolation level specifying locking in views the EXPLAIN request modifier

Is available in...

Database Administration, B035-1093

SQL Request and Transaction Processing, B035-1142

SQL Data Manipulation Language, B035-1146

SQL Data Definition Language, B035-1184

“Using EXPLAIN to Analyze Query Plans” on page 239

Utilities: Volume 2 (L-Z), B035-1102 using the Lock Display (lokdisp) utility to display all active database locks using the DBQL Lock Log using Teradata Viewpoint to investigate locks, blocked users and blocked sessions the DBQL chapter of Database Administration, B035-

1093

“Investigating Query Blocks and Delays” on page 304

Checkpoint

Before leaving Chapter 8: “Querying the Database,” make sure that:



Result

You know several ways of invoking SQL statements in Teradata.

You understand the implications of ANSI and Teradata session modes.

You understand the differences between

Teradata and ANSI SQL.

You can execute a query in SQL Assistant.

You can create macros in BTEQ and SQL

Assistant.

Reference

“Working with SQL Queries” on page 213

“About Session Modes and Transaction

Processing” on page 216

“About Differences Between Teradata SQL and ANSI SQL” on page 215

“Using SQL Assistant to Submit a Query” on page 219

“Working with Database Locks” on page 227

Teradata Data Warehouse Appliance 2800 Implementation Guide 231

Chapter 8: Querying the Database

Checkpoint



Result

•

You understand the default lock levels in

Teradata Database, and how to change them.

•

You know which utilities monitor locks.

•

You ensured that you chose the proper transaction isolation level when migrating to Teradata.

Reference

If you do not have these results, return to the section in the Reference column and review that procedure.

232 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 9

Optimizing Query Performance

After creating and populating database tables, you can take various actions in the database that help the Teradata Optimizer to handle queries more efficiently.

Task Overview

The tasks and procedures presented in this section are strongly recommended and should be performed completely and in the order shown to optimize Teradata Database queries:

Collect statistics on table columns. Identify stale statistics and recollect when necessary.

See

“Using COLLECT STATISTICS to Optimize Query Performance” on page 233

Analyze query plans using EXPLAIN and optimize query construction based on the

analysis. See “Using EXPLAIN to Analyze Query Plans” on page 239 .

Use secondary indexes and join indexes to optimize query processing. See “Using Indexes to Improve Query Performance” on page 240 .

After any query optimization change, rerun the query to measure performance differences and determine whether the changes achieved the desired result.

Repeat

step 2 through step 4

until you get satisfactory performance with correct query results.

Using COLLECT STATISTICS to Optimize Query

Performance

About Statistics Collection

Collecting statistics provides the Optimizer with the data demographics it needs to generate good query plans. The more accurate and up-to-date the statistics, the better the Optimizer can decide on plans and choose the fastest way to answer a query. Statistics are data demographics hints used by the Teradata Optimizer.

Teradata Data Warehouse Appliance 2800 Implementation Guide 233

Chapter 9: Optimizing Query Performance

Using COLLECT STATISTICS to Optimize Query Performance

The computed results are stored in the Data Dictionary DBC.StatsTbl for use during the optimizing phase of statement parsing. Statistics include:

•

Unique column values

•

Maximum rows/value

•

Typical rows/value

•

Number of null rows

The Optimizer automatically does a random AMP sample to gather rudimentary statistics when a query accesses data with no statistics, but these statistics may not be optimal.

Required Privileges

You must have STATISTICS privileges on a table (except a volatile table) to run a COLLECT

STATISTICS request.

Resource Considerations

Collecting statistics normally involves a full-table scan, so you may need to collect statistics for large tables during off-hours.

For very large tables, you can also collect statistics on a sampled subset of table rows instead of

all the rows for a table, using the SAMPLE clause. See “Sampling Statistics with the USING

SAMPLE Option” on page 237 .

About Automated Statistics Management

You have the choice of managing statistics collection manually or allowing Teradata Database to do it for you. To configure the Teradata system to automatically manage the statistics for one or more databases, the following steps are recommended:

Use the Teradata Viewpoint Stats Manager portlet to identify the databases and tables whose statistics should be automated. Alternatively, directly call the Automate-related

APIs available in the TDStats database.

Use the Teradata Viewpoint Stats Manager portlet to define jobs that collect the statistics identified in step 1. Consider defining Analyze jobs to identify additional statistics beneficial to query optimization. Alternatively, directly call Collect and Analyze-related

APIs in the TDSTSTATS database.

If you defined Analyze jobs in step 2, enable the STATSUSAGE logging option via the

BEGIN QUERY LOGGING statement for users or applications that access the objects identified in step 1.

Schedule the Collect and Analyze jobs defined in step 2 using either the Teradata

Viewpoint Stats Manager portlet or a different scheduling tool (for example, Cron).

For more information, see Workload Management API: PM/API and Open API, B035-1090 and Teradata Viewpoint User Guide, B035-2206.

234 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Using COLLECT STATISTICS to Optimize Query Performance

When to Collect Statistics

Collect statistics at the following phases of table development:

•

Newly created, unpopulated tables.

Collect statistics on unpopulated tables to set up the interval histogram used in internal processing. This initial collection makes subsequent statistics collections faster. Make sure to recollect statistics after data is added.

•

Prototype phase, newly populated tables.

•

Production phase, after a significant percentage of change to the table (~10%).

Recommendation: Collect production phase statistics after you have created users and applied real world query loads to the database (up to about 3 months of querying).

•

Collect statistics in the first few weeks after an upgrade or migration during periods of low

CPU utilization.

Collecting Statistics

Use the COLLECT STATISTICS statement to define the table columns on which you want to collect statistics, for example:

COLLECT STATISTICS ON database_name.table_name COLUMN (column_1,

column_2 ...);

At minimum, you should collect statistics on the primary index (PI) of each table. For small tables (<100 rows per AMP) PI statistics may be sufficient.

Recommendations for Large Tables

For best results on large tables, collect SUMMARY statistics only on non-partitioned tables.

Other recommendations for large tables include collecting statistics on:

•

All indexed columns

•

All frequently joined columns

•

Columns frequently referenced in WHERE clauses, particularly if the column contains very skewed, nonunique data

•

The system-derived column PARTITION (for all row and column-partitioned tables)

Reference Information

Information on...

syntax and options for the COLLECT

STATISTICS statement

Is available in...

•

SQL Data Definition Language Syntax and Examples,

B035-1144

•

SQL Data Definition Language Detailed Topics, B035-

1184

Teradata Data Warehouse Appliance 2800 Implementation Guide 235

Chapter 9: Optimizing Query Performance

Skipping Unneeded Statistics Recollection with the THRESHOLD Option

Stale Statistics

The system has some ability to extrapolate reasonable estimates for rows added since statistics were last collected, statistics that are far out of date (stale) may be worse for optimizer query planning than having no statistics at all.

Recommendation: Use the THRESHOLD option for COLLECT STATISTICS so the system automatically determines if statistics are stale and need to be recollected or if recollection can be skipped.

Note: If the current statistics are stale, but you do not want to recollect them because of resource contention, you can temporarily drop the statistics using the DROP STATISTICS command, and use the default statistics automatically collected by the system. However, you should recollect new statistics at the earliest opportunity.

About SUMMARY Statistics

Teradata recommends collecting SUMMARY statistics for both partitioned and nonpartitioned tables. This is a fast way to collect the current total number of rows in a table.

Collecting SUMMARY statistics is useful if collecting full statistics is too expensive. Collecting

SUMMARY statistics also allows more accurate extrapolation from previously collected full statistics, allowing resource-intensive full statistics collection to be delayed longer.

Skipping Unneeded Statistics Recollection with the THRESHOLD Option

To skip unneeded statistics recollections, specify the THRESHOLD option of the COLLECT

STATISTICS request. With this option, if the amount of data that changed since the last statistics collection is below a specified threshold or the statistics are newer than a specified age, Teradata does not recollect statistics. Either Teradata can determine the appropriate threshold or you can specify a change percentage following the THRESHOLD keyword and/or the number of days. You can issue COLLECT STATISTICS requests at regular intervals without being concerned that you might be wasting I/O and CPU by collecting statistics too soon. Teradata skips the recollections for the statistics whose thresholds are not met and recollects the statistics for those columns that are over the threshold. For example, if the threshold is 10% data change and you request a recollection, Teradata skips recollection if less than 10% of the data changed since the last collection.

If you specify the THRESHOLD option the first time you collect statistics, Teradata collects the statistics and remembers the THRESHOLD option. When you recollect statistics, Teradata uses the saved threshold to determine whether statistics recollection is needed. To tell Teradata to ignore the THRESHOLD option (without resetting it) the next time it collects statistics, use the FOR CURRENT option after the percent specification.

The following are the two kinds of thresholds that can be used to control the statistics recollections: change-based and time-based.

236 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Sampling Statistics with the USING SAMPLE Option

To use the THRESHOLD option, the AutoThresholdPercentForStats field in the DBS Control utility Cost Profile configuration settings must be set to either:

•

0 (the default: apply the SYSTEM THRESHOLD PERCENT for all statistics that do not have the threshold percent defined)

•

1 (apply SYSTEM THRESHOLD PERCENT for only new statistics requests that do not have the threshold percent specified)

•

2 (allows user-specified thresholds but disables the SYSTEM THRESHOLD PERCENT).

You can query the LastCollectTimeStamp column of the Data Dictionary table DBC.StatsTbl to see whether data is collected or not.

The user-specified change threshold percent is not supported for statistics on views and queries.

For the syntax of the COLLECT STATISTICS statement, see SQL Data Definition Language.

Sampling Statistics with the USING SAMPLE

Option

If you find that recollection on columns with evenly distributed data (that is, data with little or no data skew) is too costly in terms of performance, try using sampled statistics instead.

To use sample statistics, specify the USING SAMPLE option of the COLLECT STATISTICS request. You can collect sample statistics with a system-determined sample or you can specify a sample percentage. If you specify the sample percentage, Teradata reads the specified percent of rows to collect statistics.

If Teradata determines the sample percent, the system determines when to switch to sampling and the appropriate degree of sampling that can be used without sacrificing quality.

The downgrade approach works like this:

The first time you request a sample statistics collection, Teradata collects full statistics.

This gives Teradata information it needs to determine when to downgrade to a smaller percentage.

On subsequent requests to recollect statistics, Teradata collects full statistics until it has collected enough statistics history.

Using the statistics history, Teradata evaluates the nature of the column (for example, skewed, rolling, or static). Teradata considers the column usage (detailed or summary data), which it maintains in DBC.StatsTbl.UsageType field, and the user-specified number of intervals to decide when to downgrade to sample statistics. The system is more aggressive in downgrading to sample statistics for the histograms whose summary data is used.

Teradata determines a sample percentage (2% to 100%) for recollecting statistics and decides which formula to use for scaling based on the history and nature of the column.

Teradata Data Warehouse Appliance 2800 Implementation Guide 237

Chapter 9: Optimizing Query Performance

For More Information

To ensure quality, Teradata compares the recollected statistics to the history. The system lowers the sampling percentage only if a smaller sample provides quality results.

For example, Teradata never switches to sampled statistics for small tables, skewed columns, a column that is member of the partitioning expression, or columns that require details.

After few sample statistics collections, Teradata may collect full statistics to verify and adjust the sample percentage and the extrapolation method.

Sample statistics are not supported on views and queries.

A DBS Control utility Cost Profile field AutoSampleStats defaults all the COLLECT

STATISTICS requests to the SYSTEM SAMPLE option. You can override the Cost Profile default for individual COLLECT STATISTICS requests by explicitly specifying the required sample percentage.

To determine the sampling percentage in use, you can query the Data Dictionary table column

DBC.StatsTbl.SampleSizePct.

Example 1

The following requests sample statistics on the o_orderkey with user-specified sample percentage. Statistics are collected by reading 10% of the table rows:

COLLECT STATISTICS

USING SAMPLE 10 PERCENT

COLUMN o_orderkey

ON orders;

Example 2

The following requests system-determined sample statistics on the o_orderdatetime column.

The default sample percentage in DBS Control determines the number of rows sampled.

Teradata collects full statistics and remembers the sample option. Teradata considers downgrading the sample percentage after the system captures enough history and the column is identified as eligible for sample statistics:

COLLECT STATISTICS

USING SYSTEM SAMPLE

COLUMN o_orderdatetime

ON orders;

To tell Teradata to ignore the previous USING SAMPLE specification (without resetting it) the next time it recollects statistics, use the FOR CURRENT option after the SAMPLE, SYSTEM

SAMPLE, or SAMPLE PERCENT clause.

For More Information

For guidelines and suggested tools for collecting statistics, see the following:

•

SQL Data Definition Language:

238 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Using EXPLAIN to Analyze Query Plans

•

“COLLECT STATISTICS (Optimizer Form),” including “Comparison of Full and

Sampled Statistics.”

•

“SHOW STATISTICS (Optimizer Form).” Submit the SHOW STATISTICS statement with either the SUMMARY option to see summary statistics or the VALUES option to see detailed statistics.

•

SQL Request and Transaction Processing:

•

“Sampled Statistics.”

•

“Query Capture Facility.”

Using EXPLAIN to Analyze Query Plans

About the EXPLAIN Request Modifier

The EXPLAIN request modifier reports an English language summary of the query plan generated by the Optimizer to process any valid SQL request. The summary describes the

AMP steps the system would perform to resolve the request, but the request is not processed.

Note: To EXPLAIN a request, you must have the privileges required to execute the request.

EXPLAIN is useful for evaluating and optimizing SQL queries. It provides a summary of the access and join plans generated by the Optimizer for the specified SQL request, including information such as:

•

the indexes to be used

•

any intermediate spool files that will be generated

•

the join types to be performed

•

whether the requests in a transaction will be dispatched in parallel

•

the relative time it will take to complete the request

Using EXPLAIN allows you to compare the relative performance of the different versions of a query and choose the most efficient SQL.

Recommendation: Always use EXPLAIN to analyze any new queries under development.

Subtle differences in the way a query is structured can produce significant differences in its resource impact and performance, even though the queries may produce identical end results.

Administrators can use EXPLAIN interactively to examine queries that are consuming too many resources. See

“Identifying Problem Queries” on page 301

Generating an EXPLAIN with SQL Assistant

In the SQL Assistant Query window, enter the SQL query to be EXPLAINed.

Press F6.

For more information, see Teradata SQL Assistant for Microsoft Windows User Guide

Teradata Data Warehouse Appliance 2800 Implementation Guide 239

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

Generating an EXPLAIN with BTEQ

To generate an EXPLAIN for an SQL request, add the word “EXPLAIN” at the beginning of the request.

For example, the following SQL performs an EXPLAIN on a SELECT statement:

EXPLAIN SELECT * FROM Employee;

Reference Information

Information on...

syntax and options for the

EXPLAIN request modifier interpreting the output of the

EXPLAIN request modifier for various request types

Teradata Visual Explain utility

Is available in...

SQL Data Manipulation Language, B035-1146

SQL Request and Transaction Processing, B035-1142

Teradata Visual Explain User Guide, B035-2504

Using Indexes to Improve Query Performance

About Indexing Options

The process of creating a table includes specifying a primary index, which assists the system to evenly distribute table data and efficiently process requests that access the table.

After collecting statistics to aid query planning and using EXPLAINs to help enhance query construction, allow the system to run for a few months while evaluating performance. If you need to enhance performance, consider adding secondary indexes or join indexes.

Note: Teradata Database also supports hash indexes, which offer functionality similar to single-table join indexes, but using a different syntax. See Database Design, B035-1094.

Secondary indexes and join indexes can provide a more efficient path to the data by avoiding full-table scans when locating the relatively small number of rows that a query typically retrieves or updates.

You can create up to 32 indexes for one table, using any combination of secondary, join, and hash indexes. However, because Teradata parallel architecture allows the system to make highly efficient full-table scans, you may only need to assign a few indexes to a table to get the performance you need.

An index that supplies all the columns requested by a query is said to cover that query, and is often referred to as a covering index. Retrieval times are usually faster when using a covering index because the columns requested in the query can be retrieved from the index subtable rather than accessing the underlying base tables.

When the index contains only some of the columns referenced in a query, the situation is referred to as a partial cover of the query. Even a partial index cover can accelerate the

240 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance processing of a query by reducing (but not entirely eliminating) the need to access the base tables.

Costs and Benefits of Secondary Indexes and Join Indexes

Secondary indexes and join indexes can provide many benefits:

•

Lower CPU usage

•

Greater concurrency

•

Faster response times for queries

There are also some disadvantages to using indexes:

•

Indexes must be updated every time a row is updated, deleted, or added to a table. The more indexes you have defined for a table, the bigger the potential performance impact.

Sparse join indexes are updated only if the base row falls within the conditions of the sparse join index.

•

All secondary indexes are stored in subtables. When you define FALLBACK for a table, the secondary index subtables are always duplicated, which consumes additional disk space.

•

All join and hash indexes are stored in separate tables, causing a burden on disk space.

Defining FALLBACK for join or hash indexes consumes additional disk space.

When planning your indexes, you should always weigh the costs of an index against the benefits to make sure that the costs do not neutralize or even reduce the overall performance advantage of the index. For additional information, see Database Design, B035-1094.

About Secondary Indexes

Secondary indexes (SI) enhance single-row or set (multirow) selection by specifying access paths other than the primary index path. During query processing, the Optimizer estimates comparative costs to determine whether the use of a SI offers any savings. If no advantage can be obtained with the SI, a different access method is used, such as a full-table scan.

Secondary indexes are useful for:

•

Queries having a search condition that cannot be satisfied with a primary index retrieval.

For example, it is common for WHERE clause search criteria to be based on non-primary index columns, and such occasions often benefit greatly if there is an SI on the column defined for the search criterion.

•

Query plans where the SI completely or partially covers the query.

•

Facilitating aggregate operations.

•

Optimizing repetitive and standardized queries.

•

Improving system performance in decision support environments.

Recommendation: Use unique secondary indexes for decision support applications designed to return multiple rows, because the SIs may provide better performance than full-table scans.

You can create a secondary index:

Teradata Data Warehouse Appliance 2800 Implementation Guide 241

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

•

When you create the table. See “Working with Tables” on page 179

•

In a CREATE INDEX statement. See

“Creating Secondary Indexes” on page 243

Unlike primary indexes, secondary indexes can be dropped and created without altering the table they index. You can create or drop a secondary index when data usage changes, or if you find that the index is not useful for optimizing data retrieval performance.

Unique and Nonunique Secondary Indexes

You can define the secondary index as unique (USI) or nonunique (NUSI), depending on whether duplicate values are allowed in the indexed column set.

Unique secondary indexes have the following properties:

•

Can be used to enforce row uniqueness for multiset tables defined with a nonunique primary index (NUPI).

•

Guarantee that each composite index value is unique.

•

Data access based on a USI is very efficient (at most a two-AMP operation).

•

Are always preferable to NUSIs for access using a single row, but are not as efficient as

NUSIs for range query access.

•

Is useful in partitioned primary index tables if defined on the set of primary index columns when the primary index cannot be unique because it does not contain all the partitioning columns.

•

Teradata does not use a USI unless all of the indexed columns are in the predicate.

Nonunique secondary indexes have the following properties:

•

Are typically assigned to nonunique column sets that frequently appear in WHERE clause selection conditions, join conditions, ORDER BY and GROUP BY clauses, foreign keys, and other conditions such as UNION, DISTINCT, and any attribute that is frequently sorted.

•

Useful for locating rows having a specific (typically concatenated) value in the index.

•

Provide faster set selection, but USIs are more useful for retrieving single rows, particularly when a base table has a nonunique primary index.

•

Can be hash-ordered or value-ordered.

Value-ordered NUSIs are particularly useful for enhancing the performance of range queries against nonpartitioned primary index tables, especially when the NUSI covers the query or is highly selective.

•

A multicolumn NUSI created with an ORDER BY clause counts as two consecutive indexes against the maximum allowable 32 indexes.

Choosing a Secondary Index

When choosing columns for a secondary index for a table, the most important factor to consider is the selectivity of the index. An index that retrieves fewer rows is said to be more highly selective. The more highly selective an index is, the more useful it is for enhancing performance. While USI retrievals are always very efficient, the efficiency of NUSI retrievals varies greatly depending on selectivity.

242 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

You can use the Teradata Index Wizard utility to aid in choosing secondary indexes for a table.

The utility recommends a set of indexes based on specific query workloads you supply. The

Teradata Index Wizard can also validate its recommendations to ensure they actually provide the benefits expected.

Guidelines

Use the following guidelines for selecting columns to be used as secondary indexes:

•

Avoid columns that are frequently updated.

•

Avoid columns with uneven distribution because the Optimizer might mistake their usefulness.

•

Avoid creating excessive secondary indexes on a table.

•

Select column sets frequently involved in the following clauses, predicates, and other logical operations:

•

Selection criteria

•

Join criteria

•

ORDER BY clauses

•

GROUP BY clauses

•

Foreign keys (because of join and subquery processing)

•

UNION, DISTINCT, and other sort operations

When these operations act on well-indexed column sets, the number of scans and sorts that must be performed can be greatly reduced.

•

Consider creating covering indexes wherever possible. The Optimizer frequently selects covering indexes to substitute for a base table access whenever the overall cost of the query plan is reduced. Such index-only access promotes faster retrievals.

•

Select columns frequently operated on by built-in functions such as aggregates.

•

Avoid columns that do not enhance selectivity.

•

In some circumstances, multiple single-column indexes may be a better choice than using composite secondary indexes.

•

Select columns that do not have any of the following data types: BLOB, CLOB, Period,

UDT, ST_Geometry, MBR.

Creating Secondary Indexes

The following procedure shows how to create an index using BTEQ:

Log on to Teradata Database as user DBADMIN using BTEQ. See

Teradata Query Utility” on page 195

“Working with the Basic

Create one or more secondary indexes using the CREATE INDEX statement. For example:

CREATE [UNIQUE] INDEX index_name

(index_column_name,

index_column_name,

index_column_name)

ON database_name.table_name; where:

Teradata Data Warehouse Appliance 2800 Implementation Guide 243

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

Syntax Element

UNIQUE

index_name index_column_ name database_name table_name

Explanation

Specifies that no two rows in the table can have the same value or combination of values in the indexed columns.

Specifies an optional name for the secondary index.

Recommendation: Specify a name for the secondary index using a standard naming convention.

Specifies one or more columns whose values are to be indexed. If you specify more than one column, the index is created on the combined values of each column. You can specify up to 64 columns. See

“Choosing a

Secondary Index” on page 242 .

The name of the database where table_name is located if it is different from the current database. The table should be located within the

Tables_Database, as shown in

“Creating the Tables Database” on page 172

If database_name is not specified, the system looks for the table in the default database for the current session.

The index will be created for this table.

Note: The example is the minimum recommended specification for creating a secondary index. Additional options are available. For a complete description of all available options, see “CREATE INDEX” in SQL Data Definition Language Syntax and Examples, B035-1144.

You can modify the index by dropping it (DROP INDEX) and recreating it.

Example 1: Creating a Named Unique Secondary Index

The following statement creates a unique secondary index named Ident on the

Associate_Name and SocSecNo columns of the Employee table:

CREATE UNIQUE INDEX Ident (Associate_Name, SocSecNo) ON

Tables_Database.Employee;

This definition allows the named index to be dropped by using its name:

DROP INDEX Ident ON Tables_Database.Employee;

Example 2: Creating an Unnamed Nonunique Secondary Index

The following statement creates a nonunique secondary index on the Dept_No column of the

Employee table:

CREATE INDEX (Dept_No) ON Tables_Database.Employee;

The UNIQUE option is not used because multiple rows contain the same department number. The index should be useful, however, because department numbers are often used for conditional retrievals and for ordering employee listings.

The following statement drops this index:

DROP INDEX (Dept_No) ON Tables_Database.Employee;

244 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

Join Indexes

A join index allows the system to get requested data from an index rather than accessing and joining their underlying base tables. When a join index can be used to fully satisfy a query, you avoid the need to access multiple base tables, perform joins or aggregates, or redistribute the rows of very large tables, every time the query is run. You can define a join index on one or several tables.

Join indexes can also be useful for queries where the index structure contains only some of the columns referenced in the statement. This situation, referred to as a partial cover of the query, reduces (but not entirely eliminates) the need to access the base tables.

You can define the primary index for a join index on a column set that differs from the column set used to define the primary index on the base table. This facilitates joins by redistributing rows of frequently joined tables to the same AMP. You can also define nonunique secondary indexes on a join index.

You can create the following types of join indexes:

•

Single-table join index

•

Very useful for resolving joins on large tables without having to redistribute the joined rows across the AMPs.

•

Can be used to establish an alternate primary index access opportunity.

•

Can be used to aggregate one or more columns of a single table as a summary table.

•

Can be used to establish a subset of columns that are frequently accessed to improve access to those columns.

•

Multitable join index

•

Stores and maintains the joined rows of two or more tables and, optionally, aggregates selected columns.

•

Used for join queries that are performed frequently enough to justify defining a prejoin on the joined columns. Prejoins are also known as materialized views.

•

Useful when the index covers the query, making it possible to retrieve the requested data from the index rather than accessing the underlying base tables.

•

Aggregate join index

This index is extremely efficient in resolving queries that frequently specify the same aggregate operations on the same column or columns. When aggregate join indexes are available, the system does not have to repeat aggregate calculations for every query.

•

Sparse join index

This index stores a subset of the rows from the underlying base table set based on a

WHERE clause condition. This makes it possible for a smaller join index to be used in answering queries.

Recommendation: Use join indexes for decision support applications because they often provide superior performance to large table joins and aggregate computations.

To create a join index, use the CREATE JOIN INDEX statement. To create a sparse index, use the WHERE clause in the CREATE JOIN INDEX statement.

Teradata Data Warehouse Appliance 2800 Implementation Guide 245

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

Example Join Index

Suppose that a common task is to look up recent customer orders by customer number and date. You might create a join index like the following, linking the customer table, the order table, and the order detail table:

CREATE JOIN INDEX cust_ord2 AS

SELECT cust.customerid, cust.loc, ord.ordid, item, qty, odate

FROM cust, ord, orditm

WHERE cust.customerid = ord.customerid

AND ord.ordid = orditm.ordid

AND odate >= DATE '2009-08-01'

PRIMARY INDEX (customerid);

Validating and Maintaining Indexes

After you design your indexes and queries, and after you have run your workloads for a while

(approximately 30 days, depending on workload), it is important that you test your indexes to ensure that they are being used as planned, and providing the benefits you expect.

Perform the following steps regularly to verify and maintain your indexes:

Collect/re-collect statistics so that the Optimizer has the current column demographics to select the appropriate indexes when processing a query or update. See

“Using COLLECT

STATISTICS to Optimize Query Performance” on page 233

Use the EXPLAIN request modifier or the Visual Explain tool to test various candidate queries or updates and to note which indexes (if any) are used by the Optimizer. Also, examine the relative length of time required to complete the operations.

Use the Teradata Index Wizard client utility to recommend and validate sets of secondary or single-table nonsparse join indexes for a particular query workload. The Teradata Index

Wizard utility provides a “What-If Analysis” feature that allows you to see how an index might perform for a given workload and compare the performance of different indexes for the same workload.

Analyze the performance of an index to verify that the assumptions for choosing that index are correct. In particular:

•

If you define a partitioned primary index (PPI) for a table, make sure the PPI actually improves query performance over a nonpartitioned primary index by carefully examining EXPLAIN reports and collecting the appropriate statistics.

•

If you design a primary index with even row distribution as your principal criterion, analyze the actual distribution of table rows to ensure that they are evenly distributed.

Drop indexes that are rarely selected by the Optimizer. Unused indexes consume disk resources and degrade update processing performance unnecessarily.

Drop indexes where the selectivity of the index is always low (the index always retrieves a large number of rows). Evaluate the performance of the index in several different situations to confirm its ineffectiveness before dropping it.

246 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 9: Optimizing Query Performance

Using Indexes to Improve Query Performance

Check the query plans of the queries you most often use to see if the Optimizer is using your indexes. Because the Optimizer always attempts to choose the most efficient method to return the answer to your query, if you notice that the Optimizer consistently chooses a full-table scan instead of using your indexes, this indicates that you need to redesign your indexes or refresh stale collected statistics.

Reference Information

Information on...

overview of indexes designing and using indexes

Is available in...

•

Introduction to Teradata, B035-1091

•

Database Administration, B035-1093

•

SQL Fundamentals, B035-1141

•

Database Design, B035-1094

•

SQL Data Definition Language Detailed Topics, B035-1184

SQL Data Definition Language Syntax and Examples, B035-

1144 syntax and options for secondary indexes:

•

CREATE INDEX

•

DROP INDEX syntax and options for join indexes:

•

CREATE JOIN INDEX

•

DROP JOIN INDEX

Teradata Index Wizard utility Teradata Index Wizard User Guide, B035-2506

Teradata Data Warehouse Appliance 2800 Implementation Guide 247

Chapter 9: Optimizing Query Performance

Checkpoint

Before leaving Chapter 9: “Optimizing Query Performance,”

make sure that:



Result

You collected statistics on tables.

You know how to use the EXPLAIN request modifier to analyze query plans.

You know how to implement secondary and join indexes and have considered their costs and benefits.

Reference

“Using COLLECT STATISTICS to

Optimize Query Performance” on page 233

“Using EXPLAIN to Analyze Query

Plans” on page 239

“Using Indexes to Improve Query

Performance” on page 240

If you do not have these results, return to the section in the Reference column and review that procedure.

248 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 10

Setting Up Users

This section presents the administrative tasks required to create users and provide them the privileges necessary to access the database.

Required Tasks

For best results, perform all the tasks in this section completely and in the order presented.

Group potential database users by functional group and determine database access needs.

See

“User Evaluation” on page 249 .

Set up user accounts to track resource usage and assign workload priorities. See

“Working with Profiles” on page 254 .

Set up profiles to define resources, account assignments, and password control parameters for groups of users.

Create database users and assign profiles, space and accounts. See

“Working with Database

Users” on page 257 .

Create roles to define privileges for users groups and grant role membership to users.

“Using Roles to Manage User Privileges” on page 261

Grant additional privileges that are not suitable for role assignment directly to users. See

“Granting Privileges Directly to Users” on page 269 .

User Evaluation

About User Requirements

The following list identifies five typical user types and job functions.

Functional Category Description

General users Database end-users who only need to read the data or to run pre-existing queries or macros to generate reports.

Update users Privileged users who perform some general user functions and who also may need to insert, update or delete data, and create new database objects.

Teradata Data Warehouse Appliance 2800 Implementation Guide 249

Chapter 10: Setting Up Users

User Evaluation

Functional Category Description

Batch users High-level users who typically perform batch-level functions, for example:

•

Load, update, and export operations, including creation and deletion of staging tables.

•

Data backup, archive, and restore operations.

Database programmers

Assistant administrators

Users who design and create queries, macros, and stored procedures, as well as database objects, for use by the user community. Programmers may require administrator privileges within a development database, while needing only limited privileges in the main production database.

Administrative users that assist the principal administrator, user DBADMIN,

created in “Creating User DBADMIN” on page 161

. Assistant administrative users may have most or all of the same privileges granted to user DBADMIN, but have a much smaller permanent space allocation because they have a limited ownership of objects

Note: You can create additional user types where necessary to identify functional differences, however, the examples provided in this publication are based on these user types.

Determining Database User Needs

Assess database user needs and develop a user management strategy before you begin executing user management setup tasks.

Create a list of all users that require access to Teradata Database and identify each one according to user type. Minimize the number of user types to simplify user management.

Define user resource requirements for use in creating profiles:

•

Examine user space requirements.

•

Users that create or own databases, tables and other space-consuming objects require permanent storage space (perm space).

•

Users that execute SQL queries, macros, or stored procedures require spool space to contain the required temporary database structures. The spool specification in a profile limits the amount of available space a profile member can use.

•

Define user accounts based on job type and system resource requirements. Each profile can include one or more account definitions. See

“Working with User Accounts” on page 251 .

•

Define the user default database, that is, the database where the user most often works.

•

Define password control parameters. Refer to the chapters on password controls and managing passwords in Security Administration, B035-1100. Consider your site security policy and decide whether or not all users can share global password parameters, or if you need to set them by user group, in profiles.

Review the database objects (such as views, tables, macros, functions, and procedures) that users or user groups must access to do their job. Always define user privileges in the database at the highest level that is appropriate for the user. For example, if a user requires the same privileges on all views in a database, assign privileges at the database level.

250 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Working with User Accounts

Identify groups of users with common database privilege requirements and create roles to define the privileges for groups of users instead of individuals. Consolidate minor differences in access requirement where possible to minimize the number of roles.

You may need to assign specialized privileges directly to individual users.

Working with User Accounts

About Accounts

You can use accounts to:

•

Require the system to tag each session with a number, time stamp and date stamp for

monitoring and accounting purposes. See “Creating Account Strings” on page 252

•

Charge for space or processing resources used. See

“Managing User Activity with

Accounts” on page 305 .

•

Assign workload management parameters that define database access priorities. See

“Teradata Integrated Workload Management” on page 308

Teradata recommends that you devise an account system based on the jobs and resource requirements common to groups of users, and then assign accounts to users in profiles.

Specify one or more accounts for each profile, as required by profile members, using the

CREATE PROFILE or MODIFY PROFILE statement. Specifying an account in a profile

“creates” the account. You can specify the same account in more than one profile, if needed.

The first account listed for a profile is the default account for member users.

Although you can also define accounts in a CREATE USER or MODIFY USER statement, it is not recommended because the presence of an account in a user profile supersedes and invalidates any accounts specified in the user definition.

Active accounts and account assignments are listed in DBC.AccountInfoV.

Reference Information

Information on...

specifying the account string at logon accounts valid accounts and account assignments precedence of accounts in a session

Is available in...

•

Security Administration, B035-1100

•

The logon section in the User Guide for each Teradata tool or utility

Database Administration, B035-1093

•

See

“Managing User Activity with Accounts” on page 305

•

DBC.AccountinfoV in Data Dictionary, B035-1092

“Determining the Account for a User Session” on page 253

Teradata Data Warehouse Appliance 2800 Implementation Guide 251

Chapter 10: Setting Up Users

Working with User Accounts

Creating Account Strings

An account string should follow this format:

‘$G

0+account_ID&S&D&H’

If a user or profile definition specifies more than one account string, the individual strings must be separated by commas and the entire list of strings enclosed by parentheses.

Note: When designing your account system, consider how accounts may be used in assigning workload management parameters. See

“Teradata Integrated Workload Management” on page 308

where:

Element Description

Required Account String Variables

$G0+ The performance group identifier that determines the default priority level for a user session. This identifier was applicable to previous Teradata

Database releases, but no longer determines the priority level for sessions that use the account.

The session priority is determined by the priority access level defined using the Viewpoint Workload Designer portlet. For information, see

“Using

Workloads to Define Query Priority Level” on page 312

Recommendation: Use this section of the account string to note a suggested a default priority level for account members that can be used when constructing workload management rules. This ignored by the system, however, the character count shown to precedes the account ID in this example is required for compatibility with certain administrative tools:

•

$R0+ = Rush (Top)

•

$H0+ = High

•

$M0+ = Medium (default)

•

$L0+ = Low

Note: The 0 and + characters are not actually part of the priority level:

•

The 0 designates the default and only virtual partition (resource partition) allowed on Teradata Data Warehouse Appliance 2800.

•

The + character is a place holder that forces the account_ID to start at the fifth character, required for compatibility with some administrative tools.

252 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Working with User Accounts

Element

account_ID

Description

A four character string that uniquely identifies the account.

Recommendation: You can use the account_ID to differentiate among accounts and describe the account function.

•

Department such as finance (FIN) or marketing (MKT)

•

Job function such as batch processing (B), general use (G), or update (U).

For example:

FINB or MKTU

Note: Although more characters are allowed, using a four-character

account_ID maintains application compatibility and helps prevent the account string from exceeding the 30 character limit when ASE is applied.

Note: Extended object naming is available, which allows account strings to be up to 128 characters. The maximum length of an account string is limited to 30 bytes on systems in which extended object naming is not enabled. The

30-byte limit can truncate some extended account strings. For information about enabling extended object naming, see Database Administration, B035-

1093.

Account String Expansion (ASE) Variables

Teradata Database tags each session with information specified by the ASE variables for later use in management of database sessions. Each ASE variable expands to the number of characters needed to express the related information. The 30-byte string limit is enforced against the expanded form, unless your system has extended object naming enabled. For information about enabling extended object naming, see Database Administration, B035-1093.

Specification of the ASE variables shown below is optional, but recommended. Other variables are available. See Database Administration, B035-1093.

The ampersand (&) designates an account string expansion (ASE) variable.

Teradata Database automatically replaces these variables with actual values when the system establishes a session. You can use ASE variables for resource accounting and charge-back, for example, charging users a premium for resource usage during peak hours.

You can use any or all of the following:

•

&S = the session number (9 digits, system generated)

•

&D = the date (for example, July 4, 2009 appears as 090704)

•

&H = the time (2 digits, based on the 24-hour clock)

The system records database activity in the DBC.Acctg table and

DBC.AmpUsageV view by account, substituting the actual value for any specified ASE variables. A new entry appears in DBC.Acctg if a variable value changes during the session, for example, an hour change from 16 to 17.

Each row includes information on CPU, I/O, and vproc usage. See Data

Dictionary, B035-1092.

Determining the Account for a User Session

The system determines the account for a user when the user logs on as follows:

•

If the user has no account assignment, the session defaults to the first account listed for the owning user or database. Using default owner accounts is not recommended.

Teradata Data Warehouse Appliance 2800 Implementation Guide 253

Chapter 10: Setting Up Users

Working with Profiles

•

If the user definition has one or more account assignments, the system uses the first account by default.

•

If the profile for the user also contains one or more account assignments, the first profile account takes precedence over and user accounts and other profile accounts.

•

If a valid account for the user is specified in the client application, for example, in the

ODBC driver connection presets, the client account specification takes precedence over any applicable user and profile account specifications.

•

If the user has multiple assigned accounts in the user or profile definitions:

•

The user can specify an account in the logon string, which takes precedence. For example:

.logon tdpid/username,password,”account”

•

During a session, the user can submit a SET SESSION ACCOUNT statement to change the session to another assigned account.

Working with Profiles

About Profiles

You can create profiles to define resource parameters for groups of users with similar needs instead of defining them for each individual user. To assign the profile to a user, specify the profile name in a CREATE or MODIFY USER statement to give membership in the profile to the user.

Profiles can be based on the primary user types such as those shown in “About User

Requirements” on page 249 , or other factors that group users according to database resource

requirements.

Use profiles to specify parameters such as:

•

Permanent and spool space allocations

•

User account(s)

•

Password control parameters

•

Default database assignment

Creating Profiles

Start Teradata Administrator and log on as user DBADMIN.

From the main screen, click the Preview Mode button generated SQL.

to allow future display of

Click Tools>Create>Profile.

In the Profiles screen, enter values for the profile parameters.

In the Profile Name dialog box, enter a unique name for the profile.

254 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Working with Profiles

Recommendation:

•

The profile name can include such things as the user type or user department to identify its function. For example, WebUser_Profile or FinanceReport_Profile.

•

Consolidate user requirements where possible to avoid the unnecessary proliferation of profiles.

Click the General tab. Specify values for the following fields or controls.

Note: Profile values supersede corresponding values in a CREATE USER statement.

Field or Control

Account

Description

The database uses accounts for user job tracking and to prioritize requests.

Recommendation: Enter one or more account strings in accordance with

the format shown in “Working with User Accounts” on page 251 .

If you assign more than one account string to a profile, enclose each string in apostrophes, separate the strings with commas and enclose the complete specification in parentheses. For example, for the FinanceReport_Profile you may want to specify accounts for short decision support queries, small reports, and large monthly reports, as follows:

(‘$M0+FNDS&S&D&H’,‘$L0+FNSR&S&D&H’, ‘$R0+FNMR’)

Default Database Optional. The database the user is most likely to access.

If no name is specified, the system uses the name specified in the user definition (CREATE USER statement).

Recommendation: Specify the default database at the user level, rather than in the profile, to allow for differences in user default database requirements.

Teradata Data Warehouse Appliance 2800 Implementation Guide 255

Chapter 10: Setting Up Users

Working with Profiles

256

Field or Control

Spool Space

Description

This value limits the amount of space available for intermediate query results or formatted answer sets to queries and volatile tables. Spool space for a user is shared among the queries that user is executing concurrently.

The system borrows spool space for a user from unused permanent space in the system.

Recommendation: Spool space requirements in a profile depend on the activities of member users. Begin by specifying spool space in bytes according to the following percentages of the total perm space allocation for

the Spool_Reserve database created in Chapter 5: “Setting up

Administrative Users.”

•

General users: 5%

•

Update users: 10%

•

Batch users: 10%

•

Assistant administrative users: 10%

•

Database programmers: 10%

Periodically monitor usage patterns as shown in

“Identifying and

Correcting Space Problems” on page 296 , and modify spool space

assignments when required using the MODIFY PROFILE statement.

Spool space can also be specified as part of a CREATE USER statement or modified as part of a MODIFY USER statement.

Note: Profile members that do not require permanent space must still be allocated a small amount of spool space in the profile, for example, 1 MB.

Temporary Space Not applicable. Required only when using global temporary tables and other advanced features.

Recommendation: Temporary space is not normally needed. If necessary, you can add a temporary space specification later with a MODIFY

PROFILE statement.

c d e

Click the Password tab to display the nine password control parameters.

Optional. The control parameters allow you to apply different settings in the profile than are in the global default settings created in DBC.SysSecDefaults, as part of step 2

in “Setting Up the Database Administrator User” on page 158

Recommendation: Do not reset any password control parameter values in a profile unless the profile members cannot use the system defaults. For each profile password control that you change from the global value, enter the new value in the box to the right of the control name.

Do not use the Users in Profile dialog box at this time. You can specify profile membership as follows:

•

Assign a profile to each user as part of “Working with Database Users” on page 257

•

After creating users, use a MODIFY PROFILE statement to include member users.

Click the Create button to create the profile. The Query Window displays a generated

CREATE PROFILE statement similar to the following:

Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Working with Database Users

CREATE PROFILE profile_name AS

ACCOUNT = (‘account_str1’,’account_str2’)

DEFAULT DATABASE = database_name,

SPOOL = spool_space,

PASSWORD =

(EXPIRE = n_days,

MAXLOGONATTEMPTS = attempts,

LOCKEDUSEREXPIRE = n_minutes)

5 f

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Profiles dialog box.

Close Teradata Administrator or go on to “Working with Database Users” on page 257

Reference Information

For Step...

Information on...

4 syntax and options for the

CREATE PROFILE statement

4b using accounts to enforce session priorities

Is available in...

SQL Data Definition Language Syntax and

Examples, B035-1144

•

“Teradata Integrated Workload Management” on page 308

•

“Setting Up Workload Management” on page 309

•

Database Administration, B035-1093

Adding ASE variables to an account string guidelines for determining user space requirements information on monitoring and reallocating space global temporary tables password control options

Database Administration, B035-1093

“About Space Management” on page 293

Database Design, B035-1094

Security Administration, B035-1100

Working with Database Users

About Users

This task creates individual database users, including lower level administrators, database programmers and other privileged users, and database end-users.

Teradata Data Warehouse Appliance 2800 Implementation Guide 257

Chapter 10: Setting Up Users

Working with Database Users

Creating Users

Start Teradata Administrator and log on as user DBADMIN.

Note: This procedure creates users individually. To automate the creation of users by using

BTEQ scripts, see “Using BTEQ Scripts to Create Database Objects” on page 196 .

From the main screen, click the Preview Mode button generated SQL.

Do the following to create a user:

Click Tools>Create>User.

to allow future display of

In the Create User dialog, specify the values for the required fields and controls.

Field or Control

User Name

Owner

Password

Permanent Space

Explanation

Required. The name of an individual Teradata Database user.

Each database user should be uniquely identified for accurate logging. Do not allow users to share a username for accessing the database.

Note: The username must conform to the rules for SQL object names.

Required. The name of the database or user that owns the space in which the user is created.

Recommendation: DBADMIN. All users should be created in space owned by the database administrator.

Required. A temporary password. The user is prompted to change the temporary password to a permanent, private password at first logon.

May be required. Space in bytes that can be used to contain objects the user creates or owns. Permanent space is required for those users that create and store space-consuming objects.

Recommendation: Base the permanent space specification on user needs.

•

General users: Not required.

•

Update users: Required if users create and store objects.

•

Batch users: Required if users create and store objects.

•

Assistant administrators: Required if users create and store objects.

•

Database programmers: Required to create and store objects.

258 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Working with Database Users

Field or Control

Spool Space

Temporary Space

Account

Default Database

Explanation

Optional. Specifies the limit to the amount of space in bytes available for temporary process constructs such as intermediate query results or formatted answer sets to queries and volatile tables. Spool space for a user is shared among the queries that user is executing concurrently.

The system borrows user spool space from any unused permanent space found on the system.

The spool space specification in a profile takes precedence over spool space specified in a CREATE USER statement.

Recommendation: Specify spool space as part of a profile unless the user requires special spool considerations.

If you do enter a value for an individual user, specify approximately 20% of the perm space available to the largest database the user will query.

Not applicable. Required only when using global temporary tables and other advanced features.

PROFILE statement.

Optional. You can set up user account information to form the basis of various user management options.

Recommendation: If possible, do not specify accounts at the user level, unless the user requires a unique account. Instead specify one or more accounts in the profile in which the user has membership. For information, see

“Working with Profiles” on page 254 .

Note:

If a user is a member of a profile that specifies one or more accounts, the profile account assignment supersedes and invalidates all account assignments specified in the user definition.

Optional. Identifies the database that owns the space in which the

Teradata Database stores or searches for new or target objects in an SQL query, unless a different database is specified in the query.

Note: Users can use the DATABASE statement to establish a new default database for the current session.

Recommendation: Specify the database most often accessed by the user.

•

General users: Specify a read-only Views database. If restrictions are necessary, use role privileges to allow access to particular views.

•

Update users: Specify either a read-only Views or an updatable Views database, depending on where the user normally works.

•

Batch users: Specify the Tables_Database, where batch operations take place.

•

Assistant administrators: Specify DBADMIN.

•

Database programmers: Specify the name of the development database.

Teradata Data Warehouse Appliance 2800 Implementation Guide 259

Chapter 10: Setting Up Users

Working with Database Users

Field or Control

Profile Name

Default Role

Explanation

Optional. Gives the user membership in the named profile.

For syntax elements that appear in both the CREATE USER statement for a user, and in a profile in which the user is a member, the profile values take precedence.

A user can be a member of only one profile.

Recommendation: Specify profile membership for all users. Select from the drop-down list and highlight the needed profile.

Identifies the default role used for determining user privileges in the database for the current session. This is usually the role associated with the activities performed most frequently by the user.

Note: The user can employ the SET ROLE statement at the beginning of a session or transaction to change from the default role to another role. The

SET ROLE ALL statement allows access to all roles of which the user is a member.

Recommendation: You may specify a default role later after you have created the user and the roles. See

“Defining the Default Role for a User” on page 268 . Note that you must specify a default role even if the user is a

member of only one role.

Optional.

Recommendation: Do not use for initial database implementation.

Default Journal

Startup String

Before Journal

After Journal

FALLBACK

Collation

Time Zone

Default Date Form

Default Character

Set

Optional. Specification of FALLBACK automatically creates a duplicate of each table stored in the user space, in addition to the duplicates already created by disk mirroring. The system reverts to the FALLBACK tables in the event of a failure.

Recommendation: Specify FALLBACK only for individual missioncritical tables or tables so large that their size prevents timely backup to tape or external disk.

Optional. Database default values that apply to all users are already set as part of system installation and configuration.

Recommendation: Do not change the default values for a user unless the default value is not applicable.

Note: All users must use the same collation value.

260 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

Click the Create button. The Query Window displays the generated CREATE USER statement, similar to the following:

CREATE USER "GenUser1" FROM "DBADMIN"

AS PERM = 0

PASSWORD = "temp123"

STARTUP = ''

DEFAULT DATABASE = "Personnel_Views"

NO FALLBACK

NO BEFORE JOURNAL

NO AFTER JOURNAL

PROFILE=”GenUser_Profile”

4 d

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Create User dialog box.

Log off Teradata Administrator or go on to “Using Roles to Manage User Privileges” on page 261 .

Reference Information

For Step...

Information on...

Is available in...

syntax and options for the CREATE

USER statement

SQL Data Definition Language Syntax and

Examples, B035-1144 assigning permanent and spool space Database Administration, B035-1093 the creation and use of accounts

“Creating User Roles” on page 264

Using Roles to Manage User Privileges

Do the following to setup roles to manage user privileges:

Create roles, as shown in

Grant privileges to each role, as shown in “Granting Privileges to a Role” on page 265 .

Grant role membership to users, as shown in

“Granting User Membership in a Role” on page 267 .

Note: Some privileges cannot be granted to a role. You must grant those privileges directly to

a user. For information, see “Granting Privileges Directly to Users” on page 269 .

Teradata Data Warehouse Appliance 2800 Implementation Guide 261

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

User Types and Minimum Required Privileges

The following table describes the minimal privileges required by the three basic user types.

User Type

General

Update

Privilege Requirements

Database end-users who typically read data and execute macros in a read-only

Views database created in

shown in “Working with Table Access Privileges for Views” on page 178 .

Assign the following privileges on a read-only Views database to all General users:

•

EXECUTE

•

SELECT

The read-only Views database must have privileges on the Tables_Database, as

Privileged database users who update data generally require the following privileges:

Privileges required on a read-only Views database:

•

EXECUTE

•

SELECT

•

CREATE VIEW and DROP VIEW

•

CREATE MACRO and DROP MACRO

Privileges required on an updatable Views database:

•

EXECUTE

•

SELECT

•

INSERT, UPDATE, and DELETE

•

EXECUTE PROCEDURE

•

EXECUTE FUNCTION

•

CREATE VIEW and DROP VIEW

•

CREATE MACRO and DROP MACRO

Additional recommended privileges on an updatable Views database for database programmers:

•

SHOW

•

ALTER, CREATE, and DROP PROCEDURE

•

ALTER, CREATE, and DROP FUNCTION

•

ALTER and CREATE EXTERNAL PROCEDURE

•

CREATE TRIGGER and DROP TRIGGER

To provide update capability on views, you must grant the updatable Views database SELECT, INSERT, UPDATE, DELETE WITH GRANT OPTION privileges on the referenced tables in the Tables_Database, as shown in

“Working with Table Access Privileges for Views” on page 178

262 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

User Type

Batch

Assistant

Administrators

Database

Programmers

Privilege Requirements

Data movers, who typically perform batch-level functions, such as:

•

Batch data load, update, and export operations.

•

Data backup, archive, and restore operations, including creating and deleting staging tables.

Batch users must have the following privileges on the Tables_Database:

•

SELECT

•

INSERT, UPDATE, DELETE

•

DUMP and RESTORE

•

CHECKPOINT

•

CREATE TABLE and DROP TABLE

If you need one or more assistant administrators to help share administrative duties, they may require the same privileges as those granted to DBADMIN, or a subset of those privileges. Use the procedure shown in

“Setting Up the Database

Administrator User” on page 158

and

“Granting Database Privileges to User

DBADMIN” on page 163

to create assistant administrators and grant the privileges they need.

Database programmers may require administrator-level privileges within the development database to allow them to create and test database objects.

Administrators can then deploy the objects to the production database.

Types of Privileges

You can explicitly grant database privileges to users, roles, or databases. Users also gain other privileges without a formal grant. Before you decide which privileges to explicitly grant, make sure you understand the privileges users receive by other means.

Privilege

Implicit Privileges

Ownership

Description

Users that own perm space have certain implicit (ownership) privileges on any object contained in the space they own, even if they did not create the object.

Note: You can transfer ownership using the GIVE statement.

Explicit privileges

Automatic When a user creates a database object, Teradata Database automatically grants privileges to:

•

The creator of the object

•

A newly created user or database

Teradata Data Warehouse Appliance 2800 Implementation Guide 263

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

Privilege

GRANT

Inherited

Description

You can grant privileges:

•

Directly to a user or database

•

To a role, then GRANT membership in the role to one or more users

•

To an external role, then map the external role to one or more groups of directory users

Privileges that a user acquires indirectly.

•

All users inherit the privileges of the system-generated user, PUBLIC, a role-like collection of privileges available by default, whether or not they have any other privileges. You can grant additional privileges to PUBLIC.

•

A user inherits all the privileges granted to each role of which the user is a member.

•

Directory users inherit the privileges of the database users and external roles to which they are mapped.

Note: The system logs automatic and explicit privileges in exactly the same way, and are indistinguishable as to how they were acquired. All privileges except implicit privileges are stored in the data dictionary in the DBC.AccessRights table, by each user.

For a detailed discussion of privileges, see “Teradata Database User Privileges” in Chapter 5:

“Creating Users and Granting Privileges” in Security Administration, B035-1100.

Privileges That Must Be Explicitly Granted

Some privileges cannot be acquired by indirect means and must be explicitly granted to a user, database, or role. For information, see “Privileges that Must Be Explicitly Granted” in Security

Administration, B035-1100.

Creating User Roles

Start Teradata Administrator and log on as user DBADMIN.

On the main screen, click the Preview Mode button generated SQL.

to allow future display of

Click Tools>Create>Role.

In the Roles dialog, use the Role Name field to specify a unique role name. The role name should also provide some indication of the role function or the group of users to which it applies, for instance:

•

FinanceUser_Role

•

Update_Role

Click the Create button. The Query Window displays the generated CREATE ROLE statement:

CREATE ROLE role_name

264 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

In the Query Window, click the Run Query button. A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Roles dialog box.

Repeat this procedure to create the needed roles.

Log off Teradata Administrator or go on to “Granting Privileges to a Role” on page 265

Granting Privileges to a Role

Use the GRANT statement to grant privileges to the roles necessary to serve the basic user types. A GRANT statement takes the following basic form:

GRANT privilege

ON database_object_name

TO role_name

Start Teradata Administrator and log on as user DBADMIN.

From the main screen, click the Preview Mode button generated SQL.

Grant privileges to each role as follows:

Click Tools>Grant/Revoke>Object Rights.

to allow future display of

In the Grant/Revoke Objects dialog, specify values for the following:

Fields and Controls Explanation

Database Name Required.

•

To grant privileges on an entire database, specify the name of the database.

•

To grant privileges on an object, specify the parent database that contains the object.

Recommendation: When specifying privileges for:

•

General users, select a read-only Views database.

•

Update users, select a read-only Views database or an updatable Views database.

•

Batch users, select the Tables_Database.

•

Administrative users, select DBADMIN.

•

Database programmers, select a Development database.

Teradata Data Warehouse Appliance 2800 Implementation Guide 265

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

Fields and Controls Explanation

Object Type Required.

Specify the type of database object on which privileges are being granted.

For example:

•

To grant privileges on the Tables_Database, specify Database.

•

To grant privileges on the tables located in the Tables_Database, specify Table.

Recommendation: Always grant privileges at the highest level that is appropriate, while observing security concerns and user “need to know.”

Objects Required when objects are displayed.

If the Object Type is Database, this field is blank and not required.

Otherwise, the Objects field displays all of the database objects of the object type contained in the named database.

For example, if Database Name is Tables_Database and Object Type is

Table, this field displays all of the tables contained in the

Tables_Database.

Select the specific database object on which privileges are being granted.

To/From User

Role

Public

Not applicable for granting privileges to roles.

Required. The role to which the specified privileges are granted.

Select the name of a previously created role from the displayed list.

Optional.

Checking the Public box grants the specified privileges to PUBLIC, a group of rights accessible by any user with logon privileges, even if no other privileges have been granted.

Recommendation: Do not grant additional privileges to PUBLIC at this time.

Normal

Create

Drop

All

Dictionary

Access

All But

Required. Specify the privileges by checking the boxes, based on the guidelines in

“User Types and Minimum Required Privileges” on page 262 .

Recommendation: Consider the privileges that the user may get without

formal granting, as shown in “Types of Privileges” on page 263

, before deciding on what privileges to grant.

Optional. Do not use for roles.

Grants all privileges that apply on the database object. This box is usually used only for the master administrator, DBADMIN.

Optional. Grants administrative privileges on data dictionary tables.

Optional.

Provides basic SELECT and EXECUTE privileges on the specified object.

Optional.

When the All But box is checked, role members receive all privileges except those checked in the Normal, Create, and Drop sections.

266 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

Not all privileges need to be granted using roles. It may be more efficient to grant some specialized privileges directly to a user, rather than creating a role with a membership of one.

Note: Any user can grant privileges on any database object it owns to any other user or role, excluding the CREATE and DROP privileges, which are not ownership privileges.

Click the Grant button. The Query Window displays the generated GRANT statement, for example:

GRANT EXECUTE, SELECT, INSERT, UPDATE, DELETE, DUMP, RESTORE,

CHECKPOINT, CREATE TABLE, DROP TABLE ON "Tables_Database" TO

"Role_BatchUser_2"

5 d

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Grant/Revoke Objects dialog box.

Repeat this procedure to grant privileges to all roles.

Close Teradata Administrator or go to

“Granting User Membership in a Role” on page 267 .

Reference Information

For Step...

Information on...

3 syntax and options for the GRANT

(SQL Form) statement using roles to manage user access

Is available in...

SQL Data Control Language, B035-1149

Security Administration, B035-1100

Granting User Membership in a Role

After creating database users, grant them membership in one or more roles to provide the required database access privileges.

Start Teradata Administrator and log on as user DBADMIN.

On the main screen, click the Preview Mode button generated SQL.

to allow future display of

Click Tools>Create>Role.

In the Roles dialog, select a role from the Role Name drop-down menu.

Click the Users tab.

Select all users that will be members of the selected role, and click Add.

The Query Window will display a GRANT statement similar to:

Grant "Role_1" To "GenUser1";

Teradata Data Warehouse Appliance 2800 Implementation Guide 267

Chapter 10: Setting Up Users

Using Roles to Manage User Privileges

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Roles dialog box.

Repeat this procedure for each role to which a user requires membership.

Log off Teradata Administrator or go to “Defining the Default Role for a User” on page 268 .

Reference Information

For Step...

Information on...

3 syntax and options for the

CREATE ROLE statement using roles to manage user access syntax and options for the GRANT

(SQL form) statement database privileges, including those conferred by object ownership syntax and options for GRANT

(Role form)

Is available in...

SQL Data Definition Language Syntax and

Examples, B035-1144

Security Administration, B035-1100

SQL Data Control Language, B035-1149

Defining the Default Role for a User

To ensure that role privileges are available to users at log on, you must define a default role for each user that is a member of one or more roles. If you do not specify a default role, the user must employ the SET ROLE statement to select the operant role. For example:

SET ROLE role_name; or

SET ROLE ALL;

You can also use the SET ROLE statement to change from one role to another role within a session.

To ensure that the user is operating with the appropriate role, specify the default role for a user as follows:

Start Teradata Administrator and log on as user DBADMIN.

On the main screen, click the Preview Mode button generated SQL.

Click the + next to DBADMIN to display the list of users.

to allow future display of

268 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Granting Privileges Directly to Users

Select the user you want to modify.

Click Tools>Modify User.

In the Modify User dialog, click the Default Role drop-down menu and select a default role.

You can optionally select All Roles, which will allow access to all roles of which the user is a member.

Click the Modify button. The Query Window displays the generated MODIFY USER statement, for example:

MODIFY USER "GenUser1" AS

STARTUP = ''

DEFAULT DATABASE = "Personnel_Views"

NO FALLBACK

NO BEFORE JOURNAL

NO AFTER JOURNAL

COLLATION = HOST

DEFAULT CHARACTER SET LATIN

DATEFORM=INTEGERDATE

TIME ZONE=NULL

DEFAULT ROLE="Role_GenUser_2"

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Modify User dialog box.

Repeat this procedure to specify the default role for each user who is a member of a role.

Log off Teradata Administrator or go on to “Granting Privileges Directly to Users” on page 269 .

Reference Information

For Step...

Information on...

1 syntax and options for the SET ROLE statement

7 syntax and options for the MODIFY

USER statement, including the default role using roles to manage user access

Is available in...

SQL Data Definition Language Syntax and

Examples, B035-1144

SQL Data Definition Language Syntax and

Examples, B035-1144

Security Administration, B035-1100

Granting Privileges Directly to Users

Some privileges cannot or should not be granted to roles, but should instead be granted directly to users.

•

System-level privileges that cannot be granted to a role, as shown in

“Granting Database

Privileges to User DBADMIN” on page 163 .

Teradata Data Warehouse Appliance 2800 Implementation Guide 269

Chapter 10: Setting Up Users

Granting Privileges Directly to Users

Note: System-level privileges are normally used by administrators and should not be granted to other users.

•

Object-level privileges that apply to too few users to require creation of a role.

Note: A user automatically has the privilege to grant most privileges on any database object the user owns to any other user or role. This excludes CREATE and DROP privileges, which are not automatic ownership privileges. The CREATE and DROP privileges must be granted directly to a user, and must include the WITH GRANT OPTION clause, before that user can grant these privileges to others. For information on ownership privileges, see Security

Administration, B035-1100.

Prerequisites

You can only grant privileges to users that already exist in the database. For information on creating users, see

“Working with Database Users” on page 257 .

The Sys_Calendar database and Calendar view must exist. They are normally created as part of system installation by running the DIPALL script.

Granting Privileges on Sys_Calendar to All Users

Sys_Calendar is a system database used to contain the Sys_Calendar.CalDates table and

Sys_Calendar.Calendar view. The Calendar view is a user-accessible tool for date arithmetic. It permits easy specification of arithmetic expressions and aggregation, and is particularly useful when requesting values aggregated by weeks, months, year-to-date, years, and so on. You can use the Calendar view to get attributes for any date between the years 1900 and 2100, such as which day of the week or which week of the month a date occurs.

Use the following procedure to grant SELECT privilege on Sys_Calendar to all Teradata

Database users.

Start Teradata SQL Assistant and log on as DBADMIN.

Enter the following statement in the main query window:

GRANT SELECT ON Sys_Calendar TO PUBLIC

Click the Execute button

Close Teradata SQL Assistant.

to run the query.

Reference Information

For Step...

Information on...

All Sys_Calendar and the Calendar view

Is available in...

Data Dictionary

270 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 10: Setting Up Users

Granting Privileges Directly to Users

Granting Privileges to a User

Start Teradata Administrator and log on as DBADMIN.

From the main screen, click the Preview Mode button generated SQL.

Click Tools>Grant/Revoke>Object Rights.

In the Grant/Revoke Objects dialog, specify the following:

to allow future display of

•

Use the Database Name, Object Type, and Objects fields to identify the database object which the user will receive privileges on.

•

In the To/From User tab, select the user who will receive the specified privileges.

•

In the Normal, Create, or Drop sections, check the privileges the user will receive.

For details, see “Granting Database Privileges to User DBADMIN” on page 163 .

Click the Grant button. The Query Window displays the generated GRANT statement similar to:

GRANT privilege

ON database_object_name

TO username; where

•

The ON clause is based on the values of the Database Name, Object Type, and Objects fields.

•

The TO clause is based on the user selected from the To/From User tab.

In the Query Window, click the Run Query button . A Query Complete message appears in the bottom left corner of the main window when the query executes.

Close the Query Window and the Grant/Revoke Objects dialog box.

Log off Teradata Administrator.

Reference Information

For Step...

Information on...

5 syntax and options for the GRANT

(SQL form) statement database privileges, including those conferred by object ownership

Is available in...

SQL Data Control Language, B035-1149

Security Administration, B035-1100

Teradata Data Warehouse Appliance 2800 Implementation Guide 271

Chapter 10: Setting Up Users

Checkpoint

Before leaving Chapter 10: “Setting Up Users,”

make sure that:



Result

You have assessed database user needs and developed a user management strategy.

Reference

“About User Requirements” on page 249

You have created accounts for all user categories

“Working with Profiles” on page 254

Profiles define resource parameters for groups of users with similar needs.

Individual database users, including administrators and end users, have been created.

Roles are created in your database, each role has privileges, and users have been granted role membership.

Some users, such as administrators and those who need uncommon object-level privileges, have had privileges granted to them directly.

“Working with Database Users” on page 257

“Using Roles to Manage User

Privileges” on page 261

“Granting Privileges Directly to Users” on page 269

If you do not have these results, return to the section in the Reference column and review that procedure.

272 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 11

Monitoring Database Access

This chapter describes how to log user access attempts and monitor the access logs to detect issues.

About Access Logging

You can log user access to the database, and then audit the logs to identify:

•

User logon frequency

•

Database objects accessed

•

Privileges checked

•

Failed access attempts

•

Possible unauthorized activities

Default Access Logging

By default, Teradata Database records all permanent user attempts to log on and off Teradata

Database in the Event Log.

Common Access Logging Requirements

A common rationale for logging and auditing user access to the database is the Payment Card

Industry Data Security Standard (PCI-DSS), which requires that all retailers, financial institutions, and payment processors that store information on credit card holders must provide audit trails that allow reconstruction of all instances of the following events:

•

Attempts to access cardholder data

•

Actions of any type taken by any individual with root or administrative privileges

•

Invalid access attempts

•

Creation and deletion of system-level objects

•

Initialization of the audit logs (use of the BEGIN/END LOGGING statement)

•

Attempts to access audit trails

•

Use of identification and authentication mechanisms

The example logging and auditing procedures in the sections that follow are based on the PCI-

DSS requirements, but they can be used to monitor access to any sensitive data.

Teradata Data Warehouse Appliance 2800 Implementation Guide 273

Chapter 11: Monitoring Database Access

Setting Up Access Logging

Note: The procedures shown in the following sections are provided only as examples, and do not in themselves guarantee compliance with PCI-DSS requirements.

For additional information on logging and auditing options, see Security Administration.

Setting Up Access Logging

Running the DIPACC Script

The DBC.AccLogRule macro must exist in the database before initiating access logging. You can create this macro with the DIPACC script.

Log on to the control node as shown in “Logging On to the Control Node” on page 333

At the Input Supervisor Command prompt, start the DIP utility.

Open a cnsterm window as shown in steps 1 and 2 of

“Using cnsterm to Run a Database

Utility” on page 334 .

> start dip

Hold the

Ctrl

key while pressing the

key to exit the Supervisor Window.

At the Linux command prompt start cnsterm again, this time specifying the application window in which the DIP utility is running.

# cnsterm 1

At the prompt on cnsterm screen 1, enter:

> DIPACC

The system returns a message similar to the following:

Executing DIPACC at Wed Sep 16 15:54:06 2009

Please wait...

DIPACC is complete at Wed Sep 16 15:54:06 2009

Please review the results in /var/opt/teradata/tdtemp/dip18.txt on node 4- 9

Would you like to execute another DIP script (Y/N)?

Enter

at the prompt to exit DIP.

Close the Client Connection window.

Close the Teradata Administration Workstation window.

About the BEGIN LOGGING Statement

You can enable access logging using the BEGIN LOGGING statement.

The basic form of the BEGIN LOGGING statement is:

BEGIN LOGGING ON frequency operation BY username ON object_name ;

274 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 11: Monitoring Database Access

Setting Up Access Logging where:

Syntax Element

frequency operation username object_name

Description

The frequency of logging during a session.

Valid specifications: FIRST, LAST, FIRST AND LAST, or EACH

The action or comma-separated list of actions which, if present in a user request, triggers logging.

The name of the user, or comma-separated list of users, for which the system logs activity.

The name of a database object which, if present in a request, triggers logging.

Note: BEGIN LOGGING parameters are optional. The absence of some parameters causes the system to use default values. For a detailed description of BEGIN LOGGING syntax and options, see SQL Data Definition Language Syntax and Examples, B035-1144.

The BEGIN LOGGING statement also has differing effects depending on how subsequent user queries reference the object of the logging rule when they access the database.

For example, the logging statement BEGIN LOGGING ON FIRST SELECT...ON

DatabaseA.Table1 has the following effects:

Query

SELECT . . . FROM Table1

SELECT . . . FROM View1

(where View1 is a view of Table1)

EXECUTE MACRO1

(where Macro1 contains the statement

SELECT . . . FROM Table1)

Result

The system generates a log entry because the query directly names the object that is subject to the logging rule.

The system does not generate a log entry for these queries, even though they access Table1, because the queries do not directly reference Table1.

Note: To log access of Table1 for these queries, you must create logging rules that specify the view or macro.

Enabling Access Logging

The following procedure is based on the example requirements shown in “Common Access

Logging Requirements” on page 273 .

Start Teradata Administrator and log on as user DBADMIN.

On the main screen, click the Preview Mode button

SQL.

to enable display of generated

Initiate logging on tables or views that contains sensitive data, such as cardholder data.

Teradata Data Warehouse Appliance 2800 Implementation Guide 275

Chapter 11: Monitoring Database Access

Setting Up Access Logging

a b c

From the main window, click Tools>Access Logging.

The Access Logging screen contains three check boxes labeled All. Two boxes are already checked by default. Uncheck the All boxes to enable display of the option list.

Specify values for the following fields:

Field

On Database

Object Type

Object

By User

Denials

With SQL

First

Last

First & Last

Each

Normal field

Description

The name of the database that owns the object that contains the sensitive data.

Select the containing database from the drop-down list.

The type of object that contains the sensitive data.

Select Table or View from the drop-down list to identify the type of object that contains the sensitive data.

The specific object that contains the sensitive data

Select the name of the specific table or view from the drop-down list.

The name of the user(s) for which logging is required.

Check the All box. Access by any user must be auditable. All is highlighted in the By User field.

Checking this box logs any denial of access to the object.

Recommendation: Not required. All denials are logged as part of

step 5 .

Optional. Checking this box logs the SQL submitted against the object.

Note: Logging SQL may consume a large amount of log space. Do not check this box except as needed for detailed investigation of an individual user.

Checking one of these boxes indicates when the logging is to be performed.

Recommendation: Check Each to conform to the requirement for logging all administrator activity.

Create field

Drop field

Groups field

Lists the normal privileges applicable to the object.

Recommendation: Check all the active (not grayed out) privileges listed except Checkpoint.

Lists the create privileges applicable to the object.

Recommendation: Check all the active (not grayed out) privileges listed.

Lists the drop privileges applicable to the object.

Recommendation: Check all the active (not grayed out) privileges listed.

Checking items in the Groups field automatically creates multiple logging rules.

Recommendation: Do not check any items in this field.

Click the Begin Log button.

276 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 11: Monitoring Database Access

Setting Up Access Logging

The Query window appears and displays the generated BEGIN LOGGING statement.

BEGIN LOGGING DENIALS ON EACH SELECT, INSERT, UPDATE, DELETE,

STATISTICS, INDEX, REFERENCES, DUMP, RESTORE, SHOW, GRANT, CREATE

TRIGGER, DROP TABLE, DROP TRIGGER ON Table

"Tables_Database"."Table_Name"

f e

From the Query window, click the Run Query button .

You can optionally display the list of access logging rules at any time as follows:

Close the Access Logging window.

g ii

On the main menu deselect the Preview Mode button display.

On the main window, click Tools>Access Logging.

to suppress the SQL

iii iv

In the Access Logging window, click the Display button to display the logging rules created by the previous steps.

Repeat step 1 through step 3 for each table or view that contains sensitive data. As an

alternative to repeating the entire procedure, you can do the following:

Copy the SQL for the initial logging statement.

Open a query window by clicking the Query button at the bottom of the left hand menu. This opens a Teradata SQL Assistant query window, which can execute multiple SQL statements.

iii

Paste in the SQL and replicate it for each table or view that contains sensitive data, customizing each statement copy for a specific object.

4 a iv

Click the Run Query button to execute the SQL statements.

Close the Query window.

Initiate logging of any action taken by all users with administrative privileges as follows:

From the Access Logging window, uncheck the All boxes to display the lists of options.

Specify values for the following fields:

Field Description

On Database The name of the owner of the object that contains the sensitive data.

Recommendation: Check the All box to capture all administrator activity.

Object Type The type of object that contains the sensitive data.

Not required because the All box is checked in the On Database field.

Teradata Data Warehouse Appliance 2800 Implementation Guide 277

Chapter 11: Monitoring Database Access

Setting Up Access Logging

Field

Object

By User

Denials

With SQL

Description

The specific object that contains the sensitive data

Not required because the All box is checked in the On Database field.

The name of the user(s) for which logging is required.

Recommendation: Select all users that have administrative privileges from the

By User field.

Checking this box logs any denial of access to the object.

Recommendation: Not required. All denials are logged as part of

step 5

Optional. Checking this box logs the SQL submitted against the object.

Note: Logging SQL may consume a large amount of log space. Do not check this box except as needed for detailed investigation of a specific user.

First

Last

First & Last

Each

Checking one of these boxes indicates when the logging is to be performed.

Recommendation: Check Each to log all administrator activity.

Normal field Not required. Specification of individual privileges is checked automatically when All is checked in the Groups field.

Create field

Drop field

Groups field Checking items in the Groups field creates multiple logging rules.

Recommendation: Check All to monitor all privilege checks for administrators.

Click the Begin Log button.

The Query window appears and displays the generated BEGIN LOGGING statement.

BEGIN LOGGING DENIALS ON EACH EXECUTE, SELECT, INSERT, UPDATE,

DELETE, STATISTICS, INDEX, REFERENCES, DUMP, RESTORE, CHECKPOINT,

SHOW, EXECUTE PROCEDURE, ALTER PROCEDURE, UDTUSAGE, UDTTYPE, GRANT,

UDTMETHOD, EXECUTE FUNCTION, ALTER FUNCTION, ALTER EXTERNAL

PROCEDURE, CREATE OWNER PROCEDURE, CREATE TABLE, CREATE VIEW,

CREATE MACRO, CREATE DATABASE, CREATE USER, CREATE TRIGGER, CREATE

PROCEDURE, CREATE PROFILE, CREATE ROLE, CREATE FUNCTION, CREATE

EXTERNAL PROCEDURE, CREATE AUTHORIZATION, DROP TABLE, DROP VIEW,

DROP MACRO, DROP DATABASE, DROP USER, DROP TRIGGER, DROP PROCEDURE,

DROP PROFILE, DROP ROLE, DROP FUNCTION, DROP AUTHORIZATION BY

"DBADMIN","DBC","admin1","admin2"

d e

From the Query window, click the Run Query button

Close the Query window.

278 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 11: Monitoring Database Access

Setting Up Access Logging

Initiate logging of all invalid access attempts as follows:

Specify values for the following fields:

Field

Database

Object Type The type of object.

Not required because the All box is checked in the On Database field.

Object The specific object.

Not required because the All box is checked in the On Database field.

By User The name of the user(s) for which logging is required.

Recommendation: Check the All box above the By User field to log invalid access attempts by all users.

Denials

Description

The name of the owner of the object that contains the sensitive data.

Recommendation: Check the All box (the default) to log invalid access attempts on all databases and objects.

With SQL

Checking this box logs any denial of access to the object.

Recommendation: Check this box.

Optional. Checking this box logs the SQL submitted against the object.

Note: Logging SQL may consume a large amount of log space. Do not check this box except as needed for detailed investigation of a specific user.

Checking one of these boxes indicates when the logging is to be performed.

Recommendation: Check Each to log all access attempts.

First

Last

First & Last

Each

Normal field

Create field

Not required. Specification of individual privileges is checked automatically when All is checked in the Groups field.

Drop field

Groups field

Checking items in the Groups field creates multiple logging rules.

Recommendation: Check All to monitor all privilege checks for administrators.

Click the Begin Log button. The Query window appears with the following SQL:

BEGIN LOGGING DENIALS ON EACH EXECUTE, SELECT, INSERT, UPDATE,

DELETE, STATISTICS, INDEX, REFERENCES, DUMP, RESTORE, CHECKPOINT,

SHOW, EXECUTE PROCEDURE, ALTER PROCEDURE, UDTUSAGE, UDTTYPE, GRANT,

UDTMETHOD, EXECUTE FUNCTION, ALTER FUNCTION, ALTER EXTERNAL

PROCEDURE, CREATE OWNER PROCEDURE, CREATE TABLE, CREATE VIEW,

CREATE MACRO, CREATE DATABASE, CREATE USER, CREATE TRIGGER, CREATE

PROCEDURE, CREATE PROFILE, CREATE ROLE, CREATE FUNCTION, CREATE

EXTERNAL PROCEDURE, CREATE AUTHORIZATION, DROP TABLE, DROP VIEW,

DROP MACRO, DROP DATABASE, DROP USER, DROP TRIGGER, DROP PROCEDURE,

DROP PROFILE, DROP ROLE, DROP FUNCTION, DROP AUTHORIZATION;

Teradata Data Warehouse Appliance 2800 Implementation Guide 279

Chapter 11: Monitoring Database Access

Setting Up Access Logging

280

6 c

From the Query window, click the Run Query button .

Close the Query window.

Initiate logging of any query that creates or deletes a system level object, that is, in the space directly owned by user dbc, as follows:

From the Access Logging window, uncheck the All boxes to display the options lists.

Specify values for the following fields:

Field Description

On Database The name of the owner of the object that contains the sensitive data.

Recommendation: Select DBC to specify the system-level database.

Object Type The type of object that contains system-level objects.

Recommendation: Specify Database.

Object

By User

Not required. The previous two fields already identify the top-level object.

The name of the user(s) for which logging is required.

Recommendation: Check All in the box above the By User field to log creation or deletion of system-level objects by all users.

Denials

With SQL

First

Last

First & Last

Each

Checking this box logs any denial of access to the object.

Recommendation: Not required. All denials are logged as part of

step 5

Optional. Checking this box logs the SQL submitted against the object.

Note: Logging SQL may consume a large amount of log space. Do not check this box except as needed for detailed investigation of a specific user.

Checking one of these boxes indicates when the logging is performed.

Recommendation: Check Each to log attempts to create or delete system-level objects.

Normal field Not required. Specification of individual privileges is checked automatically when All is checked in the Groups field.

Create field

Drop field

Groups field Checking items in the Groups field creates multiple logging rules.

Recommendation: Check All to monitor all privilege checks on database DBC.

Click the Begin Log button.

BEGIN LOGGING ON EACH INDEX, REFERENCES, ALTER PROCEDURE, ALTER

FUNCTION, ALTER EXTERNAL PROCEDURE, CREATE OWNER PROCEDURE, CREATE

TABLE, CREATE VIEW, CREATE MACRO, CREATE DATABASE, CREATE USER,

CREATE TRIGGER, CREATE PROCEDURE, CREATE FUNCTION, CREATE EXTERNAL

PROCEDURE, CREATE AUTHORIZATION, DROP TABLE, DROP VIEW, DROP MACRO,

DROP DATABASE, DROP USER, DROP TRIGGER, DROP PROCEDURE, DROP

FUNCTION, DROP AUTHORIZATION ON Database "DBC"

Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 11: Monitoring Database Access

Setting Up Access Logging

7 d

From the Query window, click the Run Query button

Close the Query window.

Close the Access Logging window.

Log the initialization of the audit logs.

a b

On the main screen press the Query button open SQL Assistant.

at the bottom of the left menu to

In the SQL Assistant Query window, enter the following SQL statement:

BEGIN LOGGING WITH TEXT ON EACH ALL ON MACRO DBC.AccLogRule;

8 c

Click the Run Query button .

Initiate logging on all attempts to access audit trails.

Enter the following SQL statement in the SQL Assistant Query window.

BEGIN LOGGING ON EACH ALL ON TABLE DBC.AccessLogTbl;

BEGIN LOGGING ON EACH ALL ON VIEW DBC.AccessLog;

BEGIN LOGGING ON EACH ALL ON VIEW DBC.DeleteAccessLog;

BEGIN LOGGING ON EACH ALL ON TABLE DBC.EventLog;

BEGIN LOGGING ON EACH ALL ON VIEW DBC.LogOnOff;

Click the Run Query button .

Close the Query Window and the Access Logging dialog box.

Log off Teradata Administrator or go on to “Auditing Database Activity Using DBC Log

Views” on page 283 .

Reference Information

For step...

Information on...

All the DIPACC script and the

DBC.AccLogRule macro security logging strategies; logging for directory users and proxy users optional specifications and syntax for the BEGIN LOGGING statement

Is available in...

Utilities: Volume 1 (A-K), B035-1102

Security Administration, B035-1100

SQL Data Definition Language Syntax and

Examples, B035-1144

Teradata Data Warehouse Appliance 2800 Implementation Guide 281

Chapter 11: Monitoring Database Access

Disabling Access Logging

You can use the END LOGGING statement to terminate access logging on any user, action, or object for which one or more logging rules are currently active.

An END LOGGING statement generates an error if a corresponding BEGIN LOGGING statement is not currently in effect for the object specified in the END LOGGING statement.

Also consider the following END LOGGING characteristics:

•

You cannot omit the BY username clause to apply the END LOGGING to all users.

•

The END LOGGING statement terminates access logging on the database objects included in the statement. If the END LOGGING statement terminates all logging rules for a particular user, database, or object, the system deletes the row from DBC.AccLogRuleTbl.

To disable access logging:

Query the DBC.AccLogRules view to display the list of BEGIN LOGGING statements currently in effect:

SELECT * FROM DBC.AccLogRulesV;

Submit an END LOGGING statement for each BEGIN LOGGING statement in the list that you want to end.

Reference Information

Information on...

use of the END LOGGING statement security logging strategies

Is available in...

SQL Data Definition Language Syntax and Examples, B035-1144

Security Administration, B035-1100

Using Access Logs

About Access Logs

Access logging writes information to the logs shown in the following Data Dictionary views.

View Name

DBC.AccessLogV

DBC.LogOnOffV

Description

Each entry is the results of a privilege check performed due to a user request to access a database object. These privilege checks are based on the rules defined in BEGIN LOGGING statements executed on the system.

Collects a history of logon and logoff activity by date, showing the associated user, session number, and events such as logon failures. Event data indicates why a logon was unsuccessful.

282 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 11: Monitoring Database Access

Using Access Logs

Auditing Database Activity Using DBC Log Views

The administrator should perform regular audits of the access logs to detect undesirable activity, and if necessary take remedial action:

To perform a general audit of the security log views:

From the main Teradata Administrator screen, click the bottom left Query button

b c

. Teradata Administrator opens an SQL Assistant query window.

From the View menu, ensure that Show History is not checked (the default). This option shows the history of SQL Assistant queries launched from this client, and is not necessary for security logging.

In the Query window, enter the following SQL to access the security log of interest:

SELECT * FROM [view_name] [table_name] where:

•

view_name is DBC.AccessLogV or DBC.LogOnOffV

•

table_name is DBC.EventLog

2 d

Right-click in the Query window and from the menu, click the Execute button .

As a result of the query, SQL Assistant displays the Answer Set table, which shows the most recent access log entries, based on the number of rows set for display.

Note: You can click Tools>Options>Answer Set to access display format options.

You can follow the same procedure shown in

step 1

, but construct the SQL statement to narrow the audit parameters. For example:

•

A typical query of the DBC.AccessLog view would be similar to:

SELECT LogDate, UserName, AccessType, StatementText

FROM DBC.AccessLogV

WHERE LogDate =

'2009-04-18'

;

•

A typical query of the DBC.LogOnOff view would be similar to:

SELECT LogDate, LogTime, Event, LogicalHostId, IFPNo

FROM DBC.LogOnOffV

WHERE LogDate=

2009-09-29

AND UserName=

Tester

ORDER BY LogTime;

Reference Information

For step...

Information on...

All content of the access log tables and views

Is available in...

•

Security Administration, B035-1100

•

Data Dictionary, B035-1092

Teradata Data Warehouse Appliance 2800 Implementation Guide 283

Chapter 11: Monitoring Database Access

Checkpoint

Before leaving Chapter 11: “Monitoring Database Access,” make sure that:



Result

The database is configured to monitor and log user interactions with the database.

You understand how to disable access logging.

You have a program for regular auditing of the access logs.

Reference

“About Access Logging” on page 273

“Disabling Access Logging” on page 282

“Using Access Logs” on page 282

If you do not have these results, return to the section in the Reference column and review that procedure.

284 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 12

Monitoring the Database

This section describes how to monitor Teradata Database system health, activity, resources, and performance, using Teradata Viewpoint 15.00.

For information on how to use Teradata Viewpoint monitoring functions to investigate system problems, see

Chapter 13: “Managing the Database.”

Prerequisites

•

A Teradata Viewpoint server is installed and connected to the Teradata Data Warehouse

Appliance 2800 system.

•

The RSS data collection system is enabled on the Teradata Data Warehouse Appliance 2800 system.

•

The Teradata Viewpoint server logon user (viewpoint) exists in the database and has the privileges necessary to logon and execute database monitoring and management functions.

•

At least one administrative user is configured to access and administer Teradata Viewpoint and the Viewpoint data collectors are enabled.

•

All users that you want to setup to access Teradata Viewpoint are defined in the database.

Reference Information

Information on...

Teradata Viewpoint initial setup requirements described in

“Prerequisites” on page 285

Is available in...

Teradata Viewpoint User Guide, B035-2206

Teradata Viewpoint use and administration Teradata Viewpoint User Guide, B035-2206

Enabling the RSS data collection system and setting collection rates in the database using the Control GDO editor (ctl)

Utilities, B035-1102

Defining users and granting user privileges in the database

Chapter 10: “Setting Up Users”

Teradata Data Warehouse Appliance 2800 Implementation Guide 285

Chapter 12: Monitoring the Database

About Viewpoint Monitoring Privileges

All database users can benefit from using Teradata Viewpoint to monitor the database, but not all users need all Teradata Viewpoint capabilities.

You can use the examples in the following table to help determine the database monitoring functions needed by various user types, and in creating and assigning privileges to Teradata

Viewpoint roles.

Role Privileges

Default Teradata Viewpoint roles

Administrator Assign this role only to the Teradata Viewpoint administrator(s).

Has all privileges (default). This role can access the functions in the Admin tool menu to configure Teradata Viewpoint alerts, users, roles, and systems.

User

TD_SE (Teradata

Solution Engineer)

Includes minimal privileges

This role is intended for the Teradata Solution Engineer when they need access to system health and metrics. You can enable or disable this role, but do not reconfigure it.

TD_TSS (Teradata

Technical Support

Specialist)

Example custom roles

Note: Roles are based on the user types/duties shown in

“About User Requirements” on page 249

Database

Administrator

This role is intended for Teradata Technical Support Specialists when they need access to your system SQL. You enable or disable this role, but do not reconfigure it.

Database administrators may require all Teradata Viewpoint monitoring functions to perform administrative duties in the database.

Suggested role privileges: Create a Database Administrator role that has privileges to use all portlets and portlet functions, except System

Administration, which should only be accessible to the Teradata Viewpoint administrator(s).

Note: You may find it useful to create an additional role that limits access to some portlets and functions for lower level administrators.

Database

Programmer/

Power User

Database programmers perform functions similar to administrators, creating database objects, running ad hoc queries, and monitoring performance.

Suggested role privileges: Similar to Database Administrator, but without analytical functions.

Note: Programmer privileges in the database are often restricted to a development database, but Teradata Viewpoint monitors all databases within the Teradata Data Warehouse Appliance 2800 system.

286 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 12: Monitoring the Database

Setting Up Teradata Viewpoint Users

Role

Batch User

Update User

General User

Privileges

Batch users run load and export utilities, or who perform backup, archive and restore operations.

Suggested role privileges for the following portlets include:

•

For job planning:

•

Metric Heatmap

•

Space Usage

•

Viewpoint Calendar

•

During job execution and troubleshooting:

•

System Health

•

My Queries or Query Monitor

•

Workload Monitor

•

SQL Scratchpad

•

Console Utilities

•

Privilege to set preferences and share portlets

Users who perform miscellaneous insert/update/delete operations.

Suggested role privileges:

•

Viewpoint Calendar (no create or edit privileges)

•

System Health (View Summary only)

•

My Queries

•

Workload Monitor

•

SQL Scratchpad

Low-level users that run macros and stored procedures to access data, which select data and generate reports.

Suggested role privileges:

•

Viewpoint Calendar (no create or edit privileges)

•

System Health (View Summary only)

•

My Queries

Setting Up Teradata Viewpoint Users

For users that are not already set up to access Teradata Viewpoint, as part of initial system installation, you must perform Teradata Viewpoint set-up operations.

Log on as the Teradata Viewpoint administrator.

From the Teradata Viewpoint portal page, click in the top right corner of the page.

Use User Manager to create Teradata Viewpoint users and assign membership in one or more roles according to user job function. Include an email address for each user, so that

Teradata Viewpoint can send them alert emails, if necessary.

Teradata Data Warehouse Appliance 2800 Implementation Guide 287

Chapter 12: Monitoring the Database

Working with Viewpoint User Pages

Instruct users to set up their Teradata Viewpoint profile by specifying their username, password, and account, so the system can verify that each user exists in the specified database system and that the account is valid for the user. Profile information is used by some portlets, for example:

•

My Queries portlet, to track query activity for the user

•

SQL Scratchpad portlet, to determine database access privileges for the user

Click Close to close the Viewpoint Administration view and return to the Teradata

Viewpoint portal page.

Use Roles Manager to create Teradata Viewpoint roles and define sets of user privileges for each role.

When creating roles:

•

Define the portlets available to the role.

•

Define whether user members can set their own preferences and share portlets.

•

Give or remove user permissions for portlet tools and functions.

Teradata Viewpoint provides five default roles, but you may find it useful to configure custom roles, based on the suggestions in

“About Viewpoint Monitoring Privileges” on page 286 .

Reference Information

Information on...

the duties typically performed by the user types for which customer roles are recommended

Is available in...

“About User Requirements” on page 249

creating Teradata Viewpoint users, roles, and profiles

•

Teradata Viewpoint online help

•

Teradata Database 15.0 documentation

•

Teradata Viewpoint User Guide, B035-

2206

•

Teradata Viewpoint Configuration and

Upgrade Guide, B035-2207

•

Teradata Alerts User Guide, B035-2210

Working with Viewpoint User Pages

Organize your portlets by adding pages to the Teradata Viewpoint portal.

The primary Viewpoint User page should contain the most important portlets for live monitoring of database activity, for example:

•

System Health (all)

•

My Queries (users) or Query Monitor (administrators and programmers)

•

1 or 2 other optional portlets, depending on the type of user

288 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 12: Monitoring the Database

Using Teradata Alerts

You can create additional pages to contain other portlets.

Note: You may need to limit the number of portlets per page. Displaying too many Teradata

Viewpoint portlets on one page may make it hard to find needed data, and for some browsers, may slow portlet loading and response times.

For details about configuring pages and portlets, see Teradata Viewpoint User Guide, B035-

2206.

Creating a Teradata Viewpoint Page

From the Teradata Viewpoint portal:

In the portal, click to add a page.

Enter a name for the page, up to 30 characters, and press Enter.

[Optional] Click Add Content to add portlets.

For information on how to use monitoring capabilities to identify and troubleshoot database problems, see

Chapter 13: “Managing the Database.”

Using Teradata Alerts

Teradata alerts enables alert functionality in the Teradata Viewpoint portal. The Teradata

System Administrator can set up alerts to invoke actions to automatically respond to database or system triggers.

Alerts can be configured to:

•

Send an email notification

•

Send an SNMP notification

•

Run a BTEQ script

•

Run a SQL query

•

Run a Windows or Linux executable program

•

Write to an alert log that can be viewed in the Alert Viewer portlet

Each alert action set has a unique name and is triggered according to the rules for any alert that specifies the action set name.

The database management tasks shown in Chapter 13: “Managing the Database,” include

other suggested alert protocols.

Setting Up Alert Actions

The alert setup defines alert notification parameters and alert actions.

See Teradata Viewpoint User Guide, B035-2206 for procedure details.

Teradata Data Warehouse Appliance 2800 Implementation Guide 289

Chapter 12: Monitoring the Database

Using Teradata Alerts

From the main Teradata Viewpoint portal page, click page.

in the top right corner of the

Choose the Alert Setup portlet.

Use Delivery Settings/Email to configure communication with the host SMTP email server.

Use Delivery Settings/Teradata Login to select the Teradata system for which you are configuring the alert.

Use Alerts Presets/Action Sets to set up common alert actions, for example, an email message to all administrative users. Then you can use

“Creating Alerts” on page 290

to set up monitoring parameters that invoke the associated alert action whenever Teradata

Viewpoint detects that a parameter was exceeded.

Note: Specifying one or more roles in the action sends an email to each role member and is the most efficient way of identifying email recipients. You can list email addresses for any recipients that are not Teradata Viewpoint users.

Creating Alerts

A Teradata Viewpoint alert is based on:

•

A threshold specified for a monitoring parameter, for example, when a database exceeds

95% space usage.

•

The time period during which the parameter must be over threshold to invoke the alert.

•

The name of an Action Set, for example, the alert notification created in

“Setting Up Alert

Actions” on page 289 , which defines who should receive the alert, and how the message is

delivered.

•

A message that the system delivers to the list of users defined in the Action Set, if the threshold and time criteria are met.

To configure a sample alert:

From the Teradata Viewpoint main portal, click in the top right corner of the page.

Choose the Monitored Systems portlet.

Choose a Teradata system.

From the Setup menu, select Alerts, and then configure an alert, for example, a System

Health alert that sends a message if the system is down, similar to the following example.

290 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 12: Monitoring the Database

Checkpoint

Note: The Alert Action name “General Alert” is created using

“Setting Up Alert Actions” on page 289

Check the Enabled box and click Apply.

Note: See Teradata Viewpoint User Guide, B035-2206 for details and options.

Checkpoint

Before leaving Chapter 12: “Monitoring the Database,”

make sure that:



Result

You have determined which Teradata

Viewpoint privileges are appropriate for user groups at your site.

Database users are configured to access

Teradata Viewpoint.

Reference

“About Viewpoint Monitoring Privileges” on page 286

“Setting Up Teradata Viewpoint Users” on page 287

Teradata Data Warehouse Appliance 2800 Implementation Guide 291

Chapter 12: Monitoring the Database

Checkpoint



Result

Teradata Viewpoint users have pages that display related groups of portlets.

One or more Teradata Viewpoint alerts are setup and you understand how to create additional alerts, as needed.

Reference

“Working with Viewpoint User Pages” on page 288

“Using Teradata Alerts” on page 289

292 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 13

Managing the Database

Database management includes:

•

Space management

•

Query management

•

Account management and cost accounting

•

Workload management

For additional information, see Database Administration, B035-1093.

Prerequisites

•

To execute the procedures shown in this chapter, you must have:

•

Teradata Database administrator privileges. See

“Setting Up the Database

Administrator User” on page 158 .

•

Teradata Viewpoint administrator privileges. See Teradata Viewpoint User Guide,

B035-2206.

•

Teradata Viewpoint is set up for basic monitoring functions. See

Chapter 12: “Monitoring the Database.” This chapter contains additional monitoring recommendations.

About Space Management

Other implementation tasks in this publication include assigning space to databases and users, but these allocations are based on estimates. Changes in space usage patterns and data expansion require that you actively monitor database space and make needed changes.

Compressing Data to Save Space

Teradata recommends that you use one or more of these compression options to conserve disk space:

•

Multi-value compression

•

Algorithmic compression

Teradata Data Warehouse Appliance 2800 Implementation Guide 293

Chapter 13: Managing the Database

Compressing Data to Save Space

•

Hash/Join index row compression

•

Block-level compression

You can use these compression methods in any combination for space savings of as much as

80% to 90%, depending on the characteristics of the data being compressed.

Using Multi-Value Compression (MVC)

MVC compresses repeating values in a column when you specify the value in a compression list in the column definition. You can specify compression for up to 255 values per column.

When data in the column matches a value specified in the compression list, the database stores the value only once in the table header, regardless of how many times it occurs as a field value for the column. The database then stores a smaller substitute value, often as small as 2 bits, in each row where the value occurs.

MVC generally provides the best cost/benefit ratio compared to other methods. Because it requires minimal resources to uncompress the data during query processing, you can use

MVC for hot (frequently-used) data without compromising query/load performance.

Procedure

Use the COMPRESS phrase in a CREATE TABLE or ALTER TABLE statement to specify a list of frequently occurring values for the column that contains the values.

The system automatically compresses the specified values when data moves into the table, and uncompresses the values when the containing rows are accessed.

Using Algorithmic Compression (ALC)

Teradata Database provides several standard compression algorithms in the form of user defined functions (UDFs), and also an algorithmic compression framework that allows you to create custom compression and decompression algorithms in UDF format.

The standard algorithmic compression (ALC) UDFs compress character data by column.

When column values are mostly unique, ALC may provide better compression results than

MVC. When columns have repeated values, you can use ALC and MVC concurrently on the same column, but the system does not apply ALC to any value covered by MVC.

ALC generally functions best on cold (seldom used) data, because of the amount of CPU required for the decompress/recompress cycle when compressed data is accessed, although some ALC algorithms require less CPU than others.

Procedure

Specify the name of an ALC compression UDF in the COMPRESS USING phrase for a column definition in a CREATE TABLE or ALTER TABLE statement.

Specify the name of an ALC decompression UDF in the DECOMPRESS USING phrase for the column definition.

294 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Compressing Data to Save Space

Using Hash Index and Join Index Row Compression

Row compression automatically divides rows into repeating and nonrepeating portions. The system appends multiple sets of nonrepeating column values to a single set of repeating column values. This allows the system to store the repeating value set only once, while any nonrepeating column values are stored as logical segmental extensions of the base repeating set. The nonrepeating column set has a pointer to each of the repeating column sets so it can reconstruct the rows when required.

Row compression significantly reduces index storage space for index columns that have a large number of repeating values.

For hash indexes, the system compresses rows by default.

For join indexes you can:

Specify the columns to be compressed using the (column_1_name) syntax elements in the

SELECT clause of a CREATE JOIN INDEX statement.

Specify the columns to remain uncompressed using the (column_2_name) syntax elements in the SELECT clause for the same CREATE JOIN INDEX statement.

About Block-Level Compression

Teradata Database stores table data in units called data blocks (DBs); physical units of I/O that determine how the Teradata Database file system handles data. The DATABLOCKSIZE option in a CREATE TABLE or ALTER TABLE statement defines the maximum multi-row data block size for a table. Unused space in the data blocks can be compressed.

On Teradata Data Warehouse Appliance 2800 systems, block-level compression is enabled by default and ready to use. Customers do not need to set up block-level compression or maintain it.

Caution:

Teradata does not recommend disabling block-level compression. The Teradata Data

Warehouse Appliance 2800 system is designed and optimized for block-level compression. If block-level compression is disabled, system performance could be less than optimal.

Reference Information

Information on...

specifying MVC or ALC compression in a

CREATE TABLE or ALTER TABLE statement specifying join index row compression in a

CREATE JOIN INDEX statement all available compression options and how to use them

Is available in...

SQL Data Definition Language Syntax and

Examples, B035-1144

Database Administration, B035-1093

Teradata Data Warehouse Appliance 2800 Implementation Guide 295

Chapter 13: Managing the Database

Identifying and Correcting Space Problems

Information on...

compression usage and restrictions, determining the maximum number of compressed values, calculating space and I/O savings, and comparisons between using MVC and ALC applying compression to various data types using the COMPRESS and DECOMPRESS phrases

Is available in...

Database Design, B035-1094

SQL Data Types and Literals, B035-1143

Identifying and Correcting Space Problems

You can use Teradata Viewpoint to monitor database space usage and detect space problems.

Space problems vary depending on the type of space and how the system uses it.

Space Type

Permanent (Perm)

Spool

Temporary (Temp)

Usage

Permanent storage space contains objects that persist in the database, for example, tables, indexes, and journals. Perm space is assigned in a:

•

CREATE DATABASE or MODIFY DATABASE statement

•

CREATE USER or MODIFY USER statement

When you create an object, or when data rows are inserted into an object, the system takes the needed space from the perm space of the immediate owner of the object. The system automatically returns the space to the owner when it is no longer needed.

Spool space holds intermediate query results, the formatted answer sets to queries, and volatile tables (if used). The system automatically draws spool space from unused system disk space.

You can specify a limit on the amount of spool space available to a user or database in a:

•

CREATE DATABASE or MODIFY DATABASE statement

•

CREATE PROFILE or MODIFY PROFILE statement

•

CREATE USER or MODIFY USER statement

If you do not specify a spool space limit, a user automatically inherits the spool limit of the immediate owner.

Teradata recommends creating a spool space reserve to ensure that there is sufficient spool space to execute user queries. For information, see

“Creating the Spool Space Reserve” on page 155 .

Temp space stores global temporary tables.

Global temporary tables are an advanced feature and not covered in this publication. For information, see Database Administration, B035-1093.

296 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Identifying and Correcting Space Problems

Identifying Space Problems

Several Teradata Viewpoint portlets provide space usage information, which you can use to identify space problems.

System Health Portlet

Use the System Health portlet to track current system-level space usage. This portlet displays segmented bar graphs that show normal, degraded and critical space usage ranges.

Parameter Description

Total disk space Percentage of total disk space in use across the system

DBC disk space Percent of disk space assigned to DBC currently in use

Actions

If system disk space usage moves beyond the normal range (80%), add disk capacity.

The DBC database contains logs, system tables and views, and other functions necessary for system operation.

If DBC space usage moves beyond the normal range, reallocate perm space from DBADMIN to DBC.

Space Usage Portlet

Use the Space Usage portlet to track detailed space usage parameters, including available space, current usage, and peak usage for each space type, by database or node.

In the selection menu, click the currently-selected system name to display a list of available systems.

Select a system.

Click .

Select By Database from the Select Report dialog box.

Click . The report appears in the summary table.

Parameter Description

Current Perm% Percentage of available perm space currently being used by each user and database.

Peak Perm% The highest percentage of total available perm used by each user and database since the last reset

(default 24 hours).

Action

Consider allocating additional perm space to any user or database when it reaches 90%

perm space usage. See “Reallocating Perm

Space” on page 298

Teradata Data Warehouse Appliance 2800 Implementation Guide 297

Chapter 13: Managing the Database

Identifying and Correcting Space Problems

Parameter

Current Perm

Skew%

Description

A measure of how the perm space for a database distributes across all AMPs. Higher percentages indicate uneven distribution.

Action

A high perm skew percentage indicates that one or more tables in the database is skewed, that is, it has a poorly designed primary index.

To identify skewed tables, see

“Finding and

Fixing Skewed Tables” on page 298

Note: If you think there is a space problem, you can click a database name to display the

Details view, which shows the current perm, peak perm, and skew% for each table in the database.

Using the Metrics Heatmap Portlet

The Metrics Heatmap portlet displays many of the same parameters as the Space Usage portlet, but allows you to see space usage trends over several months. A review of space usage trends in Metrics Heatmap can be useful when planning and scheduling batch jobs or other large space-using tasks, or when estimating growth in system disk requirements.

Reallocating Perm Space

In the Space Usage portlet, highlight the database or user that requires more space.

Note: You can also define the value for spool in a profile, and then assign profile

membership to a user. See “Working with Profiles” on page 254

Click the Add Space button and:

•

Enter the username and password of a database user that has DROP privileges

(required for use of the MODIFY statement) on the database or user that requires more perm space.

•

Enter the space in MBs and the name of the user or database that directly owns the perm space being transferred.

The system generates a MODIFY DATABASE or MODIFY USER statement that reallocates the space.

Increasing the Spool Space Limit for a User

Specify a new value for SPOOL in a MODIFY PROFILE or MODIFY USER statement, depending on where the user spool is defined, for example:

MODIFY [PROFILE profile_name | USER user_name ] AS

SPOOL = bytes ;

Finding and Fixing Skewed Tables

The DBC.TableSizeV contains information that can help identify skewed tables. Table skew results from an inappropriate primary index. A query that references a skewed table may try to process more rows on some AMPs than others, and may run out of space:

298 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Identifying and Correcting Space Problems

•

SELECT statements may run out of spool space if the accessed object has a defined spool space limit.

•

INSERT and UPDATE statements may run out of perm space.

Use the following SQL statement to find skewed tables in the DBC.TableSizeV:

SELECT vproc AS

"AMP", TableName (FORMAT 'X(20)'), CurrentPerm

FROM DBC.TableSizeV

WHERE DatabaseName = 'database'

ORDER BY TableName, "AMP" ;

AMP

---

TableName

--------------------employee_upi_onempid employee_upi_onempid employee_upi_onempid employee_upi_onempid employee_nupi_ondept employee_nupi_ondept employee_nupi_ondept employee_nupi_ondept

CurrentPerm

------------

18,944

19,968

4,096

30,208

15,360

12,288

In this example, the answer set displays space allocations by AMP for two tables. The results show that:

•

CurrentPerm is similar across all vprocs for employee_upi_onempid. Permanent space distribution is relatively even across all AMPs in the system.

•

The table Employee_nupi_ondept is poorly distributed. The CurrentPerm figures range from 4,096 bytes to 30,208 bytes on different AMPs.

Redefine the primary index for any skewed tables that you find. See “About Primary

Indexes” on page 182 .

Setting Up Teradata Viewpoint Alerts for Space Usage

You can use Teradata Viewpoint to regularly monitor space usage, and catch most space problems. However, it may be useful to setup a few alerts in areas where space problems can

seriously affect database function. See “Using Teradata Alerts” on page 289

The following table contains some examples of common space usage alerts.

Teradata Data Warehouse Appliance 2800 Implementation Guide 299

Chapter 13: Managing the Database

Identifying and Correcting Space Problems

Alert

Crashdumps Space

The crashdumps database needs enough space to contain possible large data dumps that occur during crashes, and which are used in system recovery.

DBC Space

User DBC contains all system tables and logs.

Critical system functions depend on DBC having enough space.

Note: You can set the same alert parameters for

DBCMNGR and

SystemFE, which perform other critical system functions.

Set up three alerts to identify when a database exceeds important space thresholds.

•

All DB 90%

•

All DB 95%

•

All DB 97%

Setup Parameters

Alert rules:

•

Only include databases = crashdumps

•

Current Perm Max% > 70

Note: The threshold is set low because a crashdump can be very large.

Alert Action:

•

Do not run twice in 5 minutes

Severity: Medium

Alert rules:

•

Only include databases = DBC

•

Current Perm Max% > 80

Note: Use 90% for SystemFE.

Alert Action:

•

Do not run twice in 5 minutes

Severity: Medium

Response to Alert Occurrence

•

Add perm space to the crashdumps database. See

“Assigning Perm Space to

Crashdumps” on page 156

•

Purge the crashdumps database of unneeded data and back up needed data to external media.

See Database Administration,

B035-1093.

Add perm space to the database.

See “Assigning Perm Space to

Crashdumps” on page 156

for information on the DBC space allocation for appliance implementation.

Alert rules:

•

All databases

•

Current Perm Max%

> percent

Alert Action:

•

Email (Pager for critical alerts)

•

Do not run twice in 5 minutes

Severity: (apply one of the following to the related alert)

•

Medium (90%)

•

High (95%)

•

Critical (97%)

You should allocate additional perm space to a database as soon as possible after perm space usage exceeds 90%.

Databases that trigger the High or Critical alert levels before you can respond to a Medium alert are growing very fast and should receive more space immediately.

You can investigate which tables are using database perm space.

See

“Identifying Space

Problems” on page 297

300 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Managing Query Problems

About Common Query Problems

Query Problem

Stale statistics

Badly skewed data

Poor query construction

Concurrency issues

Result

The optimizer uses statistics to plan query execution. If the statistics are out of date, the optimizer may create a poor plan.

Recommendation: Review tables to see whether statistics are out of date, and recollect statistics if required.

Causes table rows to be distributed unevenly among AMPs and queries to execute unevenly, which slows processing time.

Recommendation: Monitor table skew. Redefine the primary index

if required. See “Finding and Fixing Skewed Tables” on page 298

Poor SQL syntax or missed punctuation can result in bad queries.

Recommendations:

•

Identify bad queries and the users responsible for them. See

“Identifying Problem Queries” on page 301

•

Abort bad queries when required. See “Controlling Problem

Queries” on page 302

Some queries are delayed or prevented from executing because of lock contentions, or the relative priorities of concurrent queries.

Recommendations:

•

Identify the cause of a delayed query. See

“Investigating Query

Blocks and Delays” on page 304 .

•

Release a query from the delay cue. See

“Controlling Problem

Queries” on page 302

•

Change the priority for a database operation or user. See

“Changing the Account for a Session or Request” on page 307

•

Establish more detailed concurrency controls using Teradata

IWM. See

“Setting Up Workload Management” on page 309 .

Viewing Lock Contentions

The Teradata Viewpoint Lock Viewer portlet generates a continuous report of database lock activity, based on the settings for the:

•

Time interval defined in the Lock Info data collector (default 3600 seconds)

Log table columns selected as enabled from the Table Actions menu the log columns in the Lock Viewer portlet.

to the right of

Identifying Problem Queries

When notified of delays by a user or an alert, you can use the Query Monitor portlet to find out if the delay is the result of a problem query.

Teradata Data Warehouse Appliance 2800 Implementation Guide 301

Chapter 13: Managing the Database

Managing Query Problems

Note: The Query Monitor portlet has many functions beyond what is shown in this example procedure. See Teradata Viewpoint User Guide for detailed setup and options.

Monitor query activity using the By Session tab.

Look for problem queries using the following Query Monitor parameters:

•

High CPU Use% combined with low REQ I/O accesses. If the CPU divided by the I/0 is

> 100, it indicates a problem query.

•

High CPU Skew% with significant Delta CPU.

•

High spool usage.

Note: You can click and sort the display by a parameter instead of by session number.

Select a session row that shows CPU characteristics indicating a problem query to display the Details View, which provides information about the query, including the user and account that submitted the query.

Select the SQL tab to display the SQL for the query. Examine the SQL for errors and poor construction.

Select the Explain tab to display an abbreviated version of the step statistics and explain text (generated from a full EXPLAIN request), along with a listing of the active steps, completed steps, and steps yet to run.

Check for the following in the Explain:

•

The steps required to execute the query

•

The type of operation being performed, and whether it includes a product join

Often the query is stuck on the step where the product join occurs.

You can copy the query from the SQL tab, run it from Teradata SQL Assistant, and request a full EXPLAIN to get more details and validate the source of the problem.

If a bad query causes problems in the database, you can:

•

Use Query Monitor to control the query. See

“Controlling Problem Queries” on page 302 .

•

Use the SET SESSION ACCOUNT request to re-assign a poorly-performing query to a

lower-priority account. See “Changing the Account for a Session or Request” on page 307 .

Controlling Problem Queries

To control a problem query:

In the Query Monitor portlet, click the session with the identified problem query. The

Details view appears.

You can use Manage Queries to:

•

Abort or Change Priority

•

Change Workload

•

Release Query

You must log in with a user ID that has permissions to abort or change priorities, change workloads, or release queries. If you log off, close a portlet, or open a new portlet instance, you must log in again.

302 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Managing Query Problems

Note: Change Workload is available only if Teradata Active System Management

(TASM) is enabled. If TASM is disabled, Change Priority is available. If you do not see

Change Workload or Change Priority in the menu, the system you are monitoring does not support these features or you do not have permission to use them. If the query you are monitoring is delayed, only Release Query is available.

See “About Managing Queries and Sessions” in the Teradata Viewpoint User Guide,

B035-2206.

Note: Use the following guidelines when considering whether to abort a session:

•

Do not abort the session if it is still running other queries.

•

If the session is not running other queries.

•

If the query is a SELECT statement, you can safely abort the query.

•

If the query includes an INSERT, UPDATE, DELETE, or other statement that changes data, aborting a partially completed query may cause data problems.

About Lock Contentions

Teradata Database uses the Lock Manager to automatically lock database objects accessed by each transaction, to prevent or limit simultaneous access by other transactions. Before the transaction begins, the Lock Manager requests a lock on the data. When the transaction is complete, the Lock Manager releases the lock.

Locks have different degrees of severity or exclusivity according to the type of transaction being processed.

Lock Level Description

Read Prevents write and exclusive locks. Generally caused by a SELECT.

Ensures consistency during read operations. Several users may hold concurrent read locks on the same data, during which no modification of the data is permitted.

Write

Exclusive

Prevents other read, write, and exclusive locks. Generally caused by an INSERT,

UPDATE, or DELETE statement.

Enables users to modify data while locking out all other users except those using access locks. Until a write lock releases, no new read or write locks are allowed.

Prevents any other type of concurrent access. Generally caused by statements that make structural changes, for example, using an ALTER TABLE statement to add, drop, or change a column, when the statement uses the LOCKING modifier.

Exclusive locks are the most restrictive type of lock. When you hold an exclusive lock, other users cannot read or write to the data.

Access Prevents exclusive locks only. Caused by the LOCKING…FOR ACCESS statement modifier.

This type of lock allows for reading data while modifications are in process. Access locks are designed for decision support on large tables that are updated only by small, single-row changes. Access locks can cause “stale reads,” in that other concurrent queries may access data that has not been updated.

Teradata Data Warehouse Appliance 2800 Implementation Guide 303

Chapter 13: Managing the Database

Managing Query Problems

Investigating Query Blocks and Delays

Most blocks are momentary and do not require attention. However, if a block persists, you can investigate it to identify the cause and determine whether further action is required.

Use the Teradata Viewpoint Query Monitor portlet to monitor the parameters related to query blocks and delays.

State

Blocked

Description

Indicates that a session query is held up by a lock on an object that the query is attempting to access.

Blocked Time How long the query has been blocked.

Momentary locks are normal and not harmful. Persistent locks may indicate:

•

A runaway query or hung query that cannot complete and release its locks, and which should be aborted

•

A long-running query, such as large-scale update or backup operation, which should be rescheduled to avoid resource contention

Delayed Indicates that the query is in a delay queue caused by a workload rule.

Click the session ID for the query to access the Details View.

•

If a query is blocked, see the Blocked By tab for details

•

If the query is delayed, the Delay tab provides details about the cause of the delay

You can also use the Lock Viewer portlet to find out additional details about the block.

About Blocks and Delays Due to Workload Management Priorities

In addition to blocks that result from normal query execution, blocks can also occur as a result

of the enforcement of workload management rules (see “Teradata Integrated Workload

Management” on page 308 ).

Single-statement transaction requests held in workload management delay queue do not hold limited resources until after they are released from the queue and begin execution. However, requests that are part of a multi-request transaction (multiple requests embedded between

BT/ET) may hold resources while on the delay queue.

The system detects blocks caused by workload management queuing. You can set Teradata

Integrated Workload Management to log, release, or abort the query when such blocks occur,

based on settable parameters. For more information, see “Managing Blocks That Result from

Throttle Delays” on page 326

304 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Managing User Activity with Accounts

Reference Information

Information on...

Locking Logger, Lock Display, and Show Locks utilities managing locks lock and transaction processing

Is available in...

Utilities: Volume 2 (L-Z), B035-1102

Database Administration, B035-1093

SQL Request and Transaction Processing, B035-

1142

Managing User Activity with Accounts

Teradata recommends that you devise an account system based on the jobs and resource requirements common to groups of users, and then assign accounts to users in profiles.

Specify one or more accounts for each profile, as required by profile members, using the

CREATE PROFILE or MODIFY PROFILE statement. Specifying an account in a profile

“creates” the account. You can specify the same account in more than one profile, if needed.

The first account listed for a profile is the default account for member users.

Active accounts and account assignments are listed in DBC.AccountInfoV.

You can use accounts to:

•

Require the system to tag each session with a number, time stamp and date stamp for

monitoring and accounting purposes. See “Working with User Accounts” on page 251 .

•

Charge for space or processing resources used. See

“Managing User Activity with

Accounts” on page 305 .

•

Assign workload management parameters that define database access priorities. See

“Teradata Integrated Workload Management” on page 308

About Account String Structure

An account string should follow this format:

‘$G

0+account_ID&S&D&H’ where:

•

The G in the $G

phrase is the priority indicator.

•

account_ID

is a four character workload descriptor that starts at the fifth character.

•

ID&S&D&H

is a set of optional account string variables.

Teradata Data Warehouse Appliance 2800 Implementation Guide 305

Chapter 13: Managing the Database

Managing User Activity with Accounts

Use of the Account String Priority Indicator

In past Teradata Database releases, the priority indicator (the G variable in the example above) defined the default priority level for sessions that used the account.

For Teradata Database 15.0 and up on SLES 11, session priority levels are no longer defined by the account string, but are determined by settings in the Viewpoint Workload Designer portlet. You can use the priority character to indicate the priority that is set in Workload

Manager. See “Using Workloads to Define Query Priority Level” on page 312 .

Note: Even if you choose not to use the G variable to indicate priority level, the position is still required as a placeholder, to ensure that the account_ID starts in position 5 in the string, for compatibility with existing applications and related system functions.

Constructing account_IDs to Identify the Assigned Workload

You can construct the account_ID portion of each account string based on the workload assignment that is associated with the account, but it is not required.

Use of the Account String Expansion Variables

The portion of the account string following the account_ID is used for account string expansion (ASE) variables. Teradata recommends the &S&D&H (shown in the preceding example account string) to add a time and date stamp to each session that uses the account.

Various Data Dictionary logs and Teradata Viewpoint portlets use the time and date stamp to track session events.

Other ASE variables are available. See Database Administration, B035-1093.

Using Accounts as Workload Management Criteria

You can use the workload management features in the Teradata Viewpoint Workload Designer portlet to create workloads, throttles, and filters to use in managing query priority, concurrency, and resource consumption.

After creating accounts and assigning them to users, you can assign workload management controls by account. Although you can use other criteria to assign workload controls, accounts are one of the best and easiest to use assignment methods.

For more information, see “Teradata Integrated Workload Management” on page 308

Using Accounts for Resource Charge Back

Charge-back billing using accounts permits objective cost allocation of system resources across all users and the ability to charge users for their use of database resources.

The user account string enables you to summarize resource usage by account ID. The system table DBC.Acctg tracks CPU use in seconds and I/O resources expended by a session. The I/O resource tracks the number of AMP-to-disk read and write operations generated by a given session, and charges them to the current account associated with a session.

You can use the DBC.AMPUsage view to access aggregations of logged in DBC.Acctg.

306 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Managing User Activity with Accounts

How the System Determines the Session Account

When a user logs on, the system determines the session account based on the following hierarchy. Each account source supersedes the source that precedes it in the hierarchy.

•

The default user account (first account specified) in the:

•

User definition

•

User profile, if the user is a profile member (supersedes any accounts defined in the user definition)

•

A user account specified in the logon string, when the user has multiple accounts and does not want to use the default.

•

An account specified in a SET SESSION ACCOUNT statement, as described in “Changing the Account for a Session or Request” on page 307 . The statement is often used when the

user has multiple accounts, and needs to change accounts among several jobs/requests run in the same session.

Note: If an account string is not available from these sources, the system uses the default account for the parent user. This is not recommended because the parent user priority level may be inappropriate.

Changing the Account for a Session or Request

You can use the SET SESSION ACCOUNT statement to change the account during a session.

For example, if a user in the Finance department has the default FIN1 account with a medium

(M) access level:

'$M0+FIN1&S&D&H'

The user can use SET SESSION ACCOUNT to change to a different account string associated with a workload (FINT) that has a top priority (T) access level.

SET SESSION ACCOUNT='$T0+FINT&S&D&H' FOR REQUEST;

A SET SESSION ACCOUNT statement must specify an account that is assigned to the user executing the request, either in the user definition or in a profile of which the user is a member.

Investigating Accounts

You can reference the DBC.AccountInfo V to view the list of names for an account or account category and determine whether each name is an individual user or a profile. For example:

SELECT AccountName,UserName,UserOrProfile

FROM DBC.AccountInfoV

WHERE AccountName LIKE '$R%'

ORDER BY AccountName ;

Teradata Data Warehouse Appliance 2800 Implementation Guide 307

Chapter 13: Managing the Database

Teradata Integrated Workload Management

The Teradata Data Warehouse Appliance 2800 uses Teradata Integrated Workload

Management (IWM) parameters to manage database queries and enforce priorities.

You can define a Teradata IWM rule set, using the Workload Designer portlet in Teradata

Viewpoint, and then configure the rule set to perform workload management functions using the features shown in the following table.

Workload Management Feature Description

Workloads Each workload defines a set of database access priority rules and the class of queries to which the rules apply.

Session Limits

Throttles

Defines system-wide limits on the number of sessions that are allowed to be logged on at one time.

Throttles to manage query concurrency, and may cause the system to delay some queries when throttle thresholds are exceeded.

Throttles can be applied system-wide or only to specific workloads.

Filters

Bypasses

Utility controls

States

Filters to reject queries that have certain characteristics before they begin to execute.

Filters are applied system-wide.

Allow some queries to be exempted from rules that would otherwise delay or reject them.

Manages Load/Export utility and console utility work flow separately from other query activity.

Manages queries and allocates resources based on operating period events.

After creating a new state, you should review the state-specific values of your filters and throttles.

The Teradata Viewpoint Workload Designer portlet provides many additional options for controlling workloads. For details, see Teradata Viewpoint User Guide, B035-2206.

Note: The following features are not available on the Teradata Data Warehouse Appliance

2800:

•

Service Level Goals (SLGs)

•

Non-Tactical Workload Exceptions

•

Virtual Partitions

For information, see the Teradata Viewpoint User Guide, B035-2206.

308 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Setting Up Workload Management

You can use the Teradata Viewpoint Workload Designer portlet to create Teradata IWM rule sets that regulate the database workload.

For details on using the Workload Designer portlet, see Teradata Viewpoint User Guide, B035-

2206.

Overview of Workload Management Tasks

Determine workload management needs. See “Determining Workload Management

Needs” on page 309

Create a ruleset. See

“Creating a Ruleset” on page 310 .

Create one or more workload definitions and assign each one to a priority access level. See

“Using Workloads to Define Query Priority Level” on page 312

Create system-level workload management controls.

•

Session limits

•

Throttles

•

Filters

•

States

See

“System-Level Workload Management” on page 318

Optionally define separate load/export utility and console utility session limits and throttles. See

“Managing Utility Jobs” on page 322

Optionally set up block management criteria for handling queries that get stuck in a throttle delay queue. See

“Managing Blocks That Result from Throttle Delays” on page 326 .

Determining Workload Management Needs

Before defining Teradata IWM workload management parameters, you should evaluate how your database is used. The objective is to identify job handling and query limitation needs that cannot be met by performance group assignments and scheduling.

•

Monitor database activity using the Teradata Viewpoint Metric Heatmap portlet to understand overall workload concurrency and possible resource contention. For information on the Metric Heatmap portlet, see Teradata Viewpoint User Guide, B035-

2206.

•

Use the Teradata Viewpoint Query Monitor and Lock Viewer portlets to study resource contention at various times of day, to understand blocking and wait time patterns. See the

sections beginning with “About Lock Contentions” on page 303

Teradata Data Warehouse Appliance 2800 Implementation Guide 309

Chapter 13: Managing the Database

Creating a Ruleset

•

Optionally use the database query logging (DBQL) logging feature to determine query performance details. For information on tracking processing behavior with DBQL, see

Database Administration, B035-1093.

•

Optionally monitor the ResUsageSPS table to determine resource usage by performance group. For information on the ResUsageSPS table, see Data Dictionary, B035-1092.

If less important queries are preventing critical queries from executing in a timely manner, you can use workload management controls to prioritize queries.

Creating a Ruleset

You must create a Teradata IWM ruleset to contain any workload management rules that you want to define. You can create multiple rulesets, but only one ruleset can active at a time. In the interest of simplicity, Teradata suggests that you start with a single ruleset.

After you complete the setup of all rules in the main ruleset, and have activated and tested it, you can create another ruleset that is a variation of the main set to use in adjusting workload management parameters.

Note: This and other workload management set up tasks in this chapter use the Teradata

Viewpoint Workload Designer portlet. For detailed instructions on using the Workload

Designer portlet, see Teradata Viewpoint User Guide, B035-2206.

In the Workload Designer Ruleset view:

Click the + on the top right of the Working area to create a new ruleset.

Add a Name and Description for the ruleset.

For the initial implementation, use the defaults on the Bypass, Reserves, and Other tabs.

Activating and Changing Rulesets

When you complete creation of the workloads and system-level controls, as shown in the topics that follow, use the:

•

Make Ready option to copy the ruleset to the Teradata Database server and to the Ready section.

•

Make Active option to make the ruleset take effect on subsequent database queries.

To revise an active ruleset, first make another ruleset active using the drop down list next to the ruleset name. This automatically moves the previously active ruleset into the Ready area.

To edit the ruleset, using the drop down list next to the ruleset name, choose Copy to Working

Rulesets. From there, you can make changes and then select Make Active.

For details, see Teradata Viewpoint User Guide, B035-2206.

310 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Creating States

Create states to control how your system allocates resources during different time periods. For example, besides the default Base state, you can create a state for a late night batch window and a state for month-end processing. Once you create a state, you can apply filters, throttles, and workloads based on those states.

To create a state, do the following:

Click the States tab in the Ruleset toolbar.

Click the Setup Wizard button.

Click Next.

Click the + next to Planned Environments.

Click the pen icon to edit the name of the planned environment.

Click Next.

Click the + next to Available Events.

Click a radio button to select the event type.

Under Configure Event Details, give the event a name and description.

Click the check box next to Create New Corresponding Planned Environment.

Under Event Frequency and Duration, choose the time period for the event.

[Optional] Select Wrap around midnight to have a time range spanning midnight for a period event.

[Optional] Under Configure Notifications, enable the following options for the start or the end of the event:

•

Send Alert: Select an alert to send when the event starts or ends.

•

Run Program: Not available on Appliance 2800 systems.

•

Post to QTable: Type a message to post to the system queue table when the event starts or ends.

Click OK.

Click Next.

To map a state to a planned environment (a time frame), either drag an existing state into a planned environment or click the + next to States to create a new state. Then drag that new state into the planned environment.

Click Finished.

Teradata Data Warehouse Appliance 2800 Implementation Guide 311

Chapter 13: Managing the Database

About Multiple Planned Environments

With multiple planned environments (operating periods) defined, more than one can be in effect at the same time. For example, a Daytime planned environment is in effect from

8 am- 5 pm. A Weekend planned environment is in effect Saturdays and Sundays. At 8 am on

Saturday both periods apply.

Teradata Dynamic Workload Management evaluates the planned environments from right to left, so drag them into the order in which you want them to be applied. For example, if you want the throttles associated with the Weekend planned environment to be in effect at 8 am on Saturday, drag the Weekend planned environment to the right of the Daytime planned environment on the States tab of the Ruleset toolbar.

Using Workloads to Define Query Priority Level

Workload management is most easily initiated using workload-based rules, that is, a collection of rules that only apply to a subset of database requests.

About Workloads

You can create workloads to represent a class of database requests (queries) with common characteristics. Workloads are useful for:

•

Setting differing access priorities for various classes of queries.

•

System usage accounting to aid such activities as monitoring resource usage patterns, performance tuning, and capacity planning.

Identifying a subclass of queries to which a workload should apply may use some of the same criteria used to create and assign accounts or profiles to user groups. Other classification criteria may include originating application, target database object or query type. For details, see

“Workload Classification Settings” on page 315 .

The system allows you to define up to 250 workloads, however, you should only create a workload where there is a clear need. Usually creating 5 to 20 workloads should be sufficient to efficiently manage system workloads while minimizing workload administration.

Workload Priority Levels

The system prioritizes database queries by the hierarchical tier, and the access level or performance group within that tier, to which a query is assigned by the workload applicable to the query. Queries are processed by the uppermost applicable tier. Queries that do not have an assigned tier and performance group default to Timeshare tier, Medium priority.

312 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Using Workloads to Define Query Priority Level

Top High Medium Low

Internal Tier

The Internal Tier automatically handles system-level functions, for example access privilege checking or querying/writing to the data dictionary, at the highest priority level.

System resources in excess of those required for handling internal system functions fall to the

Virtual Partition Tier.

Virtual Partition Tier

A virtual partition represents a collection of workloads. There is only a single virtual partition available with Teradata IWM. The administrator cannot make changes at this level in the hierarchy. All remaining system resources fall to the Tactical Tier.

Tactical Tier

The Tactical Tier is an optional tier that may not contain workloads in some Teradata

Database sites. This tier is intended exclusively for highly-tuned, very short duration tactical queries – primarily queries that support single-AMP and few-AMP operations.

Workloads running at the Tactical level receive all the resources they need, with the remaining resources passed down to the next level. Because of this unique characteristic, special care needs to be taken when defining Tactical workloads.

•

Only highly-tuned, very short, single-AMP or few-AMP queries should be assigned to a

Tactical workload.

•

Do not use Tactical workloads for load utilities.

Teradata Data Warehouse Appliance 2800 Implementation Guide 313

Chapter 13: Managing the Database

Using Workloads to Define Query Priority Level

•

As a safe guard, adjust the exception thresholds, if needed, so that they effectively demote queries with non-tactical characteristics from Tactical to Timeshare.

•

Monitor tactical exceptions regularly, adjust the exception thresholds, when needed.

System resources that remain after executing Tactical Tier queries fall to the Timeshare Tier.

Timeshare Tier

The Timeshare Tier is intended for all non-tactical queries. It is normal for the Timeshare Tier to prioritize nearly all queries on most database systems. Prioritization is done by means of sub-tiers called access levels, each of which represents a prioritization level.

The Timeshare Tier has four predefined access levels that you can assign to workloads:

Timeshare Access Level

Top

High

Medium

Low

Access Weight

The access weight determines the relative processing resource allocation available to each access level and the frequency with which the system offers CPU to jobs running at that level.

Access level does not predict actual CPU usage or consumption. Lower level jobs receive more

CPU when higher level jobs are not using it.

The following is a typical set of access level assignments:

•

Top: Emergency jobs

•

High: Short (sub-second) queries

•

Medium: Longer queries

•

Low: Large batch jobs and reports.

Note: These assignments are shown only as examples. Always assign access levels according to site-specific business needs.

After completing the initial setup of Timeshare tier workloads, change a workload access level by dragging the workload from one level and dropping it into another from the Workload

Distribution tab.

314 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Using Workloads to Define Query Priority Level

Workload Classification Settings

Once you create your workload, use the Classification tab options to assign workload classifications. If you do not specify a classification, the rules defined for the parameter apply globally.

Classification Criteria

Request Source

Description

The query source. Can be one of the following:

•

User name

•

Account name

•

Account string (includes ASE variables)

•

Profile

•

Application

•

Client IP address

•

Client ID

Target The query target:

•

Database object (database, table, view, macro, stored procedure, function, method, QueryGrid Server)

•

Sub-criteria related to the object, for example: “Unconstrained product join against table XYZ.”

Query Characteristics For example, estimated total processing time, statement type, join type, full table scan, memory usage.

Query Band

Utility

Criteria that can be specified in a SET QUERY BAND statement.

The utility that is the source of the query, for example, TPT Load operator.

Recommendations:

•

You can use as many of the workload classification criteria as required, but Teradata recommends that you simplify classification wherever possible so that the effects are clear.

•

Request source and query band classification criteria are the most exact and predictable.

Use one of these classification methods whenever possible.

•

Use the Target, Query Characteristics, and Utility criteria mainly to differentiate subclassifications of request source and query band criteria, rather than as primary criteria.

Creating a Workload

In the Ruleset toolbar, select Workloads.

Select the + next to Workloads to create a workload.

In the General tab, enter a name and [optional] a description.

Under Workload Management Method, select Tactical or Timeshare, based on how you want to assign priority for queries to which the workload should apply. See the descriptions in

“Workload Priority Levels” on page 312 .

Click Save.

Teradata Data Warehouse Appliance 2800 Implementation Guide 315

Chapter 13: Managing the Database

Using Workloads to Define Query Priority Level

Click the Classification tab.

Select the classification criteria.

Click Add. Add details to the criteria and click OK.

Click Save.

Optionally create a workload throttle, as shown in the following topic.

If you selected Timeshare in step 4

, the newly created workload appears in the Medium access level in the Timeshare section of the Workload Distribution tab. You can drag and drop the workload to a different access level if required.

Using Workload Throttles

A workload throttle is an attribute of a specific workload or workload group, which only controls queries that are classified for that workload. Otherwise, workload throttles function the same as system throttles. You can apply a workload throttle to a single workload or a workload group.

Recommendations for workload throttles:

•

Create workload throttles first and then introduce system-level throttles later, if needed.

•

Avoid throttling Tactical workloads, which are supposed to have priority among concurrent queries.

•

Throttle Low and Medium timeshare workloads to avoid a shortage of AMP worker tasks.

For a detailed description of options and usage, see “Working with Throttles” on page 319

Also see

“Using Workload Utility Throttles” on page 325

Creating a Workload Throttle

From the Ruleset toolbar, select Throttles.

Next to Workload Group Throttles, click +.

Enter a name and, optionally, a description to create a group throttle.

Click Save.

Click the State Specific Settings tab.

Click a previously created state in the Planned Environments area.

Under Default Settings, Concurrency Limit, select either Unlimited or Limited. If choosing

Limited, enter a limit number for concurrent queries in the box and select Delay.

To apply the workload throttle to the workload, select Workload on the Ruleset toolbar.

Create a workload and then select the Throttles tab and select a group throttle. But why are there no workload throttles to choose from.

Defining Workload Exceptions

A workload exception can be used to change a workload control parameter for an atypical condition that may arise among a set of queries that would normally be assigned to a workload.

316 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Using Workloads to Define Query Priority Level

Note: Teradata Integrated Workload Management on the Teradata Data Warehouse Appliance

2800 only supports the definition of exceptions on Tactical workloads.

You can use the Tactical Exception tab to express workload exceptions as thresholds. You cannot create an Exception for a non-Tactical workload.

Setting

Tactical CPU Time

Tactical I/O Physical Byte

Explanation

This is the CPU seconds consumed by the query. It can be set to either:

•

CPU per node

The default value is 2 seconds.

•

CPU (sum over all nodes)

The default value is the number of nodes multiplied by the CPU per node value.

This is the physical bytes of I/O transferred. It can be set to either:

•

Physical bytes of I/O transferred per node

The default value is 200 MB.

•

Physical bytes of I/O transferred (sum over all nodes)

The default value is the number of nodes multiplied by the I/O per node value.

Note: The values of these parameters (either defaults or saved custom values) remain in effect until they are changed. If you add nodes to the configuration, the system does not automatically recalculate the per node values.

To complete the exception definition, you must specify an alternate tactical workload, to which a query transfers if it exceeds the threshold, using “Change Workload.”

Usage Notes

The normal use of tactical exceptions is to differentiate among tactical queries that may otherwise be subject to the same workload. For example:

•

For a tactical workload where the Source specifies an application that is normally used to submit low CPU usage queries, you can use an exception to detect queries with higher

CPU usage and route them to a lower priority workload.

•

For business critical applications that may sometimes need to consume large amounts of

CPU and I/O. You can set the values small for most queries in the workload and create an except to allow extra resources.

For additional information, see “Workload Designer” in Teradata Viewpoint User Guide,

B035-2206.

Teradata Data Warehouse Appliance 2800 Implementation Guide 317

Chapter 13: Managing the Database

System-Level Workload Management

Specifying an Evaluation Order

If you create several workloads, a query attempting to run on the database may be subject to more than one of the workloads. To avoid uncertainty as to which workload a query should be assigned to, define a workload Evaluation Order. When multiple workloads apply to query, the system always uses the workload closest to the top of the list.

In the active ruleset that contains the workloads you want to prioritize, click the Workloads tab.

Click the Evaluation Order tab.

In the list of workloads, do one of the following to create the needed evaluation order:

•

Drag and drop workload names to reorder the list.

•

Click in an item number box, and after highlighting the number you want to change, enter the new number.

Click Save.

Note: You can also set the evaluation order for utility management rules. For information on workload management for Utilities, see

“Managing Utility Jobs” on page 322 .

System-Level Workload Management

In addition to managing queries at the workload level, you can also create system-level controls. Workload-based controls only apply to queries assigned to one or more workloads.

System level controls apply to all queries attempting to access the database.

Teradata IWM system-level control methods include the following.

Method

Session Limits

Throttles

Filters

Bypass

Function

Rejects queries if the number of sessions exceeds specified limits.

Delays or rejects queries if the system workload exceeds certain concurrency criteria.

Reject queries that have certain characteristics.

Allows queries in a defined bypass classification to avoid restrictions imposed by a system-level control.

Creating Session Logon Limits

To limit the number of sessions that can be logged on at once and reject logons that exceed that limit, do the following:

Click the Sessions tab on the Ruleset toolbar.

On the Query Sessions tab, click + to create a new limit.

Enter a name and a description.

318 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

System-Level Workload Management

Under Rule Type, select one of the following:

•

Collective: Applies the throttle to all users that meet the criteria.

•

Individual: Applies the throttle individually to each user or database object.

•

Member: Applies the throttle to individual members of an account or profile group classification.

Click Save.

On the Classification tab, click Add Criteria.

In the Edit Request Source Criteria window, select the Source Type.

Select the source from the list.

Click Include.

Click OK.

Click Save.

On the State Specific Settings tab, do one of the following:

•

Click a state and set the session limit for that planned environment.

•

Under Default Settings, click the radio button next to the empty box and enter the maximum number of sessions that can be logged on at once.

Click Save.

Working with Throttles

Throttles manage query concurrency, and can either reject or delay queries when specified concurrency limits are exceeded. When system activity falls below the throttle concurrency limit, the system begins to run delayed queries in the order they were delayed. If a query has been delayed and then begins to run, it cannot be delayed again.

Use workload throttles primarily to prevent a large number of relatively low priority queries from running at the same time, leaving no available resources for higher priority queries.

Note: If a query is subject to multiple throttles, it must be allowed by all throttles before it can run.

Example Throttle Rules

A throttle limits the number of concurrent queries in a filter classification. When the throttle limit is reached, additional affected queries go into the delay queue.

You can create throttles to limit concurrency according to throttle classification, for example:

•

Limit a specific user (source classification) to having no more than 10 sessions at a time

(query session limit).

•

Limit the number of application X sessions (source classification) simultaneously executing against a table (target classification).

•

Allow no more than 3 concurrent data mining queries (source classification), because data mining is slow and uses significant resources.

Teradata Data Warehouse Appliance 2800 Implementation Guide 319

Chapter 13: Managing the Database

System-Level Workload Management

•

Limit queries based on query characteristics, for example, statement type, step row count, or join properties.

•

Limit the number of queries that can be run during end-of-the-month processing (Limits by State).

Comparing System Throttles to Workload Throttles

You can create throttles to reject or delay queries at either the workload or system level.

Although these two types of throttles function in similar ways, there are some differences.

Throttle Type

Workload Throttle

System Throttle

Description

Controls query concurrency only for the associated workload.

A workload throttle is subject to the same classification criteria as the parent workload.

Controls query concurrency for all queries, or for a specified subset of queries, across the entire system.

System throttles are most useful during temporary system-wide situations. Throttles do not affect sessions that are already executing.

System throttles can make full use of all classification criteria.

Do not use system throttles for utilities.

Default System Throttles

The following throttles are created by default on Teradata Data Warehouse Appliance 2800 systems, and automatically apply globally.

Throttle all at 52:

•

Limits the database to execution of 52 concurrent queries.

•

Places additional queries into the delay queue.

•

Prevents unusually large query demand from putting the system into flow control.

Throttle High, Medium, and Low timeshare access level queries with estimated processing time > 1 second:

•

Sets a limit of 30 concurrently executing H, M, or L queries that have an estimated processing time > 1 second. There is no built-in limit on shorter queries.

•

Places additional long queries into the delay queue.

•

This throttle does not apply to short queries (<1 sec), or to a Top query of any size.

Creating a System Throttle

Use the following procedure to create a system throttle. To create a workload throttle, see

“Working with Filters” on page 321 . Also see

“Using Workload Utility Throttles” on page 325

and

“Creating Session Logon Limits” on page 318

320 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

System-Level Workload Management

From the Ruleset toolbar, click Throttles.

Click the + next to System Throttles to create a system throttle.

Enter a name and description.

Select a Rule Type option:

•

Collective applies the throttle to all users that meet the criteria.

•

Individual applies the throttle individually to each user or database object.

•

Member applies the throttle to individual members of an account or profile group classification.

Click Save.

Click the Classification tab.

From the drop-down list, specify the classification criteria.

Click Add.

Enter the details in the pop-up window.

Click OK.

Click Save.

Click the State Specific Settings tab. Do one of the following:

•

Click a state and set the limit for that planned environment.

•

Under Default Settings, click the radio button next to the empty box and enter the maximum number of active queries or utility jobs. Choose Delay or Reject.

Click Save.

Working with Filters

A filter rejects applicable queries before they begin running. Filters work in a way similar to throttles, except that filters cannot delay a query, only reject the query or let it run.

You can only define system-level filters. Workload filters are not allowed.

Because filters prevent applicable queries from ever running, they are not commonly used. If you do use filters, you can create Bypasses to exempt certain query classifications from being affected by a filter.

You can enable or disable filters for states, for example, to filter all queries from a certain source during a late night batch window.

Filters use the same classification criteria as workloads. See “Workload Classification Settings” on page 315

Teradata Data Warehouse Appliance 2800 Implementation Guide 321

Chapter 13: Managing the Database

Managing Utility Jobs

For example, you can use classification criteria to define filters that prohibit:

•

A specific user (source classification) from running a query with an estimated processing time of longer than 15 minutes (query characteristic classification).

•

Any query without join constraints (query characteristic) that runs against a large complex table (target).

For information on creating filters and using Warning Mode, see Teradata Viewpoint User

Guide, B035-2206.

Use of Warning Mode During Initial Implementation

When creating a filter, you can specify Warning Only mode for use during initial implementation. This mode returns a warning message when the filter affects a query rather than rejecting the query, so you can determine how the filter is functioning without disrupting users. Once you determine that the filter is working as planned, you can remove it from

Warning Only mode and allow the system to reject affected queries as designed.

Managing Utility Jobs

You can use Teradata IWM to manage the concurrent use of certain Teradata utilities, at a system level or for specific workloads.

Protocol

Load/Export Utilities

FastLoad

Applications

MultiLoad

FastExport

•

Teradata Parallel Transporter Load Operator

•

FastLoad utility

•

JDBC FastLoad

•

CSP Save Dump

•

Non-Teradata FastLoad

•

Teradata Parallel Transporter Update Operator

•

MultiLoad utility

•

JDBC MultiLoad

•

Non-Teradata MultiLoad

•

Teradata Parallel Transporter Export Operator

•

FastExport utility

•

JDBC FastExport

•

Non-Teradata FastExport

322 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Managing Load/Export Utility Jobs

Protocol

Backup/Restore

Applications

•

ARCMAIN

•

Supported BAR applications

Console Utilities

Console utilities For example:

•

Check Table

•

Scan Disk

Note: Teradata IWM utility management functions are also supported for third-party load/ export utilities that use the Teradata Parallel Transporter Application Programming Interface

(API).

Note: The TPump and Teradata PT Stream operator function using the SQL protocol can be managed using standard query-oriented workload management tools, for example, workloads, session limits, throttles, and filters.

Managing Load/Export Utility Jobs

Workload management of load/export utility concurrency includes:

•

Utility Limits (system-level utility job throttles)

•

Utility Session Limits (system-level utility per-job session throttles)

•

Utility Concurrency limits (workload utility throttles)

Consider the following when determining how best to use throttles to manage utility jobs.

•

Use system-level utility throttles to set general utility session concurrency limits, for example, for all users or all accounts.

•

Use workload throttles for more detailed utility concurrency control, for example, for use of utilities by a specific user or account.

Using Utility Limits to Manage Load, Export, and Backup/Restore Jobs

The Teradata Data Warehouse Appliance 2800 has several default utility limits, based on utility protocol. You can also create custom job limits.

Default Utility Limits by Utility Protocol

Utility Protocol

FastLoad + MultiLoad

Job Limit

FastLoad 30

MultiLoad 30

Teradata Data Warehouse Appliance 2800 Implementation Guide 323

Chapter 13: Managing the Database

Managing Load/Export Utility Jobs

Utility Protocol

FastExport

Backup/Restore

Job Limit

350

Creating Custom Utility Job Limits

If possible, use the default utility job limits listed in the previous topic. If the default limits are not sufficient, you can create custom utility job limits.

On the Sessions tab, click the Utility Limits tab.

Next to Utility Limits, click the + to add a new limit.

Enter the name and a description and click Save.

On the Classification tab, select the utilities to which the limit will be applied and click

Save.

On the State Specific Settings tab, click a state that you defined previously and select either

Use Default Settings or Create State Specific Settings. For state specific settings, click the

Job Limit box, enter a number, and select either Delay or Reject.

Click OK.

Click Save.

About Utility Workloads

Observe the following when using Teradata IWM Workloads to manage utility sessions.

The Teradata IWM handles the entire load/unload process as one unit of work. The unit of work starts at the BEGIN LOADING/MLOAD/EXPORT statement on the control SQL session. It ends after the END LOADING/MLOAD/EXPORT statement. Therefore, a utility unit of work spans multiple SQL statements.

Only the first SQL statement of a unit on the control SQL session is subject to the Utility classification criterion used to assign a utility workload. Subsequent statements of the unit are automatically assigned to the same utility workload.

SQL statements outside the load/unload unit as well as SQL statements from any auxiliary

SQL sessions are assigned to a different workload(s).

This also applies to workload throttles. See “Using Workload Utility Throttles” on page 325 .

Using Workloads to Manage Load/Export Job Priorities

You can use Teradata IWM Workloads to manage load/export job priorities. For example:

Create the workloads you want to manage, as shown in “Creating a Workload” on page 315 . Timeshare workloads default to medium priority.

Note: The following classification criteria are not available to utility workloads:

•

Query Characteristics: All

•

Targets: Macro and stored procedure

324 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Managing Load/Export Utility Jobs

From the main Workloads screen, click the Workload Distribution tab.

Drag the workload whose priority you want to change to the desired priority. For example, you can drag workload MultiLoad from Low to High.

Click Save.

Using Workload Utility Throttles

Workload throttles are useful mainly to create very detailed concurrency controls, for example, for a specific user. Otherwise you should use system-level throttles to control utility concurrency.

Applicable throttle counters (system and workload throttles) are only checked and incremented at the beginning of a work unit. Throttle counters are decremented at the end of a unit. For backup/restore, the entire script is treated as one unit.

Note: Teradata IWM sees a utility job as a single unity of work. Only the initial SQL statement in a load/export job is subjected to the workload classification criteria.

Creating a Workload Utility Throttle

You can create a workload utility throttle to control a specific type of utility for a specific user, for example:

From the Ruleset toolbar, click Workloads.

Edit or create a workload.

From the Classification tab, choose Request Source, click Add, and choose Source Type

Username.

Click the username, Include, and OK.

From the Classification tab, choose Utility, click Add, and specify the utility for which to limit concurrency, for example, FastExport.

Click Save.

Return to editing the workload. Click the Throttles tab.

Under default settings, select either Unlimited or Limited as a concurrency limit. If you choose Limited, enter a concurrency limit number in the box and select either Delay or

Reject.

(Optional) To override the default settings for a state, do the following:

Next to the state name, click the pen icon.

Select Create State Specific Settings.

If you do not want to limit the concurrent queries for this state, select Unlimited under

Concurrency Limit.

If you want to limit the concurrent queries for this state, enter a concurrency limit number, and select either Delay or Reject.

Teradata Data Warehouse Appliance 2800 Implementation Guide 325

Chapter 13: Managing the Database

Managing Console Utilities

(Optional) If you have defined group throttles, select a group throttle from the list to make this workload a member of a workload group throttle.

•

Only workloads with delay throttles defined can be members of a group throttle.

•

A workload with a reject throttle defined cannot be part of a group throttle.

•

A workload cannot be a member of more than one group throttle.

Click Save.

Managing Console Utilities

Console utilities such as Scandisk (Ferret) and Checktable do not log on and run the normal paths through the Parser/Dispatcher like query requests, so they bypass the classification step that assigns requests to workloads. Because of this, you must establish workload priorities for console utilities differently than for load/export utilities.

From the Workloads tab on the Ruleset toolbar, use the Console Utilities tab to enable workload priorities for console utilities.

By default, the tab shows all console utilities running in the WD - Default workload, at a medium priority.

Instead of using the defaults, you can use the drop down menus on the Console Utilities tab to specify different workload priority levels (performance groups) for the individual console utilities listed.

Managing Blocks That Result from Throttle

Delays

Queries subject to throttles that are also part of a multi-request transaction (multiple requests embedded between BT/ET), may hold resources while in a throttle delay queue. This occurs if earlier requests in the multi-request transaction obtain locks, which will not be released until the entire transaction completes (including the delayed portion).

Delay queue blocks can present a problem because when all currently executing requests for a throttle definition are held in the delay queue, they cannot complete and the block cannot be released.

Teradata IWM detects all delay queue blocks. Sometimes the blocks can resolve themselves over time, but for delay queue blocks that persist, Teradata IWM provides optional attribute settings that you can use to specify how the system manages the blocks.

About the Allowable Delay Queue Blocking Period

Two parameters found on the Workload Designer General tab, control the duration of the delay queue blocking period. From the Other tab:

326 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Monitoring Workloads

•

The Exception Interval attribute defines how often the system checks exception thresholds.

The default is 60 seconds. If this attribute is set to off, the system takes no block action, regardless of other settings.

•

The Block Cycles attribute defines how many Exception Intervals the system waits before taking the action specified in the Block Action attribute. The default setting is 1.

About System Management of the Delay Queue Blocks

The Block Action attribute found on the Workload Designer General tab, Other tab define what action the system is to take after the defined number of Block Cycles have elapsed. The valid actions are:

•

Log: The request remains in the delay queue (unless system activity has dropped below the throttle threshold) and the system logs the block event to the TDWMEventLog.

•

Abort: Aborts the queued request and then logs the event.

•

Release: Releases the request to freely execute and then logs the event.

The default action is Release.

Configuring Delay Queue Block-Handling Attributes

Click the General tab and then the Other tab.

In the Intervals area, set the Exception Interval in seconds. Teradata recommends that you use the default (60).

In the Blocker area, set the Block Cycles attribute, for example, to 2. This means the system waits two 60-second intervals for the block to resolve before it takes action. Two 60-second cycles is often enough time for system activity to drop below the throttle threshold and lift the block. If not, the system takes the specified Block Action.

Set the Block Action attribute. Teradata recommends that you try the Release setting.

Although releasing the query is contrary to the threshold rules for queries that would otherwise remain in the delay queue, it still allows for some concurrency management while causing minimal disruption to query execution. You can use another setting if needed.

Monitoring Workloads

Teradata IWM accumulates a variety of data about each workload, at the interval specified on the Workload Monitor portlet page.

Working with Monitoring Intervals

The system uses workload summary data gathered at the intervals specified on the Other tab of the Workload Designer General view to generate various displays shown on the Viewpoint

Workload Health and Workload Monitor portlets.

Teradata Data Warehouse Appliance 2800 Implementation Guide 327

Chapter 13: Managing the Database

Monitoring Workloads

Note: Teradata recommends that you use the default interval settings unless you have a reason to do otherwise.

Interval

Event Interval

Page Interval

Logging Interval

Exception Interval

Description

The interval of time in seconds between system checks for occurrences of workload-related events logged by the system in the TDWMEventLog.

Default value: 60 seconds

The interval over which the system collects workload various data for display on the Workload Monitor portlet. Data is stored in the TDWMSummaryLog, based on Logging interval.

Default value: 60 seconds (which synchronizes with the default refresh time of the Workload Monitor portlet)

Determines the interval at which the system writes logged, workload-related information to log tables and then flushes the information from memory.

Default value: 600 seconds

This interval applies to the following logs:

•

TDWMEventLog

•

TDWMEventHistoryLog

•

TDWMSummaryLog

•

DBQLLogTbl

The value for this interval should be an even multiple of other interval settings.

The interval of time between system checks for exceptions, if exceptions are configured.

Default value: 60 seconds

Related Information

Information on...

interval options and how to set them the log tables controlled by the page interval

Is available in...

Teradata Viewpoint User Guide, B035-2206

Data Dictionary, B035-1092

Using Viewpoint Workload Monitor Portlet

Allows you to monitor workload management activity in the database.

•

Multiple views of workloads and related data.

•

Allocation of system resources per workload

•

Information about the queries being processed, delayed, and rejected

•

Information about individual active queries

328 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 13: Managing the Database

Monitoring Workloads

Using Data from the TDWMSummaryLog Table

At each Logging interval (see “Working with Monitoring Intervals” on page 327

), the system writes the summarized details, by workload (WD) to the DBC.TDWMSummaryLog table.

Available data include:

•

Arrival count

•

Response time (avg/min/max)

•

CPU time (avg/min/max)

•

Query counts:

•

Active (concurrent)

•

Completed

•

Failed due to error

•

Rejected

•

Delayed

•

Queries moved into or out of the workload using Change WD function

In addition to populating the Workload Monitor portlet, you can use the data in this table to create custom analysis and reports, including use of historical data.

Overriding Workload Management Effects for Queries and Sessions

When monitoring workload activity, you may identify queries for which the assigned workload management criteria are not having the needed effect. You can manually manage individual queries from the Query Monitor portlet to improve performance and balance resource usage.

Option

Aborting a query or session

Changing the workload of a query or session

Releasing a Query

Description

You can abort a query or session that is blocking other queries or consuming too many resources

You can change the workload of a query or session to allow higher priority workloads to run or to balance workload resources.

You can release a query from the delay queue for immediate processing.

For information on use of workload management override functions, see Teradata Viewpoint

User Guide

Teradata Data Warehouse Appliance 2800 Implementation Guide 329

Chapter 13: Managing the Database

Checkpoint

Before leaving Chapter 13: “Managing the Database,”

make sure that:



Result

You have evaluated compression options and implemented those that apply to your system.

You can monitor and manage database space.

You can monitor and manage database queries.

Reference

“Compressing Data to Save Space” on page 293

“Identifying and Correcting Space

Problems” on page 296

“Managing Query Problems” on page 301

You understand how to create and use accounts.

“Managing User Activity with

Accounts” on page 305

You understand Teradata IWM capabilities and have implemented needed workload controls.

“Setting Up Workload Management” on page 309

If you do not have a result, review and redo the procedure shown in the Reference column.

330 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 14

Maintaining the Database

This section discusses database management utilities and tasks that must be performed to maintain system health and optimal function.

Teradata Database Console Utilities

Teradata Data Warehouse Appliance 2800 administration tasks require that you run Teradata

Database console utilities. The following topics describe several ways to access the utilities:

•

Running Database Utilities From Viewpoint

•

Running Database Utilities from cnsterm

•

Running Database Utilities from a Database Node

Note: Database utilities can have negative effects on the database if they are not run correctly, and should be used only by trained personnel, as specified in documented procedures or under the direction of Teradata Customer Support.

Running Database Utilities From Viewpoint

You can run some database-level utilities from the Teradata Viewpoint Remote Console portlet. For setup and usage information, see “Remote Console” in Teradata Viewpoint User

Guide, B035-2206.

•

Abort Host

•

CheckTable

•

Configure

•

DBS Control

•

Ferret

•

Gateway Global

•

Lock Display

•

Operator Console

•

Priority Scheduler

•

Query Configuration

•

Query Session

•

Recovery Manager

Teradata Data Warehouse Appliance 2800 Implementation Guide 331

Chapter 14: Maintaining the Database

Teradata Database Console Utilities

•

Show Locks

•

Teradata DWM Dump

•

Update Space

•

Vproc Manager

Reference Information

Information on...

utility functions, syntax, options,

Is available in...

•

Utilities Volume 1 (A-K)

•

Utilities Volume 2 (L-Z)

Running Database Utilities from cnsterm

You can run all database utilities from the Teradata Database Console Subsystem (CNS). Some utilities, such as DIP, can only run from this interface.

The cnsterm program is a user interface to the Console Subsystem (CNS). CNS provides six virtual interface windows:

•

Windows 1 through 4 are interactive application windows in which database utilities run.

•

Window 5 is the database I/O window, which displays messages from database programs, such as SQL diagnostics, that do not run in CNS application windows.

•

Window 6 is the Supervisor window, the primary user interface to CNS. Launch database utilities in the Supervisor window, and they run in the application windows.

You can use the Supervisor window to issue CNS commands to the database. For more information on CNS commands

Note: You can issue CNS commands to the database from the Supervisor window, and also run console utilities from Database Window (DBW), an X-window based graphical user interface. See “Database Window” in Utilities: Volume 1 (A-K), B035-1102.

CNS Permission Requirements

The root user on the control node is automatically authorized to access CNS, and can run all database-level utilities from cnsterm or DBW. However, Teradata recommends that access to root privileges be severely limited, even among administrative users.

To run console utilities without root privileges, an administrative user must be either:

•

A member of the Linux tdtrusted group, which is automatically created during the initial installation and configuration of the Teradata Data Warehouse Appliance 2800 system, and which has permission to run console utilities.

•

Explicitly granted the right to run console utilities with the CNS GRANT command.

332 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Teradata Database Console Utilities

Granting CNS Permissions

Do the following to grant users who do not have root privileges or membership in the tdtrusted group permission to access CNS and run database utilities.

Access the CNS Supervisor window by entering

cnsterm at the control node command prompt.

To grant another user account permission to access CNS via cnsterm or DBW to run all database-level utilities, enter: grant user_ID@localhost all where user_ID is the account the user uses to log on to control node.

Note: The permissions should be granted or revoked only when all TPA nodes are running.

For example:

Input Supervisor Command:

> grant vsattui@localhost all grant vsattui@localhost all

CNSSUPV: permissions for vsattui@localhost updated vsattui@localhost: all

Exit cnsterm by pressing Ctrl-C. The new permissions take effect immediately.

Reference Information

Information on...

CNS permissions and the CNS GRANT command

Is available in...

“Database Window” in Utilities: Volume 1 (A-K), B035-

1102

Logging On to the Control Node

The cnsterm program runs only from the control node, which is typically the lowest numbered running system node. This procedure describes accessing the control node from

SMClient.

From a workstation that has been set up using the procedures described in

“Configuring a

Workstation for Use with SMWeb” on page 112

, navigate to the SMWeb Home page by following the procedure described in

“Accessing the SMWeb Home Page” on page 114

Select Server Management Client.

In the SMClient Tree View, right-click the control node, and click Connect.

Note: The control node is the lowest numbered running node in the lowest numbered cabinet in the Teradata Data Warehouse Appliance 2800 system. The control node is typically shown as Node 2 in the Tree View. Do not select a server management node

(CMIC, numbered 14 in the Tree View), Teradata MS, or BAR server. For the location of

Teradata Data Warehouse Appliance 2800 Implementation Guide 333

Chapter 14: Maintaining the Database

Teradata Database Console Utilities

Node 2 in the cabinet, see

“Teradata Data Warehouse Appliance 2800 Cabinet

Configurations” on page 26

In the Connect dialog box, click Secure Shell (SSH). Click OK.

In the New Connection dialog box, click the SSH/SFTP tab, and for the Default Username enter root.

Click OK.

At the command prompt, log in as root, a member of the tdtrusted group, or a user with

CNC privileges.

Using cnsterm to Run a Database Utility

Note: Because cnsterm is a command-line program, it allows access to only one CNS window at a time.

At the Linux prompt on the control node, enter the following command to configure the

Teradata Database command-line environment:

tdatcmd

To start cnsterm to run a utility, enter:

cnsterm

The cnsterm prompt appears:

Input Supervisor Command:

This cnsterm prompt is actually the Supervisor window of CNS from which you can launch database utilities.

At the prompt, start a utility. Preface the utility name with the CNS

start command.

For example:

>start vprocmanager

The system displays a message similar to the following, indicating the available application window in which the utility has been started:

Started 'vprocmanager' in window 1

at Thu Jul 23 11:53:10 2009

Up to four utilities can be run simultaneously. CNS starts each utility in a different application window. If all application windows are occupied by running utilities, CNS will not start another utility until one of the running utilities stops or is aborted.

From the control node command line, only one virtual window can be viewed at a time.

To display the Application Window in which the utility is running, and see the output from the utility or to interact with the utility:

•

Use Ctl-C to exit the Supervisor Window.

•

At the Linux command prompt start cnsterm again, this time specifying the application window in which the utility of interest is running. For example, enter the following to display application window 1, in which the vprocmanager utility, started

in step 4

, is running: cnsterm 1

Use Ctrl-C to exit any window and

cnsterm

n to open another.

334 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Teradata Database Console Utilities

Some utilities display information and stop automatically. Other utilities are interactive, and have a number of commands that can be issued from the utility command prompt.

Interactive utilities must be explicitly stopped using the command that is appropriate to the utility. This is most often either

quit or

quit;

(quit followed by a semicolon).

When a utility has stopped running, either by itself because it is non-interactive or as a result of an explicit quit command, use Ctrl-C to close the associated CNS application window and return to the Linux command prompt.

Note: The Supervisor (main cnsterm) window can only be closed using Ctrl-C.

Using cnscim to Check the Status of CNS Tasks

When CNS indicates that all four application windows are occupied by running utilities, it is helpful to see what is running in each window. Use the cnscim program:

Open a Teradata Command Prompt. See “Logging On to the Control Node” on page 333

At the Linux command prompt of the control node, enter:

cnscim -screens cnscim returns output showing the status of each CNS window, for example:

Screen 1 -- vprocmanager active=True, enabled fkeys=, help level=0, nostop=False, reading=True, hide=True

Screen 5 -- DBS I/O active=True, enabled fkeys=, help level=0, nostop=False, reading=False, hide=False

Screen 6 -- SUPERVISOR active=True, enabled fkeys=, help level=0, nostop=False, reading=True, hide=False

Running Database Utilities from a Database Node

You can run PDE-level utility programs, for example, psh and pdestate from the command line of any database node.

At the Linux command prompt, enter tdatcmd

to set up the Teradata Database command line environment.

On the command line, enter the following to start the utility:

utility_name [options] where

utility_name

is the name of the utility, and

options

can include any of the available command-line options and arguments for the utility.

Teradata Data Warehouse Appliance 2800 Implementation Guide 335

Chapter 14: Maintaining the Database

Database Maintenance Tasks

All Teradata Data Warehouse Appliance 2800 customers receive a Teradata Core Support card from the Teradata representative with delivery of the system. Be sure to follow the recommended maintenance procedures listed on the card.

Note: Some of the core support maintenance recommendations are covered in detail this publication.

The maintenance topics that follow are of two types:

•

Periodic maintenance tasks that should be done at regular intervals

•

“Managing Accumulated Log Data” on page 336

•

“Verifying Data Block Integrity” on page 340

•

Additional maintenance tasks that only need to be performed occasionally

•

“Restarting the Teradata Database Software” on page 342

•

“Upgrading Teradata Software” on page 350

•

“Powering the System Off and On” on page 350

•

“Servicing Unplanned Power Outages” on page 364

Managing Accumulated Log Data

About Database Logs

Teradata Database contains a number of log tables that accumulate data, either automatically or after certain features are enabled. Because log data grows over time, you must periodically purge older information to avoid using up permanent space.

Logs

Access Log

(DBC.AccLogTbl)

Description

Logs that can be purged manually or using Teradata Viewpoint. See

“Deleting Old Log Data with

Teradata Viewpoint” on page 338 .

Data collected as defined in a BEGIN LOGGING statement, for each privilege check of an attempted user access of a database object.

Data collected during database query logging (DBQL), if DBQL is enabled.

DBQ Logs:

•

DBC.DBQLSummaryTbl

•

DBC.DBQLStepTbl

•

DBC.DBQLogTbl

•

DBC.DBQLObjTbl

•

DBC.DBQLExplainTbl

•

DBC.DBQLSqlTbl

•

DBC.DBQLXMLLockTbl

336 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Managing Accumulated Log Data

Logs

Event Log

(DBC.EventLog)

ResUsage Logs:

•

DBC.ResUsageSpma

•

DBC.ResUsageSvpr

•

DBC.ResUsageShst

•

DBC.ResUsageIpma

•

DBC.ResUsageIvpr

•

DBC.ResUsageScpu

•

DBC.ResUsageSldv

•

DBC.ResUsageSawt

•

DBC.ResUsageSps

•

DBC.ResUsageSpdsk

•

DBC.ResUsageSvdsk

Description

Data collected automatically by the system for each user logon event.

ResUsage tables collect data on system resource usage.

You can enable ResUsage data collection and set the collection rate using either:

•

The ctl utility SCREEN RSS command

•

Teradata Viewpoint data collectors

The collection rate determines how quickly data accumulates and when the logs should be purged.

SWEvent Log

(DBC.SW_Event_Log)

TDWM Logs:

•

DBC.TDWMSummaryLog

•

DBC.TDWMEventLog

•

DBC.TDWMExceptionLog

The system automatically inserts rows in response to software errors and system events, for use by Teradata Customer Service.

Logs for Teradata Viewpoint workload management functions.

Logs that must be purged manually purged

In Doubt transaction Log

(DBC.InDoubtResLog)

Contains a row for each transaction where completion was in doubt.

Note: Depending on site requirements, you may need to retain older data long after it should be removed from an active log. If so, you can create backup log tables to store log history and periodically copy data from the active logs to the backup tables. You can also archive copies of the backup tables on tape for long-term reference.

Reference Information

Information on...

configuring access logging configuration and use of DBQL

Is available in...

Chapter 11: “Monitoring Database Access”

Chapter 15: “Tracking Query Behavior with Database

Query Logging,” in Database Administration, B035-

1093.

Teradata Data Warehouse Appliance 2800 Implementation Guide 337

Chapter 14: Maintaining the Database

Managing Accumulated Log Data

Information on...

using the ctl utility SCREEN RSS command to set up ResUsage logging and log intervals setting up Teradata Viewpoint data collectors

Is available in...

the SCREENRSS command in Chapter 8: “Control

GDO Editor (ctl), in Utilities Volume 1, B035-1102.

“Configuring Data Collectors” in Teradata Viewpoint

Configuration and Upgrade Guide, B035-2207.

Deleting Old Log Data with Teradata Viewpoint

From the Teradata Viewpoint portal page, click in the top right corner of the page.

Choose the Monitored Systems portlet.

From the Systems list, click the name of the system you want to update.

From the Setup list, click Log Table Cleanup.

From the Tables list, click a table.

[Optional] Under Details, do one of the following:

•

Select the Enable table cleanup check box to activate cleanup and include the table in the cleanup schedule.

•

Clear the Enable table cleanup check box to disable cleanup and exclude the table from the cleanup schedule.

For Login, select the user you want to run the cleanup task.

For Cleanup After, set the retention period using a number and calendar value.

After the log table cleanup has been configured for Teradata Database, you can set a schedule:

From the Systems list, click the name of the system you want to update.

f b d

From the Setup list, click Cleanup Schedule.

[Optional] Under Cleanup Schedule Details, do one of the following:

•

Select the Enable cleanup scheduler check box to activate the cleanup schedule.

•

Clear the Enable cleanup scheduler check box to disable the cleanup schedule.

For Login, select the user you want to collect the current time and Teradata Database version.

For Cleanup Time, enter a time at which the cleanup task is run on the Viewpoint server by the DCS.

Current Teradata Time indicates the current setting or unknown indicates a connection to Teradata Database cannot be made.

Click Apply.

338 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Managing Accumulated Log Data

Deleting Old Log Data Manually from System Tables

Before deleting old log data, determine whether you need to retain records of the data set for deletion. For example, while Teradata recommends that you purge log data at least every 90 to

180 days, security policy for some sites may require retention of access log data for a much longer time period.

Note: You cannot delete data that is less than 30 days old.

Use the following procedure when deleting old log data from system tables:

If your site requires long term retention of log data, do the following:

Create a duplicate log table in another database using the Copy Table syntax for the

CREATE TABLE statement.

CT DBC.tablename AS databasename.tablename

For further information on using the Copy Table syntax, see “Create Table” in

SQL

Data Definition Language Syntax and Examples, B035-1144.

Back up the table to tape storage in accordance with your site back up policy.

Recommendation: Match the log backup/deletion schedule to the amount of log data you want to maintain locally in system tables. For example, to maintain 90 days of log data in a system table do the first back up at 120 days, then delete the last 30 days of data in the log. Back up the log data every 30 days after that.

Drop the duplicate table using a DROP TABLE statement.

Log on to SQL Administrator as DBADMIN or another administrative user with DELETE privileges on database DBC.

In the Query window, enter a SQL statement to purge old log entries. For example:

DELETE FROM DBC.object_name WHERE (Date - LogDate) > number_of_days ; where:

Syntax Element

object_name

Description

The name of the DBC object that allows log deletions, as shown in “About

Database Logs” on page 336

. For example, DeleteAccessLogV is the delete object for the Access Log.

Date

LogDate

SQL syntax element for the current date.

The date contained in the LogDate column of the log view based on the specified number_of_days from the current date.

number_of_days

The number of days of data that you want to retain in the system table; the span of days from the current date to the oldest LOGDATE to be retained.

Teradata Data Warehouse Appliance 2800 Implementation Guide 339

Chapter 14: Maintaining the Database

Verifying Data Block Integrity

Routine system maintenance should include running SCANDISK and CheckTable monthly or more frequently to check for data corruption in the file system and database:

•

SCANDISK checks the integrity of the Teradata Database file system. The file system keeps track of all data stored in Teradata Database. SCANDISK inspects the low-level file system data structures to ensure that the internal links between such structures are correct, consistent, and reflect the proper ordering of the tables and rows in Teradata Database.

SCANDISK reports any problems it finds.

•

CheckTable checks the integrity of the tables stored in Teradata Database. It inspects the table data structures, such as table headers, rows, and indexes to ensure that they are properly formed, exist on valid AMP vprocs, and are consistent across the different subtables that constitute a table (primary data, fallback data, and secondary indexes).

For periodic maintenance, Teradata recommends running SCANDISK immediately prior to running CheckTable.

Running SCANDISK

SCANDISK is a command issued from within the Ferret utility.

Note: To use this procedure, you must have root access or the cns permission shown in

“CNS

Permission Requirements” on page 332 .

Log on to the control node as shown in “Logging On to the Control Node” on page 333 .

Coordinate with the database administrator to determine an appropriate priority setting for running SCANDISK. Running at a lower priority reduces the database performance impact of the utility while users are on the system, but can increase the time required for the scan.

Set the priority level under which SCANDISK will execute. For example, on the Database

Console command line, enter: set priority=low

Disable script mode to enable the inquire and abort commands. On the Database Console command line, enter:

disable script mode

Start SCANDISK with the following command on the Database Console command line: scandisk

Enter

y to indicate that SCANDISK should be started on all AMP vprocs. SCANDISK begins verifying the integrity of file system data structures.

Note: SCANDISK can take a long time to check systems with large amounts of storage.

•

You can check the progress of SCANDISK at any time by entering

inquire on the

Database Console command line.

•

You can stop SCANDISK at any time by entering

abort on the Database Console command line.

340 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Verifying Data Block Integrity

When SCANDISK has finished checking, it displays a message similar to the following:

72 of 72 vprocs responded with no messages or errors

Enter

quit on the Database Console command line to exit Ferret.

If SCANDISK reports any errors, open a support incident with Teradata Customer Support at https://tays.teradata.com

, and attach a copy of the file containing the program output. For more information on opening incidents, see

“Opening Incidents Through

Teradata At Your Service” on page 133 .

Running CheckTable at Level 2 for Database DBC

After running SCANDISK without errors, run CheckTable. CheckTable offers different levels of checking. Higher-level checking is more thorough, but requires more time to run and uses more system resources. Consequently, Teradata recommends that you initially run CheckTable at a low level, and only run at a higher level of checking if problems are found at the lower level of checking.

Note: To run this procedure, you must have root access or the cns permission shown in

“CNS

Permission Requirements” on page 332 .

Log on to the control node as shown in “Logging On to the Control Node” on page 333

On the Database Console command line, type:

check dbc at level two concurrent mode;

Note: Be sure to include the semicolon at the end of the line.

If you are running CheckTable during a maintenance window, when there are no users on the system, you can omit the concurrent mode option to speed up the check.

When CheckTable has finished checking, it presents a summary of the results, similar to:

156 table(s) checked.

156 fallback table(s) checked.

0 non-fallback table(s) checked.

15 table(s) bypassed due to being unhashed.

0 table(s) failed the check.

0 Dictionary error(s) were found.

If any tables fail the check, run CheckTable again at level three on those tables. This could take some time, depending on the size and complexity of the tables.

Running CheckTable at Level 1 for Non-DBC Tables

On the Database Console command line, type: check all tables exclude dbc at level one concurrent mode;

Note: Be sure to include the semicolon at the end of the line.

If you are running CheckTable during a maintenance window, when there are no users on the system, you can omit the concurrent mode option to speed up the check.

Teradata Data Warehouse Appliance 2800 Implementation Guide 341

Chapter 14: Maintaining the Database

Restarting the Teradata Database Software

When CheckTable has finished checking, it presents a summary of the results, similar to:

242 table(s) checked.

241 fallback table(s) checked.

1 non-fallback table(s) checked.

0 table(s) failed the check.

0 Dictionary error(s) were found.

If any tables fail the check, run CheckTable again at level three on those tables. This could take some time, depending on the size and complexity of the tables.

Enter

quit; on the Database Console command line to exit the CheckTable utility.

Remember to end the command with a semicolon.

If CheckTable finds any errors open a support incident with Teradata Customer Support at https://tays.teradata.com.

Attach a copy of the text file containing the program output. For more information on opening incidents, see

“Opening Incidents Through

Teradata At Your Service” on page 133 .

Reference Information

Information on...

the CheckTable utility the SCANDISK command

Is available in...

“Checktable” in Utilities: Volume 1 (A-K), B035-1102

Restarting the Teradata Database Software

Occasional database restarts are a part of the ongoing maintenance and management of

Teradata Database. Restarts can be initiated manually by an administrator or automatically by the Teradata Database system itself.

Restart Type

Manual

Automatic

Possible Reasons

•

Install patch upgrade to Teradata Database software

•

Finalize changes made to user tunable system configuration settings

•

Change to physical system configuration

•

Bring offline AMPs back online

•

Error in database, application, or BYNET software

•

Failure in physical storage systems

•

Loss of power that causes nodes to reboot

•

Component failure in critical system hardware

You can enable restart protection to make restarts transparent to applications and users. After a Teradata Database restart, incomplete SQL requests are automatically resubmitted for

342 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Restarting the Teradata Database Software

sessions that have redrive enabled. For more information, see “Redrive Protection for

Queries” on page 345 .

Without redrive enabled, the restart process:

•

Informs logged on users of the restart, and terminates all database sessions.

•

Frees associated session resources, such as spool space.

•

Initiates database stop and startup processing.

•

Logs restart information.

•

Performs transaction recovery processing. Partially completed transactions are rolled back.

Initiating a Manual Restart

The database is unavailable during the restart process, so you should schedule manual restarts during times when database use is at a minimum, for example during periodic maintenance.

Notify users of manual restarts and advise them to log off the system.

For more information on scheduling periodic maintenance windows, see “Opening a

Maintenance Window” on page 131

PDE executes restarts in stages. You can use the pdestate utility to monitor the status of the system both before and during a restart.

Log on to the control node of the system, as described in “Logging On to the Control

Node” on page 333 .

At the command line, enter: psh pdestate -a

Ideally, pdestate will indicate that no users are logged on to the system, and the system is quiescent (idle), with a message similar to this: all 4 nodes:

PDE state is RUN/STARTED.

DBS state is 5: Logons are enabled - The system is quiescent

Note: For more information about the psh and pdestate commands, see the man pages for these utilities.

To initiate the restart process, at the command line enter:

tpareset -f reason where reason is a required string that describes the reason for the restart, and is logged with the restart event. The string cannot begin with a hyphen, and need not be enclosed in apostrophes.

Enter

y at the prompt to confirm you want to restart the database.

For more information on the tpareset command, see “TPAReset (tpareset)” in Utilities:

Volume 2 (L-Z), B035-1102.

Teradata Data Warehouse Appliance 2800 Implementation Guide 343

Chapter 14: Maintaining the Database

Restarting the Teradata Database Software

To monitor the restart process as it goes through the various stages, run pdestate

periodically, as described in step 2 .

If the database fails to return to a fully functional state, run the Vproc Manager utility as

described in “Troubleshooting Database Restarts” on page 344 .

Reference Information

Information on...

the tpareset command

Is available in...

“TPAReset (tpareset)” in Utilities: Volume 2 (L-Z),

B035-1102

About Automatic Restarts

Teradata Database automatically restarts if certain problems are detected. Frequently, the restart resolves the problem, however, some problems persist across restarts, and can cause repeated restarts.

You can track automatic restarts by monitoring the AWS Fault Viewer. To ensure the database returns to a fully operational state, run the Vproc Manager utility as shown in

“Troubleshooting Database Restarts” on page 344

. If system vprocs or nodes remain down or offline, submit an incident to Customer Support using the Teradata @ Your Service web site,

as described in “Opening an Incident” on page 133 .

Note: The system saves a crashdump if it automatically restarts. The crashdump information can be used by Teradata Support personnel to investigate software errors that cause restarts.

Make sure to allocate space for crashdumps, as described in “Assigning Perm Space to

Crashdumps” on page 156

Troubleshooting Database Restarts

After any database restart, do the following to verify that Teradata Database is fully functional:

From a Console Subsystem command line, as described in

From Viewpoint” on page 331 , start the Vproc Manager utility (vprocmanager) by

entering:

“Running Database Utilities

start vprocmanager

On the Vproc Manager command line enter: status notonline

If the system is up and running properly, Vproc Manager displays:

SYSTEM NAME: system_name

current_date_time

All DBS vprocs are fully online.

All PDE nodes are fully online.

344 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Redrive Protection for Queries

If any vprocs are not in an ONLINE state, Vproc Manager lists those vprocs. For example:

SYSTEM NAME: Teradata_app_1 09/09/14 14:38:04

DBS LOGICAL CONFIGURATION

-------------------------

Rcv

Jrnl/

Vproc Rel. Node Can Crash Vproc Config Config Cluster/ Host VSS

Number Vproc# ID Move Count State Status Type Host No. Type Vproc

------ ------ ------ ----- ----- ------- -------- ------ -------- ----- -----

5 6 2-14 Yes 0 OFFLINE Online AMP 2 On 10237

--------------------------------------------------------------------------------

DBS State: Logons are enabled - The system is quiescent

DBS RestartKind: COLD

All PDE nodes are fully online.

Exit Vproc Manager by entering

quit on the Vproc Manager command line.

If you do not understand the reason for an automatic restart, or if the output from Vproc

Manager indicates an ongoing problem, submit an incident using the Teradata @ Your

Service web site, as described in

“Opening an Incident” on page 133

Note: Before opening the incident, you can inspect the relevant portions of the system event log, /var/log/messages, and attach a copy of those entries to the incident.

Redrive Protection for Queries

Redrive protection makes database restarts transparent to applications and users. After a

Teradata Database restart, incomplete SQL requests are automatically resubmitted for sessions that have Redrive enabled.

Enabling Redrive Protection

To enable Redrive protection...

Do...

at the system level for all sessions by default

Set the RedriveProtection DBS Control field to 1.

Ensure that the RedriveProtection DBS Control field is set to 1.

Set the RedriveDefaultParticipation DBS Control field to 1.

at the session level at the user, account, or profile level

Set the Redrive field in the Session Options parcel to 'Y'.

Insert or modify a row in the TDWM.Redrive table and set the value of the RedriveMethod column to 2 for the user, account, or

profile. For details, see “Setting Redrive Protection for Users,

Accounts, and Profiles” on page 346

Teradata Data Warehouse Appliance 2800 Implementation Guide 345

Chapter 14: Maintaining the Database

Redrive Protection for Queries

Note: If any of the following are true, the session will not participate in Redrive:

•

The RedriveProtection DBS Control field is set to 0

•

The Redrive field in the Session Options parcel is set to 'N'

•

There is a row in the TDWM.Redrive table indicating that Redrive is disabled for this session

In addition, Recoverable Network Protocol must be enabled in order for you to use Redrive.

For details about Recoverable Network Protocol, see the DisableRecoverableNetProtocol DBS

Control field in Utilities.

The Redrive capability is assigned to a session at logon time. Once a session is enabled with

Redrive, you can subsequently use the Redrive query band to toggle Redrive protection off and on during the life of the session using this syntax:

SET QUERY_BAND = 'redrive=on;' FOR SESSION;

SET QUERY_BAND = 'redrive=off;' FOR SESSION;

For details on using the Redrive query band, see SQL Data Definition Language Detailed

Topics.

Disabling Redrive Protection

To disable Redrive protection...

Do...

at the system level for all sessions by default

Disable logons from the Supervisor window of Database

Window (DBW) or similar console subsystem interface, such as cnsterm.

Ensure that no sessions are logged on.

Set the RedriveProtection DBS Control field to 0.

Ensure that the RedriveProtection DBS Control field is set to 1.

Set the RedriveDefaultParticipation DBS Control field to 0.

at the session level at the user, account, or profile level

Set the Redrive field in the Session Options parcel to 'N'.

Insert or modify a row in the TDWM.Redrive table and set the value of the RedriveMethod column to 1 for the user, account, or

profile. For details, see “Setting Redrive Protection for Users,

Accounts, and Profiles” on page 346

Setting Redrive Protection for Users, Accounts, and Profiles

You can enable or disable Redrive protection for individual users, accounts, and profiles using the TDWM.Redrive table:

Ensure that TASM is running.

Insert, modify, or delete rows in TDWM.Redrive to specify whether particular users, accounts, or profiles will participate in Redrive.

346 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Redrive Protection for Queries

From the Teradata Viewpoint Workload Designer portlet, issue the TDWM Activate command after changing the TDWM.Redrive table in order for the new changes to take effect.

The table definition for TDWM.Redrive is:

CREATE SET TABLE TDWM.Redrive ,FALLBACK ,

NO BEFORE JOURNAL,

NO AFTER JOURNAL,

CHECKSUM = DEFAULT,

DEFAULT MERGEBLOCKRATIO

(

ObjectType VARCHAR(10) CHARACTER SET UNICODE

NOT CASESPECIFIC NOT NULL,

ObjectName VARCHAR(128) CHARACTER SET UNICODE

NOT CASESPECIFIC NOT NULL,

RedriveMethod INTEGER NOT NULL)

UNIQUE PRIMARY INDEX ( ObjectType ,ObjectName );

Insert a row into the table or modify an existing row in the table to specify whether Redrive protection is enabled for a particular user, account, or profile:

Column Name

ObjectType

ObjectName

RedriveMethod

Valid Values

In order of precedence, where

USER is most specific and

PROFIL is least specific:

•

USER

•

ACCT (account)

•

ACCTSTR (account string)

•

PROFIL (profile)

The name of the object

•

1 (Disable Redrive)

2 (Enable Redrive)

Description

Specifies whether you are setting Redrive protection for a user, an account, or a profile.

The name of the user (or application), account, or profile for which you are setting Redrive protection.

For example, if ObjectType is USER, then ObjectName is the user name.

Determines whether Redrive is enabled or disabled for the user, account, or profile specified by ObjectName.

When there is a conflict, the most specific ObjectType is used. For example, suppose these rows are in TDWM.Redrive:

ObjectType

USER

PROFIL

ObjectName

Mark

Manager

RedriveMethod

If a session logs on as USER Mark and PROFIL Manager, since both rows in the table qualify, the most specific ObjectType is chosen. USER is more specific than PROFIL; therefore,

Teradata Data Warehouse Appliance 2800 Implementation Guide 347

Chapter 14: Maintaining the Database

Redrive Protection for Queries

RedriveMethod 1 (Do not use Redrive) is chosen and the session will not participate in

Redrive.

If there is no row in TDWM.Redrive for the session, the RedriveDefaultParticipation DBS

Control field determines whether the session participates in Redrive.

Redrive attributes are assigned to users, accounts, and profiles at logon time, and these attributes remain for the entire session. The attributes are not changed for that session even if new entries are made to TDWM.Redrive that would apply to the session. However, once

Redrive is enabled, you can use the Redrive query band to turn Redrive off and on during the life of the session.

Restrictions

•

Redrive only hides database restarts from requests running in the SQL partition.

•

If a UDF or external stored procedure modifies data that is external to Teradata Database, then the request involving that function or procedure cannot be redriven.

•

If a database restart occurs while SELECT AND CONSUME requests are waiting for rows to consume, the restart is hidden from the application, but the queued up requests will not be in the same order as they were at the time of the restart.

•

If a PE node fails, then the restart cannot be hidden from applications that were logged onto the failing node.

•

Database restarts cannot be hidden if the restart occurs:

•

During execution of stored procedures.

•

After the first request of an explicit Teradata transaction or an ANSI/ISO transaction and the transaction placed a write lock or exclusive lock on a table in database DBC.

•

After the request is committed on the AMPs but before the PE is notified of the commit.

Example 1

When the session logs on and you have these settings...

Then the session...

RedriveProtection DBS Control field is 0 will not participate in Redrive.

•

RedriveProtection DBS Control field is 1

•

Redrive field in Session Options parcel is 'Y'

•

TDWM.Redrive contains a row matching your user name, account, account string, or profile with

RedriveMethod = 1 (Do not use Redrive) will not participate in Redrive because the row in TDWM.Redrive specifies not to use Redrive.

348 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Redrive Protection for Queries

When the session logs on and you have these settings...

Then the session...

•

RedriveProtection DBS Control field is 1

•

Redrive field in Session Options parcel is 'N'

•

TDWM.Redrive contains a row matching your user name, account, account string, or profile with

RedriveMethod = 2 (Use Redrive) will not participate in Redrive because the

Redrive field in the Session Options parcel is 'N'.

•

RedriveProtection DBS Control field is 1

•

Redrive field in Session Options parcel is 'Y'

•

TDWM.Redrive does not contain any matching row or it contains a row matching your user name, account, account string, or profile with

RedriveMethod = 2 (Use Redrive) will participate in Redrive.

Example 2

If you want to use Redrive, but do not want to change any application settings:

•

If you only want a single account to use Redrive:

Set the RedriveProtection DBS Control field to 1.

Set the RedriveDefaultParticipation DBS Control field to 0.

Add a row in TDWM.Redrive for the account and enter a value of 2 in the

RedriveMethod column for the account.

•

If you want all sessions to use Redrive except those from a particular account string:

Set the RedriveProtection DBS Control field to 1.

Set the RedriveDefaultParticipation DBS Control field to 1.

Add a row in TDWM.Redrive for the account string and enter a value of 1 in the

RedriveMethod column for the account string.

Powering the System Off and On

You may need to stop the database and shut down the system hardware due to a scheduled power outage or when directed by Teradata Customer Support. The following procedures describe the best practices for:

•

Stopping the database and removing power from all chassis in a system or cabinet

Note: During a power off, the chassis are powered off, but the cabinet AC boxes are still receiving power from the grid.

•

Restoring power to all chassis in a system or cabinet and starting the database.

Powering Off All Chassis in a System or Cabinet

The following procedure should be used to shut down the Teradata Database and remove power from all component chassis within a system or cabinet. The procedure does not remove power from the cabinets.

350 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

Notify all users that the system is going to be powered off and that they should save all work in progress and log off the system. Users include Teradata Database users and those using Teradata Managed Server (TMS) and BAR applications.

Ensure the Teradata Database is not set to automatically start after nodes are rebooted.

Using a browser, open the PUT application. For more information, see the Parallel

Upgrade Tool (PUT) Reference, B035-5716.

In the PUT screen, type the User Name and Password for the node, then press

Enter

In the Other operations drop-down list, select Set Teradata Startup Option.

From the Network Subnet Selection page, select the BYNET network, xx.xx.xx.xx

(byn0), then click Next.

When the Select Nodes page appears, move all the nodes from the Available list to the

Selected list, then click Next.

When the Select Teradata Startup Option page appears, select DO NOT automatically

start Teradata after a system reboot, then click Next.

From the Select Reboot Option page, select No, don’t reboot the nodes now, then click

Next.

Click Finish.

Access the database control node. See “Logging On to the Control Node” on page 333

Check the status of the Teradata Database to make sure user activity is stopped by typing the following, then press

Enter:

pdestate -a

If the following message displays, the database is quiescent, has no users logged on, and you can continue with the next step:

PDE state is RUN/STARTED.

DBS state is 5: Logons are enabled - The system is quiescent.

If the following message displays, users are logged on. You must ask them to log off, and repeat this step (rerun

pdestate -a

PDE state is RUN/STARTED.

DBS state is 4: Logons are enabled - Users are logged on.

Shut down the Teradata Database, as follows:

In the node console window, type the following, then press

Enter

tpareset -x down for maintenance

Type

to confirm that you want to shut down Teradata Database, then press

Enter

Teradata Data Warehouse Appliance 2800 Implementation Guide 351

Chapter 14: Maintaining the Database

Powering the System Off and On

6 c

To verify that the Teradata Database has stopped, type the following, then press

Enter

psh pdestate -a

The system returns a message similar to the following:

# psh pdestate -a all number of nodes nodes:

PDE state: DOWN/HARDSTOP

Note: If the system does not return this message on the first attempt, repeat the command until the message is returned.

From Server Management Client (SMClient), verify that the operational states of the chassis in the cabinet or system have an OK status.

9 a

In the SMClient Tree View, select System, then expand the Collective and Cabinet branches.

In the SMClient Tree View, if the Hide normal chassis status box is checked, clear it.

For each cabinet displayed in the SMClient Tree View, verify that the chassis icons are

green.

From SMClient, perform a controlled shutdown and power off of the nodes, TMS servers, and BAR servers.

•

To shut down and power off the nodes and servers in one cabinet, select that cabinet in the Tree View, then select the Functions > Power Off command. When prompted to confirm, click Yes.

•

To shut down and power off all the nodes and servers in the system, select System in the Tree View, then select the Functions > Power Off command. When prompted to confirm, click Yes.

If your selection includes nodes, VMS Chassis, or a VM node, the operating system performs an orderly shutdown and the components are powered off.

From SMClient, verify that the nodes and servers are powered off.

In the SMClient Tree View, if the Hide normal chassis status box is checked, clear it.

For each cabinet, verify that the icons for the nodes and servers are black. A black icon indicates that the node or server is powered off.

Do one of the following:

•

To perform an orderly shutdown of an SWS VM and Viewpoint VM in a system or cabinet that has VMSs:

Using SMClient, select the SWS VM and Viewpoint VM in the SMClient Tree View.

Select Functions > Power Off. When prompted to confirm, click Yes.

•

In a system or cabinet that has a physical SWS, perform an orderly shutdown of the

SWS by typing the following at an SWS command prompt:

shutdown -P now

At the front of each cabinet that has chassis powered off, verify that:

The LEDs on all processing nodes and servers, if present, are powered off.

352 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

The VMS power LEDs and status LEDs (upper right of each VMS chassis) are on.

Figure 72: Power button with LED and Status LED on VMS Control Panel (Intel R1208 Chassis)

Status LED Power Button with LED

Node_0288

At the front of each cabinet that has chassis powered off, perform a graceful shutdown of each VMS.

Briefly (less than four seconds) press the power button on each VMS control panel.

13 b

Verify that each VMS is off.

A VMS is off when the power LED and all other LEDs except the status LED on its control panel are off.

If BYNET V5 InfiniBand switches are in the cabinet, unplug both power cords from the switch chassis.

At the rear of each cabinet that has chassis powered off, use both power switches to power off each disk array.

Power off the drive enclosure containing the controller modules (RAID I/O modules).

Power off the drive enclosure containing the expansion modules (JBOD I/O modules).

Teradata Data Warehouse Appliance 2800 Implementation Guide 353

Chapter 14: Maintaining the Database

Powering the System Off and On

Figure 73: Power Switches on Disk Array Controller (top) and Expansion Module (bottom)

Rear, Array Controller

Power Switch

Rear, Expansion Module

Power Switch

6Gb/s

SERVICE

LINK

IN OUT

6Gb/s

LINK

IN OUT

LINK

At the rear of each cabinet, power off the circuit breakers on the AC feeder boxes.

Array_0285

354 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

Figure 74: Circuit Breaker Switches on 30A Phase-to-Phase, 32A Single-Phase, and 30A Three-Phase Delta

AC Feeder Boxes

Power_0089

Teradata Data Warehouse Appliance 2800 Implementation Guide 355

Chapter 14: Maintaining the Database

Powering the System Off and On

Figure 75: Circuit Breaker Switches on 60A Three-Phase Delta and 30A/43A Three-Phase WYE 230V L-N

AC Feeder Boxes

356

Power_0090

Note: Switching the circuit breakers off removes power from all remaining chassis, including Ethernet switches and KVM.

For each BYNET V5 cabinet (if present):

Remove the filler panel covering the AC boxes.

Switch off all of the circuit breakers on each orange and blue AC box.

Note: The circuit breakers are off when the switches are in the down position. On some

AC boxes, the switches may be labeled with the word off, which is visible only when the switches are in the down position.

Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

Top 4

Btm. 4

Figure 76: Circuit Breaker Switches on Blue and Orange AC Boxes

Top 4

Btm. 4

Power_0101

For each Platform Framework Cabinet (if present):

Remove the filler panel covering the AC boxes.

Switch off all of the circuit breakers on each orange and blue AC box.

Note: The circuit breakers are off when the switches are in the down position. On some

AC boxes, the switches may be labeled with the word off, which is visible only when the switches are in the down position.

At the front of each cabinet that has been powered off, verify that all LEDs are off for the following (depending on your system configuration):

•

Processing nodes

•

Servers

•

Switches

•

Drive enclosures with controllers

•

Drive enclosures with ESMs

•

Drive enclosures with I/O modules

•

VMSs

•

Enterprise SWS

At this point, if you selected System in the Tree View, all chassis in all system cabinets are powered off. If you selected one or more cabinets, all chassis in the selected cabinets are powered off.

Powering On All Chassis in a System or Cabinet

The following procedure assumes that the system has been powered off with the Functions >

Power Off command and that the Teradata database has been stopped or nodes have been brought out of the configuration.

Note: When you are ready to restart the database, you may contact Teradata Customer

Support for assistance.

At the front of each Platform Framework Cabinet that has been powered off:

Switch on all the circuit breakers on each orange and blue AC box.

Replace the filler panel for the AC boxes.

Teradata Data Warehouse Appliance 2800 Implementation Guide 357

Chapter 14: Maintaining the Database

Powering the System Off and On

Top 4

Btm. 4

At the front of each BYNET V5 cabinet that has been powered off:

Switch on all the circuit breakers on each orange and blue AC box.

Replace the filler panel for the AC boxes.

Figure 77: Circuit Breaker Switches on Blue and Orange AC Boxes

Top 4

Btm. 4

Power_0101

At the rear of each cabinet that has been powered off, switch on all the circuit breakers on each AC feeder box.

Figure 78: Circuit Breaker Switches on 30A Phase-to-Phase, 32A Single-Phase, and 30A Three-Phase Delta

AC Feeder Boxes

358

Power_0089

Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

Figure 79: Circuit Breaker Switches on 60A Three-Phase Delta and 30A/32A Three-Phase WYE 230V L-N

AC Feeder Boxes

Power_0090

When the circuit breakers are switched on, the following power on automatically

(depending on your system configuration):

•

VMSs and their hosted VMs (CMIC, Viewpoint, and SWS)

•

Physical SWS

•

KVM

•

Switches

Note: It takes 5-10 minutes for the VMSs to completely power on. Status for the VMSs and other chassis will not be available until the VMSs have completely powered on.

Teradata Data Warehouse Appliance 2800 Implementation Guide 359

Chapter 14: Maintaining the Database

Powering the System Off and On

If the SWS is not already powered on, manually power up the SWS chassis.

At the rear of each cabinet that has been powered off, use both power switches to power on each drive enclosure.

Power on the drive enclosure containing the expansion modules (JBOD I/O modules) first, and allow two minutes for them to boot up.

Power on the drive enclosure containing the array controller modules (RAID I/O modules).

Figure 80: Power Switches on Expansion Module (top) and Disk Array Controller (bottom)

Rear, Expansion Module

Power Switch

6Gb/s

SERVICE

LINK

6Gb/s

IN OUT

6Gb/s

LINK

OUT

LINK

Power Switch

Rear, Array Controller

Power Switch

360

Array_0305

Allow enough time for the CMICs to establish communication with the chassis, then from

SMClient verify that the VMSs and the drive enclosures are operating normally before continuing.

In the SMClient Tree View, select System, then expand the Collective and Cabinet branches.

In the SMClient Tree View, if the Hide normal chassis status box is checked, clear it.

For each cabinet displayed in the SMClient Tree View, verify that the icon for each

VMS is green.

This indicates the server management nodes have booted up and have an OK status in the SMClient Tree View.

In the SMClient Tree View, verify that the chassis icon for each drive enclosure is green.

This indicates the drive enclosures have finished performing their power-on self-tests, and that they have an OK status in the SMClient Tree View.

Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

Caution:

If the icons for the VMS are not green, submit an incident to Teradata Customer Support

using the Teradata @ Your Service web site (see “Additional Information” on page 4 ).

Use SYMplicity to place the disk arrays online.

From the SWS, open SYMplicity.

In the Enterprise Management window, select the Devices tab.

Double click the array where the offline controller is located (indicated by a red circle with a down pointing arrow).

In the Array Management window, select the Physical tab.

f e

Click the offline controller (indicated by a red circle with an "x").

Select Advanced > Recovery > Place Controller > Online.

When a confirmation dialog box appears, click Yes.

Allow approximately 3 minutes for the controller to come online.

When the controller is online, the seven segment display will show the tray ID.

Caution:

If the correct number of drive enclosures are not displayed, or their icons are not green, submit an incident through Teradata @ Your Service.

From SMClient, power on the nodes, TMSs, and BAR servers:

To power on the nodes and servers in one cabinet, select that cabinet in the SMClient

Tree View, then select the Functions > Power On command. When prompted to confirm, click Yes.

9 b

To power on all the nodes and servers in the system, select System in the Tree View, then select the Functions > Power On command. When prompted to confirm, click Yes.

A Command Summary window displays to show the progress of the Power Off command.

When the command is running, the Status column displays In Progress. When the command completes, the Status column displays Complete. For more information about the window, see Server Management online Help.

Wait approximately 5-10 minutes for all nodes and servers (if present) to boot and to allow enough time for the CMICs to establish communication with all node and server chassis.

From the SMClient Tree View, verify that all components are powered on and operating normally.

The icons for all the chassis in each cabinet must be green, which means they have an OK status in the SMClient Tree View.

Caution:

If the icons for all the chassis in the cabinet are not green, submit an incident through Teradata

@ Your Service.

If you used the Teradata Parallel Upgrade Tool (PUT) to change the Set Teradata Start

Option to DO NOT start the database, use PUT to change the Set Teradata Start Option back to Start the Database.

Using a browser, open the PUT application. For more information, see the Parallel

Upgrade Tool (PUT) Reference, B035-5716.

Teradata Data Warehouse Appliance 2800 Implementation Guide 361

Chapter 14: Maintaining the Database

Powering the System Off and On

b c d

In the PUT screen, type the User Name and Password for the node, then press

In the Other operations drop-down list, select Set Teradata Startup Option.

Enter

From the Network Subnet Selection page, select the BYNET network, xx.xx.xx.xx

(byn0), then click Next.

When the Select Nodes page appears, move all the nodes from the Available list to the

Selected list, then click Next.

When the Select Teradata Startup Option page appears, select Automatically Start

Teradata after a system reboot, then click Next.

From the Select Reboot Option page, select No, don’t reboot the nodes now, then click

Next.

11 h

Click Finish.

If there are no problems encountered during the power on, start the Teradata Database.

In the SMClient Tree View, select the lowest-numbered node in the lowest-numbered cabinet. Do not select a VMS, TMS, or BAR server. For the location of lowestnumbered node in the cabinet, see

“Teradata Data Warehouse Appliance 2800 Cabinet

Configurations” on page 26 .

Click Functions > Connect.

On the Connect dialog box, select Console, then click Ok.

On the New Connection dialog box, click Ok.

A console window for the node displays.

Log on as root and provide the password.

The Teradata Command Prompt appears.

Verify that the nodes are connected to both BYNET networks (BYNET0 and BYNET1).

At the Teradata Command Prompt, type the following, then press

Enter

bam -s

•

For a Teradata Data Warehouse Appliance 2800 system with two nodes on the

BYNET over Ethernet, the following message should display:

Net #

Nodes

Routes

Net name eth2 eth3

•

For a Teradata Data Warehouse Appliance 2800 system with four nodes on the

BYNET V5 over InfiniBand, the following message should display:

Net #

Nodes

Routes

Net name

mlx4_0_1 mlx4_0_2

Where:

•

Net # is the number of the BYNET network (0 or 1)

•

Nodes is the number of nodes currently connected to the network in the Teradata

362 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 14: Maintaining the Database

Powering the System Off and On

Data Warehouse Appliance 2800 system

•

Routes is the current number of network routing paths (usually one routing path per node)

•

Net name is the network interface name

Verify that all the pdisks on all the nodes are good.

At the Teradata Command Prompt, type the following, then press

Enter

psh verify_pdisks

Wait for the following message to appear:

All pdisks on this node verified

Caution:

If this message does not appear, submit an incident through Teradata @ Your Service.

Type the following to verify that the database is down, then press

Enter

psh pdestate

The following message should display:

PDE state is DOWN/HARDSTOP

Type in the following command to start Teradata Database and press

Enter

/etc/init.d/tpa start

j a

Type the following and press

Enter

psh pdestate -a

The following message should display:

PDE state is RUN/STARTED.

DBS state is 5: Logons are enabled - The system is quiescent.

Note: Depending on the size of the Teradata database, it may take several minutes before the command returns this message. If the system does not return it on the first attempt, repeat the

psh pdestate -a

command until the message is returned.

Use vprocmanager to verify that all vprocs have started.

At the Teradata command prompt, type the following and press

tdatcmd

Enter

At the Teradata command prompt, type the following and press

vprocmanager

Enter

At the vprocmanager command prompt, type the following and press

status notonline

Enter

In the output, verify that the following message displays:

All DBS vprocs are fully online

All PDE nodes are fully online

If the messages do not display, submit an incident through Teradata @ Your Service.

Teradata Data Warehouse Appliance 2800 Implementation Guide 363

Chapter 14: Maintaining the Database

Servicing Unplanned Power Outages

For more information about troubleshooting a database start, and for information about gathering supporting information, such as console log error codes, for the

purpose of submitting an incident to Customer Support, see “Troubleshooting

Database Restarts” on page 344

Servicing Unplanned Power Outages

In the event of an unplanned power outage:

•

Submit an incident to Customer Support using the Teradata @ Your Service web site, as

described in “Opening an Incident” on page 133 .

•

Do not restart the database. With the help of Customer Support, perform a full system

power on sequence, as described in “Powering On All Chassis in a System or Cabinet” on page 357 .

Checkpoint

Before leaving this chapter, make sure that:



Result

You know the various methods for running console utilities.

You have a procedure for regularly purging accumulated log data.

You regularly check for data corruption in the database and file system.

You know how to restart Teradata Database software.

You know when to upgrade Teradata software and how to request assistance from Teradata

Customer Service.

You know how to stop the database and shut down the system hardware. You also know how to restore power and restart the database.

You know what to do in the event of an unplanned system outage.

Reference

“Running Database Utilities From

Viewpoint” on page 331

“Managing Accumulated Log Data” on page 336

“Verifying Data Block Integrity” on page 340

“Restarting the Teradata Database

Software” on page 342

“Upgrading Teradata Software” on page 350

“Powering the System Off and On” on page 350

“Servicing Unplanned Power Outages” on page 364

If you do not have these results, return to the section in the Reference column and review that procedure.

364 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 15

Moving Data to and from Teradata

Database Tables

This chapter shows how to set up, create, run, and troubleshoot simple data movement jobs using Teradata Parallel Transporter (PT) simplified job scripting.

For instructions on creating more complex Teradata PT job scripts, see Teradata Parallel

Transporter User Guide, B035-2445.

Note: Simplified job scripting is suitable for most simple data movement tasks. For more complex jobs, you can use the full Teradata PT scripting language (similar to SQL) to modify the simplified job script examples shown in this chapter.

Although Teradata PT is the preferred data movement utility, you can also use the BTEQ

utility to do some data movement tasks. See Appendix B: “Loading and Updating Tables with

BTEQ.”

Data Movement Task Overview

•

“Setting Up Configuration Files” on page 368

•

“Setting Up the Job Variables Files” on page 369

•

“Loading Data from an External ODBC Database” on page 370

•

“Loading Data from an External Flat File” on page 375

•

“Exporting Data to an External Flat File” on page 380

•

“Launching a Teradata PT Job” on page 383

•

“Monitoring and Managing a Teradata PT Job” on page 384

•

“Evaluating a Completed Teradata PT Job” on page 386

•

“Troubleshooting a Failed Job” on page 387

About Teradata Parallel Transporter Simplified

Job Scripts

All Teradata PT job scripts, simplified and full, use operators to move data from a source to a target destination. Producer operators read data from a data source and consumer operators write data to a data destination, as shown in the following diagram.

Teradata Data Warehouse Appliance 2800 Implementation Guide 365

Chapter 15: Moving Data to and from Teradata Database Tables

About Teradata Parallel Transporter Simplified Job Scripts

Data

Source

Reads

Data

Producer

Operator

Data

Stream

Consumer

Operator

Writes

Data

Destination

1195-001A

A Teradata PT simplified job, however, uses operator templates.

An operator template is a stored DEFINE OPERATOR statement that is automatically imported into your job script when you reference, in an APPLY statement, a standard Teradata

PT operator by its template name, as shown in the following example. In a full Teradata PT job script, you have to specify a DEFINE OPERATOR statement.

APPLY 'INSERT INTO TABLE_X ( :col1, ..., :coln );'

TO OPERATOR( $LOAD() ) ... ;\

In this example, $LOAD is the template name of the standard Teradata PT Load (consumer) operator that writes data to a data destination, in this case inserting values into Table_X.

The DEFINE OPERATOR statement for the $LOAD operator is stored in template file

$LOAD.txt in the Teradata PT template directory. Template operator names are the standard operator types prefixed by the dollar sign ($), unless a shorter yet still descriptive name exists.

Data Schemas

To move data, all Teradata PT job scripts must describe the structure of the data to be processed, that is, the columns in table rows or fields in file records. This description is called the data schema. But Teradata PT simplified job scripting does not require that you define a

SCHEMA statement. Schemas in Teradata PT simplified job scripting is inferred by the operator templates.

Example

A Teradata PT simplified job script uses this basic format as shown in the following example:

DEFINE JOB job_name

(

APPLY dml statement(s) TO OPERATOR ($consumer_operator_name)

SELECT * FROM OPERATOR ($producer_operator_name);

); where:

This Teradata PT Job Element...

Specifies...

DEFINE JOB job_name the name of the job.

Recommendation: use a descriptive name, for example,

Load_Daily_Transactions.

366 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

About Teradata Parallel Transporter Simplified Job Scripts

This Teradata PT Job Element...

Specifies...

APPLY dml statement(s) TO

OPERATOR

consumer_operator_name) the operation, called APPLY, that is to be performed on the target table.

TO OPERATOR

consumer_operator_name)

SELECT * FROM OPERATOR

producer_operator_name) the operator that writes data to the target table.

Operators that write to Teradata Database include:

•

$LOAD

•

$UPDATE

•

$INSERTER

•

$STREAM (optional, if purchased)

Operators that write to an external flat file include:

•

$DATACONNECTOR_CONSUMER or $FILE_WRITER the operation that selects data from the operator that has read data from the data source.

Operators that read data from external sources include:

•

$ODBC operator (external ODBC table data)

•

$DATACONNECTOR_PRODUCER or $FILE_READER (flat file data)

Operators that read data from Teradata Database include:

•

$EXPORT or $SELECTOR

Note: The SELECT statement used in Teradata PT simplified job scripts is not an SQL SELECT statement. You must create the

SELECT statement using the producer operator SelectStmt attribute.

Related Information

For...

Is available in...

more information on the simplified Teradata PT job script language all Teradata PT operators and attributes

Teradata Parallel Transporter User Guide,

B035-2445

Teradata Parallel Transporter Reference, B035-

2436

Teradata PT scripting options and strategies Teradata Parallel Transporter User Guide,

B035-2445 simple practice scripts you can launch and observe

Teradata Parallel Transporter Quick Start

Guide, B035-2501

Teradata Data Warehouse Appliance 2800 Implementation Guide 367

Chapter 15: Moving Data to and from Teradata Database Tables

Setting Up Configuration Files

Before beginning to run Teradata PT simplified job scripts, Teradata recommends that you set up the following global configuration files. Set up is normally only required at Teradata PT installation.

Configuration File Parameters

Global Job Variables File

Checkpoint Directory

Log Directory

Purpose

Allows you to specify global variables and values that can be used by many jobs.

Creating global variables helps eliminate the errors inherent in re-entering values in multiple job scripts.

It also allows you to keep such information as user name and password out of scripts where they may be seen by unauthorized persons.

Setup for these directories is included in the Teradata PT installation procedure.

For details, see the Teradata Tools and Utilities installation guide for your platform.

The contents of these configuration files can then be shared by all jobs.

Teradata PT supports configuration files on the following operating systems for the specification of Teradata PT system-wide configuration options.

Platform

Windows

UNIX z/OS

Configuration File

<installation directory>\twbcfg.ini

<installation directory>/twbcfg.ini

Configuration options can also be customized by placing the following configuration file in the home directory:

$HOME/.twbcfg.ini

Specified through the DDNAME of ATTRFILE.

To specify configuration file parameters use this form:

;

For example, on a UNIX system:

GlobalAttributeFile = '/usr/tbuild/<version_number>/ global.jobvariables.txt';

CheckPointDirectory = '/usr/tbuild/<version_number>/checkpoint';

LogDirectory = '/var/log/tbuild'; where:

•

GlobalAttributeFile is the path to the global job variables file.

368 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Setting Up the Job Variables Files

•

CheckpointDirectory is where Teradata PT stores job checkpoint records.

•

LogDirectory is the directory where Teradata PT stores job logs.

Specifying the Log Directory Value

You can specify the log directory for Teradata PT-generated logs in the following ways:

Specify the -L jobLogDirectory in the tbuild or tload command.

Set the LogDirectory parameter in twbcfg.ini file (recommended).

Note: If -L jobLogDirectory is used on the command line and the LogDirectory parameter is set in twbcfg.ini file, the value specified via -L jobLogDirectory is used.

If you do not specify or set the Log Directory value in either of the two ways listed above, logs are saved in the following default locations on UNIX and on Windows respectively:

<installation directory>logs.

Setting Up the Job Variables Files

You can create job variables and assign job variable values in two types of files:

•

Global Job Variables File: You can create a global job variables file to contain values for job variables. Every Teradata PT job automatically reads the global job variables file, if one exists. If there is a job variable used anywhere in the script, the job looks for the corresponding value in the global job variables file.

Note: A global job variables file is available on UNIX and Windows systems.

•

Local job variables file: You can also create a local job variables file to contain values for job variables. When the tbuild command specifies the -v option, the associated job reads the local job variables file. For example: tbuild -f weekly_update.txt -v jobvars.txt

Note: On z/OS, specify a local job variables file through the DDNAME of ATTRFILE.

If possible, define known common job variables when you begin writing your job script. The use of job variables enhances the efficiency and security of job scripting. You can add additional job variable names and values when required.

Setting up variables requires two actions:

•

Setting up script values to defer to local or global job variable values by specifying them using the form

@<job variable name>

, as follows:

VARCHAR TdpId = @MyTdpId,

VARCHAR UserName = @MyUserName,

VARCHAR UserPassword = @MyUserPassword

•

Entering job variable assignments in the global job variables file and/or the local job variables file separated by commas, or one assignment per line without commas, in the form

<job variable name>=’value’

, as follows:

MyTdpId ='database1',

MyUserName ='johndoe',

Teradata Data Warehouse Appliance 2800 Implementation Guide 369

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External ODBC Database

MyUserPassword ='johndoe'

The location of the global job variables file and the local job variables file, as well as the name of the global and local job variables file, is user-definable in the context of the following:

•

The user-defined path and filename of the global job variables file must put inside the twbcfg.ini file as an entry, as follows:

GlobalAttributeFile = '<userspath>/<usersGlobalJobVariablesName>'

•

The user-defined path and filename of the local job variables files is specified after the -v option on the command line.

For further information on specifying job variables in the script, see

“Setting Up the Job

Variables Files” on page 369

For information on specifying job variables on the command line at job launch, see “Assigning

Operator Attributes” on page 371 .

Loading Data from an External ODBC Database

The following figure illustrates loading data from an ODBC-compliant database into a

Teradata Database table using Teradata PT producer and consumer operators.

Oracle

Database

Read

Data

ODBC

Operator

Data

Stream

Load

Operator

Write

Data

Teradata

Database

Producer

Operator

Consumer

Operator

2550A002

Usage Notes for Loading a Teradata Table

DataDirect drivers must be installed and configured on each client from which Teradata PT

jobs are run. See “Setting Up an External ODBC Data Source” on page 147

The target table must exist in Teradata Database and must:

•

Be empty

•

Have no join indexes, hash indexes, or secondary indexes

•

Have no foreign keys

Note: To load data into a populated table, use the Update operator ($UPDATE). Operator attribute specification for $UPDATE using job variables is similar to the $LOAD operator shown in this job example. For information on creating an update job, see Teradata Parallel

Transporter User Guide, B035-2445.

For information on converting tables in an ODBC-compliant database to Teradata tables, see

“Converting Existing Database Tables to Teradata Tables” on page 180 .

370 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External ODBC Database

The database that owns the destination table must have enough perm space for the data.

Creating the Job Script

Use Notepad or another text editor to create the job script, using the simplified scripting format and standard operator definitions ($LOAD and $ODBC). For example:

DEFINE JOB job_name

(

APPLY $INSERT TO OPERATOR ($LOAD)

SELECT * FROM OPERATOR($ODBC);

);

Note: The example job script specifies the standard Teradata PT DML insert macro,

$INSERT. The $INSERT macro causes Teradata PT to generate an insert statement automatically based on the Load operator TargetTable attribute. If you need a more complex INSERT statement, for example, to use a CASE statement, you must create the full DML INSERT statement. See “Coding the Executable Section” in Teradata Parallel

Transporter User Guide.

Save the file as job_name.txt to a directory set up for similar jobs, for example (Windows):

C:/Program Files/Teradata/Client/client_version/Teradata Parallel

Transporter/Load_Jobs

Assigning Operator Attributes

Using a Teradata PT simplified job script requires that you define job variable values for certain common operator attributes in a local job variables file, as shown in the following procedure.

Variables already specified in the Global Job Variables file need not be specified again in the local job variables file unless you want to change the values. Local job variable values override the corresponding global variables when the job runs.

Note: Your job may benefit from the use of additional operator attributes not shown for this step. See “Load Operator” and “ODBC Operator” in Teradata Parallel Transporter Reference,

B035-2436.

Identify the Load operator attributes you want to use for the job and assign values to them.

The following table shows job variable names for commonly used LOAD attributes.

LOAD Operator

Job Variable Name

TargetTdpId

TargetUserName

TargetUserPassword

TargetAccountId

Job Variable Value

Values for these variables may have already been specified in the global job variables file, and only need to be specified in local job variables file if you want to override the global values.

Teradata Data Warehouse Appliance 2800 Implementation Guide 371

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External ODBC Database

LOAD Operator

Job Variable Name

LoadTargetTable

LoadErrorTable1

Job Variable Value

TargetWorkingDatabase Normally, the name of the database where the LoadTargetTable is located.

Specifying a TargetWorkingDatabase eliminates the need to fully qualify the name for LoadTargetTable, and ensures that

LoadErrorTable1, LoadErrorTable2, and LoadLogTable are located in the same database as LoadTargetTable.

The name of the Teradata Database table being loaded.

The name of a table that contains a list of records that were not processed for a job because of certain acquisition phase errors:

•

Constraint violations - Records that violate a range or value constraint defined for specific columns of a table.

•

Unavailable AMP - Records to be written to a non-fallback table about an offline AMP.

•

Data conversion errors - Records that fail to convert to a specified data type.

You cannot use a name that duplicates an existing table unless you are restarting a paused Load operator job.

If you specify a name, the system creates LoadErrorTable1 in the default database for the logon user, unless a different database is specified for the TargetWorkingDatabase attribute.

If you do not specify a name, the system default name for

LoadErrorTable1 is based on the LoadTargetTable name. The system names the table using the form ttname_ET, and creates the table is in the database that contains LoadTargetTable, unless a different database is specified in the TargetWorkingDatabase attribute.

LoadErrorTable2

LoadLogTable

The name of a table that contains a list of records that violated the unique primary index constraint for the LoadTargetTable.

You cannot use a name that duplicates an existing table unless you are restarting a paused Load operator job.

If you specify a name, the system creates LoadErrorTable2 in the default database for the logon user, unless a different database is specified in the TargetWorkingDatabase attribute.

If you do not specify a name, the system default name for

LoadErrorTable2 is based on the LoadTargetTable name. The system names the table using the form ttname_UV, and creates the table is in the database that contains LoadTargetTable, unless a different database is specified in the TargetWorkingDatabase attribute.

The name of the restart log table that contains checkpoint data which can be used in restarting a job.

The log table name must not duplicate t an existing table name.

The system automatically creates the log table in the default database for the TargetUserName unless you specify a database name as the value for the TargetWorkingDatabase attribute.

372 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External ODBC Database

LOAD Operator

Job Variable Name

LoadPrivateLogName

Job Variable Value

The name of a file in Logs directory to which the system writes job information specific to the Load operator, for example, LoadLog.

The specified name appears as a file in the public log.

If no private log name is specified, the log is stored in the public log.

For additional information and usage notes for Load operator attributes, see “Load

Operator” in Teradata Parallel Transporter Reference, B035-2436.

Identify the attributes you want to use for the ODBC operator and assign values to them.

The following table shows the job variable names for commonly used ODBC attributes.

ODBC Operator

Job Variable Name Job Variable Value

ODBCDSNname The DSNname of the ODBC source system, for example, OracleSys.

The DSNname is not required if it was already specified in the Global

Job Variables file.

ODBCUserName The name of a valid user for the ODBC source system, who has

SELECT privileges on the source table specified in ODBCSelectStmt.

The password for the user specified by UserName.

ODBCUserPassword

ODBCPrivateLogName The name of a file in the Logs directory that contains additional detailed job run information, specific to the $ODBC operator, which is not found in the public log. For example, ODBCLog.

Public logs can be useful in determining the causes of job failure.

ODBCSelectStmt The SQL SELECT statement that defines the ODBC data source and the columns the $ODBC operator should read. For example:

SELECT * FROM databasename.tablename; or if you are selecting a subset of available tablename columns,

SELECT

column_name1,

column_name2,

...

FROM databasename.tablename;

ODBCTruncateData Instructs the system how to handle source data strings that are too large to fit into the target table column.

For an explanation, see “Handling Truncated Data” on page 374

For additional information and usage notes for ODBC operator attributes, see “ODBC

Operator” in Teradata Parallel Transporter Reference, B035-2436.

Use Notepad or other plain text editor to create a list of job variables as described in step 1 and step 2, setting the actual values for your system, for example:

TargetTdpId = 'tdpId'

Teradata Data Warehouse Appliance 2800 Implementation Guide 373

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External ODBC Database

,TargetUserName = 'tdusername'

,TargetUserPassword = 'tdpassword'

,TargetAccountId = 'account_id'

,TargetWorkingDatabase= 'database_name'

,LoadPrivateLogName = 'loadlog'

,ODBCDSNname = 'DSNname'

,ODBCPrivateLogName = 'odbclog'

,ODBCUserName = 'odbcusername'

,ODBCUserPassword = 'odbcpassword'

,ODBCTruncateData = 'No'

,ODBCSelectStmt = 'Select * FROM databasename.tablename;'

Note: Operator job variable names are shown in the order the operators appear in the job script, but this arrangement is not required.

Save the job variables file as job_nameVar.txt, to the directory that contains the job script.

Note: For information on running a job, see

“Launching a Teradata PT Job” on page 383 .

Usage Considerations When Importing Data from an ODBC Database

Consider the following topics when importing data from an ODBC database into Teradata.

Handling Truncated Data

ODBC-compliant databases, for example Oracle or IBM DB2, sometimes contain column data types that may not be compatible with Teradata. For example, the maximum size of the

IBM DB2 column type LONG, which is equivalent to a Teradata VARCHAR column, is 2 MB.

The maximum VARCHAR column size is 64000 bytes.

You can load data from a LONG column data source if the data does not exceed the Teradata

VARCHAR 64000 byte limit. Use the TruncateData attribute for the ODBC operator to specify whether any source data that does exceed the limit should be truncated to fit into the corresponding Teradata column or to skip the operation for that row and return an error.

The TruncateData attribute values are:

•

'Yes' (or 'Y') = truncate data (default)

•

'No' (or 'N') = do not truncate data

Handling DATE Fields

On some non-Teradata databases the Date field does not equate to a Teradata DATE data type.

An Oracle DATE field, for example, is equivalent to the Teradata TIMESTAMP data type, which has a format of YYYY-MM-DD HH:MM:SS and is equivalent to CHAR(19). The

Teradata DATE data type in ANSI date form has a format of YYYY-MM-DD (equivalent to

CHAR(10)).

Whether the TruncateData attribute is set to Yes or No, the ODBC operator truncates the conversion of an Oracle Date field to a Teradata DATE data type. To avoid truncation when

374 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External Flat File converting Oracle Date information, the data type for the Teradata column must be

TIMESTAMP or CHAR(19).

Handling DECIMAL Data

When running a load job from a Windows client to import DECIMAL data from non-

Teradata Databases (for example, Oracle) and moving it to Teradata Database, you may encounter varying results depending on several data factors:

•

If the precision values between the source and target tables are not equal, the data is checked at runtime. If the data does not fit, the job is terminated.

•

If the scale factors do not match, one of the following happens:

•

If the source scale factor is less than the target, then Teradata PT adds 0s (zeros) to the end of the source scale factor until they do match, and then the job continues.

•

If the source scale factor is greater than the target, the job terminates before attempting to process the data, due to possible loss of data.

•

For source column NUMBER (m, n) and target column DECIMAL (M, N), the job does the following:

•

Terminates with error if n>N

•

Runs if n<N or n=N

•

Runs if m<=M, assuming n<N or n=N

•

Attempts to run if m>M, assuming n<N or n=N

For more information, see “ODBC Operator” in Teradata Parallel Transporter Reference.

Loading Data from an External Flat File

The following figure illustrates how Teradata PT loads data from an external flat file into a

Teradata Database table using Teradata PT producer and consumer operators.

Flat

File

Read

Data

DataConnector

Operator

Data

Stream

Load

Operator

Write

Data

Teradata

Database

Producer

Operator

Consumer

Operator

2550A004

Usage Notes for Loading a Teradata Table

DataDirect drivers must be installed and configured on each client from which Teradata PT

jobs are run. See “Setting Up an External ODBC Data Source” on page 147

The target table exists in Teradata Database and:

•

Is empty

Teradata Data Warehouse Appliance 2800 Implementation Guide 375

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External Flat File

•

Has no join indexes, hash indexes, or secondary indexes

•

Has no foreign keys

Note: To insert data into a populated table, use the Update operator ($UPDATE). Operator attribute specification for $UPDATE using job variables is similar to the $LOAD operator shown in this job example. For information on creating an update job, see Teradata Parallel

Transporter User Guide, B035-2445.

Make sure the target table has enough perm space to contain the data being loaded.

Investigate possible data conversion issues which may result form Teradata data type requirements.

Creating the Job Script

Use Notepad or another text editor to create the job script, using the simplified scripting format and standard operator definitions ($LOAD and $FILE_READER).

$FILE_READER is the more descriptive names for the DataConnector Producer operator.

For example:

DEFINE JOB job_name

(

APPLY $INSERT TO OPERATOR ($LOAD)

SELECT * FROM OPERATOR($FILE_READER);

);

Note: The example job script specifies the standard Teradata PT DML insert macro,

$INSERT. The $INSERT macro causes Teradata PT to automatically generate an insert statement based on the Load operator TargetTable attribute. If you need a more complex

INSERT statement, for example, to use a CASE statement, you must create the full DML

INSERT statement. See “Coding the Executable Section” in Teradata Parallel Transporter

User Guide, B035-2445.

See “Coding the Executable Section” in Teradata Parallel Transporter User Guide, B035-

2445.

Save the file as job_name.txt to the directory set up for this and similar jobs, for example, on Windows:

C:/Program Files/Teradata/Client/client_version/Teradata Parallel

Transporter/Load_Jobs

Specifying Operator Attributes

Using a Teradata PT simplified job script requires that you define job variable values for certain common operator attributes in a local job variables file, as shown in the following procedure.

Note: Your job may benefit from the use of other available operator attributes. See “Load

Operator” and “DataConnector Operator” in Teradata Parallel Transporter Reference, B035-

2436.

376 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External Flat File

Identify the Load operator attributes you want to use for the job and assign values to them.

The following table shows the job variable names for commonly used LOAD attributes.

LOAD Operator

Job Variable Name

TargetTdpId

TargetUserName

Job Variable Value

Values for these variables may have already been specified in the global job variables file. If so, they only need to be respecified in local job variables file if you want to change values.

TargetUserPassword

TargetAccountId

TargetWorkingDatabase Normally, the name of the database where the LoadTargetTable is located.

Specifying a TargetWorkingDatabase eliminates the need to fully qualify the name for LoadTargetTable, and ensures that

LoadErrorTable1, LoadErrorTable2, and LoadLogTable are located in the same database as LoadTargetTable.

LoadTargetTable

LoadErrorTable1

The name of the Teradata Database table being loaded.

The name of a table that contains a list of records that were not processed for a job because of certain acquisition phase errors:

•

Constraint violations - Records that violate a range or value constraint defined for specific columns of a table.

•

Unavailable AMP - Records to be written to a non-fallback table about an offline AMP.

•

Data conversion errors - Records that fail to convert to a specified data type.

You cannot use a name that duplicates an existing table unless you are restarting a paused Load operator job.

If you specify a name, the system creates LoadErrorTable1 in the default database for the logon user, unless a different database is specified in the TargetWorkingDatabase attribute.

If you do not specify a name, the system default name for

Teradata Data Warehouse Appliance 2800 Implementation Guide 377

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External Flat File

LOAD Operator

Job Variable Name

LoadErrorTable2

LoadLogTable

LoadPrivateLogName

Job Variable Value

The name of a table that contains a list of records that violated the unique primary index constraint for the LoadTargetTable.

You cannot use a name that duplicates an existing table unless you are restarting a paused Load operator job.

If you specify a name, the system creates LoadErrorTable2 in the default database for the logon user, unless a different database is specified in the TargetWorkingDatabase attribute.

If you do not specify a name, the system default name for

The name of the restart log table that contains checkpoint data which can be used in restarting a job.

The log table name must not duplicate t an existing table name.

The system automatically creates the log table in the default database for the TargetUserName unless you specify a database name as the value for the TargetWorkingDatabase attribute.

The name of a file in Logs directory to which the system writes job information specific to the Load operator, for example, LoadLog.

If no private log name is specified, the log is stored in the public log.

For additional information and usage notes for Load operator attributes, see “Load

Operator” in Teradata Parallel Transporter Reference, B035-2436.

Identify the attributes you want to use for the DataConnector operator and assign values to them. The following table shows the job variable names for commonly used

DataConnector operator ($FILE_READER) attributes.

DataConnector Operator

Job Variable Name

FileReaderFileName

Job Variable Value

The fully qualified name of the flat file that the operator reads, for example, a Windows pathname.

378 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Loading Data from an External Flat File

DataConnector Operator

Job Variable Name

FileReaderFormat

Job Variable Value

The format of the SourceFile, which can be any of the following values:

•

'Delimited' = in text format with each field separated by a delimiter character. When you specify Delimited format, you can use the optional FileReaderTextDelimiter attribute to specify the delimiter character. The default is the pipe character ( | ).

Note: The fields specified for this attribute must use the

VARCHAR data type. Non-VARCHAR specifications result in an error.

•

'Binary': A 2-byte integer, n, followed by n bytes of data.

•

'Formatted' = both prefixed by a record-length marker and followed by an end-of-record marker.

•

'Text' = character data separated by an end-of-record (EOR) marker.

•

'Unformatted' = not formatted. The data has no record or field delimiters and must be specified using a Teradata PT schema.

For details about using formats other than 'Delimited', see

“DataConnector Operator” in Teradata Parallel Transporter

Reference, B035-2436.

FileReaderTextDelimiter The delimiter used in the SourceFile, for example, '|' (default) or ',' .

To use the tab character as a delimiter, use uppercase'TAB', not 'tab'.

Note: If a character used as a delimiter also appears as part of the data, it must be preceded by a backslash character. For example, when a comma delimited flat file includes an address field that allows commas, the address must appear in the form: Los Angeles\,

California

FileReaderOpenMode The access mode ('read' or 'write'). The value for $FILE_READER is

'read'.

For additional information and usage notes for DataConnector operator attributes, see

“DataConnector Operator” in Teradata Parallel Transporter Reference, B035-2436.

Use Notepad or other plain text editor to create the job variables file and set the attribute values for the variables as described in step 1 and step 2, for example:

TargetTdpId

,TargetUserName

= 'tdpId'

= 'tdusername'

,TargetAccountId

,TargetWorkingDatabase

,LoadPrivateLogName

= 'account_id'

= 'database_name'

= 'loadlog'

Teradata Data Warehouse Appliance 2800 Implementation Guide 379

Chapter 15: Moving Data to and from Teradata Database Tables

Exporting Data to an External Flat File

,FileReaderTextDelimiter = '|'

Note: Operator job variable names are shown in the order the operators appear in the job script, but this arrangement is not required.

Save the job variables file as job_nameVar.txt, to the directory that contains the job script.

For information on running a job, see “Launching a Teradata PT Job” on page 383 .

Exporting Data to an External Flat File

The following figure illustrates how Teradata PT exports data from a Teradata Database table to an external flat file, using Teradata PT consumer and producer operators.

Flat

File

Write

Data

DataConnector

Operator

Data

Stream

Export

Operator

Read

Data

Teradata

Database

Consumer

Operator

Producer

Operator

2550A003

Usage Notes for Exporting Data to a Flat File

Determine the location of the flat file for use in specifying the $FILE_WRITER FileName attribute, which must be a complete pathname.

The $EXPORT operator is shown in this job example; however, you must use the SQL Selector operator ($SELECTOR) to export Large Objects (BLOB/CLOB data)

For information on the SQL Selector operator, see Teradata Parallel Transporter User Guide,

B035-2445.

Creating an Export Job Script

Use Notepad or another text editor to create the job script, using the simplified scripting format and standard operator definitions ($EXPORT and $FILE_WRITER).

$FILE_WRITER is the more descriptive name for the DataConnector Consumer operator.

For example:

DEFINE JOB job_name

(

APPLY $INSERT TO OPERATOR ($FILE_WRITER)

SELECT * FROM OPERATOR($EXPORT);

);

380 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Exporting Data to an External Flat File

Save the file as job_name.txt to the directory set up for this and similar jobs, for example, on Windows:

C:/Program Files/Teradata/Client/client_version/Teradata Parallel

Transporter/Expt_Jobs

Specifying Operator Attributes

Using a Teradata PT simplified job script requires that you define job variable values for certain common operator attributes in a local job variables file, as shown in the following procedure.

Note: Your job may benefit from the use of other available operator attributes. See

“DataConnector Operator” and “Export Operator” in Teradata Parallel Transporter Reference,

B035-2436.

Identify the DataConnector operator attributes you want to use and assign values to them.

The following table shows the job variable names for commonly used DataConnector operator ($FILE_WRITER) attributes.

DataConnector Operator

Job Variable Name

FileWriterFileName

FileWriterFormat

Job Variable Value

The fully qualified name of the flat file to which $FILE_WRITER writes the data, for example, a Windows pathname.

The format of the TargetFile, which can be any of the following values:

•

'Delimited' = in text format with each field separated by a delimiter character. When you specify Delimited format, you can use the optional FileWriterTextDelimiter attribute to specify the delimiter character. The default is the pipe character ( | ).

Note: The fields specified for this attribute must use the

VARCHAR data type. Non-VARCHAR specifications result in an error.

•

'Binary': A 2-byte integer, n, followed by n bytes of data.

•

'Formatted' = both prefixed by a record-length marker and followed by an end-of-record marker.

•

'Text' = character data separated by an end-of-record (EOR) marker.

•

'Unformatted' = not formatted. The data has no record or field delimiters and must be specified using a Teradata PT schema.

For details about using formats other than 'Delimited', see

“DataConnector Operator” in Teradata Parallel Transporter

Reference, B035-2436.

Teradata Data Warehouse Appliance 2800 Implementation Guide 381

Chapter 15: Moving Data to and from Teradata Database Tables

Exporting Data to an External Flat File

DataConnector Operator

Job Variable Name

FileWriterTextDelimiter The delimiter used in the SourceFile, for example, '|' (the default) or

',' .

To use the tab character as a delimiter, use uppercase'TAB', not 'tab'.

California

FileWriterOpenMode

Job Variable Value

The access mode ('read' or 'write'). The value for $FILE_WRITER is

'write'.

For additional information and usage notes for DataConnector operator attributes, see

“DataConnector Operator” in Teradata Parallel Transporter Reference, B035-2436.

Identify the EXPORT operator attributes you want to use and assign values to them. The following table shows the job variable names for commonly used EXPORT operator attributes.

Export Operator

Job Variable Name

SourceTdpId

SourceUserName

SourceUserPassword

SourceAccountId

ExportPrivateLogName

Description

Values for these variables may have already been specified in the global job variables file. If so, they only need to be respecified in local job variables file if you want to change values.

The name of a file in the Logs directory to which the system writes job information about the $EXPORT operator, for example, ExportLog.

If no private log name is specified, the log is stored in the public log.

382 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Launching a Teradata PT Job

Export Operator

Job Variable Name

ExportSelectStmt

Description

The SQL SELECT statement which identifies the Teradata database, table, and columns that the $EXPORT operator should read. For example:

SELECT * FROM databasename.tablename; or if you are selecting a subset of available SourceTable columns:

SELECT

column_name1,

column_name2,

...

FROM databasename.tablename;

Note: Teradata PT supports most Teradata SQL SELECT statement options, including WHERE clauses, CASE statements, and UNION ALL. See Teradata Parallel Transporter User Guide,

B035-2445.

For additional information and usage notes for Export operator attributes, see “Export

Operator” in Teradata Parallel Transporter Reference, B035-2436.

Use Notepad or other plain text editor to create the job variables file and set the attribute values for the variables as described in step 1 and step 2, for example:

FileWriterFileName = 'flatfile_name'

,FileWriterFormat = 'delimited'

,FileWriterTextDelimiter = '|'

,SourceTdpId

,SourceUserName

,SourceUserPassword

,SourceAccountId

= 'tdpId'

= 'tdusername'

= 'tdpassword'

= 'account_id'

,ExportSelectStmt = 'SELECT * FROM databasename.tablename'

Save the job variables file as job_nameVar.txt to the directory that contains the job script.

Note: For information on running a job, see

“Launching a Teradata PT Job” on page 383 .

Launching a Teradata PT Job

Use the tbuild command to launch a Teradata PT job.

In a Command window, navigate to the directory where the job script is stored. For example:

C:/Program Files/Teradata/Client/15.00/Teradata Parallel

Transporter/LoadJobs

Enter the following at the command prompt: tbuild -f filename -v job_variables_filename -j jobname where:

Teradata Data Warehouse Appliance 2800 Implementation Guide 383

Chapter 15: Moving Data to and from Teradata Database Tables

Monitoring and Managing a Teradata PT Job

Option or Parameter

-f filename

-v

job_variables_filename

-j jobname

Specifies

The file name of the job script. The file name should use a .tpt extension.

If you do not execute the tbuild command in the directory where the job script is stored, filename must be a fully qualified pathname.

The job variables file associated with the job script.

If you are not executing the tbuild command in the directory where the job script is stored, or if the job variables file is not located in the same directory as the job script, job_variables_file must be a fully qualified pathname.

A unique name that helps to easily identify the public log and checkpoint log for a job.

jobname must be the last argument in the tbuild command.

When the job completes, the screen displays an Exit Code. For information on exit codes, see

“Examining the Exit Codes” on page 386

Specifying Job Variables at Job Launch

You can specify job variables on the command line as part of the tbuild command, which launches a job, for example, to specify a different username and password. Command line variable values supercede any corresponding variable values that may exist in the local and global job variables files. For example: tbuild -f filename -v jobvariable_filename -u “jobvariable_name =

‘value’[,jobvariable_name = ‘value’]” -j jobname

Reference Information

Information on...

tbuild syntax and options using tbuild

Is available in...

Teradata Parallel Transporter Reference, B035-2436

Teradata Parallel Transporter User Guide, B035-2445

Monitoring and Managing a Teradata PT Job

Teradata PT provides the capability to monitor and manage a job while it is running.

•

The twbcmd command allows you to:

•

Pause and resume a job.

•

View the status of a job.

384 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Monitoring and Managing a Teradata PT Job

•

The twbkill command allows you to stop a job.

Pausing and Resuming a Job

After a Teradata PT job launches, you can pause and then resume the job using the twbcmd command.

From the command line in the working directory, enter the following command to pause the job:

twbcmd job_id JOB PAUSE where job_id is the job name followed by a dash (“-”) and the job sequence number generated by the system at launch.

When you are ready to continue, enter the following command to resume the job: twbcmd job_id JOB RESUME

The job resumes at the point at which it was paused.

Reference Information

Information on...

twbcmd syntax and options using twbcmd

Is available in...

Teradata Parallel Transporter Reference, B035-2436

Teradata Parallel Transporter User Guide, B035-2445

Viewing the Job Status

Do the following to check the status of a running job.

From the command line in the working directory, enter the following command to check job status: twbcmd job_id JOB STATUS where job_id is the job name followed by a dash (“-”) and the job sequence number generated by the system at launch.

Terminating a Job

If you need to terminate a running job (for example if continuation of the job could either cause system failures or significantly impact overall system performance), you can use the

twbkill command to force all executing job tasks to terminate immediately.

From the command line in the working directory, enter the following command to terminate a job:

twbkill job_id where job_id is the job name followed by a dash (“-”) and the job sequence number generated by the system at launch.

When the job terminates, check the logs, as shown in

“Troubleshooting a Failed Job” on page 387 , to determine the cause of the job termination.

Teradata Data Warehouse Appliance 2800 Implementation Guide 385

Chapter 15: Moving Data to and from Teradata Database Tables

Evaluating a Completed Teradata PT Job

Reference Information

Information on...

the twbkill command

Is available in...

•

“Managing an Active Job” in Teradata Parallel

Transporter User Guide, B035-2445

•

“Teradata PT Utility Commands” in Teradata Parallel

Transporter Reference, B035-2436

Evaluating a Completed Teradata PT Job

Examining the Exit Codes

Upon completion, each Teradata PT job returns an exit code to indicate job success or failure.

Examine the job exit code that appears on the screen where you launched the job.

Exit Code

Description.

Completed successfully.

Completed successfully, but issued one or more warnings.

Terminated due to a user error, such as a syntax error.

Terminated due to a fatal error.

A fatal error is any error other than a user error.

Determine whether or not further action is required.

•

If the exit code is 0, the job was successful and no further action is required.

•

If the exit code is 4, you can check the logs to examine the warning(s) and determine whether or not you should revise the portion of the script that generated each warning to avoid a possible future failure.

•

If the exit code is 8 or 12, revise the script to correct the error.

For jobs that return an exit code that requires examination of the job logs, go on to

“Troubleshooting a Failed Job” on page 387

Reference Information

Information on...

exit codes, error tables, logs, and strategies for evaluating a job

Is available in...

The chapter on “Post-Job Considerations” in Teradata

Parallel Transporter User Guide, B035-2445

386 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 15: Moving Data to and from Teradata Database Tables

Troubleshooting a Failed Job

To fix a failed Teradata PT job, you must be able to detect the cause of the failure and correct it.

Access:

•

The public log in the Logs directory.

•

Private (operator) logs and error tables.

Evaluate the logs and any errors they contain.

•

If the job fails before it runs, the failure may have been caused by a tbuild error, a scripting syntax error, or a system resource issue. The associated errors and warnings are in the public log.

•

If the job runs but fails to complete, it may be due to an initialization error, such as an invalid operator attribute specification, or a data acquisition error, such as an improper SQL SELECT statement. These errors may be found in both the public log and private logs.

•

If an error is detected in a private (operator) log, you also need to evaluate the corresponding information in the error tables for the operator, which provide more detailed information about the error.

For detailed information about detecting and correcting job errors, see the chapter on

“Troubleshooting a Failed Job” in Teradata Parallel Transporter User Guide, B035-2445.

Once the causes of errors have been corrected in the job script, you can re-launch the job.

Checkpoint

Before leaving Chapter 15: “Moving Data to and from Teradata Database Tables,”

make sure that:



Result

The Configurations file is set up and ready for use.

You have created the required job script and local job variables file, and have loaded at least one Teradata Database table with data from an external ODBC source table.

You have created the required job script and local job variables file, and have loaded at least one Teradata Database table with data from an external flat file.

Reference

“Setting Up Configuration Files” on page 368

“Loading Data from an External ODBC

Database” on page 370

“Loading Data from an External Flat

File” on page 375

Teradata Data Warehouse Appliance 2800 Implementation Guide 387

Chapter 15: Moving Data to and from Teradata Database Tables

Checkpoint



Result

You have created the required job script and local job variables file, and have exported data from at least one Teradata Database table to an external flat file.

You have successfully launched a Teradata PT job and monitored it as it ran.

You have used the Teradata PT error code system to evaluate a completed job.

You understand how to examine the logs and error files to determine the cause and corrective action for a failed job.

Reference

“Exporting Data to an External Flat

File” on page 380

“Launching a Teradata PT Job” on page 383

“Evaluating a Completed Teradata PT

Job” on page 386

“Troubleshooting a Failed Job” on page 387

If you do not have these results, return to the section in the Reference column and review that procedure.

388 Teradata Data Warehouse Appliance 2800 Implementation Guide

CHAPTER 16

Backing Up Data to Disk with Appliance

Backup Utility

The Appliance Backup Utility feature provides a simple way to back up Teradata Database to a disk file system, then restore the backup datasets from the disk file system to the same Teradata

Database. You can also use the Appliance Backup Utility to copy Teradata Database object data of one instance of a Teradata Database to another instance of a Teradata Database. You must have the Appliance Backup Utility installed on each Teradata Database node when copying data to another instance.

System Configuration

Data is backed up to IP SAN (iSCSI) or NAS (NFS) disk storage, which is required, but

Teradata Corporation does not provide. You are responsible for providing, configuring, and maintaining the disk storage.

Figure 81: System Diagram

Teradata Node 1

Appliance Backup Utility

Using

ARC CLIv2 PIOM

TDICU and Tera-GSS

Third-Party Server

GB Ethernet

IP SAN or NAS

Disk

Storage

Third-Party Backup Application

Client and Media Server

Teradata Node 2

Appliance Backup Utility

Using

ARC CLIv2 PIOM

TDICU and Tera-GSS

Tape

Storage

VTL or

Disk

Storage

3134A001

For complete data protection, copy data from the IP SAN or NAS disk storage to tape through any third-party backup application such as NetBackup, IBM Tivoli, EMC NetWorker, and

CommVault. Backing up then becomes a two-step process: backing up to IP SAN or NAS disk storage, then copying to tape storage, disk, or Virtual Tape Library (VTL) with a third-party application. To restore, use the original file names to copy the data back to the IP SAN or NAS disk storage, then restore to Teradata Database.

Teradata Data Warehouse Appliance 2800 Implementation Guide 389

Chapter 16: Backing Up Data to Disk with Appliance Backup Utility

Features

Note: You are responsible for providing, configuring, and maintaining the third-party application and should be proficient in managing your data protection environment. Teradata

Corporation support is limited to Appliance Backup Utility functionality on the node.

Using the Appliance Backup Utility GUI, you can:

•

Back up all DBC data with the Backup All option

•

Restore the latest DBC backup with the Restore Latest option

•

Back up selected database objects such as triggers, macros, or tables with the Backup

Selected Objects option

•

Restore selected database objects with the Restore Selected Objects option

See the Appliance Backup Utility Installation and User Guide, B035-3134 for information on using the Appliance Backup Utility GUI.

Components

The Appliance Backup Utility software components are the Appliance Backup Utility server, client, and GUI.

Appliance Backup Utility Server

The Appliance Backup Utility server is a Teradata Database node that:

•

Has Appliance Backup Utility server, client, and GUI software

•

Is connected to the IP SAN or NAS disk storage

•

Is the node on which you run the configuration script

The Teradata Database node that is designated as the Appliance Backup Utility server also functions as the GUI and an Appliance Backup Utility client. There must always be an active

Application Backup Utility client on the Teradata Database node that is selected to run the

Application Backup Utility server.

Appliance Backup Utility Client

An Appliance Backup Utility client is a Teradata Database node that you have specified as a client and has:

•

Active Appliance Backup Utility client software

•

A connection to the IP SAN or NAS disk storage

•

Passive Appliance Backup Utility server software, which is not used unless the server is manually switched in failover recovery

390 Teradata Data Warehouse Appliance 2800 Implementation Guide

Chapter 16: Backing Up Data to Disk with Appliance Backup Utility

About Appliance Backup Utility Operation

Appliance Backup Utility GUI

The Appliance Backup Utility GUI allows you to control the backup and restore operations of the Appliance Backup Utility. You can install the GUI on any node or PC workstation that is connected to the Appliance Backup Utility server.

About Appliance Backup Utility Operation

The Teradata Database node that is designated as the Appliance Backup Utility server controls backup and restore operations, working as a master to Appliance Backup Utility clients that manage the data streams during backup and restore operations.

A Backup All job is configured to run multiple data streams, which are equal to the number of

Appliance Backup Utility clients configured to the Appliance Backup Utility. For every job data stream, a backup file is created on the storage device. There might be multiple disk partitions or directories designated as destination paths for the backup stream. The sum of all backup files created by the data streams equals the entire backup of your Teradata Database. If one or more of these files are deleted or corrupted, you will not be able to restore your

Teradata Database backup.

You can configure a Backup Selected Objects job to run one or more data streams. Configure one stream only if you know the length of time the backup will take and if the objects or group of objects are small. Optimal backup throughput is only achieved with full parallelism where all Appliance Backup Utility clients are used.

Teradata Node Connection to Secondary

Storage Device

The Appliance Backup Utility takes advantage of Teradata node parallelism to back up and restore Teradata Database, resulting in high performance. Appliance Backup Utility backup and restore throughput also scales with the size of the system.

To achieve maximum parallelism, connect each Teradata Database node to a backup target disk device. This allows the node to send all data on its primary disk to the device through the

Gbit network connection on the node. If there is no direct connection from a node to the secondary storage device, an Appliance Backup Utility client cannot be configured for that node. The data local to that node is redirected through the Teradata BYNET to other nodes that are configured as Appliance Backup Utility clients. The backup and restore operation will complete, but the throughput will be severely degraded.

To achieve maximum network performance, ensure that the network connection is in a private LAN.

Teradata Data Warehouse Appliance 2800 Implementation Guide 391

Chapter 16: Backing Up Data to Disk with Appliance Backup Utility

Secondary Storage Device

Teradata Database backup and restore throughput is affected by several factors. One of the most important factors is the storage device you choose to connect to the Teradata Database node. The Appliance Backup Utility supports the use of IP SAN (iSCSI) or NAS (NFS) as a secondary storage device, but Teradata Corporation does not sell or recommend a specific brand. However, consider the following criteria when choosing the storage device:

•

Total size of the storage space

•

Type, quantity, and size of the disk drives in the array

•

Storage device performance rating

•

Type of network connection (1Gbit or 10Gbit)

•

Number of network connections to the device

•

Concurrency and parallelism aspects of the device

•

Disk partitioning

•

Other device specifications that contribute to the read and write performance of the storage device

Network Switch

A Gbit network switch might be necessary to connect every Teradata Database node to the IP

SAN or NAS storage device. Teradata Corporation does not provide this device. It is your responsibility to provide and configure this device.

Installation and Configuration

See the Appliance Backup Utility Installation and User Guide, B035-3134 for information on installing and configuring Appliance Backup Utility.

392 Teradata Data Warehouse Appliance 2800 Implementation Guide

APPENDIX A

Type and Format Differences between

Teradata and Other DBMS

This appendix describes the differences between the types and formats used in Teradata and those used in other database management systems, for example, Oracle.

About Teradata Data Types

Teradata Database data types may differ from the data types in other ANSI-compliant databases. You may need to convert some existing data types into Teradata data types.

Be aware that even though some data types seem the to be the same in both systems, there may be subtle differences in the way the data types are implemented. Queries using these data types may not return an error, but the results may not be as expected.

Recommendation: Always test queries thoroughly after converting to Teradata data types and make sure that the data type functions as you expect.

The following table shows how some Oracle data types can be mapped to Teradata data types:

Oracle Data Type

BINARY_DOUBLE

BINARY_FLOAT

BLOB/CLOB

CHAR

DATE

FLOAT

LONG

LONG RAW

NUMBER or NUMBER (*)

NUMBER(38)

NUMBER(n, m)

TIMESTAMP

Teradata Data Type

FLOAT

BLOB/CLOB

CHAR

DATE or TIMESTAMP(0)

NUMBER

LONG VARCHAR or VARCHAR

VARBYTE (<=64000)

NUMBER or NUMBER (*)

NUMBER(38)

NUMBER(n, m)

TIMESTAMP or TIMESTAMP WITH TIME ZONE

Teradata Data Warehouse Appliance 2800 Implementation Guide 393

Appendix A: Type and Format Differences between Teradata and Other DBMS

About Teradata Data Types

Oracle Data Type

TIMESTAMP WITH TIME

ZONE

TIMESTAMP WITH LOCAL

TIME ZONE

VARCHAR2

XML

Teradata Data Type

TIMESTAMP or TIMESTAMP WITH TIME ZONE

VARCHAR

XML

In Teradata, the maximum number of characters or bytes allotted to a CHAR or VARCHAR column depends on the character size of server character set for the column. For example, if the server character set is:

•

LATIN (single-byte), then the maximum value is 64,000

•

UNICODE (double-byte), then the maximum value is 32,000

Teradata has several additional numeric data types, including:

•

BYTEINT - a signed binary integer value from -128 to 127

•

SMALLINT - a signed binary integer value from -32,768 to 32,767

•

INTEGER - a signed, binary integer value from -2,147,483,648 to 2,147,483,647

•

BIGINT - a signed, binary integer value from -9,223,372,036,854,775,808 to

9,223,372,036,854,775,807

Note: Oracle does not have an INTEGER data type, but it does have an alias called INTEGER that maps to the NUMBER data type.

DATE Formats

In Teradata, the date format for the system is set with the DateForm configuration setting and the default date format setting in the specification for data formatting (SDF) file.

Those settings determine the following:

•

Export data type of DATE values

•

Data entry format for DATE values

•

Format of DATE values in macros being executed

•

Date format for string-to-DATE comparisons and conversions

•

Display format of DATE columns in newly created tables and views

To view the current system default DATE format, enter:

HELP SESSION;

You can use the dbscontrol utility DateForm setting to reset the system-level date format.

394 Teradata Data Warehouse Appliance 2800 Implementation Guide

Appendix A: Type and Format Differences between Teradata and Other DBMS

About Teradata Data Types

DateForm Setting

0 (IntegerDate, the default)

1 (ANSIDate)

Description

Use the system default DATE format specified in the SDF file.

The default format is YY/MM/DD. However, you can customize the SDF file to change this date format to any valid date format.

The export data type is four-byte integer.

The system default DATE format is YYYY-MM-DD.

The export data type is CHARACTER(10).

This format is similar to the DATE data type format in Oracle.

For details about the DateForm setting, see DBS Control in Utilities: Volume 1 (A-K), B035-

1102.

You can also override the system-level date format.

To change the DATE format setting for ...

the system the session a user a DATE column or DATE value

Use the ...

•

DBS Control utility to change the DateForm setting.

•

Locale Definition utility (tdlocaledef) to customize the SDF file.

SET SESSION DATEFORM statement.

DATEFORM option in the CREATE USER or

MODIFY USER statement.

FORMAT phrase.

Recommendation: To avoid format errors in date operations, specify dates as ANSI DATE literals. All SQL date operations accept this format. The format for an ANSI DATE literal is:

DATE 'YYYY-MM-DD'

Temporal Data Type

Teradata is a temporal database management system (DBMS). It provides built-in support for the time dimension, including special facilities for storing, querying, and updating timerelated data. As a temporal DBMS, Teradata can distinguish between historical data, current data, and data that will be in effect in the future.

Teradata provides temporal table support with period data types. A period is an anchored duration that represents a set of contiguous time granules within the duration. It has a beginning bound (defined by the value of a beginning element) and an ending bound

(defined by the value of an ending element). Beginning and ending elements can be DATE,

TIMESTAMP, or TIMESTAMP WITH TIME ZONE types, but both must be the same type.

Oracle has a temporal data type, which is defined as a period. The Oracle period definition does not map directly to a Teradata period definition. The differences are as follows:

Teradata Data Warehouse Appliance 2800 Implementation Guide 395

Appendix A: Type and Format Differences between Teradata and Other DBMS

About Teradata Data Types

Item Oracle

Start and end column data type

DATE, TIMESTAMP, TIMESTAMP WITH

TIME ZONE, or TIMESTAMP WITH

LOCAL TIME ZONE

Yes Start and end columns are

NULLABLE

Infinite values NULL value is used to represent infinite values

Data type of period column NUMBER data type

Internal storage of period column

Valid time dimension

Teradata

DATE, TIMESTAMP, or TIMESTAMP WITH

TIME ZONE

No as per ANSI

System-generated NUMBER data type value is stored in the period column

Any period definition in the table is a valid time dimension column, and there can be more than one valid time dimension column in the table

MAX DateTime value (UNTIL_CHANGED) is used to represent infinite value

The PERIOD data type of Teradata

For example, if the start and end columns are

DATE data type then the period column data type is PERIOD (DATE)

This is a pseudo-column, and no value is stored

The period definition with [AS] VALIDTIME defines the valid time column, and there can be only one valid time dimension column in the table

Geospatial Types

Teradata Database supports geospatial types. Geospatial information identifies the geographic location of features and boundaries on the planet. Geospatial types address the need to store, manage, retrieve, manipulate, and analyze geospatial information by governmental bodies and commercial enterprises. For example, local governments might use geospatial data for city planning, traffic management, or accident investigation.

You can use geospatial types to represent 0-dimensional (point), 1-dimensional (line),

2-dimensional (polygon), and 3-dimensional geometries.

Teradata Database implements geospatial types as system-defined structured types. The geospatial types define methods that perform geometric calculations and test for spatial relationships between two geospatial values.

For more information, see SQL Geospatial Types, B035-1181.

JSON Type

For more information, see Temporal Table Support, B035-1182 or ANSI Temporal Table

Support, B035-1186.

JSON (Javascript Object Notation) is a text-based, data interchange format, often used in web applications to transmit data. JSON has been widely adopted by web application developers because compared with XML it is easier to read and write for humans and easier to parse and generate for machines. JSON documents can be stored and processed in Teradata Database.

396 Teradata Data Warehouse Appliance 2800 Implementation Guide

Appendix A: Type and Format Differences between Teradata and Other DBMS

Reference Information

The functionality for supporting the storage and processing of JSON (JavaScript Object

Notation) data in Teradata Database includes:

•

A JSON data type, stored as a JSON document or as JSON records in relational format

•

Methods, functions, and procedures for processing, shredding, and publishing JSON data

•

JSON documents up to 16 MB

•

JSONPath support, which provides simple traversal and regular expressions with wildcards to filter and navigate complex JSON documents

For more information, see Teradata JSON, B035-1150.

User-Defined Types

Teradata Database supports user-defined types (UDTs). SQL provides a set of predefined data types, such as INTEGER and VARCHAR, that you can use to store the data that your application uses, but they might not satisfy all of the requirements you have to model your data.

User-defined types allow you to extend SQL by creating your own data types and then using them like predefined data types. You can also define methods that operate on the UDT.

Distinct Types

Distinct UDTs are based on a single predefined data type, such as INTEGER or VARCHAR.

For example, you can create a distinct UDT named euro that is based on a DECIMAL(8,2) data type and use it to store monetary data. You can define a method for the euro type that converts the value to a US dollar amount.

Structured Types

Structured UDTs are collections of one or more fields called attributes, each of which is defined as a predefined data type or other UDT (which allows nesting).

For example, you can create a structured UDT named circle that consists of x-coordinate, y-coordinate, and radius attributes. You can define a method for the circle type that computes the area of the circle using the radius attribute.

Note: Teradata has different storage definition requirements than Oracle and does not use extents or table spaces.

Reference Information

Information on...

supported data types in Teradata Database, including UDTs

Is available in...

SQL Data Types and Literals, B035-1143

Teradata Data Warehouse Appliance 2800 Implementation Guide 397

Appendix A: Type and Format Differences between Teradata and Other DBMS

Reference Information

Information on...

DATE literals

DATE formats and the FORMAT phrase using the DBS Control utility (dbscontrol) to change the DateForm setting the SDF file and the Locale Definition utility (tdlocaledef)

•

CREATE USER / MODIFY USER

•

HELP SESSION

•

SET SESSION DATEFORM

Is available in...

SQL Data Types and Literals, B035-1143

Utilities: Volume 1 (A-K), B035-1102

Utilities: Volume 2 (L-Z), B035-1102

SQL Data Definition Language Detailed Topics, B035-

1184

398 Teradata Data Warehouse Appliance 2800 Implementation Guide

APPENDIX B

Loading and Updating Tables with BTEQ

This appendix describes using BTEQ to load data into Teradata Database or to update existing tables.

Differences between BTEQ and Teradata PT

BTEQ and Teradata PT can both load data into Teradata and can update tables, among other functions. Other similarities include:

•

Capacity: Both can send up to 64 KB per request and up to 1 MB per request with array support.

•

Capabilities: Both can support multiple sessions and can load, export, process DDL, and act as a command line interface.

The following table explains the major differences between BTEQ and Teradata PT:

BTEQ

Consumes less client CPU.

Loads or updates either all records or stops after x records that you specify with the REPEAT command.

Limited error handling.

Teradata PT

Consumes more client CPU.

Can also load or update only selected rows.

No checkpoint restart.

No SERIALIZE option.

Does not process multiple DML statements in a single pass of the input data.

Performs error handling and creates error log tables.

Checkpoint restart.

SERIALIZE option ensures the correct sequencing of transactions.

Can perform conditional apply or multiple apply.

Recommendation: If your job has millions of rows, use Teradata PT. If not, especially for a load job that will be used again in the future, consider both. See which performs better and causes less system overhead. BTEQ can be a good choice for smaller amounts of data, exploratory work, and DDL.

Teradata Data Warehouse Appliance 2800 Implementation Guide 399

Appendix B: Loading and Updating Tables with BTEQ

Loading Tables

Use the following BTEQ input stream to load (import) data into the Teradata Database:

.IMPORT DATA FILE=DeptData.imp

.REPEAT *

USING DeptNo (SMALLINT),

DeptName (VARCHAR(14)),

Loc (CHAR(3)),

MgrNo (SMALLINT)

INSERT INTO Personnel.newtable (DeptNo, DeptName,

Loc,MgrNo)

VALUES (:DeptNo, :DeptName, :Loc, :MgrNo); where:

•

The REPEAT * command repeats the next request until the data in the import file is exhausted.

•

The term newtable refers to an empty table to receive the data being loaded.

Reference Information

Information on...

BTEQ commands, including

PACK running batch jobs to submit

BTEQ commands and

Teradata SQL

Is available in...

Basic Teradata Query Reference, B035-2414

•

“Using BTEQ Scripts to Create Database Objects” on page 196

•

Basic Teradata Query Reference, B035-2414

Updating Tables

Frequently, when updating the Teradata Database, you make the same change to many rows. It is helpful to eliminate the repetitive work required to update them individually. The REPEAT command serves this purpose.

Updating Rows Using a Single Request

If you can describe all of the rows by some formula, then you can use a single request to update them all. The following request, for example, updates the salaries of all employees in department 600 of the database Personnel: update personnel.employee set salary=salary*1.07

where deptno=600;

400 Teradata Data Warehouse Appliance 2800 Implementation Guide

Appendix B: Loading and Updating Tables with BTEQ

Updating Tables

Updating Rows Using Multiple Requests

If you cannot describe all of the rows by a formula, you must describe them individually. The following requests, for example, update the salaries of two employees: update personnel.employee set salary=salary*1.07

where empno = 10006; update personnel.employee set salary=salary*1.07

where empno = 10013;

This approach is convenient for a few updates, but if there were hundreds, the script would become very long. It would also be very inflexible; you would have to edit each entry to use the script again for another list of employees.

Updating Rows by Importing a File

A better approach would be to create a separate file (for example, RAISEEMP) containing two records in data format representing the employee numbers 10006 and 10013. Then use the

BTEQ IMPORT command with a REPEAT command to update the rows in the database.

Using the REPEAT Command When Importing a File

The REPEAT command appears before the request and specifies the total number of requests to be submitted.

The following BTEQ script using the BTEQ REPEAT command opens the character-format file RAISEEMP and repeats the update sequence twice:

.IMPORT data file=raiseemp

.REPEAT 2 using enumb (char(5)) update personnel.employee set salary=salary*1.07

where empno = :enumb;

For each employee, BTEQ reads a value from the RAISEEMP file for the variable called enumb and carries out the UPDATE for the row whose EmpNo equals the value of enumb.

Notice:

When using a file originally exported with the BTEQ EXPORT command as the source for an

IMPORT command across a different platform type, ensure that the endianness type of both platforms is the same. You can verify this from the “Client Platform Byte Order” tab in the output of the SHOW CONTROLS command.

Teradata Data Warehouse Appliance 2800 Implementation Guide 401

Appendix B: Loading and Updating Tables with BTEQ

Updating Tables

402 Teradata Data Warehouse Appliance 2800 Implementation Guide

APPENDIX C

Advanced Features

This appendix describes advanced features that can benefit your system after it is set up and functioning smoothly.

Database Query Log

Use the Database Query Log (DBQL) to track query behavior. DBQL provides a series of predefined tables and views that can store historical records of queries and their duration, performance, and target activity based on rules you specify. You control whether or not to populate the DBQL tables. If you choose not to use DBQL, the tables remain empty.

DBQL logs information on a variety of SQL requests, from short transactions to longerrunning analysis and mining queries. You can log information for an application name, a user or group of users, or a list of accounts.

To implement DBQL, you use simple SQL requests to control the starting and ending of the logging activity. These rules may be dynamically changed as needed to support management of the Teradata Database system.

When to Use DBQL

Use DBQL to do any of the following:

•

Capture query/statement counts and response times. You can look in the DBQL logs to see if this is the first time this query has been broken and what the historical pattern of its execution has been.

•

Validate that nonunique secondary indexes (NUSIs) are actually used. You can free up space and improve table update performance by deleting NUSIs.

•

Determine which aggregate join indexes (AJIs) are used the most. This allows you to make a cost-benefit analysis on their AJIs, comparing usage against size and time to build.

•

Analyze SQL text and process steps. View the SQL text that inadvertently wiped out the system using DBQL historical data and then attempt to rebuild the lost data.

•

Log optimizer queries as XML documents.

•

Make further refinements to workload groups and scheduling.

•

Discover potential application improvements.

•

Understand basic workload trends, such as growth patterns and workload mix, and identify outliers.

Teradata Data Warehouse Appliance 2800 Implementation Guide 403

Appendix C: Advanced Features

About Procedures and External Procedures

•

Determine whether a query has redrive protection and if the request was redriven after a database failure.

For more information about DBQL, see Database Administration, B035-1093.

About Procedures and External Procedures

If you have one or more SQL statements that you use repeatedly, you may want to store the statements in a procedure in Teradata Database, and then simply call the procedure from your application whenever you want to execute the SQL statements.

In addition to SQL statements such as INSERT and SELECT, procedures can use various control and condition handling statements such as REPEAT and LOOP. This allows procedures to support more complex SQL than macros. You can also pass input arguments to the procedure and have it return output arguments.

Applications that use procedures can perform better because of greatly reduced network traffic between client and server, and are easier to maintain because business rules are encapsulated and enforced on the server.

Note: Teradata uses the following terminology for procedures:

•

Stored procedures (SQL procedures): Procedures that are written using SQL statements.

•

External procedures: Procedures that are written using C, C++, or Java.

Instead of using procedures, you may want to use macros to execute simple, repetitive SQL.

See