Teradata 2580 Data Warehouse Appliance Implementation Guide

From the principal administrative client configured in Chapter 4: “Setting Up Teradata

“Password Control Options” in Chapter 6:

“Creating and Managing Passwords” in Security

Administration

Procedure 2: Create User DBADMIN

Clients,” log on to Teradata Administrator as user DBC.

Teradata Data Warehouse Appliance 2580 Implementation Guide 107

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: Setting Up the Database Administrator User

Create the database administrator as follows:

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 the default password control values and how to change them, see “Password Control Options” in Chapter 6: “Creating and Managing

Passwords” in Security Administration.

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. Space in bytes that will contain 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 103

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

Procedure 1: Create the DBADM Profile .

108 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: 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

“Procedure 3: Grant Database

Privileges to User DBADMIN” on page 110 , 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.

Reference Information

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

For step...

Information on...

1 logon to Teradata Administrator

2 characteristics of a user

Is available in...

“Task 1: Preparing for Administration” on page 97 .

“Databases and Users” in Chapter 2: “Populating the Database” in Database Administration

Teradata Data Warehouse Appliance 2580 Implementation Guide 109

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: Setting Up the Database Administrator User

For step...

(cont)

Information on...

syntax and options for the

CREATE USER statement guidelines for determining administrator space requirements and long term managing of space the default password control values and how to change them

Is available in...

“CREATE USER” in Chapter 6: “CREATE

TRANSFORM - CREATE VIEW” in SQL Data

Definition Language Syntax and Examples

Chapter 4: “Space” in Database Administration

“Password Control Options” in Chapter 6:

“Creating and Managing Passwords” in Security

Administration

Procedure 3: Grant 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.

The Query window appears and displays the generated GRANT statement:

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

110 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: Setting Up the Database Administrator User

3 d

From the Query window, click the Run Query button

Specify values for the following fields:

e a

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.

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;

d e

From the Query window, click the Run Query button

Close the Query window.

Teradata Data Warehouse Appliance 2580 Implementation Guide 111

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: Setting Up the Database Administrator User

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

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, INSERT, UPDATE, DELETE, STATISTICS, SHOW,

EXECUTE PROCEDURE, EXECUTE FUNCTION 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.

112 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: Setting Up the Database Administrator User

Specify values for the following fields:

Field

To/From User

All

Grant

Description

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 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;

6 e

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 113

Chapter 5: Allocating Space and Creating an Administrative User

Task 3: Setting Up the Database Administrator User

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 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.

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 on 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

“Procedure 2: Create User DBADMIN.”

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

114 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 5: Allocating Space and Creating an Administrative User

Task 4: Setting Up Administrators to Monitor Teradata Database Activity

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 on to the next section,

“Task 4: Setting Up Administrators to Monitor Teradata Database Activity.”

Reference Information

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

For step...

2 through 6

Information on...

Is available in...

logon to Teradata Administrator

“Task 1: Preparing for Administration” on page 97 .

system tables and views

•

Chapter 2: “Data Dictionary Views” in Data

Dictionary

•

Chapter 4: “Data Dictionary Tables” in Data

Dictionary

user privileges syntax and options for the

GRANT statement password format rules

Chapter 2: “Creating Users and Defining Access

Privileges” in Security Administration

“GRANT (SQL Form)” in Chapter 2: “Data

Control Language Syntax” in SQL Data Control

Language

“GRANT (Role Form)” in Chapter 2: “Data

Control Language Syntax” in SQL Data Control

Language

“Creating Passwords” in Chapter 6: “Creating and Managing Passwords” in Security

Administration

Task 4: Setting Up Administrators to Monitor

Teradata Database Activity

Procedure 1: Add Administrative Users to Teradata Manager

In Chapter 3, “Task 10: Initialize Teradata Manager”

“Procedure 2: Create Teradata Manager

User DBCMANAGER” on page 88 sets up the DBCMANAGER user to perform a single

function, that is, to logon and maintain the Teradata Manager service connection to the database. All further use of Teradata Manager to monitor and manage Teradata Database should be done by other Teradata Database administrative users.

Teradata Data Warehouse Appliance 2580 Implementation Guide 115

Chapter 5: Allocating Space and Creating an Administrative User

Task 4: Setting Up Administrators to Monitor Teradata Database Activity

The following procedure adds the principal administrator, user DBADMIN, as a Teradata

Manager user. This procedure can also be used to add other administrative users, but the procedure assumes that all Teradata Manager users are added after they are created in the database and have database administrator privileges similar to those defined in

“Procedure 3:

Grant Database Privileges to User DBADMIN” on page 110

From the Teradata Manager server, click Start > Programs > Teradata Manager 13.0 >

Database Setup. The Teradata Manager Database Setup window appears.

In the Database Setup window click File > Database Setup.

If you have not already saved the screen output to a log file, a dialog box offers to save it before clearing the screen and continuing.

In the Database Setup dialog:

•

For Super User enter DBC, and for Super User Password, enter the permanent DBC password.

•

Leave Console Password blank.

•

Uncheck the Set up Database for Teradata Manager check box.

•

Check Create a Teradata Manager User.

•

For User Name, enter a username for the new Teradata Manager user:

•

for initial setup, DBADMIN

•

for adding other users, specify a valid Teradata Database username

•

Leave User Account String as it is for DBADMIN. Assign the needed account strings by assigning user membership in a profile that contains the needed account strings.

Note: Creating a Teradata Manager user automatically replaces the user profile with the default Teradata Manager profile. For information on replacing or adding to

autogenerated Teradata Manager profiles, see “Procedure 2: Reset the Profile for a

Teradata Manager User” on page 117

•

For User Password and Confirm Password enter the permanent private password for the new user. All users are created with a temporary password and then prompted to create a permanent private password at first log on to the database. Do not enter a temporary password in this field.

•

For Perm Space, leave the value at 10 MB.

•

For Spool Space, check Same as Parent.

•

For DBADMIN all privileges should show in the Give privileges to run box and the

Do not give privileges to run box should be empty.

For Teradata Manager users other than DBADMIN, you can optionally restrict access to some Teradata Manager functions:

Click the privilege to highlight it.

Use the <<button to move the privilege from the Give privileges to run box to the

Do not give privileges to run box. To simplify access management give all privileges to administrators set up as Teradata Manager users.

116 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 5: Allocating Space and Creating an Administrative User

Task 4: Setting Up Administrators to Monitor Teradata Database Activity

•

Leave Migrate TDWM Database unchecked.

•

Click OK.

Creating the Teradata Manager user will take a few minutes. The output of the process is displayed in the Database Setup window.

When the process is finished, close the Database Setup window, or create another user by

choosing Database Setup from the File menu and returning to step 2

Note: Creating a Teradata Manager user automatically replaces the user profile with the default Teradata Manager profile. The default profile will not be sufficient for most users for general database activity. Therefore you must replace the default profile generated by

Teradata Manager with the profile you created for the user.

Reference Information

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

For step...

Information on...

All set up of the DBCMANAGER user

Is available in...

“Procedure 2: Create Teradata Manager User

DBCMANAGER” on page 88

3 user accounts

Manager with the DBADM profile created in “Procedure 1: Create the DBADM Profile” on page 105

Procedure 2: Reset the Profile for a Teradata Manager User

Use this procedure to reset the profile for all newly added Teradata Manager users with preexisting Teradata Database profiles.

From the Teradata Manager server, click Start>Programs>Teradata Manager

13.0>Teradata Manager. The Logon Information screen appears.

In the Logon Information screen enter the following information:

•

For System (DBS) Name, enter the name of the Teradata Database system.

•

For Username, enter DBC.

•

For Password, enter the permanent DBC password.

•

Click the Profile drop down arrow, and select Default.

•

Click in any other field to release the OK button.

•

In the Server options field, ensure that Get data from Teradata Database is checked.

•

Click OK.

From the menu bar at the top of the main screen select Administer.

In the drop down menu, select BTEQ window to open the BTEQ utility. The BTEQ query window appears.

Logon to the database by entering system_name/dbc in the query window. Press Enter.

Teradata Data Warehouse Appliance 2580 Implementation Guide 117

Chapter 5: Allocating Space and Creating an Administrative User

Checkpoint

At the prompt, enter the DBC password and press Enter.

Enter the following SQL statement to replace the default profile assigned by Teradata

MODIFY USER DBADMIN AS PROFILE=DBADM PERM=perm_space ; where the value of perm_space is the amount space in bytes calculated for the Permanent

Space field in step b

“Procedure 2: Create User DBADMIN” on page 107 .

Press Enter.

On the BTEQ menu bar, click Sessions>Exit to close BTEQ.

On the Teradata Manager menu bar click File>Exit to close Teradata Manager.

Reference Information

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

For step...

Information on...

7 setting up the DBADMIN user profile setting up for user DBADMIN setting up other user profiles

Is available in...

“Procedure 1: Create the DBADM Profile” on page 105

“Procedure 2: Create User DBADMIN” on page 107

“Task 2: Creating Profiles” on page 241 .

Checkpoint

Before leaving Chapter 5: “Allocating Space and Creating an Administrative User,” make sure

that:

√

Result

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

The DBS Control utility fields related to the use of Locking Logger are reset from the default values.

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

Crashdumps has perm space assigned to it.

Reference

“Procedure 1: Set up Teradata

Administrator GUI” on page 97 .

“Procedure 3: Change Locking Logger

Settings” on page 98

“Procedure 4: Change the

PasswordExpire Parameter and Restart the Database” on page 99 .

“Procedure: Assign Perm Space to

Crashdumps” on page 101 .

118 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 5: Allocating Space and Creating an Administrative User

Checkpoint

√

Result

There is a spool space reserve.

You have an administrative user called

DBADMIN, who has:

•

A profile.

•

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

•

Been added as a Teradata Manager user.

Reference

“Procedure: Create a Spool Space

Reserve” on page 103 .

•

“Task 3: Setting Up the Database

Administrator User” on page 105 .

•

“Task 4: Setting Up Administrators to Monitor Teradata Database

Activity” on page 115

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 119

Chapter 5: Allocating Space and Creating an Administrative User

Checkpoint

120 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 6

Creating Databases, Tables, and

Views

This section describes the methodology for creating databases, data tables, and views in

Teradata Database. It also describes how to use the Teradata Administrator, Teradata SQL

Assistant, and Basic Teradata Query (BTEQ) utilities to accomplish these administrative tasks.

Teradata Administrator provides a Windows-based graphical interface for performing database administration tasks such as creating databases and tables, granting system privileges, and managing database space. It provides an easy way to execute administrative procedures interactively.

BTEQ is a general-purpose, command-based program that allows users on a workstation to submit SQL requests to the database, including Data Manipulation Language (DML), Data

Definition Language (DDL), and Data Control Language (DCL) statements. You can submit queries interactively or prepare a script and submit it as a batch job.

You can also use the SQL Assistant utility to submit SQL requests to the database. For a

comparison of BTEQ and SQL Assistant, see “Task: Submitting a Query Using SQL Assistant” on page 208

Task 1: Creating Databases

A Teradata Database is permanent space that can contain objects such as data tables, indexes, views, and macros, as well as users and other databases. A database implicitly owns all objects created within its space. Individual objects do not require a space allocation, but you can specify space limits for some objects.

To ensure data integrity, Teradata recommends only administrators and privileged users interact with data tables. All other database activity should be done in views. This approach requires creation of the following top level databases:

Database

Tables_Database(s)

Description

•

Owns perm space.

•

Contains all tables and data.

•

Typically, is not directly accessed by end users.

•

Administrative and Batch users create and can modify database objects and perform data loads and updates.

Note: Where security policy requires it, you can designate views for all database operations so that users never access the data tables directly.

Teradata Data Warehouse Appliance 2580 Implementation Guide 121

Chapter 6: Creating Databases, Tables, and Views

Task 1: Creating Databases

Database

Views_Database(s)

Description

•

Does not require perm space because it contains no permanent objects.

•

Contains views of the tables in the Tables_Database.

•

Allows end users to execute all queries against individual views.

•

Update users can perform INSERT, SELECT, DELETE, UPDATE and

MERGE operations using views.

Procedure 1: 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

SQL.

to specify display of generated

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

Specify values for the following database parameters.

Syntax Element

Database Name

Explanation

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

Recommendation: Enter Tables, Tables_Database, TBL_DB, or something similar.

Owner

Permanent

Spool

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

Recommendation: Enter DBADMIN.

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

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

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.

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.

122 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 1: Creating Databases

Syntax Element

Account

Default Journal

Comment

Before Journal

After Journal

FallBack

Explanation

Not applicable.

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

on using accounts, see “User Accounts” on page 241 .

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 syntax element is not normally used.

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 syntax element is not normally used.

Not applicable, but turned on 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

Teradata Data Warehouse Appliance 2580 Implementation Guide 123

Chapter 6: Creating Databases, Tables, and Views

Task 1: Creating Databases

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.

Procedure 2: 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.

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.

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

For information on the creation of views, see “Task 3: Creating Views” on page 140

For a description of user types, see “Task 1: Assessing User Needs” on page 239

Owner

Permanent

Space

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

Recommendation: Enter DBADMIN.

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

Recommendation: Although the Views database is not created to contain tables, it is the best place to put stored procedures. If you plan to use stored procedures, allocate a minimal amount of permanent space, for example 100 MB, and then adjust the space allocation if needed using the MODIFY DATABASE statement.

124 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 1: Creating Databases

Syntax Element

Spool Space

Temp Space

Account

Default Journal

Comment

Before Journal

After Journal

FALLBACK

Explanation

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 “Task 6: Granting Table Access

Not applicable.

Recommendation: Not applicable, because journaling is not specified.

Optional. You can enter text to describe the database.

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 to Views Databases” on page 262 . After completing the procedure, return to this

section and continue with the remaining tasks.

Teradata Data Warehouse Appliance 2580 Implementation Guide 125

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

Reference Information

For step...

All

Information on...

options for setup and operation of

Teradata Administrator syntax and options for:

•

CREATE DATABASE

•

DELETE DATABASE

•

DROP DATABASE

•

MODIFY DATABASE guidelines for determining database space requirements an overview of SQL procedures and how they are stored in the database data protection using FALLBACK creating and using views user types

Is available in...

Chapter 2: “Getting Started With Teradata

Administrator” in Teradata Administrator

User Guide

“CREATE DATABASE” in Chapter 2:

“CREATE AUTHORIZATION - CREATE

GLOP SET” in SQL Data Definition

Language Detailed Topics

“CREATE DATABASE” in Chapter 2:

“CREATE AUTHORIZATION - CREATE

GLOP SET” in SQL Data Definition

Language Syntax and Examples

Chapter 4: “Space” in Database

Administration

“Stored Procedure Overview” in Chapter 1:

“Introduction” in SQL Stored Procedures

and Embedded SQL

“Fallback Protection” in Chapter 8:

“Protecting Data” in Database

Administration

“Task 3: Creating Views” on page 140 .

“Task 1: Assessing User Needs” on page 239

Task 2: Creating Tables

Like all database management systems, Teradata has a CREATE TABLE statement. While this statement is similar to those in other ANSI-compliant databases, there are a few differences.

Therefore, you will need to convert your SQL table definitions to Teradata SQL table definitions.

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

•

Create all data tables in the Tables_Database. See “Task 1: Creating Databases” on page 121 .

•

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

•

Provide general user access to table data using views and macros.

•

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

126 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

Example

The following shows how a simple table definition in Oracle can be written in Teradata. Note that Teradata does not use extents or table spaces, and has different storage definition requirements.

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 details about the CREATE TABLE statement in Teradata, see

“Procedure 3: Creating Tables in Teradata” on page 130

Procedure 1: Converting Existing Tables to Teradata Tables

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

ANSI-compliant database to Teradata.

Identify each Oracle schema/user and all database objects (tables, indexes, views, materialized views, etc.) 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 under databases and users:

•

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 almost the same as a database, except that a user has a password and can log on to the system, whereas the database cannot.

Determine the objects that are migrating to Teradata and map them to Teradata databases/ users.

You can create Teradata databases that correspond to the Oracle schemas. You can migrate the Oracle database objects and group them using the corresponding Teradata databases.

Identify the DDL for each schema object.

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 127

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

Map Oracle table elements to Teradata table elements. See

“Procedure 3: Creating Tables in

Teradata” on page 130 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.

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

In Teradata, you define a Primary Index, which is used to distribute table rows across units of parallel execution (AMPs). You can achieve further partitioning of the data rows within each AMP by defining a Partitioned Primary Index for the table. This partitioning is similar to the type of partitioning that Oracle tables perform, although it is easier to define such partitioning schemes in Teradata because partitioning is a logical organization of data within the database file system, but it requires no knowledge of table space definitions or physical disks. For more information, see

“Procedure 4: Choosing a Primary Index” on page 136

and

“Partitioned Primary

Indexes” on page 138 .

•

Constraints can be defined on the columns.

•

Referential integrity can be defined.

•

Global temporary tables are supported.

•

The data block size can be defined.

•

Triggers can be defined. See “Triggers” on page 388

•

Freespace can be defined.

Teradata has a number of additional table options, including:

•

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

For details, see

“Procedure 4: Choosing a Primary Index” on page 136

•

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, you have to enable a table to be accessed with parallel query processes in Oracle. This is automatic in Teradata.

Translate the DDL for each schema object to Teradata DDL.

Oracle and Teradata DDL for creating tables differ 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/users. You define the space quotas when you create the databases/users. See

“Task 1: Creating Databases” on page 121 . Teradata Database manages disk space usage automatically and allocates space to

the tables as needed to store data. Therefore, the Teradata CREATE TABLE statement does not include database storage management clauses.

128 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

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 the Teradata CREATE TABLE statement, see

“Procedure 3: Creating Tables in Teradata” on page 130 .

Procedure 2: Starting the Basic Teradata Query Utility

Basic Teradata Query Utility (BTEQ) is a general-purpose, command-based program that allows users on a workstation to communicate with one or more Teradata Database systems.

Using BTEQ, you can:

•

Create database objects such as databases, tables, and views.

•

Perform administrative tasks.

•

Submit SQL requests, including DDL, DCL, and DML statements.

•

Format reports for both print and screen output.

You can create data tables interactively using Teradata Administrator, BTEQ, or SQL Assistant.

You can also automate the creation of data tables by creating and running a BTEQ script that contains the BTEQ commands and SQL DDL statements for creating data tables. See

“Task 4:

Using Scripts to Create Database Objects” on page 145

For those who know Oracle, BTEQ is similar to SQL*Plus.

Procedure: 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 Teradata Data Warehouse Appliance 2580 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:

•

The Teradata Database release and version.

•

The transaction semantics for the session.

•

The character set for the session.

Teradata Data Warehouse Appliance 2580 Implementation Guide 129

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

•

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...

2, 5

All

Information on...

setting session character sets logging on to Teradata Database using BTEQ session transaction semantics options for setup and operation of

BTEQ

Is available in...

“Viewing and Changing International Character

Set Settings and Defaults” in Appendix A:

“Teradata Database Configuration, Global

Defaults, and Client Connections” in Database

Administration.

“The LOGON Command” in Chapter 2:

“Starting and Exiting BTEQ” in Basic Teradata

Query Reference.

“Session Modes and Transaction Processing” on page 204 .

Chapter 3: “Using BTEQ” in Basic Teradata

Query Reference.

Procedure 3: Creating Tables in Teradata

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

•

Teradata Administrator

•

BTEQ (interactively or through scripts)

•

SQL Assistant

Teradata Administrator provides an easy-to-use graphical interface for creating tables. BTEQ and SQL Assistant allow you to submit CREATE TABLE DDL statements to Teradata

Database. For a comparison of BTEQ and SQL Assistant, see “Task: Submitting a Query Using

SQL Assistant” on page 208

. The following procedure shows how to create tables using BTEQ:

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

“Procedure 2:

Starting the Basic Teradata Query Utility” on page 129

.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);

130 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables where:

Syntax Element

MULTISET

SET

Explanation

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.

database_name data_type

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 “Task 1: Creating Databases” on page 121

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 the data type of a column. You must specify a single data type for each column.

For more information, see

“Teradata Data Types” on page 375

[UNIQUE]

PRIMARY

INDEX

Specifies the primary index, which is used by the system for data distribution, data access, table joins, and aggregations. 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 131

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

Syntax Element

primary_index_ column

Explanation

Specifies a column that defines 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 index columns that primarily have unique values, that are frequently accessed, and have values that do not change. See

“Procedure 4: Choosing a Primary Index” on page 136

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

using the ALTER TABLE statement, see “Optional Table-level and Column-level

Elements” on page 132

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

Create Database Objects” on page 145

Set privileges on the table so that only designated administrative users can access or

modify the table directly. See Chapter 12: “Managing Database Users,”

for information about granting privileges on the table to 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

“Task 1: Optimizing Query Performance Using

COLLECT STATISTICS” on page 224 .

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 Chapter 5: “CREATE TABLE” in SQL Data Definition Language Syntax

and Examples.

Syntax Element

GLOBAL

TEMPORARY

JOURNAL

Explanation

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.

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. This can be done at a later time after you have analyzed your data protection needs.

132 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

Syntax Element

FREESPACE

DATABLOCKSIZE

[UNIQUE] INDEX

PARTITION BY

Explanation

Specifies the percent of free space that will remain 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%.

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 or complex queries). Use a smaller value if the database is used primarily for tactical work (online transaction processing).

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

“Task 3: Using Secondary and Join Indexes” on page 228

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 138 .

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 Chapter 5: “CREATE TABLE” in SQL Data Definition

Language Syntax and Examples.

Teradata Data Warehouse Appliance 2580 Implementation Guide 133

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

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.

COMPRESS

CONSTRAINT

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

Recommendation: For maximum benefit, apply the COMPRESS phrase to a column under the following conditions:

•

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 length results in the elimination of 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

134

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);

Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

To create this table using a BTEQ script, see “Task 4: Using Scripts to Create Database Objects” on page 145

See

Chapter 7: “Loading Data from an ODBC-Compliant Database”

for a sample Teradata

Parallel Transporter (PT) load job script that loads data into this table.

See

Chapter 17: “Exporting Data to a Flat File” for a sample Teradata PT export job script that

exports data from this table and writes the data to an external flat file.

Reference Information

Information on...

Is available in...

an overview of tables, including global temporary and volatile tables

•

syntax and options for:

•

CREATE TABLE

•

ALTER TABLE

•

DROP TABLE

•

RENAME TABLE

•

required privileges for tables the default database

“Tables”in Chapter 2: “Populating the Database” in Database

Administration.

“Tables”in Chapter 1: “Objects” in SQL Fundamentals.

Chapter 5: “CREATE TABLE” in SQL Data Definition

Language Syntax and Examples.

data protection using:

•

FALLBACK

•

Permanent Journal using the FREESPACE option to manage performance, and guidelines for calculating a

FREESPACE value using the DATABLOCKS option to manage performance and guidelines for calculating a

DATABLOCKS value

“Default Database” in Chapter 2: “Basic SQL Syntax and

Lexicon” in SQL Fundamentals.

Chapter 8: “Protecting Data” in Database Administration.

data types and data type attributes Chapter 1: “SQL Data Definition” in SQL Data Types and

Literals.

indexing:

•

primary indexes

•

partitioned primary indexes

•

secondary indexes

•

join indexes (materialized views)

“Procedure 4: Choosing a Primary Index” on page 136

“Task 3: Using Secondary and Join Indexes” on page 228

“FreeSpacePercent” in Chapter 12: “DBS Control

(dbscontrol)” in Utilities: Volume 1 (A-K).

“FreeSpacePercent” in Chapter 11: “Managing Space” in

Performance Management.

“DATABLOCKSIZE” in Chapter 8: “CREATE/ALTER TABLE and Data Retrieval in Performance Management.

“PermDBSize” in Chapter 12: “DBS Control (dbscontrol)” in

Utilities: Volume 1 (A-K).

Teradata Data Warehouse Appliance 2580 Implementation Guide 135

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

Information on...

compressing column values column-level and table-level constraints

Is available in...

“Column Sizing Guidelines” in Chapter 15: “Database-Level

Capacity Planning Considerations” in Database Design.

“COMPRESS Phrase”in Chapter 9: “Default Value Control

Phrases” in SQL Data Types and Literals.

“Semantic Constraint Specifications” in Chapter 13:

“Designing for Database Integrity” in Database Design.

Procedure 4: Choosing a Primary Index

In Teradata Database, the Primary Index (PI) is the physical mechanism for assigning a data row to an Access Module Processor (AMP) and a location on the disks of the AMP. The value of the primary index for a row is processed by a hashing algorithm, and the resulting hash value determines where the row is placed. PIs also enable efficient joins and aggregations. The most efficient way to access a row is by using the PI; this is always a one-AMP operation

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

Guidelines for Choosing PI columns

Choosing a PI for a table is perhaps the most critical decision a database designer makes because the choice may have a profound impact on system performance. A good PI choice balances workload evenly among AMPs, leading to optimal performance, parallelism, and efficient data access. Use the Space Usage application of Teradata Manager to check for data skew. If a PI causes skew, you can change it by dropping and recreating the table.

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.

136 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

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.

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 rarely, and preferably never, 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 more 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

“Task 3: Using Secondary and Join Indexes” on page 228

for information on optimizing indexes.

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

“Primary and Foreign

Keys” on page 138

When your 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 137

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

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 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

No Primary Index (NoPI) Tables

You can create tables without a primary index (NoPI). The chief purpose of NoPI tables is to enhance the performance of FastLoad and Teradata Parallel Data Pump (TPump) Array

INSERT data loading into staging tables.

You can also use NoPI tables as intermediate work tables where PI access is not a consideration. NoPI tables are automatically balanced across AMPs, leading to parallel efficiency.

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

Primary 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

138 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 2: Creating Tables

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.

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.

Reference Information

Information on...

indexing:

•

primary indexes

•

partitioned primary indexes

•

secondary indexes

•

join indexes (materialized views) no primary index tables

Is available in...

“Task 3: Using Secondary and Join Indexes” on page 228 .

Chapter 10: “Data Distribution and Data Access Methods” in Introduction to Teradata

“Indexes”in Chapter 1: “Objects” in SQL Fundamentals

Chapter 9: “Teradata Database Indexes: The Basics” in

Database Design

“NoPI Tables” in Chapter 10: “Primary Indexes” in

Database Design.

Teradata Data Warehouse Appliance 2580 Implementation Guide 139

Chapter 6: Creating Databases, Tables, and Views

Task 3: Creating Views

Information on...

referential integrity

Is available in...

“Referential Integrity”in Chapter 1: “Objects” in SQL

Fundamentals

Task 3: Creating 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 “Task 1: Creating Databases” on page 121 .

For information on materialized views, see

“Join Indexes” on page 232

Procedure

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 “Task: Submitting a Query Using

SQL Assistant” on page 208 .

140 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 3: Creating Views

The following procedure shows how to create views using BTEQ:

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

the Basic Teradata Query Utility” on page 129 .

“Procedure 2: Starting

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; 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

“Task 1: Creating Databases” on page 121

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 “Task: Understanding Lock Levels” on page 217

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.

ALL option

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 141

Chapter 6: Creating Databases, Tables, and Views

Task 3: Creating Views

Syntax Element

SELECT clause

(continued)

Explanation

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.

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 “Task 4: Using Scripts to

Create Database Objects” on page 145

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.

142 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 3: Creating Views

See

Chapter 12: “Managing Database Users,”

for information about granting privileges on the view to users.

Example 1

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:

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

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...

2 overview of views

•

syntax and options for:

•

CREATE VIEW/REPLACE

VIEW

•

DROP VIEW

•

RENAME VIEW

•

required privileges for views

Is available in...

“Views” in Chapter 2: “Populating the

Database” in Database Administration

“Views”in Chapter 1: “Objects” in SQL

Fundamentals

“CREATE VIEW/ REPLACE VIEW”in

Chapter 6: “CREATE TRANSFORM -

CREATE VIEW” in SQL Data Definition

Language Syntax and Examples

Teradata Data Warehouse Appliance 2580 Implementation Guide 143

Chapter 6: Creating Databases, Tables, and Views

Task 3: Creating Views

For step...

Information on...

2 the default database

2 the SELECT statement, including usage of the following options and clauses:

•

DISTINCT or ALL option

•

TOP n and TOP m PERCENT clause

•

WHERE clause

•

GROUP BY clause

•

HAVING clause

•

QUALIFY clause

•

ORDER BY clause

•

WITH CHECK OPTION clause

•

rules for creating, replacing, and using views

•

updatable views

•

deleting rows using views

(DELETE, Basic/Searched Form)

•

updating rows using views

(UPDATE) specifying locking in views

2 recursive views

Is available in...

“Default Database”in Chapter 2: “Basic SQL

Syntax and Lexicon” in SQL Fundamentals

Chapter 1: “The SELECT Statement” in SQL

Data Manipulation Language

“CREATE VIEW/ REPLACE VIEW”in

Chapter 6: “CREATE TRANSFORM -

CREATE VIEW” in SQL Data Definition

Language Syntax and Examples

Chapter 3: “SQL Data Manipulation

Language Statement Syntax” in SQL Data

Manipulation Language

“Task: Understanding Lock Levels” on page 217 .

SQL Request and Transaction Processing

(Publication number B035-1142-098A, available from http:// www.info.teradata.com

.) Chapter 9: “Locking and Transaction Processing”, sections

“Preventing Deadlocks” and “The LOCKING

Modifier in View Definitions”

“CREATE RECURSIVE VIEW/ REPLACE

RECURSIVE VIEW” in Chapter 4: “CREATE

PROCEDURE - CREATE ROLE” in SQL

Data Definition Language Syntax and

Examples

144 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 6: Creating Databases, Tables, and Views

Task 4: Using Scripts to Create Database Objects

Task 4: Using Scripts to Create Database

Objects

You can automate the creation of tables, views, and other database objects by using BTEQ scripts. You can write a BTEQ script which contains BTEQ commands and SQL statements for creating the tables and views. Then, you can invoke BTEQ with a script or batch file to send the SQL to Teradata Database. In addition, your BTEQ script can execute other files that contain BTEQ commands and SQL statements. For those who are familiar with Oracle, BTEQ scripts are similar to SQL*Plus scripts.

Procedure

The following procedure shows one way of using a BTEQ script to create the sample table from

“Task 2: Creating Tables” on page 126

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 Teradata Data Warehouse Appliance 2580 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.

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 145

Chapter 6: Creating Databases, Tables, and Views

Checkpoint

Reference Information

Information on...

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

Is available in...

“Procedure 2: Starting the Basic Teradata Query Utility” on page 129

“Running BTEQ Batch Jobs” in Chapter 3: “Using BTEQ” in

Basic Teradata Query Reference

Checkpoint

Before leaving Chapter 6: “Creating Databases, Tables, and Views,”

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

“Task 1: Creating Databases” on page 121

“Task 2: Creating Tables” on page 126 .

“Task 3: Creating Views” on page 140 .

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

146 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 7

Loading Data from an

ODBC-Compliant Database

You can move data from an ODBC-compliant database into Teradata Database tables using

Teradata Parallel Transporter (PT).

This section describes how to:

•

Create a job variables file that a Teradata PT load job script will use

•

Customize a sample load job script

•

Launch a Teradata PT job

•

Monitor and manage a Teradata PT job

•

Evaluate a completed Teradata PT job

•

Troubleshoot a failed job, if necessary

Required Tasks

The tasks in this section are required when using Teradata PT to load data from an ODBCcompliant database. Perform tasks 1, 2, 3, and 5 completely and in the order presented. Tasks 4 and 6 are optional depending on job conditions and outcome.

Prerequisites

The tasks and procedures in this section assume that the target table exists in Teradata

Database and that it is:

•

Empty

•

Has no join indexes, hash indexes, or secondary indexes

•

Has no foreign keys

For information on converting tables in an ODBC-compliant database to Teradata tables, see

“Procedure 1: Converting Existing Tables to Teradata Tables” on page 127 .

Teradata Data Warehouse Appliance 2580 Implementation Guide 147

Chapter 7: Loading Data from an ODBC-Compliant Database

Teradata PT Load Job Script

Teradata PT uses operators to execute extract and write functions within a single job script.

The following figure illustrates loading data from an Oracle database into Teradata Database 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

•

The ODBC operator, a producer operator, reads data from an external database and writes it to (“produces”) a data stream. The data stream consists of buffers in memory that temporarily hold the data.

•

The Load operator, a consumer operator, reads data from a data stream (“consumes it”) and then writes the data to an empty Teradata Database table as directed in a Teradata PT job script APPLY statement.

Sample Load Job Script

The following load job script reads data from the source Oracle Employee table and loads it into the Teradata Employee table.

For the definition of the sample source table, see

“Sample Source Table” on page 149

. For the definition of the sample target table, see

“Sample Target Table” on page 150 .

DEFINE JOB Data_LOAD

DESCRIPTION 'Loading data from an Oracle employee table into an empty

Teradata Database employee table'

(

DEFINE SCHEMA ODBC_Schema

(

Associate_Id DECIMAL(9,0),

Associate_Name VARCHAR(25),

Salary DECIMAL(8,2),

DOB VARCHAR(10),

Job_Title VARCHAR(25),

Dept_No DECIMAL(3,0),

Marital_Status CHAR(1),

No_Of_Dependents DECIMAL(2,0)

);

DEFINE OPERATOR ODBC_Operator

TYPE ODBC

SCHEMA ODBC_Schema

ATTRIBUTES

(

148 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Teradata PT Load Job Script

VARCHAR PrivateLogName = 'ODBC_log',

VARCHAR DSNName = @jobvar_datasourcename1,

VARCHAR UserName = @jobvar_ODBCusername1,

VARCHAR UserPassword = @jobvar_ODBCpassword1,

VARCHAR SelectStmt = 'Select

Associate_Id,

Associate_Name,

Salary,

TO_CHAR(DOB, ''YYYY-MM-DD'') AS DOB,

Job_Title,

Dept_No,

Marital_Status,

No_Of_Dependents

FROM employee;'

);

DEFINE OPERATOR Load_Operator

TYPE LOAD

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'Load_log',

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername1,

VARCHAR UserPassword = @jobvar_TDpassword1,

VARCHAR LogTable = 'employee_table_log_table',

VARCHAR TargetTable = 'Tables_Database.Employee'

);

APPLY

('INSERT INTO Tables_Database.Employee (

:Associate_Id,

:Associate_Name,

:Salary,

:DOB,

:Job_Title,

:Dept_No,

:Marital_Status,

:No_Of_Dependents );'

)

TO OPERATOR (Load_Operator)

SELECT *

FROM OPERATOR (ODBC_Operator);

);

Sample Source Table

The source Oracle table is defined with the following columns:

CREATE TABLE Employee (

Associate_Id NUMBER(9,0),

Associate_Name

Salary

DOB

Job_Title

Dept_No

Marital_Status

VARCHAR2(25),

NUMBER(8,2),

DATE,

VARCHAR2(25),

NUMBER(3,0),

CHAR,

No_Of_Dependents NUMBER(2,0));

Teradata Data Warehouse Appliance 2580 Implementation Guide 149

Chapter 7: Loading Data from an ODBC-Compliant Database

Create a Job Script

Sample Target Table

The data definition of the target Teradata table is as follows:

CREATE SET TABLE Tables_Database.Employee

(Associate_Id

Associate_Name

INTEGER,

CHAR(25),

Salary

DOB

Job_Title

Dept_No

DECIMAL(8,2),

DATE,

VARCHAR(25),

SMALLINT,

Marital_Status CHAR,

No_Of_Dependents BYTEINT)

UNIQUE PRIMARY INDEX (Associate_Id);

Reference Information

Information on...

the DEFINE JOB, DEFINE SCHEMA, DEFINE

