Chapter 17 Testing Query Performance Using Target-Level Emulation: Application DBAs. Teradata Release 15.10
โฆษณา
โฆษณา
CHAPTER 17
Testing Query Performance Using
Target-Level Emulation:
Application DBAs
This chapter describes using the Target-Level Emulation facility to capture production system information. You can then use this information to generate a query plan identical to the plan that would be produced on the production system.
You can use this tool to validate and verify new queries in a test environment, ensuring that your production work is not disrupted by problematic queries.
About Target Level Emulation
The Target Level Emulation facility permits you to emulate a production environment on a test system by capturing environmental cost parameters, dynamic AMP sample statistics, intermediate IPE feedback of results or statistical data, and Optimizer-relevant DBS Control information from that environment and storing it in the relational tables
SystemFE.Opt_Cost_Table, SystemFE.Opt_RAS_Table, and SystemFE.Opt_DBSCtl_Table.
SystemFE.Opt_XMLPlan_Tbl stores query plans in XML format for use in target-level emulation.
You can then use the information from these tables together with appropriate column and index statistics to make the Optimizer on the test system generate query plans as if it were operating in the target environment rather than the test environment.
This feature produces a query plan for the emulated target system: it does not emulate the performance of that system.
The SQL DIAGNOSTIC statements that support Target Level Emulation are documented in
SQL Data Manipulation LanguageFor additional information about using Target Level
Emulation from a client utility GUI interface, see Teradata System Emulation Tool User Guide.
Benefits
This feature ensures that queries are thoroughly debugged and optimized in a safe, but equivalent, emulated environment prior to introducing them into the production environment. TLE:
•
Models the impact of various environmental changes and DBS Control parameter settings on SQL request performance.
Database Administration 405
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
About Target Level Emulation
•
Provides an environment for determining the source of various Optimizer-based production database query problems using environmental cost data and dynamic AMP sample-based statistical data.
About the Two Forms of Target Level Emulation
There are 2 forms of target level emulation.
•
Cost-based
•
Dynamic AMP sample-based
The DBS Control information stored in SystemFE.Opt_DBSCtl_Table supports both forms of target level emulation. The two forms are definitely not mutually exclusive: they are meant to be used together as a tool for the precise analysis of production system query plans generated on much smaller test systems.
Environmental cost parameters are constant across a system configuration because there is only one set of environmental cost values per system. Table statistics, on the other hand, are different for each base table and do not vary as a function of system configuration. For example, the cardinality of a given table is the same whether that table is on a two AMP system or a 100 AMP system; however, environmental costs vary considerably as a function of system configuration.
These differences account for the sometimes dissimilar syntax of analogous SQL
DIAGNOSTIC statements for handling cost and dynamic AMP statistical information.
Cost-based target level emulation has two possible forms: static and dynamic.
•
Static emulation refers to setting environmental cost parameters at the SYSTEM level.
Once set, the cost parameters persist across system restarts and reboots.
•
Dynamic emulation refers to setting environmental cost parameters at the IFP (referring to the Parsing Engine or PE), REQUEST, or SESSION levels (see SQL Data Manipulation
Language for definitions of what these terms mean in the context of Target Level
Emulation).
When you first set cost parameters, they are read dynamically from
SystemFE.Opt_Cost_Table and copied to a memory-resident data structure. The Optimizer then initializes its cost parameters from this memory-resident structure dynamically. The cost parameters do not persist across system restarts and reboots.
The advantage of dynamic target level emulation is that multiple users in multiple sessions can simultaneously emulate environmental cost parameters from multiple target systems on the same test system.
Dynamic AMP sample-based target level emulation permits you to generate dynamic AMP statistical samples on a production system and then export the captured data to a test system for detailed query analysis.
406 Database Administration
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Enabling Target Level Emulation
About Related Tools and Utilities
The target level emulation feature is closely related to other Teradata Database support tools, particularly those detailed in the following list:
•
Query Capture Facility.
•
Visual Explain Tool.
See Teradata Visual Explain User Guide.
•
Teradata System Emulation Tool (TSET).
You can perform TLE tasks using the Teradata System Emulation Tool interface. See
Teradata System Emulation Tool User Guide for details.
•
Teradata Index Wizard.
See Teradata Index Wizard User Guide.
•
CHECK STATISTICS option of the INSERT EXPLAIN and DUMP EXPLAIN statements.
See the documentation for these statements in SQL Data Manipulation Language.
Enabling Target Level Emulation
Target Level Emulation is disabled by default and should never be enabled on a production system.
Before you can use target level emulation on a test system, you must enable it.
The following is a high level procedure for performing this task.
1
2
Run the DIP utility script DIPSYSFE to create the optimizer cost values table
SystemFE.Opt_Cost_Table, the dynamic AMP sample statistical values table
SystemFE.Opt_RAS_Table, the XML-formatted query plans table
SystemFE.Opt_XMLPlan_Tbl, and the DBS Control parameters table
SystemFE.Opt_DBSCtl_Table.
Use the DBS Control utility to enable Target Level Emulation on your test system by setting DBS Control general parameter 22, Target Level Emulation, to TRUE.
Target Level Emulation and Cost Profiles
To enable optimizer cost profile system DIAGNOSTIC statements in combination with Target
Level Emulation, you must set the EnableCostProfileTLE parameter of DBS Control to TRUE.
If the DBS Control parameter EnableSetCostProfile is set to 0, Teradata Database automatically sets EnableCostProfileTLE to FALSE. This cannot be changed independently.
To solve the problem, ensure that the EnableSetCostProfile parameter is set to a value other than 0 and then set the EnableCostProfileTLE parameter to TRUE.
Database Administration 407
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Capturing Target System Optimizer Cost Values and Dynamic AMP Statistical Samples
Capturing Target System Optimizer Cost Values and Dynamic AMP Statistical Samples
Process Phases
The extraction of Optimizer cost value information from a target system and its subsequent application to a test system is a two-phase process, as follows.
1
Data capture phase.
2
Target system optimizer variables are read from the Dictionary and various system tables and written to a staging area. This phase is initiated from the target system.
Application phase.
The captured data in the staging area is exported to the appropriate Dictionary and system tables on the test system. This phase can be initiated from either the target or the test system.
You can use the Teradata System Emulation Tool from a client system to perform this data capture and application. See Teradata System Emulation Tool User Guide for details.
If you do not use Teradata System Emulation Tool, then you must follow a more circuitous path to capture target system optimizer variables and apply them to a test system. This topic presents both procedures.
Procedure Using the Teradata System Emulation Tool
Capturing data from a target production system and applying it to a test system is a two-phase process.
•
The first phase reads the relevant data on the target system and then writes it to a staging area.
•
The second phase exports the staging data to the test system and applies it to the appropriate data tables and system files.
The following is a high level overview of this procedure.
1
Depending on your requirements, perform one or all of the following steps.
a
Populate SystemFE.Opt_Cost_Table and SystemFE.Opt_DBSCtl_Table on the target system by running the DIAGNOSTIC DUMP COSTS statement (see SQL Data
Manipulation Language).
This operation extracts the Optimizer environmental cost value and DBS Control information from the target system and writes it to a relational table so it can be copied and used to drive the Optimizer on a test system.
b
Populate SystemFE.Opt_RAS_Table on the target system by running the DIAGNOSTIC
DUMP SAMPLES statement (see SQL Data Manipulation Language).
This operation extracts dynamic AMP statistics from the header of the specified table on the target system and writes it to a relational table so it can be copied and used to drive the Optimizer on a test system.
408 Database Administration
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Capturing Target System Optimizer Cost Values and Dynamic AMP Statistical Samples
2
3
4
5
6 c
Populate SystemFE.Opt_XMLPlan_Tbl by running the DIAGNOSTIC DUMP
XMLEXPLAIN statement (see SQL Data Manipulation Language).
Log onto Teradata System Emulation Tool from a client connected with the target system.
Create a target system profile to define the databases, tables, views, macros, and related environmental parameters or dynamic AMP statistics and DBS Control information to be captured for loading onto the test system.
Collect the Optimizer cost value information or dynamic AMP statistics, the DBS Control information, and any necessary object definitions and test queries from the target system and place it in a staging area from which the test system can import it.
To do this, invoke the Teradata System Emulation Tool Export function from the target system. This action writes the data created by DIAGNOSTIC DUMP COSTS or
DIAGNOSTIC DUMP SAMPLES into a staging area.
Invoke the Teradata System Emulation Tool Import function from a client connected with the test system to import the data from the staging area on the target system to
SystemFE.Opt_Cost_Table or SystemFE.Opt_RAS_Table and to
SystemFE.Opt_DBSCtl_Table on the test system.
The Import function permits you to select from several different load utilities to use to transfer the data.
Depending on your requirements, perform one or both of the following steps:
a
Run the DIAGNOSTIC SET COSTS SQL statement (see SQL Data Manipulation
Language) to specify the exact level of cost value information (and for which target configuration) you want to set.
b
Run the DIAGNOSTIC SET SAMPLES SQL statement (see SQL Data Manipulation
Language) to specify the exact level of dynamic AMP statistical sampling (and for which target configuration) you want to set.
You can also use Teradata System Emulation Tool to copy any of the following target system data to an appropriate test system:
•
Object definitions
•
Statistics
•
QCD data
•
Dynamic AMP samples
•
All available target system data, including cost parameters
Procedure Using SQL DIAGNOSTIC Statements
The following list provides a high level procedure for capturing Optimizer environmental cost information from a production system and applying that information to a test system.
1
Depending on your requirements, perform one or both of the following steps.
a
Populate SystemFE.Opt_Cost_Table and SystemFE.Opt_DBSCtl_Table on the target system by running the DIAGNOSTIC DUMP COSTS statement (see SQL Data
Manipulation Language for the syntax and usage information for this statement).
Database Administration 409
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Capturing Target System Optimizer Cost Values and Dynamic AMP Statistical Samples
2
3 b
Populate SystemFE.Opt_RAS_Table on the target system by running the DIAGNOSTIC
DUMP SAMPLES statement (see SQL Data Manipulation Language for the syntax and usage information for this statement).
This extracts the dynamic AMP statistical samples from the target system and writes them to a relational table so they can be copied and used to drive the Optimizer on a test system.
Depending on your requirements, perform one or both of the following steps.
a
This extracts the Optimizer environmental cost value information from the target system and writes it to a relational table so it can be copied and used to drive the
Optimizer on a test system.
Copy the Optimizer cost value information and any necessary object definitions and test queries from the target system to the test system.
To do this, select rows from SystemFE.Opt_Cost_Table on the production system and export them to a file using an appropriate load utility from the following list:
•
FastExport
•
CLIv2
•
BTEQ SQL script
b
Copy the dynamic AMP statistical samples and any necessary object definitions and test queries from the target system to the test system.
To do this, select rows from SystemFE.Opt_RAS_Table on the production system and export them to a file using an appropriate load utility from the following list.
•
FastExport
•
CLIv2
•
BTEQ SQL script
Depending on your requirements, perform one or both of the following steps.
a
Import the rows into SystemFE.Opt_Cost_Table on the test system using an appropriate load utility from the following list.
•
FastLoad
•
MultiLoad
•
Teradata Parallel Data Pump
•
CLIv2
•
BTEQ SQL script
b
Import the rows into SystemFE.Opt_RAS_Table on the test system using an appropriate load utility from the following list.
•
FastLoad
•
MultiLoad
•
Teradata Parallel Data Pump
•
CLIv2
•
BTEQ SQL script
410 Database Administration
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Target Level Emulation and Cost Profiles
4
5
6
7
Import the rows into SystemFE.Opt_DBSCtl_Table on the test system using an appropriate load utility from the following list.
•
FastLoad
•
MultiLoad
•
Teradata Parallel Data Pump
•
CLIv2
•
BTEQ SQL script
Import the rows into SystemFE.Opt_XMLPlan_Tbl using an appropriate load utility from the following list.
•
FastLoad
•
MultiLoad
•
Teradata Parallel Data Pump
•
CLIv2
•
BTEQ SQL script
Populate the test system with appropriate test data imported from the production system for which testing is to be performed.
Depending on your requirements, perform one or both of the following steps.
a
Run the DIAGNOSTIC SET COSTS SQL statement (see SQL Data Manipulation
Language) to specify the exact level of cost value information (and for which target configuration) you want to set.
b
Run the DIAGNOSTIC SET SAMPLES SQL statement (see SQL Data Manipulation
Language) to specify the exact level of dynamic AMP statistical sampling (and for which target configuration) you want to set.
For an illustration, see
“About Mapping Target System Files to a Test System” on page 414 .
Target Level Emulation and Cost Profiles
Using Target Level Emulation to Capture Target System Cost Profile Data
You can use Target Level Emulation to obtain all necessary target system cost profile data. The general procedure is to use Teradata System Emulation Tool to save a copy of the
DBC.CostProfiles and DBC.ConstantValues rows for the active cost profile on the target system, and then to install these as variable profiles on the emulation system (see
Emulation and Cost Profiles” on page 407 ).
Target system cost profile information is associated with the TLE cost segment row in
SystemFE.Opt_Cost_Table.
This information consists of the following data.
•
Profile type
•
Profile name
Database Administration 411
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Target Level Emulation and Cost Profiles
•
Profile category
•
Any rows for that profile from the DBC.ConstantValues table
Capturing Profile Information
You can capture Profile identity information by submitting the following request:
DIAGNOSTIC DUMP COSTS targ-sys-name
The profile type, name, and category are stored in the cost table row.
Teradata System Emulation Tool looks for this profile during export and, if found, captures the result of the following macro, which produces a set of SQL requests that create the actual cost profile:
EXEC DBC.ShowCostProfileAs('profile-name'
, 'targ-sys-name_Profile'
, ');
Teradata System Emulation Tool Import Function
The Teradata System Emulation Tool Import function installs the cost segment row in the
SystemFE.Opt_Cost_Table table on the emulated system and then runs the sequence of SQL requests to create a variable cost profile named targ-sys-name_Profile. It then inserts the constant value rows collected from the target system.
Installing Cost Segments at a Particular Emulation Level
The following diagnostic request installs the cost segment and activates targ-sys-name_Profile at the specified emulation level.
DIAGNOSTIC SET COSTS targ-sys-name,
PROFILE targ-sys-name_Profile ON FOR level; where level is one of the following scopes.
This scope level...
REQUEST
IFP
SESSION
SYSTEM
Applies to the current...
SQL request.
parsing engine.
session.
system, meaning there is no restriction enforced.
412 Database Administration
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
Capturing and Installing Costing Information Including the Active Cost Profile
Capturing and Installing Costing Information
Including the Active Cost Profile
Two Ways to Capture and Install Cost Profile Information
There are 2 ways to capture Target Level Emulation data:
•
Using the Teradata System Emulation Tool Export function (see Teradata System
Emulation Tool User Guide).
•
Using the following SQL DIAGNOSTIC statements:
•
DIAGNOSTIC COSTPRINT
•
DIAGNOSTIC DUMP COSTS
•
DIAGNOSTIC SET COSTS
•
DIAGNOSTIC SET PROFILE
•
DIAGNOSTIC DUMP SAMPLES
•
DIAGNOSTIC SET SAMPLES
See SQL Data Manipulation Language for the syntax and usage notes for these statements.
Procedure Using SQL DIAGNOSTIC Statement Requests
The procedure defined here uses the second method.
1
Determine the name of the session profile.
2
DIAGNOSTIC HELP PROFILE;
Assume the request returns the name prof-name for the session profile.
Capture the cost segment and SQL to generate the emulation cost profile.
DIAGNOSTIC DUMP COSTS Wellington;
.EXPORT FILE=ProfileSQL
EXEC DBC.ShowCostProfileAs ( 'prof-name'
, 'Wellington_Profile'
, 'Active cost profile for Wellington')
3
4
.EXPORT reset
Load the file named ProfileSQL.
To do this, execute the following BTEQ installation command.
.RUN FILE=ProfileSQL
This installs as a Wellington_Profile variable Cost Profile.
Insert the cost segment row for Wellington into SystemFE.Opt_Cost_Table and his DBS
Control and internal parameter rows into SystemFE.Opt_DBSCtl_Table using
DIAGNOSTIC DUMP COSTS (see
“Capturing Target System Optimizer Cost Values and
Dynamic AMP Statistical Samples” on page 408 ).
Database Administration 413
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
About Mapping Target System Files to a Test System
5
6
Insert the internal parameter row for Wellington into SystemFE.Opt_RAS_Table using
).
Run the appropriate SQL DIAGNOSTIC requests to install the Target Level Emulation data.
DIAGNOSTIC SET COSTS Wellington
, PROFILE Wellington_Profile
ON FOR scope_level; where scope_level indicates one of the following.
This scope level...
REQUEST
IFP
SESSION
SYSTEM
Applies to the current...
SQL request.
parsing engine.
session.
system, meaning there is no restriction enforced.
For details, see “SET DIAGNOSTIC COSTS” in SQL Data Manipulation Language.
DIAGNOSTIC SET SAMPLES Wellington
ON FOR scope_level; where scope_level indicates one of the following.
This scope level...
SESSION
SYSTEM
Applies to the current...
session.
system, meaning there is no restriction enforced.
7
For details, see “DIAGNOSTIC SET SAMPLES” in SQL Data Manipulation Language.
This step is optional.
Remove the profile.
EXEC DBC.DeleteCostProfile ('Wellington_Profile');
About Mapping Target System Files to a Test
System
This topic provides an overview of the process of mapping target system files to the Optimizer on a test system using Target Level Emulation.
The following graphic indicates the flow of how target system optimizer environmental cost parameters are mapped to test system structures that, in turn, cause the test system query
414 Database Administration
Database Administration
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
About Mapping Target System Files to a Test System optimizer to generate request plans that are based on the environmental cost parameters and data demographics of the emulated production system.
SystemFE Database
Cost Structure
Environment Structure
System Structure
Cost Table
Target Key
Target
System
Target System
Mapped to
Global PDE
System
Structures
Mapped
Target
Structure
Mapped
Cost Table
Structure
Optimizer Cost GDO
FF07D348
The flow for dynamic AMP statistical samples is essentially identical after making the necessary changes to the node labels in the diagram.
415
Chapter 17: Testing Query Performance Using Target-Level Emulation: Application DBAs
About Mapping Target System Files to a Test System
416 Database Administration
ดาวน์โหลด
ลิงก์สาธารณะได้รับการอัปเดตแล้ว
ลิงก์สาธารณะไปยังแชทของคุณได้รับการอัปเดตแล้ว You may view and manage your chat links after registration here.
ลิงก์สาธารณะของเอกสาร
โฆษณา
