Teradata Virtual Storage
Release 14.0
B035-1179-111A
January 2012
The product or products described in this book are licensed products of Teradata Corporation or its affiliates.
Teradata, Active Enterprise Intelligence, Applications Within, Aprimo, Aprimo Marketing Studio, Aster, BYNET, Claraview, DecisionCast,
Gridscale, Managing the Business of Marketing, MyCommerce, Raising Intelligence, Smarter. Faster. Wins., SQL-MapReduce, Teradata Decision
Experts, Teradata Labs Logo, Teradata Raising Intelligence Logo, Teradata Source Experts, WebAnalyst, and Xkoto are trademarks or registered
trademarks of Teradata Corporation or its affiliates in the United States and other countries.
Adaptec and SCSISelect are trademarks or registered trademarks of Adaptec, Inc.
AMD Opteron and Opteron are trademarks of Advanced Micro Devices, Inc.
EMC, PowerPath, SRDF, and Symmetrix are registered trademarks of EMC Corporation.
GoldenGate is a trademark of Oracle.
Hewlett-Packard and HP are registered trademarks of Hewlett-Packard Company.
Intel, Pentium, and XEON are registered trademarks of Intel Corporation.
IBM, CICS, RACF, Tivoli, and z/OS are registered trademarks of International Business Machines Corporation.
Linux is a registered trademark of Linus Torvalds.
LSI is a registered trademark of LSI Corporation.
Microsoft, Active Directory, Windows, Windows NT, and Windows Server are registered trademarks of Microsoft Corporation in the United
States and other countries.
NetVault is a trademark or registered trademark of Quest Software, Inc. in the United States and/or other countries.
Novell and SUSE are registered trademarks of Novell, Inc., in the United States and other countries.
Oracle, Java, and Solaris are registered trademarks of Oracle and/or its affiliates.
QLogic and SANbox are trademarks or registered trademarks of QLogic Corporation.
SAS and SAS/C are trademarks or registered trademarks of SAS Institute Inc.
SPARC is a registered trademark of SPARC International, Inc.
Symantec, NetBackup, and VERITAS are trademarks or registered trademarks of Symantec Corporation or its affiliates in the United States
and other countries.
Unicode is a registered trademark of Unicode, Inc. in the United States and other countries.
UNIX is a registered trademark of The Open Group in the United States and other countries.
Other product and company names mentioned herein may be the trademarks of their respective owners.
THE INFORMATION CONTAINED IN THIS DOCUMENT IS PROVIDED ON AN “AS-IS” BASIS, WITHOUT WARRANTY OF ANY KIND, EITHER
EXPRESS OR IMPLIED, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NON-INFRINGEMENT. SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF IMPLIED WARRANTIES, SO THE ABOVE EXCLUSION
MAY NOT APPLY TO YOU. IN NO EVENT WILL TERADATA CORPORATION BE LIABLE FOR ANY INDIRECT, DIRECT, SPECIAL, INCIDENTAL,
OR CONSEQUENTIAL DAMAGES, INCLUDING LOST PROFITS OR LOST SAVINGS, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
The information contained in this document may contain references or cross-references to features, functions, products, or services that are
not announced or available in your country. Such references do not imply that Teradata Corporation intends to announce such features,
functions, products, or services in your country. Please consult your local Teradata Corporation representative for those features, functions,
products, or services available in your country.
Information contained in this document may contain technical inaccuracies or typographical errors. Information may be changed or updated
without notice. Teradata Corporation may also make improvements or changes in the products or services described in this information at any
time without notice.
To maintain the quality of our products and services, we would like your comments on the accuracy, clarity, organization, and value of this
document. Please email: [email protected].
Any comments or materials (collectively referred to as “Feedback”) sent to Teradata Corporation will be deemed non-confidential. Teradata
Corporation will have no obligation of any kind with respect to Feedback and will be free to use, reproduce, disclose, exhibit, display, transform,
create derivative works of, and distribute the Feedback and derivative works thereof without limitation on a royalty-free basis. Further, Teradata
Corporation will be free to use any ideas, concepts, know-how, or techniques contained in such Feedback for any purpose whatsoever, including
developing, manufacturing, or marketing products or services incorporating Feedback.
Copyright © 2010 - 2012 by Teradata Corporation. All Rights Reserved.
Preface
Purpose
This book describes the optional Teradata Virtual Storage (VS) product.
Audience
This book is intended for database administrators and other technical personnel responsible
for designing and administering Teradata Database.
Supported Software Releases and Operating
Systems
This book supports Teradata® Database 14.0.
Teradata Database 14.0 is supported on:
•
SUSE Linux Enterprise Server (SLES)10
•
SLES 11
Note that SLES 11 will be supported after the initial release of Teradata Database 14.0.
Teradata Database client applications support other operating systems.
Prerequisites
You should be familiar with Teradata Database SQL DDL and DML, and database design
strategies.
For more information on these topics, refer to the following Teradata Database manuals:
Teradata Virtual Storage
•
SQL Data Definition Language
•
SQL Data Manipulation Language
•
Database Design
3
Preface
Changes to This Book
Changes to This Book
Release
Description
Teradata Database 14.0
January 2012
• Updated description of FORCE command tid syntax element.
• Updated Syntax Diagram Conventions in Appendix A to mention
mixed-case words in syntax diagrams.
Teradata Database 14.0
November 2011
• Changed “Vss” prefixed RSS table column names to use “Tvs” instead.
• Updated output example for SHOWCYLALLOC.
• Added information about Teradata Viewpoint support for Teradata VS.
Additional Information
URL
Description
www.info.teradata.com/
Use the Teradata Information Products Publishing Library site
to:
• View or download a manual:
1 Under Online Publications, select General Search.
2 Enter your search criteria and click Search.
• Download a documentation CD-ROM:
1 Under Online Publications, select General Search.
2 In the Title or Keyword field, enter CD-ROM, and click
Search.
• Order printed manuals:
Under Print & CD Publications, select How to Order.
www.teradata.com
The Teradata home page provides links to numerous sources of
information about Teradata. Links include:
• Executive reports, case studies of customer experiences with
Teradata, and thought leadership
• Technical information, solutions, and expert advice
• Press releases, mentions and media resources
4
www.teradata.com/t/TEN/
Teradata Customer Education designs, develops and delivers
education that builds skills and capabilities for our customers,
enabling them to maximize their Teradata investment.
www.teradataatyourservice.com
Use Teradata @ Your Service to access Orange Books, technical
alerts, and knowledge repositories, view and join forums, and
download software patches.
Teradata Virtual Storage
Preface
Teradata Database Optional Features
URL
Description
developer.teradata.com/
Teradata Developer Exchange provides articles on using
Teradata products, technical discussion forums, and code
downloads.
To maintain the quality of our products and services, we would like your comments on the
accuracy, clarity, organization, and value of this document. Please email [email protected].
Teradata Database Optional Features
This book may include descriptions of the following optional Teradata Database features and
products:
•
Teradata Row Level Security
•
Temporal Table Support
•
Teradata Columnar
•
Teradata Virtual Storage (VS)
You may not use these features without the appropriate licenses. The fact that these features
may be included in product media or downloads, or described in documentation that you
receive, does not authorize you to use them without the appropriate licenses.
Contact your Teradata sales representative to purchase and enable optional features.
Teradata Virtual Storage
5
Preface
Teradata Database Optional Features
6
Teradata Virtual Storage
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Supported Software Releases and Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
Changes to This Book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Additional Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4
Teradata Database Optional Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5
Chapter 1: Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Benefits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Chapter 2: Tuning and Troubleshooting Teradata VS . . . . . . . . . 11
Tuning Teradata VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
AutoCylPackColdData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Storage Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Troubleshooting Teradata VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
SHOWCYLALLOC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SHOWWHERE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Chapter 3: Specifying Data Temperatures. . . . . . . . . . . . . . . . . . . . . . . 21
TVSTemperature Query Bands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Ferret Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
BEGIN OPTIMIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
CANCEL OPTIMIZE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
FORCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Teradata Virtual Storage
7
Table of Contents
Chapter 4: Resource Usage Table Columns
for Teradata VS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
About the Mode Column . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
ResUsageSpdsk Table Migration Columns. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .29
ResUsageSvdsk Table Migration Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
ResUsageSvpr Table Node Agent Columns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
Appendix A: How to Read Syntax Diagrams . . . . . . . . . . . . . . . . . . . . .33
Syntax Diagram Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33
Appendix B: Starting the Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .39
Starting Utilities from Database Window. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .40
Starting Utilities from the Linux Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Starting Utilities from HUTCNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .43
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
8
Teradata Virtual Storage
CHAPTER 1
Overview
Teradata Virtual Storage (VS):
•
Allocates storage
•
Keeps track of where data is stored on the physical media
•
Maintains statistics on the data temperature (frequency of access) and on the grade
(performance metric of storage locations)
•
Automatically migrates more frequently accessed data to faster physical storage and less
frequently accessed data to slower physical storage
Benefits
Storage Optimization, Data Migration, and Data Evacuation
Mixing storage technologies (device types, speeds, capacities) in a parallel architecture
typically requires significant user interaction to ensure that the most frequently accessed data
is stored on the fastest storage. Teradata VS automates this process, transparently moving this
important data to storage media that offers the fastest I/O performance.
Teradata VS maintains statistics on the data temperature and on the grade. This allows
Teradata VS to intelligently migrate more frequently accessed data to faster physical storage.
As data access patterns change, Teradata VS can move storage cylinders to faster or slower
physical storage within each clique to improve system performance over time.
Teradata VS can migrate all data from one physical storage device to another to prepare for
removal or replacement of the physical device. This process is called evacuation. Complete
data evacuation requires a system restart, but Teradata VS supports a soft evacuation feature
that allows much of the data to be migrated while the system remains online. This can
minimize system down time when evacuations are necessary.
Lower Barriers to System Growth
Device management features of Teradata VS provide the ability to pool storage within each
clique. Each storage device (pdisk) can be shared, if necessary, by all AMPs in a clique. If the
number of storage devices is not a multiple of the number of AMPs in the clique, the extra
storage is shared. Consequently, storage can be added to the system in smaller increments, as
needs and opportunities arise.
Teradata Virtual Storage
9
Chapter 1: Overview
Considerations
Mixed Storage Support
Teradata VS supports the use of different disk types, capacities, and speeds used within
cliques. As new types of physical storage (such as new disk sizes and types) become available
and are certified for use with Teradata Database, they can be added to any clique.
Considerations
Default Behavior
If you do not purchase Teradata VS, temperature-based data migration provided by Teradata
VS will not be active. To enable Teradata VS, speak with your Teradata sales representative.
Note: Temperature-based block-level data compression (TBBLC) can be enabled regardless of
purchase of TVS. For more information on TBBLC, see Database Administration and Utilities.
Initial Data Temperature
When data is loaded into a new table, the system does not know whether that data will be hot
(accessed frequently) or cold (accessed infrequently), so it is initially assigned the temperature
specified by the appropriate Storage setting in DBS Control. Typically, you can allow the
system to set the temperature according to this setting.
Over time, Teradata VS monitors data access patterns, assigns table data a temperature based
on those access patterns, and moves data between faster and slower storage to place the hotter
data on faster physical storage.
For tables with very specific data access requirements, you can use the TVSTemperature query
band (at load time) or the Ferret FORCE command (soon after a table is created) to expedite
the time required to place the data into the proper storage grade.
Note: Only use the TVSTemperature query band or the Ferret FORCE command when you
know that the standard background migration will not support data access of a new table.
Teradata VS monitors frequency of data access and adjusts data temperatures dynamically as it
monitors frequency of data access. Consequently, temperatures can change from those
specified using the TVSTemperature query band or the FORCE command, if the measured
frequency of actual data access differs from the temperature that is initially set.
10
Teradata Virtual Storage
CHAPTER 2
Tuning and Troubleshooting
Teradata VS
This chapter provides information on using DBS Control and Ferret utilities to tune and
troubleshoot Teradata VS. See Utilities for more information on working with the DBS
Control and Ferret utilities.
The Virtual Storage collector and TVS Monitor portlet of Teradata Viewpoint allow you to
collect and view statistics on data temperature and storage grade of cylinders allocated in
Teradata VS. Statistics reflect current relationships between data temperature and storage
grade, and historical trends in the management of storage grades based on data temperature.
Temperature and grade metrics can help assess storage requirements for data, as well as aid in
fine tuning the balance between disk performance and data-access demands. For more
information about the TVS Monitor portlet, see Teradata Viewpoint User Guide.
Teradata Virtual Allocation Manager (TVAM) is a tool for managing storage optimization and
data migration aspects of Teradata VS. It should be used only under the direction of Teradata
Support Center personnel. Tvam documentation includes a man page and online help.
Tuning Teradata VS
Some aspects of Teradata VS are controlled by these settings in the DBS Control utility:
Teradata Virtual Storage
•
“AutoCylPackColdData”
•
“Storage Group”
•
All Other Temperature
•
DEPOT Temperature
•
GLOBAL TEMP Fallback Temperature
•
GLOBAL TEMP Fallback CLOB Temperature
•
GLOBAL TEMP Primary Temperature
•
GLOBAL TEMP Primary CLOB Temperature
•
PERMANENT JOURNAL Temperature
•
PERM Fallback Temperature
•
PERM Fallback CLOB Temperature
•
PERM Primary Temperature
•
PERM Primary CLOB Temperature
•
SPOOL Temperature
•
WAL Temperature
11
Chapter 2: Tuning and Troubleshooting Teradata VS
AutoCylPackColdData
AutoCylPackColdData
Purpose
Determines whether AutoCylPack (automatic background cylinder packing) operations are
performed on cylinders that store cold (infrequently accessed) data, in addition to cylinders
storing more frequently accessed data.
Note: This field is effective only when temperature-based block-level compression is enabled
or on systems that have licensed Teradata Virtual Storage.
Field Group
File System
Valid Settings
Setting
Description
TRUE
AutoCylPack processes cylinders holding cold data.
FALSE
AutoCylPack ignores cylinders holding cold data.
Default
FALSE
Changes Take Effect
After the DBS Control Record has been written.
Related Topics
12
For more information on…
See…
DBS Control settings related to
AutoCylPack and
temperature-based block-level
compression
Utilities: Volume 1 (A-K),
Free Space Percent
• FreeSpacePercent and SHOWFSP in Utilities: Volume 1 (A-K).
• Database Administration
Teradata Virtual Storage
Chapter 2: Tuning and Troubleshooting Teradata VS
Storage Group
Storage Group
Purpose
Each setting in the Storage group specifies the initial temperature that will be assigned to data
loaded or inserted into empty subtables of a particular type. The temperature represents the
expected frequency of access to that data, and can determine whether the data is compressed,
and where the data is stored.
Note: Because the frequency of access is continually monitored by Teradata Database, the
temperature can change over time from the initial temperature setting.
The individual Storage setting names and defaults are listed below. These settings are relevant
and visible only when temperature-based block level compression is enabled, or on systems
that have licensed Teradata Virtual Storage (VS).
Storage Setting Name
Default Temperature
DEPOT Temperature
HOT
GLOBAL TEMP Fallback Temperature
WARM
GLOBAL TEMP Fallback CLOB Temperature
WARM
GLOBAL TEMP Primary Temperature
WARM
GLOBAL TEMP Primary CLOB Temperature
WARM
PERMANENT JOURNAL Temperature
HOT
PERM Fallback Temperature
WARM
PERM Fallback CLOB Temperature
WARM
PERM Primary Temperature
WARM
PERM Primary CLOB Temperature
WARM
SPOOL Temperature
HOT
WAL Temperature
HOT
All Other Temperature
WARM
Controls initial data temperature set for data loaded into empty subtables
that are not specifically controlled by other Storage group settings.
Teradata Virtual Storage
13
Chapter 2: Tuning and Troubleshooting Teradata VS
Troubleshooting Teradata VS
Valid Settings
Setting
Description
HOT
Data is expected to be accessed frequently.
WARM
Data is expected to be accessed moderately frequently.
COLD
Data is expected to be accessed infrequently.
DEFAULT
Uses the default temperature for this type of data. Resets the setting to the factory
default value for the specified table or data type.
Changes Take Effect
After the DBS Control record has been written.
Usage Notes
The Storage settings are honored when data is loaded into empty tables by any of the
following techniques:
•
INSERT/INSERT ... SELECT statement
•
CREATE TABLE AS ... WITH DATA statement
•
CREATE JI statement
•
Load utilities TPump, FastLoad, MultiLoad, Teradata Parallel Transporter
•
Teradata Archive/Recovery (ARC) utility
•
Table Rebuild utility
Note: The TVSTemperature query bands and the Ferret FORCE command override these
storage settings.
Because data temperature is assigned at the cylinder level, after initial assignment, data in
different partitions of a partitioned table can have different temperatures.
For systems licensed to use Teradata VS, data can be automatically moved (migrated) to faster
or slower grades of storage as data temperatures change due to changing data access patterns.
Troubleshooting Teradata VS
You can use the following Ferret commands to troubleshoot Teradata VS.
14
Command
Valid SCOPE Options
Function
“SHOWCYLALLOC”
Vprocs
Shows a summary of the number of allocated
and free cylinders on the system categorized by
the performance grade of their storage.
Teradata Virtual Storage
Chapter 2: Tuning and Troubleshooting Teradata VS
Troubleshooting Teradata VS
Teradata Virtual Storage
Command
Valid SCOPE Options
Function
“SHOWWHERE”
Vprocs, tables, or
WAL log
Displays information about cylinder allocation,
grade, and temperature
15
Chapter 2: Tuning and Troubleshooting Teradata VS
SHOWCYLALLOC
SHOWCYLALLOC
Purpose
Shows a summary of the number of allocated and free cylinders on the system, categorized by
the performance grade of the storage media where they are stored.
Syntax
SHOWCYLALLOC
SHOWC
1102A244
Example
SYSTEM WIDE CYLINDER ALLOCATION SUMMARY
+---------------+-------------------+-------------------+-------------------+----------------+
|
STORAGE
|
TOTAL
|
ALLOCATED
|
FREE
|
FREE GBs
|
|
|-------------------|-------------------|-------------------|
|
|
| SMALL | LARGE* | SMALL | LARGE* | SMALL | LARGE* |
|
+---------------+---------+---------+---------+---------+---------+---------+----------------+
| FAST RESERVED |
2518 |
1682 |
21 |
17 |
2497 |
1665 |
24.755028 |
+---------------+---------+---------+---------+---------+---------+---------+----------------+
| FAST
|
2016 |
1345 |
0 |
91 |
2016 |
1254 |
18.912706 |
+---------------+---------+---------+---------+---------+---------+---------+----------------+
| MEDIUM
|
5544 |
3701 |
0 |
1 |
5544 |
3700 |
55.001480 |
+---------------+---------+---------+---------+---------+---------+---------+----------------+
| SLOW
|
2585 |
1672 |
0 |
0 |
2585 |
1672 |
25.012749 |
+---------------+---------+---------+---------+---------+---------+---------+----------------+
* Reported in units of Large Cylinders
(A Large Cylinder is 6 times the size of a small cylinder)
Related Topics
16
•
“BEGIN OPTIMIZE” on page 24
•
“CANCEL OPTIMIZE” on page 25
•
“FORCE” on page 26
Teradata Virtual Storage
Chapter 2: Tuning and Troubleshooting Teradata VS
SHOWWHERE
SHOWWHERE
Purpose
The SHOWWHERE command displays information about cylinder allocation, grade, and
temperature. This command is available only if temperature-based block-level compression
(TBBLC) or Teradata Virtual Storage (VS) is enabled.
Syntax
SHOWWHERE
SHOWW
/S
/M
/L
1102A197
where:
Syntax Element
Description
/S
Displays a summary listing of the cylinders showing one line for every unique
combination of cylinder type and grade (PERM FAST, PERM MEDIUM,
PERM SLOW, WAL FAST, WAL MEDIUM, and so forth).
This is the default.
/M
Displays a medium length listing of the cylinders with one line for every
unique combination of cylinder type and grade per AMP (vproc).
/L
Displays a long listing of the cylinders with one line for every unique
combination of cylinder type and grade per AMP (vproc) per storage device.
Usage Notes
Display output is limited to cylinders in the current SCOPE (one or more vprocs, tables, or the
WAL log). If no scope has been specified, SHOWWHERE shows information for all cylinders.
For more information, see SCOPE in the Ferret chapter of Utilities: Volume 1 (A-K).
If temperature information is not available for the current scope, SHOWWHERE returns an
error.
In order to display storage grade (I/0 speed) information, the storage devices must have
already been profiled. For more information, contact the Teradata Support Center.
Teradata Virtual Storage
17
Chapter 2: Tuning and Troubleshooting Teradata VS
SHOWWHERE
Example
Ferret ==>
showwhere
SHOWWHERE result for Each AMP
+-------------+------------+------------------+------------------------+
Vproc
|
# of
|
Type
|
|
Temperature
|
Num
|
Cyls
|
|
Grade
%
| %HOT
%WARM
%COLD
|
+-------------+------------+------------------+-------+-------+--------+
|
32*
|
PERM |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
PERM | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PERM |
SLOW
|
0% |
0% |
0% |
0%
|
|
4
|
WAL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL |
SLOW
|
0% |
0% |
0% |
0%
|
|
6
|
DEPOT |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
DEPOT | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
DEPOT |
SLOW
|
0% |
0% |
0% |
0%
|
|
28
|
WAL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
|
SPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
SPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
SPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
4*
| SPOOL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
| SPOOL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
| SPOOL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
|GLOBAL TEMP |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|GLOBAL TEMP | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|GLOBAL TEMP |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
|
JRNL |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
JRNL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
JRNL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
|
PSPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
PSPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PSPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
TOTAL
|
302
|
|
FAST
| 100% | 28% |
0% | 72%
|
|
0
|
| MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
|
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
* Reported in units of Large Cylinders
(A Large Cylinder is 6 times the size of a small cylinder)
Ferret ==>
showwhere /m
SHOWWHERE result for Each AMP
+-------------+------------+------------------+------------------------+
Vproc
|
# of
|
Type
|
|
Temperature
|
Num
|
Cyls
|
|
Grade
%
| %HOT
%WARM
%COLD
|
+-------------+------------+------------------+-------+-------+--------+
0
|
17*
|
PERM |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
PERM | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PERM |
SLOW
|
0% |
0% |
0% |
0%
|
|
2
|
WAL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL |
SLOW
|
0% |
0% |
0% |
0%
|
|
3
|
DEPOT |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
DEPOT | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
DEPOT |
SLOW
|
0% |
0% |
0% |
0%
|
|
14
|
WAL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
SPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
SPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
SPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
| SPOOL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
| SPOOL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
| SPOOL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|GLOBAL TEMP |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|GLOBAL TEMP | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|GLOBAL TEMP |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
JRNL |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
JRNL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
JRNL |
SLOW
|
0% |
0% |
0% |
0%
|
18
Teradata Virtual Storage
Chapter 2: Tuning and Troubleshooting Teradata VS
SHOWWHERE
1
TOTAL
|
1*
|
PSPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
PSPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PSPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
+-------------+------------+------------------+-------+-------+--------+
|
15*
|
PERM |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
PERM | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PERM |
SLOW
|
0% |
0% |
0% |
0%
|
|
2
|
WAL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL |
SLOW
|
0% |
0% |
0% |
0%
|
|
3
|
DEPOT |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
DEPOT | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
DEPOT |
SLOW
|
0% |
0% |
0% |
0%
|
|
14
|
WAL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
SPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
SPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
SPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
| SPOOL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
| SPOOL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
| SPOOL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|GLOBAL TEMP |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|GLOBAL TEMP | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|GLOBAL TEMP |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
JRNL |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
JRNL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
JRNL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
PSPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
PSPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PSPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
+-------------+------------+------------------+-------+-------+--------+
|
302
|
|
FAST
| 100% | 28% |
0% | 72%
|
|
0
|
| MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
|
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
* Reported in units of Large Cylinders
(A Large Cylinder is 6 times the size of a small cylinder)
Ferret ==>
showwhere /l
You have indicated that you want to do a long display for
the SHOWWHERE command. Please be aware that the output can be
extremely large.
Do you wish to continue?? (Y/N)
y
SHOWWHERE result for Each AMP
+-------------+------------+------------------+------------------------+
Vproc
|
# of
|
Type
|
|
Temperature
|
Num Disk |
Cyls
|
|
Grade
%
| %HOT
%WARM
%COLD
|
+-------------+------------+------------------+-------+-------+--------+
0
0
|
17*
|
PERM |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
PERM | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PERM |
SLOW
|
0% |
0% |
0% |
0%
|
|
2
|
WAL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL |
SLOW
|
0% |
0% |
0% |
0%
|
|
3
|
DEPOT |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
DEPOT | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
DEPOT |
SLOW
|
0% |
0% |
0% |
0%
|
|
14
|
WAL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
SPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
SPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
SPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
| SPOOL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
| SPOOL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
| SPOOL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|GLOBAL TEMP |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|GLOBAL TEMP | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|GLOBAL TEMP |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
JRNL |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
JRNL | MEDIUM
|
0% |
0% |
0% |
0%
|
Teradata Virtual Storage
19
Chapter 2: Tuning and Troubleshooting Teradata VS
SHOWWHERE
|
0*
|
JRNL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
PSPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
PSPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PSPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
SUB-TOTAL |
157
|
|
FAST
| 100% | 27% |
0% | 73%
|
|
0
|
| MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
|
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
1
1
|
15*
|
PERM |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
PERM | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PERM |
SLOW
|
0% |
0% |
0% |
0%
|
|
2
|
WAL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL |
SLOW
|
0% |
0% |
0% |
0%
|
|
3
|
DEPOT |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
DEPOT | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
DEPOT |
SLOW
|
0% |
0% |
0% |
0%
|
|
14
|
WAL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0
|
WAL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
WAL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
SPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
SPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
SPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
2*
| SPOOL POOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
| SPOOL POOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
| SPOOL POOL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|GLOBAL TEMP |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|GLOBAL TEMP | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|GLOBAL TEMP |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
JRNL |
FAST
| 100% |
0% |
0% | 100%
|
|
0*
|
JRNL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
JRNL |
SLOW
|
0% |
0% |
0% |
0%
|
|
1*
|
PSPOOL |
FAST
| 100% | 100% |
0% |
0%
|
|
0*
|
PSPOOL | MEDIUM
|
0% |
0% |
0% |
0%
|
|
0*
|
PSPOOL |
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
SUB-TOTAL |
145
|
|
FAST
| 100% | 30% |
0% | 70%
|
|
0
|
| MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
|
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
TOTAL
|
302
|
|
FAST
| 100% | 28% |
0% | 72%
|
|
0
|
| MEDIUM
|
0% |
0% |
0% |
0%
|
|
0
|
|
SLOW
|
0% |
0% |
0% |
0%
|
+-------------+------------+------------------+-------+-------+--------+
* Reported in units of Large Cylinders
(A Large Cylinder is 6 times the size of a small cylinder)
20
Teradata Virtual Storage
CHAPTER 3
Specifying Data Temperatures
Normally, Teradata VS monitors the frequency of data access at the cylinder level, and
periodically migrates cylinders that store more frequently accessed (hotter) data to faster
storage media, and less frequently accessed (colder) data to slower storage media. The
monitoring process requires some time to gauge the frequency of access, before data can be
migrated to appropriate media.
The temperature that is assigned to new data, before it has been migrated for the first time, is
normally determined by defaults set in DBS Control. This chapter discusses techniques for
explicitly specifying data temperatures, which can precede or override the normal monitoring
and migration process.
For more information on the benefits and considerations of specifying and changing data
temperatures, see “Chapter 1 Overview.”
TVSTemperature Query Bands
TVSTemperature query bands can be used to specify an initial temperature setting for subsets
of table data. This allows the data to be stored on access-appropriate media sooner than the
normal Teradata VS monitoring and migration process would otherwise provide. Use the
TVSTemperature query bands when the frequency of access for different kinds of data is
known or can be anticipated. The following TVSTemperature query bands can be used in any
combination.
Query Band
Sets Initial Temperature For
TVSTEMPERATURE
Data for which a temperature is not specified by other
TVSTemperature query bands.
If this query band is not used, the initial temperature
set for this data follows the defaults specified by the
Storage settings in DBS Control.
TVSTEMPERATURE_PRIMARY
Primary data for tables and secondary indexes
TVSTEMPERATURE_PRIMARYCLOB
Primary data for CLOBs
TVSTEMPERATURE_FALLBACK
Fallback data for tables and secondary indexes
TVSTEMPERATURE_FALLBACKCLOB
Fallback data for CLOBs
Each of the query bands can be set to either COLD, WARM, or HOT.
Teradata Virtual Storage
21
Chapter 3: Specifying Data Temperatures
TVSTemperature Query Bands
Query Band Value
Set For Data Expected to be Accessed
COLD
Infrequently. Data is stored initially on relatively slow media.
WARM
Moderately frequently. Data is stored on media of moderate speed.
HOT
Very frequently. Data is stored initially on the fastest media.
Note: Although the data is initially stored on media that corresponds to the temperature set
by the query bands, if subsequent monitoring by Teradata Database indicates the data is
accessed more or less frequently than the set temperature, the data can be migrated to other
media.
These query bands are used with load utilities such as FastLoad, MultiLoad, Teradata Parallel
Data Pump. The following SQL statements, used to populate tables, support the temperatures
that have been set using the TVSTemperature query bands:
•
INSERT into an empty table
•
INSERT ... SELECT into an empty table
•
MERGE inserts into an empty table
•
CREATE TABLE ... AS ... WITH DATA
•
CREATE HASH INDEX
•
CREATE JOIN INDEX
Example 1
A customer is loading five years of historical data (not previously stored in the Teradata
Database) and intends to perform some background analytics. Given the age of the data and
the relatively light usage being planned, this data should reside on slow storage intended for
infrequently accessed data. Without TVSTemperature, the newly loaded data would be stored
on cylinders having the default temperature, specified in DBS Control, and subsequently
migrated over time to cold storage, as the system determines that the data is infrequently
accessed. Loading it directly to cold storage makes sense in this instance since the likely
frequency of data access is clearly known.
Example 2
The following SQL statement causes the temperature for all fallback data loaded into an
empty table during the current session to be classified as COLD, and stored on storage media
(or portions of storage devices) that are graded as slow in relation to the other storage media.
SET QUERY_BAND = 'TVSTEMPERATURE_FALLBACK = COLD;' FOR SESSION;
Example 3
The following SQL statement causes the temperature for all primary data loaded into an
empty table during the current session to be classified as HOT, and stored on relatively fast
storage media. All other types of data loaded during this session will be classified as COLD.
22
Teradata Virtual Storage
Chapter 3: Specifying Data Temperatures
Ferret Commands
SET QUERY_BAND = 'TVSTEMPERATURE_PRIMARY = HOT;
TVSTEMPERATURE = COLD;'
FOR SESSION;
Related Topics
For more information on ...
See ...
Data temperatures
Database Design
Query bands
SQL Data Definition Language Detailed Topics
Storage settings in DBS Control
Utilities
CREATE TABLE, CREATE JOIN INDEX,
CREATE HASH INDEX statements
SQL Data Definition Language
INSERT, INSERT ... SELECT, MERGE
statements
SQL Data Manipulation Language
Ferret Commands
You can use the following Ferret utility commands to start an immediate Teradata VS
migration, or explicitly set the data temperature of table rows or partitions at any time.
Teradata Virtual Storage
Command
Valid SCOPE Options
Function
“BEGIN OPTIMIZE”
None
Initiates immediate, high-priority migrations
necessary to move cylinders modified by the
FORCE command to appropriate classes of
storage. Normal migration is a background,
lower priority process.
“CANCEL OPTIMIZE”
None
Halts the immediate migration that was started
by the BEGIN OPTIMIZE command, and
returns migrations to a lower priority
background process.
“FORCE”
Vprocs
Sets the classification of cylinders occupied by a
table to a specified data temperature value,
regardless of table data access history.
23
Chapter 3: Specifying Data Temperatures
BEGIN OPTIMIZE
BEGIN OPTIMIZE
Purpose
Initiates immediate, high-priority migrations necessary to move cylinders modified by the
FORCE command to appropriate classes of storage. Normal migration is a background
process with a lower priority.
Note: Performance can be negatively impacted if you use the OPTIMIZE command during
peak hours.
Syntax
BEGIN OPTIMIZE
BEG OPT
1102A247
Usage Notes
Migrations resulting from BEGIN OPTIMIZE occur at the maximum possible speed, without
regard to potential impacts to existing workloads. Because cylinders marked HOT or COLD
using the FORCE command are at the maximum temperature extremes, these cylinders are
likely to be the first selected for migration, depending on available space.
If space on storage media of appropriate performance grade is not available, some cylinders
are moved out of FAST and SLOW storage locations to make room for the HOT and COLD
table data, respectively.
Example
Ferret ==>
> begin optimize
BEGIN OPTIMIZE command could consume significant system resources
Do you wish to continue?? (Y/N)
> Y
Optimization has been started on all vprocs
If you wish to revert this optimization to a low level background mode,
you can issue a CANCEL OPTIMIZE command
Related Topics
24
•
“CANCEL OPTIMIZE” on page 25
•
“FORCE” on page 26
•
“SHOWCYLALLOC” on page 16
Teradata Virtual Storage
Chapter 3: Specifying Data Temperatures
CANCEL OPTIMIZE
CANCEL OPTIMIZE
Purpose
Halts the high-priority optimization data migration that was begun by the BEGIN OPTIMIZE
command. Migration for the process of data storage optimization reverts to the normal lowerpriority background process. The normal background migration process imposes a minimal
workload on system resources.
Syntax
CANCEL OPTIMIZE
CANCEL OPT
1102A246
Example
Ferret ==>
> cancel optimize
Optimization has been stopped on all vprocs
Related Topics
Teradata Virtual Storage
•
“BEGIN OPTIMIZE” on page 24
•
“FORCE” on page 26
•
“SHOWCYLALLOC” on page 16
25
Chapter 3: Specifying Data Temperatures
FORCE
FORCE
Purpose
Sets the cylinders occupied by a table or range of rows, to a specified data temperature,
regardless of how frequently the data has been historically accessed.
Syntax
FORCE
tid
TEMPERATURE =
rowspec
TO rowspec
HOT
WARM
COLD
1102A245
Syntax Element
Descriptions
tid
Identifies the subtable for which cylinder temperatures are set.
A tid consists of a unique identifier for the table plus an identifier for one
subtable component of the table, such as the primary data subtable.
The table can be uniquely identified in either of two ways:
1 Specify the name of the database to which the table belongs and the
table name, separated by a period. The names individually or together
must be delimited. The following formats are valid:
• "database_name.table_name"
• "database_name"."table_name"
• 'database_name.table_name'
• 'database_name'.'table_name'
2 Specify the unique numeric identifier of the table, which consists of
two numeric values separated by a space. The unique table identifier is
the first two numeric values returned by the TABLEID command.
These two numbers are common to all subtables that comprise the
table.
Note: The format of the input numbers depends on the current radix
setting, which is displayed by the RADIX command.
The second part of the tid identifies the subtable, and is called a
type_and_index. This value can be represented in a number of ways,
which are explained in the Ferret chapter of Utilities and Filer chapter of
Support Utilities. The primary data subtable has a numeric
type_and_index value of decimal 1024 or hex 400. Specifying a 0 causes
the FORCE command to be applied to all subtables of the table.
26
Teradata Virtual Storage
Chapter 3: Specifying Data Temperatures
FORCE
Syntax Element
Descriptions
rowspec [TO rowspec]
• For a nonpartitioned NoPI table, the row or range of rows for which a
data temperature is to be set.
• For a partitioned table, the “combined partition number” that
identifies the partition for which a data temperature is to be set (or the
combined partition numbers that identify a range of logically
contiguous partitions).
The combined partition number is a calculated value that takes into
account any column partitions and the different levels of partitioning
in multilevel partitioned tables. It uniquely identifies every partition in
the table.
For tables with only a single-level partition without column
partitioning, the combined partition number for any row is the value
of the system-derived PARTITON column of the row.
For more information on calculating combined partition numbers for
other types of tables, see Database Design.
HOT
WARM
COLD
The data temperature that will be set for the cylinders that store row data
for the specified table or rows, regardless of the historical frequency of
access for that data.
• HOT cylinders are the most frequently accessed. During data
migration their data is stored on the fastest storage media.
• WARM cylinders are accessed with moderate frequency. Their data is
stored on moderately fast storage media.
• COLD cylinders store the least frequently accessed data. Their data is
stored on the slowest storage media.
Usage Notes
For new tables, Teradata Database does not yet have metrics on data access to use in assigning
a temperature to the table data, so relies on the defaults set in the Storage group of DBS
Control settings. The FORCE command can be used to force a non-default temperature on
new tables to allow Teradata VS to place the data that currently exists in the table on storage
appropriate to the expected table data temperature, without waiting for the system to collect
data access statistics.
In addition to setting the temperature for whole tables, FORCE can be used to set the
temperature for a row, range of rows, or specific partitions. For example:
•
When data in older rows of a nonpartitioned NoPI table is less frequently accessed than
data in newer rows, you can use FORCE to set the older rows to COLD.
•
When one or more partitions of a partitioned table are expected to be more frequently
accessed than other partitions, you can use FORCE to set the frequently accessed
partitions to HOT.
When temperature based block-level compression is enabled, using FORCE to set infrequently
accessed tables or partitions to COLD will cause them to be compressed sooner than they
otherwise would be.
Teradata Virtual Storage
27
Chapter 3: Specifying Data Temperatures
FORCE
Data temperature can change over time from the temperature specified with the FORCE
command if the measured frequency of actual data access differs from the temperature set
using the FORCE command.
The temperature of boundary cylinders that store rows from more than a single table are not
affected by the FORCE command if COLD is specified.
The FORCE command ignores any table scope that might have been previously specified, and
operates only on the table that is explicitly specified in the FORCE command.
Related Topics
For more information on…
See…
nonpartitioned NoPI tables
SQL Data Definition Language.
PARTITION columns
Database Design.
rowspecs
the Filer chapter of Support Utilities.
table identifiers
the Ferret chapter in Utilities.
Example 1
The following example changes the temperature of a table.
Ferret ==>
> force 0 6CE 400 temperature = hot
FORCE command changed the temperature of table test.table1 to HOT.
The temperature of 117 cylinders have been changed to HOT.
Example 2
The following example sets the temperature for a subset of rows a partitioned table. In this
case, the rows are those in the combined partition identified by an external partition number
of 9.
Ferret ==>
> force "test.ppi_t02" 400 9 temperature = hot
FORCE command changed the temperature of table test.ppi_t02
to HOT for the specified partition.
The temperature of 5 cylinders have been changed to HOT.
28
Teradata Virtual Storage
CHAPTER 4
Resource Usage Table Columns for
Teradata VS
This chapter provides information on resource usage table columns used with Teradata VS.
For more information on resource usage, see Resource Usage Macros and Tables.
About the Mode Column
The Mode column describes the kind of data reported by the resource usage column.
IF the Mode column is ....
THEN these resource usage columns ...
count
tally the number of times an event occurred, such as the number of
disk reads or writes during the logging period.
max
report the maximum value recorded during the logging period. Most
of the max columns have a max suffix in the column name (for
example, IoRespMax).
min
report the minimum value recorded during the logging period. The
min columns have a min suffix in the column name (for example,
AvailableMin).
track
show the value of a countable item achieved at the end of the current
logging period. An example of a countable item is a queue length.
ResUsageSpdsk Table Migration Columns
Migration columns, a subcategory of the ResUsageSpdsk table statistics, identify the number
of cylinders that migrated to a different location on a device as well as the time, in
centiseconds, of all migration I/Os used, incurred, or saved during the log period.
Note: Each allocation is for a cylinder size worth of data, also known internally in the
allocator as an extent. Thus the column names begin with Ext for extent.
Note: Associated configuration settings appear in the Control GDO Editor (ctl) utility if you
have purchased Teradata VS. For more information, see Teradata Virtual Storage.
Teradata Virtual Storage
29
Chapter 4: Resource Usage Table Columns for Teradata VS
ResUsageSpdsk Table Migration Columns
Column Name
Mode
Description
Data Type
ExtMigrateFaster
count
Number of cylinders migrated to a faster location on a device. This
count is for cylinders that were allocated on this device and
migrated to a different location within the same device or migrated
to a completely different device.
FLOAT
The following formula calculates a ExtMigrateSlower value, which
is the number of cylinders migrated to slower locations:
ExtMigrateSlower = ExMigrateTotal - ExMigrateFaster.
ExtMigrateIOTimeBenefit
count
Estimates the total I/O time savings achieved by migrations
completing in the log period. The I/O time savings include the
improvement in response time caused by the new data arrangement
up to the time horizon. ExtMigrateIOTimeBenefit does not include
the cost of the migration I/Os and is a gross benefit, not a net
benefit.
FLOAT
ExtMigrateIOTimeCost
count
Estimates the total cost, in centiseconds, incurred by migration
I/Os completing during the log period, where cost is the extra time
waited by all non-migration I/Os as a result of the migration
I/O.
FLOAT
ExtMigrateIOTimeImprove
count
Estimates the percent improvement in average I/O response time
due to migrations completing in the log interval. For example, if,
right before a particular log interval, the average I/O response time
was 10 milliseconds (ms), then the migration logs an
ExtMigrateIOTimeImprove value of 10% in this interval. The
average I/O response time after the log interval should be (100%10%)*10ms = 9ms. Migration then logs an
ExtMigrateIOTimeImprove of 1% in the next interval. The average
I/O response time in the new log interval is (100%-1%)*9ms =
8.91ms.
FLOAT
ExtMigrateIOTimeImprove is only an estimate. Its permanent
improvement remains in effect as long as the workload does not
change and newer migrations do not significantly alter the data
arrangement.
When the workload changes or new migrations affect data
arrangement, response time changes in an unquantifiable way.
Despite this, ExtMigrateIOTimeImprove is useful because it
predicts actual system performance at least for short periods of
time and can be used to understand why the migration algorithm is
doing what it is doing.
ExtMigrateReadRespTot
count
Migration read I/O response time.
FLOAT
ExtMigrateWriteRespTot
count
Migration write I/O response time.
FLOAT
ExtMigrateTotal
count
Total number of cylinders migrated to a different physical location.
For more information, see the ExtMigrateFaster field.
FLOAT
30
Teradata Virtual Storage
Chapter 4: Resource Usage Table Columns for Teradata VS
ResUsageSvdsk Table Migration Columns
ResUsageSvdsk Table Migration Columns
Migration columns, a subcategory of the ResUsageSvdsk table statistics, identify the number
of cylinders that migrated to a different location on a device as well as the time, in
centiseconds, of all migration I/Os used, incurred, or saved during the log period.
Note: Each allocation is for a cylinder size worth of data, also known internally in the
allocator as an extent. Therefore, the column names begin with Ext for extent.
Note: Associated configuration settings appear in the Control GDO Editor (ctl) utility if you
have purchased Teradata VS. For more information, see Teradata Virtual Storage.
Column Name
Mode
Description
Data Type
ExtMigrateFaster
count
Number of cylinders migrated to faster locations (that is,
migrations whose gross benefits are positive) for the associated
AMP.
FLOAT
The following formula calculates a Slower Migration value, which is
the number of cylinders migrated to slower locations:
SlowerMigration = ExtMigrateTotal - ExtMigrateFaster
Cylinders are migrated to slower locations to make room for hotter
cylinders to replace them.
ExtMigrateIOTimeCost
count
Estimates the total cost, in centiseconds, incurred by migration
I/Os completing during the log period, where cost is the extra time
waited by all non-migration I/Os as a result of the migration
I/O.
FLOAT
ExtMigrateIOTimeBenefit
count
Estimates the total I/O time savings achieved by migrations
completing in the log period. The I/O time savings include the
improvement in response time caused by the new data arrangement
up to the time horizon.
FLOAT
This value does not include the cost of the migration I/Os and is a
gross benefit, not a net benefit.
Teradata Virtual Storage
31
Chapter 4: Resource Usage Table Columns for Teradata VS
ResUsageSvpr Table Node Agent Columns
Column Name
Mode
Description
Data Type
ExtMigrateIOTimeImprove
count
Estimates the percent improvement in average I/O response time
due to migrations completing in the log interval.
FLOAT
For example, if, right before a particular log interval, the average
I/O response time was 10 milliseconds (ms), then the migration
logs an ExtMigrateIOTimeImprove value of 10% in this interval.
The average I/O response time after the log interval should be
(100%-10%)*10ms = 9ms. Migration then logs an
ExtMigrateIOTimeImprove of 1% in the next interval. The average
I/O response time in the new log interval is (100%-1%)*9ms =
8.91ms.
ExtMigrateIOTimeImprove is only an estimate. Its permanent
improvement remains in effect as long as the workload does not
change and newer migrations do not significantly alter the data
arrangement.
When the workload changes or new migrations affect data
arrangement, response time changes in a nonquantifiable way.
You can use this field to predict the actual system performance for
short periods of time and to understand why the migration
algorithm is doing what it is doing.
ExtMigrateReadRespTot
count
Migration read I/O response time.
FLOAT
ExtMigrateWriteRespTot
count
Migration write I/O response time.
FLOAT
ExtMigrateTotal
count
Total number of cylinders migrated to a different physical location.
For more information, see the ExtMigrateFaster column.
FLOAT
ResUsageSvpr Table Node Agent Columns
These columns identify the migration processing statistics reported by the Node Agent.
Note: Associated configuration settings appear in the Control GDO Editor (ctl) utility if you
have purchased Teradata VS. For more information, see Teradata Virtual Storage.
Column Name
Mode
Description
Data Type
NodeAgentMigrationsDone
count
Number of migration requests completed by the Node Agent.
FLOAT
NodeAgentMigrationsStarted
count
Number of migration requests started by the Node Agent.
FLOAT
32
Teradata Virtual Storage
APPENDIX A
How to Read Syntax Diagrams
This appendix describes the conventions that apply to reading the syntax diagrams used in
this book.
Syntax Diagram Conventions
Notation Conventions
Item
Definition / Comments
Letter
An uppercase or lowercase alphabetic character ranging from A through Z.
Number
A digit ranging from 0 through 9.
Do not use commas when typing a number with more than 3 digits.
Word
Keywords and variables.
• UPPERCASE LETTERS represent a keyword.
Syntax diagrams show all keywords in uppercase, unless operating system
restrictions require them to be in lowercase.
• lowercase letters represent a keyword that you must type in lowercase, such as a
Linux command.
• Mixed Case letters represent exceptions to uppercase and lowercase rules. The
exceptions are noted in the syntax explanation.
• lowercase italic letters represent a variable such as a column or table name.
Substitute the variable with a proper value.
• lowercase bold letters represent an excerpt from the diagram. The excerpt is
defined immediately following the diagram that contains it.
• UNDERLINED LETTERS represent the default value.
This applies to both uppercase and lowercase words.
Spaces
Use one space between items such as keywords or variables.
Punctuation
Type all punctuation exactly as it appears in the diagram.
Paths
The main path along the syntax diagram begins at the left with a keyword, and proceeds, left
to right, to the vertical bar, which marks the end of the diagram. Paths that do not have an
arrow or a vertical bar only show portions of the syntax.
The only part of a path that reads from right to left is a loop.
Teradata Virtual Storage
33
Appendix A: How to Read Syntax Diagrams
Syntax Diagram Conventions
Continuation Links
Paths that are too long for one line use continuation links. Continuation links are circled
letters indicating the beginning and end of a link:
A
A
FE0CA002
When you see a circled letter in a syntax diagram, go to the corresponding circled letter and
continue reading.
Required Entries
Required entries appear on the main path:
SHOW
FE0CA003
If you can choose from more than one entry, the choices appear vertically, in a stack. The first
entry appears on the main path:
SHOW
CONTROLS
VERSIONS
FE0CA005
Optional Entries
You may choose to include or disregard optional entries. Optional entries appear below the
main path:
SHOW
CONTROLS
34
FE0CA004
Teradata Virtual Storage
Appendix A: How to Read Syntax Diagrams
Syntax Diagram Conventions
If you can optionally choose from more than one entry, all the choices appear below the main
path:
READ
SHARE
JC01A010
ACCESS
Some commands and statements treat one of the optional choices as a default value. This
value is UNDERLINED. It is presumed to be selected if you type the command or statement
without specifying one of the options.
Strings
String literals appear in apostrophes:
'msgtext '
JC01A004
Abbreviations
If a keyword or a reserved word has a valid abbreviation, the unabbreviated form always
appears on the main path. The shortest valid abbreviation appears beneath.
SHOW
CONTROLS
CONTROL
FE0CA042
In the above syntax, the following formats are valid:
•
SHOW CONTROLS
•
SHOW CONTROL
Loops
A loop is an entry or a group of entries that you can repeat one or more times. Syntax
diagrams show loops as a return path above the main path, over the item or items that you can
repeat:
,
,
(
cname
3
4
)
JC01B012
Teradata Virtual Storage
35
Appendix A: How to Read Syntax Diagrams
Syntax Diagram Conventions
Read loops from right to left.
The following conventions apply to loops:
IF...
THEN...
there is a maximum number of
entries allowed
the number appears in a circle on the return path.
there is a minimum number of
entries required
the number appears in a square on the return path.
a separator character is required
between entries
the character appears on the return path.
In the example, you may type cname a maximum of 4 times.
In the example, you must type at least three groups of column
names.
If the diagram does not show a separator character, use one
blank space.
In the example, the separator character is a comma.
a delimiter character is required
around entries
the beginning and end characters appear outside the return
path.
Generally, a space is not needed between delimiter characters
and entries.
In the example, the delimiter characters are the left and right
parentheses.
Excerpts
Sometimes a piece of a syntax phrase is too large to fit into the diagram. Such a phrase is
indicated by a break in the path, marked by (|) terminators on each side of the break. The
name for the excerpted piece appears between the terminators in boldface type.
The boldface excerpt name and the excerpted phrase appears immediately after the main
diagram. The excerpted phrase starts and ends with a plain horizontal line:
LOCKING
excerpt
A
A
HAVING
con
excerpt
where_cond
,
cname
,
col_pos
JC01A014
36
Teradata Virtual Storage
Appendix A: How to Read Syntax Diagrams
Syntax Diagram Conventions
Multiple Legitimate Phrases
In a syntax diagram, it is possible for any number of phrases to be legitimate:
dbname
DATABASE
tname
TABLE
vname
VIEW
JC01A016
In this example, any of the following phrases are legitimate:
•
dbname
•
DATABASE dbname
•
tname
•
TABLE tname
•
vname
•
VIEW vname
Sample Syntax Diagram
,
CREATE VIEW
viewname
AS
A
LOCKING
cname
CV
LOCK
ACCESS
dbname
A
DATABASE
tname
FOR
SHARE
IN
READ
TABLE
WRITE
EXCLUSIVE
vname
VIEW
EXCL
,
B
SEL
B
MODE
expr
,
FROM
qual_cond
tname
C
.aname
C
HAVING cond
;
qual_cond
,
WHERE cond
GROUP BY
cname
,
col_pos
JC01A018
Teradata Virtual Storage
37
Appendix A: How to Read Syntax Diagrams
Syntax Diagram Conventions
Diagram Identifier
The alphanumeric string that appears in the lower right corner of every diagram is an internal
identifier used to catalog the diagram. The text never refers to this string.
38
Teradata Virtual Storage
APPENDIX B
Starting the Utilities
This appendix describes how to start Teradata Database utilities.
Teradata Database offers several user interfaces from which the utilities may be started and
run.
Interface
Description
Database Window
(DBW)
DBW is a graphical tool that connects to the Teradata Database console
subsystem (CNS). CNS provides console services to utility programs that
operate on the database level of Teradata Database. Console utilities
should be started from DBW.
Note: Operators must be members of the tdtrusted user group to run
console utilities, or must be logged in as root. Non-tdtrused users may be
explicitly granted access to the console using the CNS GRANT
command. For more information on the GRANT command, see the
Database Window chapter of Utilities.
For low bandwith connections, command-line interfaces to CNS are
available, such as cnsterm and cnstool. Information on cnsterm and
cnstool is available in man page online documentation.
A subset of the console utilities can be run from the Remote Console
portlet of Teradata Viewpoint. For more information, see the Teradata
Viewpoint User Guide.
Linux command line
Utilities that run directly from the command line are primarily those
that operate on the PDE level of Teradata Database.
Host Utility Console
(HUTCNS)
HUTCNS runs a subset of utilities from a channel-attached host
terminal. It runs only on the z/OS operating system.
Note: Not all utilities support all available user interfaces. For a listing of supported user
interfaces for each utility, see the documentation for each utility.
When started, some utilities present their own interactive command-line or graphical user
interfaces. These utilities allow browsing and entering information, and continue running
until they are explicitly stopped. Many utilities that present their own command environment
are stopped by entering the QUIT command.
Some utilities that run from DBW can be stopped by issuing the stop window_number
command from the DBW Supervisor window, where window_number is the numeric
identifier of the DBW application window in which the utility is running. For more
information on DBW, see Utilities Volume 1.
Teradata Virtual Storage
39
Appendix B: Starting the Utilities
Starting Utilities from Database Window
Starting Utilities from Database Window
Database Window (DBW) is an X client program that requires an X server to be running on
the local machine. DBW supports standard X Windows display forwarding. To ensure that the
graphical user interface displays properly, you can use the standard -display option to
specify the host name or IP address of the local machine.
To start a utility from Database Window:
1
If not already done, set up the Teradata Database environment by typing:
tdatcmd
at the Linux command line.
2
Open DBW from the Linux command line by typing:
xdbw –display displayspec &
where displayspec is the name or IP address of the local machine, followed by a colon and
the server number, typically 0 or 0.0. For example:
xdbw -display myworkstation.mycompany.com:0.0 &
or
xdbw -display 192.0.2.24:0.0 &
The DBW main window opens.
3
40
Click the Supvr button to open the Supervisor (supv) window.
Teradata Virtual Storage
Appendix B: Starting the Utilities
Starting Utilities from Database Window
4
Under Enter a command type:
start utilityname [options]
where utilityname is the name of the utility, and options can include any of the available
command-line options and arguments of that utility. utilityname is not case-sensitive.
The following message appears:
Started 'utilityname' in window x
where x is the number of one of the four available application windows DBW provides.
Each utility started runs in one of the four application windows. The title bar of the
application window and the corresponding button in the DBW main window change to
reflect the name of the running utility. When the utility stops running, the application
window and main window button revert to the default text title (that is, Appl1, Appl2, and
so forth).
Note: Up to four utilities can be run concurrently in DBW. The message “All Interactive
Partitions are busy!!” indicates that all four application windows are occupied. In this case,
one of the four running utilities must be quit before another can be started.
For more information on DBW and CNS commands, and on options that are available
with the START command, see Utilities Volume 1.
Teradata Virtual Storage
41
Appendix B: Starting the Utilities
Starting Utilities from the Linux Command Line
Starting Utilities from the Linux Command Line
To start a utility from the Linux command line:
1
If not already done, set up the Teradata Database environment by typing:
tdatcmd
at the Linux command line.
2
On the command line type:
utilityname [options]
where utilityname is the name of the utility, and options can include any of the available
command-line options and arguments of that utility.
Note: Operators must be members of the tdtrusted user group or have root access to run
console utilities. Other users can run the utilities only if they have been explicitly granted
access using the GRANT command.
Starting Utilities from HUTCNS
HUTCNS is a console interface that runs a subset of the Teradata Database utilities from a
channel-attached host terminal. These utilities include: Query Session, Query Configuration,
Showlocks, and Recovery Manager. HUTCNS is available only on z/OS terminals.
To start a utility:
1
On the command line type:
HUTCNS
The HUTCNS screen appears:
****
****
**** Data Base Computer
*
*
*
* *
*
*
****
*
Program: DBS Console Interface
*
*
*
* *
****
****
****
Enter logon string as ‘TDPID/UserID,Password’
TDPID is the Teradata Database system name. After you enter the required information,
the terminal displays the following:
Enter the Utility to execute
- SESsionStatus
- CONfiguration
- LOCKsDisplay
- RCVmanager
First 3 characters are acceptable
2
Type the name or abbreviation of the specified utility.
The screen for the specified utility appears.
Note: To exit the utility from HUTCNS, type END or QUIT.
42
Teradata Virtual Storage
Glossary
BLC
Block-level compression
CLOB Character large object
JI Join index
SLES
TBBLC
SUSE Linux Enterprise Server
Temperature-based block-level compression
Teradata VS
WAL
Teradata Virtual Storage
Teradata Virtual Storage
Write-ahead log
43
Glossary
44
Teradata Virtual Storage
Index
A
R
AutoCylPackColdData, DBS Control utility 12
ResUsageSpdsk table
mode 30
ResUsageSvdsk table
mode 31
B
BEGIN OPTMIZE command, Ferret utility 24
C
CANCEL OPTMIZE command, Ferret utility 25
D
Data evacuation, Teradata VS 9
Data temperature 13
Ferret utility commands and 23
specifying initial 21
TVSTemperature query bands 21
DBS Control utility fields
AutoCylPackColdData 12
Storage group 13
S
SHOWCYLALLOC command, Ferret utility 16
SHOWWHERE command, Ferret utility 17
Storage fields, DBS Control utility 13
Syntax diagrams, how to read 33
T
Ferret utility commands
BEGIN OPTMIZE 24
CANCEL OPTMIZE 25
FORCE 26
SHOWCYLALLOC 16
SHOWWHERE 17
FORCE command, Ferret utility 26
TBBLC 13
Temperature, data 13
Temperature-based block-level compression. See TBBLC
Teradata Virtual Storage. See Teradata VS
Teradata VS
cliques and 9
data evacuation and 9
data migration and 9
initial data temperature 13
mixed storage support 10
overview 9
statistics and 9
storage optimization and 9
system growth and 9
TVSTemperature query bands 21
I
U
Initial data temperature 10, 13, 21
Utilities
running on different platforms 39
starting on z/OS 42
F
M
Modes of resource usage data 29
count 29
max 29
min 29
track 29
Z
z/OS, starting utilities on 42
Q
Query bands, TVSTemperature 21
Teradata Virtual Storage
45
Index
46
Teradata Virtual Storage