OPERATOR, and APPLY statements describing job script format rules and the function of script components defining LOB data in a Teradata PT job script schema and loading Large Object (LOB) data into a Teradata Database using Teradata PT

Is available in...

Chapter 3: “Object Definitions and the APPLY

Statement” in Teradata Parallel Transporter

Reference

Chapter 2: “Teradata PT Job Components” in

Teradata Parallel Transporter User Guide

Chapter 26: “Advanced Teradata Database

Considerations” in Teradata Parallel Transporter

User Guide

Create a Job Script

Perform the following task to create a Teradata PT load job script.

Task 1: Define Job Variables

Define values for commonly used script components, such as operator attributes, as job variables to eliminate the need to re-specify the values in each new Teradata PT job script.

Note: Use of job variables also provides the means to make passwords secure in the variables file rather than leaving them in plain view in the job script.

When a job script specifies a variable, Teradata PT automatically reads the corresponding value from the job variables file.

150 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 1: Define Job Variables

Procedure: Create the Job Variables File

Execute the following procedure from a Teradata client configured with Teradata PT.

Use a text editor to create a local job variables file that contains a list of variables and their corresponding values.

Define variables for the following operator attributes shown in the

“Sample Load Job

Script” on page 148 . You may define additional variables as needed for your particular job

script.

Each job variable must be defined on a single line separated by commas, using the following format:

variable_name=value

ODBC Operator

Attribute

DSNName

UserName

UserPassword

Variable Name

jobvar_datasourcename1

Variable Value Description

The DSN name of the ODBC data source for the system that contains the source table.

jobvar_ODBCusername1 The name of the user with access privileges to the source table.

jobvar_ODBCpassword1 The password of the user with access privileges to the source table.

Load Operator

Attribute

TdpId

Variable Name

jobvar_tdpid

UserName

UserPassword jobvar_TDusername1 jobvar_TDpassword1

Variable Value Description

The name by which the Teradata Data

Teradata Data Warehouse Appliance 2580 is known to the network.

The Teradata user with access privileges to the target Teradata table.

The password of the Teradata user with access privileges to the target Teradata table.

Note: Some job variable names include a “1” to allow for creation of multiple variables of the same type.

Save the job variables file as a .txt file in the same directory from which you will save and run your Teradata PT load job script.

Teradata Data Warehouse Appliance 2580 Implementation Guide 151

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script

Example

The following shows the contents of a sample job variables file used with the sample load job script.

jobvar_datasourcename1='Oracle_Sys1', jobvar_ODBCusername1='andy4891', jobvar_ODBCpassword1='andyspasswd', jobvar_tdpid='Tdat3', jobvar_TDusername1='DBADMIN', jobvar_TDpassword1='passwd123'

Task 2: Customize the Sample Load Job Script

Teradata PT scripts are composed of two sections:

•

A declarative section (in the form of DEFINE statements) that identifies the job, the

Teradata PT operators, and the form of the data in the source table.

•

An executable section (in the form of an APPLY statement) that determines how the source data is applied to the target Teradata table.

The

“Sample Load Job Script” on page 148 includes all the elements required for a load job.

You can use the sample as a template and then customize it for your needs by substituting sitespecific values for the values shown in the sample.

To make the sample load job script site-specific, copy the script into a text editor, and edit it as described in the following procedures.

Note: Be sure to use the same format and punctuation as shown in the sample script.

Procedure 1: Specify the Declarative Section of the Load Job Script

The declarative section of the job script identifies the job and defines the Teradata PT components used to perform it.

Use the DEFINE JOB statement to provide a unique, user-defined name for this job script, as follows:

DEFINE JOB job_name

For example: DEFINE JOB Load_Employee_Data

The job name can also be used as the file name for the script.

Use the DESCRIPTION statement to describe the job in more detail and provide some idea of the script function. For example:

DESCRIPTION 'Loading data from an Oracle employee table into an empty

Teradata Database employee table'

Use DEFINE SCHEMA statements to define the structure of the source data for the producer operator and the consumer operator:

•

The DEFINE SCHEMA statement for the producer operator defines the columns of the source table.

152 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script

•

The DEFINE SCHEMA statement for the consumer operator defines the columns of the target Teradata table.

If the consumer operator can use the same schema as the producer operator, you only need to define the schema for the producer operator.

In the load job script example, the Oracle table columns and the Teradata table columns have the same names, and the data types are similar. Therefore, both the consumer operator and the producer operator can use the same schema, so you can define a single

DEFINE SCHEMA statement that defines the schema for the ODBC operator as follows:

DEFINE SCHEMA ODBC_Schema

(

Associate_Id DECIMAL(9,0),

Associate_Name VARCHAR(25),

Salary DECIMAL(8,2),

DOB VARCHAR(10),

Job_Title VARCHAR(25),

Dept_No DECIMAL(3,0),

Marital_Status CHAR(1),

No_Of_Dependents DECIMAL(2,0)

); where:

Syntax Element

DEFINE SCHEMA

schema_name

Description

schema_name is the user-defined name for the schema.

Recommendation: Make the name descriptive and unique so it can easily be reused in other scripts.

Teradata Data Warehouse Appliance 2580 Implementation Guide 153

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script

154

Syntax Element

( schema_specifications,

... );

Description

Specify each column of the schema on a single line in the form

column_name data_ type(size) where:

•

column_name specifies a column in the source table (this defines the schema for the producer operator)

•

data_ type(size) specifies the column data type and size.

Consider the following:

•

The (size) specification is optional.

•

data_type must be the Teradata data type that corresponds to the data type of the source table column.

For Oracle tables, see

“Teradata Data Types” on page 375

for examples of how some Oracle data types map to Teradata data types.

Note:

•

The NUMBER data type in Oracle corresponds to the

DECIMAL data type in Teradata.

Teradata also supports the BYTEINT, SMALLINT,

INTEGER, and BIGINT data types. However, these data types cannot be specified in a load job script when loading

Oracle NUMBER data into Teradata. You must specify

DECIMAL to represent NUMBER columns when defining the schema for your load job.

•

The Oracle DATE data type is different from the Teradata

DATE data type. You must specify VARCHAR(10) to represent Oracle DATE columns when defining the schema for your load job.

Use the DEFINE OPERATOR statement to define the producer operator (the ODBC operator), by customizing the following portion of the sample load job script.

Note: Operator attributes shown in the example are the minimum required specifications.

DEFINE OPERATOR ODBC_Operator

TYPE ODBC

SCHEMA ODBC_Schema

ATTRIBUTES

(

VARCHAR PrivateLogName = 'ODBC_log',

VARCHAR DSNName = @jobvar_datasourcename1,

VARCHAR UserName = @jobvar_ODBCusername1,

VARCHAR UserPassword = @jobvar_ODBCpassword1,

VARCHAR SelectStmt = 'Select

Associate_Id,

Associate_Name,

Salary,

TO_CHAR(DOB,”YYYY-MM-DD”) AS DOB,

Job_Title,

Dept_No,

Marital_Status,

No_Of_Dependents

FROM employee;'

);

Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script where:

Syntax Element

DEFINE OPERATOR

operator_name

Description

operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

TYPE operator_type

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: Specify ODBC.

SCHEMA schema_name

schema_name specifies the name of the schema used by the producer operator.

Recommendation: Specify the name given to the

ATTRIBUTES

(

attribute_specification

...

);

VARCHAR PrivateLogName =

'log_name',

Specify values for each attribute in the rows that follow.

'log_name'specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'ODBC_log'.

VARCHAR DSNName =

@jobvar_datasourcename1,

The DSNName attribute is assigned the value of the

jobvar_datasourcename1 variable as defined in the job variables file. See

File” on page 151

VARCHAR UserName =

@jobvar_ODBCusername1,

The UserName attribute is assigned the value of the

jobvar_ODBCusername1 variable as defined in the job variables file. See

File” on page 151

VARCHAR UserPassword =

@jobvar_ODBCpassword1,

The UserPassword attribute is assigned the value of the

jobvar_ODBCpassword1 variable as defined in the job variables file. See

file. See “Procedure: Create the Job Variables File” on page 151

File” on page 151

VARCHAR SelectStmt =

'SELECT...

FROM source_table_name;'

The SELECT statement selects data from the source table.

Note: Transformations of Oracle DATE data are necessary when loading Oracle DATE data into Teradata

Database. Use the Oracle TO_CHAR function to convert Oracle DATE data into character data with the format 'YYYY-MM-DD'. Teradata DATE columns accept this format.

Recommendation: Specify the source table name as a fully qualified table name in the form:

database_name.table_name

Teradata Data Warehouse Appliance 2580 Implementation Guide 155

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script

Use the DEFINE OPERATOR statement to define the consumer operator (the Load operator), by customizing the following portion of the sample load job script.

Note: Operator attributes shown in the example are the minimum required specifications.

DEFINE OPERATOR Load_Operator

TYPE LOAD

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'Load_log',

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername1,

VARCHAR UserPassword = @jobvar_TDpassword1,

VARCHAR LogTable = 'employee_table_log',

VARCHAR TargetTable = 'Tables_Database.Employee'

);

Syntax Element

DEFINE OPERATOR

operator_name

Description

The operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

TYPE operator_type

SCHEMA schema_name

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: Specify LOAD.

schema_name specifies the name of the schema used by the consumer operator.

In this load job script example, the consumer operator and the producer operator can use the same schema.

Therefore, specify * to indicate that the Load operator can use the same schema as the ODBC operator.

Specify values for each attribute in the rows that follow.

ATTRIBUTES

(

attribute_specification

...

);

VARCHAR PrivateLogName =

'log_name',

'log_name' specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'Load_log'.

VARCHAR TdpId =

@jobvar_tdpid,

VARCHAR UserName =

@jobvar_TDusername1,

The TdpId attribute is assigned the value of the

jobvar_tdpid variable as defined in the job variables

The UserName attribute is assigned the value of the

jobvar_TDusername1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 151 .

156 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script

Syntax Element

VARCHAR UserPassword =

@jobvar_TDpassword1,

VARCHAR LogTable =

'log_table_name'

VARCHAR TargetTable =

target_table_name

Description

The UserPassword attribute is assigned the value of the

jobvar_TDpassword1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 151 .

log_table_name specifies the name of the restart log table that stores checkpoint information.

Recommendation: Specify a name related to the job name or target table name.

target_table_name specifies the name of the Teradata

Database target table.

Recommendation: Specify the fully qualified name of the destination table, in the form:

database_name.table_name

Procedure 2: Code the Executable Section of the Load Job Script

The executable section of the job script contains the APPLY statement. It specifies all the operations performed by the job and the objects that perform them.

The APPLY statement consists of two sections:

•

APPLY...TO

•

SELECT...FROM

as shown in the following except from the sample job script:

APPLY

('INSERT INTO Tables_Database.Employee (

:Associate_Id,

:Associate_Name,

:Salary,

:DOB,

:Job_Title,

:Dept_No,

:Marital_Status,

:No_Of_Dependents);'

)

TO OPERATOR (Load_Operator)

SELECT *

FROM OPERATOR (ODBC_Operator);

);

Teradata Data Warehouse Appliance 2580 Implementation Guide 157

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 2: Customize the Sample Load Job Script

Code the APPLY...TO section as follows:

Syntax Element

('INSERT INTO target_table (

:column_name1,

...);'

)

TO OPERATOR (consumer_operator

_name)

Description

Specifies that the INSERT statement inserts the data into the Teradata target table where

target_table must be the same value as defined for the TargetTable attribute in the DEFINE

OPERATOR statement for the Load_Operator.

Recommendation: Specify the fully qualified name of the destination table, in the form:

database_name.table_name

consumer_operator _name specifies the name of the consumer operator that loads the data into the target table.

This must be the name given to the Load operator in the DEFINE OPERATOR statement.

Code the SELECT...FROM section as follows:

Syntax Element

SELECT *

FROM OPERATOR

(producer_operator_name);

);

Description

The consumer operator (Load operator) selects all the data from the producer operator named in the

FROM OPERATOR statement.

producer_operator_name specifies the name of the producer operator that extracts the data from the source table.

This must be the name given to the ODBC operator in the DEFINE OPERATOR statement.

Save the script with a .tpt extension in the same directory as the job variables file. See

“Procedure: Create the Job Variables File” on page 151

. The file name should be the name specified in the DEFINE JOB statement in

“Procedure 1: Specify the Declarative Section of the Load Job Script” on page 152 .

Reference Information

Information on...

the job variables used in Teradata PT sample scripts describing job script format rules and the function of script components

Is available in...

Appendix A: “Job Script Examples” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

158 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 3: Launch a Teradata PT Job

Information on...

the DEFINE JOB statement the DEFINE SCHEMA statement the ODBC operator the DEFINE OPERATOR and APPLY statements the Load operator the APPLY statement

Is available in...

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 11: “ODBC Operator” in Teradata Parallel

Transporter Reference

Chapter 15: “ODBC Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 9: “Load Operator” in Teradata Parallel

Transporter Reference

Chapter 13: “Load Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Task 3: Launch a Teradata PT Job

Use the tbuild command to launch a Teradata PT job.

Procedure: Specify tbuild Options and Launch a Teradata PT Job

In a Command window, navigate to the directory where your job script is stored.

Enter the following at the command prompt: tbuild -f filename -v job_variables_file jobname where:

Option or Parameter

-f filename

Specifies

The file name of the job script. The file name should use a .tpt extension.

If you are not executing the tbuild command in the directory where the job script is stored, filename must be a fully qualified pathname.

Teradata Data Warehouse Appliance 2580 Implementation Guide 159

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 4: Monitor and Manage a Teradata PT Job

Option or Parameter

-v job_variables_file

jobname

Specifies

The job variables file associated with the job script. See

“Procedure: Create the Job Variables File” on page 151

. The file name should use a .txt extension.

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 identifies the job.

You can use the name of the job as specified in the DEFINE

JOB statement of your job script, followed by a sequence number (such as a date stamp), that uniquely identifies the particular job. For example, load16Mar09.

The job name must be the last argument in the tbuild command line.

The screen will display an Exit Code when the job completes. For information on exit

codes, see “Procedure 1: Examine Exit Codes” on page 162

Reference Information

For step...

1, 2, 3

Information on...

the Teradata PT job file name

•

the tbuild -v option

•

other Teradata PT commands the Teradata PT jobname

Is available in...

Chapter 2: “Teradata PT Job Components” in

Teradata Parallel Transporter User Guide

Chapter 2: “Teradata PT Job Components” in

Teradata Parallel Transporter User Guide

Chapter 21: “Launching a Job” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Utility Commands” in

Teradata Parallel Transporter Reference

Chapter 21: “Launching a Job” in Teradata Parallel

Transporter User Guide

Task 4: Monitor and Manage 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.

•

The twbkill command allows you to stop a job.

160 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 4: Monitor and Manage a Teradata PT Job

Procedure 1: Pause and Resume 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...

the twbcmd command

Is available in...

Chapter : “Managing an Active Job” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Utility Commands” in Teradata

Parallel Transporter Reference

Procedure 2: View 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.

Procedure 3: Terminate 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

“Procedure 2: Examine the Teradata

PT Job Logs” on page 162

to make sure you understand the problem that led to the job termination.

Teradata Data Warehouse Appliance 2580 Implementation Guide 161

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 5: Evaluate a Completed Teradata PT Job

Reference Information

Information on...

the twbkill command

Is available in...

Chapter : “Managing an Active Job” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Utility Commands” in Teradata

Parallel Transporter Reference

Task 5: Evaluate a Completed Teradata PT Job

Procedure 1: Examine Exit Codes

Each Teradata PT job returns an exit code upon job completion, which indicates job success or failure.

Examine the job exit code, which 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 area of the script that generated the 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

“Procedure 2: Examine the Teradata PT Job Logs” on page 162 .

Procedure 2: Examine the Teradata PT Job Logs

Examine the job logs to understand the details of how the job executed, what warnings were issued, and if the job failed, which errors caused the failure.

162 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 5: Evaluate a Completed Teradata PT Job

Types of Log

Console

Public

Private

Explanation

The console log displays messages in the Command window where the tbuild command was issued.

This log contains high-level information about Teradata PT operators and infrastructure. It updates continuously while the job runs.

The public log contains general information about the job. Use the tlogview command to access this log.

The private log contains job performance metadata and a log of the activities and errors for each operator defined in the job. Use the tlogview command to access this log.

Procedure 3: Examine the Teradata PT Error Tables, If Applicable

Error tables provide information on Teradata Database errors encountered while writing data to the database, as well as detailed information about errors initially presented in the job logs.

If you have set error tables as attributes in your job script, examine the error tables. There are two types of error tables.

Error Table

Name of Table

Acquisition

Application

Explanation

Exports constraint violations, bad data, and data conversion errors

Contains any rows that cause violations of the unique primary index, for instance, duplicate rows.

This error table is not used when the target table has a nonunique primary index.

Reference Information

Information on...

exit codes job steps specifying checkpoint intervals accessing public job logs and how to read them, including example logs accessing private job logs and how to read them, including example logs

Is available in...

Chapter 23: “Post-Job Considerations” in Teradata

Parallel Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 21: “Launching a Job” in Teradata Parallel

Transporter User Guide

Chapter 23: “Post-Job Considerations” in Teradata

Parallel Transporter User Guide

Chapter 23: “Post-Job Considerations” in Teradata

Parallel Transporter User Guide

Teradata Data Warehouse Appliance 2580 Implementation Guide 163

Chapter 7: Loading Data from an ODBC-Compliant Database

Task 6: Troubleshoot a Failed Job, If Necessary

Information on...

accessing the error tables and how to read them, including example tables the tlogview command strategies for evaluating a successful job

Is available in...

Chapter 23: “Post-Job Considerations” in Teradata

Parallel Transporter User Guide

Chapter : “Managing an Active Job” in Teradata

Parallel Transporter User Guide

Chapter 2: “Teradata PT Utility Commands” in

Teradata Parallel Transporter Reference

Chapter 23: “Post-Job Considerations” in Teradata

Parallel Transporter User Guide

Task 6: Troubleshoot a Failed Job, If Necessary

Reference Information

Information on...

detecting and correcting the cause of failure common job failures and remedies operator-specific error handling debugging strategies for complex job failures restarting a job removing checkpoint files the notify exit routines

Is available in...

Chapter 24: “Troubleshooting a Failed Job” in Teradata

Parallel Transporter User Guide

Chapter 24: “Troubleshooting a Failed Job” in Teradata

Parallel Transporter User Guide

Chapter 24: “Troubleshooting a Failed Job” in Teradata

Parallel Transporter User Guide

Chapter 24: “Troubleshooting a Failed Job” in Teradata

Parallel Transporter User Guide

Chapter 24: “Troubleshooting a Failed Job” in Teradata

Parallel Transporter User Guide

Chapter 24: “Troubleshooting a Failed Job” in Teradata

Parallel Transporter User Guide

“Notify Exit Routines” in Chapter 25: “Notify Exit

Routines” in Teradata Parallel Transporter User Guide

164 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 7: Loading Data from an ODBC-Compliant Database

Checkpoint

Before leaving Chapter 7: “Loading Data from an ODBC-Compliant Database,” make sure

that:

√

Result

The data that was previously in another ODBCcompliant database is now in Teradata Database.

You evaluated the Teradata PT job and resolved any problems with it.

Reference

•

“Task 1: Define Job Variables” on page 150

•

“Task 2: Customize the Sample Load

Job Script” on page 152

•

“Task 4: Monitor and Manage a

•

Teradata PT Job” on page 160 .

•

Teradata PT Job” on page 162 .

•

Method: Teradata PT EasyLoader” on page 178

Necessary” on page 164 .

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 165

Chapter 7: Loading Data from an ODBC-Compliant Database

Checkpoint

166 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 8

Loading Data from a Flat File

You can move data from a client external flat file to the Teradata Database tables using

Teradata Parallel Transporter (PT).

Note: Teradata PT provides a command-line interface, called EasyLoader, for loading data from a client external file to the Teradata Data Warehouse Appliance 2580. See

“Alternate

This section describe how to:

•

Create a job variables file that a Teradata PT load job script will use

•

Customize the sample load job script

•

Launch a Teradata PT job

•

Monitor and manage a Teradata PT job

•

Evaluate a completed Teradata PT job

•

Troubleshoot a failed job, if necessary

Required Tasks

The tasks in this section are required when using Teradata PT to load data from an external flat file. Perform tasks 1, 2, 3, and 5 completely and in the order presented. Tasks 4 and 6 are optional depending on job conditions and outcome.

Prerequisites

The tasks and procedures in this section assume that the target table exists in Teradata

Database and that it is:

•

Empty

•

Has no join indexes, hash indexes, or secondary indexes

•

Has no foreign keys

Teradata Data Warehouse Appliance 2580 Implementation Guide 167

Chapter 8: Loading Data from a Flat File

Teradata PT Load Job Script

Teradata PT uses called operators to execute extract and write functions within job script.

The following figure illustrates loading data from a client external flat file into Teradata

Database 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

•

The DataConnector Operator, called a producer operator because it reads data from a flat file and writes it to (“produces”) a data stream. A data stream consists of buffers in memory that temporarily hold data.

•

The Load Operator, called a consumer operator because it reads data from a data stream

(“consumes it”) and then writes the data to an empty Teradata Database table.

Sample Load Job Script

The following load job script reads data from a binary format flat file and loads it into the

Teradata Employee table. For a sample flat file, see “Sample Employee Flat File” on page 169

Note: The sample flat file is a delimited format flat file. The following load job script loads a binary flat file.

DEFINE JOB DataFile_LOAD

DESCRIPTION 'Loading data from a binary format employee data file into an empty Teradata Database table'

(

DEFINE SCHEMA Employee_Schema

(

Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2)

DOB INTDATE,

Job_Title VARCHAR(25),

Dept_No

Marital_Status

SMALLINT,

CHAR(1),

No_Of_Dependents BYTEINT

);

DEFINE OPERATOR File_Reader

TYPE DATACONNECTOR PRODUCER

SCHEMA Employee_Schema

ATTRIBUTES

(

168 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Teradata PT Load Job Script

VARCHAR Format

VARCHAR OpenMode

);

VARCHAR PrivateLogName = 'DataConnector_log'

VARCHAR DirectoryPath = @jobvar_datafile_path,

VARCHAR FileName = 'employee_table.dat',

= 'binary',

= 'read'

DEFINE OPERATOR Load_Operator

TYPE LOAD

SCHEMA *

ATTRIBUTES

(

VARCHAR

VARCHAR TdpId

'Load_log'

= @jobvar_tdpid,

VARCHAR UserName

VARCHAR UserPassword

VARCHAR LogTable

VARCHAR TargetTable

);

= @jobvar_TDusername,

= @jobvar_TDpassword,

= 'employee_table_log_table'

= 'Tables_Database.Employee',

APPLY

('INSERT INTO Tables_Database.Employee (

:Associate_Id,

:Associate_Name,

:Salary,

:DOB,

:Job_Title,

:Dept_No

:Marital_Status,

:No_Of_Dependents );'

)

TO OPERATOR (Load_Operator)

SELECT *

FROM OPERATOR (File_Reader);

);

Sample Employee Flat File

The following is a sample delimited format flat file. The sample Teradata

PT load job script loads a binary format flat file into an empty Teradata Database table. It can also load a delimited format flat file.

10001|John Smith|93000.00|1954-10-21|Sr. Software Engineer|100|Y|5

10002|Mary Knotts|45000.00|1974-09-13|Secretary|100|Y|1

10005|Keith Muller|85000.00|1972-06-09|Sr. Software Engineer|100|Y|3

10021|David Crane|65000.00|1966-10-02|Technical Writer|101|Y|2

10022|Richard Dublin|60000.00|1965-03-19|Software Engineer|100|N|0

10023|Kelly 0'Toole|65000.00|1955-04-08|Software Tester|102|N|2

10024|Brett Jackson|75000.00|1962-04-08|Software Engineer|100|Y|2

10025|Erik Wickman|79000.00|1965-03-08|Software Engineer|100|N|2

Teradata Data Warehouse Appliance 2580 Implementation Guide 169

Chapter 8: Loading Data from a Flat File

Create a Job Script

Reference Information

Information on...

the DEFINE JOB, DEFINE SCHEMA,

DEFINE OPERATOR, and APPLY statements describing job script format rules and the function of script components

Is available in...

Chapter 3: “Object Definitions and the APPLY

Statement” in Teradata Parallel Transporter Reference

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Create a Job Script

Perform the following task to create a Teradata PT load job script.

Task 1: Define Job Variables

Define values for commonly used script component, such as operator attributes, as job variables to eliminate the need to re-specify the values in each new Teradata PT job script.

Note: Use of job variables also provides the means to make passwords secure in the variables file rather than leaving them in plain view in the job script.

When a job script specifies a variable, Teradata PT automatically reads the corresponding value from the job variables file.

Procedure: Create the Job Variables File

Execute the following procedure from a Teradata client configured with Teradata PT.

Use a text editor to create a local job variables file that contains a list of variables and their corresponding values.

Note: The following procedure assumes you have not yet created a job variables file. If you have, you can simply add job variables to it. A job variables file can contain job variables that multiple Teradata PT scripts use.

Define variables for the following operator attributes shown in the “Sample Load Job

Script” on page 168 . You may define additional variables as needed for your particular job

script.

Each job variable must be defined on a single line separated by commas, using the following format:

variable_name=value

170 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script

DataConnector

Operator

Attribute

DirectoryPath

Variable Name

jobvar_datafile_path

Variable Value Description

The path name of the flat file

Load Operator

Attribute

TdpId

Variable Name

jobvar_tdpid

UserName

UserPassword jobvar_TDusername1 jobvar_TDpassword1

Variable Value Description

The name by which the Teradata Data

Warehouse Appliance 2580 is known to the network.

The Teradata user with access privileges to the target Teradata table.

The password of the Teradata user with access privileges to the target Teradata table.

Note: Some job variable names include a “1” to allow for creation of multiple variables of the same type.

Save the job variables file as a .txt file in the same directory from which you will save and run your Teradata PT load job script.

Example

The following shows the contents of a sample job variables file used with the sample load job script.

jobvar_datafile_path='c:\employee_data', jobvar_tdpid='Tdat3', jobvar_TDusername1='DBADMIN', jobvar_TDpassword1='passwd123'

Task 2: Customize the Sample Load Job Script

Teradata PT scripts are composed of two sections:

•

A declarative section (in the form of DEFINE statements) that identifies the job, the

Teradata PT operators, and the form of the data in the source table.

•

An executable section (in the form of an APPLY statement) that determines how the source data is applied to the target Teradata table.

The

“Sample Load Job Script” on page 168 includes all the elements required for a load job.

You can use the sample as a template and then customize it for your needs by substituting sitespecific values for the values shown in the sample.

Teradata Data Warehouse Appliance 2580 Implementation Guide 171

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script

To make the sample load job script site-specific, copy the script into a text editor, and edit it as described in the following procedures.

Note: Be sure to use the same format and punctuation as shown in the sample script.

Procedure 1: Specify the Declarative Section of the Load Job Script

The declarative section of the job script identifies the job and defines the Teradata PT components used to perform it.

Use the DEFINE JOB statement to provide a unique, user-defined name for this job script, as follows:

DEFINE JOB job_name

For example: DEFINE JOB DataFile_LOAD

The job name can also be used as the file name for the script.

Use the DESCRIPTION statement to describe the job in more detail and provide some idea of the script function. For example:

DESCRIPTION 'Loading data from a binary format employee data file into an empty Teradata Database employee table'

Use DEFINE SCHEMA statements to define the structure of the source data for the producer operator and the consumer operator:

•

The DEFINE SCHEMA statement for the producer operator defines the records of the flat file.

•

The DEFINE SCHEMA statement for the consumer operator defines the columns of the target Teradata table.

If the consumer operator can use the same schema as the producer operator, you only need to define the schema for the producer operator.

In the load job script example, the records of the flat file and the Teradata table columns have the same names and the data types are similar. Therefore, both the consumer operator and the producer operator can use the same schema, so you can define a single

DEFINE SCHEMA statement that defines the schema for the DataConnector operator as follows:

DEFINE SCHEMA Employee_Schema

(

Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB INTDATE,

Job_Title VARCHAR(25),

Dept_No SMALLINT,

Marital_Status CHAR(1),

No_Of_Dependents BYTEINT

);

172 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script where:

Syntax Element

DEFINE SCHEMA schema_name

(

schema_specifications,

... );

Description

schema_name is the user-defined name for the schema.

Recommendation: Make the name descriptive and unique so it can easily be reused in other scripts.

Specify each record of the schema on a single line in the form record_name data_ type(size) where:

•

record_name specifies a record in the flat file (this defines the schema for the producer operator)

•

data_ type(size) specifies the record data type and size. Consider the following:

•

The (size) specification is optional.

•

data_type must be the Teradata data type that corresponds to the data type of the flat file.

Use the DEFINE OPERATOR statement to define the producer operator (the

DataConnector operator), by customizing the following portion of the sample load job script.

Note: Operator attributes shown in the example are the minimum required specifications.

DEFINE OPERATOR File_Reader

TYPE DATACONNECTOR PRODUCER

SCHEMA Employee_Schema

ATTRIBUTES

(

VARCHAR PrivateLogName = 'DataConnector_log',

VARCHAR DirectoryPath = @jobvar_datafile_path,

VARCHAR FileName

VARCHAR Format

VARCHAR OpenMode

);

= 'employee_table.dat',

= 'binary',

= 'read' where:

Syntax Element

DEFINE OPERATOR

operator_name

TYPE operator_type

Description

operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: For example: DATACONNECTOR

PRODUCER.

Teradata Data Warehouse Appliance 2580 Implementation Guide 173

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script

174

Syntax Element

SCHEMA schema_name

Description

schema_name specifies the name of the schema used by the producer operator.

Recommendation: Specify the name given to the

ATTRIBUTES

(

attribute_specification

);

...

VARCHAR PrivateLogName =

'log_name',

Specify values for each attribute in the rows that follow.

'log_name'specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'DataConnector_Log'.

VARCHAR DirectoryPath=

@jobvar_datafile_path,

VARCHAR FileName =

'file_name',

VARCHAR Format = 'format',

VARCHAR OpenMode = 'mode',

The DirectoryPassword attribute is assigned the value of the jobvar_datfile_path variable as defined in the job variables file. See

“Sample Employee Flat File” on page 169 .

File” on page 170

'file_name'specifies the name of the flat file.

Recommendation: For example:

'employee_table.dat'.

'format'specifies the format of the flat file.

Recommendation: If the flat file being load is a binary format file, specify

'binary'. If the flat file being loaded is a delimited format file, specify

'delimited 'and add the TextDelimiter attribute to the script, as follows:

VARCHAR TextDelimiter =

'delimiter'

, where

'delimiter'specifies the text delimiter the flat file uses. The delimiter of the sample flat file is the pipe

(“|”). See

'mode'specifies the read/write access mode of the flat file.

Recommendation: For example:

'read'.

Use the DEFINE OPERATOR statement to define the consumer operator (the Load operator), by customizing the following portion of the sample load job script.

Note: Operator attributes shown in the example are the minimum required specifications.

DEFINE OPERATOR Load_Operator

TYPE LOAD

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'Load_log',

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername1,

VARCHAR UserPassword = @jobvar_TDpassword1,

Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script

VARCHAR LogTable = 'employee_table_log',

VARCHAR TargetTable = 'Tables_Database.Employee'

);

Syntax Element

DEFINE OPERATOR

operator_name

TYPE operator_type

SCHEMA schema_name

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: Specify LOAD.

schema_name specifies the name of the schema used by the consumer operator.

In this load job script example, the consumer operator and the producer operator can use the same schema.

Therefore, specify * to indicate that the Load operator can use the same schema as the DataConnector operator.

Specify values for each attribute in the rows that follow.

ATTRIBUTES

(

attribute_specification

...

);

VARCHAR PrivateLogName =

'log_name',

VARCHAR TdpId =

@jobvar_tdpid,

'log_name' specifies the private log that contains all diagnostic trace messages produced by the operator.

Recommendation: Name the log for the operator, for example:

'Load_log'.

The TdpId attribute is assigned the value of the

jobvar_tdpid variable as defined in the job variables

file. See “Procedure: Create the Job Variables File” on page 170

VARCHAR UserName =

@jobvar_TDusername1,

Description

The operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

VARCHAR UserPassword =

@jobvar_TDpassword1,

The UserName attribute is assigned the value of the

jobvar_TDusername1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 170 .

The UserPassword attribute is assigned the value of the

jobvar_TDpassword1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 170 .

VARCHAR LogTable =

'log_table_name'

log_table_name specifies the name of the restart log table that stores checkpoint information.

Recommendation: Specify a name related to the job name or target table name.

Teradata Data Warehouse Appliance 2580 Implementation Guide 175

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script

Syntax Element

VARCHAR TargetTable =

target_table_name

Description

target_table_name specifies the name of the Teradata

Database target table.

Recommendation: Specify the fully qualified name of the destination table, in the form:

database_name.table_name

Procedure 2: Code the Executable Section of the Load Job Script

The executable section of the job script contains the APPLY statement. It specifies all the operations performed by the job and the objects that perform them.

The APPLY statement consists of two sections:

•

APPLY...TO

•

SELECT...FROM

as shown in the following except from the sample job script:

APPLY

('INSERT INTO Tables_Database.Employee (

:Associate_Id,

:Associate_Name,

:Salary,

:DOB,

:Job_Title,

:Dept_No,

:Marital_Status,

:No_Of_Dependents);'

)

TO OPERATOR (Load_Operator)

SELECT *

FROM OPERATOR (File_Reader);

);

Code the APPLY...TO section as follows:

Syntax Element

('INSERT INTO target_table (

:column_name1,

...);'

)

Description

Specifies that the INSERT statement inserts the data into the Teradata target table where

target_table must be the same value as defined for the TargetTable attribute in the DEFINE

OPERATOR statement for the Load_Operator.

Recommendation: Specify the fully qualified name of the destination table, in the form:

database_name.table_name

176 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Task 2: Customize the Sample Load Job Script

Syntax Element

TO OPERATOR (consumer_operator

_name)

Description

consumer_operator _name specifies the name of the consumer operator that loads the data into the target table.

This must be the name given to the Load operator in the DEFINE OPERATOR statement.

Code the SELECT...FROM section as follows:

Syntax Element

SELECT *

FROM OPERATOR

(producer_operator_name);

);

Description

The consumer operator (Load operator) selects all the data from the producer operator named in the

FROM OPERATOR statement.

producer_operator_name specifies the name of the producer operator that extracts the data from the source table.

This must be the name given to the DataConnector operator in the DEFINE OPERATOR statement.

Save the script with a .tpt extension in the same directory as the job variables file. See

“Procedure: Create the Job Variables File” on page 170

. The file name should be the name specified in the DEFINE JOB statement in

“Procedure 1: Specify the Declarative Section of the Load Job Script” on page 172 .

Reference Information

Information on...

the job variables used in Teradata PT sample scripts describing job script format rules and the function of script components the DEFINE JOB statement the DEFINE SCHEMA statement

Is available in...

Appendix A: “Job Script Examples” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Teradata Data Warehouse Appliance 2580 Implementation Guide 177

Chapter 8: Loading Data from a Flat File

Task 3: Launch a Teradata PT Job

Information on...

the DataConnector operator the DEFINE OPERATOR and APPLY statements the Load operator the APPLY statement

Is available in...

Chapter 4: “DataConnector Operator” in Teradata Parallel

Transporter Reference

Chapter 8: “DataConnector Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 9: “Load Operator” in Teradata Parallel

Transporter Reference

Chapter 13: “Load Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Task 3: Launch a Teradata PT Job

See

“Task 4: Monitor and Manage a Teradata PT Job” on page 160 .

Task 4: Monitor and Manage a Teradata PT Job

See

Task 5: Evaluate a Completed Teradata PT Job

See

“Task 5: Evaluate a Completed Teradata PT Job” on page 162

Task 6: Troubleshoot a Failed Job, If Necessary

See

“Task 6: Troubleshoot a Failed Job, If Necessary” on page 164 .

Alternate Method: Teradata PT EasyLoader

Teradata PT EasyLoader is a command-line interface to Teradata PT for loading data from a delimited format flat file into a Teradata Database table which does not require that you write a Teradata PT script.

178 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Alternate Method: Teradata PT EasyLoader

Required Tasks

The tasks in this section are required when using Teradata PT EZLoader to load data from an external flat file. Execute Tasks 1, 2, and 4 completely and in the order presented. Tasks 3 and 5 are optional depending on job conditions and outcome.

Prerequisites

The following applies:

•

The target table exists in Teradata Database and it is:

•

Empty

•

Has no join indexes, hash indexes, or secondary indexes

•

Has no foreign keys

•

The flat file must be a text file that contains character data in delimited format. See

“Sample Flat File” on page 183 .

•

The layout of the data records in the flat file must match that of the target table.

•

Unicode is not supported in the command line or in the job variables file.

The tdload Command

The Teradata PT EasyLoader command, tdload, has the following syntax: tdload job_options jobname where job_options are:

Option

-f filename

-t tablename

-u username

-p password

-h tdpid

Specifies

Required. The name of the flat file containing the data to be loaded.

If you are not executing the tdload command in the directory where the flat file is stored, filename must be a fully qualified flat file name.

Required. The name of the target table.

Note: If the target table resides in a database that is different from the default database of the specified Teradata user, you must also use the

--TargetWorkingDatabase option.

Required. The logon id of the Teradata user with access privileges to the target table.

The password of the specified Teradata user.

If the option is not specified, tdload will prompt you for a password.

The name by which the Teradata Data Warehouse Appliance 2580 is known to the network.

If the option is not specified, the default host name will be used.

Recommendation: Specify this option to make sure you are connecting to the correct system.

Teradata Data Warehouse Appliance 2580 Implementation Guide 179

Chapter 8: Loading Data from a Flat File

Alternate Method: Teradata PT EasyLoader

Option

-d ''delimiter_character'' The delimiter character used to separate the fields of the data records in a delimited format flat file.

Note: The default delimiter character is a comma ('',''). This is different from the usage in a Teradata PT script where the default delimiter character is the pipe character (''|''). You must specify this option if the delimiter character in your flat file is not a comma.

-j job_variables_file

Specifies

The name of the job variables file. See “Task 1: Define a Job Variables

File” on page 181

If you are not executing the tdload command in the directory where the job variables file is stored, job_variables_file must be a fully qualified filename.

-c character_set The character set encoding of the flat file. This option sets the client session character set.

Specify this option if the flat file is not an ASCII file.

where jobname is:

Option

jobname

Specifies

A unique name that identifies the load job.

Recommendation: Teradata strongly recommends that you specify names for your jobs when multiple load jobs are running simultaneously.

You can also specify these options using long option names with the (“--”) syntax as follows:

•

--SourceFileName filename

•

--TargetTable tablename

•

--TargetUserName username

•

--TargetUserPassword password

•

--TargetTdpId tdpid

•

--SourceTextDelimiter

delimiter_character

In addition, the following options are also available:

Option

--help

--TargetWorkingDatabase database_name

Specifies

The display of detailed help usage text.

The database where the target table is located.

Note: This option is required if the target table resides in a database that is different from the default database of the specified Teradata user.

180 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Alternate Method: Teradata PT EasyLoader

Option

--TargetAccountId accountid

Specifies

The account associated with the specified

Teradata user.

The following options are used to optimize job performance:

Option

--TargetMaxSessions number

--TargetMinSessions number

--LoadInstances number

--FileInstances number

--TargetErrorLimit number

Specifies

The maximum sessions to be used in the load job.

The default value is 32.

The minimum sessions to be used in the load job.

The default value is 1.

The number of instances used to load data.

The default value is 1.

The number of instances used to read the data file.

The default value is 1.

The maximum errors allowed in data records.

When the number of errors encountered exceeds this number, the load job terminates.

The default value is 1.

Reference Information

Information on...

delimited format files determining the optimum number of sessions and instances error limits

Is available in...

“Format” in “Key Specifications” in Chapter 8:

“DataConnector Operator” in Teradata Parallel Transporter

User Guide

“Optimizing Job Performance with Sessions and Instances” in Chapter 3: “Teradata Database Effects on Job Scripts” in

Teradata Parallel Transporter User Guide

“Effects of Error Limits” in Chapter 23: “Post-Job

Considerations” in Teradata Parallel Transporter User Guide

Task 1: Define a Job Variables File

Instead of entering the options on the command line, you may specify any of them in a job variables file.

Use a text editor to create a local job variables file that contains a list of variables and their corresponding values.

Teradata Data Warehouse Appliance 2580 Implementation Guide 181

Chapter 8: Loading Data from a Flat File

Alternate Method: Teradata PT EasyLoader

Execute the following procedure from a Teradata client configured with Teradata PT.

Procedure

Use a text editor to create a job variables file that contains a list of options and their corresponding values to be used with Teradata PT EasyLoader. Each job variable must be defined on a single line separated by commas, using the following format:

option = value where:

Syntax Element

option value

Explanation

A single-letter or a multi-letter (long) option.

Note: The option name is case-sensitive.

An integer or a character string.

You must enclose character strings within apostrophes (single quotation marks).

Save the job variables file as a .txt file in the same directory as your data file. If you save the job variables file in a different directory, you will need to specify the full file name of the job variables file in the -j option when executing tdload.

Example

The following shows the contents of a sample job variables file for a Teradata PT EasyLoader job.

SourceFileName = 'employee_data.txt', u = 'dbadmin',

TargetUserPassword = 'tdpasswd5', h = 'tdat1',

TargetWorkingDatabase = 'Tables_Database',

TargetTable = 'Employee',

SourceTextDelimiter = '|',

TargetMaxSessions = 6

Task 2: Launch a Teradata PT EasyLoader Job

Procedure

Follow these steps to launch a Teradata PT EasyLoader job.

In a Command window, navigate to the directory where your data file is stored.

Enter the tdload command at the command prompt. For example: tdload -f filename -u username -p password -h tdpid -t tablename

The screen will display the Job Id for the load job.

182 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 8: Loading Data from a Flat File

Alternate Method: Teradata PT EasyLoader

Example 1

The following tdload command loads data from the emp_data.txt file into the

Tables_Database.Employee table. The name of the load job is EmpLoadJob.

tdload -f emp_data.txt -u dbadmin -p pw123 -h tdat1 -t employee -d ''|'' --

TargetWorkingDatabase Tables_Database EmpLoadJob

Example 2

The following example uses the empload_jobvars job variables file that this example assumes has specified all job options associated with the Teradata PT EasyLoader job in Example 1.

Using the -j option eliminates the need to type the options when executing tdload.

tdload -j empload_jobvars.txt

Sample Flat File

The following shows the contents of a flat file with data in delimited format. The delimiter character is the pipe(''|''). Teradata PT EasyLoader can only load a delimited format flat file.

The schema of this file matches the schema of the Teradata Employee table used in the other

Teradata PT job examples.

10001|John Smith|93000.00|1954-10-21|Sr. Software Engineer|100|Y|5

10002|Mary Knotts|45000.00|1974-09-13|Secretary|100|Y|1

10005|Keith Muller|85000.00|1972-06-09|Sr. Software Engineer|100|Y|3

10021|David Crane|65000.00|1966-10-02|Technical Writer|101|Y|2

10022|Richard Dublin|60000.00|1965-03-19|Software Engineer|100|N|0

10023|Kelly 0'Toole|65000.00|1955-04-08|Software Tester|102|N|2

10024|Brett Jackson|75000.00|1962-04-08|Software Engineer|100|Y|2

10025|Erik Wickman|79000.00|1965-03-08|Software Engineer|100|N|2

Task 3: Monitor and Manage a Teradata PT EasyLoader Job

You can monitor and manage a Teradata PT EasyLoader job just as you monitor and manage a

Teradata PT job. See

“Task 4: Monitor and Manage a Teradata PT Job” on page 160 .

Task 4: Evaluate a Completed Teradata PT EasyLoader Job

You can evaluate a completed Teradata PT EasyLoader job just as you evaluate a Teradata PT

job. See “Task 5: Evaluate a Completed Teradata PT Job” on page 162 .

Task 5: Troubleshoot a Failed Teradata PT EasyLoader Job, If Necessary

You can troubleshoot a failed Teradata PT EasyLoader job just as you troubleshoot a Teradata

PT job. See “Task 6: Troubleshoot a Failed Job, If Necessary” on page 164

Teradata Data Warehouse Appliance 2580 Implementation Guide 183

Chapter 8: Loading Data from a Flat File

Checkpoint

Before leaving Chapter 8: “Loading Data from a Flat File,” make sure that:

√

Result

The data that was previously in a client external flat file is now in Teradata Database.

You evaluated the Teradata PT job and resolved any problems with it.

Reference

•

“Task 1: Define Job Variables” on page 170

•

“Task 2: Customize the Sample Load

Job Script” on page 171

•

“Task 3: Launch a Teradata PT Job” on page 178

•

“Task 4: Monitor and Manage a

Teradata PT Job” on page 178 .

•

Teradata PT Job” on page 178 .

•

“Task 9: Convert Sequential Processing to Set Processing” on page 193 and

Necessary” on page 178 .

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

184 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 9

Migrating SQL to Teradata

When converting SQL to Teradata SQL, you will need to address a number of differences between your current database and Teradata. The following topics list some main differences, but the list is not exhaustive, and the section primarily uses Oracle as an example.

Always test your converted queries thoroughly before putting the queries to work in 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 take your SQL as written and translate it one-for-one to Teradata

SQL. However, you will not be taking advantage of all the benefits that Teradata provides. You should try to understand the rules and requirements of your overall business process, and migrate your logic and business rules instead of migrating your code. For more information, see

“Task 10:

Convert PL/SQL Functions” on page 196

Task 1: Convert Data Types to Teradata Data

Types

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

Database. However, you will need to convert some data types to Teradata data types. For details, see

“Teradata Data Types” on page 375 .

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 passed to macros, procedures, and SQL functions such as SQRT.

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 185

Chapter 9: Migrating SQL to Teradata

Task 2: Convert Built-in SQL Functions

Reference Information

Information on...

Teradata data types converting data from one type to another including:

•

implicit type conversions

•

explicit type conversions using CAST

Is available in...

“Teradata Data Types” on page 375 .

SQL Data Types and Literals

Chapter 1: “SQL Data Definition”

SQL Functions, Operators, Expressions, and

Predicates

Chapter 17: “Data Type Conversions”

Task 2: Convert Built-in SQL Functions

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 your built-in function with an equivalent Teradata SQL function.

•

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

•

Create a user-defined function (UDF) that provides the same functionality as your built-in function.

•

Translate the function into Teradata SQL and save the query as a procedure.

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

For example, 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. On the Teradata Download Center Teradata provides user-defined functions (UDFs) that emulate the most commonly used Oracle built-in SQL functions. After you install these UDFs, when Teradata Database encounters a call to an Oracle built-in SQL function, it will invoke the corresponding UDF to process the function call. For more information about UDFs, see

“User-Defined Functions” on page 387 .

The UDFs from the Teradata Download Center emulate the following Oracle built-in functions:

•

ADD_MONTHS

•

ASCII

•

CEIL

•

CHR

•

DECODE

•

FLOOR

•

GREATEST

•

INITCAP

•

INSTR

•

LAST_DAY

•

LEAST

•

LENGTH

•

LPAD

•

LTRIM

•

MONTHS_BETWEEN

•

NVL

•

REPLACE

•

ROUND

•

RPAD

•

RTRIM

•

SIGN

•

TO_CHAR

•

TO_DATE

•

TO_NUMBER

•

TRANSLATE

•

TRUNC

186 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Task 2: Convert Built-in SQL Functions

IMPORTANT: Teradata Corporation does not support these UDFs. Although the UDFs are proven to work in many situations, Teradata 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 are responsible for testing the UDF results against the Oracle function results to ensure that the UDFs work as expected for their applications. Teradata provides these UDFs only as a convenience to our customers.

Procedure 1: Installing the Teradata UDFs for Oracle

Before you begin, your system must have a C or C++ compiler on the node that Teradata uses to compile the UDFs.

Go to the Teradata Download Center, available from the Support & Downloads link at http://www.teradata.com

and download the ZIP file containing the Oracle UDFs.

Open the ZIP file and extract the files, entering 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.

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

Procedure 2: Using the Teradata UDFs for Oracle

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 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)

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 187

Chapter 9: Migrating SQL to Teradata

Task 2: Convert Built-in SQL Functions

Oracle

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])

TRUNC

MONTHS_BETWEEN(d,e)

Reference Information

Teradata

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'] )

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

Is available in...

“User-Defined Functions” on page 387 .

“Procedures and External Procedures” on page 385

SQL Functions, Operators, Expressions, and Predicates

Chapter 1: “Introduction”

SQL Functions, Operators, Expressions, and Predicates

Chapter 14: “Built-In Functions”

SQL Functions, Operators, Expressions, and Predicates

Chapter 2: “CASE Expressions”

SQL Functions, Operators, Expressions, and Predicates

Chapter 3: “Arithmetic Operators and Functions /

Trigonometric and Hyperbolic Functions”

SQL Functions, Operators, Expressions, and Predicates

Chapter 10: “String Operator and Functions”

188 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Task 3: Convert Hierarchical Joins

Information on...

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...

SQL Functions, Operators, Expressions, and Predicates

Chapter 12: “Attribute Functions”

“CHARACTER_LENGTH”

SQL Functions, Operators, Expressions, and Predicates

Chapter 17: “Data Type Conversions”

“CAST in Explicit Data Type Conversions”

Chapter 10: “Data Type Formats and Format Phrases” in

SQL Data Types and Literals

Task 3: Convert Hierarchical Joins

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

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

For example, the following shows a hierarchical query in Oracle. 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

)

WHERE Employee_Id ^= 801

ORDER BY Employee_Id;

You would code 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;

Teradata Data Warehouse Appliance 2580 Implementation Guide 189

Chapter 9: Migrating SQL to Teradata

Task 4: Convert Outer Joins

Reference Information

Information on...

recursive queries

Is available in...

“Recursive Queries”in Chapter 3: “SQL Data Definition,

Control, and Manipulation” in SQL Fundamentals

WITH [RECURSIVE] Request Modifier “WITH [RECURSIVE] Request Modifier”in Chapter 1:

“The SELECT Statement” in SQL Data Manipulation

Language

Task 4: Convert Outer Joins

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

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

This example shows a left outer join. The query returns a sorted report of department IDs and names of the people that work in those departments. All of the employees will appear in the list. If the Dept_ID of an employee is not present in the Department table, then the Dept_ID shown for that employee will be null in the report.

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

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;

However, Oracle also supports an older outer join syntax:

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.

Reference Information

Information on...

outer joins

Is available in...

“Outer Joins”in Chapter 2: “Join Expressions” in SQL

Data Manipulation Language

190 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Task 5: Check the Use of NULLs in Queries

In Teradata Database, nulls are neither values nor do they signify values. They represent the absence of a value. A null is a place holder indicating that no value is present. However, an empty string ('') is a real value in Teradata. Therefore, the keyword NULL is not the same as an empty string.

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, using SQL Assistant, the output from the SELECT statement 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...

“NULL Keyword as a Literal”in Chapter 2: “Basic SQL Syntax and

Lexicon” in SQL Fundamentals

“Manipulating Nulls”in Chapter 4: “SQL Data Handling” in SQL

Fundamentals

“Character String Literals”in Chapter 2: “Data Literals” in SQL

Data Types and Literals

Task 6: Convert Nested Aggregate Operations

Aggregate operations cannot be nested in Teradata Database.

For example, in Oracle, the following is valid:

SELECT MIN(SUM(…))

Teradata Data Warehouse Appliance 2580 Implementation Guide 191

Chapter 9: Migrating SQL to Teradata

Task 7: Convert External Tables to Table Functions

In Teradata, you must use syntax such as:

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

However, 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

Chapter 8: “Aggregate Functions”

SQL Functions, Operators, Expressions, and Predicates

Chapter 9: “Ordered Analytical Functions”

Task 7: Convert External Tables to Table

Functions

For Oracle users, External Tables in Oracle must be converted to Table Functions in Teradata

Database. A table function is a type of UDF. It is invoked in the FROM clause of an SQL

SELECT statement and 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...

“User-Defined Functions” on page 387

192 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Task 8: Convert Queue Tables

Teradata queue tables have the operational benefits of high availability, scalability, reliability, recoverability, and security that Teradata provides to standard tables.

The queue tables supported in your current database probably have similar functionality, but there may be differences in the way they are created and 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 your queue table requirements and management into Teradata queue tables and processes.

Reference Information

Information on...

using queue tables syntax and options for creating queue tables manipulating data in queue tables using:

•

INSERT (push)

•

SELECT AND CONSUME (pop)

•

SELECT (peek)

•

DELETE, UPDATE, or MERGE

Is available in...

“CREATE TABLE (Queue Table Form)” in Chapter 5:

“CREATE TABLE” in SQL Data Definition Language

Syntax and Examples

“CREATE TABLE (Queue Table Form)” in Chapter 5:

“CREATE TABLE” in SQL Data Definition Language

Syntax and Examples

Chapter 1: “The SELECT Statement” in SQL Data

Manipulation Language

Chapter 3: “SQL Data Manipulation Language

Statement Syntax” in SQL Data Manipulation Language

Task 9: Convert Sequential Processing to Set

Processing

When migrating your SQL to Teradata SQL, you should review it in the context of the complete stream of SQL processes to gain an understanding of the overall business process it is supporting.

Often, business processes are broken into multiple, simple SQL that utilize row-at-a-time cursor processing. While this style of application coding is simpler to write, it is not always the most efficient way to implement a process. This type of processing does not leverage set processing or parallelism, and instead results in the relational database behaving more like a file processing program that reads a record, acts on the record, and writes the record.

Teradata Data Warehouse Appliance 2580 Implementation Guide 193

Chapter 9: Migrating SQL to Teradata

Task 9: Convert Sequential Processing to Set Processing

The Teradata Database parallel architecture excels when it can perform parallel processing on

SQL queries instead of serial processing. Parallel processing allows Teradata to update sets of rows simultaneously. This is much more efficient than updating rows one at a time using cursors.

When migrating or developing your queries, use SQL constructs that take advantage of the parallel processing power of Teradata. For example:

Instead of using...

IF statements nested loops nested procedures or functions

Use...

CASE operations or predicates joins joins or subqueries

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 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 is a serial operation which causes the INSERTs into the Gen_Ledger table to occur one row at a time.

194 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Task 9: Convert Sequential Processing to Set Processing 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';

END IF;

INSERT INTO Gen_Ledger (Amount, Acct, DDate)

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

END LOOP;

END;

The SQL can be rewritten using a CASE statement, which allows multiple rows to be processed simultaneously.

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'

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 195

Chapter 9: Migrating SQL to Teradata

Task 10: Convert PL/SQL Functions

The SQL can be rewritten using a subquery, which allows multiple rows to be processed 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

Chapter 2: “CASE Expressions”

SQL Functions, Operators, Expressions, and Predicates

Chapter 1: “Introduction”

“SQL Predicates”

Chapter 2: “Join Expressions” in SQL Data Manipulation Language

“Subqueries” in Chapter 3: “SQL Data Definition, Control, and

Manipulation” in SQL Fundamentals

Task 10: Convert PL/SQL Functions

For Oracle users, you can migrate PL/SQL (Procedure Language SQL) to Teradata by taking the SQL as written, translating it to Teradata SQL, and embedding it into the proper vehicle for query execution. However, because PL/SQL is typically written to do row-at-a-time, cursor-based processing, this does not take advantage of the set processing features available

in Teradata. See “Task 9: Convert Sequential Processing to Set Processing” on page 193 .

Because Teradata can process complex, large, relational requests in parallel, it may be possible to convert multiple PL/SQL processes to just a few Teradata SQL statements or procedures. As a consequence, more data manipulation can be performed in a single SQL request than in single PL/SQL processes. This can result in large savings in data processing time and resources because the data are being manipulated in fewer passes and in parallel.

Therefore, although you can convert PL/SQL one-for-one to Teradata, considering and treating the whole of the business process being migrated can result in more efficient relational processing and less SQL code to maintain.

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 the query as a procedure or macro.

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

196 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Task 11: Other SQL Application Considerations

Reference Information

Information on...

set processing

Is available in...

“Task 9: Convert Sequential Processing to Set Processing” on page 193 .

UDFs

“User-Defined Functions” on page 387

Procedures and External Procedures

“Procedures and External Procedures” on page 385

creating and using macros

“Procedure 4: Choosing a Primary Index” on page 136 .

Task 11: Other SQL Application Considerations

•

Teradata will not use a primary index or unique secondary index 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 only in ANSI session mode. This function is not valid 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 opened. Any attempt to close a cursor that is already closed will result 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 the 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:

•

Verify that all of the ODBC functions in your application are supported by Teradata

ODBC.

•

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 197

Chapter 9: Migrating SQL to Teradata

Task 11: Other SQL Application Considerations

Reference Information

Information on...

indexing

•

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

Is available in...

“Task 3: Using Secondary and Join Indexes” on page 228 .

SQL Stored Procedures and Embedded SQL

Chapter 3: “SQL Cursor Control and DML

Statements”

ORDER BY clause

Teradata Database reserved words naming database objects

Unicode support

BTEQ scripts

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

“Session Modes and Transaction Processing” on page 204 .

“COMMIT” in Chapter 3: “SQL Data Manipulation

Language Statement Syntax” in SQL Data

Manipulation Language

“ORDER BY Clause” in Chapter 1: “The SELECT

Statement” in SQL Data Manipulation Language

Appendix B: “Restricted Words” in SQL

Fundamentals

“Names” in Chapter 2: “Basic SQL Syntax and

Lexicon” in SQL Fundamentals

International Character Set Support

(Publication number B035-1125-098A, available from http://www.info.teradata.com

Chapter 4: “Server Character Sets”

“UNICODE Server Character Set”

“Task 4: Using Scripts to Create Database Objects” on page 145

Chapter 7: “Loading Data from an ODBC-

Compliant Database.”

Chapter 8: “Loading Data from a Flat File.”

ODBC Driver for Teradata User Guide

Chapter 4: “ODBC Application Development”

198 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 9: Migrating SQL to Teradata

Checkpoint

Before leaving Chapter 9: “Migrating SQL to Teradata,” 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.

Hierarchical queries are rewritten in Teradata

SQL syntax.

Queries with outer joins are rewritten in

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

“Task 1: Convert Data Types to Teradata

Data Types” on page 185 .

“Task 2: Convert Built-in SQL

Functions” on page 186

“Task 3: Convert Hierarchical Joins” on page 189

“Task 4: Convert Outer Joins” on page 190

“Task 5: Check the Use of NULLs in

Queries” on page 191

“Task 6: Convert Nested Aggregate

Operations” on page 191 .

“Task 7: Convert External Tables to

Table Functions” on page 192

“Task 8: Convert Queue Tables” on page 193

“Task 9: Convert Sequential Processing to Set Processing” on page 193 .

“Task 10: Convert PL/SQL Functions” on page 196 .

“Task 11: Other SQL Application

Considerations” on page 197

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 199

Chapter 9: Migrating SQL to Teradata

Checkpoint

200 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 10

Using the Database

Required Tasks

The tasks presented in this section are not specifically required, but represent best practices for using the database. For best results, you should read and consider the information presented.

The tasks that apply to your implementation can be performed in any order.

Task: Creating 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 201

Chapter 10: Using the Database

Task: Creating SQL Queries

Reference Information

Information on...

•

SQL procedures (procedures that are written using SQL statements)

•

external procedures (procedures that are written using C, C++, or Java) embedded SQL

Is available in...

“Procedures and External Procedures” on page 385 .

using dynamic SQL with embedded applications using dynamic SQL in SQL procedures

BTEQ scripts triggers macros

SQL Stored Procedures and Embedded SQL

Chapter 1: “Introduction”

“Embedded SQL Overview”

SQL Stored Procedures and Embedded SQL

Chapter 10: “Dynamic Embedded SQL Statements”

SQL Stored Procedures and Embedded SQL

Chapter 5: “SQL Stored Procedures”

“Using Dynamic SQL in Stored Procedures”

“Task 4: Using Scripts to Create Database Objects” on page 145

“Triggers” on page 388 .

“Procedure: Executing Multiple SQL Statements in Parallel” on page 209

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.

The way you specify a multistatement request depends on the application you are using to submit your 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;

202 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Creating SQL Queries

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 statements as a single request. See

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.

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...

“Multistatement Requests” in Chapter 4: “SQL Data

Handling” in SQL Fundamentals

“Using Teradata SQL in BTEQ” in Chapter 3: “Using

BTEQ” in Basic Teradata Query Reference

“Task: Submitting a Query Using SQL Assistant” on page 208

“Entering and Executing Queries” in Chapter 2: “The

Query Window” in Teradata SQL Assistant for Microsoft

Windows User Guide

Teradata Data Warehouse Appliance 2580 Implementation Guide 203

Chapter 10: Using the Database

Task: Creating SQL Queries

Session Modes and Transaction Processing

Teradata Database supports two session modes:

•

ANSI

•

Teradata

In ANSI session mode:

•

Transaction processing adheres to the rules defined by the ANSI SQL:2008 standard. This is similar to how other relational database systems operate.

•

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

“Differences Between

Teradata and ANSI SQL” on page 207

•

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 has several defaults that differ in important ways from the ANSI semantics.

•

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

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

“Differences Between Teradata and ANSI SQL” on page 207

•

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 where 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.

204 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Creating SQL Queries

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 the 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

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 only specify a DDL statement if it is the last statement in the series immediately followed by an END

TRANSACTION.

If an error occurs, it is treated as a failure and 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 205

Chapter 10: Using the Database

Task: Creating SQL Queries

Setting the Session Mode

A system parameter specifies the default transaction mode for a site. However, you can override the default for a session. To set the transaction processing mode, use 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 modes

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 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...

SQL Request and Transaction Processing

(Publication number B035-1142-098A, available from http://www.info.teradata.com

Chapter 9: “Locking and Transaction Processing”

“Transactions, Requests, and Statements”

SQL Request and Transaction Processing

(Publication number B035-1142-098A, available from http://www.info.teradata.com

Chapter 9: “Locking and Transaction Processing”

“Transaction Semantics: Operating in ANSI or

Teradata Session Modes”

Chapter 3: “SQL Data Manipulation Language

Statement Syntax” in SQL Data Manipulation

Language

Chapter 12: “DBS Control (dbscontrol)” in

Utilities: Volume 1 (A-K)

“SESSION TRANSACTION” in Chapter 5: “BTEQ

Commands” in Basic Teradata Query Reference

“Teradata ODBC Driver Options” in “Obtaining

Dialog Box Information” in Chapter 3:

“Configuration for Microsoft Windows” in ODBC

Driver for Teradata User Guide

“Defining a .Net Data Provider for Teradata Data

Source” in “Defining a Data Source” in Chapter 1:

“Getting Started” in Teradata SQL Assistant for

Microsoft Windows User Guide

206 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Creating SQL Queries

Differences Between Teradata and ANSI SQL

Teradata tries to conform to the ANSI SQL standard whenever possible. However, to bring innovative features and capabilities to our users, Teradata has also developed SQL language elements that do not conform to the ANSI SQL standard. In many cases, a standard did not exist when those features were conceived.

In terms of standards conformance, the Teradata SQL features will fall into one of the following categories:

•

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

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

Teradata adheres to the following policy to achieve a balance between conforming to standards and providing continuing support to existing customers whose applications rely on the Teradata SQL dialect:

•

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

•

If the difference between the Teradata SQL dialect and the ANSI SQL standard for a language 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 standard and Teradata

ANSI and Teradata session modes

Is available in...

Appendix E: “What is New in Teradata SQL” in SQL

Fundamentals

“Terminology Differences Between ANSI SQL and

Teradata” in Appendix D: “ANSI SQL Compliance” in

SQL Fundamentals

“Session Modes and Transaction Processing” on page 204

Teradata Data Warehouse Appliance 2580 Implementation Guide 207

Chapter 10: Using the Database

Task: Submitting a Query Using SQL Assistant

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 “Procedure 2: Starting the Basic Teradata Query Utility” on page 129

, “Task 4: Using Scripts to Create Database Objects” on page 145

, and

“Appendix

C Advanced Features” on page 385 .

Prerequisites

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

•

Microsoft .NET Framework. See

“Task 3: Install Microsoft .NET Framework” on page 78

•

.NET Data Provider for Teradata. See “Task 1: Review Software and Installation Types” on page 74

•

ODBC Driver for Teradata. See “Task 9: Create ODBC Data Sources” on page 84 for

instructions on defining a Teradata data source, which SQL Assistant will use to access the database.

Procedure: Executing a Query Using SQL Assistant

To start Teradata SQL Assistant, select:

Start > Programs > Teradata Client > Teradata SQL Assistant

208 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Submitting a Query Using 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 created in

“Procedure 1: Set up a Teradata Data Source” on page 84

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).

Procedure: 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).

For Step...

Information on...

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

Is available in...

“Setting Query Options” in “Using the Query

Window” in Chapter 2: “The Query Window” in

Teradata SQL Assistant for Microsoft Windows User

Guide

“Setting Code Editor Options” in “Using the Query

Window” in Chapter 2: “The Query Window” in

Teradata SQL Assistant for Microsoft Windows User

Guide

“Single and Multistatement Requests” on page 202

Teradata Data Warehouse Appliance 2580 Implementation Guide 209

Chapter 10: Using the Database

Commonly Used Queries

The most commonly used and useful SQL queries include:

•

SELECT

•

INSERT

•

UPDATE

•

DELETE

A brief overview of each with examples follows. For more details, including the complete syntax, see SQL Data Manipulation Language.

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);

INSERT Statement

To add a new row to a table, use the INSERT statement. To perform a bulk insert of rows by retrieving the new row data from another table, use the INSERT … SELECT form of the statement.

210 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Commonly Used Queries

Example 1: INSERT Request

The following INSERT request creates a local instance of the global temporary table definition 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

The following INSERT...SELECT request copies all the rows from table t3 and inserts them into table t1:

INSERT t1 SELECT * from t3;

UPDATE Statement

To modify data in one or more rows of a table, use the UPDATE statement. In the UPDATE statement, you 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;

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);

Teradata Data Warehouse Appliance 2580 Implementation Guide 211

Chapter 10: Using the Database

Task: Creating Macros

Reference Information

Information on...

the SELECT statement the INSERT, UPDATE, and DELETE statements

Is available in...

Chapter 1: “The SELECT Statement” in SQL Data

Manipulation Language.

Chapter 3: SQL Data Manipulation Language

Statement Syntax” in SQL Data Manipulation

Language.

Task: Creating 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 “Task 1: Creating Databases” on page 121

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

“Procedures and External Procedures” on page 385 and “Differences Between Macros and

Procedures” on page 385

212 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Creating Macros

Procedure: Creating Macros in BTEQ

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

•

BTEQ

•

SQL Assistant

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

Database. For a comparison of BTEQ and SQL Assistant, see “Task: Submitting a Query Using

SQL Assistant” on page 208 .

The following procedure shows how to create macros using BTEQ:

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

the Basic Teradata Query Utility” on page 129 .

“Procedure 2: Starting

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

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

Explanation

The name of the database where the macro 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 “Task 1: Creating Databases” on page 121

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

The name of the macro to be created. The macro 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 213

Chapter 10: Using the Database

Task: Creating Macros

Syntax Element

SQL statement

Explanation

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.

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

REPLACE MACRO statement.

Syntax Element

data_type_attributes

USING 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.

214 Teradata Data Warehouse Appliance 2580 Implementation Guide

Example

Chapter 10: Using the Database

Task: Creating Macros

Syntax Element

LOCKING modifier

Explanation

Specifies the type of lock to be placed on a database, table, view, or row hash referenced by the subsequent SQL statement. Any object that is referenced by a request is locked until the macro transaction is completed.

Recommendation: Use the 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

“Task: Understanding Lock

Levels” on page 217 .

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

Create Database Objects” on page 145

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 12: “Managing Database Users,”

for information about granting privileges on the macro to users.

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 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 215

Chapter 10: Using the Database

Task: Creating Macros

CREATE MACRO Views_Database.New_Employee

(Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB DATE,

Job_Title

Dept_No

VARCHAR(25),

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 have created 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 and options for:

•

CREATE MACRO/REPLACE MACRO

•

RENAME MACRO

•

DROP MACRO

•

required privileges for macros executing macros the default database data types and data type attributes

Is available in...

“Macros” in Chapter 2: “Populating the Database” in

Database Administration

“Macros” in Chapter 1: “Objects” in SQL Fundamentals

SQL Data Definition Language

Chapter 3: “CREATE HASH INDEX - CREATE ORDERING”

“CREATE MACRO/ REPLACE MACRO”

SQL Data Definition Language

Chapter 3: “CREATE HASH INDEX - CREATE ORDERING”

“CREATE MACRO/ REPLACE MACRO”

“EXECUTE (Macro Form)” in Chapter 3: “SQL Data

Manipulation Language Statement Syntax” in SQL Data

Manipulation Language

SQL Fundamentals

Chapter 2: “Basic SQL Syntax and Lexicon”

“Default Database”

“Teradata Data Types” on page 375

SQL Data Types and Literals

Chapter 1: “SQL Data Definition”

216 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Understanding Lock Levels

For step...

Information on...

2 USING request modifier

LOCKING request modifier optimizing tactical query performance by using macros

Is available in...

“USING Request Modifier” in Chapter 3: “SQL Data

Manipulation Language Statement Syntax” in SQL Data

Manipulation Language

“Task: Understanding Lock Levels” on page 217

“Macros and Tactical Queries” in “Application Opportunities for Tactical Queries” in Chapter 17: “Design Issues for

Tactical Queries” in Database Design

Task: Understanding 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 217

Chapter 10: Using the Database

Task: Understanding Lock Levels

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.

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.

218 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Understanding Lock Levels

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

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 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

lock_level object_name lock_severity

NOWAIT

Explanation

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).

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.

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 219

Chapter 10: Using the Database

Task: Understanding Lock Levels

220

Syntax Element

SQL_request

Explanation

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

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 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

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

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 ...

Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 10: Using the Database

Task: Understanding Lock Levels

Monitoring and Managing Locking

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

•

EXPLAIN request modifier

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

•

Lock Display (lokdisp) and Locking Logger (dumplocklog) utilities

These utilities allow you to review all the active locks and analyze lock contention issues between concurrent SQL statements. The Locking Logger application in Teradata Manager provides a graphical user interface to the Locking Logger console utility.

•

Performance Monitor (PMON) of Teradata Manager

You can view the Session Status Report to determine which sessions are blocking other sessions and why.

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 using the Lock Display (lokdisp) utility to display all active database locks

Is available in...

“Managing Locks” in Chapter 8: “Protecting Data” in

Database Administration

SQL Request and Transaction Processing

(Publication number B035-1142-098A, available from http://www.info.teradata.com

Chapter 9: “Locking and Transaction Processing”

“LOCKING Request Modifier” in Chapter 3: “SQL

Data Manipulation Language Statement Syntax” in

SQL Data Manipulation Language

“Guidelines for Changing Default Locks

Assignments...” in Chapter 9 “Locking and

Transaction Processing” in SQL Data Manipulation

Language.

“SET SESSION CHARACTERISTICS AS

TRANSACTION ISOLATION LEVEL” in Chapter 8:

“END LOGGING - SET TIME ZONE” in SQL Data

Definition Language

“SET SESSION CHARACTERISTICS AS

TRANSACTION ISOLATION LEVEL” in Chapter 8:

“END LOGGING - SET TIME ZONE” in SQL Data

Definition Language

“Task 3: Creating Views” on page 140

“Task 2: Analyzing Query Plans Using the EXPLAIN

Request Modifier” on page 227

Chapter 3: “Lock Display (lokdisp)” in Utilities:

Volume 2 (L-Z)

Teradata Data Warehouse Appliance 2580 Implementation Guide 221

Chapter 10: Using the Database

Checkpoint

Information on...

using the Locking Logger application in

Teradata Manager to analyze lock contention issues between concurrent SQL statements using Performance Monitor (PMON) of

Teradata Manager to determine which sessions are blocking other sessions

Is available in...

“Task: Investigating Lock Contentions” on page 295

“Task: Using Performance Monitor” on page 284

Checkpoint

Before leaving Chapter 10: “Using 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.

Reference

“Task: Creating SQL Queries” on page 201

“Session Modes and Transaction

Processing” on page 204

“Differences Between Teradata and

ANSI SQL” on page 207 .

“Task: Submitting a Query Using SQL

Assistant” on page 208 .

“Task: Understanding Lock Levels” on page 217

You can create macros in BTEQ and SQL

Assistant.

•

You understand the default lock levels in

Teradata Database.

•

You know how to change default lock levels.

•

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

Teradata.

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

222 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 11

Optimizing Tables and Queries

After creating and populating your tables, Teradata recommends that you optimize your tables and queries before putting them to work in a production environment.

Required Tasks

The tasks and procedures presented in this section are strongly recommended and should be performed completely and in the order shown in

Task Overview .

Task Overview

Perform these steps to tune your tables and queries for optimal performance:

Collect statistics on the populated tables.

Run sample queries, and use the EXPLAIN request modifier to analyze index access and the query plans.

Optimize indexes and queries based on the EXPLAIN analysis:

•

Rewrite the queries to reduce resource impact.

•

Create or revise indexes. Drop unused indexes.

Collect or recollect statistics.

If you made optimization changes, rerun your queries to measure any performance differences.

Repeat

step 2 through step 5

until you are satisfied with the query results and performance.

Reference Information

For Step...

1, 5

Information on...

collecting statistics the EXPLAIN request modifier system performance related to various SQL operations

Is available in...

“Task 1: Optimizing Query Performance Using

COLLECT STATISTICS” on page 224

“Task 2: Analyzing Query Plans Using the

EXPLAIN Request Modifier” on page 227

Chapter 8: “System Performance and SQL” in

Performance Management

Teradata Data Warehouse Appliance 2580 Implementation Guide 223

Chapter 11: Optimizing Tables and Queries

Task 1: Optimizing Query Performance Using COLLECT STATISTICS

For Step...

Information on...

4 creating and optimizing indexes

Is available in...

“Task 3: Using Secondary and Join Indexes” on page 228 .

Task 1: Optimizing Query Performance Using

COLLECT STATISTICS

To ensure that the Optimizer has access to current information about how best to optimize any query or update made to the database, use the COLLECT STATISTICS statement to collect statistics regularly on all indexed columns, all frequently joined columns, and all columns frequently specified in query predicates.

Procedure: Collecting Statistics

Start Teradata Manager and enter the following in the Logon Information dialog:

•

System (DBS) Name = the name by which the Teradata Data Warehouse Appliance

2580 is known to the local area network.

•

Username and Password = DBCMANAGER or any other Teradata Manager user, and the associated password.

•

Profile = the DEFAULT profile, or other profile associated with this user.

•

Server options = Get data from Server, where Server Name is the name of the machine that is running the Teradata Manager Windows service. For information

about the Teradata Manager Windows service, see “Task 2: Install the Teradata

Manager Service” on page 76 .

Click Administer>Statistics Collection.

In the left navigation pane of the Statistics Collection window, double-click the database that contains the table for which you want to collect statistics. For example, the Tables_Database under DBADMIN.

The Statistics Collection window will show Teradata Database statistics in three windows:

•

The Database window shows a tree view of the databases.

•

The Tables window shows the tables in the selected database.

•

The Columns window shows the columns/indexes for the selected table.

In the Table window, double-click the table for which you want to collect statistics.

The columns of the selected table are displayed in the Columns window.

You may collect statistics on one or more databases, tables, or table columns. In one of the windows (Database, Tables or Columns), select the items you want to collect statistics for, and right-click on the item.

From the pop-up menu, select a Collect Statistics option.

224 Teradata Data Warehouse Appliance 2580 Implementation Guide

Usage

Chapter 11: Optimizing Tables and Queries

Task 1: Optimizing Query Performance Using COLLECT STATISTICS

Note: For details on Statistics Collection using Teradata Manager, click on the Help menu of the Statistics Collection window.

Recommendation: Collect statistics at the following phases of table development:

•

Newly created, unpopulated tables (make sure you recollect statistics after data is added).

The purpose of collecting statistics on unpopulated tables is to set up the interval histogram used in internal processing. Setting this up now makes subsequent statistics collections faster.

•

Prototype phase: the table is now populated.

•

Production phase (after a significant percentage change to the table).

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).

At minimum, you should collect statistics for the primary index of each table.

For best results, collect statistics on the following:

•

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 a table or join index with partitioning)

After collection, maintain statistics to reflect accurately the data demographics of the underlying tables. During query processing, the Optimizer estimates comparative costs to determine the best query plan. The Optimizer does not require or accept pragmas or hints.

The decisions are based solely on the current demographics of the database. Therefore, maintaining fresh statistics is very important in order for the Optimizer to generate the most efficient query plans.

Recommendation: Recollect statistics if there is 10% or more change (rows added or deleted) in the table or within a partition of a table that is partitioned. For high volumes of very nonunique values, such as dates and timestamps, it may be better to recollect at 7%.

It is better to have no statistics than stale statistics. When no statistics are available, the system dynamically determines data demographics using a random AMP sample. The Optimizer performs a quick analysis of the data demographics on a single, random AMP. This small sample is not as comprehensive or accurate as the statistics obtained by running COLLECT

STATISTICS; however, it is better than using old, inaccurate statistics.

The Optimizer can extrapolate statistics on rolling columns. A rolling column has a constant number of rows per value and a varying number of unique values, for example, DATE or

TIMESTAMP columns. Using extrapolation, the Optimizer obtains a reasonable estimate for rows that were added since statistics were last collected.

Teradata Data Warehouse Appliance 2580 Implementation Guide 225

Chapter 11: Optimizing Tables and Queries

Task 1: Optimizing Query Performance Using COLLECT STATISTICS

Determining If Your Statistics Are Stale

Your statistics can be considered stale if any of the following have changed significantly:

•

The number of rows in the table (10% or more).

The number of unique values for each column in a table and the date and time the statistics were last gathered can be obtained by:

HELP STATISTICS tablename;

•

The range of values for a column.

Sometimes you can infer this from the date and time the statistics were last collected or by the nature of the column (for instance, if the column holds a transaction date and the statistics on that column were last gathered a year ago).

•

The number of rows per value (on average or for a subset of values).

Note: The Optimizer does have some mechanisms for detecting and ignoring stale statistics.

Considerations

Collecting full statistics often involves a full-table scan and may take a significant amount of time. Therefore, collect statistics off-hours for large tables. You can also collect statistics on a sampled subset of table rows instead of all the rows for a table.

Collecting statistics for the system-derived column PARTITION is usually very fast and should be done after loading data into a partition.

You can drop statistics if your current statistics are stale, but you do not want to recollect them because of resource usage considerations. In that case, the Optimizer automatically does a random AMP sample to gather new statistics when it processes a query that needs those statistics.

Reference Information

For Step...

Information on...

database administration and collecting statistics administering statistics collection using Teradata Manager syntax and options for the

COLLECT STATISTICS statement

Is available in...

“Collecting Optimizer Statistics” in Chapter 11:

“Recommended Housekeeping Tasks” in

Database Administration

Statistics Collection online help in Teradata

Manager.

“COLLECT STATISTICS (Optimizer Form)” in

Chapter 1: “ALTER FUNCTION - COMMENT” in SQL Data Definition Language Syntax and

Examples

“COLLECT STATISTICS (Optimizer Form)” in

Chapter 1: “ALTER FUNCTION - COMMENT” in SQL Data Definition Language Detailed Topics

226 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 11: Optimizing Tables and Queries

Task 2: Analyzing Query Plans Using the EXPLAIN Request Modifier

Task 2: Analyzing Query Plans Using 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 a request. The request itself is not processed.

Note: To EXPLAIN a request, you must have the privileges that are required to execute that request.

Procedure: Using EXPLAIN with SQL Assistant

In the SQL Assistant Query window, enter the SQL query to be EXPLAINed.

Press F6.

Procedure: Using EXPLAIN with BTEQ

✔

Add the word “EXPLAIN” before the SQL request.

For example, the following performs an EXPLAIN on the SELECT statement:

EXPLAIN SELECT * FROM Employee;

Usage

EXPLAIN is extremely useful for designing new queries and optimizing existing 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 that will be used

•

any intermediate spool files that will be generated

•

the types of join to be performed

•

whether the requests in a transaction will be dispatched in parallel

•

the relative time it will take to complete the request

This permits you to code a query in different ways, and to compare the relative performance of the different versions so that you can write the most efficient SQL code.

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 while at the same time producing the identical end result.

You can also use EXPLAIN interactively to catch queries that are consuming too many

resources. See “Task 1: Finding and Aborting Queries” on page 301 .

Teradata Data Warehouse Appliance 2580 Implementation Guide 227

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

Reference Information

For Step...

Information on...

all syntax and options for the

EXPLAIN request modifier all interpreting the output of the EXPLAIN request modifier

1, 2 using EXPLAIN with SQL

Assistant

Is available in...

“EXPLAIN Request Modifier” in Chapter 4: “Query and

Workload Analysis DML Statements” in SQL Data

Manipulation Language

Chapter 5: “Interpreting the Output of the EXPLAIN

Request Modifier” in SQL Request and Transaction

Processing

(Publication number B035-1142-098A, available from http://www.info.teradata.com

“Displaying an Explain Plan of Your Query” in Chapter 2:

“The Query Window” in Teradata SQL Assistant for

Microsoft Windows User Guide

Task 3: Using Secondary and Join Indexes

Indexes enhance data access by providing a more-or-less direct path to the data, thereby avoiding full-table scans to locate the small number of rows you typically want to retrieve or update.

Because full-table scans in Teradata Database are highly efficient due to the Teradata parallel architecture, you may not need to assign many indexes to a table to get the performance you need. After you create primary indexes, it is a good idea to evaluate how your system performs for a few months before creating other indexes. However, if you do require improved performance beyond what the primary index offers, consider adding secondary or join indexes to your tables. Teradata Database also supports hash indexes, which offer functionality similar to single-table join indexes, but using a different syntax.

You can create a maximum mix of 32 secondary, join, and hash indexes for one table. (Note that each multicolumn nonunique secondary index (NUSI) created with an ORDER BY clause counts as two consecutive indexes against the maximum of 32 indexes.)

Teradata will not use a primary index or unique secondary index (USI) unless all of the indexed columns are in the predicate. Partial index access is supported for join indexes and for some NUSIs.

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 processing of a query by reducing (but not entirely eliminating) the need to access the base tables.

228 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

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 an 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 in the following situations:

•

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.

•

For query plans where the SI completely or partially covers the query.

•

To facilitate aggregate operations.

•

For optimizing repetitive and standardized queries.

•

To improve system performance in decision support environments.

Recommendation: Use secondary indexes for decision support applications that return multiple rows by design because they often provide superior performance to full-table scans.

You can create secondary indexes when you create the table (see “Task 2: Creating Tables” on page 126

), or you can add them later using the CREATE INDEX statement. Unlike primary indexes, secondary indexes can be dropped and created at will without altering the table they index. You can create or drop the secondary indexes as data usage changes, or if they are found not to be 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 Data Warehouse Appliance 2580 Implementation Guide 229

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

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.

Procedure 1: Creating Secondary Indexes

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

•

BTEQ

•

SQL Assistant

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

Database. For a comparison of BTEQ and SQL Assistant, see “Task: Submitting a Query Using

SQL Assistant” on page 208 .

The following procedure shows how to create indexes using BTEQ:

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

the Basic Teradata Query Utility” on page 129 .

“Procedure 2: Starting

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:

Syntax Element

UNIQUE

index_name index_column_ name

Explanation

Specifies that no two rows in the table can have the same value or combination of values in the indexed fields.

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 231 .

230 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

Syntax Element

database_name table_name

Explanation

The name of the database where table_name is located if it is different from the current database. The database should be located within the

Tables_Database.

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 Chapter 3: “CREATE HASH INDEX - CREATE ORDERING” in

SQL Data Definition Language Syntax and Examples.

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;

Choosing a Secondary Index

When assigning columns to be a secondary index for a table, the most important factor to consider is the selectivity of the index. An index that retrieves few rows is said to be 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 their selectivity.

Teradata Data Warehouse Appliance 2580 Implementation Guide 231

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

You can use the Teradata Index Wizard client utility to assist your selection of 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.

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

•

Select columns that are not volatile. Avoid columns that are frequently updated.

•

Avoid columns with uneven distributions 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.

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. In Oracle, join indexes are called Materialized Views.

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.

232 Teradata Data Warehouse Appliance 2580 Implementation Guide

Example

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

Join indexes provide flexibility in defining the primary index. 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.

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:

Teradata Data Warehouse Appliance 2580 Implementation Guide 233

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

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);

Weighing the Costs and Benefits of Secondary and Join Indexes

Secondary and join indexes provide many benefits:

•

Lower CPU usage

•

Greater concurrency

•

Faster response times for queries

Perhaps not so obvious are the disadvantages of using these indexes:

•

Indexes must be updated every time a row is updated, deleted, or added to a table.

This is only a consideration for nonprimary indexes. 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.

•

Disk space consumption

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.

Procedure 2: Validating and Maintaining Indexes

After you design your indexes and queries and after you have run your workloads for a while

(at least 30 days), it is extremely important that you test your indexes to ensure that they are being used as planned, and you are receiving the benefits you expect.

Perform the following steps regularly to verify and maintain your indexes:

Collect statistics so that the Optimizer has the current column demographics to select the

appropriate indexes when processing a query or update. See “Task 1: Optimizing Query

Performance Using COLLECT STATISTICS” on page 224 .

You can use the Teradata Statistics Wizard client utility at regular intervals to recommend which columns and indexes you may need to collect statistics on for particular query workloads. The Statistics Wizard also recommends when statistics should be recollected on those columns.

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.

234 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 11: Optimizing Tables and Queries

Task 3: Using Secondary and Join Indexes

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 never 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.

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 syntax and options for:

•

CREATE INDEX

•

DROP INDEX

•

CREATE JOIN INDEX

•

DROP JOIN INDEX

Is available in...

Chapter 10: “Data Distribution and Data Access Methods” in

Introduction to Teradata

“Indexes” in Chapter 2: “Populating the Database” in

Database Administration

“Indexes” in Chapter 1: “Objects” in SQL Fundamentals

“CREATE INDEX” in Chapter 3 “CREATE HASH INDEX -

CREATE ORDERING” in SQL Data Definition Language

Syntax and Examples

“CREATE JOIN INDEX” in Chapter 3 “CREATE HASH

INDEX - CREATE ORDERING” in SQL Data Definition

Language Syntax and Examples

“DROP INDEX” in Chapter 7 “DATABASE - DROP USER” in

SQL Data Definition Language Syntax and Examples

“DROP JOIN INDEX” in Chapter 7 “DATABASE - DROP

USER” in SQL Data Definition Language Syntax and Examples

Teradata Data Warehouse Appliance 2580 Implementation Guide 235

Chapter 11: Optimizing Tables and Queries

Checkpoint

Information on...

using indexes collecting and maintaining accurate database statistics

Teradata Statistics Wizard client utility

EXPLAIN request modifier

Visual Explain client utility

Teradata Index Wizard client utility

Is available in...

Chapter 9: “Teradata Database Indexes: The Basics” in

Database Design

“CREATE TABLE” in Chapter 5: “CREATE TABLE” in SQL

Data Definition Language Detailed Topics

“Task 1: Optimizing Query Performance Using COLLECT

STATISTICS” on page 224 .

Teradata Statistics Wizard User Guide

(Publication number B035-2503-088A, available from http:// www.info.teradata.com

Chapter 7: “Database Foundations for the Teradata Index and

Statistics Wizards” in SQL Request and Transaction Processing

(Publication number B035-1142-098A, available from http:// www.info.teradata.com

“Task 2: Analyzing Query Plans Using the EXPLAIN Request

Modifier” on page 227

Teradata Visual Explain User Guide

(Publication number B035-2504-088A, available from http:// www.info.teradata.com

Teradata Index Wizard User Guide

(Publication number B035-2506-088A, available from http:// www.info.teradata.com

Chapter 7: “Database Foundations for the Teradata Index and

Statistics Wizards” in SQL Request and Transaction Processing

(Publication number B035-1142-098A, available from http:// www.info.teradata.com

Checkpoint

Before leaving Chapter 11: “Optimizing Tables and Queries,” make sure that:

√

Result

You collected statistics on tables.

You know how to use the EXPLAIN request modifier to analyze query plans.

Reference

“Task 1: Optimizing Query

Performance Using COLLECT

STATISTICS” on page 224

“Task 2: Analyzing Query Plans Using the EXPLAIN Request Modifier” on page 227

236 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 11: Optimizing Tables and Queries

Checkpoint

√

Result

You know how to implement secondary and join indexes and have considered their costs and benefits.

Reference

“Task 3: Using Secondary and Join

Indexes” on page 228 .

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 237

Chapter 11: Optimizing Tables and Queries

Checkpoint

238 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 12

Managing Database Users

This section presents the administrative tasks required to create users, provide them the privileges necessary for their activity in the database, and log database activity.

Required Tasks

Perform all the tasks in this section completely and in the order presented.

Task 1: Assessing User Needs

The following list identifies five basic user types and the minimum privileges they require to work in the database.

•

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 that may perform some general user functions and who also need to insert, update or delete data, and to create new database objects. This group of users can include database programmers.

•

Batch users: High-level users who typically perform batch-level functions, such as:

•

Load, update, and export operations, including creating and deleting tables.

•

Data backup, archive, and restore operations.

•

Assistant administrator users: Administrative users that assist the principal administrator,

user DBADMIN, created in Chapter 4, “Procedure 2: Create User DBADMIN” on page 107 . 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.

•

Database programmer users: Programmers often have the task of creating databases, tables, and other database objects for use by the user community. They may require administrative-level privileges within a development database, while needing only limited privileges on the created objects after they are deployed to a production database.

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 239

Chapter 12: Managing Database Users

Task 1: Assessing User Needs

Procedure: Assessing 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 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.

•

Define user accounting requirements for use in specifying one or more account strings.

Each profile can include one or more accounts. Each account can specify:

•

A priority level (low, medium, high, and rush)

•

A four-character account identifier based on such things as department, group, and function.

•

A date and time stamp

•

Define the user default database.

•

Define password control parameters. Refer to “Setting Password Controls” in Chapter

6: “Creating and Managing Passwords,” in Security Administration. Consider your site security policy and decide whether or not all users can share global password parameters, or if you need to set them in individual user 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 database privileges at the highest level that is appropriate for a particular user. For example, if a user requires the same privileges on all views in a database, assign privileges at the database level.

Identify groups of users with common database privilege requirements and create roles to define the privileges for each group. Consolidate minor differences in access requirements where possible to minimize the number of roles.

Reference Information

For Step...

Information on...

1 syntax and options for the CREATE

USER statement types of users in Teradata Database

Is available in...

“CREATE USER” in Chapter 6: “CREATE

TRANSFORM - CREATE VIEW” in SQL

Data Definition Language Syntax and

Examples

“Types of Users” in Chapter 3: “Users, Roles, and Profiles” in Database Administration

240 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 2: Creating Profiles

For Step...

Information on...

database objects and their function database privileges, including those conferred by object ownership the use of roles in managing user privileges syntax and options for GRANT (Role form) allocating space global temporary tables

Is available in...

Chapter 2: “Populating the Database” in

Database Administration

Chapter 1: “Teradata Database Privileges” in

SQL Data Control Language

“Using Roles to Manage Privileges” in

Chapter 3: “Users, Roles, and Profiles” in

Database Administration

“GRANT (Role Form)” in Chapter 2: “SQL

Data Control Language Statement Syntax” in

SQL Data Control Language

Chapter 4: “Space” in Database

Administration

“Denormalizing Through Global Temporary and Volatile Tables” in Chapter 8:

“Denormalizing the Physical Schema” in

Database Design

Task 2: Creating Profiles

You can create profiles to define resource parameters for groups of users with similar needs instead of defining them for each individual user. Then list the profile in a CREATE or

MODIFY USER statement to establish membership in a profile for each user.

Profiles can be based on the primary user types such as those shown in “Task 1: Assessing User

Needs” on page 239

, or other factors that group users according to database resource requirements.

Use profiles to specify the following for profile members (users):

•

Permanent and spool space allocations

•

User account(s)

•

Password control parameters

•

Default database assignment

User Accounts

Each user logon to the database should specify a user account string.

Accounts can used by the database to:

•

Manage workloads

•

Monitor resource usage

•

Assign priority to work

•

Charge for space or resources used

Teradata Data Warehouse Appliance 2580 Implementation Guide 241

Chapter 12: Managing Database Users

Task 2: Creating Profiles

Teradata recommends, but does not require, that you specify at least one user account in each user profile. Users with similar responsibilities and resource requirements should be assigned to the same account(s) to reduce the overall number of accounts you must maintain.

Determining the Session Account

The account for a user is invoked by the database when the user logs on as follows:

•

Specify user accounts in:

•

A CREATE USER or MODIFY USER statement.

•

A CREATE PROFILE or MODIFY PROFILE statement for the profile specified in the user definition.

Note: If a user is a member of a profile that specifies one or more accounts, the profile account assignments supersede and invalidate all accounts specified in the user definition.

•

If the user is assigned only one account, the logon uses that account by default.

•

If the user is assigned multiple accounts and the default account (the first listed in the operant user or profile definition) is appropriate for the session, the logon need not contain the account string.

•

If the user has multiple accounts and does not want to use the default, the logon string can specify another assigned account.

•

During a session, the user can submit a SET SESSION ACCOUNT statement to change the session to another assigned account.

•

If the user has no account assignment, the session defaults to the first account listed for the owning user or database. Such a use of default owner accounts is not recommended.

Reference Information

Information on...

specifying the account string at logon accounts

Is available in...

•

“Command Line Logons” in Chapter 5: “Logon

Requirements and Controls” in Security Administration

•

The logon section in the User Guide for a particular Teradata tool or utility.

Chapter 7: “Sessions and Accounts” in Database Administration

Account String Structure

Teradata recommends that you devise an account system and then identify the accounts required for various groups in the user community before attempting to specify account information in user profiles. An account string is limited to 30 characters in length.

User account strings should follow this format:

‘$G0+account_ID&S&D&H’

242 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 2: Creating Profiles

Note: If a CREATE or MODIFY statement specifies more than one account string, the individual strings must be separated by commas and the entire list of strings enclosed by parentheses.

where:

Element

Required Account String Variables

Description

$G0+

account_ID

Optional. The performance group identifier. Priority scheduler uses the identifier to determine the priority of the session.

Recommendation: Specify one of the following in place of

$G0+:

•

$R0+ = Rush

•

$H0+ = High

•

$M0+ = Medium (default)

•

$L0+ = Low

Note: Consider the following when specifying the performance group.

•

The 0 specification designates resource partition 0, the default and only partition allowed on Teradata 255x.

•

The + character is a place holder that forces the account_ID to start at the fifth character, which is important for compatibility with certain administrative tools.

The account name. Uniquely identifies the account.

Recommendation: You can use the four characters of the

account_ID to differentiate accounts and to provide an abbreviated description of the account function.

For example:

•

to designate a company department, such as finance (FIN) or marketing (MKT)

•

to designate a job function, such as general use (G), update

(U), or batch processing (B).

A complete account ID might resemble one of the following:

FINB or MKTU

Note: Although more characters are allowed, using a fourcharacter account_ID maintains application compatibility and helps prevent the overall account string from exceeding the 30 character limit when account string expansion takes place.

Account String Expansion (ASE) Variables

Teradata Database tags the 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 character string limit is enforced against the expanded form.

Specification of the ASE variables shown below is optional, but recommended. Other variables are available. For information, see Database Administration.

Teradata Data Warehouse Appliance 2580 Implementation Guide 243

Chapter 12: Managing Database Users

Task 2: Creating Profiles

Element

Description

The ampersand (&) designates an account string expansion

(ASE) variable. Teradata Database automatically replaces these variables with actual values upon opening the session. You can use any or all of the following:

•

&S = the session number

•

&D = the date

•

&H = the time

Procedure: Create User 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.

Recommendation:

•

Incorporate such things as the user type or user department into the profile name to identify its function. For example, GenUser_Profile or Finance_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

“User Accounts” on page 241 .

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:

(‘$M0+accl&S&D&H’,‘$L0+accr&S&D&H’, ‘$R0+acc51’)

Note: There is a 30 character limit on each account string, and that limit includes the expanded form of the ASE variables in the string.

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.

244 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 2: Creating Profiles

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: “Allocating Space and

Creating an Administrative User.”

•

General users: 5%

•

Update users: 10%

•

Batch users: 10%

•

Assistant administrative users: 10%

•

Database programmers: 10%

Periodically monitor usage patterns as shown in “Task 3: Managing Space

Utilization” on page 306 , 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

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 “Task 3: Setting Up the Database Administrator User” on page 105 .

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

“Task 3: Creating Database Users.”

•

After creating users, use a MODIFY PROFILE statement to include member users.

Teradata Data Warehouse Appliance 2580 Implementation Guide 245

Chapter 12: Managing Database Users

Task 2: Creating Profiles

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

CREATE PROFILE statement similar to the following:

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 Task 3: Creating Database Users .

Reference Information

For Step...

Information on...

syntax and options for the

CREATE PROFILE statement using accounts to enforce session priorities

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

Is available in...

“CREATE PROFILE” in Chapter 4: “CREATE

PROCEDURE - CREATE ROLE” in SQL Data

Definition Language Syntax and Examples

•

“Task 2: Monitoring and Changing the System

Priority of Jobs” on page 302 .

•

“Task 4: Regulating System Access with Filters and Throttles” on page 310

•

Chapter 7: “Sessions and Accounts” in

Database Administration

Chapter 7: “Sessions and Accounts” in Database

Administration.

Chapter 4: “Space” in Database Administration

“Task 3: Managing Space Utilization” on page 306

“Denormalizing Through Global Temporary and

Volatile Tables” in Chapter 8: “Denormalizing the

Physical Schema” in Database Design

“Password Control Options” in Chapter 6:

“Creating and Managing Passwords” in Security

Administration

246 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 3: Creating Database Users

This task creates individual database users, including lower level administrators, database programmers and other privileged users, and database end-users.

Procedure: Create 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 “Task 4: Using Scripts to Create Database Objects” on page 145

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 more than one user to share a particular 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 individual 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 247

Chapter 12: Managing Database Users

Task 3: Creating Database Users

Field or Control

Spool Space

Temporary Space

Account

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.

Optional. You can set up user account information to form the basis of various user management options.

Recommendation: Do not specify accounts at the user level. Instead name a profile in the Profile parameter that contains the needed

account(s). For information, see “Task 2: Creating Profiles” on page 241

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.

248 Teradata Data Warehouse Appliance 2580 Implementation Guide

Field or Control

Default Database

Profile Name

Default Role

Default Journal

Startup String

Before Journal

After Journal

Chapter 12: Managing Database Users

Task 3: Creating Database Users

Explanation

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.

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 “Procedure 4: Define the

Default Role for a User” on page 258 . 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 249

Chapter 12: Managing Database Users

Task 3: Creating Database Users

Field or Control

FALLBACK

Collation

Time Zone

Default Date Form

Default Character Set

Explanation

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: FALLBACK is not normally needed at the user or database level. FALLBACK is only recommended for individual mission-critical 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 unless they do not work for a specific user.

Note: All users must use the same collation value.

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 “Task 4: Using Roles to Manage Privileges” on page 251 .

Reference Information

For Step...

Information on...

syntax and options for the CREATE

USER statement

Is available in...

“CREATE USER” in Chapter 6: “CREATE

TRANSFORM - CREATE VIEW” in SQL

Data Definition Language Syntax and

Examples

assigning permanent and spool space Chapter 4: “Space” in Database

Administration

the creation and use of accounts

“Procedure 1: Create User Roles.”

250 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

Using roles to manage user access privileges in the database is comprised of three steps.

Create roles and identify them according to the set of privileges they represent, as shown in

Grant privileges to each role, as shown in “Procedure 2: Grant Privileges to a Role.” The

privileges users receive as a result of role membership are called inherited privileges.

Grant role membership to users who require the set of privileges it contains, as shown in

“Procedure 3: Grant User Membership in a Role.”

Note: Some privileges cannot be granted to a role. You must grant those privileges directly to

a user. For information, see “Task 5: Granting Privileges Directly to Users” on page 260

User Types and Required Privileges

The following table describes the minimal privileges required by the three basic user types.

User Type

General

Privilege Requirements

Database end-users who typically read data and execute macros in a read-only

Views database created in Chapter 5,

“Task 3: Creating Views” on page 140

Requires the following privileges on a read-only Views database for all General users:

•

EXECUTE

•

SELECT

Some General users may also require the following privileges on a read-only Views database:

•

CREATE VIEW

•

DROP VIEW

The read-only Views database must have SELECT WITH GRANT OPTION

privileges on the Tables_Database, as shown in “Task 6: Granting Table Access

Privileges to Views Databases” on page 262 .

Teradata Data Warehouse Appliance 2580 Implementation Guide 251

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

User Type

Update

Batch

Assistant

Administrators

Privilege Requirements

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

“Task 6:

Granting Table Access Privileges to Views Databases” on page 262

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 Chapter 4,

“Task 3: Setting

Up the Database Administrator User” on page 105 and

“Procedure 3: Grant

Database Privileges to User DBADMIN” on page 110 to create assistant

administrators and grant the privileges they need.

252 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

User Type

Database

Programmers

Privilege Requirements

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.

•

Implicit privileges: 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 it.

•

Explicit privileges: Privileges acquired by a grantee named in a GRANT statement. The grantee can be a user, role, or database.

•

Automatic privileges: Privileges automatically granted by the system as a result of the creation of a database object to:

•

The creator of a database, user, or other object

•

A newly created database or user

Note: Automatic and explicit privileges are logged by the system in exactly the same way, and after being granted, are indistinguishable as to how they were acquired.

•

Inherited privileges: Privileges that are passed on indirectly to a user in the following ways:

•

All users inherit the privileges of PUBLIC, a role-like pseudo user created by the system and available to all users with logon privileges, regardless of whether or not they are granted any other privileges.

•

A role member inherits the privileges granted to a role when the role is active for the member.

•

If the TO clause in a GRANT (SQL form) statement includes the ALL option, the privileges accorded to the user(s) explicitly named in the statement are automatically inherited by all child users and databases.

Note: All privileges except implicit privileges are stored in the data dictionary in the

DBC.AccessRights table, for each user.

For a detailed discussion of privileges, see Chapter 6: “Privileges” in Database Administration.

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

Chapter 6: “Privileges” in Database Administration.

Teradata Data Warehouse Appliance 2580 Implementation Guide 253

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

Procedure 1: Create User Roles

Start Teradata Administrator and log on as user DBADMIN.

On the main screen, click the Preview Mode button generated SQL.

Click Tools>Create>Role.

to allow future display of

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

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 “Procedure 2: Grant Privileges to a Role.” .

Procedure 2: Grant 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:

254 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

Fields and Controls

Database Name

Object Type

Objects

To/From User

Role

Explanation

Required.

•

If you are granting privileges on a database, specify the name of that database.

For example, if you want to grant privileges on the

Tables_Database, specify Tables_Database. Do not specify the database that contains the Tables_Database.

•

If you are granting privileges on an object contained in a database, such as tables, specify the parent database that contains the object.

For example, if you want to grant privileges on the Employee table located in the Tables_Database database, specify

Tables_Database.

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.

Required.

Specify the type of database object on which privileges are being granted.

For example:

•

If you want to grant privileges on the Tables_Database, specify

Database.

•

If you want 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.”

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.

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 255

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

Fields and Controls

Public

Normal

Create

Drop

All

Dictionary

Access

All But

Explanation

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.

Required. Specify the privileges by checking the boxes, based on the guidelines in

“User Types and Required Privileges” on page 251

Recommendation: Consider the privileges that the user may get without formal granting, as shown in

“Types of Privileges” on page 253 , 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.

Not all privileges need to be granted using roles. In some cases, 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

“Procedure 3: Grant User Membership in a Role.”

256 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

Reference Information

For Step...

Information on...

syntax and options for the GRANT

(SQL Form) statement using roles to manage user access database privileges, including those conferred by object ownership

Is available in...

“GRANT (SQL Form)” in Chapter 2: “”Data

Control Language Syntax in SQL Data Control

Language

“Using Roles to Manage Privileges” in Chapter

3: “Users, Roles, and Profiles” in Database

Administration

Chapter 1: “Teradata Database Privileges” in

SQL Data Control Language

Procedure 3: Grant 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";

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 “Procedure 4: Define the Default Role for a User.”

Teradata Data Warehouse Appliance 2580 Implementation Guide 257

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

Reference Information

For Step...

Information on...

1 syntax and options for the CREATE

ROLE statement

3 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...

“CREATE ROLE” in Chapter 4: “CREATE

PROCEDURE - CREATE ROLE” in SQL Data

Definition Language Syntax and Examples

“Using Roles to Manage Privileges” in Chapter

3: “Users, Roles, and Profiles” in Database

Administration

“GRANT (SQL Form)” in Chapter 2: “Data

Control Language Syntax” in SQL Data Control

Language

Chapter 1: “Teradata Database Privileges” in

SQL Data Control Language

“GRANT (Role Form)” in Chapter 2: “Data

Control Language Syntax” in SQL Data Control

Language

Procedure 4: Define 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.

Select the user you want to modify.

to allow future display of

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.

258 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 4: Using Roles to Manage Privileges

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 “Task 5: Granting Privileges Directly to Users.”

Reference Information

For Step...

Information on...

syntax and options for the SET ROLE statement syntax and options for the MODIFY

USER statement, including the default role using roles to manage user access

Is available in...

“SET ROLE” in Chapter 8: “END

LOGGING - SET TIME ZONE” in SQL

Data Definition Language Syntax and

Examples

“MODIFY USER” in Chapter 8: “END

LOGGING - SET TIME ZONE” in SQL

Data Definition Language Syntax and

Examples

“Using Roles to Manage Privileges” in

Chapter 3: “Users, Roles, and Profiles” in

Database Administration

Teradata Data Warehouse Appliance 2580 Implementation Guide 259

Chapter 12: Managing Database Users

Task 5: 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

“Procedure 3: Grant

Database Privileges to User DBADMIN” on page 110

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 grant most privileges on any database object it owns to any other user or role. This excludes the 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 Chapter 6: “Privileges” in Database Administration.

Prerequisites

You can only grant privileges to users that already exist in the database. For information on creating users, see

“Task 3: Creating Database Users” on page 247 .

The Sys_Calendar database and Calendar view must exist. They are normally created as part of system installation by running the DIPALL script.

Procedure 1: Grant 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 falls on.

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.

260 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Task 5: Granting Privileges Directly to Users

Reference Information

For Step...

Information on...

All Sys_Calendar and the Calendar view

Is available in...

“CALENDAR System View” in Chapter 1:

“Teradata Database Data Dictionary Overview” in

Data Dictionary

Procedure 2: Grant 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 “Procedure 3: Grant Database Privileges to User DBADMIN” on page 110

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 or go on to “Task 6: Granting Table Access Privileges to

Views Databases.”

Teradata Data Warehouse Appliance 2580 Implementation Guide 261

Chapter 12: Managing Database Users

Task 6: Granting Table Access Privileges to Views Databases

Reference Information

For Step...

Information on...

syntax and options for the GRANT

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

Is available in...

“GRANT (SQL Form)” in Chapter 2: “Data

Control Language Syntax” in SQL Data Control

Language

Chapter 1: “Teradata Database Privileges” in

SQL Data Control Language

Task 6: Granting Table Access Privileges to

Views Databases

Grant table access privileges to all read-only Views and updatable 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.

Procedure 1: Grant Table Access to Each Views Database

Start Teradata Administrator and log on as user DBADMIN.

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.

262 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 12: Managing Database Users

Checkpoint

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 “Task 3: Setting up Access Logging” on page 271 .

Reference Information

For Step...

Information on...

syntax and options for the GRANT

(SQL form) statement database privileges, including those conferred by object ownership the recommended structure for tables and views databases

Is available in...

“GRANT (SQL Form)” in Chapter 2: “Data

Control Language Syntax” in SQL Data

Control Language

Chapter 1: “Teradata Database Privileges” in

SQL Data Control Language

“User Types and Required Privileges” on page 251 .

Checkpoint

Before leaving Chapter 12: “Managing Database Users,”

make sure that:

√

Result

You have assessed database user needs and developed a user management strategy.

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.

Reference

“Task 1: Assessing User Needs” on page 239

“Task 2: Creating Profiles” on page 241

“Task 3: Creating Database Users” on page 247

“Task 4: Using Roles to Manage

Privileges” on page 251

Teradata Data Warehouse Appliance 2580 Implementation Guide 263

Chapter 12: Managing Database Users

Checkpoint

√

Result

Some users, such as administrators and those who need uncommon object-level privileges, have had privileges granted to them directly.

Read-only views and updatable Views databases have table access privileges.

Reference

“Task 5: Granting Privileges Directly to

Users” on page 260 .

“Task 6: Granting Table Access

Privileges to Views Databases” on page 262

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

264 Teradata Data Warehouse Appliance 2580 Implementation Guide

SECTION 3

Ongoing Maintenance

Teradata Data Warehouse Appliance 2580 Implementation Guide 265

Section 3: Ongoing Maintenance

266 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 13

Monitoring Your System

This section discusses monitoring system health, system performance, and current activity and trends for your Teradata Data Warehouse Appliance 2580. The tools you use here include

Teradata Manager, Teradata Administrator, DBC Log Views, and Teradata Performance

Monitor.

Required Tasks

The tasks presented here are not specifically required for database implementation; however,

Teradata strongly recommends them as best practices for monitoring the database. Do Tasks 1 through 4 first. You can perform the remaining tasks in any order.

Teradata Manager

There are several ways to monitor the health and performance of the Teradata Data

Warehouse Appliance 2580. Teradata Manager includes a collection of useful monitoring and reporting tools, including the following:

•

Dashboard

•

Performance Monitor

•

Session Information

•

System Alerts

•

Locking Logger (for investigating lock contentions)

Task 1: Starting Teradata Manager

To start Teradata Manager:

From the Windows Start menu Programs group, click Teradata Manager 13.0>Teradata

Manager.

In the Logon Information dialog:

•

For System (DBS) Name, enter the name by which the Teradata Data Warehouse

Appliance 2580 is known on the network.

•

For Username and Password, enter the logon information for a Teradata Manager user

as created in “Procedure 1: Add Administrative Users to Teradata Manager” on page 115 .

Teradata Data Warehouse Appliance 2580 Implementation Guide 267

Chapter 13: Monitoring Your System

Task 2: Using the Dashboard

•

Click the Profile list and wait for DEFAULT to appear there.

•

Click Get data from Server

•

For Server Name enter the name by which the Teradata Manager server machine is known on the network. The Teradata Manager server is the machine running the

Teradata Manager Windows service, as described in

“Task 2: Install the Teradata

Manager Service” on page 76 .

•

Click OK.

Teradata Manager opens on the local machine but uses data provided by the Teradata

Manager Windows service on the Teradata Manager server.

Task 2: Using the Dashboard

The Teradata Manager Dashboard provides a summary of several system conditions in a single view.

Procedure 1: Viewing the Main Dashboard Screen

To view the main Dashboard screen:

✔

From the Teradata Manager Monitor menu, click Dashboard.

The Dashboard shows real-time data and recent trends in resource usage.

268 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 2: Using the Dashboard

The main Dashboard screen has three components:

•

Indicators at the top of the Dashboard show the operational status of AMPs, PEs, Nodes,

Bynet, and VSS (virtual storage). Green indicates OK, and red indicates a component is non-operational.

•

The gauges show information on current system resource usage, status of logged on sessions, and performance information. The following table describes the information displayed by each of the gauges.

Gauge

Virtual Utilization

Physical

Utilization

Session

Data Label

AMP Utilization %

PE Utilization %

VSS

AMP Parallelism

Node Utilization %

Bynet Utilization %

Disk Utilization %

Node Parallelism

Total Sessions

Blocked Sessions

Active Sessions

Transaction Rate

Response Time

I/O Per

Transaction

Average Transaction

Rate (TPM)

Average Response

Time

Average I/O per

Transaction

Description

The average percent of CPU usage for all online

AMPs in the configuration

The average percent of CPU usage for all online PEs in the configuration

The average percent of CPU usage by virtual storage services (VSS) over time

An indication of the parallelism that is being achieved across all vprocs. This value is a percentage calculated as: Average CPU usage across all AMPs x

100 / CPU usage by the AMP having the highest usage.

The average percent of CPU usage for all online nodes in the configuration

The percent of total Bynet utilization (i.e., average of the online Bynets).

The average percent of disk usage for all online nodes in the configuration

An indication of the parallelism that is being achieved across all nodes. This value is a percentage calculated as: Average CPU usage across all nodes x

100 / CPU usage by the node having the highest usage.

The total number of sessions logged on to Teradata

Database

The number of blocked sessions on the system

The total number of active sessions logged on to

Teradata Database

The average number of requests processed per minute

The average response time required for each request

(in seconds)

The average number of logical reads and writes issued per request

Teradata Data Warehouse Appliance 2580 Implementation Guide 269

Chapter 13: Monitoring Your System

Task 2: Using the Dashboard

•

The graphs at the bottom of the Dashboard show recent trends over the last hour. The following table describes the information displayed in the graphs.

Graph

Virtual Utilization

Summary

Physical Utilization

Summary

Sessions Summary

Data Label

Vproc Avg

Vproc Min

Vproc Max

Node Avg

Node Min

Node Max

Total Sessions

Active Sessions

Blocked Sessions

Description

The average percent CPU utilization of all online vprocs during the data collection period

The minimum percent CPU utilization by any vproc during the collection period

The maximum percent CPU utilization by any vproc during the collection period

The average percent CPU utilization per node during the collection period

The minimum percent CPU utilization by any node during the data collection period

The maximum percent CPU utilization by any node during the data collection period

The total number of sessions logged on to Teradata

Database

The number of active sessions logged on to Teradata

Database

The number of blocked sessions logged on to Teradata

Database

Procedure 2: Viewing Detailed Status Information

You can drill down from the main Dashboard screen to get more detailed status information:

Click the links under the large gauges to display reports showing details of current resource utilization and session information.

Clicking on the Sessions link displays a table showing per-session information. Doubleclicking any session in the table, or right-clicking the session number displays more detailed information about the session. In addition to providing more information on a particular session, the detail screen also allows you to abort sessions, investigate problems with blocked sessions, change the priority of session work, check on the SQL submitted by a session, and other capabilities which are described in the Teradata Manager online help.

The following Teradata Manager tools also display detailed session information:

•

Click Monitor>Sessions

•

Click Monitor>Session Information

•

Click Monitor>Performance Monitor, and display session information as described in

“Task: Using Performance Monitor” on page 284

You can right-click a session number

270 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Click the links under the small gauges to display graphs showing performance trends over the last hour.

Click the links under the Summary graphs to display graphs with more detailed information for the last hour.

Note the following features of the reports and graphs:

•

For more details on the large gauge reports, right-click the items in the first column of the reports.

•

Optionally, you can view the reports as graphs and view graphs as reports by clicking the link at the top right of the report or graph.

•

For more information on the report columns and graph items, see the Teradata Manager online help.

•

You can choose the types of information that appears on the graphs.

•

The reports and graphs dynamically update at the collection rate defined on the Collection

Rates tab of the Teradata Manager Administer>Teradata Manager screen.

•

You can save the reports and graphs by clicking Save As from the Teradata Manager File menu. Report and graph data can be saved in a number of text-based formats. Graphs also can be saved as bitmap (.bmp) images.

•

You can also view detailed information by clicking the items on the Teradata Manager

Monitor menu.

Reference Information

Information on...

the Teradata Manager Dashboard

Is available in...

Teradata Manager User Guide - Chapter 6 - section

Monitoring Overall System Activity Using the Dashboard

Task 3: Setting up Access Logging

Teradata Database automatically monitors all user logon and logoff activity and writes it to the

Event Log.

In addition, the database administrator can configure the database to monitor the details of

user interactions with the database and write them to the Access Log, as shown in Procedure 2:

Initiate Access Logging .

The Access Log captures auditable records about the database objects that users access, frequency of access, and whether or not the access was denied. The log satisfies various regulations, such as the Sarbanes-Oxley law in the United States, which require the ability to trace certain kinds of user activity in a database that contains confidential information.

Teradata Data Warehouse Appliance 2580 Implementation Guide 271

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Typical Logging Requirements

A common rationale for auditing is the Payment Card Industry Data Security Standard (PCI-

DSS), which requires that all retailers, financial institutions, and payment processors that store credit cardholder information 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 generally to monitor access to any sensitive data.

For additional information on logging and auditing options, see Chapter 7: “Monitoring

Database Activity” in Security Administration.

Procedure 1: Run the DIPACC Script

The DBC.AccLogRule macro must exist before initiating access logging. Create this macro by running the DIPACC script.

Log on to the control node as shown in

Database Utility” on page 361

“Task 1: Log on to the Control Node” on page 360

Open a cnsterm window as shown in steps 1 and 2 of

“Task 2: Use cnsterm to Run a

At the Input Supervisor Command prompt, start the DIP utility.

> start dip

Hold the Ctrl key while pressing the C 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 the DIP number for the DIPACC script:

> 18

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 N at the prompt to exit DIP.

272 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Close the Client Connection window.

Close the Teradata Administration Workstation window.

Procedure 2: Initiate Access Logging

Access logging beyond the default tracking of logon/logoff activity must be explicitly turned on using the BEGIN LOGGING statement.

Initiate logging similar to the following procedure, which is based on the example

requirements shown in “Typical Logging Requirements” on page 272

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.

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

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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 273

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Field

First

Last

First & Last

Each

Normal field

Description

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.

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 iii iv

On the main menu deselect the Preview Mode button display.

to suppress the SQL

On the main window, click Tools>Access Logging.

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.

274 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

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.

Object The specific object that contains the sensitive data

Not required because the All box is checked in the On Database field.

By User

Denials

With SQL

First

Last

First & Last

Each

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.

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 275

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Field Description

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"

5 d a

From the Query window, click the Run Query button

Close the Query window.

Initiate logging of all invalid access attempts as follows:

Specify values for the following fields:

Field

Database

With SQL

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.

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 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.

276 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Field

First

Last

First & Last

Each

Normal field

Create field

Drop field

Groups field

Description

Checking one of these boxes indicates when the logging is to be performed.

Recommendation: Check Each to log all access attempts.

Not required. Specification of individual privileges is checked automatically when All is checked in the 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;

6 a b 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 because 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 277

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

Field

Denials

With SQL

Description

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 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"

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;

Click the Run Query button .

278 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 3: Setting up Access Logging

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 “Procedure 1: Auditing Database Activity

Using DBC Log Views.”

Note: You can use the END LOGGING statement to end some or all logging as follows:

END LOGGING ON ALL; or

END LOGGING ON access_type BY username ON database_object; where:

Element Description

access_type

The type of access on which to end logging, for example CREATE TABLE.

username

The Teradata Database user for whom logging is ended.

database_object

The name of the database object on which logging is ended, in the form

database.object.

Reference Information

For step...

Information on...

All the DIPACC script and the

DBC.AccLogRule macro security logging strategies

Is available in...

“DIP Scripts” in Chapter 10: “Database

Initialization Program” in Utilities: Volume 1

(A-K)

Chapter 7: “Monitoring Database Activity” in

Security Administration

Teradata Data Warehouse Appliance 2580 Implementation Guide 279

Chapter 13: Monitoring Your System

Task 4: Investigating Database Access Attempts

For step...

Information on...

optional specifications and syntax for the BEGIN LOGGING and END

LOGGING statements usage recommendations and restrictions for the BEGIN LOGGING statement security logging strategies

Is available in...

“BEGIN LOGGING” in Chapter 1: “ALTER

FUNCTION - COMMENT” in SQL Data

Definition Language Syntax and Examples

Chapter 8: “END LOGGING - SET TIME

ZONE” in SQL Data Definition Language

Syntax and Examples

“BEGIN LOGGING” in Chapter 1: “ALTER

FUNCTION - COMMENT” in SQL Data

Definition Language Syntax and Examples

Chapter 8: “END LOGGING - SET TIME

ZONE” in SQL Data Definition Language

Syntax and Examples

Chapter 7: “Monitoring Database Activity” in

Security Administration

Task 4: Investigating Database Access

Attempts

The administrator should perform regular audits of the logs to detect undesirable activity and if necessary take remedial action, as shown in the following procedure.

Each row in the audit log shows the results of a database privilege check.

Procedure 1: Auditing Database Activity Using DBC Log Views

Audit the Event Log and Access Log views to identify undesirable activity.

The following views provide logs of user activity in the database:

View Name

DBC.AccessLog

DBC.LogOnOff

Description

Each entry indicates the results of a privilege check performed due to a user request to access a database object. The privilege checks performed 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.

280 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 4: Investigating Database Access Attempts

You can use these views for security monitoring as shown in the following procedure:

To perform a general audit of the security log views:

From the main Teradata Administrator screen, click on 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 where view_name is DBC.AccessLogV or DBC.LogOnOffV.

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...

All

Information on...

content of the access log tables and views using Teradata Manager to monitor and manage access logging

Is available in...

•

“Monitoring Security Related Tables and

Views” in Chapter 7: “Monitoring Database

Activity” in Security Administration

•

“System Views Reference” table in Chapter

3: “Data Dictionary Views” in Data

Dictionary

“Auditing Database Activity with Teradata

Manager” on page 282

Teradata Data Warehouse Appliance 2580 Implementation Guide 281

Chapter 13: Monitoring Your System

Task 4: Investigating Database Access Attempts

Auditing Database Activity with Teradata Manager

In addition to direct queries of the security log views shown in “Procedure 1: Auditing

Database Activity Using DBC Log Views” on page 280 , you can also use Teradata Manager to

audit database activity and set auditing parameters.

Procedure 2: Setting Auditing Parameters in Teradata Manager

You can optionally set audit report criteria in Teradata Manager using audit log filter parameters to focus on a subset of overall database activity.

To set the audit log filter, do the following in Teradata Manager:

Click Investigate>Audit Log>Filter.

To audit privilege checks that:

•

Occurred within a certain time frame, enter the Access Log Date/Time parameters

•

Were caused by sessions logged on within a certain time frame, enter the Session

Logon Date options

•

Belong to a specific user, enter the User to be audited

•

On users that belong to a specific account, enter the Account to be audited

•

Resulted in specific access outcomes, select one of the following:

•

Both - Shows privilege checks that resulted in both granted and denied access

•

Grant - Shows only privilege checks that resulted in granted access

•

Deny - Shows only privilege checks that resulted in denied access

•

Occurred on attempts to access specific objects, select the Database, Table, or Column to be audited.

Click OK to save your filter settings.

Procedure 3: Investigating Privilege Checks

To investigate the access log, do the following in Teradata Manager menu bar:

Click Investigate>Audit Log.

Select one the following report options.

•

Database/User

•

Table/View/Macro

•

Grants

•

Indexes

•

Maintenance

•

Denials

•

Summary

The Access Log Entries screen for that option appears, listing all access attempts on the

item selected in step 2

that conform to the rules for that item in “Procedure 2: Initiate

Access Logging” on page 273

282 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task 4: Investigating Database Access Attempts

Procedure 4: Creating a Customized Audit Report

Use this procedure in Teradata Manager to create a customized report of attempts to access the database:

Click Investigate>Audit Log>Custom.

Select the types of access to be included in the report by doing the following:

•

Check All to include all types of access

•

Check the category names to automatically check all the boxes for that category (DB/

User, Objects, Access, Maintenance, Other). Clear any options.

•

Check the options one by one

Click Next.

Choose the columns to display in the report by moving the column names to the Selected list. To do this, highlight the column name in the Available list, then click Add->.

Click Next.

Set the order of the columns on the report by moving the column names up or down in the Left to Right Column Order list. To do this, highlight the column name, then click Up or

Down, depending on the direction, to move the column.

Set the sort order of the report by moving the column names up or down in the Row Sort

Order (Order By) list. To do this, highlight the column name, then click Up or Down, depending on the direction, to move the column.

Click OK to view the report.

Procedure 5: Investigating Logon Activity

LogOnOff Usage presents daily, weekly, and monthly logon statistics based on information in the DBC.LOGONOFF view on the associated Teradata Database. You can use this log for security auditing or to monitor user activity.

Three LogOnOff Usage reports are available:

Report Name

DailyReport

WeeklyReport

MonthlyReport

Description

The number of logons across several days, either in 10 minute or one hour intervals, grouped by time interval and user

A summary of all logons for the last ten weeks, grouped by week

A summary of all logons over the 30 days, grouped by date

Do the following to investigate logons:

From the Teradata Manager menu bar, click Investigate>Logon/Logoff History.

From the Logonoff Usage screen, select View.

From the View screen, select Daily Report.

Teradata Data Warehouse Appliance 2580 Implementation Guide 283

Chapter 13: Monitoring Your System

Task: Using Performance Monitor

From the Daily Logon Report Parameters window, define the date range and Viewing

Window.

Note: Selecting Weekly or Monthly report in the previous step eliminates the need for setting these parameters.

Click OK.

Teradata Manager displays the logon/logoff history by date for the specified period.

Task: Using Performance Monitor

Performance Monitor (PMON) provides another way to monitor the general health of

Teradata Database. PMON can be used to help analyze current performance, current and historical session information, and can be used to abort sessions.

While PMON provides many of the same types of information as other tools in Teradata

Manager, such as the Dashboard and various session viewing tools, advantages to using

PMON in certain circumstances include:

•

Most screens (except the main screen and the Chart screen) do not automatically refresh data. The static displays can be an advantage when investigating certain issues, like lock contention (blocked or delayed SQL database queries).

•

PMON provides many detailed graph options for session data, including the capability to graph one parameter against another, such as CPU Use by Account and Disk I/O by User.

•

The Chart screen lets you chart several types of data at once on the same graph easily, by simply checking boxes to designate the information to be graphed.

Procedure 1: Starting Performance Monitor

To start Teradata Performance Monitor:

Do one of the following:

•

From the Teradata Manager Monitor menu, click Performance Monitor.

•

From the Programs group of the Windows Start menu, Performance Monitor can appear in different places, depending on how it was installed:

Click Start>Programs>Teradata Performance Monitor 13.0>Performance Monitor or:

Click Start>Programs>Teradata Manager 13.0>Performance Monitor

Click File>Logon / Connect

If you started PMON from Teradata Manager, you will be logged on to the database using the same username and password that was used to log on to Teradata Manager. If you started PMON from the Windows Start menu, enter your logon information and click OK.

Click the Start button.

284 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Using Performance Monitor

[Optional] Click Tools>Options and use the Options dialog box to customize how

Performance Monitor looks and behaves, such as setting the criteria for “critical” resource levels, changing the colors used to highlight critical levels, determining how sessions are displayed, and whether session history is maintained in log files.

Procedure 2: Charting Performance Data

To chart performance data:

Click the Chart button.

Use the tabs and checkboxes to specify the information to be charted, and the Intervals control to set how many data collection periods appear on the horizontal axis of the chart.

Teradata Data Warehouse Appliance 2580 Implementation Guide 285

Chapter 13: Monitoring Your System

Task: Using Performance Monitor

The Virtual tab shows information that can be charted for vproc (AMP and PE) usage. The

Physical tab shows information that can be charted for node use. Both can be combined on the same chart.

The chart is dynamically updated at the collection rate defined on the Start tab of the

Tools>Options dialog box.

Procedure 3: Viewing and Graphing Resource Information

To view information on current resource usage, click the Resource button.

Check or uncheck the Physical box to determine whether the window displays physical resource usage (resources used by the nodes) or virtual resource usage (resources used by the vprocs: AMPs and PEs).

Click to select a node or vproc in the Online list to display resource usage information for that node or vproc.

Some types of resource information can be displayed in graphs, which show per-node or per-vproc information. To display a graph of resource information:

From the View menu, click the type of resource information to be graphed, or double-click over a data field in the Resource Usage window where the mouse cursor changes to a hand.

To save a graph as an image file or as tab-delimited text data, click File>Save As, and provide a file name and location.

286 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Using Performance Monitor

Procedure 4: Viewing and Graphing Session Information

To view information on currently logged on database sessions, click the Session button.

Use the controls in the Sessions window to filter and sort the sessions that appear in the

Users list as desired. Each item in the list represents one current database logon session. A user may have more than one session open at any time.

In the Users list, double-click a user session to display session information.

Some types of session information can be displayed in graphs. To display a graph of session information:

From the View menu, click the type of session information to be graphed, or double-click over a data field in the User Info window where the mouse cursor changes to a hand.

Some session information graphs can display an additional dimension of information. These

“data type A by data type B” graphs can provide important information on relationships between the data, which can help in discovering patterns and troubleshooting. To generate A by B graphs:

Move the mouse cursor over a data field in the User Info window where the mouse cursor changes to a hand.

Click and hold the mouse button to change the mouse cursor to a red circle-slash.

While holding the mouse button down, drag the cursor to a data field in the other column of the User Info window, where the cursor changes to a green “bulls eye” shape.

Teradata Data Warehouse Appliance 2580 Implementation Guide 287

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

Release the mouse button to create a graph that shows both types of data.

Use the checkboxes in the graph window to refine the information that appears on the graph.

To save a graph as an image file or as tab-delimited text data, click File>Save As, and provide a file name and location.

Note: Use the View and Style menus to choose from various types of graphs and other visual characteristics. For example, some types of graphs can be rotated in 20 degree increments to aid in viewing the graph information.

Reference Information

Information on...

Performance Monitor

Is available in...

the Performance Monitor online help.

Task: Using Alerts to Monitor Your System

Teradata Manager can be set up to monitor Teradata Database and act automatically when interesting or critical events occur. For example, Teradata Manager can page the DBA, send email to the CIO, or escalate incidents to the help desk. Teradata Manager can also trigger corrective measures, such as running a user-defined SQL script.

288 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

To create an Alert, first create an alert policy, second define possible actions, and third define the events that will trigger alerts. When you define an event, you see the list of actions you defined previously and choose which action you want to occur when the event happens. These procedures are described next.

Procedure 1: Creating a New Alert Policy

An Alert Policy includes both events and actions. To create a new alert policy, do the following:

Start Teradata Manager (Start>Programs>Teradata Manager 13.0>Teradata Manager).

From the Teradata Manager menu bar, click Administer>Alert Policies to start the Alert

Policy Editor.

From the Alert Policy Editor menu bar, click File>New.

Enter a Name for the new alert policy.

Click OK to create the new policy.

Although many policies can be created, only one policy can be active at a time.

Procedure 2: Defining Actions

Define actions that occur when alert thresholds are reached before you define the condition that sets off the alert. Do this so the action you want is available in the drop-down list when you specify the alert condition.

To define actions, do the following:

In the Alert Policy Editor, click on the name of the policy you just created to activate the

Actions tab, then click Add.

Click on the Action Definition button.

Type in the action name, for example, Page Larry.

Click OK.

From the Physical Action list, choose one of the following actions to perform. You will be asked to supply more information, such as an email address, depending on the action you choose. Be sure to read the Procedure Notes column in the following table to see specific information and recommendations for each action.

Do Not Repeat Within describes the number of minutes that you want to elapse before the action is invoked again. If you choose

, Teradata Manager executes the action you specify every time the alert condition is detected, regardless of how frequently this happens.

Repeat the procedure to create each action you want to be available from the menu when you define events that trigger the actions in

“Procedure 4: Defining Events” on page 291

Teradata Data Warehouse Appliance 2580 Implementation Guide 289

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

Defined Action Description Procedure Notes

Send a page Supports numeric messages only. Alphanumeric messages are supported using the Send an e-mail action.

The Send a Page action requires a modem configured on the Windows system that hosts the

Teradata Manager service.

Send an e-mail Sends alphanumeric pages as well as e-mail.

•

The automatically generated fields appearing in an e-mail alert are described in “Email Alert

Message” in Chapter 15: “Using Alerts to

Monitor Your System” in Teradata Manager User

Guide.

•

If sending an e-mail does not work as expected,

return to the procedure described in “Procedure

4: Start the Teradata Manager Windows Service” on page 90

Run a program Launches an application, which may correct the problem detected. Teradata

Manager sends information about the alert to that application.

•

Save the program you want to execute (the .exe file) in the secure subdirectory of your Teradata

Manager folder on the Teradata Manager server

PC (the default path is \\Program

Files\Teradata\Teradata Manager 13.0\Secure).

•

Type the name of the application (the .exe file) in the Program Name box in Teradata Manager

Alert Policy Editor.

•

In the Parameters box, enter any command line parameters to be passed to the application. For more details, see “Command Line Parameters” in Chapter 15: “Using Alerts to Monitor Your

System” in Teradata Manager User Guide.

Run a BTEQ script

Executes a BTEQ command window, passing a file that is specified as input. For example, a script could run a cleanup routine or insert data into a table.

•

Put the.exe file in the secure subdirectory of your

Teradata Manager folder on the Teradata

Manager server PC (the default path is

\\Program Files\Teradata\Teradata Manager

13.0\Secure).

•

The BTEQ session executes on the Teradata

Manager server PC and accesses the Teradata

Manager profile data. This allows use of the special .logon shortcut in the SQL script and avoids placing a username and password in the script file. For example, if the current Teradata

Manager profile specifies tdpid “teradb”, username “tdmanager”, and password “tdm”, then the BTEQ command .logon is equivalent to

“.logon teradb/tdmanager,tdm”. For more

information, see “Task 2: Creating Profiles” on page 241

290 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

Defined Action Description

Generate an

SNMP trap

Allows third-party applications, such as HP

OpenView, to monitor

Teradata Database performance and to be notified of exceptions using

SNMP traps.

Display a

Banner

Procedure Notes

The SNMP alert action requires the Microsoft

SNMP service to be installed and configured on the

Teradata Manager server PC. Consult the Windows documentation for information on setting up the

SNMP service.

Displays scrolling alert information on the Windows desktop.

This information is generated automatically.

Procedure 3: Creating a List of Actions (Optional)

Teradata Manager can execute a combination of actions when an event occurs. For example, when the perm space utilization of a database exceeds 90%, Teradata Manager can page the

DBA, execute a program, and send e-mail to five people.

After you have defined at least two actions, you can add them to a list of actions as follows:

Click the Actions tab, and then click Add.

Type in the action name.

Select List of Actions.

Click OK.

Click Add under the List of Actions box and select actions to add to the list.

Click OK.

Procedure 4: Defining Events

Note: The following procedure is easier to follow if you read the procedure first before executing it.

Events occur when a monitored system parameter crosses a predefined threshold.

To define events, do the following:

In the Alert Policy Editor, click one of the tabs described in the following table.

For each tab, supply the information requested, including the specifics that apply to that tab, shown in the Procedure Notes column in the following table.

Teradata Data Warehouse Appliance 2580 Implementation Guide 291

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

Defined Event

Tab

DB Space

System

Nodes

Vprocs

Sessions

Description Procedure Notes

Raises an alert whenever the database space used on any

AMP exceeds the specified percentage.

Click Add to identify which database the event applies

to. In the dialog box, either click Apply to All

databases or click Apply to a Specific database and enter the database name.

Recommendation: To create a space alert on database DBC when it exceeds 80%, choose Apply to

a Specific database, enter DBC, and then click OK.

Specify 80% in the box labeled % space used is

above.

Raises an alert whenever the performance of Teradata

Database is no longer within the specified thresholds.

•

Do not assign a Run a BTEQ script action to the

Response Time event. If an alert is triggered for response time, the system is congested or hung, so a BTEQ script would itself become blocked.

•

For the Parallel efficiency events, the parallel efficiency = 100 * AvgCPU/MaxCPU. Averages are a simple average across all online nodes or

AMPs, depending on the event you choose.

Recommendation: All events in the Nodes and

Vprocs tabs (except Node is Down) contain a

Duration box. Enter a duration of five or 10 (minutes) to avoid firing the alert when there is a temporary spike.

For the Node is Down event, leave the Non TPA node count at the default.

Recommendation: In the Idle for (minutes) event,

use the Exception button to specify exceptions who are exempt from this alert. Also, do not use the Abort action for idle sessions. Some sessions may legitimately sit idle for a long time.

Recommendation: Create alerts for blocked sessions and anyone logging on more than ‘n’ sessions simultaneously. Specify exceptions for session alerts, for example, batch jobs and DBAs.

Recommendation: In the Duration box, specify a

Duration of five or 10 (minutes) to avoid firing the alert when there is a temporary spike.

Combinations Specifies a combination of your choice of two Node events or two AMP and PE events that trigger an alert.

Click Add, choose either the Node events or AMP and

PE events radio button, and then select one event from each list.

Recommendation: Under Node Events, specify a combination of Node CPU use percent > 90 and

Parallel Efficiency of Nodes < 80.

Events Specifies an alert whenever a specific error code occurs.

Event codes must be 10 digits.

292 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

For all alert events you can choose the following actions:

Action

Actions you defined previously

Description

Records the event in the alert log.

The alert log contains one entry for each alert activated. The files are in text format, and have the default name alerts.log.

The log files are located in:

\Documents and Settings\All Users\Application Data\Teradata \Teradata

Manager\Databases\<TDPID>

Does not raise an alert.

See

“Procedure 2: Defining Actions” on page 289

Note: Teradata recommends that for all events, you set the initial action to be <Write to Log> until you have tested the affects of the thresholds on your system. You can then view the log to determine which alerts are launching too frequently or not launching enough and adjust the limits before adding further actions. Follow this process to avoid sending false positive e-mails and pages.

In the Sessions event tab, you also have these additional actions to choose from:

Action

Description

Aborts the Teradata Database session for which an alert condition was detected.

Sets the priority of the Teradata Database session for which an alert condition was detected to the one specified in the Lower Priority Action field on the System tab. If there is no entry in this field, the default $L is used.

Procedure 5: Defining Rates for the Policy

To set the frequency for alert-related Teradata Manager actions, such as refreshing policy information and collecting event data, use this procedure:

In the Alert Policy Editor, click on the Rates tab.

Highlight a Teradata Manager action, for example, Collect Session Data, and choose a collection interval for each.

Refresh Policy Rate Information is the frequency at which Teradata Manager checks to see if the active alert policy has been updated and, if so, executes the new policy.

The Process Alert Requests Rate is the frequency at which Teradata Manager checks to see if alerts need to be raised for user jobs. For more information on how this rate is used, see Using the Alert Request Table on page 263 of Teradata Manager User Guide and Using the

MonitorRequest Table on page 264 of Teradata Manager User Guide.

Teradata Data Warehouse Appliance 2580 Implementation Guide 293

Chapter 13: Monitoring Your System

Task: Using Alerts to Monitor Your System

Recommendation: Set the Collect Session Data rate to 60. Next, reset the default Session monitoring rate in Teradata Database to match this.

Procedure 6: Resetting the Teradata Database Session Monitoring Rate

To reset the default Session monitoring rate in Teradata Database, do the following:

From the Teradata Manager Monitor menu, select Performance Monitor.

From the Performance Monitor File menu, select Logon/Connect.

Click the Start button.

Under the Tools menu, select Set Monitor Rates.

Change the rate for Session to 60.

Click Set.

Procedure 7: Applying the Policy to the Database

There are two modes for applying your alert policy to Teradata Database:

•

Interactive: Applies the policy changes to the database as requested

•

Batch: Allows automatic alert policy changes to be scheduled

To apply your new policy to the database in interactive mode, do the following:

From the Alert Policy Editor, select Tools>Apply to Database.

Select a system from the list, then click Apply.

To confirm that the alert is now active, click on the Active tab in the Select a System area, and then click on the system the alert is applied to.

To apply your new policy to the database in batch mode so it can be scheduled to apply later, see Example of Applying Policy in Batch Mode in Teradata Manager User Guide, Chapter 15, page 257.

Procedure 8: Investigating System Alerts

After you set up the alert policy, you can view the status of the database using the Alert Viewer.

The Alert Viewer provides a single viewpoint on the overall system performance. You can drill down from an overall picture to identify the problem area, possibly preventing a hazardous situation.

To investigate overall system or database performance, from the Teradata Manager menu bar, do the following:

Select Investigate>Alert Viewer.

See the graphing function that displays a graph for any data point value by simply clicking on it.

To chart resource usage information about nodes, AMPs, PEs, the Bynet, and sessions, from the Alert Viewer View menu, choose Chart.

294 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Investigating Lock Contentions

Alert Examples

To see examples of how to set up different types of alerts, see Teradata Manager User Guide,

Chapter 15, pages 261-266.

Task: Investigating Lock Contentions

Any number of users and applications can simultaneously access data stored in Teradata

Database. To protect against inconsistent data that could result from data being changed by one user while the same data is being queried by another, Teradata Database includes a concurrency control mechanism. The Lock Manager locks the database objects accessed by each transaction, preventing or limiting 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, and can be applied to different database objects, depending on the type of transaction being processed. Locking and unlocking database objects is handled automatically by the Lock Manager; however, locks can also be manually applied, if necessary. For more information about the Lock Manager, see SQL

Request and Transaction Processing - Chapter 9, section “Lock Manager”.

Situations can arise where poorly formed SQL statements or other problems cause database transactions to run for long periods or abort ungracefully, resulting in persistent locks slowing or preventing other transactions from completing. The locks are said to be delayed or blocked.

In these situations, system performance can be adversely affected, and some queries may not be able to obtain locks on the objects to which they need access.

In such a situation, part of the troubleshooting protocol involves investigating database lock requests to see whether any have been significantly delayed while waiting for existing locks to be released. The Locking Logger utility is one way to investigate recently delayed lock requests to determine if a particular transaction is causing a problem.

Procedure 1: Starting the Locking Logger Application

The Locking Logger application in Teradata Manager allows you to store the recent history of database object locks to a database table, and generate lock reports from that data. These reports can help identify transactions that hold locks for a longer period than is typical. Such transactions cause the lock requests of new transactions to be delayed while waiting for the lock to be released by the older transaction.

Note: Be sure you have followed

“Procedure 3: Change Locking Logger Settings” on page 98 .

If not, be aware that changing the LockLogger setting in DBS Control to enable lock logging

requires a database restart. For the procedure to restart the database, see “Task 1: Initiate a

Manual Restart” on page 364

To start Locking Logger:

✔

From the Teradata Manager Investigate menu, click Locking Logger.

Teradata Data Warehouse Appliance 2580 Implementation Guide 295

Chapter 13: Monitoring Your System

Task: Investigating Lock Contentions

Procedure 2: Creating a Lock Log Table

The first step in investigating suspected lock issues is creating a lock log table, and storing recent lock information to the table. The lock information is held in fixed-size AMP buffers, which replace older information with newer as the system operates. Consequently, these buffers always reflect the latest lock history.

To create a lock log table:

Click Tools>Create Table.

296

In the Locking Logger Create Table dialog box:

•

Accept the default, time-stamped name for the lock log table, or substitute one of your own.

•

Leave the Mode control set to Snapshot.

Note: The Continuous mode of operation continuously adds rows to the lock log table as new lock information is recorded in the AMP buffers, and can consume significant system resources. Continuous mode should be used only under the direction of

Teradata Customer Support personnel.

•

Leave SQL Sessions set to Maximum for the most efficient Locking Logger operation.

•

Use the Time Constraints fields to specify the time period for which lock information will be stored in the lock log table.

Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Task: Investigating Lock Contentions

For an initial investigation of suspected lock problems, leave the fields blank to store all lock information from the AMP buffers to the lock log table.

•

Use the controls at the bottom of the dialog box to determine the database objects for which lock information is stored to the lock log table.

For an initial investigation of suspected lock problems, leave the All Objects checkbox checked.

Click Submit.

If the specified table does not exist, Locking Logger offers to create it. Click Yes.

The progress of the table creation and population is indicated by messages on the Locking

Logger status line, at the lower left of the window.

When the table creation and population is complete, and no further status messages appear on the status line, click Close to close the Locking Logger Create Table dialog box.

Procedure 3: Generate a Lock Report

After the lock information has been stored in the lock log table, generate a report to see the lock information.

To generate a lock report:

Click Tools>Generate Report.

In the Locking Logger Report dialog box:

•

Specify the name of the lock log table if it is different from the table name that appears by default.

•

In the Logon Time Constraints group, specify the beginning and ending date and time to define the time period for which lock information will be shown.

Note: You can use the date and time keywords to specify the current date and time. The

date-# format indicates a number of days before the current date. For example, entering date-1 would indicate yesterday.

Teradata Data Warehouse Appliance 2580 Implementation Guide 297

Chapter 13: Monitoring Your System

Task: Investigating Lock Contentions

Click Generate.

An SQL script runs to gather the lock information meeting the date criteria from the lock log table. Status messages in the lower left of the Locking Logger main window indicate the steps in the process. Depending on how your client machine is configured, your screen may momentarily change to show the script code being executed, then return to the

Locking Logger screen.

Each entry in the lock report indicates details of a lock request that was blocked (delayed) for one second or more while a transaction was waiting for another transaction to finish and release its lock on the same database object. Information reported for every blocked lock request includes:

•

The time of the lock request

•

The length of the delay in fulfilling the lock request

•

The name of the database and table for which the lock was requested and delayed

•

The level of lock that was requested

•

The user and account whose lock request was blocked

•

The level of lock that was blocking the request

•

The user and account whose lock was blocking the requested lock

•

Other information on the blocked and blocking locks

Example Locking Logger Report Entry

ReqDate ReqTime Delay

2009-09-22 16:56:38 00:00:10.820

Database Name Table Name

DBC Indexes

BlockedLevel BlockedMode BlockedHostID

Table Wr 1

Blocked User Name Blocked Account Name

MIX1TESTER

BlockedLogonSource

$L4$

(TCP/IP) A09F 153.64.206.67 TDAPPSYS

BlockingLevel BlockingMode BlockingHostID

26204 DWD BTEQ 01 LSS

Table Wr 1

Blocking User Name Blocking Account Name

GARY $H-DBC-MANAGER

BlockingLogonSource

(TCP/IP) 0B16 141.206.34.213 TDAPPSYS 2604 SYSTEM ISSERVICE 01 LSS

Processor DeadLock MultiBlockers Statement

0-7 N N Create Index

To save the report to a text file, click File>Save As, and specify the file name and location.

In addition to Locking Logger, these tools can be used to help investigate potential lock issues:

•

Session display tools available from Teradata Manager (Dashboard, Monitor>Sessions, and

Monitor>Session Information).

•

Performance Monitor, as described in

“Task: Using Performance Monitor” on page 284 .

•

Lock Display and Show Locks utilities, which show current system locks. (Only Locking

Logger can show historical lock information.)

298 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 13: Monitoring Your System

Reference Information

Information on...

Locking Logger, Lock Display, and Show Locks utilities managing locks

Teradata Database Lock Manager

Is available in...

Chapter 3: “Lock Display (lokdisp)” in Utilities:

Volume 2 (L-Z)

Chapter 4: “Locking Logger (dumplocklog)” in

Utilities: Volume 2 (L-Z)

Chapter 14: “Show Locks (showlocks)” in

Utilities: Volume 2 (L-Z)

Database Administration - Chapter 8 - section

Managing Locks

SQL Request and Transaction Processing - Chapter

9 - section Lock Manager.

Managing Your System

This section discusses managing your system to find and correct issues as they arise.

Required Tasks

The tasks presented here are not specifically required for database implementation; however,

Teradata strongly recommends them as best practices for managing the database. You can perform the tasks in any order.

Management Methods

There are several ways to manage your system, including changing service priorities, aborting queries, and investigating and managing disk space usage.

Task 1: Finding and Aborting Queries

Teradata recommends that you use Teradata Performance Monitor (PMON) to find and stop queries that unnecessarily consume too many resources and degrade the performance of other work. Here are the steps to finding and stopping a query:

You receive notification from a Teradata Manager alert.

From the Teradata Manager menu bar, click Monitor>Performance Monitor.

After PMON launches, you need to log on (File>Logon/Connect).

Click the Start button.

View the PMON session screen. Sort by descending order, Delta AMP Cpu.

Note: If you have recently used the Session screen or are using Client mode (fetching the data from a Teradata Manager server), you do not need to perform the next three steps; go to step 7.

Display the Session screen.

Wait one refresh interval (shown at the top left of the window, in seconds).

Click the Refresh button.

Double-click the session with the highest CPU usage. This will show the User Info screen, which displays detailed information for that session.

Teradata Data Warehouse Appliance 2580 Implementation Guide 301

Chapter 14: Managing Your System

Task 2: Monitoring and Changing the System Priority of Jobs

Use the Next button to scroll through the sessions, looking for the following:

•

Low I/O accesses

•

High CPU skew combined with a nontrivial amount of Delta CPU. (A yellow background color in the skew field indicates this combination.)

Click the SQL button to display the SQL that is being executed in this session and the

Explain plan steps that are being run. This screen shows you which step is executing and the estimated versus actual times and I/O counts.

In the EXPLAIN, look at how many steps and what type of operation is being performed.

Product joins, in particular, can be problematic.

Use the Refresh button to refresh the SQL/EXPLAIN dialog box. See if the query is stuck on a step. If yes, this is likely to be the root cause. To be sure, copy the SQL and paste it into either a BTEQ or Teradata SQL Assistant screen and run a full EXPLAIN. If the step shows a product join with many rows, this SQL is the problem.

Close the SQL/Explain dialog box.

Click the Abort button.

Note: EXPLAINs from an executing query may use different words or contain less information than full EXPLAINs provided by the Optimizer.

The EXPLAIN request modifier reports an English language summary of the query plan generated by the Optimizer to process any valid SQL request. The request itself is not processed.

Reference Information

For Step...

Information on...

2 PMON

Is available in...

Chapter 19: “Teradata Manager Applications” in

Teradata Manager User Guide

Task 2: Monitoring and Changing the System

Priority of Jobs

Some jobs in Teradata Database are given a higher priority and allocated more system resources than others. The priority given a job initially is determined by the priority specified in a user account string. When users log on, the database employs one of the following to determine the session account:

•

The default user account, that is, the first account listed in the user profile, or if the user is not a profile member, the user definition.

•

An account specified in the log on string.

•

An account specified in a SET SESSION ACCOUNT statement, as described in

“Procedure: Changing a Priority Level for a Session or Request” on page 305 .

302 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 2: Monitoring and Changing the System Priority of Jobs

•

If there is no applicable account, the system uses the default account for the parent user.

This is not recommended because the parent user priority level may be inappropriate.

Database administrators assign account strings in the user definition, or in the profile of which the user is a member (recommended). The account string includes a performance group specification (PG) that determines the priority level. For more information defining an account string, see the sections begining with

“Running Utilities from the CNS Command Line” on page 360 .

There are four default priority levels on a Teradata Database 2580, and all accounts are assigned to one of these priority levels. This section explains how the predefined priority levels operate, how to monitor their behavior, and how to change the priority of a job.

Predefined System Priorities

The following table shows the four predefined performance groups and the relative weights given to each priority level when all four levels are active. Each defined account must specify one of these groups.

Performance

Group

Priority

Level

Rush

High

Medium

Low

Typical Query

Accesses a single or few AMPs

Relative

Weight

Estimated processing time less than 1 second

53%

26%

Estimated processing time between 1 and 100 seconds 14%

Estimated processing time greater than 100 seconds 7%

The relative weight associated with a performance group is an indication of the priority contrast among all active groups and the frequency that CPU is offered to jobs running in that priority level. It is not intended to predict the actual CPU usage or consumption. Lowerpriority jobs receive more CPU when higher-priority jobs are not using it.

Jobs cannot run forever at the priority level at which they are submitted. Each performance group has a predetermined CPU usage milestone (a time limit), after which the priority given a job decreases. For example, a job that starts with a rush priority could be given low priority after 210 seconds. The following table describes CPU milestones for performance groups and how Teradata Database handles queries that exceed the CPU usage milestone.

Performance Group

CPU Usage Milestone (in seconds per node)

200

None

Teradata Database Action When Milestone Is

Exceeded

The service priority changes to Medium.

The service priority changes to Low.

None

Teradata Data Warehouse Appliance 2580 Implementation Guide 303

Chapter 14: Managing Your System

Task 2: Monitoring and Changing the System Priority of Jobs

Disabling CPU Milestones for Priority Levels (Optional)

You can allow all queries to run at their original priority without being subject to CPU milestones. For example, you may want a $H query to continue to run at high priority until completion, even if that takes 10 minutes. Consider carefully how you want priority levels to operate at your site. Optionally, you can use the following procedure (which requires a database restart) to disable the CPU milestones for all queries.

Issue the following at the Teradata command line. For more information on the command line, see

schmon -G DEFAULTSETTINGS

Restart Teradata Database to apply the new settings. See “Task 1: Initiate a Manual Restart” on page 364

To reapply CPU milestones for performance levels, follow this procedure:

Issue the following at the Teradata command line: schmon -G CLEAR

Restart Teradata Database to apply the new settings. See “Task 1: Initiate a Manual Restart” on page 364

Note: Neither schmon -G procedure in this section takes effect if Teradata DWM is active.

Disable filters and throttles and log off Teradata DWM before issuing the command. For more

information on Teradata DWM, see “Task 4: Regulating System Access with Filters and

Throttles” on page 310

Note: Users require the root privilege to run schmon. For more information on this privilege, see

“Task 4: Grant CNS Permissions to Non-Root Users” on page 362

Using schmon To Monitor Workload Characteristics

To monitor workload characteristics, run schmon from the Teradata command prompt. You can do the following things with schmon:

•

Display current priority settings

•

Display and monitor resource usage statistics for nodes and priority levels

•

Display priority data for the specified sessions from the current node or all nodes

You cannot use schmon to make changes. The following schmon options are available on the

Teradata Data Warehouse Appliance 2580.

Schmon Option

-d

-h

Description

Displays the current priority settings in multi-line format. For syntax, usage notes, and examples see “schmon -d” in Utilities: Volume 2 (L-Z).

Displays help for schmon. You can specify one or more schmon top-level options (for example, -M) on which to display extended help information. For syntax, usage notes, and examples, see “schmon -h” in Utilities: Volume 2 (L-Z).

304 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 2: Monitoring and Changing the System Priority of Jobs

Schmon Option

-m

-M

-s

Description

The schmon -m option displays or monitors priority resource usage statistics.

For syntax, usage notes, and examples, see “schmon -m” in Utilities: Volume 2

(L-Z).

Displays or monitors priority resource usage statistics for all nodes of an MPP

Teradata Database. For syntax, usage notes, and examples, see “schmon -M” in

Utilities: Volume 2 (L-Z).

Displays priority data for the specified sessions from the current node or all nodes in the Teradata Database system. For syntax, usage notes, and examples, see “schmon -s” in Utilities: Volume 2 (L-Z).

Procedure: Changing a Priority Level for a Session or Request

To change the priority level for a session or single SQL request, do the following:

Issue a SET SESSION ACCOUNT SQL request.

In this example a user switches the account for use during a subsequent SQL request from the default to another assigned account with a higher priority, $H0+FIN1&S&D&H:

SET SESSION ACCOUNT='$H0+FIN1&S&D&H' FOR REQUEST;

SET SESSION ACCOUNT must specify an account that is assigned to the executing user, either in the user definition or in a profile of which the user is a member.

Note: A user cannot change to a higher priority account unless that account is one of the accounts the database administrator has defined for the user.

Alternately, someone with administrator privileges in Teradata Manager can change the priority level of a session from the Sessions button in the Dashboard. For more information on the Teradata Manager Dashboard, see

“Task 2: Using the Dashboard” on page 268 .

Recommendation: Disable CPU milestones before changing the priority level for a session or request. Otherwise, the new priority is subject to automatic demotion based on CPU milestones. See

“Disabling CPU Milestones for Priority Levels (Optional)” on page 304 .

Procedure: Finding All Accounts with RUSH Priority

The following query selects all account strings with a RUSH priority code, and whether the name associated with an account is an individual user or a profile:

SELECT AccountName,UserName,UserOrProfile

FROM DBC.AccountInfoV

WHERE AccountName LIKE '$R%'

ORDER BY AccountName ;

Teradata Data Warehouse Appliance 2580 Implementation Guide 305

Chapter 14: Managing Your System

Task 3: Managing Space Utilization

In this example, the query returns:

AccountName

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

$R$_ABCD&S&D&H

$R$_EFGH&S&D&H

$R$_IJKL&S&D&H

$R$_MNOP&S&D&H

$R$_QRST&S&D&H

Reference Information

UserName

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

AcctsRecv

DBADMIN

DBC

SysAdmin

SystemFe

UserOrProfile

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

Profile

User

Information on...

assigning or modifying the priority level for a profile changing the priority level for a session or request monitoring priority levels using schmon

Is available in...

“Task 2: Creating Profiles” on page 241

“SET SESSION” in Chapter 8: “END LOGGING -

SET TIME ZONE” in SQL Data Definition Language

Syntax and Examples

Chapter 6: “Priority Scheduler (schmon)” in Utilities:

Volume 2 (L-Z)

Task 3: Managing Space Utilization

Implementation of Teradata Database requires that space be assigned to databases and users.

Initial space allocations, such as those made in

Chapter 6: “Creating Databases, Tables, and

Views”

and

Chapter 14: “Managing Your System”

are based on estimates. Actual space usage may vary and require reallocation of space among database objects.

You can use Teradata Manager to monitor space usage and manage space allocation.

Note: Teradata Manager also tracks the use of temporary space for temporary tables and volatile tables not covered in this section.

Reference Information

Information on...

use of temporary space temporary tables and volatile tables, database objects that use temporary space

Is available in...

Chapter 4: “Space” in Database Administration

Chapter 2: “Populating the Database” in Database

Administration

306 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 3: Managing Space Utilization

Prerequisites

Use of the following space management procedures requires that the user executing the procedures:

•

Is a Teradata Database user with administrator privileges, as defined in “Task 3: Setting Up the Database Administrator User” on page 105 .

•

Must be a valid Teradata Manager user with all privileges, as defined in “Task 4: Setting Up

Administrators to Monitor Teradata Database Activity” on page 115 .

Procedure 1: Manage Permanent Space Usage

Permanent space is the space used by the database to store data and objects. If a user or database exceeds its allocation of permanent (perm) space it can no longer accept additional data or space consuming objects. Monitor permanent space usage to identify databases or users that are in need of a larger space allocation.

Use the following procedure monitor and manage perm space usage:

From the Teradata Manager menu bar, click Investigate>Space Usage>Space by Database.

The Database Space summary screen appears. The Database Name column shows an alphabetical listing of space owners (databases and users), and the space usage for each.

On the Database Space summary screen, examine the Current Perm% and Peak Perm% to identify space owners that have consumed a high percentage of their available perm space.

To find out which tables are consuming space for a particular space owner, right-click the space owner name in the Database Name column to display the shortcut menu.

Click on Table Space. The Table Space in “database_name” dialog box appears. The

Display space usage for all tables in this database box is checked by default.

Note: You can uncheck the Display space usage for all tables in this database and specify a value for Current Perm >= to narrow the search to only the largest tables.

Click OK. The Table Space (database_name) screen appears.

Examine the Table Space screen to identify the space consumed by each table.

Do one of the following to resolve perm space shortages:

•

Transfer space to a user or database that is nearing perm space limits, as shown in

“Procedure 2: Move Perm Space” on page 307

•

Transfer ownership of a database with extra perm space to a database that needs space, as shown in

“Procedure 3: Transfer Database Ownership to Reallocate Perm Space” on page 308 .

Procedure 2: Move Perm Space

If a user or database runs short on perm space, you can transfer perm space to it from user

DBADMIN or another object with a high percentage of unused perm space.

From the Teradata Manager menu bar, click Administer>Move Space.

The Move Space dialog box appears.

Teradata Data Warehouse Appliance 2580 Implementation Guide 307

Chapter 14: Managing Your System

Task 3: Managing Space Utilization

Fill in the fields as described in the following table.

Field

Amount to Move

From

Permanent Space Allocation

Maximum

Current

Unused

Description

Enter the amount of disk space to reallocate in bytes, kilobytes, megabytes, or gigabytes.

Select the name the source of the space.

Recommendation: Specify DBADMIN or another database with significant excess perm space.

Shows the maximum permanent disk space available to the database specified in the From field.

Shows the permanent disk space currently used by the database specified in the From field and the percentage of available space being used.

Shows the amount of unused permanent disk space for the database specified in the From field and the percentage of available space used.

Select the name of the destination for the space.

Permanent Space Allocation

Maximum

Current

Unused

Shows the maximum permanent disk space available to the database specified in the To field.

Shows the permanent disk space currently used by the database specified in the To field, and the percentage of available space used.

Shows the amount of unused permanent disk space for the database specified in the To field and the percentage of available space that is unused.

Click OK.

At the prompt make sure the amount to move, source name, and destination name are correct, then click Yes.

Procedure 3: Transfer Database Ownership to Reallocate Perm Space

Follow this procedure to transfer ownership of a space-owning database or user to another database or user to increase the available perm space of the recipient.

From the Teradata Manager menu bar, click Administer>Move Database.

The Move Database dialog box appears.

Scroll through the Give list and highlight the name of the space owner (database or user) to be transferred. The name appears in the Give field.

Scroll through the To list and highlight the recipient (new owner) of the transferred database or user. The recipient appears in the To field.

308 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 3: Managing Space Utilization

Click OK.

At the prompt make sure the names of the space owners are correct, then click Yes.

Procedure 4: Manage Spool Space Usage

Spool space is used to execute operations in the database. Creation of the spool-reserve database as shown in

“Procedure: Create a Spool Space Reserve” on page 103 should provide

enough total spool space for the database. User profiles limit the amount of the spool space reserve that can be consumed by a particular user.

To monitor spool space, do the following:

From the Teradata Manager menu bar, click Investigate>Space Usage>Space by Database.

The Database Space summary screen appears.

On the Database Space summary screen, examine the Peak Spool% column to identify space owners that have consumed a high percentage of the available spool space.

High spool space usage may indicate:

•

A high number of concurrent user queries

•

The presence of poorly constructed queries that use more spool space than necessary.

If spool space usage is near capacity, consider the following suggestions:

•

Make sure that all users are members of profiles that limit the spool space available to each user, as shown in

“Task 2: Creating Profiles” on page 241 .

•

Reschedule database activities that consume large amounts of spool, such as large queries and batch jobs, for times when the system is less busy, or use filters or throttles

to manage session concurrency, as shown in “Task 4: Regulating System Access with

Filters and Throttles” on page 310

•

Search for poorly performing queries that may make inefficient use of spool space, as

shown in “Task 1: Finding and Aborting Queries” on page 301

Procedure 5: Manage Table Skew

Skew percentage is the degree of unevenness of table row distribution among the AMPs assigned to the table. Such uneven distribution may cause queries against the table to fail because of insufficient perm space for a single overburdened AMP, while total available perm space is adequate to run the query.

To find skewed tables, do the following:

From the Teradata Manager menu bar, click Investigate>Space Usage>Space by Database.

The Database Space summary screen appears. The Database Name column shows an alphabetical listing of space owners (databases and users), and the space usage for each.

On the Database Space summary screen, examine the Skew% column to find out which databases contain overly skewed tables, that is skewed more than 10-15%.

To examine individual skewed tables, right-click the name of a database with a high skew percentage in the Database Name column to display the shortcut menu.

Teradata Data Warehouse Appliance 2580 Implementation Guide 309

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

4 b

Click on Table Space. The Table Space in “database_name” dialog box appears. The

Display space usage for all tables in this database box is checked by default.

Note: You can uncheck the Display space usage for all tables in this database and specify a value for Skew >= to narrow the search to only the most skewed tables.

Click OK. The Table Space (database_name) screen appears.

Examine the Table Space screen to identify any tables that are overly skewed, that is, skewed more than 10-15%.

Skewing may indicate the need to recreate the primary index for the table. Do the following to quickly access the table structure for review of its indexes:

Right click the name of a skewed table in the Table Name column.

Click Show Table to access the CREATE TABLE statement for the table, which will show how the table is indexed.

Reindex the table if necessary. For information on indexing, see the sections on indexing beginning with

“Procedure 4: Choosing a Primary Index” on page 136 .

Task 4: Regulating System Access with Filters and Throttles

You can use Teradata Dynamic Workload Manager to regulate system activity:

•

Filters restrict access to database objects

•

Throttles regulate the amount of activity by sessions, queries, and load utilities

To work with Teradata Dynamic Workload Manager (Teradata DWM), you must have administrator privileges to the following:

•

tdwm database

•

DBQLogTbl

•

Teradata Manager summary tables

The Teradata Manager Database setup utility installs the tdwm database.

Procedure 1: Starting Teradata Dynamic Workload Manager

From the Windows Start menu, select Programs>Teradata Dynamic Workload Manager

13.0.

The Teradata Dynamic Workload Manager Connect dialog box opens, prompting you to connect to a Teradata Dynamic Workload Manager server.

310 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

Complete the fields of the Teradata Dynamic Workload Manager Connect dialog box.

Field

DBC Name

Action/Description

Enter the name of the Teradata Database system you want to use to manage your workloads.

User Name

The default user name for Teradata DWM is tdwm. Another user name can be defined and will have restricted permissions: read-only access to the

Teradata Dynamic Workload Manager tables and no ability to use the

Activate command.

Password

Enter the password associated with the user name you entered in the User

Name box. The default password for Teradata Dynamic Workload Manager is tdwmadmin. Change this default password as soon as possible; to do this, use the MODIFY USER statement.

Do Not Connect to the Teradata

Database

[Optional] Click to work offline from the Teradata Database. Rule sets can be viewed or modified while in local mode.

The Do Not Connect to the Teradata Database is unchecked by default. Leave it alone.

Click OK.

The Teradata Dynamic Workload Manager window opens.

Note: Only one person can run Teradata DWM to write to the tdwm database and issue tdwm commands on a Teradata Database at a time.

Procedure 2: Creating Filters

Use filters to reject (filter out) unwanted logon and query requests. You can create two types of filters: object access filters and query resource filters.

•

Object access filters restrict access to database objects, such as tables and databases.

Examples include:

•

Reject all non-SELECT queries that access the INVENTORY_HISTORY table.

•

Prevent user C from logging on to the Teradata Database.

•

Prevent everyone from issuing SQL DML on Table B.

•

Prevent everyone from accessing Database T (and all tables/views/macros in it).

•

Prevent users A and B from performing DML on Table T.

•

Query resource filters limit database resources for any issuing object, query object, or object combinations. Examples include:

•

Table B cannot be involved in a Product Join AND the query cannot return more than

1 million rows.

•

Queries estimated to take longer than 30 minutes cannot run.

•

User A cannot run a query estimated to return more than 1 million rows.

•

Database C cannot be referenced in a query that requires a full-table scan of any of its tables.

Teradata Data Warehouse Appliance 2580 Implementation Guide 311

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

To create a new filter, do the following in Teradata Dynamic Workload Manager:

From the Rules menu, select one of these options:

•

Filter>Create>Object Access Rule

•

Filter>Create>Query Resource Rule

In the Description tab, set the following properties for the filter:

Field/Control

Name

Action/Comment

Enter up to 30 characters for the name of the rule. You can use alphanumeric, dash (-), underscore (_), and dollar sign ($).

Description

(Optional) Enter up to 50 characters to explain the function of the rule.

Restrict object combinations

Select this control to restrict users' access to all tables, views, or macros, for example.

This control becomes available later when you apply the rule to specific database objects.

Global Rule - applies to all requests

Select this control to apply the global filter to all objects. The filter will apply to all logon and/or query requests that meet the criteria of the rule.

Because a global rule automatically applies to all Teradata Database objects, you cannot associate individual objects with the rule.

For example, with a global filter rule, you could restrict all of the queries on the Teradata Database system, depending on the SQL

Type and other attributes.

Caution: A global object access rule rejects all of the specified statement type requests except those from the DBC user and any bypassed objects.

Warning Mode (Do not reject

Query - Log Only

If you want to see the effects of a filter before you permanently enable it, you can define it as operating in a warning mode.

When a rule is in a warning mode, the following events occur:

•

Queries are evaluated according to the rule

•

Errors are logged only for queries that would potentially be rejected

•

An error status code or message is not returned to the end-user

Select Accept.

Specify the type of SQL requests to which the rule applies. In the SQL tab, select the type of

SQL to be filtered. The default is ALL. To choose other options, clear ALL and select one or more other types.

Select OK.

If you are creating an object access filter, skip to

step 9 on page 314 . If you are creating a

Query Resource filter, select the Query Resource tab.

312 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

Either select OR to specify that the rule is triggered by any one of the specified conditions or select AND to specify that the rule is triggered only when all of the specified conditions are met.

Choose from the following optional fields/controls:

Field/Control

Maximum Row Count

Final Row Count

Maximum Processing Time

Restricted Table Joins

No Full Table Scans Allowed

Action/Comments

Specify the maximum estimated row count allowed for any step in a query.

If a query contains any step that contains more than this number of rows, the query is rejected

The default value is zero, which means the row count estimate is not used in processing the rule.

Define the row count as one of the following values:

•

Rows

•

Thousand Rows

•

Million Rows

•

Billion Rows

Specify the estimated answer set size of a query.

Define the row count as one of the following values:

•

Rows

•

Thousand Rows

•

Million Rows

•

Billion Rows

Enter the length of time you estimate as the greatest amount of time a query should be allowed to run.

Note that this value does not represent an estimated response time. Instead, it represents Optimizer estimates for the current system configuration in a non-busy state.

Select the type of table joins you want to restrict from one of the following items:

•

None: Allow all joins.

•

All Joins: Teradata Dynamic Workload Manager detects this condition for tables associated with a join step.

•

Product Joins: Teradata Dynamic Workload Manager detects this condition for tables associated with a join step AND the join-mode is one of the product join modes.

•

Unconstrained Product Joins: Teradata Dynamic Workload

Manager detects this condition for tables associated with a join step AND the join-mode is one of the product join modes AND there are no constraint instructions.

Check this box to restrict full table (all row) scans while a query is running. Clear the check box to allow full table (all row) scans while a query is running.

Teradata Data Warehouse Appliance 2580 Implementation Guide 313

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

Select Accept.

After you create a rule, you can link any number of objects with it. To link an object to a rule, from the Window menu, select Database Browser.

Select one or more objects from the Browser window.

Drag the selected objects to the rule name in the tree pane of the main Teradata DWM window to the left. If the type of object is incompatible with the destination rule, the icon changes to a circle with a slash.

The objects appear under either Query or Context.

314 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

To enable the filter, select it in the tree pane of the main Teradata DWM window to the left.

From the Rules menu, select Filter>Enable.

Save and activate the rule set. From the Rules menu, select Rule Sets > Save to Database

.

In the Save Rule Set dialog box, select Save as New Rule Set and type in a name. The name can be up to 30 characters and contain alphanumeric, dash, underscore, and dollar sign characters.

Teradata Data Warehouse Appliance 2580 Implementation Guide 315

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

From the Rules menu, select Rule Sets>Activate.

Select OK to close the dialog box.

Example: Restricting User Access

You administer the NewProducts development database, which many users with different levels of expertise can access.

Sam is learning how to write SQL and has negatively impacted system performance on multiple occasions due to his inexperience.

You want to create a rule to prohibit Sam from running a query on the NewProducts database that takes longer than 15 minutes to process:

From the Rules menu, select Filter > Create > Query Resource Rule. The Query Resource

Rule dialog box opens.

2 a

On the Description tab, enter a rule name and description in the Name and Description boxes. Leave the Global and Warning buttons unchecked.

Verify the ALL (default) setting on the SQL tab.

c c

On the Query Resource tab, enter

15:00

in Maximum Processing Time.

Select OK to close the Query Resource Rule dialog box and return to the Teradata

Dynamic Workload Manager.

From the Window menu, select Database Browser:

Locate Sam in the Database Browser window.

Drag Sam to the rule.

Locate the NewProducts database in the Database Browser.

Drag-and-drop the NewProducts database to the rule.

Sam and the NewProducts database appear under either Query or Context.

On the Description tab, select Restrict object combination. Click Accept.

From the Rules menu, choose Filter > Enable.

Save and activate the rule set. From the Rules menu, select Rule Sets > Save to Database

.

In the Save Rule Set dialog box, select Save as New Rule Set and type in a name. The name can be up to 30 characters and contain alphanumeric, dash, underscore, and dollar sign characters.

A dialog box confirm, click OK.

From the Rules menu, select Rule Sets>Activate.

Click to select the new rule set. Leave filters and throttles unchecked.

Select OK to close the dialog box.

More Filter Examples

For more examples of setting up filters in various situations, see Examples of Creating Filters in Chapter 7, page 133, of the Teradata Dynamic Workload Manager User Guide.

316 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

Procedure 3: Managing Query Concurrency Using Object Throttles

Use throttles to control how many queries, sessions, or utilities can run concurrently.

Throttles can delay or reject requests. When a limit you set is reached, new queries are put in a

FIFO delay queue until an active query finishes. This alleviates congestion and blocking so there is greater throughput and predictable response times.

You can create system-level session and query throttling on users, accounts, profiles, and database objects (for example, tables and views).

There are two kinds of throttles:

•

Object throttles, which limit how many sessions or queries can run for specified objects

•

Utility throttles, which limit how many load utilities can run

Examples of Object Throttles

•

No more than 10 queries from user MSI may run at one time.

•

User A cannot have more than five simultaneous sessions on the entire Teradata Database.

•

Account SALES cannot have more than four simultaneous queries running on the entire

Teradata Database.

•

Table T1 cannot have any DML queries running on the entire Teradata Database.

Creating an Object Throttle

To create a new object throttle, select Rules > Throttles > Create > Object Throttle Rule.

Teradata Data Warehouse Appliance 2580 Implementation Guide 317

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

To define the descriptive attributes for a throttle, in the Description tab, set the following properties for a throttle:

Field/Control

Name

Description

Rule Type

Individual: Separate limit for each associated object

Action/Comment

Enter up to 30 characters for the name of the rule. You can use alphanumeric, dash (-), underscore (_), and dollar sign ($).

(Optional) Enter up to 50 characters to explain the function of the rule.

Select the option corresponding to how you want throttle limits to be applied to objects and users:

Individual Applies a throttle limit to a database object individually.

This is the default setting.

Collective: Single limit for all associated objects

Members: Separate limit for users associated with objects

Global: Single limit for all requests

Collective Applies one throttle limit to all objects associated with the rule collectively (as a group), and not to each object individually.

For example, if you associate users George, Carmen, and Jack with an object throttle with a collective limit of five queries, this group of users cannot run more than five queries at the same time. If Carmen is running three queries and George is running two, the query Jack issues is throttled and delayed until one of the other queries completes.

Members Applies limits to all users who are members of, or are associated with, objects (account or profile, for example) that are associated with the rule. A limit applies to each member individually. For example, a limit of five on an account with five users means each user can have five queries running.

For example, if users George, Carmen, and Jack are associated with an object throttle with a limit of five queries for members, George,

Carmen and Jack can each run no more than five queries and could run 15 queries at the same time as a group.

Note: To select Collective and Members, you must first associate objects with the rule (two or more for Collective and one or more for Members). See

step 12 on page 320 through step 14 on page 320 .

Global Restricts all selected SQL requests except for DBC and bypassed users.

Caution: Global object access rules and global object throttle rules could affect a significant number of queries.

Click OK. Ignore the message about the filter or throttle having no associated objects. You will perform that step later.

To specify the type of SQL request managed by the throttle, select the SQL tab.

The default is ALL. To choose other options, clear ALL and select one or more other types.

Click Accept.

318 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

To set query throttle parameters, select the Query Throttle Params tab. Fill in the fields as follows:

Field/Control

Only limit queries with Step

Time Threshold

Disable Object Throttling

Rule Override

Throttle All-AMP Queries

Only

Action/Comment

[Optional] Step time threshold is the value that triggers an object throttle. The value you enter is compared against the value the system estimates for each step. If any step estimate exceeds the step time threshold value, the query is throttled.

The following examples illustrate how the step time threshold value is used:

•

If the step time threshold is 100 and the longest step is 80, then the query will be exempt from the rule.

•

If the step time threshold is 100 and the system estimates that at least one step is greater than or equal to 100, then the query will be controlled by the rule.

Specifies that you cannot override the throttle by aborting or executing any SQL requests that the throttle delays.

Teradata Dynamic Workload Manager releases an SQL request from the queue only when all throttle limits that apply to it are satisfied.

Throttles only All-AMP requests.

The throttle applies to a multistatement request if at least one step in the Optimizer plan involves all AMPs. Before implementing this option, note that some all-AMP requests are very quick.

Click Accept.

Select the Values by State tab to specify how to apply the throttle.

Fill in the fields or controls, as described in the following table.

Field/Control

Unlimited Sessions

Session Limit

Description

When checked, the throttle is applied to all sessions.

Recommendation: Uncheck this box to activate Session Limit.

Enter the maximum number of sessions that can run simultaneously.

Unlimited Queries

Query Limit

When checked, the throttle is applied to all queries. If unchecked, the

Query Limit column activates.

Enter the maximum number of queries that can run simultaneously.

Warning: Do not define query limits of two or fewer. That can result in blocks between needed locks and requests being held by

Teradata DWM.

Teradata Data Warehouse Appliance 2580 Implementation Guide 319

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

Field/Control

Reject

Description

Optionally, reject queries that exceed the specified session limit or query limit. If you do not select Reject, queries that exceed the specified limits will be delayed.

Click Accept.

After you create a rule, you can link any number of objects with it. If the type of object is incompatible with the destination rule, the icon changes to a circle with a slash. To link an object to a rule, from the Window menu, select Database Browser.

Select one or more objects in the Database Browser.

Drag and drop the selected objects on the rule name in the tree to the left.

To enable the throttle, select it in the Rules area.

From the Rules menu, select Throttles, and then choose Enable.

Save and activate the rule set. From the Rules menu, select Rule Sets>Save to Database.

In the Save Rule Set dialog box, select Save as New Rule Set and type in a name. The name can be up to 30 characters and contain alphanumeric, dash, underscore, and dollar sign characters.

Click OK on the confirmation dialog box.

From the Rules menu, select Rule Sets>Activate.

Click to select your new rule set from the list.

Click OK.

Example of Creating an Object Throttle

Assume you want to specify that application ABC cannot have more than three all-AMP queries running concurrently that are estimated to take more than one minute of processing time, and you want to reject any over-limit queries. To create an object throttle for this scenario, follow these steps:

From the Rules menu, select Throttles > Create > Object Throttle Rule. The Object Throttling

Rule dialog box opens.

On the Description tab, enter

App ABC concurrency limit

for Name.

On the Query Throttle Params tab:

4 a

Specify a one minute (1:00) Step Time Threshold.

Select Disable Object Throttling Rule Override.

Select Throttle All-AMP Queries Only.

On the Values By State tab, uncheck Unlimited Queries, enter a query limit of 3, and check

Reject.

Click OK.

From the Rules menu, choose Throttles > Enable.

320 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

Save at the rule set. From the Rules menu, select Rule Sets>Save to Database.

In the Save Rule Set dialog box, select Save as New Rule Set and type in a name. The name can be up to 30 characters and contain alphanumeric, dash, underscore, and dollar sign characters. Click OK to confirm.

From the Rules menu, select Rule Sets>Activate.

Click to select your new rule set. Leave filters and throttles checked.

Click OK.

Procedure 4: Limit Utility Concurrency Using Utility Throttles

Utility throttles control how many load utilities can run simultaneously on a Teradata

Database. You can specify a throttle rate (limit) for each utility option (FastLoad + MultiLoad,

FastLoad, MultiLoad, FastExport, and Archive/Restore).

To create a new utilities throttle, select Rules > Throttles > Create > Utilities Rule.

In the Description tab, fill in the Name and Description fields.

Choose the utility in the Utility Type list. Select either Archive/Restore or one of the following to specify the type of utility limited by the rule:

IF you choose utility type....

FastLoad

MultiLoad

FastExport

FastLoad+MultiLoad

THEN the Teradata PT Operator Throttled Is...

Load

Update

Export

Both Load and Update

Click the Utility Limits By State tab. Enter the maximum number of the specified type of utility that can run simultaneously. Maximum concurrency limits are:

•

FastLoad: 30

•

MultiLoad: 30

•

FastLoad+MultiLoad: 30

•

FastLoad+MultiLoad+FastExport: 30

•

Archive/Restore: 350

If you do not want the default of unlimited and unlimited queries, click on these and reset the value.

Click OK.

To enable the rule, in the Rules area, right-click on the utility throttle rule name. Click

Enable.

Save the rule. Click Rules > Rule Sets > Save to Database.

Teradata Data Warehouse Appliance 2580 Implementation Guide 321

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

From the Rules menu, select Rule Sets>Activate. Click to select the new rule set. Leave filters and throttles checked.

Click OK.

Example of Creating a Utility Throttle

Assume you want to allow a maximum of 30 concurrent MultiLoad jobs, and you want to reject any new MultiLoad jobs exceeding this limit, not just delay them.

From the Rules menu, select Throttles > Create > Utilities Rule. The Utility Rule dialog box opens.

On the Description tab, type

MultiLoad concurrency Limit

for Name. The

Description is optional.

Select MultiLoad in the Utility Type list.

Click the Utility Limits By State tab.

322

Do not change the default limit of 30.

Check Reject.

Click OK.

Enable the rule. In the Rules area, right-click on the utility throttle rule to access the shortcut menu. Click Enable.

Save the rule. Click Rules > Rule Sets > Save to Database.

In the Save Rule Set dialog box, select Save as New Rule Set and type in a name. The name can be up to 30 characters and contain alphanumeric, dash, underscore, and dollar sign characters.

Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

From the Rules menu, select Rule Sets>Activate. Click to select the new rule set.

Click OK.

Procedure 5: Unlinking Objects from a Rule

You can unlink Teradata Database objects from a rule whenever you like. When you unlink an object from a rule, the object is not deleted. The object still exists, but that particular rule no longer applies to the object. To unlink an object from a rule, do the following:

In the Context or Query area, select the object type you want to unlink.

Use one of the following options:

•

From the Rules menu, choose Filter or Throttles. Next, choose Delete > Delete Object.

•

Right-click the object to open a shortcut menu, and then choose Delete.

Click Yes to confirm the deletion and close the dialog box.

Procedure 6: Exempting Users, Accounts, and Profiles from Filters and

Throttles

You can exempt users, accounts, or profiles from filters and object throttles by declaring them to be “bypassed.”

From the Rules menu, select Filters or Throttle, and then choose Bypass.

The Grant Bypass dialog box displays.

From the Type list, select one of the following items:

•

Users

•

Accounts

•

Profiles

Teradata Data Warehouse Appliance 2580 Implementation Guide 323

Chapter 14: Managing Your System

Task 4: Regulating System Access with Filters and Throttles

From the Users, Accounts, or Profiles list, select the objects to which you want to give bypass privileges.

Click Add to move them to the Unrestricted… list. All the objects in this list are excluded from rules.

Select OK to close the dialog box and return to the Teradata Dynamic Workload Manager.

You must save and activate the Rule Set for these bypass privileges to be in effect. See

step 16 on page 315 . After the changes take effect, queries submitted by the users, accounts, or profiles

you chose are exempt from Teradata Dynamic Workload Manager rules.

Procedure 7: Disabling a Filter or Throttle

To disable filters or throttles, do the following:

Right-click the rule in the Rules area.

Select Disable from the shortcut menu. A red X appears over the rule icon.

Save the rule set. From the Rules menu, select Rule Sets > Save to Database

.

From the Rules menu, select Rule Sets>Activate. Click to select a rule set.

Procedure 8: Deleting a Filter or Throttle

To delete a filer or throttle from the tdwm database, do the following:

Right-click the rule in the Rules area.

Select Delete from the shortcut menu.

Click Yes.

Save the rule set. From the Rules menu, select Rule Sets > Save to Database

.

Click to select a rule set.

From the Rules menu, select Rule Sets>Activate.

Procedure 9: Monitoring Teradata Dynamic Workload Manager

To monitor Teradata DWM, in Teradata Manager, click Monitor>Teradata DWM and choose one of the following:

•

Delay Queue Stats: Reports on objects in the delay queue because of a throttle.

•

Object Logon Stats: Reports on the sessions needing the object that are active or in the delay queue because of a throttle.

•

Object Query Stats: Reports on queries on the object that are active or in the delay queue because of a throttle.

•

Object Delay Queue List: Lists objects in the delay queue.

•

Object Utilities Stats: Reports on utilities running on the system.

•

Utility Delay Queue List: Lists utilities in the delay queue because of a throttle.

For more information on Teradata Dynamic Workload Manager, see “Task 4: Regulating

System Access with Filters and Throttles” on page 310 .

324 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 14: Managing Your System

Troubleshooting

Guidelines for Using Throttles

Throttles are an optional workload management technique useful under certain circumstances. Consider using throttles if:

•

Any platform resource is at maximum usage level

•

High priority work is not performing as expected

Start using query throttles by:

•

Analyzing concurrency by application or by account:

•

Focus on low priority, resource-intensive applications

•

Determine which resource-intensive applications have the highest concurrency

•

Analyzing concurrency by user. Some users submit excessive numbers of concurrent, resource-intensive queries.

When implementing throttles, keep these things in mind:

•

Focus throttle use on low or medium priority work.

•

Keep throttle rules simple and easy to understand.

•

Avoid frequent manual changes to throttle limits.

•

Apply throttles cautiously. A query cannot be released from the delay queue until all throttles rules affecting it are satisfied (for example, account, user, and profile rules).

•

Delaying some queries via throttles can help overall performance and throughput of the platform.

Troubleshooting

For practical information on troubleshooting lack of disk space, resolving table skew, preventing slowdowns, and many other topics of interest in managing system performance, see Database Administration, Chapter 14, Troubleshooting.

Checkpoint

Before leaving Chapter 14: “Managing Your System,” make sure that:

√

Result

You can find and abort queries.

You understand predefined system priorities and can monitor and change the system priority of jobs.

Reference

“Task 1: Finding and Aborting Queries” on page 301 .

“Task 2: Monitoring and Changing the

System Priority of Jobs” on page 302 .

Teradata Data Warehouse Appliance 2580 Implementation Guide 325

Chapter 14: Managing Your System

Checkpoint

√

Result

You can use Teradata Manager to monitor and manage space allocation.

You know how to regulate system access with filters and throttles.

Reference

“Task 3: Managing Space Utilization” on page 306 .

“Task 4: Regulating System Access with

Filters and Throttles” on page 310 .

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

326 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 15

Performing Periodic Maintenance

This section discusses database management tasks that need to be performed at regular intervals to maintain system health.

Required Tasks

The tasks presented here are not specifically required for database implementation; however,

Teradata strongly recommends them as best practices. You can perform the tasks in any order.

Task 1: Managing Accumulated Log Data

Teradata Database contains a number of log tables that accumulate data. Many of the logs grow without limit, so you must purge older information. Purging log data is recommended because unpurged logs use permanent space that may be needed by other database objects:

Note: Depending on site requirements, you may need to retain older data long after it should be removed from a log. Teradata recommends that you create backup log tables to store log history and then periodically copy data from the logs to the backup tables. You can then archive copies of the backup tables on tape for long-term reference.

Managing Log Data with Teradata Manager

Teradata Manager automatically collects and retains data for use in database management.

The data retention period is based on system defaults, which can be reset. Data older than the defined retention period is automatically deleted by the Teradata Manager Cleanup function.

Teradata Manager collects the following types of data for use in managing the database. The amount of data collected is dependent on the user-configurable data collection interval.

Log Category Description

AMPUsage Data on activity of Access Module

Processors (AMPs).

DBC.DBQL Log tables Data collected during database query logging.

Heartbeat Query

Summary Data

Data collected as a result of running heartbeat queries to test database function and performance.

Default Data Retention Period

2 years

•

Detail data: 1 year

•

Summary data: 2 years

2 years

Teradata Data Warehouse Appliance 2580 Implementation Guide 327

Chapter 15: Performing Periodic Maintenance

Task 1: Managing Accumulated Log Data

Log Category

Priority Scheduler

Summary Information

QryBandPairs

Summary Data

Resusage Data in dbc

Tables

Spool Space Usage

Summary Log

Table Space Usage

Summary Log

TDWM Logs

Description

Information on priority scheduler activities is collected in these logs:

•

Configuration Log

•

Node Performance Log

•

System Performance Log

Summary information collected on use of the query banding feature (not covered in this publication).

Resusage tables collect data on system resource usage that allow for long term trend analysis.

•

Individual resusage tables

•

Resusage Summary Log

Shows spool space usage during the retention period.

Shows permanent space usage by tables during the retention period.

Teradata Workload Manager logs:

•

dbc.tdwmsummarylog

•

dbc.tdwmeventlog

•

dbc.tdwmexceptionlog

Default Data Retention Period

2 years

•

Detail data: 1 year

•

Summary data: 2 years

2 years

•

Detail data: 1 year

•

Summary data: 2 years

Reference Information

Information on...

configuring the Teradata Manager data collection interval perm space requirements for data collection, including examples

Is available in...

“Scheduling Tasks that Launch Applications” in

Chapter 17 of Teradata Manager User Guide.

“Step 9 - Enabling Data Collection” in Chapter 4 of

Teradata Manager User Guide.

Procedure 1: Setting the Data Cleanup Schedule

The schedule for cleaning up old log data should be based on the data retention period set when you enable logging in Teradata Manager.

Clean up old data as follows:

From the Teradata Manager main screen, click Administer>Teradata Manager.

From the Teradata Manager Administration window, click the Data Collection tab.

From the list of data logging categories select Cleanup, the last entry on the Source list.

Click Configure.

328 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 15: Performing Periodic Maintenance

Task 1: Managing Accumulated Log Data

In the Configure dialog box, enter the username, password, and account (if used) for

DBADMIN or another Teradata Database user with delete privileges in database DBC.

In the Authentication Mechanism field, select TD2 from Name drop down menu.

Click OK.

Click Schedule.

On the Schedule screen:

Check the Enabled box.

In the Schedule Type field select Repeat at Fixed Interval.

In the Define Schedule field, set the Interval for 30 days. The cleanup task checks the logs at the specified interval and deletes any data older than the retention period.

Click the Add button.

Managing Log Data Directly in System Tables

You can use an SQL statement to manually delete all old log data. However, Teradata recommends using Teradata Manager to delete the log data it manages, as shown in

“Procedure 2: Deleting Old Data from Logs in System Tables” on page 329

For logs, not managed by Teradata Manager, manual deletion is the only way to purge old data.

The following logs require manual deletion of old data:

Log Name and

Related DBC Table

Access Log

DBC.AccLogTbl

Software Event Log

DBC.SW_Event_Log

In Doubt

Transactions

DBC.InDoubtResLog

Delete Object Name

•

For all access logging:

DeleteAccessLogV

•

For logon information only: DBC.LogOnOffV

Description

A log of all database logons and privilege checks, as defined in the BEGIN LOGGING

statements executed as part of “Procedure 2:

Initiate Access Logging” on page 273

DBC.SoftwareEventLogV

Contains information about errors generated by system activity.

DBC.DeleteOldInDoubtV

Contains a row for each transaction for which the outcome was in doubt.

Procedure 2: Deleting Old Data from Logs in 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.

Teradata Data Warehouse Appliance 2580 Implementation Guide 329

Chapter 15: Performing Periodic Maintenance

Task 2: Verifying Data Block Integrity

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 Chapter 5: “CREATE

TABLE” in SQL Data Definition Language Syntax and Examples.

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 an 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

Date

LogDate number_of_days

Description

The name of the DBC object that allows log deletions, as shown in

“Managing Log Data Directly in System Tables” on page 329

. For example, DeleteAccessLogV is the delete object for the Access Log.

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.

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.

Task 2: 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.

330 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 15: Performing Periodic Maintenance

Task 2: Verifying Data Block Integrity

•

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.

Procedure 1: Run SCANDISK

SCANDISK is a command issued from within the Ferret utility.

From Teradata Manager, open the Database Console application by clicking:

Administer > Database Console

In the Utilities menu of Database Console, click Ferret.

Click Options > Redirect Output, and specify a location and file name to which the text output shown on screen will be automatically copied. If you specify an existing text file, the output will be appended to the file, otherwise the file will be created.

This log of your SCANDISK session can be sent to Teradata Customer Support if

SCANDISK finds problems with the file system structures.

You should coordinate with your 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.

When SCANDISK has finished checking, it displays a message similar to the following:

72 of 72 vprocs responded with no messages or errors

Uncheck the Redirect Output option to stop the output logging.

Enter

quit on the Database Console command line to exit Ferret.

Teradata Data Warehouse Appliance 2580 Implementation Guide 331

Chapter 15: Performing Periodic Maintenance

Task 2: Verifying Data Block Integrity

If SCANDISK reports any errors, open a support incident with Teradata Customer Support at http://www.teradataatyourservice.com

, and attach a copy of the file containing the program

output. For more information on opening incidents, see “Task 9: Open an Incident Using

Teradata @ Your Service” on page 69

Procedure 2: Run 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 CheckTable be run at a low level initially, and only run at a higher level of checking if problems are found at the lower level of checking.

From Teradata Manager, open the Database Console application by clicking:

Administrate > Database Console

In the Utilities menu of Database Console, click Check Table.

This log of your CheckTable session can be sent to Teradata Customer Support if

CheckTable finds problems with the table structures.

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.

Procedure 3: Run 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.

332 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 15: Performing Periodic Maintenance

Checkpoint

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.

Uncheck the Redirect Output option to stop the output logging.

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 http://www.teradataatyourservice.com.

Attach a copy of the text file containing the program

output. For more information on opening incidents, see “Task 9: Open an Incident Using

Teradata @ Your Service” on page 69

Reference Information

Information on...

the CheckTable utility the SCANDISK command

Is available in...

Chapter 5: “CheckTable (checktable)” in Utilities: Volume 1 (A-K)

Checkpoint

Before leaving Chapter 15: “Performing Periodic Maintenance,” make sure that:

√

Result

You have a system for managing and purging accumulated log data.

You regularly check for data corruption in the database and file system.

Reference

“Task 1: Managing Accumulated Log

Data” on page 327

“Task 2: Verifying Data Block Integrity” on page 330 .

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 333

Chapter 15: Performing Periodic Maintenance

Checkpoint

334 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 16

Updating a Table from a Flat File

You can update data in an already populated table in Teradata Database with data from a client external flat file using Teradata Parallel Transporter (PT).

This chapter describes how to:

•

Create a job variables file that a Teradata PT load job script will use

•

Customize a sample update job script for use with your database tables

•

Launch a Teradata PT job

•

Monitor and manage a Teradata PT job

•

Evaluate a completed Teradata PT job

•

Troubleshoot a failed job, if necessary

Required Tasks

The tasks in this section are required when using Teradata PT to update a Teradata Database table. Perform tasks 1, 2, 3, and 5 completely and in the order presented. Tasks 4 and 6 are optional depending on job conditions and outcome.

Teradata PT Update Job Script

Teradata PT uses operators to execute extract and write functions within a single job script.

The following figure illustrates updating a Teradata Database with data from a client external flat file using Teradata PT producer and consumer operators.

Flat

File

Read

Data

DataConnector

Operator

Data

Stream

Update

Operator

Write

Data

Teradata

Database

Producer

Operator

Consumer

Operator

2550A001

•

The DataConnector Operator, called a producer operator, reads data from a flat file and writes it to (“produces”) a data stream. A data stream consists of buffers in memory that temporarily hold data.

•

The Update Operator, called a consumer operator, reads data from a data stream

(“consumes it”) and then updates an already populated Teradata Database table.

Teradata Data Warehouse Appliance 2580 Implementation Guide 335

Chapter 16: Updating a Table from a Flat File

Teradata PT Update Job Script

Sample Update Job Script

The following update job script updates an already populated Teradata Employee table with

data from a flat file. For the sample delimited format flat file, see “Sample Employee Flat File” on page 337

DEFINE JOB FILE_UPDATE

DESCRIPTION 'Updating a Teradata employee table with data from a delimited format flat file'

(

DEFINE SCHEMA File_Schema

(

Associate_Id VARCHAR(25),

Associate_Name

Salary

DOB

Job_Title

VARCHAR(25),

VARCHAR(10),

VARCHAR(25),

Dept_No

Marital_Status

VARCHAR(25),

VARCHAR(1),

);

No_Of_Dependents VARCHAR(25),

DEFINE OPERATOR File_Reader

TYPE DATACONNECTOR PRODUCER

SCHEMA File_Schema

ATTRIBUTES

(

VARCHAR PrivateLogName = 'DataConnector_log'

VARCHAR DirectoryPath = @jobvar_datafile_path,

VARCHAR FileName = 'employee_table.txt',

VARCHAR Format = 'delimited',

VARCHAR OpenMode = 'read',

VARCHAR TextDelimiter = '|'

);

DEFINE OPERATOR Update_Operator

TYPE UPDATE

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'Update_log'

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername,

VARCHAR UserPassword = @jobvar_TDpassword,

VARCHAR LogTable

VARCHAR TargetTable =

);

= 'employee_table_log'

'Tables_Database.Employee',

APPLY

('UPDATE Tables_Database.Employee

SET Associate_Name = :Associate_Name,

Salary = :Salary,

DOB

Job_Title

= :DOB,

= :Job_Title,

Dept_No = :Dept_No,

Marital_Status = :Marital_Status,

No_Of_Dependents = :No_Of_Dependents

WHERE Associate_Id = :Associate_Id;'

336 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 16: Updating a Table from a Flat File

Create a Job Script

'INSERT INTO Tables_Database.Employee VALUES (

:Associate_Id

:Associate_Name,

:Salary,

:DOB,

:Job_Title,

:Dept_No,

:Marital_Status,

:No_Of_Dependents);')

INSERT FOR MISSING UPDATE ROWS

TO OPERATOR (Update_Operator)

SELECT *

FROM OPERATOR (File_Reader);

);

Sample Employee Flat File

10001|John Smith|93000.00|1954-10-21|Sr. Software Engineer|100|Y|5

10002|Mary Knotts|45000.00|1974-09-13|Secretary|100|Y|1

10005|Keith Muller|85000.00|1972-06-09|Sr. Software Engineer|100|Y|3

10021|David Crane|65000.00|1966-10-02|Technical Writer|101|Y|2

10022|Richard Dublin|60000.00|1965-03-19|Software Engineer|100|N|0

10023|Kelly 0'Toole|65000.00|1955-04-08|Software Tester|102|N|2

10024|Brett Jackson|75000.00|1962-04-08|Software Engineer|100|Y|2

10025|Erik Wickman|79000.00|1965-03-08|Software Engineer|100|N|2

Reference Information

Information on...

the DEFINE JOB, DEFINE SCHEMA,

DEFINE OPERATOR, and APPLY statements describing job script format rules and the function of script components

Is available in...

Chapter 3: “Object Definitions and the APPLY

Statement” in Teradata Parallel Transporter

Reference

Chapter 2: “Teradata PT Job Components” in

Teradata Parallel Transporter User Guide

Create a Job Script

Perform the following task to create a Teradata PT load job script.

Teradata Data Warehouse Appliance 2580 Implementation Guide 337

Chapter 16: Updating a Table from a Flat File

Task 1: Define Job Variables

Define values for commonly used script component, such as operator attributes, as job variables to eliminate the need to re-specify the values in each new Teradata PT job script.

Note: Use of job variables also provides the means to make passwords secure in the variables file rather than leaving them in plain view in the job script.

When a job script specifies a variable, Teradata PT automatically reads the corresponding value from the job variables file.

Procedure: Create the Job Variables File

Execute the following procedure from a Teradata client configured with Teradata PT.

Use a text editor to create a local job variables file that contains a list of variables and their corresponding values.

Define variables for the following operator attributes shown in the “Sample Update Job

Script” on page 336 . You may define additional variables as needed for your particular job

script.

Each job variable must be defined on a single line separated by commas, using the following format:

variable_name=value

DataConnector

Operator

Attribute

DirectoryPath

Variable Name

jobvar_datafile_path

Variable Value Description

The path name of the flat file

Update Operator

Attribute

TdpId

Variable Name

jobvar_tdpid

UserName

UserPassword jobvar_TDusername1 jobvar_TDpassword1

Variable Value Description

The name by which the Teradata Data

Warehouse Appliance 2580 is known to the network.

The Teradata user with access privileges to the target Teradata table.

The password of the Teradata user with access privileges to the target Teradata table.

338 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

Note: Some job variable names include a “1” to allow for creation of multiple variables of the same type.

Save the job variables file as a .txt file in the same directory from which you will save and run your Teradata PT update job script.

Example

The following shows the contents of a sample job variables file used with the sample load job script.

jobvar_datafile_path='c:\employee_data', jobvar_tdpid='Tdat3', jobvar_TDusername1='DBADMIN', jobvar_TDpassword1='passwd123'

Task 2: Customize the Sample Update Job

Script

Teradata PT scripts are composed of two sections:

•

A declarative section (in the form of DEFINE statements) that identifies the job, the

Teradata PT operators, and the form of the data in the source table.

•

An executable section (in the form of an APPLY statement) that determines how the source data is applied to the target Teradata table.

The

“Sample Update Job Script” on page 336 includes all the elements required for an update

job. You can use the sample as a template and then customize it for your needs by substituting site-specific values for the values shown in the sample.

To make the sample load job script site-specific, copy the script into a text editor, and edit it as described in the following procedures.

Note: Be sure to use the same format and punctuation as shown in the sample script.

Procedure 1: Specify the Declarative Section of the Load Job Script

The declarative section of the job script identifies the job and defines the Teradata PT components used to perform it.

Use the DEFINE JOB statement to provide a unique, user-defined name for this job script, as follows:

DEFINE JOB job_name

For example: DEFINE JOB FILE_UPDATE

The job name can also be used as the file name for the script.

Use the DESCRIPTION statement to describe the job in more detail and provide some idea of the script function. For example:

DESCRIPTION 'Updating a Teradata employee table with data from a flat file'

Teradata Data Warehouse Appliance 2580 Implementation Guide 339

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

Use DEFINE SCHEMA statements to define the structure of the source data for the producer operator and the consumer operator:

•

The DEFINE SCHEMA statement for the producer operator defines the records of the flat file.

•

The DEFINE SCHEMA statement for the consumer operator defines the columns of the target Teradata table.

If the consumer operator can use the same schema as the producer operator, you only need to define the schema for the producer operator.

In the update job script example, the records of the flat file and the Teradata table columns have the same names and the data types are similar. Therefore, both the consumer operator and the producer operator can use the same schema, so you can define a single

DEFINE SCHEMA statement that defines the schema for the DataConnector operator as follows:

DEFINE SCHEMA Employee_Schema

(

Associate_Id VARCHAR(25),

Associate_Name VARCHAR(25),

Salary VARCHAR(25),

DOB VARCHAR(10),

Job_Title VARCHAR(25),

Dept_No VARCHAR(25),

Marital_Status VARCHAR(1),

No_Of_Dependents VARCHAR(25)

); where:

Syntax Element

DEFINE SCHEMA schema_name

(

schema_specifications,

... );

Description

schema_name is the user-defined name for the schema.

Recommendation: Make the name descriptive and unique so it can easily be reused in other scripts.

Specify each record of the schema on a single line in the form record_name data_ type(size) where:

•

record_name specifies a record in the flat file (this defines the schema for the producer operator)

•

data_ type(size) specifies the record data type and size. Consider the following:

•

The (size) specification is optional.

•

data_type must be the Teradata data type that corresponds to the data type of the flat file.

Use the DEFINE OPERATOR statement to define the producer operator (the

DataConnector operator), by customizing the following portion of the sample update job script.

Note: Operator attributes shown in the example are the minimum required specifications.

340 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

DEFINE OPERATOR File_Reader

TYPE DATACONNECTOR PRODUCER

SCHEMA Employee_Schema

ATTRIBUTES

(

VARCHAR PrivateLogName = 'DataConnector_log',

VARCHAR DirectoryPath = @jobvar_datafile_path,

VARCHAR FileName

VARCHAR Format

VARCHAR OpenMode = 'read'

VARCHAR TextDelimiter = '|'

);

= 'employee_table.txt',

= 'delimited', where:

Syntax Element

DEFINE OPERATOR

operator_name

Description

operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

TYPE operator_type

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: For example: DATACONNECTOR

PRODUCER.

SCHEMA schema_name

ATTRIBUTES

(

attribute_specification

...

);

VARCHAR PrivateLogName =

'log_name',

Specify values for each attribute in the rows that follow.

VARCHAR DirectoryPath=

@jobvar_datafile_path,

'log_name'specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'DataConnector_Log'.

The DirectoryPassword attribute is assigned the value of the jobvar_datfile_path variable as defined in the job variables file. See

File” on page 338

VARCHAR FileName =

'file_name',

schema_name specifies the name of the schema used by the producer operator.

Recommendation: Specify the name given to the

file. See “Procedure: Create the Job Variables File” on page 338

VARCHAR Format = 'format',

'file_name'specifies the name of the flat file.

Recommendation: For example:

'employee_table.dat'.

'format'specifies the format of the flat file.

Recommendation: For example:

'delimited'.

Teradata Data Warehouse Appliance 2580 Implementation Guide 341

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

Syntax Element

VARCHAR OpenMode = 'mode',

VARCHAR TextDelimiter =

'delimiter',

Description

'mode'specifies the read/write access mode of the flat file.

Recommendation: For example:

'read'.

'delimiter'specifies the text delimiter the flat file uses.

Recommendation: For example:

'|'.

Use the DEFINE OPERATOR statement to define the consumer operator (the Update operator), by customizing the following portion of the sample update job script.

Note: Operator attributes shown in the example are the minimum required specifications.

DEFINE OPERATOR Update_Operator

TYPE UPDATE

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'Update_log',

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername1,

VARCHAR UserPassword = @jobvar_TDpassword1,

VARCHAR LogTable = 'employee_table_log',

VARCHAR TargetTable = 'Tables_Database.Employee'

);

Syntax Element

DEFINE OPERATOR

operator_name

Description

The operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

TYPE operator_type

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: Specify LOAD.

SCHEMA schema_name

schema_name specifies the name of the schema used by the consumer operator.

In this load job script example, the consumer operator and the producer operator can use the same schema.

Therefore, specify * to indicate that the Load operator can use the same schema as the DataConnector operator.

ATTRIBUTES

(

attribute_specification

...

);

Specify values for each attribute in the rows that follow.

342 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

Syntax Element

VARCHAR PrivateLogName =

'log_name',

VARCHAR TdpId =

@jobvar_tdpid,

VARCHAR UserName =

@jobvar_TDusername1,

VARCHAR UserPassword =

@jobvar_TDpassword1,

VARCHAR LogTable =

'log_table_name'

VARCHAR TargetTable =

target_table_name

Description

'log_name' specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'Update_log'.

The TdpId attribute is assigned the value of the

jobvar_tdpid variable as defined in the job variables

The UserName attribute is assigned the value of the

jobvar_TDusername1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 338 .

The UserPassword attribute is assigned the value of the

jobvar_TDpassword1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 338 .

log_table_name specifies the name of the restart log table that stores checkpoint information.

Recommendation: Specify a name related to the job name or target table name.

target_table_name specifies the name of the Teradata

Database target table.

Recommendation: Specify the fully qualified name of the destination table, in the form:

database_name.table_name

Procedure 2: Code the Executable Section of the Load Job Script

The executable section of the job script contains the APPLY statement. It specifies all the operations performed by the job and the objects that perform them.

The APPLY statement consists of two sections:

•

APPLY...TO

•

SELECT...FROM

as shown in the following except from the sample job script:

APPLY

('UPDATE Tables_Database.Employee_table

SET Associate_Name = :Associate_Name,

Salary = :Salary,

DOB

Job_Title

= :DOB,

= :Job_Title,

Dept_No = :Dept_No,

Marital_Status = :Marital_Status,

No_Of_Dependents = :No_Of_Dependents

WHERE Associate_Id =

'INSERT INTO Tables_Database.Employee VALUES (

:Associate_Id;'

Teradata Data Warehouse Appliance 2580 Implementation Guide 343

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

:Associate_Id

:Associate_Name,

:Salary,

:DOB,

:Job_Title,

:Dept_No,

:Marital_Status,

:No_Of_Dependents);')

INSERT FOR MISSING UPDATE ROWS

TO OPERATOR (Update_Operator)

SELECT *

FROM OPERATOR (File_Reader);

);

Code the APPLY...TO section as follows:

Syntax Element

('INSERT INTO target_table (

:column_name1,

...);'

)

INSERT FOR MISSING UPDATE ROWS

TO OPERATOR (consumer_operator

_name)

Description

Specifies that the INSERT statement inserts the data into the Teradata target table where

target_table must be the same value as defined for the TargetTable attribute in the DEFINE

OPERATOR statement for the Update_Operator.

Recommendation: Specify the fully qualified name of the destination table, in the form:

database_name.table_name

This option specifies that if a row with the requested data to be updated was not found in the table, the data will be inserted as a new row.

The option can only be used with a pair of

INSERT/UPDATE statements specified in the

APPLY statement.

To find out the total number of rows updated or inserted, check the private log where that information is captured.

consumer_operator _name specifies the name of the consumer operator that writes the data to the target table.

This must be the name given to the Load operator in the DEFINE OPERATOR statement.

Code the SELECT...FROM section as follows:

Syntax Element

SELECT *

Description

The consumer operator (Update operator) selects all the data from the producer operator named in the FROM OPERATOR statement.

344 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 16: Updating a Table from a Flat File

Task 2: Customize the Sample Update Job Script

Syntax Element

FROM OPERATOR

(producer_operator_name);

);

Description

producer_operator_name specifies the name of the producer operator that extracts the data from the source table.

This must be the name given to the DataConnector operator in the DEFINE OPERATOR statement.

Save the script with a .tpt extension in the same directory as the job variables file. See

“Procedure: Create the Job Variables File” on page 338

. The file name should be the name specified in the DEFINE JOB statement in

“Procedure 1: Specify the Declarative Section of the Load Job Script” on page 339 .

Reference Information

Information on...

the job variables used in Teradata PT sample scripts describing job script format rules and the function of script components the DEFINE JOB statement the DEFINE SCHEMA statement the DataConnector operator the DEFINE OPERATOR and APPLY statements the Update operator the APPLY statement

Is available in...

Appendix A: “Job Script Examples” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 4: “DataConnector Operator” in Teradata Parallel

Transporter Reference

Chapter 8: “DataConnector Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 16: “Update Operator” in Teradata Parallel

Transporter Reference

Chapter 20: “Update Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Teradata Data Warehouse Appliance 2580 Implementation Guide 345

Chapter 16: Updating a Table from a Flat File

Task 3: Launch Your Teradata PT Job

See

“Task 4: Monitor and Manage a Teradata PT Job” on page 160 .

Task 4: Monitor and Manage Your Active

Teradata PT Job

See

Task 5: Evaluate a Completed Teradata PT Job

See

“Task 5: Evaluate a Completed Teradata PT Job” on page 162

Task 6: Troubleshoot a Failed Job, If Necessary

See

“Task 6: Troubleshoot a Failed Job, If Necessary” on page 164 .

Checkpoint

Before leaving Chapter 16: “Updating a Table from a Flat File,”

make sure that:

√

Result

The Teradata Database table is now updated with data from a client external flat file.

You evaluated the Teradata PT job and resolved any problems with it.

Reference

•

“Task 1: Define Job Variables” on page 338

•

“Task 2: Customize the Sample

Update Job Script” on page 339

•

“Task 3: Launch Your Teradata PT

Job” on page 346 .

•

“Task 4: Monitor and Manage Your

Active Teradata PT Job” on page 346

•

Teradata PT Job” on page 346 .

•

Script” on page 348 . You may define additional variables as needed for your particular job

Necessary” on page 346 .

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

346 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 17

Exporting Data to a Flat File

You can export data from a Teradata Database table and write it to a client external flat file using Teradata Parallel Transporter (PT).

This section describes how to:

•

Create a job variables file that a Teradata PT load job script will use

•

Customize a sample load job script

•

Launch a Teradata PT job

•

Monitor and manage a Teradata PT job

•

Evaluate a completed Teradata PT job

•

Troubleshoot a failed job, if necessary

Required Tasks

The tasks in this section are required when using Teradata PT to export data from Teradata

Database to an external flat file. Perform tasks 1, 2, 3, and 5 completely and in the order presented. Tasks 4 and 6 are optional depending on job conditions and outcome.

Teradata PT Export Job Script

Teradata PT uses called operators to execute extract and write functions within job script.

The following figure illustrates exporting data from Teradata Database table and writing it to a client external flat file using Teradata PT producer and consumer operators.

Flat

File

Write

Data

DataConnector

Operator

Data

Stream

Export

Operator

Read

Data

Teradata

Database

Consumer

Operator

Producer

Operator

2550A003

•

The Export operator, called a producer operator, reads data from a Teradata Database table and writes it to (“produces”) a data stream. A data stream consists of buffers in memory that temporarily hold data.

•

The DataConnector operator, called a consumer operator, reads data from a data stream

(“consumes it”) and then writes the data to a external flat file.

Teradata Data Warehouse Appliance 2580 Implementation Guide 347

Chapter 17: Exporting Data to a Flat File

Teradata PT Export Job Script

Sample Export Job Script

The following Teradata PT job script exports data from a Teradata table and writes it into an employee flat file.

DEFINE JOB EXPORT_TO_FILE

DESCRIPTION 'Exporting rows from a Teradata employee table into a binary format employee flat file'

(

DEFINE SCHEMA Product_Source_Schema

(

Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB

Job_Title

INTDATE,

VARCHAR(25),

Dept_No SMALLINT,

Martial_Status CHAR(1),

No_Of_Dependents BYTEINT

);

DEFINE OPERATOR Export_Operator

TYPE EXPORT

SCHEMA Product_Source_Schema

ATTRIBUTES

(

VARCHAR PrivateLogname = 'Export_log'

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername,

VARCHAR UserPassword = @jobvar_TDpassword,

VARCHAR LogTable = 'employee_table_log'

VARCHAR SelectStmt = 'SELECT *

Tables_Database.Employee;'

);

DEFINE OPERATOR File_Writer

TYPE DATACONNECTOR CONSUMER

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'DataConnector_log'

VARCHAR DirectoryPath = @jobvar_datafile_path,

VARCHAR FileName = 'employee_table.dat',

VARCHAR Format = 'binary',

VARCHAR OpenMode = 'write'

);

APPLY

TO OPERATOR (File_Writer)

SELECT *

FROM OPERATOR (Export_Operator);

);

348 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 17: Exporting Data to a Flat File

Create a Job Script

Reference Information

Information on...

the DEFINE JOB, DEFINE SCHEMA, DEFINE

OPERATOR, and APPLY statements describing job script format rules and the function of script components

Is available in...

Chapter 3: “Object Definitions and the APPLY

Statement” in Teradata Parallel Transporter

Reference

Chapter 2: “Teradata PT Utility Commands” in

Teradata Parallel Transporter Reference

Create a Job Script

Perform the following task to create a Teradata PT load job script.

Task 1: Define Job Variables

Define values for commonly used script component, such as operator attributes, as job variables to eliminate the need to re-specify the values in each new Teradata PT job script.

Note: Use of job variables also provides the means to make passwords secure in the variables file rather than leaving them in plain view in the job script.

When a job script specifies a variable, Teradata PT automatically reads the corresponding value from the job variables file.

Procedure: Create the Job Variables File

Execute the following procedure from a Teradata client configured with Teradata PT.

Use a text editor to create a local job variables file that contains a list of variables and their corresponding values.

Define variables for the following operator attributes shown in the

“Sample Export Job

script.

Each job variable must be defined on a single line separated by commas, using the following format:

variable_name=value

Teradata Data Warehouse Appliance 2580 Implementation Guide 349

Chapter 17: Exporting Data to a Flat File

Task 2: Customize the Sample Update Job Script

Export Operator

Attribute

TdpId

Variable Name

jobvar_tdpid

UserName

UserPassword jobvar_TDusername1 jobvar_TDpassword1

Variable Value Description

The name by which the Teradata Data

Warehouse Appliance 2580 is known to the network.

The Teradata user with access privileges to the target Teradata table.

The password of the Teradata user with access privileges to the target Teradata table.

DataConnector

Operator

Attribute

DirectoryPath

Variable Name

jobvar_datafile_path

Variable Value Description

The path name of the flat file

Note: Some job variable names include a “1” to allow for creation of multiple variables of the same type.

Save the job variables file as a .txt file in the same directory from which you will save and run your Teradata PT export job script.

Example

The following shows the contents of a sample job variables file used with the sample load job script.

jobvar_tdpid='Tdat3', jobvar_TDusername1='DBADMIN', jobvar_TDpassword1='passwd123' jobvar_datafile_path='c:\employee_data'

Task 2: Customize the Sample Update Job

Script

Teradata PT scripts are composed of two sections:

•

A declarative section (in the form of DEFINE statements) that identifies the job, the

Teradata PT operators, and the form of the data in the source table.

•

An executable section (in the form of an APPLY statement) that determines how the source data is applied to the target Teradata table.

The

“Sample Export Job Script” on page 348

includes all the elements required for an export job. You can use the sample as a template and then customize it for your needs by substituting site-specific values for the values shown in the sample.

350 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 17: Exporting Data to a Flat File

Task 2: Customize the Sample Update Job Script

To make the sample load job script site-specific, copy the script into a text editor, and edit it as described in the following procedures.

Note: Be sure to use the same format and punctuation as shown in the sample script.

Procedure 1: Specify the Declarative Section of the Load Job Script

The declarative section of the job script identifies the job and defines the Teradata PT components used to perform it.

Use the DEFINE JOB statement to provide a unique, user-defined name for this job script, as follows:

DEFINE JOB job_name

For example: DEFINE JOB Product_Source_Schema

The job name can also be used as the file name for the script.

Use the DESCRIPTION statement to describe the job in more detail and provide some idea of the script function. For example:

DESCRIPTION 'Exporting rows from a Teradata employee table into an employee fat file'

Use DEFINE SCHEMA statements to define the structure of the source data for the producer operator and the consumer operator:

•

The DEFINE SCHEMA statement for the producer operator defines the columns of the source Teradata table.

•

The DEFINE SCHEMA statement for the consumer operator defines the records of the flat file.

If the consumer operator can use the same schema as the producer operator, you only need to define the schema for the producer operator.

In the export job script example, the Teradata table columns and the records of the flat file have the same names and the data types are similar. Therefore, both the consumer operator and the producer operator can use the same schema, so you can define a single

DEFINE SCHEMA statement that defines the schema for the Export operator as follows:

DEFINE SCHEMA Product_Source_Schema

(

Associate_Id INTEGER,

Associate_Name CHAR(25),

Salary DECIMAL(8,2),

DOB INTDATE,

Job_Title VARCHAR(25),

Dept_No SMALLINT,

Marital_Status CHAR(1),

No_Of_Dependents BYTEINT

);

Teradata Data Warehouse Appliance 2580 Implementation Guide 351

Chapter 17: Exporting Data to a Flat File

Task 2: Customize the Sample Update Job Script where:

Syntax Element

DEFINE SCHEMA schema_name

(

schema_specifications,

... );

Description

schema_name is the user-defined name for the schema.

Recommendation: Make the name descriptive and unique so it can easily be reused in other scripts.

Specify each record of the schema on a single line in the form column_name data_ type(size) where:

•

column_name specifies a column in the source table

(this defines the schema for the producer operator)

•

data_ type(size) specifies the record data type and size. Consider the following:

•

The (size) specification is optional.

•

data_type must be the Teradata data type that corresponds to the data type of the flat file.

Use the DEFINE OPERATOR statement to define the producer operator (the Export operator), by customizing the following portion of the sample export job script.

Note: Operator attributes shown in the example are the minimum required specifications.

DEFINE OPERATOR Export_Operator

TYPE EXPORT

SCHEMA *

ATTRIBUTES

(

VARCHAR PrivateLogName = 'Export_log',

VARCHAR TdpId = @jobvar_tdpid,

VARCHAR UserName = @jobvar_TDusername,

VARCHAR UserPassword = @jobvar_TDpassword,

VARCHAR LogTable = 'employee_table_log',

VARCHAR SelectStmt = 'SELECT *

FROM

);

Syntax Element

DEFINE OPERATOR

operator_name

TYPE operator_type

Description

The operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: Specify EXPORT.

352 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 17: Exporting Data to a Flat File

Task 2: Customize the Sample Update Job Script

Syntax Element

SCHEMA schema_name

Description

schema_name specifies the name of the schema used by the consumer operator.

In this load job script example, the consumer operator and the producer operator can use the same schema.

Therefore, specify * to indicate that the Load operator can use the same schema as the DataConnector operator.

Specify values for each attribute in the rows that follow.

ATTRIBUTES

(

attribute_specification

...

);

VARCHAR PrivateLogName =

'log_name',

'log_name' specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'Export_log'.

VARCHAR TdpId =

@jobvar_tdpid,

VARCHAR UserName =

@jobvar_TDusername1,

VARCHAR UserPassword =

@jobvar_TDpassword1,

The TdpId attribute is assigned the value of the

jobvar_tdpid variable as defined in the job variables

file. See “Procedure: Create the Job Variables File” on page 349

The UserName attribute is assigned the value of the

jobvar_TDusername1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 349 .

The UserPassword attribute is assigned the value of the

jobvar_TDpassword1 variable as defined in the job

variables file. See “Procedure: Create the Job Variables

File” on page 349 .

VARCHAR LogTable =

'log_table_name'

VARCHAR SelectStmt =

'SELECT statement(s)'

log_table_name specifies the name of the restart log table that stores checkpoint information.

Recommendation: Specify a name related to the job name or target table name.

SELECT statement(s) specifies Teradata SQL Select statement that selects data from the Teradata Database source table.

Recommendation: Specify the fully qualified name of the source table, in the form:

database_name.table_name

Use the DEFINE OPERATOR statement to define the consumer operator (the

DataConnector operator), by customizing the following portion of the sample export job script.

Note: Operator attributes shown in the example are the minimum required specifications.

Teradata Data Warehouse Appliance 2580 Implementation Guide 353

Chapter 17: Exporting Data to a Flat File

Task 2: Customize the Sample Update Job Script

DEFINE OPERATOR File_Writer

TYPE DATACONNECTOR CONSUMER

SCHEMA Product_Source_Schema

ATTRIBUTES

(

VARCHAR PrivateLogName = 'DataConnector_log',

VARCHAR DirectoryPath = @jobvar_datafile_path,

VARCHAR FileName = 'employee_table.dat',

VARCHAR Format = 'binary',

VARCHAR OpenMode

);

= 'write' where:

Syntax Element

DEFINE OPERATOR

operator_name

Description

The operator_name is the user-defined name for this operator definition.

Recommendation: Specify a simple name such as the name of the operator.

TYPE operator_type

operator_type specifies the type of Teradata PT operator being defined.

Recommendation: For example: DATACONNECTOR

PRODUCER.

SCHEMA schema_name

schema_name specifies the name of the schema used by the producer operator.

Recommendation: Specify the name given to the

ATTRIBUTES

(

attribute_specification

...

);

VARCHAR PrivateLogName =

'log_name',

Specify values for each attribute in the rows that follow.

'log_name'specifies the private log that contains all diagnostic trace messages the operator produces.

Recommendation: Name the log for the operator, for example:

'DataConnector_log'.

VARCHAR DirectoryPath=

@jobvar_datafile_path,

VARCHAR FileName =

'file_name',

VARCHAR Format = 'format',

The DirectoryPassword attribute is assigned the value of the jobvar_datfile_path variable as defined in the job variables file. See

“Procedure: Create the Job Variables File” on page 349

File” on page 349

'file_name'specifies the name of the flat file.

Recommendation: For example:

'employee_table.dat'.

'format'specifies the format of the flat file.

Recommendation: Specify the format of the flat file. For example:

'binary'.

354 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 17: Exporting Data to a Flat File

Task 2: Customize the Sample Update Job Script

Syntax Element

VARCHAR OpenMode = 'mode',

Description

'mode'specifies the read/write access mode of the flat file.

Recommendation: For example:

'write'.

Procedure 2: Code the Executable Section of the Load Job Script

The executable section of the job script contains the APPLY statement. It specifies all the operations performed by the job and the objects that perform them.

The APPLY statement consists of two sections:

•

APPLY...TO

•

SELECT...FROM

as shown in the following except from the sample job script:

APPLY

TO OPERATOR (File_Writer)

SELECT *

FROM OPERATOR (Export_Operator);

);

Code the APPLY...TO section as follows:

Syntax Element

TO OPERATOR (consumer_operator

_name)

Description

consumer_operator _name specifies the name of the consumer operator that writes the data to the target table.

This must be the name given to the DataConnector operator in the DEFINE OPERATOR statement.

Code the SELECT...FROM section as follows:

Syntax Element

SELECT *

FROM OPERATOR

(producer_operator_name);

);

Description

The consumer operator (DataConnector operator) selects all the data from the producer operator named in the FROM OPERATOR statement.

producer_operator_name specifies the name of the producer operator that extracts the data from the source table.

This must be the name given to the Export operator in the DEFINE OPERATOR statement.

Teradata Data Warehouse Appliance 2580 Implementation Guide 355

Chapter 17: Exporting Data to a Flat File

Task 3: Launch Your Teradata PT Job

Save the script with a .tpt extension in the same directory as the job variables file. See

. The file name should be the name specified in the DEFINE JOB statement in

“Procedure 1: Specify the Declarative Section of the Load Job Script” on page 351 .

Reference Information

Information on...

the job variables used in Teradata PT sample scripts describing job script format rules and the function of script components the DEFINE JOB statement the DEFINE SCHEMA statement the Export operator the DEFINE OPERATOR and APPLY statements the DataConnector operator the APPLY statement

Is available in...

Appendix A: “Job Script Examples” in Teradata Parallel

Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 2: “Teradata PT Job Components” in Teradata

Parallel Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 6: “Export Operator” in Teradata Parallel

Transporter Reference

Chapter 10: “Export Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Chapter 4: “DataConnector Operator” in Teradata Parallel

Transporter Reference

Chapter 8: “DataConnector Operator” in Teradata Parallel

Transporter User Guide

Chapter 3: “Object Definitions and the APPLY Statement” in Teradata Parallel Transporter Reference

Task 3: Launch Your Teradata PT Job

See

“Task 4: Monitor and Manage a Teradata PT Job” on page 160 .

356 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 17: Exporting Data to a Flat File

Task 4: Monitor and Manage Your Active Teradata PT Job

Task 4: Monitor and Manage Your Active

Teradata PT Job

See

Task 5: Evaluate a Completed Teradata PT Job

See

“Task 5: Evaluate a Completed Teradata PT Job” on page 162

Task 6: Troubleshoot a Failed Job, If Necessary

See

“Task 6: Troubleshoot a Failed Job, If Necessary” on page 164 .

Checkpoint

Before leaving Chapter 17: “Exporting Data to a Flat File,” make sure that:

√

Result

The data that was previously in Teradata

Database is exported to a client external flat file.

You evaluated the Teradata PT job and resolved any problems with it.

Reference

•

“Task 1: Define Job Variables” on page 349

•

“Task 2: Customize the Sample

Update Job Script” on page 350

•

“Task 3: Launch Your Teradata PT

Job” on page 356 .

•

“Task 4: Monitor and Manage Your

Active Teradata PT Job” on page 357

•

Teradata PT Job” on page 357 .

•

Chapter 4: “Setting Up Teradata Clients”

Necessary” on page 357 .

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 357

Chapter 17: Exporting Data to a Flat File

Checkpoint

358 Teradata Data Warehouse Appliance 2580 Implementation Guide

CHAPTER 18

Other Management Procedures

This section describes procedures that are not required for the initial set up of Teradata Data

Warehouse Appliance 2580. However, these procedures may be needed on occasion to address issues that occur during ongoing system maintenance and management.

Note: You received a Teradata Core Support card from your Teradata representative when your system was delivered. Be sure to read the important information on this card, and follow all the recommended maintenance procedures listed there.

Upgrading Teradata Software

Teradata periodically releases software patches and maintenance upgrades to customers with maintenance and support agreements. Information about these patches and upgrades is available from the Teradata @ Your Service website, at http://www.teradataatyourservice.com

Review the following on a regular basis to keep informed of any Teradata Database issues and workarounds, and to ensure that your licensed Teradata software is the most current available.

Interval

Weekly

Monthly

Quarterly

Items to Review at Teradata @ Your Service

Tech Alerts and associated software patches

Teradata Tools and Utilities client application patches and updates, as described in

Teradata Database software patch and maintenance releases

For more information on upgrading Teradata Database software, see the following publications, which are available from http://www.info.teradata.com

Publication Title

Teradata Database Upgrade Guide, Overview, and Preparation

Upgrading Teradata Software (Maintenance): Linux SLES9 SP3, SLES10 SP1,

TD 6.2, 12.0, 13.0

Parallel Upgrade Tool (PUT) for UNIX MP-RAS and Linux User Guide,

Release 3.04.06

Publication Number

B035-5921-049K

B035-5920-049K

B035-5712-049K

Teradata Data Warehouse Appliance 2580 Implementation Guide 359

Chapter 18: Other Management Procedures

Running Utilities from the CNS Command Line

There are several ways to run database-level and other maintenance and troubleshooting utilities for Teradata Data Warehouse Appliance 2580:

•

Database-level utility programs used for standard system management and maintenance are most easily run from the Database Console application of Teradata Manager, as

described in “Teradata Manager” on page 267

•

PDE-level utility programs like psh and pdestate can be run from the command line of any system node.

Note: Run the

tdatcmd command at the Linux command line to configure the Teradata

Database command-line environment prior to running any Teradata programs.

•

Database utilities that manipulate data at a low level are potentially dangerous to the system, and should be run only by trained personnel under the direction of Teradata

Customer Support. These utilities can be run only from the cnsterm program, described later in this section, or the Database Window (DBW), an X-window based graphical user interface, which is described in Utilities - Database Window (xdbw) chapter. Both cnsterm and DBW are interfaces to the Teradata Database Console Subsystem (CNS).

In situations where Teradata Manager is unavailable, any of the database utilities can be run from cnsterm. This section describes running database utilities from the cnsterm command line.

Task 1: Log 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

“Task 1: Set Up a Workstation for Use with SMWeb” on page 45 , navigate to the SMWeb Home page by

following the procedure described in

“Task 2: Access the SMWeb Home Page” on page 47

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 2580

system. The control node is typically node 8. Nodes are numbered 8, 9, 12, and 13 in the Tree View. Do not select a server management node (CMIC), Teradata MS, or BAR server (numbered 10 or 11 in the

Tree View). For the location of node 8 in the cabinet, see “Example Cabinet

Configurations” on page 29

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.

360 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Running Utilities from the CNS Command Line

Click OK.

At the command prompt, log in as root.

Task 2: Use cnsterm to Run a Database Utility

The cnsterm program is a user interface to the Console Subsystem (CNS). CNS provides six virtual interface windows:

•

Windows 1 through 4 are the 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. Use the

Supervisor window to launch database utilities, which then run in the application windows.

Note: The Supervisor window is also used to issue CNS commands to the database. For more information on CNS commands, see Chapter 11: “Database Window (xdbw)” in

Utilities: Volume 1 (A-K).

The following procedure provides access to the CNS subsystem using cnsterm. Because cnsterm is a command-line program, it allows access to only one CNS window at a time.

At the Linux prompt on the command 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:

Teradata Data Warehouse Appliance 2580 Implementation Guide 361

Chapter 18: Other Management Procedures

Running Utilities from the CNS Command Line

•

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 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

To move between the application windows and the Supervisor window, use the Ctrl-C key combination to exit one window and cnsterm n to open another.

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.

For more information on options and commands for specific utilities, see Utilities (B035-

1102-098A) available from http://www.info.teradata.com

Task 3: Use 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 as shown in

“Task 1: Log on to the Control Node” on page 360 .

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

Task 4: Grant CNS Permissions to Non-Root Users

The root/administrator user on the control node is automatically authorized to access CNS, and run all database-level utilities from cnsterm or DBW. Other users must be explicitly authorized by the administrator using the CNS grant command.

362 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Restarting the Teradata Database Software

Do the following to grant non-root users permission to access CNS and run database utilities.

Access the CNS Supervisor window by entering prompt.

cnsterm at the control node command

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. 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...

Chapter 11: “Database Window (xdbw)” in

Utilities: Volume 1 (A-K)

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

Teradata Data Warehouse Appliance 2580 Implementation Guide 363

Chapter 18: Other Management Procedures

Restarting the Teradata Database Software

As part of any restart process:

•

Teradata Database:

•

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.

•

PDE executes the various stages of the restart process.

Task 1: Initiate a Manual Restart

The database will be unavailable during the restart process, so schedule manual restarts to happen during periodic maintenance windows, or during times when database use is at a minimum. If a manual restart is required, but has not been planned for a maintenance window, notify uses that the system will be restarted, and advise them to log off the system, if possible.

For more information on scheduling periodic maintenance windows, see

“Procedure 2:

Opening a Maintenance Window” on page 67

System restarts progress through various discrete operational stages. When a manual or automatic restart is initiated, PDE executes the stages to shut down the database software and start it back up again. The pdestate utility can be used to check the status of the PDE and database (DBS) software at any time, so can be used to monitor the status of the system both before and during a restart operation.

Log on to the control node of the system, as described in “Task 1: Log on to the Control

Node” on page 360 .

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.

364 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Restarting the Teradata Database Software

For more information on the tpareset command, see Chapter 20: “TPA Reset (tpareset)” in

Utilities: Volume 2 (L-Z).

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 “Task 2: Troubleshoot Database Restarts” on page 365 .

Reference Information

Information on...

the tpareset command

Is available in...

Chapter 20: “TPA Reset (tpareset)” in Utilities:

Volume 2 (L-Z)

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.

Note automatic restarts by monitoring the AWS Fault Viewer. To ensure the database has

returned to a fully operational state, run the Vproc Manager utility as shown in “Task 2:

Troubleshoot Database Restarts” on page 365 . If system vprocs or nodes remain down or

offline, submit an incident to Customer Support using the Teradata @ Your Service website, as

described in “Task 9: Open an Incident Using Teradata @ Your Service” on page 69

Note: The system saves important aspects of the system state (a “crashdump”) whenever the system 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

“Procedure: Assign Perm Space to Crashdumps” on page 101

Task 2: Troubleshoot Database Restarts

After any database restart, do the following to verify that Teradata Database is fully functional:

Start the Vproc Manager utility (vprocmanager) using one of these methods:

•

From a Console Subsystem command line, as described in

“Running Utilities from the

CNS Command Line” on page 360

, enter: start vprocmanager

•

From Teradata Manager click Administer>Database Console to run the Database

Console tool, and on the Utilities menu click Vproc Manager.

Teradata Data Warehouse Appliance 2580 Implementation Guide 365

Chapter 18: Other Management Procedures

Powering the System Off and On

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.

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 to Customer Support using the Teradata @ Your Service website, as described in

“Task 9: Open an Incident Using

Teradata @ Your Service” on page 69

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.

Powering the System Off and On

You may need to stop the database and shut down the system hardware due to a scheduled local power outage or when directed by a Customer Service Representative. 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.

Task 1: Power 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.

366 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Powering the System Off and On

5 c d

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 (MS) 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-5713.

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, as described in

“Task 1: Log on to the Control Node” on page 360 .

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

tpareset -x down for maintenance

Enter

Type

to confirm that you want to shut down the Teradata Database, then press

Enter

To verify that the Teradata Database has stopped, type the following, then press

psh pdestate -a

Enter .

Teradata Data Warehouse Appliance 2580 Implementation Guide 367

Chapter 18: Other Management Procedures

Powering the System Off and On

The system returns a message similar to the following:

# psh pdestate -a all 2 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 SMClient, verify that the operational states of the chassis in the cabinet or system have an OK status.

In the Tree View, select System, then select the View > Status command. The Status window displays.

In the Status window, if the Hide components that have normal operational states box is checked, clear it.

For each cabinet, verify that the chassis icons are green in the Status window.

From SMClient, perform a controlled shutdown and power off of the nodes, Teradata

MSs, 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.

•

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.

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 SMClient online Help.

From SMClient, verify that the nodes and servers are powered off.

In the Status window, if the Hide components that have normal operational states box is checked, clear it.

For each cabinet, verify that the icons for the nodes and servers are black in the Status window. A black icon indicates that the node or server is powered off.

At the front of each cabinet, verify that:

The LEDs on all processing nodes are powered off.

The server management node power LEDs and status LEDs (upper right of each server management node chassis) are on.

368 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Powering the System Off and On

Power On/Off Button

Power LED

Status LED

Contol Panel

(front)

Node_0036

Note: The server management node is in position 10 (third node from the AC boxes). See

“Example Cabinet Configurations” on page 29 for the location of the server management

node in the cabinet.

At the front of each cabinet, perform a graceful shutdown of each server management node (CMIC).

Briefly (less than four seconds) press the power button on each server management node control panel.

Verify that each server management node is off. A server management node is off when the power LED and all other LEDs except the status LED on its control panel are off.

At the rear of each cabinet, use both power switches to power off each disk array.

Array_0001

Power Switches

At the front of each cabinet, switch off all of the circuit breakers on each orange and blue

AC box.

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.

Note: Switching the circuit breakers off removes power from the Ethernet switches.

Teradata Data Warehouse Appliance 2580 Implementation Guide 369

Chapter 18: Other Management Procedures

Powering the System Off and On

Top 4

Btm. 4

Circuit Breakers

Front

NEMA AC Boxes

Top 4

Btm. 4

Circuit Breakers

Top 4

Btm. 4

Circuit Breakers

IEC AC Boxes

Top 4

Btm. 4

Circuit Breakers

Power_0011

At the front of each cabinet, verify that all LEDs on the nodes, Teradata MSs, server management nodes, and disk drives are off.

At this point, all chassis in all system cabinets are powered off.

Task 2: Power On All Chassis in a System or Cabinet

At the front of each cabinet, switch on all of the circuit breakers on each orange and blue

AC box.

Note: It is not necessary to power on the server management nodes (CMICs). The server management nodes and Ethernet switches power on automatically when the circuit breakers are switched on. It takes 5-10 minutes for the server management nodes to completely power on. Status for the server management nodes and other chassis will not be available until the server management nodes have completely powered on.

At the rear of each cabinet, use both power switches to power on each disk array. It takes approximately three minutes for the disk arrays to power on completely.

From SMClient, after allowing enough time for the server management nodes to establish communication with all chassis, verify that the server management nodes and the disk arrays are operating normally before continuing.

If the Status window is not already displayed, in the Tree View, select System, then select the View > Status command. The Status window displays.

If the Hide components that have normal operational states box is checked, clear it.

370 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Powering the System Off and On

In the Status window, verify that the icon for each server management node (CMIC) is

green.

This indicates the server management nodes have booted up and have an OK status in the Tree View.

In the Status window, verify that the icon for each disk array is green.

This indicates the disk arrays have finished performing their power-on self-tests, and that they have an OK status in the Tree View.

Caution:

If the icons for the server management node (CMIC) are not green, submit an incident to

Customer Support using the Teradata @ Your Service website, as described in “Task 9: Open an Incident Using Teradata @ Your Service” on page 69

From the SWS, use Simplicity, version 9.72 or later, to verify that the disk arrays have no hardware issues.

Select Start > Programs > Simplicity Storage Manager > Simplicity Storage Manager

Client.

When the Initial Automatic Discovery window appears, click Yes.

Make sure the correct number of disk arrays are displayed (6 arrays for half cabinet; 12 arrays for full cabinet) and that the array icons are green.

Caution:

If the correct number of disk arrays are not displayed, or their icons are not green, submit an incident through Teradata @ Your Service.

From SMClient, power on the nodes, Teradata MSs, and BAR servers:

To power on the nodes and servers in one cabinet, select that cabinet in the Tree View, then select the Functions > Power On command.

6 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.

A Command Summary window displays to show the progress of the Power Off command.

Wait approximately 5-10 minutes for all nodes to boot.

From SMClient, use the Status window to 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 Tree View.

Caution:

If the icons for all the chassis in the cabinet are not green, submit an incident through

Teradata@YourService.

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-5713.

Teradata Data Warehouse Appliance 2580 Implementation Guide 371

Chapter 18: Other Management Procedures

Powering the System Off and On

8 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.

f 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 (Node 8) in the lowestnumbered cabinet. Nodes are numbered 8, 9, 12, and 13 in the Tree View. Do not select a server management node (CMIC), TMS, or BAR server (numbered 10 or 11 in the

Tree View). For the location of node 8 in the cabinet, see

“Example Cabinet

Configurations” on page 29 .

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.

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 2580 system with two nodes, the following message should display:

Net #

Nodes

Routes

Net name etho0 eth1

•

For a Teradata Data Warehouse Appliance 2580 system with four nodes, the following message should display:

Net #

Nodes

Routes

Net name eth0 eth1

372 Teradata Data Warehouse Appliance 2580 Implementation Guide

Chapter 18: Other Management Procedures

Powering the System Off and On

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

Data Warehouse Appliance 2580 system

•

Routes is the is the current number of network routing paths (usually one routing path per node)

•

Net name is the network interface name

g i

Verify that all the pdisks on all the nodes are good.

At the Teradata Command Prompt, type the following, then press

psh verify_pdisks

Enter

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

psh pdestate

The following message should display:

PDE state is DOWN/HARDSTOP

Enter :

9 i

Type in the following command to start Teradata Database and then hit Enter:

/etc/init.d/tpa start

Type the following, then 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.

Type the following, then press

tdatcmd

Enter

Type the following, then press

vprocmanager

Enter :

At the vprocmanager command prompt, type the following, then 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

Teradata Data Warehouse Appliance 2580 Implementation Guide 373

Chapter 18: Other Management Procedures

Unplanned Power Outages

If the message does not display, submit an incident through Teradata @ Your Service.

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 “Task 2: Troubleshoot

Database Restarts” on page 365

Unplanned Power Outages

In the event of an unplanned power outage:

•

Submit an incident to Customer Support using the Teradata @ Your Service website, as

described in “Task 9: Open an Incident Using Teradata @ Your Service” on page 69

•

Do not restart the database. With the help of Customer Support, perform a full system power on sequence, as described in

“Task 2: Power On All Chassis in a System or Cabinet” on page 370

Checkpoint

Before leaving Chapter 18: “Other Management Procedures,” make sure that:

√

Result

You know how to upgrade Teradata software.

You know how to run utilities from the CNS command line.

You know how to restart Teradata Database software.

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

“Upgrading Teradata Software” on page 359

“Running Utilities from the CNS

Command Line” on page 360 .

“Restarting the Teradata Database

Software” on page 363

“Powering the System Off and On” on page 366

“Unplanned Power Outages” on page 374

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

374 Teradata Data Warehouse Appliance 2580 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, such as Oracle.

Teradata Data Types

The data types supported in Teradata Database may differ from the data types in other ANSIcompliant databases. Therefore, you need to convert your data types to Teradata data types.

Be aware that even though some data types seem the same in both systems, there may be subtle differences in the way the data types are implemented. Therefore, your query may not return an error, but the results may not be as expected.

Recommendation: Always test your queries thoroughly after converting to Teradata 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

BLOB/CLOB

CHAR

DATE

FLOAT

LONG

LONG RAW

NUMBER or NUMBER(38)

NUMBER(m, n)

VARCHAR2

Teradata Data Type

BLOB/CLOB

CHAR

DATE or TIMESTAMP(0)

FLOAT

(The total number of digits cannot exceed 15)

LONG VARCHAR or VARCHAR

VARBYTE (<=64000)

DECIMAL(38)

DECIMAL(m, n)

VARCHAR

Teradata Data Warehouse Appliance 2580 Implementation Guide 375

Appendix A: Type and Format Differences Between Teradata and Other DBMS

Teradata Data Types

In Teradata, the maximum number of characters or bytes allotted to a CHAR or VARCHAR column depends on the server character set for the column. For example, if the server character set is:

•

LATIN, then the maximum value is 64,000

•

UNICODE, then the maximum value is 32,000

For Oracle users, note that Oracle does not have an INTEGER data type, but they have an alias called INTEGER that maps to the NUMBER data type. NUMBER corresponds to the

DECIMAL data type in Teradata. 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

The following table shows additional possibilities for converting the NUMBER data type.

Oracle Data Type

NUMBER(1)

NUMBER(2,n)

NUMBER(3)

NUMBER(4,n)

NUMBER(5)

NUMBER(9,n)

NUMBER(10)

NUMBER(18)

NUMBER(19,n)

NUMBER(38,n)

Teradata Data Type

BYTEINT - 8 bits or

DECIMAL(1) - 8 bits

DECIMAL(2,n) - 8 bits

BYTEINT - 8 bits or

SMALLINT - 16 bits or

DECIMAL(3) - 16 bits

DECIMAL(4,n) - 16 bits

SMALLINT - 16 bits or

INTEGER - 32 bits or

DECIMAL(5) - 32 bits

DECIMAL(9,n) - 32 bits

INTEGER - 32 bits or

DECIMAL(10) - 64 bits

BIGINT - 64 bits or

DECIMAL(18) - 64 bits

DECIMAL(19,n) - 128 bits

DECIMAL(38,n) - 128 bits

376 Teradata Data Warehouse Appliance 2580 Implementation Guide

Appendix A: Type and Format Differences Between Teradata and Other DBMS

Teradata Data Types

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

You can use the DBS Control utility (dbscontrol) to set DateForm to the following:

Setting

0 (IntegerDate)

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.

Initially, DateForm is set to IntegerDate. You can override the system-level date format for a user, session, individual DATE column or DATE value.

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.

To view the current value of the system default DATE format, enter:

HELP SESSION;

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'

Teradata Data Warehouse Appliance 2580 Implementation Guide 377

Appendix A: Type and Format Differences Between Teradata and Other DBMS

Teradata Data Types

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), and 2dimensional (polygon) 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.

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.

378 Teradata Data Warehouse Appliance 2580 Implementation Guide

Appendix A: Type and Format Differences Between Teradata and Other DBMS

Reference Information

Information on...

supported data types in Teradata Database, including UDTs geospatial types

DATE literals

DATE formats and the FORMAT phrase

Is available in...

Chapter 3: “Decimal/Numeric Data Types”SQL Data

Types and Literals

Chapter 2: “Types” in SQL Geospatial Types,

Publication number B035-1181-098A, available from http://www.info.teradata.com

“Date Literals”

in Chapter 2: “Data Literals”

SQL Data Types and Literals

Chapter 10: “Data Type Formats and Format

Phrases” using the DBS Control utility (dbscontrol) to change the DateForm setting

SQL Data Types and Literals

Chapter 12: “DBS Control (dbscontrol)” the SDF file and the Locale Definition utility (tdlocaledef)

Utilities: Volume 1 (A-K)

Chapter 2: “Locale Definition Utility (tdlocaledef)”

•

CREATE USER / MODIFY USER

•

HELP SESSION

•

SET SESSION DATEFORM

Utilities: Volume 2 (L-Z)

“CREATE USER”

in Chapter 6: “CREATE TRANSFORM - CREATE

VIEW”

SQL Data Definition Language Detailed Topics

Teradata Data Warehouse Appliance 2580 Implementation Guide 379

Appendix A: Type and Format Differences Between Teradata and Other DBMS

Reference Information

380 Teradata Data Warehouse Appliance 2580 Implementation Guide

APPENDIX B

Using 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 2580 Implementation Guide 381

Appendix B: Using BTEQ

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;

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.

382 Teradata Data Warehouse Appliance 2580 Implementation Guide

Appendix B: Using BTEQ

Loading Data Into the Teradata Database

Caution:

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.

Loading Data Into the Teradata Database

The following example loads a client data file into the Teradata Database. The data load uses one session. Consider using multiple sessions or a pack factor greater than 1 to use the ability of Teradata Database to execute SQL requests in parallel.

If the table has secondary indexes, you should probably use a small number of sessions. If the table is NO FALLBACK, you may need a large number.

Note: It is extremely important to clean your data before loading it into the system. Rollbacks and resubmittals can seriously impact performance.

BTEQ Input Stream

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

Chapter 5: “BTEQ Commands.”

“Task 4: Using Scripts to Create Database Objects” on page 145 .

Basic Teradata Query Reference

Chapter 3: “Using BTEQ,” “Running BTEQ Batch Jobs.”

Teradata Data Warehouse Appliance 2580 Implementation Guide 383

Appendix B: Using BTEQ

Loading Data Into the Teradata Database

384 Teradata Data Warehouse Appliance 2580 Implementation Guide

APPENDIX C

Advanced Features

This appendix describes advanced features that can benefit your system after it is set up and functioning smoothly.

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