CBO Cost Formulas基于成本优化器的成本计算公式大全

CBO Cost Formulas成本计算公式大全:

成本模型:连接方式Join method

注意 连接基数(Join Cardinality)不受到连接方式(join method) 的影响, oracle中主要的三种join method HASH JOIN、Nested Loops、Sort Merge:

  • Nested Loops嵌套循环成本公式:
    • Cost(outer)+Cost(inner))*cardinality(outer)
  • Sort merge 合并排序连接成本公式:
    • Cost(outer) + Cost(inner) + Sort(outer) + Sort(inner)
  • Hash Join 哈希连接公式:
    • Cost(outer) + Cost(inner) + Build(outer) + Probe(inner)

 

Index Unique Scan Cost成本计算
INDEX UNIQUE SCAN COST = (BLEVEL (1-(OIC/100)) + 1) * (OICA/100)

 

Index Range Scan Cost成本计算
INDEX RANGE SCAN COST = (BLEVEL + FF*LFBL)*(1-(OIC/100))+ FF*CLUF)* (OICA/100)

 

 

formula does not include the CPU cost

  • BLEVEL = number of branch levels in index
  • add +1 for leaf block
  • FF = filtering factor – selectivity
  • LFBL = number of leaf blocks
  • CLUF = index clustering factor
  • OIC = optimizer_index_caching(default 0)
  • OICA = optimizer_index_cost_adj parameter(default=100)

 

CPU costing启用的情况下:

mreadtime -Average time , in milliseconds, for a multi-block read (according to sys.aux_stats$)

sreadtime – Average time , in milliseconds, for a single-block read (according to sys.aux_stats$)

MBRC – Average number of blocks to be read in a multi-block read (according to sys.aux_stats$

#SRDs – number of single block reads

#MRDs – number of multi block reads

#CPUCycles – number of CPU Cycles

sreadtime = ioseektim + db_block_size/iotfrspeed

mreadtim = ioseektim + db_file_multiblock_read_count * db_block_size / iotrfspeed

#MRds = #Blks/MBRC

Cost 成本本身 =(#SRds * sreadtim +#MRds * mreadtim + #CPUCycles/cpuspeed)/sreadtim ,  

Cost成本的单位 为 single-block read time=sreadtim

 

 

OSS Description

Provide a description of the component including how it will be built and what it will do, with a reference to the functional requirements (from the Functional Specification) that are being addressed.

Optimizer system statistics contains hardware characteristics. With OSS optimizer combines IO and CPU resources needed to execute query into single unit – estimated execution time.

OSS Components:

 

Component Initialization Maintenance Description Abbreviated component’s name (get_system_stats and set_system_stats)
CPU speed At system startup Gathering system stats with gathering_mode =  ‘NOWORKLOAD’ or ‘START’, ‘STOP’ or ‘INTERVAL’ or setting manually # CPU cycles per second cpuspeed
IO seek time At system startup Gathering system stats with gathering_mode =  ‘NOWORKLOAD’ or setting manually Seek time + latency time + OS overhead time ioseektim
IO transfer speed At system startup Gathering system stats with gathering_mode =  ‘NOWORKLOAD’ or setting manually Rate at which oracle can read data in the single read request iotfrspeed
Max IO throughput None Gathering system stats with gathering_mode =  ‘NOWORKLOAD’ or ‘START’, ‘STOP’ or ‘INTERVAL’ or setting manually This number characterizes maximum throughput (MB / sec) IO subsystem can deliver maxthr
Average slave IO throughput None Gathering system stats with gathering_mode =  ‘START’, ‘STOP’ or ‘INTERVAL’ or setting manually Average parallel slave IO throughput slavethr
Average Single Block Read Time None Gathering system stats with gathering_mode =  ‘START’, ‘STOP’ or ‘INTERVAL’ or setting manually sreadtim
Average Multi Block Read Time None Gathering system stats with gathering_mode =  ‘START’, ‘STOP’ or ‘INTERVAL’ or setting manually mreadtim
Average multi block read count None Gathering system stats with gathering_mode =  ‘START’, ‘STOP’ or ‘INTERVAL’ or setting manually mbrc

 

  1. cpuspeed, ioseektim, iotfrspeed are always collected
  2. maxthr, slavethr, sreadtim, mreadtim and mbrc collected only when user gathers workload statistics.

These two sets contain equivalent information. The difference is that A) does not relate to workload and B) does. At any moment of time only one set of OSS can be used.

 

 

OSS data located in data dictionary in the aux_stats$ table and in the SGA variable kkossga. aux_stats$ keeps persistent copy of the OSS. kkossga keeps working copy. Data in kkossga and  aux_stats$ is always synchronized. User can modify, delete and gather OSS through interface provided in the DBMS_STATS package.

 

OSS used to represent cost as query estimated running time (it’s implemented as #CPU cycles and # multi block reads conversion to # single block reads) and to adjust FTS cost for parallel reads.

SRead_Cost(#Cycles) = (#Cycles * (1 / CPUSpeed)) / sreadtim

SRead_Cost(#MReads) = (#MReads * mreadtim) / sreadtim

When no workload stats available optimizer uses NOWORKLOAD stats to compute sreadtim and mreadtim:

sreadtim = ioseektim + block_size / iotfrspeed

mreadtim = ioseektim + mbrc * block_size / iotfrspeed

Optimizer converts multi block reads to single block reads (even if cost formula looks elegant the actual processing has to support old days behavior and it causes that internally everything converted to single block reads)

aux_stats$

table aux_stats$ (

sname varchar2(30) not null,       /* Prefix */

pname varchar2(30) not null,       /* Name of parameter */

pval1 number,                      /* NUMBER parameter value */

pval2 varchar2(255)                /* VARCHAR2 parameter value */

)

This table stores OSS. It also used to store the intermediate values when analyzing workload.

sname column used to store global prefixes of the stats SYSSTATS_MAIN, SYSSTATS_TEMP and SYSSTATS_INFO.

if sname = SYSSTATS_MAIN then pname and pval1 columns store name-value pairs for data representing current stats:

cpuspeed (# cpu cycles per second) in millions;

ioseektim (Seek time + latency time + OS overhead time) in milliseconds;

iotfrspeed (IO transfer speed) in bytes/ second;

maxthr (maximum I/O system throughput) in bytes/sec;

slavethr (average slave throughput);

sreadtim (wait time to read single block) in milliseconds;

mreadtim (wait time to read a multiblock) in milliseconds;

mbrc (multiblock read count) in blocks;

if sname = SYSSTATS_TEMP then pname and pval1 columns store name-value pairs for intermediate data, generated than user issues DBMS_STAT.GATHER_SYSTEM_STATS procedure and removed then gathering completes.

if sname = SYSSTATS_INFO then pname, pval2 columns store name-values for current and intermediate stats:

DSTART – then gathering was started, format “MM-DD-YYYY HH:MI”

DSTOP – then gathering was (will be, had to be) finished format “MM-DD-YYYY HH:MI”

STATUS – ‘COMPLETED’, ‘AUTOGATHERING’, ‘MANUALGATHERING’, ‘INVALID’

关于10053 trace中的UNCOMPBKTS和ENDPTVALS

关于10053 trace中的Histogram部分的UNCOMPBKTS和ENDPTVALS

当Histogram直方图类型为frequency histograms( Histogram: Freq)时UncompBkts 等于统计信息中采样的总行数-NULLS(Card: Original- NULLS,因为dbms_stats默认是auto_sample_size采样,所以这栏其实是采样到的原始Card-NULLS), 而EndPtVals 等于bucket总数,或者说NDV,因为frequency histograms中 NDV=number of buckets 

当直方图类型为height balanced histograms (Histogram: HtBal) UncompBkts  等于bucket的数目(其实也等于10053 trace中#Bkts的数目),而EndPtVals 等于已经被压缩的Histogram的大小,其实是等于: select count(*) from dba_tab_histograms where table_name=’MACLEANLIU’ and column_name=’MACLEANLIU’的实际总和。  通过这2个值对比,可以了解到popular值的多少以及数据的倾斜度, 是有多个大量重复的值(popular value)还是仅有一个巨大的重复值。

 

仍不明确少数概念的话,来看看下面这个图:

Histogram representation

Oracle CBO术语大集合

最近准备写点Histogram和density相关的文章,先把术语给大家理一理:

cardinality (CDN)
Legend
CBQT – cost-based query transformation
JPPD – join predicate push-down
OJPPD – old-style (non-cost-based) JPPD
FPD – filter push-down
PM – predicate move-around
CVM – complex view merging
SPJ – select-project-join
SJC – set join conversion
SU – subquery unnesting
OBYE – order by elimination
OST – old style star transformation
ST – new (cbqt) star transformation
CNT – count(col) to count(*) transformation
JE – Join Elimination
JF – join factorization
SLP – select list pruning
DP – distinct placement
qb – query block
LB – leaf blocks
DK – distinct keys
LB/K – average number of leaf blocks per key
DB/K – average number of data blocks per key
CLUF – clustering factor
NDV – number of distinct values
Resp – response cost
Card – cardinality
Resc – resource cost
NL – nested loops (join)
SM – sort merge (join)
HA – hash (join)
CPUSPEED – CPU Speed
IOTFRSPEED – I/O transfer speed
IOSEEKTIM – I/O seek time
SREADTIM – average single block read time
MREADTIM – average multiblock read time
MBRC – average multiblock read count
MAXTHR – maximum I/O system throughput
SLAVETHR – average slave I/O throughput
dmeth – distribution method
1: no partitioning required
2: value partitioned
4: right is random (round-robin)
128: left is random (round-robin)
8: broadcast right and partition left
16: broadcast left and partition right
32: partition left using partitioning of right
64: partition right using partitioning of left
256: run the join in serial
0: invalid distribution method
sel – selectivity
ptn – partition
adop Automatic degree of parallelism

TABLE: Table Name
ALIAS: Table Alias
QBS: Query Block Signature
#ROWS: Number of Rows
#BLKS: Number of Blocks
ARL: Average Row Length
COR: Cardinality Original
CRD: Cardinality Rounded
CCM: Cardinality Computed
CNA: Cardinality Non Adjusted

AVGLEN: Average Column Length
NDV: Number of Distinct Values
NULLS: Number of Nulls in Column
DEN: Column Density
MIN: Minimum Column Value
MAX: Maximum Column Value
TYPE: Histogram Type
#BKTS: Histogram Buckets
UNCOMPBKTS: Histogram Uncompressed Buckets   
ENDPTVALS: Histogram End Point Values 
OOR: Out-of-Range Predicate

TABLE: Table Name
ALIAS: Table Alias
INDEX: Index Name
QBS: Query Block Signature
LVLS: Index Levels
#LB: Number of Leaf Blocks
#DK: Number of Distinct Keys
LB/K: Average Number of Leaf Blocks Per Key
DB/K: Average Number of Data Blocks Per Key
CLUF: Clustering Factor
INDEX_COLS: Index Column Numbers

COST: Cost of the Join
CARD: Cardinality of the Join
BC: Best Cost
LINE#: Line Number in the 10053 Trace File Where Cost Value is Located
JOIN#: Join Number in the 10053 Trace File Associated With Key
STATUS: If Permutation was Computed for all Table Joins the Status = COMPL. If Not, status = ABORT
*: In ANY Column Indicates Value Not Found in File

Freq 频率直方图
HtBal 高度平衡直方图

 

 

关于 UNCOMPBKTS和ENDPTVALS

 

当直方图类型为frequency histograms( Histogram: Freq)时UncompBkts  等于统计信息中采样的总行数-NULLS(Card: Original- NULLS,因为dbms_stats默认是auto_sample_size采样,所以这栏其实是采样到的原始Card-NULLS), 而EndPtVals 等于bucket总数,或者说NDV,因为frequency histograms中 NDV=number of buckets 

当直方图类型为height balanced histograms (Histogram: HtBal) UncompBkts  等于bucket的数目(其实也等于10053 trace中#Bkts的数目),而EndPtVals 等于已经被压缩的Histogram的大小,其实是等于: select count(*) from dba_tab_histograms where table_name=’YOUR_TABLE_NAME’ and column_name=’YOUR_COLUMN_NAME’的实际总和。  通过这2个值对比,可以了解到popular值的多少以及数据的倾斜度, 是有多个大量重复的值(popular value)还是仅有一个巨大的重复值。

 

 

SQL Performance Analyzer SPA常用脚本汇总

SPA常用脚本汇总

附件为 一个SPA报告 spa_buffergets_summary

 

SQL 性能分析器 SQL Performance Analyzer SPA

Oracle Database 11g 引入了 SQL 性能分析器;使用该工具可以准确地评估更改对组成工作量的 SQL 语句的影响。SQL 性能分析器可帮助预测潜在的更改对 SQL 查询工作量的性能影响。这种功能可向 DBA 提供有关 SQL 语句性能的详细信息,例如,执行前后的统计信息,提高或降低性能的语句。这样一来,您就可以执行诸如以下操作的操作:在测试环境中进行更改,以确定数据库升级是否会改进工作量性能。

 

  1. 11g 的新增功能
  2. 目标用户:DBA、QA、应用程序开发人员
  3. 帮助预测系统更改对 SQL 工作量响应时间的影响
  4. 建立不同版本的 SQL 工作量性能(即 SQL 执行计划和执行统计信息)
  5. 以串行方式执行 SQL(不考虑并发性)
  6. 分析性能差异
  7. 提供对单个 SQL 的细粒度性能分析
  8. 与 SQL 优化指导集成在一起以优化回归

SQL 性能分析器:使用情形
SQL 性能分析器可用于预测和防止会影响 SQL 执行计划结构的任何数据库环境更改所带来的潜在性能问题。这些更改可以包括(但不限于)以下任何一种更改:

  1. 数据库升级
  2. 实施优化建议
  3. 更改方案
  4. 收集统计信息
  5. 更改数据库参数
  6. 更改操作系统和硬件

 

DBA 甚至可以使用 SQL 性能分析器为最复杂的环境预测先期更改导致的 SQL 性能更改。例如,随着应用程序在开发周期中的变化,数据库应用程序开发人员可以测试对方案、 数据库对象和重写应用程序的更改,以减轻任何潜在的性能影响。
使用 SQL 性能分析器还可以比较 SQL 性能统计信息。

SQL 性能分析器:概要

1.  收集 SQL:在这个阶段中,将收集用于表示生产系统中的 SQL 工作量的 SQL 语句集。可以使用 SQL 优化集或自动工作量资料档案库 (AWR) 来捕获要传送的信息。因为 AWR 本质上是捕获高负载的 SQL,所以应考虑修改默认的 AWR 快照设置和捕获的顶级 SQL,以确保 AWR 捕获最大数量的 SQL 语句。这可以确保捕获更加完整的 SQL 工作量。

2.  传送:在这个阶段中,应将得到的工作量结果传送到测试系统。从生产系统导出 STS,然后将 STS 导入到测试系统。

3.  计算“之前版本”性能:在进行任何更改之前,执行 SQL 语句,收集评估将来的更改对工作量性能的可能影响所需的基线信息。在此阶段收集的信息给出了系统工作量当前状态的一个快照。性能数据包括:

-执行计划(如由解释计划生成的计划)
-执行统计信息(如由占用时间、缓冲获取次数、磁盘读取次数和已处理的行数组成的信息)

4. 进行更改:获得了之前版本数据后,可以实施计划的更改,然后开始查看对性能的影响。

5.  计算“之后版本”性能:在数据库环境中进行了更改之后才执行此步骤。SQL 工作量的每个语句都在虚拟执行(仅收集统计信息)模式下运行,收集与步骤 3 所捕获的信息相同的信息。

6.  比较和分析 SQL 性能:在获得了两个版本的 SQL 工作量性能数据后,可以通过比较之后版本与之前版本的数据来进行性能分析。比较的根据是执行统计信息,如所用时间、CPU 时间和缓冲区获取次数等。

7.  优化回归的 SQL:在此阶段中,已经准确地确认了哪些 SQL 语句在进行数据库更改时可能导致性能问题。在此阶段中可以使用任何一种数据库工具来优化系统。例如,可以对确认的语句使用 SQL 优化指导或访问指导,然后实施相应的建议。也可以使用在步骤 3 中捕获的计划植入 SQL 计划管理 (SPM) 以确保计划保持不变。在实施了任何优化操作后,应重复该过程来创建新的之后版本,然后分析性能差异以确保新的性能是可接受的。
默认情况下SPA若涉及到DML语句则只有查询部分Query会被执行,但是貌似是从11.2开始可以执行完全的DML了,需要加入参数EXECUTE_FULLDML,但是该参数目前有一些BUG:

Bug 10428438 : WITH EXECUTE_FULLDML ROWS IS ALWAYS SET TO 0 11.2.0.1

Bug 14635522 : SPA SHOULD CAPTURE AND REPLAY TRANSACTIONS 11.2.0.3

 

By default, only the query portion of DMLs is executed. Using APIs, you can execute the full DML by using the EXECUTE_FULLDML task parameter.EXECUTE_FULLDML when set to TRUE executes DML statement fully, including acquiring row locks and modifying rows; When EXECUTE_FULLDML is set to FALSE (the default value is false) to execute only the query part of the DML without modifying data. When TRUE, SQL Performance Analyzer will issue a rollback following DML execution to prevent persistent changes from being made by the DML. So SPA does not make make any change to the data in the tables.

 

执行方法如下:

 

execute DBMS_SQLPA.SET_ANALYSIS_TASK_PARAMETER(task_name   => 'TASK_21137', -
                                               parameter   => 'EXECUTE_FULLDML', -
                                               value       => 'TRUE');

 

 

 

 

从cursor cache中收集tuning set, 持续12分钟,间隔5秒钟

 

 

begin
DBMS_SQLTUNE.CREATE_SQLSET (sqlset_name => 'MAC_SPA');
dbms_sqltune.capture_cursor_cache_sqlset(
sqlset_name => 'MAC_SPA' ,
time_limit => 12*60,
repeat_interval => 5);
end ;
/

basic_filter=> q'# module like 'DWH_TEST%' and sql_text not like '%applicat%' and parsing_schema_name in ('APPS') #'

basic_filter   => 'sql_text LIKE ''%my_objects%'' and parsing_schema_name = ''SPA_TEST_USER''',

==>过滤条件使用

 

从当前cursor cache中匹配条件 获得SQLset ROW

 

 

SELECT sql_id, sql_text 
FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE('buffer_gets > 500')) 
ORDER BY sql_id;

SELECT * 
FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE('sql_id = ''4rm4183czbs7j'''));

 DECLARE
  cur sys_refcursor;
BEGIN
  OPEN cur FOR
    SELECT value(P) 
    FROM table(DBMS_SQLTUNE.SELECT_CURSOR_CACHE) P;

  -- Process each statement (or pass cursor to load_sqlset).

  CLOSE cur;
END;
/

 -- create the tuning set
EXEC DBMS_SQLTUNE.CREATE_SQLSET('MAC_SPA');
-- populate the tuning set from the cursor cache
DECLARE
 cur DBMS_SQLTUNE.SQLSET_CURSOR;
BEGIN
 OPEN cur FOR
   SELECT VALUE(P)
     FROM table(
       DBMS_SQLTUNE.SELECT_CURSOR_CACHE(
         'parsing_schema_name <> ''SYS'' AND elapsed_time > 5000000',
          NULL, NULL, NULL, NULL, 1, NULL,
         'ALL')) P;

DBMS_SQLTUNE.LOAD_SQLSET(sqlset_name => 'MAC_SPA',
                        populate_cursor => cur);

END;
/

 

 

从AWR快照中加载SQLset ROW到SQL TUNING SET

 

 

DECLARE
  cur sys_refcursor;
BEGIN
  OPEN cur FOR
    SELECT VALUE (P) 
    FROM table(dbms_sqltune.select_workload_repository(4146,4161)) P;

  -- Process each statement (or pass cursor to load_sqlset)
  DBMS_SQLTUNE.LOAD_SQLSET(sqlset_name => 'MAC_SPA',
                        populate_cursor => cur);
  CLOSE cur;
END;
/

 

 

 

将SQL TUNING SET Pack到表中:

 

 

set echo on
select name,statement_count from dba_sqlset;

drop table maclean.pack_sqlset purge;

exec DBMS_SQLTUNE.CREATE_STGTAB_SQLSET('PACK_SQLSET','MACLEAN');

exec DBMS_SQLTUNE.PACK_STGTAB_SQLSET('MAC_SPA','SYS','PACK_SQLSET','MACLEAN');

SQL> desc maclean.pack_sqlset;
 Name                                      Null?    Type
 ----------------------------------------- -------- ----------------------------
 NAME                                               VARCHAR2(30)
 OWNER                                              VARCHAR2(30)
 DESCRIPTION                                        VARCHAR2(256)
 SQL_ID                                             VARCHAR2(13)
 FORCE_MATCHING_SIGNATURE                           NUMBER
 SQL_TEXT                                           CLOB
 PARSING_SCHEMA_NAME                                VARCHAR2(30)
 BIND_DATA                                          RAW(2000)
 BIND_LIST                                          SQL_BIND_SET
 MODULE                                             VARCHAR2(48)
 ACTION                                             VARCHAR2(32)
 ELAPSED_TIME                                       NUMBER
 CPU_TIME                                           NUMBER
 BUFFER_GETS                                        NUMBER
 DISK_READS                                         NUMBER
 DIRECT_WRITES                                      NUMBER
 ROWS_PROCESSED                                     NUMBER
 FETCHES                                            NUMBER
 EXECUTIONS                                         NUMBER
 END_OF_FETCH_COUNT                                 NUMBER
 OPTIMIZER_COST                                     NUMBER
 OPTIMIZER_ENV                                      RAW(1000)
 PRIORITY                                           NUMBER
 COMMAND_TYPE                                       NUMBER
 FIRST_LOAD_TIME                                    VARCHAR2(19)
 STAT_PERIOD                                        NUMBER
 ACTIVE_STAT_PERIOD                                 NUMBER
 OTHER                                              CLOB
 PLAN_HASH_VALUE                                    NUMBER
 PLAN                                               SQL_PLAN_TABLE_TYPE
 SPARE1                                             NUMBER
 SPARE2                                             NUMBER
 SPARE3                                             BLOB
 SPARE4                                             CLOB

 

 

 

将测试对应 schema的数据和 上述PACK TABLE 导出导入到 目标测试库中:

 

set echo on
exec DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET('MAC_SPA','SYS',TRUE,'PACK_SQLSET','MACLEAN');
alter system flush buffer_cache;
alter system flush shared_pool;

 

 

创建SPA任务 并运行;

 

 

var sts_task varchar2(64);
exec :sts_task:= dbms_sqlpa.create_analysis_task(task_name => '10g_11g_spa',description => 'experiment for 10gR2 to 11gR2 upgrade',sqlset_name=> 'MAC_SPA');

PL/SQL procedure successfully completed.

var exe_task varchar2(64);
exec :exe_task:=dbms_sqlpa.execute_analysis_task(task_name=>'10g_11g_spa',execution_name=>'10g_trail',execution_type=>'CONVERT SQLSET',execution_desc=>'10g sql trail');

var exe_task varchar2(64);
exec :exe_task:=dbms_sqlpa.execute_analysis_task(task_name=>'10g_11g_spa',execution_name=>'11g_trail',execution_type=>'TEST EXECUTE',execution_desc=>'11g sql trail');

 

 

 

执行任务比较

 

 

 

比较CPU_TIME
EXEC dbms_sqlpa.execute_analysis_task( -
  task_name => '10g_11g_spa', -
  execution_name => 'compare_10g_112_cpu', -
  execution_type => 'COMPARE PERFORMANCE', -
  execution_params => dbms_advisor.arglist('COMPARISON_METRIC','CPU_TIME','EXECUTION_NAME1','10g_trail','EXECUTION_NAME2','11g_trail'), -
  execution_desc => 'Compare 10g SQL Trace Performance to 11g Test-Execute for CPU_TIME')
  /

比较BUFFER_GETS
EXEC dbms_sqlpa.execute_analysis_task( -
  task_name => '10g_11g_spa', -
  execution_name => 'compare_10g_112_buffergets', -
  execution_type => 'COMPARE PERFORMANCE', -
  execution_params => dbms_advisor.arglist('COMPARISON_METRIC','BUFFER_GETS','EXECUTION_NAME1','10g_trail','EXECUTION_NAME2','11g_trail'), -
  execution_desc => 'Compare 10g SQL Trace Performance to 11g Test-Execute for BUFFER_GETS')
  /

比较实际执行时长 

begin 
DBMS_SQLPA.EXECUTE_ANALYSIS_TASK( 
task_name => 'SPA_TEST', 
execution_type => 'COMPARE PERFORMANCE', 
execution_name => 'Compare_elapsed_time', 
execution_params => dbms_advisor.arglist('execution_name1', '10g_trail', 'execution_name2', '11g_trail', 'comparison_metric', 'elapsed_time') ); 
end; 
/

比较物理读

begin 
DBMS_SQLPA.EXECUTE_ANALYSIS_TASK( 
task_name => '10g_11g_spa', 
execution_type => 'COMPARE PERFORMANCE', 
execution_name => 'Compare_physical_reads0', 
execution_params => dbms_advisor.arglist('execution_name1', '10g_trail', 'execution_name2', '11g_trail', 'comparison_metric', 'disk_reads') ); 
end; 
/

Set the comparison_metric parameter to specify an expression of execution 
statistics to use in the performance impact analysis. Possible values include 
the following metrics or any combination of them: elapsed_time (default), 
cpu_time, buffer_gets, disk_reads, direct_writes, and optimizer_cost.

 

 

 

获得SPA报告:

 

 

 

set long 100000 longchunksize 100000 linesize 200 head off feedback off echo off 
spool spa_report_elapsed_time.html 
SELECT dbms_sqlpa.report_analysis_task('SPA_TEST', 'HTML', 'ALL','ALL', execution_name=>'Compare_elapsed_time') FROM dual; 
spool off

产生buffergets 比较report    

set heading off long 100000000 longchunksize 10000 echo off;
set linesize 1000 trimspool on;
spool buffergets_summary.html
select xmltype(dbms_sqlpa.report_analysis_task('10g_11g_spa',
                                                'html',
                                                'typical',
                                                'all',
                                                null,
                                                100,
                                                'compare_10g_112_buffergets')).getclobval(0,0)
from dual;
spool off

产生errors比较report 
spool errors_summary.html
select xmltype(dbms_sqlpa.report_analysis_task('10g_11g_spa',
                                                'html',
                                                'errors',
                                                'summary',
                                                null,
                                                100,
                                                '11g_trail')).getclobval(0,0)
from dual;
spool off

产生unsupport比较report 
spool unsuppor_all.html
select xmltype(dbms_sqlpa.report_analysis_task('10g_11g_spa',
                                                'html',
                                                'unsupported',
                                                'all',
                                                null,
                                                100,
                                                '11g_trail')).getclobval(0,0)
from dual;
spool off

 

 

 

 

 

execution_type
Type of the action to perform by the function. If NULL it will default to the value of the DEFAULT_EXECUTION_TYPE parameter. Possible values are:
[TEST] EXECUTE – test-execute every SQL statement and collect its execution plans and execution statistics. The resulting plans and statistics will be stored in the advisor framework. This is default.
EXPLAIN PLAN – generate explain plan for every statement in the SQL workload. This is similar to the EXPLAIN PLAN command. The resulting plans will be stored in the advisor framework in association with the task.
COMPARE [PERFORMANCE] – analyze and compare two versions of SQL performance data. The performance data is generated by test-executing or generating explain plan of the SQL statements. Use this option when two executions of type EXPLAIN_PLAN or TEST_EXECUTE already exist in the task
CONVERT SQLSET – used to read the statistics captured in a SQL Tuning Set and model them as a task execution. This can be used when you wish to avoid executing the SQL statements because valid data for the experiment already exists in the SQL Tuning Set.

 

 

For 9i Upgrade to 10g

 

 

为什么说log file sync(其实是写redo慢)会造成buffer busy wait?

《gc buffer busy/gcs log flush sync与log file sync》一文中我介绍了 redo flush慢造成RAC中gc buffer busy争用的原理, 而在《【技术分享】开Oracle调优鹰眼,深入理解AWR性能报告》 中我又介绍了 log file sync(其实本质是lgwr 写redo慢)也会造成单实例single instance环境中的buffer busy wait等待, 这是为什么呢?

 

我们来做一个演示说明该问题:

 

示例用表:

conn maclean/oracle

create table  maclog (t1 int);

 

打开一个Session A 并获得它的OS进程号

[oracle@vrh8 ~]$ sqlplus / as sysdba

SQL*Plus: Release 10.2.0.5.0 – Production on Sat Mar 9 09:32:25 2013

Copyright (c) 1982, 2010, Oracle. All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.5.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

 

 

[oracle@vrh8 ~]$ ps -ef|grep LOCAL
oracle 18441 18438 0 09:41 ? 00:00:00 oracleG10R25 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq)))
oracle 18445 18348 0 09:42 pts/3 00:00:00 grep LOCAL

 

使用 gdb debug 该18375的前台进程,并指定breakpoint

[oracle@vrh8 ~]$ gdb $ORACLE_HOME/bin/oracle 18441
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-37.el5)

(gdb) b kcrf_commit_force
Breakpoint 1 at 0x286519c

 

之后在session A执行:

 

SQL> insert into maclog values(1);

1 row created.

若insert hang,则在GDB 中输入多次C  – continue 这样能够继续

 

输入 commit; ==》 此时session A会hang住

 

SQL> commit;   ====》HANG

 

在GDB 中输入bt 可以看到stack call

(gdb) bt
#0 0x000000000286519c in kcrf_commit_force ()
#1 0x00000000028620ef in kcrfw_redo_gen ()
#2 0x00000000010e7dba in kcbchg1_main ()
#3 0x00000000010e6d99 in kcbchg ()
#4 0x000000000143f65a in ktucmt ()
#5 0x00000000013c7a06 in ktcCommitTxn ()
#6 0x00000000042a559e in ktdcmt ()
#7 0x00000000024fe09c in k2lcom ()
#8 0x0000000002418993 in k2send ()
#9 0x0000000001418b47 in xctctl ()
#10 0x00000000014174dd in xctcom_with_options ()
#11 0x000000000211fc26 in kksExecuteCommand ()
#12 0x00000000030ef87a in opiexe ()
#13 0x0000000003232d47 in kpoal8 ()
#14 0x00000000013b7c10 in opiodr ()
#15 0x0000000003c3c9da in ttcpip ()
#16 0x00000000013b3144 in opitsk ()
#17 0x00000000013b60ec in opiino ()
#18 0x00000000013b7c10 in opiodr ()
#19 0x00000000013a92f8 in opidrv ()
#20 0x0000000001fa3936 in sou2o ()
#21 0x000000000072d40b in opimai_real ()
#22 0x000000000072d35c in main ()

其stack call为ktcCommitTxn=> ktucmt => kcbchg => kcbchg1_main => kcrfw_redo_gen => kcrf_commit_force

 

kcbchg==> block change ,为什么要发生block change呢? 因为commit需要对在Buffer Cache里的block做immediate block cleanout

此时开一个session B  查询maclog表

SQL> select * from maclog; ==》阻塞在buffer busy wait上

 

这样就通过 无法完成的immediate block cleanout 去pin住buffer ,来形成了一个buffer busy wait

 

做一个system state dump :
SQL> oradebug setmypid
Statement processed.
SQL>
SQL> oradebug dump systemstate 266;
Statement processed.
SQL> oradebug tracefile_name
/s01/admin/G10R25/udump/g10r25_ora_18551.trc

 

分析该systemstate dump

 

Session B一直在等 buffer busy wait

SO: 0xaa42fff8, type: 4, owner: 0xaa3048f8, flag: INIT/-/-/0x00
(session) sid: 164 trans: (nil), creator: 0xaa3048f8, flag: (100051) USR/- BSY/-/-/-/-/-
DID: 0001-0008-00000002, short-term DID: 0000-0000-00000000
txn branch: (nil)
oct: 0, prv: 0, sql: (nil), psql: (nil), user: 0/SYS
service name: SYS$BACKGROUND
waiting for ‘buffer busy waits’ wait_time=0, seconds since wait started=245
file#=2, block#=89, class#=21
blocking sess=0x(nil) seq=12413
Dumping Session Wait History
for ‘buffer busy waits’ count=1 wait_time=0.215431 sec
file#=2, block#=89, class#=21
for ‘buffer busy waits’ count=1 wait_time=0.977438 sec
file#=2, block#=89, class#=21
for ‘buffer busy waits’ count=1 wait_time=0.977538 sec
file#=2, block#=89, class#=21
for ‘buffer busy waits’ count=1 wait_time=0.977512 sec
file#=2, block#=89, class#=21
for ‘buffer busy waits’ count=1 wait_time=0.977480 sec
file#=2, block#=89, class#=21
for ‘buffer busy waits’ count=1 wait_time=0.977488 sec
file#=2, block#=89, class#=21
for ‘buffer busy waits’ count=1 wait_time=0.977639 sec
file#=2, block#=89, class#=21

其stack call为:

Short stack dump:
ksdxfstk()+32<-ksdxcb()+1573<-sspuser()+111<-__restore_rt()+0<-__GI_semtimedop()+10<-sskgpwwait()+265<-skgpwwait()+162<-kslwaitns_timed()+1102<-kskthbwt()+246<-kslwait(
)+228<-kcbzwb()+1496<-kcbgtcr()+23190<-ktugct()+588<-ktbgcl1()+4711<-ktrgcm()+1979<-ktrget()+486<-kdst_fetch()+524<-kdstf0000001kmP()+3137<-kdsttgr()+2427<-qertbFetch()
+650<-qergsFetch()+444<-opifch2()+2944<-opiall0()+2206<-opikpr()+642<-opiodr()+1184<-rpidrus()+196<-skgmstack()+158<-rpidru()+116<-rpiswu2()+409<-kprball()+1270<-kkescF
etch()+83<-kkedsamp()+6304<-kkedsSel()+1495<-kkecdn()+3055<-kkotap()+859<-kkoiqb()+9830<-kkooqb()+904<-kkoqbc()+2093<-apakkoqb()+167<-apaqbdDescendents()+414<-apaqbdLis
tReverse()+68<-apadrv()+573<-opitca()+1545<-kksLoadChild()+9714<-kxsGetRuntimeLock()+1454<-kksfbc()+14910<-kkspsc0()+979<-kksParseCursor()+142<-opiosq0()+1641<-kpooprx(
)+318<-kpoal8()+964<-opiodr()+1184<-ttcpip()+1226<-opitsk()+1310<-opiino()+1024<-opiodr()+1184<-opidrv()+548<-sou2o()+114<-opimai_real()+163<-main()+116<-__libc_start_m
ain()+244<-_start()+41

 

 

file=2 block=0x89 即 137 md: EXCL  被  owner: 0xaa30b888  PID=22持有

SO: 0xaadd91d8, type: 24, owner: 0xaa44f240, flag: INIT/-/-/0xc0
(buffer) (CR) PR: 0xaa30c878 FLG: 0x0
class bit: (nil)
kcbbfbp: [BH: 0x69fe2948, LINK: 0xaadd9218] (WAITING)
where: ktuwh05: ktugct, why: 0
BH (0x69fe2948) file#: 2 rdba: 0x00800089 (2/137) class: 33 ba: 0x69cc6000
set: 3 blksize: 8192 bsi: 0 set-flg: 0 pwbcnt: 0
dbwrid: 0 obj: -1 objn: 0 tsn: 1 afn: 2
hash: [aacc0958,aacc0958] lru: [75fc3228,7eff15a8]
obj-flags: object_ckpt_list
ckptq: [6ef77368,aadf28f8] fileq: [6ef77378,aadf2938] objq: [a7bdd678,6afdf518]
use: [aaddb748,aaddb748] wait: [aaddef10,aadd9218]
st: XCURRENT md: EXCL tch: 465
flags: mod_started gotten_in_current_mode block_written_once
redo_since_read
change state: ACTIVE
change count: 1
LRBA: [0x2d5.10d5a.0] HSCN: [0x0.242e76a] HSUB: [1]
Using State Objects
—————————————-
SO: 0xaaddb708, type: 24, owner: 0xaa454568, flag: INIT/-/-/0x00
(buffer) PR: 0xaa30b888 FLG: 0x1000
class bit: (nil)
kcbbfbp: [BH: 0x69fe2948, LINK: 0xaaddb748]
where: ktuwh02: ktugus, why: 0
Waiting State Objects
—————————————-
SO: 0xaaddeed0, type: 24, owner: 0xaa450598, flag: INIT/-/-/0xc0
(buffer) PR: 0xaa3048f8 FLG: 0x0
class bit: (nil)
kcbbfbp: [BH: 0x69fe2948, LINK: 0xaaddef10] (WAITING)
where: ktuwh02: ktugus, why: 0

 

简单来说这个示例说明了几点:

  1. OLTP类型的小DML操作一般都会是immediate block cleanout的,这要求在commit之前对block做change kcbchg
  2. 在commit kcrf_commit_force完成前都不会释放对该block buffer的buffer pin
  3. 由上述2点造成的buffer pin最终会影响select和其他insert/update/delete 形成buffer busy wait
  4. 由于慢的lgwr写redo log会造成 kcrf_commit_force commit的缓慢,表现在等待事件上就是log file sync
  5. 由于block cleanout时pin block buffer且commit 慢,则会导致更长时间的buffer busy wait
  6. 若log file sync是由lgwr 写redo log慢(log file parallel write)引起的,则它的另一个效应就是buffer busy wait增多
  7. 若看到AWR中log file sync+buffer busy wait是主要等待事件,则优先解决log file sync ,因为buffer busy wait实际可能是受害者

 

AWR中与commit cleanout相关的 Instance activity 有好几个

 

commit cleanout failures: block lost
commit cleanout failures: buffer being written
commit cleanout failures: callback failure
commit cleanout failures: cannot pin
commit cleanouts
commit cleanouts successfully completed

 

【技术分享】开Oracle调优鹰眼,深入理解AWR性能报告

Oracle调优鹰眼系列只有2讲,对AWR感兴趣的同学更多指标可以参考 【性能调优】Oracle AWR报告指标全解析 https://www.askmaclean.com/archives/performance-tuning-oracle-awr.html

 

 

【技术分享】开Oracle调优鹰眼,深入理解AWR性能报告 第一讲https://zcdn.askmaclean.com/%E3%80%90Maclean%20Liu%E6%8A%80%E6%9C%AF%E5%88%86%E4%BA%AB%E3%80%91%E5%BC%80Oracle%E8%B0%83%E4%BC%98%E9%B9%B0%E7%9C%BC%EF%BC%8C%E6%B7%B1%E5%85%A5%E7%90%86%E8%A7%A3AWR%E6%80%A7%E8%83%BD%E6%8A%A5%E5%91%8A.mp4

适合参与成员: 对性能优化有兴趣或急于提升自己oracle技术水平的学员

 

 

 

 

 

讲座材料presentation 当前版本下载:

【Maclean Liu技术分享】开Oracle调优鹰眼,深入理解AWR性能报告_20130303版.pdf.pdf (1.79 MB, 下载次数: 32641)

 

【技术分享】开Oracle调优鹰眼,深入理解AWR性能报告 第二讲

涉及性能优化教学知识:Host CPU、Instance CPU、Wait Class、SQL Statistics、AWR FOR RAC集群特定调优

适合的学员: 对性能优化有兴趣,或给予提升自己Oracle调优技能的同学

预计时长: 2个小时左右

本次公开教学的视频地址:

 

 

 

正式版文档材料已上传:

 

【Maclean Liu技术分享】开Oracle调优鹰眼,深入理解AWR性能报告 第二讲 正式版 20130.pdf (2.27 MB, 下载次数: 30699)

_library_cache_advice和latch:shared pool、latch:shared pool simulator

版本10.2.0.4和11.1.0.6中”_library_cache_advice”=TRUE的情况下可能出现高latch:shared pool、latch: shared pool simulator等latch争用等待事件,默认情况下_library_cache_advice受到参数”statistics_level”的影响为TRUE,当_library_cache_advice=TRUE时他启用library cache simulator特性。

 

该library cache simulator特性负责估算shared pool LRU的表现,simulator模拟器收集heap内存堆大小以及load载入、pin、unpin的次数信息;通过这些数据来估算出若我们有更大的shared pool,我们可以由更大的共享池来缓存更多的SQL、PLSQL在共享池中,以此来节约加载时间。若我们设置更小的shared pool size,则又会对加载时间有何等的影响?

 

题外话:另一个对ASMM 下shared pool有作用的参数:

_memory_broker_shrink_heaps:
  • If 0, will not try to shrink shared pool or Java pool
  • If greater than zero, will wait this many seconds after failed shrink request to ask again

 

禁用library cache simulator设置”_library_cache_advice”=false”可能”(具体仍需要诊断)解决高latch:shared pool、latch: shared pool simulator、Library Cache – Mutex X具体等的问题,禁用library cache simulator会导致AWR中”shared pool advisory”和 “java pool advisory”2个环节不可用,但是这些特性实际可有可无。

但是”_library_cache_advice”=false”时且启用了ASMM(sga_target>0)的情况,注意为shared_pool_size设置一个合理的最小值!

 

分别在10.2.0.4和11.1.0.6上进行了针对解析的压力测试:

10204 no change baseline Executes/second = 3,610, DB Time = 12,349s, DB CPU = 8,938s, latch:library cache wait = 598s, avg.wait = 34ms
10204 – _library_cache_advice=off Executes/second = 3,843, DB Time = 16,208s, DB CPU = 9,402s, latch:library cache wait = 616s, avg. wait = 50ms
11106- no change -baseline Executes/second = 3,529, DB Time = 14,148s, DB CPU = 9,286s, library cache: mutex X wait = 2,725s, avg. wait = 1ms
11106 -session_cache=500, instantiation=150 Executes/second = 3,436, DB Time = 13,396s, DB CPU = 9,040s, library cache: mutex X wait = 2,383s avg. wait = 1ms
11106 – _library_cache_advice=off Executes/second = 6,059, DB Time = 75,134s, DB CPU = 17,321s, library cache: mutex X wait = 38,892s,avg. wait = 1ms

 

 

针对高latch:shared pool、latch: shared pool simulator、Library Cache – Mutex X解析类等待事件,解决的思路包括:

  1. 升级到最新的Patch set + PSU
  2. 考虑cursor_sharing=FORCE
  3. 注意即使_optim_peek_user_binds=false,若你的SQL本身还是有硬绑定的自由变量,则dc_histogram仍可能是硬解析争用的焦点
  4. 设置较大的 session_cachced_cursor和instantiation
  5. 设置library_cache_advice=false
  6. 关闭11g中的ACS自适应游标特性
  7. 关闭11g中的cardinality feedback特性
  8. 使用MSSM,或者 ASMM下 _memory_broker_shrink_heaps=0 + _enable_shared_pool_durations=false

11gR2游标共享新特性带来的一些问题以及_cursor_features_enabled、_cursor_obsolete_threshold和106001 event

版本11gR2中引入cursor sharing游标共享和mutex互斥锁增强的一些特性,而这些特性也带来了一些问题(主要体现在版本11.2.0.1和11.2.0.2上,11.2.0.3上基本已经修复)。

Cursor Obsolescence游标废弃是一种SQL Cursor游标管理方面的增强特性,该特性启用后若parent cursor父游标名下的子游标child cursor总数超过一定的数目,则该父游标parent cursor将被废弃,同时一个新的父游标将被开始。 这样做有2点好处:

  • 避免进程去扫描长长的子游标列表child cursor list以找到一个合适的子游标child cursor
  • 废弃的游标将在一定时间内被age out,其占用的内存可以被重新利用

 

实际在版本10g中就引入了该Cursor Obsolescence游标废弃特性,当时child cursor 的总数阀值是1024, 但是这个阀值在11g中被移除了,这导致出现一个父游标下大量child cursor即high version count的发生;由此引发了一系列的版本11.2.0.3之前的cursor sharing 性能问题,主要症状是版本11.2.0.1和11.2.0.2上出现大量的Cursor: Mutex S 和 library cache lock等待事件。

增强补丁Enhancement patch《Bug 10187168 – Enhancement to obsolete parent cursors if VERSION_COUNT exceeds a threshold》就该问题引入了新的隐藏参数_cursor_obsolete_threshold(Number of cursors per parent before obsoletion.),该”_cursor_obsolete_threshold”参数用以指定子游标总数阀值,若一个父游标的child cursor count<=>version count高于”_cursor_obsolete_threshold”,则触发Cursor Obsolescence游标废弃特性。

 

注意版本11.2.0.3中默认就有”_cursor_obsolete_threshold”了,而且默认值为100。

 

对于版本11.1.0.7、11.2.0.1和11.2.0.2则都有该Bug 10187168的bug backport存在,从2011年5月开始就有相关针对的one-off backport补丁存在。 但是这些one-off backport补丁不使用”_cursor_obsolete_threshold”参数。在版本11.1.0.7、11.2.0.1和11.2.0.2上需要设置合适的”_cursor_features_enabled”(默认值为2)参数,并设置必要的106001 event,该event的level值即是child cursor count的阀值,必须设置该106001事件后该特性才生效。

但是请注意 “_cursor_features_enabled”参数需要重启实例方能生效。而”_cursor_obsolete_threshold”参数和106001 event则可以在线启用、禁用。

对于不同的版本而言,一般推荐打上最新的PSU补丁,并根据补丁的README提示或者咨询Oracle Support获得关于该版本上Cursor Obsolescence问题的信息:
针对不同版本设置 “_cursor_features_enabled”+106001 event的方法:

 

 

 

 

题外话是11.2.0.3中的Mutex增强了很多,不要再跟着初学者论坛的那帮家伙一起愚蠢地大喊:”虽然版本升级 8i=>9i=>10g=>11g=>12c,但是我觉得oracle里面基础、核心的东西一直都没变了”这种神话了, 你一直浮游在Oracle的表面怎么可能知道Kernel到底有多大的变化?!!

详解dbms_stats.gather_fixed_objects_stats

exec dbms_stats.gather_fixed_objects_stats;

 

该gather_fixed_objects_stats存储过程收集的X$基表对象如下,一般建议在系统高峰时段收集 例如大量session登陆之后,以保证v$SESSION、V$PROCESS、V$LOCK等常用视图相关的SQL语句执行计划恰当。

select table_name,num_rows,last_analyzed from dba_tab_statistics where last_analyzed is not null order by last_analyzed desc

 

Table_name Num_rows Last_analyzed
X$XS_SESSION_NS_ATTRIBUTES 0 2013/8/16 9:34
X$XS_SESSION_ROLES 0 2013/8/16 9:34
X$XS_SESSIONS 0 2013/8/16 9:34
X$ZASAXTAB 0 2013/8/16 9:34
X$XSOQOPLU 0 2013/8/16 9:34
X$XSOQSEHI 0 2013/8/16 9:34
X$XSOQOJHI 0 2013/8/16 9:34
X$XSOQOPHI 0 2013/8/16 9:34
X$XSSINFO 0 2013/8/16 9:34
X$XPLTON 141 2013/8/16 9:34
X$XPLTOO 188 2013/8/16 9:34
X$XML_AUDIT_TRAIL 0 2013/8/16 9:34
X$VINST 0 2013/8/16 9:34
X$XSAWSO 16 2013/8/16 9:34
X$XSAGOP 29 2013/8/16 9:34
X$XSOBJECT 0 2013/8/16 9:34
X$XSLONGOPS 0 2013/8/16 9:34
X$XSOQMEHI 0 2013/8/16 9:34
X$XSAGGR 0 2013/8/16 9:34
X$SKGXPIA 0 2013/8/16 9:34
X$TRACE 5810 2013/8/16 9:34
X$TRACE_EVENTS 1000 2013/8/16 9:34
X$TIMEZONE_NAMES 2226 2013/8/16 9:34
X$TIMEZONE_FILE 1 2013/8/16 9:34
X$VERSION 5 2013/8/16 9:34
X$UNFLUSHED_DEQUEUES 0 2013/8/16 9:34
X$RXS_SESSION_ROLES 0 2013/8/16 9:34
X$UNIFIED_AUDIT_RECORD_FORMAT 93 2013/8/16 9:34
X$TEMPORARY_LOB_REFCNT 8 2013/8/16 9:34
X$UGANCO 0 2013/8/16 9:34
X$RULE_SET 1 2013/8/16 9:34
X$TARGETRBA 1 2013/8/16 9:34
X$QUIESCE 1 2013/8/16 9:34
X$QKSMMWDS 1209 2013/8/16 9:34
X$QKSHT 314 2013/8/16 9:34
X$QKSXA_REASON 353 2013/8/16 9:34
X$RULE 1 2013/8/16 9:34
X$RFMP 1 2013/8/16 9:34
X$RFMTE 0 2013/8/16 9:34
X$RFAHIST 0 2013/8/16 9:34
X$RFAFO 0 2013/8/16 9:34
X$RO_USER_ACCOUNT 0 2013/8/16 9:34
X$QKSCESYS 415 2013/8/16 9:34
X$QKSCESES 21165 2013/8/16 9:34
X$QKSBGSYS 884 2013/8/16 9:34
X$QKSBGSES 45084 2013/8/16 9:34
X$QKSCR_RSN 0 2013/8/16 9:34
X$QKSFMPRT 1001 2013/8/16 9:34
X$QKSFMDEP 996 2013/8/16 9:34
X$QKSCR 0 2013/8/16 9:34
X$QKSFM 996 2013/8/16 9:34
X$PROPS 38 2013/8/16 9:34
X$POLICY_HISTORY 0 2013/8/16 9:34
X$OPTIM_CALIB_STATS 25 2013/8/16 9:34
X$ORAFN 188 2013/8/16 9:34
X$PRMSLTYX 26 2013/8/16 9:34
X$PERSISTENT_PUBLISHERS 0 2013/8/16 9:34
X$OPVERSION 1008 2013/8/16 9:34
X$QERFXTST 10 2013/8/16 9:34
X$PERSISTENT_QUEUES 0 2013/8/16 9:34
X$PERSISTENT_SUBSCRIBERS 0 2013/8/16 9:34
X$OPTION 82 2013/8/16 9:34
X$OFS_STATS 0 2013/8/16 9:34
X$OFS_RW_LATENCY_STATS 0 2013/8/16 9:34
X$OBJECT_POLICY_STATISTICS 0 2013/8/16 9:34
X$OFSMOUNT 0 2013/8/16 9:34
X$OPARG 589 2013/8/16 9:34
X$NSV 0 2013/8/16 9:34
X$OPERATORS 1008 2013/8/16 9:34
X$OPDESC 1008 2013/8/16 9:34
X$OCT 242 2013/8/16 9:34
X$MESSAGES 416 2013/8/16 9:34
X$NLS_PARAMETERS 20 2013/8/16 9:34
X$MODACT_LENGTH 1 2013/8/16 9:34
X$MUTEX_SLEEP_HISTORY 77 2013/8/16 9:34
X$MUTEX_SLEEP 14 2013/8/16 9:34
X$MSGBM 0 2013/8/16 9:34
X$NONDURSUB 0 2013/8/16 9:34
X$NONDURSUB_LWM 0 2013/8/16 9:34
X$NFSCLIENTS 0 2013/8/16 9:34
X$NFSOPENS 0 2013/8/16 9:34
X$NFSLOCKS 0 2013/8/16 9:34
X$MESSAGE_CACHE 0 2013/8/16 9:34
X$LOGMNR_TAB$ 0 2013/8/16 9:34
X$LOGMNR_TS$ 0 2013/8/16 9:34
X$LOGMNR_USER$ 0 2013/8/16 9:34
X$LOGMNR_TABPART$ 0 2013/8/16 9:34
X$LOGMNR_TABSUBPART$ 0 2013/8/16 9:34
X$LOGMNR_SESSION 0 2013/8/16 9:34
X$LOGMNR_TYPE$ 0 2013/8/16 9:34
X$LOGMNR_UET$ 0 2013/8/16 9:34
X$LOGMNR_UNDO$ 0 2013/8/16 9:34
X$LOGMNR_SUBCOLTYPE$ 0 2013/8/16 9:34
X$LOGMNR_TABCOMPART$ 0 2013/8/16 9:34
X$LOGMNR_LOGS 0 2013/8/16 9:34
X$LOGMNR_PARAMETERS 0 2013/8/16 9:34
X$LOGMNR_ROOT$ 0 2013/8/16 9:34
X$LOGMNR_OBJ$ 0 2013/8/16 9:34
X$LOGMNR_SEG$ 0 2013/8/16 9:34
X$LOGMNR_PROCESS 0 2013/8/16 9:34
X$LOGMNR_OPQTYPE$ 0 2013/8/16 9:34
X$LOGMNR_PARTOBJ$ 0 2013/8/16 9:34
X$LOGMNR_PROPS$ 0 2013/8/16 9:34
X$LOGMNR_REFCON$ 0 2013/8/16 9:34
X$LOGMNR_NTAB$ 0 2013/8/16 9:34
X$LOGMNR_INDPART$ 0 2013/8/16 9:34
X$LOGMNR_INDSUBPART$ 0 2013/8/16 9:34
X$LOGMNR_LOB$ 0 2013/8/16 9:34
X$LOGMNR_LOBFRAG$ 0 2013/8/16 9:34
X$LOGMNR_LOG 0 2013/8/16 9:34
X$LOGMNR_KOPM$ 0 2013/8/16 9:34
X$LOGMNR_LATCH 0 2013/8/16 9:34
X$LOGMNR_LOGFILE 0 2013/8/16 9:34
X$LOGMNR_KTFBUE 0 2013/8/16 9:34
X$LOGMNR_DICTIONARY 0 2013/8/16 9:34
X$LOGMNR_COL$ 0 2013/8/16 9:34
X$LOGMNR_IND$ 0 2013/8/16 9:34
X$LOGMNR_COLTYPE$ 0 2013/8/16 9:34
X$LOGMNR_ENCRYPTION_PROFILE$ 0 2013/8/16 9:34
X$LOGMNR_DICTIONARY_LOAD 0 2013/8/16 9:34
X$LOGMNR_ENC$ 0 2013/8/16 9:34
X$LOGMNR_CLU$ 0 2013/8/16 9:34
X$LOGMNR_FILE$ 0 2013/8/16 9:34
X$LOGMNR_INDCOMPART$ 0 2013/8/16 9:34
X$LOGMNR_ENCRYPTED_OBJ$ 0 2013/8/16 9:34
X$LOBSTATHIST 18 2013/8/16 9:34
X$LOBSTAT 3 2013/8/16 9:34
X$LOBSEGSTAT 0 2013/8/16 9:34
X$LOGMNR_ATTRIBUTE$ 0 2013/8/16 9:34
X$LE 0 2013/8/16 9:34
X$LOGMNR_CDEF$ 0 2013/8/16 9:34
X$LOGMNR_CALLBACK 0 2013/8/16 9:34
X$LOGBUF_READHIST 16 2013/8/16 9:34
X$LOGMNR_ATTRCOL$ 0 2013/8/16 9:34
X$KZDOS 0 2013/8/16 9:34
X$KZSRO 2 2013/8/16 9:34
X$KZSPR 393 2013/8/16 9:34
X$KZSRT 6 2013/8/16 9:34
X$KZRTPD 0 2013/8/16 9:34
X$KZEKMENCWAL 1 2013/8/16 9:34
X$KZDPSUPSF 3 2013/8/16 9:34
X$KZCKMCS 0 2013/8/16 9:34
X$KZPOPR 99 2013/8/16 9:34
X$KZAJOBS 0 2013/8/16 9:34
X$KZAPARAMS 0 2013/8/16 9:34
X$KZATS 0 2013/8/16 9:34
X$KZCKMEK 0 2013/8/16 9:34
X$KYWMPCTAB 0 2013/8/16 9:34
X$KXSREPLAYLOB 0 2013/8/16 9:34
X$KYWMCLTAB 0 2013/8/16 9:34
X$KYWMNF 0 2013/8/16 9:34
X$KYWMPCMN 0 2013/8/16 9:34
X$KZAHIST 0 2013/8/16 9:34
X$KXTTSTETS 0 2013/8/16 9:34
X$KXTTSTECS 0 2013/8/16 9:34
X$KXTTSTEHS 0 2013/8/16 9:34
X$KXTTSTEIS 0 2013/8/16 9:34
X$KXSREPLAYTIME 0 2013/8/16 9:34
X$KXSREPLAYDATE 0 2013/8/16 9:34
X$KXSREPLAYGUID 0 2013/8/16 9:34
X$KXSREPLAYSEQ 0 2013/8/16 9:34
X$KYWMWRCTAB 0 2013/8/16 9:34
X$KXFSOURCE 0 2013/8/16 9:34
X$KXFTASK 0 2013/8/16 9:34
X$KXSREPLAY 0 2013/8/16 9:34
X$KXSBD 64 2013/8/16 9:34
X$KXSCC 64 2013/8/16 9:34
X$KXFPSMS 70 2013/8/16 9:34
X$KXFPYS 20 2013/8/16 9:34
X$KXFPSST 13 2013/8/16 9:34
X$KXFRSVCHASH 0 2013/8/16 9:34
X$KXFQSROW 0 2013/8/16 9:34
X$KXFPCST 26 2013/8/16 9:34
X$KXFPCMS 70 2013/8/16 9:34
X$KXFPNS 20 2013/8/16 9:34
X$KXFPPIG 0 2013/8/16 9:34
X$KXFPIG 0 2013/8/16 9:34
X$KXFPINSTLOAD 1 2013/8/16 9:34
X$KXFPDP 16 2013/8/16 9:34
X$KXFPPFT 100 2013/8/16 9:34
X$KXFPBS 5 2013/8/16 9:34
X$KXDRS 0 2013/8/16 9:34
X$KXFPCDS 47 2013/8/16 9:34
X$KXFPSDS 47 2013/8/16 9:34
X$KXFPREMINSTLOAD 0 2013/8/16 9:34
X$KXDBIO_STATS 0 2013/8/16 9:34
X$KWSCPJOBSTAT 0 2013/8/16 9:34
X$KWSBGAQPCSTAT 1 2013/8/16 9:34
X$KWSBGQMNSTAT 1 2013/8/16 9:34
X$KWQMNTASKSTAT 23 2013/8/16 9:34
X$KWSBJCSQJIT 0 2013/8/16 9:34
X$KWQPS 0 2013/8/16 9:34
X$KWQPD 0 2013/8/16 9:34
X$KWRSNV 13 2013/8/16 9:34
X$KWSBSMSLVSTAT 2 2013/8/16 9:34
X$KVII 12 2013/8/16 9:34
X$KVIS 0 2013/8/16 9:34
X$KVIT 18 2013/8/16 9:34
X$KUPVJ 0 2013/8/16 9:34
X$KWDDEF 2089 2013/8/16 9:34
X$KWQDLSTAT 32 2013/8/16 9:34
X$KWQBPMT 1 2013/8/16 9:34
X$KWQMNC 1 2013/8/16 9:34
X$KWQMNSCTX 2 2013/8/16 9:34
X$KWQMNTASK 2 2013/8/16 9:34
X$KWQMNJIT 12 2013/8/16 9:34
X$KWQITCX 1 2013/8/16 9:34
X$KTUGD 1 2013/8/16 9:33
X$KTUXE 438 2013/8/16 9:33
X$KTUSMST 7 2013/8/16 9:33
X$KTUSMST2 3 2013/8/16 9:33
X$KTUSUS 10 2013/8/16 9:33
X$KTTETS 11 2013/8/16 9:33
X$KTUTST 0 2013/8/16 9:33
X$KTURHIST 0 2013/8/16 9:33
X$KTUMASCN 1 2013/8/16 9:33
X$KUPVA 0 2013/8/16 9:33
X$KTTVS 11 2013/8/16 9:33
X$KTUCUS 0 2013/8/16 9:33
X$KTSTSSD 1 2013/8/16 9:33
X$KTSSO 1 2013/8/16 9:33
X$KTSTFC 0 2013/8/16 9:33
X$KTSTUSC 8 2013/8/16 9:33
X$KTSLCHUNK 0 2013/8/16 9:33
X$KTSTUSG 8 2013/8/16 9:33
X$KTSPSTAT 1 2013/8/16 9:33
X$KTTEFINFO 11 2013/8/16 9:33
X$KTSSPU 0 2013/8/16 9:33
X$KTSTUSS 8 2013/8/16 9:33
X$KTFTHC 1 2013/8/16 9:33
X$KTFTME 0 2013/8/16 9:33
X$KTPRXRS 0 2013/8/16 9:33
X$KTPRXRT 0 2013/8/16 9:33
X$KTPRHIST 0 2013/8/16 9:33
X$KTSKSTAT 0 2013/8/16 9:33
X$KTIFP 51 2013/8/16 9:33
X$KTIFF 21 2013/8/16 9:33
X$KTIFB 16 2013/8/16 9:33
X$KTIFV 0 2013/8/16 9:33
X$KTRSO 0 2013/8/16 9:33
X$KTCNREGQUERY 0 2013/8/16 9:33
X$KTFBNSTAT 0 2013/8/16 9:33
X$KTFBHC 10 2013/8/16 9:33
X$KTFSTAT 0 2013/8/16 9:33
X$KTFSIMSTAT 0 2013/8/16 9:33
X$KTFSAN 1 2013/8/16 9:33
X$KTFSBI 0 2013/8/16 9:33
X$KTFSRI 0 2013/8/16 9:33
X$KTCXB 517 2013/8/16 9:33
X$KTCSP 0 2013/8/16 9:33
X$KTCNREG 0 2013/8/16 9:33
X$KTFTBTXNMODS 0 2013/8/16 9:33
X$KTFTBTXNGRAPH 0 2013/8/16 9:33
X$KTCNQUERY 0 2013/8/16 9:33
X$KTCNQROW 0 2013/8/16 9:33
X$KTFBFE 32 2013/8/16 9:33
X$KSXRMSG 0 2013/8/16 9:33
X$KSXRREPQ 0 2013/8/16 9:33
X$KSXRCONQ 0 2013/8/16 9:33
X$KSXRSG 1 2013/8/16 9:33
X$KTATL 8 2013/8/16 9:33
X$KTCNINBAND 0 2013/8/16 9:33
X$KTADM 2112 2013/8/16 9:33
X$KTATRFIL 8 2013/8/16 9:33
X$KTATRFSL 8 2013/8/16 9:33
X$KTCNCLAUSES 0 2013/8/16 9:33
X$KSXPPING 0 2013/8/16 9:33
X$KSXPCLIENT 0 2013/8/16 9:33
X$KSXPIF 0 2013/8/16 9:33
X$KSXPIA 0 2013/8/16 9:33
X$KSXAFA 11 2013/8/16 9:33
X$KSWSEVTAB 1792 2013/8/16 9:33
X$KSWSCRSTAB 0 2013/8/16 9:33
X$KSXM_DFT 0 2013/8/16 9:33
X$KSXRCH 0 2013/8/16 9:33
X$KSWSCRSSVCTAB 0 2013/8/16 9:33
X$KSWSASTAB 4 2013/8/16 9:33
X$KSWSCLSTAB 52 2013/8/16 9:33
X$KSUSEX 472 2013/8/16 9:33
X$KSUSGSTA 839 2013/8/16 9:33
X$KSUTM 1 2013/8/16 9:33
X$KSUSGIF 1 2013/8/16 9:33
X$KSWSAFTAB 0 2013/8/16 9:33
X$KSUSIO 472 2013/8/16 9:33
X$KSUVMSTAT 2 2013/8/16 9:33
X$KSUSM 472 2013/8/16 9:33
X$KSUXSINST 1 2013/8/16 9:33
X$KSUSESTA 396008 2013/8/16 9:33
X$KSUSE 472 2013/8/16 9:33
X$KSUSECON 476 2013/8/16 9:33
X$KSUSECST 472 2013/8/16 9:33
X$KSUPR 300 2013/8/16 9:33
X$KSUPRLAT 0 2013/8/16 9:33
X$KSURLMT 27 2013/8/16 9:33
X$KSUPL 10 2013/8/16 9:33
X$KSUPGS 0 2013/8/16 9:33
X$KSURU 4720 2013/8/16 9:33
X$KSUSD 839 2013/8/16 9:33
X$KSUINSTSTAT 0 2013/8/16 9:33
X$KSUMYSTA 839 2013/8/16 9:33
X$KSULOP 8 2013/8/16 9:33
X$KSUPGP 53 2013/8/16 9:33
X$KSUCF 10 2013/8/16 9:33
X$KSUCLNDPCC 0 2013/8/16 9:33
X$KSUCPUSTAT 13 2013/8/16 9:33
X$KSUNETSTAT 0 2013/8/16 9:33
X$KSUPDBSES 254 2013/8/16 9:33
X$KSTEX 0 2013/8/16 9:33
X$KSULV 556 2013/8/16 9:33
X$KSULL 1 2013/8/16 9:33
X$KSQEQTYP 241 2013/8/16 9:33
X$KSQRS 2304 2013/8/16 9:33
X$KSQST 419 2013/8/16 9:33
X$KSRPCIOS 3 2013/8/16 9:33
X$KSRMSGO 0 2013/8/16 9:33
X$KSRCCTX 253 2013/8/16 9:33
X$KSRMSGDES 95 2013/8/16 9:33
X$KSRMPCTX 95 2013/8/16 9:33
X$KSRCHDL 94 2013/8/16 9:33
X$KSRCDES 253 2013/8/16 9:33
X$KSQDN 1 2013/8/16 9:33
X$KSPPI 3341 2013/8/16 9:33
X$KSPPSV 3341 2013/8/16 9:33
X$KSPPSV2 3346 2013/8/16 9:33
X$KSQEQ 5872 2013/8/16 9:33
X$KSPSPFH 1 2013/8/16 9:33
X$KSPVLD_VALUES 701 2013/8/16 9:33
X$KSPPO 133 2013/8/16 9:33
X$KSPSPFILE 3342 2013/8/16 9:33
X$KSMSTRS 4 2013/8/16 9:33
X$KSMUP 3323 2013/8/16 9:33
X$KSMSST 0 2013/8/16 9:33
X$KSMSSINFO 0 2013/8/16 9:33
X$KSOLTD 0 2013/8/16 9:33
X$KSPPCV2 3346 2013/8/16 9:33
X$KSOLSSTAT 22 2013/8/16 9:33
X$KSOLSFTS 24464 2013/8/16 9:33
X$KSO_SCHED_DELAY_HISTORY 902 2013/8/16 9:33
X$KSPPCV 3341 2013/8/16 9:33
X$KSMLRU 10 2013/8/16 9:33
X$KSMSPR 117 2013/8/16 9:33
X$KSMPP 437 2013/8/16 9:33
X$KSMSP_DSNEW 1 2013/8/16 9:33
X$KSMSP_NWEX 22 2013/8/16 9:33
X$KSMSGMEM 12 2013/8/16 9:33
X$KSMLS 5 2013/8/16 9:33
X$KSMPGDST 0 2013/8/16 9:33
X$KSMPGDP 0 2013/8/16 9:33
X$KSMSD 4 2013/8/16 9:33
X$KSMSS 1079 2013/8/16 9:33
X$KSMNS 0 2013/8/16 9:33
X$KSMNIM 0 2013/8/16 9:33
X$KSMPGST 1800 2013/8/16 9:33
X$KSLWSC 6581 2013/8/16 9:33
X$KSLWH 331 2013/8/16 9:33
X$KSLWT 35 2013/8/16 9:33
X$KSMFS 5 2013/8/16 9:33
X$KSMJS 4 2013/8/16 9:33
X$KSMGE 103 2013/8/16 9:33
X$KSMHP 0 2013/8/16 9:33
X$KSMJCH 0 2013/8/16 9:33
X$KSMDD 354 2013/8/16 9:33
X$KSMDUT1 320 2013/8/16 9:33
X$KSMFSV 16387 2013/8/16 9:33
X$KSLPO 458 2013/8/16 9:33
X$KSLLTR 703 2013/8/16 9:33
X$KSLHOT 10 2013/8/16 9:33
X$KSLLCLASS 8 2013/8/16 9:33
X$KSLLD 703 2013/8/16 9:33
X$KSLSCS 13 2013/8/16 9:33
X$KSLES 211456 2013/8/16 9:33
X$KSLSESHIST 943 2013/8/16 9:33
X$KSLLW 6581 2013/8/16 9:33
X$KSI_REUSE_STATS 415 2013/8/16 9:33
X$KSLECLASS 125 2013/8/16 9:33
X$KSLEMAP 1567 2013/8/16 9:33
X$KSLED 1567 2013/8/16 9:33
X$KSLEPX 9 2013/8/16 9:33
X$KSIRPINFO 0 2013/8/16 9:33
X$KSLEI 1567 2013/8/16 9:33
X$KSKPLW 1 2013/8/16 9:33
X$KSKQVFT 0 2013/8/16 9:33
X$KSKQDFT 0 2013/8/16 9:33
X$KSIRGD 0 2013/8/16 9:33
X$KSLCS 6136 2013/8/16 9:33
X$KSIRESTYP 241 2013/8/16 9:33
X$KSIMSI 0 2013/8/16 9:33
X$KSFQP 0 2013/8/16 9:33
X$KSFQDVNT 1 2013/8/16 9:33
X$KSFVQST 192 2013/8/16 9:33
X$KSFVSTA 32 2013/8/16 9:33
X$KSIMAT 5 2013/8/16 9:33
X$KSFMLIB 0 2013/8/16 9:33
X$KSFMIOST 0 2013/8/16 9:33
X$KSFMFILE 0 2013/8/16 9:33
X$KSFMFILEEXT 0 2013/8/16 9:33
X$KSFMSUBELEM 0 2013/8/16 9:33
X$KSIMAV 0 2013/8/16 9:33
X$KSFVSL 0 2013/8/16 9:33
X$KSFDSTCG 96 2013/8/16 9:33
X$KSFDSTCMP 1764 2013/8/16 9:33
X$KSFDSTFILE 53 2013/8/16 9:33
X$KSFDSTBLK 0 2013/8/16 9:33
X$KSFMCOMPL 0 2013/8/16 9:33
X$KSFDSTTHIST 1 2013/8/16 9:33
X$KSFDSTLL 65 2013/8/16 9:33
X$KSFMELEM 0 2013/8/16 9:33
X$KSFMEXTELEM 0 2013/8/16 9:33
X$KSFDSTHIST 13 2013/8/16 9:33
X$KSBDPNEEDED 1 2013/8/16 9:33
X$KSBFT 76 2013/8/16 9:33
X$KSBSRVDT 124 2013/8/16 9:33
X$KSBTABACT 3210 2013/8/16 9:33
X$KSFDFTYP 37 2013/8/16 9:33
X$KSFDSSCLONEINFO 0 2013/8/16 9:33
X$KSDAFT 0 2013/8/16 9:33
X$KSFDKLL 0 2013/8/16 9:33
X$KSDHNG_CHAINS 1 2013/8/16 9:33
X$KSDHNG_SESSION_BLOCKERS 0 2013/8/16 9:33
X$KSDHNG_CACHE_HISTORY 20 2013/8/16 9:33
X$KSDAF 0 2013/8/16 9:33
X$KSBDP 402 2013/8/16 9:33
X$KSBDD 402 2013/8/16 9:33
X$KSAST 300 2013/8/16 9:33
X$KRVXDTA 45 2013/8/16 9:33
X$KRVXTX 0 2013/8/16 9:33
X$KRVXISPLCR 0 2013/8/16 9:33
X$KRVXOP 0 2013/8/16 9:33
X$KRVXTHRD 0 2013/8/16 9:33
X$KRVXWARNV 0 2013/8/16 9:33
X$KRVXISPCHK 0 2013/8/16 9:33
X$KRVXSV 0 2013/8/16 9:33
X$KRVXDKA 32 2013/8/16 9:33
X$KRVSLV 0 2013/8/16 9:33
X$KRVSLVS 0 2013/8/16 9:33
X$KRVSLVPG 0 2013/8/16 9:33
X$KRVSLVST 0 2013/8/16 9:33
X$KRSTALG 13 2013/8/16 9:33
X$KRSTAPPSTATS 1055 2013/8/16 9:33
X$KRSTDGC 0 2013/8/16 9:33
X$KRSTDEST 31 2013/8/16 9:33
X$KRSTPVRS 0 2013/8/16 9:33
X$KRVSLVTHRD 0 2013/8/16 9:33
X$KRSSMS 4 2013/8/16 9:33
X$KRFSTHRD 0 2013/8/16 9:33
X$KRDRSBROV 0 2013/8/16 9:33
X$KRDEVTHIST 0 2013/8/16 9:33
X$KRDMMIRA 0 2013/8/16 9:33
X$KRCGFE 0 2013/8/16 9:33
X$KRCSTAT 1 2013/8/16 9:33
X$KRFBLOG 0 2013/8/16 9:33
X$KRFGSTAT 0 2013/8/16 9:33
X$KRCFH 0 2013/8/16 9:33
X$KRBPHEAD 0 2013/8/16 9:33
X$KRBPDIR 0 2013/8/16 9:33
X$KRCEXT 0 2013/8/16 9:33
X$KRCCDE 0 2013/8/16 9:33
X$KRBZA 3 2013/8/16 9:33
X$KRCCDR 0 2013/8/16 9:33
X$KRCFDE 0 2013/8/16 9:33
X$KRCFBH 0 2013/8/16 9:33
X$KRCBIT 0 2013/8/16 9:33
X$KRCCDS 0 2013/8/16 9:33
X$KRBPDATA 0 2013/8/16 9:33
X$KRBAFF 10 2013/8/16 9:33
X$KRBMSFT 0 2013/8/16 9:33
X$KRBMRST 0 2013/8/16 9:33
X$KRASGA 1 2013/8/16 9:33
X$KRBMCA 6 2013/8/16 9:33
X$KQRST 69 2013/8/16 9:33
X$KQRPD 59 2013/8/16 9:33
X$KQRSD 14 2013/8/16 9:33
X$KRBMROT 0 2013/8/16 9:33
X$KQFTA 1107 2013/8/16 9:33
X$KQFVI 1261 2013/8/16 9:33
X$KQFVT 1261 2013/8/16 9:33
X$KQFDT 37 2013/8/16 9:33
X$KQFCO 18145 2013/8/16 9:33
X$KQFTVRTTST0 1 2013/8/16 9:33
X$KQRFP 7719 2013/8/16 9:33
X$KQRFS 1948 2013/8/16 9:33
X$KQFSZ 45 2013/8/16 9:33
X$KQFP 37 2013/8/16 9:33
X$KQFOPT 129 2013/8/16 9:33
X$KQDPG 1 2013/8/16 9:33
X$KPOQSTA 0 2013/8/16 9:33
X$KPONESTAT 0 2013/8/16 9:33
X$KPONJSTAT 1 2013/8/16 9:33
X$KPPLCONN_INFO 0 2013/8/16 9:33
X$KPONDESTAT 0 2013/8/16 9:33
X$KPPLCC_INFO 0 2013/8/16 9:33
X$KPPLCC_STATS 0 2013/8/16 9:33
X$KPPLCP_STATS 0 2013/8/16 9:33
X$KPONDCONSTAT 0 2013/8/16 9:33
X$KNSTMVR 0 2013/8/16 9:33
X$KNSTCAPS 0 2013/8/16 9:33
X$KNSTRQU 1 2013/8/16 9:33
X$KNSTTXN 0 2013/8/16 9:33
X$KNSTRPP 0 2013/8/16 9:33
X$KNSTXSTS 0 2013/8/16 9:33
X$KNSTOGGC 4 2013/8/16 9:33
X$KNSTSESS 3 2013/8/16 9:33
X$KOCST 1 2013/8/16 9:33
X$KNSTMT 0 2013/8/16 9:33
X$KNSTCAP 0 2013/8/16 9:33
X$KNSTCAPCACHE 0 2013/8/16 9:33
X$KNSTANR 0 2013/8/16 9:33
X$KNSTASL 0 2013/8/16 9:33
X$KNSTACR 0 2013/8/16 9:33
X$KNGFL 0 2013/8/16 9:33
X$KNGFLE 0 2013/8/16 9:33
X$KNLAROW 0 2013/8/16 9:33
X$KNLASG 1 2013/8/16 9:33
X$KMPSRV 8 2013/8/16 9:33
X$KMPCP 4 2013/8/16 9:33
X$KMPCSO 1 2013/8/16 9:33
X$KMPDH 4 2013/8/16 9:33
X$KMPCMON 4 2013/8/16 9:33
X$KMMSI 16 2013/8/16 9:33
X$KMGSTFR 800 2013/8/16 9:33
X$KMGSOP 22 2013/8/16 9:33
X$KMMDI 2 2013/8/16 9:33
X$KMMSG 1 2013/8/16 9:33
X$KMMNV 2 2013/8/16 9:33
X$KMMRD 192 2013/8/16 9:33
X$KMMSAS 1 2013/8/16 9:33
X$KMMHST 1 2013/8/16 9:33
X$KMMDP 1 2013/8/16 9:33
X$KMGSCT 17 2013/8/16 9:33
X$KMGSBSADV 7 2013/8/16 9:33
X$KMGSBSMEMADV 0 2013/8/16 9:33
X$KKOCS_HISTOGRAM 150 2013/8/16 9:33
X$KMCVC 0 2013/8/16 9:33
X$KKOCS_STATISTICS 0 2013/8/16 9:33
X$KLPT 0 2013/8/16 9:33
X$KLCIE 0 2013/8/16 9:33
X$KMCQS 6 2013/8/16 9:33
X$KKOCS_SELECTIVITY 0 2013/8/16 9:33
X$KJZSIWTEVT 0 2013/8/16 9:33
X$KJZNHANGSES 0 2013/8/16 9:33
X$KJZNWLMPCRANK 0 2013/8/16 9:33
X$KJZNRSLNRC 0 2013/8/16 9:33
X$KJZNHNGSTATS 0 2013/8/16 9:33
X$KKOAR_HINT 17 2013/8/16 9:33
X$KKKICR 1 2013/8/16 9:33
X$KKAEET 11 2013/8/16 9:33
X$KKCNRSTAT 0 2013/8/16 9:33
X$KKCNEREG 0 2013/8/16 9:33
X$KKCNEREGSTAT 0 2013/8/16 9:33
X$KJZNHNGMGRSTS 0 2013/8/16 9:33
X$KJR_FREEABLE_CHUNKS 0 2013/8/16 9:33
X$KJXM 0 2013/8/16 9:33
X$KJMSDP 0 2013/8/16 9:33
X$KJMDDP 0 2013/8/16 9:33
X$KJR_CHUNK_STATS 0 2013/8/16 9:33
X$KJZNHANGS 0 2013/8/16 9:33
X$KJZNCBHANGS 0 2013/8/16 9:33
X$KJREQFP 0 2013/8/16 9:33
X$KJRTBCFP 0 2013/8/16 9:33
X$KJPNPX 0 2013/8/16 9:33
X$KJLEQFP 0 2013/8/16 9:33
X$KJISFT 0 2013/8/16 9:33
X$KJILFT 0 2013/8/16 9:33
X$KJKMKGA 0 2013/8/16 9:33
X$KJIRFT 0 2013/8/16 9:33
X$KJITRFT 0 2013/8/16 9:33
X$KJIDT 1 2013/8/16 9:33
X$KJILKFT 0 2013/8/16 9:33
X$KJICVT 0 2013/8/16 9:32
X$KJFMHBACL 0 2013/8/16 9:32
X$KJDRPCMPF 0 2013/8/16 9:32
X$KJDDDEADLOCKS 0 2013/8/16 9:32
X$KJDDDEADLOCKSES 0 2013/8/16 9:32
X$KJCTFS 0 2013/8/16 9:32
X$KJCTFR 0 2013/8/16 9:32
X$KJCTFRI 0 2013/8/16 9:32
X$KJDRMREQ 0 2013/8/16 9:32
X$KJDRPCMHV 0 2013/8/16 9:32
X$KJDRMAFNSTATS 1 2013/8/16 9:32
X$KJDRMREADMOSTLYSTATS 1 2013/8/16 9:32
X$KJDRMHVSTATS 1 2013/8/16 9:32
X$KJDRHV 0 2013/8/16 9:32
X$KGSKVFT 34 2013/8/16 9:32
X$KJCISOT 7 2013/8/16 9:32
X$KJCISPT 2 2013/8/16 9:32
X$KJBR 0 2013/8/16 9:32
X$KJAC_CONFIG 1 2013/8/16 9:32
X$KJBL 0 2013/8/16 9:32
X$KJBLFX 0 2013/8/16 9:32
X$KJAC_ID 0 2013/8/16 9:32
X$KJAC_MY_ID 0 2013/8/16 9:32
X$KJBRFX 0 2013/8/16 9:32
X$KGSKTE 0 2013/8/16 9:32
X$KGSKTO 0 2013/8/16 9:32
X$KGSKCP 2 2013/8/16 9:32
X$KGSKPP 2 2013/8/16 9:32
X$KGSKASP 1 2013/8/16 9:32
X$KGSKSCS 0 2013/8/16 9:32
X$KGSKQUEP 1 2013/8/16 9:32
X$KGSKCFT 2 2013/8/16 9:32
X$KGSKNCFT 2 2013/8/16 9:32
X$KGSKPFT 1 2013/8/16 9:32
X$KGSKDOPP 1 2013/8/16 9:32
X$KGHLU 1 2013/8/16 9:32
X$KGSCC 1 2013/8/16 9:32
X$KGICS 1 2013/8/16 9:32
X$KFVOL 0 2013/8/16 9:32
X$KFVOLSTAT 0 2013/8/16 9:32
X$KFVACFSV 0 2013/8/16 9:32
X$KFZPBLK 0 2013/8/16 9:32
X$KFVACFSTAG 0 2013/8/16 9:32
X$KFVACFSRULESET 0 2013/8/16 9:32
X$KFVACFSRULESETRULE 0 2013/8/16 9:32
X$KFZUDR 0 2013/8/16 9:32
X$KFZGDR 0 2013/8/16 9:32
X$KFZUAGR 0 2013/8/16 9:32
X$KFVACFSS 0 2013/8/16 9:32
X$KFTMTA 0 2013/8/16 9:32
X$KFVACFS 0 2013/8/16 9:32
X$KFVACFSREALM 0 2013/8/16 9:32
X$KFVACFSENCR 0 2013/8/16 9:32
X$KFVACFSRULE 0 2013/8/16 9:32
X$KFVACFSREALMS 0 2013/8/16 9:32
X$KFVACFSREPLTAG 0 2013/8/16 9:32
X$KFVACFSREALMGROUP 0 2013/8/16 9:32
X$KFVACFSREALMFILTER 0 2013/8/16 9:32
X$KFVACFSCMDRULE 0 2013/8/16 9:32
X$KFVACFSADMIN 0 2013/8/16 9:32
X$KFVACFSREPL 0 2013/8/16 9:32
X$KFVACFSREALMUSER 0 2013/8/16 9:32
X$KFRC 0 2013/8/16 9:32
X$KFNSDSKIOST 0 2013/8/16 9:32
X$KFKID 0 2013/8/16 9:32
X$KFKLIB 0 2013/8/16 9:32
X$KFNRCL 0 2013/8/16 9:32
X$KFMDGRP 0 2013/8/16 9:32
X$KFNCL 0 2013/8/16 9:32
X$KFKLSOD 0 2013/8/16 9:32
X$KFGRP_STAT 0 2013/8/16 9:32
X$KFGXP 0 2013/8/16 9:32
X$KFIAS_FILE 0 2013/8/16 9:32
X$KFIAS_PROC 0 2013/8/16 9:32
X$KFIAS_CLNT 0 2013/8/16 9:32
X$KFGRP 0 2013/8/16 9:32
X$KFGMG 0 2013/8/16 9:32
X$KFGBRB 0 2013/8/16 9:32
X$KFGBRW 0 2013/8/16 9:32
X$KFFOF 0 2013/8/16 9:32
X$KFGBRC 0 2013/8/16 9:32
X$KFFXP 0 2013/8/16 9:32
X$KFGBRS 0 2013/8/16 9:32
X$KFFIL 0 2013/8/16 9:32
X$KFENV 0 2013/8/16 9:32
X$KFDSK_STAT 0 2013/8/16 9:32
X$KFDSR 0 2013/8/16 9:32
X$KFDXEXT 0 2013/8/16 9:32
X$KFDSK 0 2013/8/16 9:32
X$KFDFS 0 2013/8/16 9:32
X$KFDSD 0 2013/8/16 9:32
X$KFDPARTNER 0 2013/8/16 9:32
X$KFDDD 0 2013/8/16 9:32
X$KFCBH 0 2013/8/16 9:32
X$KFCCE 0 2013/8/16 9:32
X$KFBH 0 2013/8/16 9:32
X$KFCLLE 0 2013/8/16 9:32
X$KFDAT 0 2013/8/16 9:32
X$KFDAP 0 2013/8/16 9:32
X$KFCSTAT 0 2013/8/16 9:32
X$KFALS 0 2013/8/16 9:32
X$KEWSSVCV 112 2013/8/16 9:32
X$KEWRTB 125 2013/8/16 9:32
X$KEWX_SEGMENTS 0 2013/8/16 9:32
X$KEWX_LOBS 0 2013/8/16 9:32
X$KEWMWPCMV 0 2013/8/16 9:32
X$KEWRATTRSTALE 0 2013/8/16 9:32
X$KEWSSMAP 269 2013/8/16 9:32
X$KEWSSYSV 34 2013/8/16 9:32
X$KEWSSESV 38704 2013/8/16 9:32
X$KEWRSQLCRIT 0 2013/8/16 9:32
X$KEWMRWMV 28761 2013/8/16 9:32
X$KEWMSEMV 70 2013/8/16 9:32
X$KEWMFLMV 30 2013/8/16 9:32
X$KEWMIOFMV 420 2013/8/16 9:32
X$KEWMSMDV 161 2013/8/16 9:32
X$KEWMWCRMV 0 2013/8/16 9:32
X$KEWMRSM 219 2013/8/16 9:32
X$KEWMGSM 14 2013/8/16 9:32
X$KEWMRMGMV 0 2013/8/16 9:32
X$KEWMDRMV 31148 2013/8/16 9:32
X$KEWEFXT 0 2013/8/16 9:32
X$KEWESMS 0 2013/8/16 9:32
X$KEWMAFMV 0 2013/8/16 9:32
X$KEWEPCS 0 2013/8/16 9:32
X$KEWMEVMV 3524 2013/8/16 9:32
X$KEWMDSM 283 2013/8/16 9:32
X$KEWESMAS 0 2013/8/16 9:32
X$KEWECLS 0 2013/8/16 9:32
X$KEWASH 325 2013/8/16 9:32
X$KEWAM 1 2013/8/16 9:32
X$KESWXMON_STATNAME 75 2013/8/16 9:32
X$KETOP 15 2013/8/16 9:32
X$KETCL 7 2013/8/16 9:32
X$KESWXMON_PLAN 2 2013/8/16 9:32
X$KETTG 15 2013/8/16 9:32
X$KELTSD 175 2013/8/16 9:32
X$KESSPAMET 9 2013/8/16 9:32
X$KESPLAN 0 2013/8/16 9:32
X$KERPISTATS 1 2013/8/16 9:32
X$KEOMNMON_SESSTAT 0 2013/8/16 9:32
X$KERPIREPREQ 0 2013/8/16 9:32
X$KESWXMON 5 2013/8/16 9:32
X$KELTOSD 28 2013/8/16 9:32
X$KELTGSD 7 2013/8/16 9:32
X$KELRTD 129 2013/8/16 9:32
X$KELRXMR 3 2013/8/16 9:32
X$KELRSGA 1 2013/8/16 9:32
X$KEHR 82 2013/8/16 9:32
X$KEHPRMMAP 24 2013/8/16 9:32
X$KEHRP 38 2013/8/16 9:32
X$KEHSQT 63 2013/8/16 9:32
X$KEHSYSMAP 10 2013/8/16 9:32
X$KEHOSMAP 9 2013/8/16 9:32
X$KEHTIMMAP 19 2013/8/16 9:32
X$KEHR_CHILD 86 2013/8/16 9:32
X$KDNSSF 472 2013/8/16 9:32
X$KDXST 0 2013/8/16 9:32
X$KDXHS 16 2013/8/16 9:32
X$KEAOBJT 26 2013/8/16 9:32
X$KEACMDN 49 2013/8/16 9:32
X$KEHETSX 9 2013/8/16 9:32
X$KEHF 119 2013/8/16 9:32
X$KEHEVTMAP 105 2013/8/16 9:32
X$KEHECLMAP 12 2013/8/16 9:32
X$KECPDENTRY 0 2013/8/16 9:32
X$KECPRT 0 2013/8/16 9:32
X$KEAFDGN 84 2013/8/16 9:32
X$KCVFH 10 2013/8/16 9:32
X$KCVFHTMP 1 2013/8/16 9:32
X$KDLU_STAT 216 2013/8/16 9:32
X$KDLT 1 2013/8/16 9:32
X$KCVDF 10 2013/8/16 9:32
X$KCTICW 1 2013/8/16 9:32
X$KCTLAX 0 2013/8/16 9:32
X$KCRMF 0 2013/8/16 9:32
X$KCRMT 0 2013/8/16 9:32
X$KCRMX 0 2013/8/16 9:32
X$KCRRDSTAT 31 2013/8/16 9:32
X$KCRFX 0 2013/8/16 9:32
X$KCRRLNS 0 2013/8/16 9:32
X$KCRRNHG 3050 2013/8/16 9:32
X$KCRRASTATS 31 2013/8/16 9:32
X$KCRRARCH 30 2013/8/16 9:32
X$KCMSCN 1 2013/8/16 9:32
X$KCRFWS 1 2013/8/16 9:32
X$KCRFSTRAND 53 2013/8/16 9:32
X$KCPDBINC 0 2013/8/16 9:32
X$KCLQN 0 2013/8/16 9:32
X$KCLRCVST 1 2013/8/16 9:32
X$KCPXPL 20 2013/8/16 9:32
X$KCRFDEBUG 1 2013/8/16 9:32
X$KCFTIO 200 2013/8/16 9:32
X$KCLFX 0 2013/8/16 9:32
X$KCLLS 0 2013/8/16 9:32
X$KCLCRST 1 2013/8/16 9:32
X$KCFISTCAP 0 2013/8/16 9:32
X$KCLCURST 1 2013/8/16 9:32
X$KCLDELTAST 0 2013/8/16 9:32
X$KCFISTSA 11 2013/8/16 9:32
X$KCLPINGPIN 2048 2013/8/16 9:32
X$KCCRSP 0 2013/8/16 9:32
X$KCCRSR 9 2013/8/16 9:32
X$KCFIOHIST 28 2013/8/16 9:32
X$KCFIOFCHIST 0 2013/8/16 9:32
X$KCFIO 200 2013/8/16 9:32
X$KCCRS 42 2013/8/16 9:32
X$KCCRT 1 2013/8/16 9:32
X$KCCTIR 8 2013/8/16 9:32
X$KCCSL 0 2013/8/16 9:32
X$KCCTF 1 2013/8/16 9:32
X$KCCTS 11 2013/8/16 9:32
X$KCFISOSS 0 2013/8/16 9:32
X$KCFISOSSN 0 2013/8/16 9:32
X$KCFISOSSL 0 2013/8/16 9:32
X$KCFISOSST 0 2013/8/16 9:32
X$KCFISOSSC 0 2013/8/16 9:32
X$KCFISCAP 5 2013/8/16 9:32
X$KCCIC 2 2013/8/16 9:32
X$KCCRDI 1 2013/8/16 9:32
X$KCCIRT 1 2013/8/16 9:32
X$KCCNRS 0 2013/8/16 9:32
X$KCCPDB 0 2013/8/16 9:32
X$KCCLE 99 2013/8/16 9:32
X$KCCPA 0 2013/8/16 9:32
X$KCCRM 1 2013/8/16 9:32
X$KCCLH 70 2013/8/16 9:32
X$KCCOR 0 2013/8/16 9:32
X$KCCRL 0 2013/8/16 9:32
X$KCCPD 0 2013/8/16 9:32
X$KCCFN 18 2013/8/16 9:32
X$KCCBI 1 2013/8/16 9:32
X$KCCDL 1 2013/8/16 9:32
X$KCCDFHIST 0 2013/8/16 9:32
X$KCCBLKCOR 0 2013/8/16 9:32
X$KCCCP 8 2013/8/16 9:32
X$KCCCF 2 2013/8/16 9:32
X$KCCDI 1 2013/8/16 9:32
X$KCCDI2 1 2013/8/16 9:32
X$KCCFE 10 2013/8/16 9:32
X$KCCAL 3 2013/8/16 9:32
X$KCCBS 2 2013/8/16 9:32
X$KCCBP 2 2013/8/16 9:32
X$KCCBF 2 2013/8/16 9:32
X$KCCBL 0 2013/8/16 9:32
X$KCCDC 0 2013/8/16 9:32
X$KCCFC 0 2013/8/16 9:32
X$KCCCC 0 2013/8/16 9:32
X$KCCFLE 0 2013/8/16 9:32
X$KCCAGF 1 2013/8/16 9:32
X$KCCACM 9 2013/8/16 9:32
X$KCCADFC 0 2013/8/16 9:32
X$KCBWDS 32 2013/8/16 9:32
X$KCBVBL 0 2013/8/16 9:32
X$KCBWH 1300 2013/8/16 9:32
X$KCBUWHY 1300 2013/8/16 9:32
X$KCBWAIT 19 2013/8/16 9:32
X$KCBWBPD 9 2013/8/16 9:32
X$KCBSW 1300 2013/8/16 9:32
X$KCBTEK 11 2013/8/16 9:32
X$KCBMKID 1 2013/8/16 9:32
X$KCBPRFH 0 2013/8/16 9:32
X$KCBOBH 31016 2013/8/16 9:32
X$KCBMMAV 0 2013/8/16 9:32
X$KCBLSC 64 2013/8/16 9:32
X$KCBPINTIME 2048 2013/8/16 9:32
X$KCBSC 21 2013/8/16 9:32
X$KCBSDS 32 2013/8/16 9:32
X$KCBOQH 1849 2013/8/16 9:32
X$KCBBHS 0 2013/8/16 9:32
X$KCBBES 19 2013/8/16 9:32
X$KCBKWRL 1 2013/8/16 9:32
X$KCBKPFS 400 2013/8/16 9:32
X$KCBBF 3000 2013/8/16 9:32
X$KCBFWAIT 400 2013/8/16 9:32
X$KAUVRSTAT 1 2013/8/16 9:32
X$KBRPSTAT 5 2013/8/16 9:32
X$KCBLDRHIST 1000 2013/8/16 9:32
X$K2GTE2 0 2013/8/16 9:32
X$KCBDWS 1 2013/8/16 9:32
X$KCBDWOBJ 0 2013/8/16 9:32
X$KCBFCIO 0 2013/8/16 9:32
X$KCBDBK 1 2013/8/16 9:32
X$K2GTE 0 2013/8/16 9:32
X$IR_RS_PARAM 0 2013/8/16 9:32
X$JSKJOBQ 1 2013/8/16 9:32
X$JSKSLV 0 2013/8/16 9:32
X$JSKMIMRT 0 2013/8/16 9:32
X$IR_WR_PARAM 0 2013/8/16 9:32
X$IR_WORKING_FAILURE_SET 0 2013/8/16 9:32
X$IR_WORKING_REPAIR_SET 0 2013/8/16 9:32
X$IR_REPAIR_OPTION 0 2013/8/16 9:32
X$IR_REPAIR_STEP 0 2013/8/16 9:32
X$IR_WF_PARAM 0 2013/8/16 9:32
X$JSKMIMMD 0 2013/8/16 9:32
X$GIMSA 24 2013/8/16 9:32
X$INSTANCE_CACHE_TRANSFER 0 2013/8/16 9:32
X$ESTIMATED_MTTR 1 2013/8/16 9:32
X$GLOBALCONTEXT 0 2013/8/16 9:32
X$HEATMAPSEGMENT 19 2013/8/16 9:32
X$IR_MANUAL_OPTION 0 2013/8/16 9:32
X$HOFP 0 2013/8/16 9:32
X$IEE 0 2013/8/16 9:32
X$IEE_ORPIECE 0 2013/8/16 9:32
X$IEE_CONDITION 0 2013/8/16 9:32
X$DURABLE_SHARDED_SUBS 0 2013/8/16 9:32
X$HS_SESSION 0 2013/8/16 9:32
X$DRM_HISTORY 0 2013/8/16 9:32
X$DRM_HISTORY_STATS 0 2013/8/16 9:32
X$DNFS_STATS 0 2013/8/16 9:32
X$DUAL 1 2013/8/16 9:32
X$DRA_FAILURE 75 2013/8/16 9:32
X$DRA_FAILURE_PARAM 189 2013/8/16 9:32
X$DRA_FAILURE_REPAIR_MAP 116 2013/8/16 9:32
X$DRA_REPAIR_PARAM 73 2013/8/16 9:32
X$DRA_FAILURE_REPAIR 264 2013/8/16 9:32
X$DRA_FAILURE_CHECK 53 2013/8/16 9:32
X$DRA_FAILURE_CHECK_MAP 107 2013/8/16 9:32
X$DRA_FAILURE_PARENT_MAP 11 2013/8/16 9:32
X$DRA_REPAIR 112 2013/8/16 9:32
X$DNFS_FILES 0 2013/8/16 9:32
X$DNFS_CHANNELS 0 2013/8/16 9:32
X$DNFS_HIST 0 2013/8/16 9:32
X$DNFS_SERVERS 0 2013/8/16 9:32
X$DNFS_META 1 2013/8/16 9:32
X$DIAG_INFO 11 2013/8/16 9:32
X$DGLPARAM 36 2013/8/16 9:32
X$DGLXDAT 0 2013/8/16 9:32
X$DBKRECO 0 2013/8/16 9:32
X$DBKRUN 6 2013/8/16 9:32
X$DIR 15 2013/8/16 9:32
X$DBKINCMETCFG 1 2013/8/16 9:32
X$DBKINCMETSUMMARY 1 2013/8/16 9:32
X$DBKINCMETINFO 0 2013/8/16 9:32
X$DBKEFEFC 18 2013/8/16 9:32
X$DBKH_CHECK_PARAM 63 2013/8/16 9:32
X$DBKFDG 20 2013/8/16 9:32
X$DBKFSET 0 2013/8/16 9:32
X$DBKINFO 51 2013/8/16 9:32
X$DBKH_CHECK 38 2013/8/16 9:32
X$DBKEFIEFC 512 2013/8/16 9:32
X$CON_KSLSCS 13 2013/8/16 9:32
X$CON_KSLEI 1567 2013/8/16 9:32
X$CON_KSUSGSTA 839 2013/8/16 9:32
X$CKPTBUF 25664 2013/8/16 9:32
X$CONTEXT 0 2013/8/16 9:32
X$CON 1 2013/8/16 9:32
X$CON_KEWSSYSV 34 2013/8/16 9:32
X$DBKEFAFC 7 2013/8/16 9:32
X$DBKEFDEAFC 0 2013/8/16 9:32
X$DBKECE 40 2013/8/16 9:32
X$CELL_NAME 0 2013/8/16 9:32
X$BUFFERED_SUBSCRIBERS 0 2013/8/16 9:32
X$BH 33749 2013/8/16 9:32
X$BMAPNONDURSUB 32 2013/8/16 9:32
X$BUFFER 0 2013/8/16 9:32
X$BUFFERED_PUBLISHERS 0 2013/8/16 9:32
X$BUFFER2 0 2013/8/16 9:32
X$BUFFERED_QUEUES 0 2013/8/16 9:32
X$AUD_OBJ_ACTIONS 19 2013/8/16 9:32
X$AUD_XS_ACTIONS 48 2013/8/16 9:32
X$AUD_OLS_ACTIONS 19 2013/8/16 9:32
X$ASH 581 2013/8/16 9:32
X$AUD_DP_ACTIONS 4 2013/8/16 9:32
X$AUD_DPAPI_ACTIONS 3 2013/8/16 9:32
X$AUD_DV_OBJ_EVENTS 14 2013/8/16 9:32
X$ACTIVECKPT 9 2013/8/16 9:32
X$ABSTRACT_LOB 1 2013/8/16 9:32
X$AQ_SUBSCRIBER_LOAD 0 2013/8/16 9:32
X$QESRSTATALL 7137 2013/8/16 9:32
X$QESRSTAT 0 2013/8/16 9:32
X$QESRCOBJ 0 2013/8/16 9:32
X$QESRCMEM 0 2013/8/16 9:32
X$QESRCDEP 0 2013/8/16 9:32
X$QESRCMSG 0 2013/8/16 9:32
X$QESRCDR 0 2013/8/16 9:32
X$QESRCSTA 13 2013/8/16 9:32
X$QESRCRR 0 2013/8/16 9:32
X$QESMMSGA 38 2013/8/16 9:32
X$QESMMIWT 0 2013/8/16 9:32
X$QESMMIWH 33 2013/8/16 9:32
X$QESMMAPADV 14 2013/8/16 9:32
X$QESRCRD 0 2013/8/16 9:32
X$KQLSET 2689 2013/8/16 9:32
X$QESBLSTAT 20 2013/8/16 9:32
X$QESMMAHIST 462 2013/8/16 9:32
X$KQLFXPL 7099 2013/8/16 9:32
X$KQLFSQCE 714215 2013/8/16 9:32
X$KKSSRD 1720 2013/8/16 9:32
X$KKSSQLSTAT 2956 2013/8/16 9:32
X$KQLFBC 2281 2013/8/16 9:32
X$KKSAI 0 2013/8/16 9:32
X$KKSCS 1704 2013/8/16 9:32
X$KKSBV 2281 2013/8/16 9:32
X$KGLXS 4253 2013/8/16 9:32
X$KGLTR 750 2013/8/16 9:32
X$KGLSIM 18 2013/8/16 9:32
X$KGLOB 15849 2013/8/16 9:32
X$KGLRD 6578 2013/8/16 9:32
X$KGLST 269 2013/8/16 9:32
X$KGLSN 37 2013/8/16 9:32
X$KGLPN 29 2013/8/16 9:32
X$KGLNA1 53213 2013/8/16 9:32
X$KGLLK 436 2013/8/16 9:32
X$KGLAU 478 2013/8/16 9:32
X$KGLDP 5312 2013/8/16 9:32
X$KGLNA 53196 2013/8/16 9:32
X$KGLJSIM 10 2013/8/16 9:32
X$KGLMEM 126 2013/8/16 9:32
X$KGLJMEM 126 2013/8/16 9:32

 

 

  procedure gather_fixed_objects_stats
(stattab varchar2 default null, statid varchar2 default null,
statown varchar2 default null,
no_invalidate boolean default
to_no_invalidate_type(get_param('NO_INVALIDATE')));
--
-- Gather statistics for fixed tables.
-- To run this procedure, you must have the SYSDBA or ANALYZE ANY DICTIONARY
-- system privilege.
--
-- Input arguments:
--   stattab - The user stat table identifier describing where to save
--      the current statistics.
--   statid - The (optional) identifier to associate with these statistics
--      within stattab.
--   statown - The schema containing stattab (if different then ownname)
--   no_invalidate - Do not invalide the dependent cursors if set to TRUE.
--      The procedure invalidates the dependent cursors immediately
--      if set to FALSE.
--      Use DBMS_STATS.AUTO_INVALIDATE to have oracle decide when to
--      invalidate dependend cursors. This is the default. The default
--      can be changed using set_param procedure.
-- Exceptions:
--   ORA-20000: insufficient privileges
--   ORA-20001: Bad input value
--   ORA-20002: Bad user statistics table, may need to upgrade it
--
function report_gather_fixed_obj_stats
(stattab varchar2 default null, statid varchar2 default null,
statown varchar2 default null,
no_invalidate boolean default
to_no_invalidate_type(get_param('NO_INVALIDATE')),
detail_level varchar2 default 'TYPICAL',
format varchar2 default 'TEXT')
return clob;
--
-- This procedure runs gather_fixed_objects_stats in reporting mode. That is,
-- stats are not actually collected, but all the objects that will be
-- affected when gather_fixed_objects_stats is invoked are reported.
-- The detail level for the report is defined by the detail_level
-- input parameter. Please see the comments for report_single_stats_operation
-- on possible values for detail_level and format.
-- For all other input parameters, please see the comments on
-- gather_fixed_objects_stats.
procedure delete_fixed_objects_stats(
stattab varchar2 default null, statid varchar2 default null,
statown varchar2 default null,
no_invalidate boolean default
to_no_invalidate_type(get_param('NO_INVALIDATE')),
force boolean default FALSE);
--
-- Deletes statistics for fixed tables
-- To run this procedure, you must have the SYSDBA or ANALYZE ANY DICTIONARY
-- system privilege.
--
-- Input arguments:
--   stattab - The user stat table identifier describing from where
--      to delete the statistics.  If stattab is null, the statistics
--      will be deleted directly in the dictionary.
--   statid - The (optional) identifier to associate with these statistics
--      within stattab (Only pertinent if stattab is not NULL).
--   statown - The schema containing stattab (if different then ownname)
--   no_invalidate - Do not invalide the dependent cursors if set to TRUE.
--      The procedure invalidates the dependent cursors immediately
--      if set to FALSE.
--      Use DBMS_STATS.AUTO_INVALIDATE to have oracle decide when to
--      invalidate dependend cursors. This is the default. The default
--      can be changed using set_param procedure.
--   force - Ignores the statistics lock on objects and delete
--           the statistics if set to TRUE.
--
-- Exceptions:
--   ORA-20000: insufficient privileges
--   ORA-20002: Bad user statistics table, may need to upgrade it
--
procedure export_fixed_objects_stats(
stattab varchar2, statid varchar2 default null,
statown varchar2 default null);
--
-- Retrieves statistics for fixed tables and stores them in the user
-- stat table identified by stattab
-- To run this procedure, you must have the SYSDBA or ANALYZE ANY DICTIONARY
-- system privilege.
--
-- Input arguments:
--   stattab - The user stat table identifier describing where
--      to store the statistics.
--   statid - The (optional) identifier to associate with these statistics
--      within stattab.
--   statown - The schema containing stattab (if different then ownname)
--
-- Exceptions:
--   ORA-20000: insufficient privileges
--   ORA-20002: Bad user statistics table, may need to upgrade it
--
procedure import_fixed_objects_stats(
stattab varchar2, statid varchar2 default null,
statown varchar2 default null,
no_invalidate boolean default
to_no_invalidate_type(get_param('NO_INVALIDATE')),
force boolean default FALSE);
--
-- Retrieves statistics for fixed tables from the user stat table and
-- stores them in the dictionary
-- To run this procedure, you must have the SYSDBA or ANALYZE ANY DICTIONARY
-- system privilege.
-- The statistics will be imported as pending in case PUBLISH preference
-- is set to FALSE.
--
-- Input arguments:
--   stattab - The user stat table identifier describing from where
--      to retrieve the statistics.
--   statid - The (optional) identifier to associate with these statistics
--      within stattab.
--   statown - The schema containing stattab (if different then ownname)
--   no_invalidate - Do not invalide the dependent cursors if set to TRUE.
--      The procedure invalidates the dependent cursors immediately
--      if set to FALSE.
--      Use DBMS_STATS.AUTO_INVALIDATE to have oracle decide when to
--      invalidate dependend cursors. This is the default. The default
--      can be changed using set_param procedure.
--   force - Override statistics lock.
--     TRUE- Ignores the statistics lock on objects and import
--           the statistics.
--     FALSE-The statistics of an object will be imported only if it
--           is not locked.
--
-- Exceptions:
--   ORA-20000: insufficient privileges
--              if ORA-20000 shows "no statistics are imported", several
--              possible reasons are: (1) user specified statid does not
--              exist; (2) statistics are locked; (3) objects in the
--              stattab no longer exist in the current database
--   ORA-20001: Invalid or inconsistent values in the user stat table
--   ORA-20002: Bad user statistics table, may need to upgrade it

Oracle SQL优化之自动 SQL 优化

  • 描述语句概要分析
  • 使用 SQL 优化指导
  • 使用 SQL 访问指导
  • 使用自动 SQL 优化

自动优化 SQL 语句

  • 自动优化 SQL 语句可简化 SQL 优化的整个过程,并取代手动 SQL 优化。
  • 优化程序模式:

–正常模式

–优化模式或自动优化优化程序 (ATO)

  • SQL 优化指导用于访问优化模式。
  • 应仅对高负载的 SQL 语句使用优化模式。

自动优化 SQL 语句是查询优化程序自动执行整个 SQL 优化过程的功能。此自动过程取代了复杂、重复且费时的手动 SQL 优化功能。SQL 优化指导向用户公开了 SQL 优化的功能。增强的查询优化程序有两种模式:

  • 在正常模式下,优化程序编译 SQL 并生成执行计划。正常模式下的优化程序会为绝大多数的 SQL 语句生成一个合理的执行计划。在正常模式下,优化程序遵循非常严格的时间约束条件,通常为一秒钟的若干分之几,在此期间它必须找到一个有效的执行计划。
  • 在优化模式下,优化程序执行更多分析,检查是否可以进一步改善在正常模式下生成的执行计划。在优化模式下查询优化程序的输出并不是一个执行计划,而是一系列操作及其理由和预期优点(用于生成一个有明显优势的更好计划)。在优化模式下调用的优化程序被称为自动优化优化程序 (ATO)。ATO 执行的优化被称为系统 SQL 优化。

在优化模式下,优化程序可以用几分钟的时间来优化单条语句。对于对整个系统产生重要影响的高负载的复杂 SQL 语句,应使用 ATO。

 

应用程序优化面临的挑战

 

应用程序优化面临的挑战

甚至对于专家而言,确定高负载 SQL 语句并对其进行优化也是一项非常具有挑战性的任务。SQL 优化不仅是数据库服务器性能管理最重要的方面之一,而且也是最难完成的任务之一。从 Oracle Database 10g 开始,确定高负载 SQL 语句的任务由自动数据库诊断监视器 (ADDM) 自动执行。虽然 ADDM 识别的高负载 SQL 语句数量可能只占 SQL 总工作量的一个非常小的百分比,但优化这些语句的任务仍十分复杂,需要具有高水平的专业
知识。

此外,SQL 优化活动是一项持续进行的任务,因为在部署新应用程序模块时 SQL 工作量通常发生相对更改。

Oracle Database 10g 引入的 SQL 优化指导旨在取代手动优化 SQL 语句的过程。消耗大量资源(例如 CPU、I/O 和临时空间)的 SQL 语句是 SQL 优化指导的目标对象。该指导接收一条或多条 SQL 语句作为输入后,会提供有关优化执行计划的建议、该建议的理由、估计的性能改善以及实施建议的实际命令。您可以接受建议,从而优化 SQL 语句。引入 SQL 优化指导后,您现在可以让 Oracle 优化程序为您优化 SQL 代码。

 

SQL 优化指导:概览

SQL 优化指导:概览

 

SQL 优化指导主要是用作优化过程的驱动者。它通过调用自动优化优化程序 (ATO) 来执行以下四种特定类型的分析:

  • 统计信息分析:ATO 检查每个查询对象,确定是否缺少统计信息,或统计信息是否已过时,然后提出收集相关统计信息的建议。同时它还收集辅助信息,以便在无法实施建议的情况下提供缺少的统计信息或更正过时统计信息。
  • SQL 概要分析:ATO 会验证它自身的估计值并收集辅助信息以消除估计错误。同时它还根据 SQL 语句的过去执行历史记录,以自定义优化程序设置(例如第一批行和所有行)的形式收集辅助信息。它使用辅助信息构建一个 SQL 概要文件并提出创建 SQL 概要文件的建议。创建 SQL 概要文件后,此概要文件以正常模式启用查询优化程序,以生成经过良好优化的计划。
  • 访问路径分析:ATO 会检查新索引是否可明显地改进查询中每个表的访问性能,并且在适当的时候提供创建这种索引的建议。
  • SQL 结构分析:在这里,ATO 会尝试确定导致不佳计划的 SQL 语句,并提供相关建议来调整它们。建议的调整可能是对 SQL 代码的语法更改,也可能是语义更改。

过时或缺少的对象统计信息

 

  • 对于优化程序而言,对象统计信息是关键输入。
  • ATO 验证每个查询对象的对象统计信息。
  • ATO 使用动态采样,并生成以下内容:

–辅助对象统计信息,用于弥补缺少的或修正过时的对象
统计信息

–收集合适的对象统计信息的建议:

DBMS_STATS.GATHER_TABLE_STATS(
ownname=>’SH’, tabname=>’CUSTOMERS’,estimate_percent=>DBMS_STATS.AUTO_SAMPLE_SIZE);

 

查询优化程序依赖对象统计信息生成执行计划。如果统计信息已过时或缺少统计信息,则优化程序得不到所需的必要信息,因而生成的执行计划可能不是最理想的。

ATO 检查每个查询对象,确定其是否缺少统计信息或统计信息是否已过时,并生成两种类型的输出:

  • 统计信息形式的辅助信息(适用于没有统计信息的对象)和统计信息调整系数(适用于具有过时统计信息的对象)
  • 为具有过时统计信息或没有统计信息的对象收集相关统计信息的建议

为了获得最佳效果,您应在获得建议时收集统计信息,然后重新运行自动优化程序。但是,如果接受此建议,可能会对系统中的其它查询产生影响,这一点可能令您对是否立即接受建议有所顾虑。

 

SQL 语句概要分析

  • 对于优化程序而言,统计信息是关键输入。
  • ATO 验证语句统计信息,例如:

–谓词选择性

–优化程序设置(FIRST_ROWS 与 ALL_ROWS)

  • 自动优化优化程序使用以下方法和对象:

–动态采样

–执行语句的一部分

–语句的过去执行历史记录统计信息

  • 如果已生成了统计信息,ATO 会构建一个概要文件:

exec :profile_name :=    dbms_sqltune.accept_sql_profile( task_name =>’my_sql_tuning_task‘);

在 SQL 概要分析期间,主要验证步骤是验证查询优化程序自己所估计的被优化语句的成本、选择性和基数。

在 SQL 概要分析期间,ATO 执行验证步骤,以验证自己的估计值。验证包括对数据进行采样,并对样本应用适当的谓词。对新估计值和常规估计值进行比较,如果区别足够大,则应用更正系数。另一种估计值验证方法需要执行 SQL 语句的一部分。在各自谓词都提供有效的访问路径时,部分执行方法比采样方法更高效。ATO 选择适当的估计值验证
方法。

ATO 还可以使用 SQL 语句的过去执行历史记录来确定正确的设置。例如,如果执行历史记录表明在多数时候仅部分执行 SQL 语句,则 ATO 使用 FIRST_ROWS 优化,而不使用
ALL_ROWS。

如果在统计信息分析或 SQL 概要分析期间生成了辅助信息,则 ATO 会构建 SQL 概要文件。在构建 SQL 概要文件后,它会生成一个创建 SQL 概要文件的用户建议。

在此模式下,ATO 可能会建议接受生成的 SQL 概要文件,以将其激活。

 

计划优化流程和 SQL 概要文件创建

计划优化流程和 SQL 概要文件创建

SQL 概要文件是在自动优化 SQL 语句期间构建的辅助信息集合。因此,SQL 概要文件与 SQL 语句对应,而统计信息与表或索引对应。创建概要文件之后,正常模式下的查询优化程序将 SQL 概要文件与现有统计信息结合在一起使用,为相应 SQL 语句生成经过良好优化的计划。SQL 概要文件将永久存储在数据字典中。但是,常规字典视图不会显示 SQL 概要文件信息。在创建 SQL 概要文件后,每次在正常模式下编译相应 SQL 语句时,查询优化程序就会使用 SQL 概要文件生成经过良好优化的计划。

幻灯片显示了创建和使用 SQL 概要文件的流程。此流程包括两个不同阶段:系统 SQL 优化阶段和常规优化阶段。在系统 SQL 优化阶段中,您可以使用 Oracle Enterprise Manager Database Control 或命令行界面选择要进行系统优化的 SQL 语句,并运行 SQL 优化指导。SQL 优化指导会调用 ATO 生成优化建议(ATO 可能会使用 SQL 概要文件)。如果已构建了 SQL 概要文件,则您可以接受它。接受 SQL 概要文件后,此概要文件会存储在数据字典中。在下一阶段,当最终用户发出相同 SQL 语句时,查询优化程序(在正常模式下)会使用 SQL 概要文件构建一个经过良好优化的计划。SQL 概要文件的使用过程对于最终用户是完全透明的,并且不需要对应用程序源代码进行更改。

 

SQL 优化循环

SQL 优化循环

 

SQL 概要文件中包含的辅助信息以特定方式进行存储,在数据库发生更改(如添加或删除索引、表大小增长以及定期收集数据库统计信息)后这些信息仍保持相关。所以,在创建概要文件时,不会冻结相应计划(如在使用大纲时)。

但是,SQL 概要文件可能不再适应数据库中发生的大量更改或者在很长一段时间内累积起来的更改。在这种情况下,需要构建新的 SQL 概要文件,以取代旧的概要文件。

例如,当 SQL 概要文件已过时时,相应 SQL 语句的性能可能会显著变差。在这种情况下,相应 SQL 语句可能会开始表现为高负载或顶级 SQL 语句,因而会再次成为系统 SQL 优化的目标。在这样的情形下,ADDM 会再次将此语句捕获为高负载 SQL。如果发生此情况,您可能决定为该语句重新创造一个新的概要文件。

 

访问路径分析

 

访问路径分析

ATO 还提供有关索引的建议。有效地编制索引是一种广为人知的优化技术,该技术可以通过减少对全表扫描的需求来显著提高 SQL 语句的性能。ATO 生成的任何索引建议都专用于正在进行优化的 SQL 语句。所以,对于与单个 SQL 语句相关的性能问题,它可以提供快速解决方案。

由于 ATO 并不对索引建议会如何影响整个 SQL 工作量执行分析,所以建议对典型 SQL 工作量中的 SQL 语句运行访问指导。访问指导将收集为 SQL 工作量中每条语句提供的建议,并将其合并成对整体 SQL 工作量的全局建议。

访问路径分析可以提供以下建议:

  • 如果新索引能显著改善性能,则创建新索引。
  • 运行 SQL 访问指导,基于应用程序工作量执行全面的索引分析。

 

SQL 结构分析

SQL 结构分析

SQL 结构分析的目标是帮助确定编写不当的 SQL 语句,并就如何调整这些语句提供建议。

语法上的某些变化会对性能产生负面影响。在此模式下,ATO 会根据一组规则对语句进行评估,确定效率较低的编码技术,并提供相应备选语句作为建议。建议可能与原始查询很相似,但不完全相同。例如,NOT EXISTS 和 NOT IN 构造器很相似,但不完全相同。所以,您必须自己确定建议是否有效。由于此原因,ATO 不自动重新编写查询,而是提供建议。

SQL 结构分析可以检测以下类别的问题:

  • SQL 构造器的使用,例如使用了 NOT IN,而不是 NOT EXISTS,或者使用了 UNION 而不是 UNION ALL
  • 谓词的使用,例如谓词涉及的索引列的数据类型不匹配,妨碍索引的使用
  • 设计错误(例如笛卡尔积)

SQL 优化指导:使用模型

SQL 优化指导:使用模型

SQL 优化指导可以接受一条或多条 SQL 语句作为输入。输入可以来自不同的来源:

  • ADDM 确定的高负载 SQL 语句
  • 当前在游标高速缓存中的 SQL 语句
  • 来自自动工作量资料档案库 (AWR) 的 SQL 语句:用户可以选择 AWR 捕获的任何 SQL 语句集。可以使用快照或基线完成此操作。
  • 自定义工作量:用户可以创建一个只包含用户感兴趣的语句的自定义工作量。这些语句可能不在游标高速缓存中,并且不是 ADDM 或 AWR 要捕获的高负载语句。对于这样的语句,用户可以创建一个自定义工作量,并使用指导对其进行优化。

可以对来自游标高速缓存、AWR 和自定义工作量的 SQL 语句进行过滤和排序,然后再将其输入到 SQL 优化指导中。

如果输入的语句有多条,则系统会提供一个名为 SQL 优化集 (STS) 的新对象。STS 可存储多条 SQL 语句及其执行信息:

  • 执行上下文:分析方案名称和绑定值
  • 执行统计信息:平均所用时间和执行计数

:创建 STS 时,可以将另一 STS 用作信息来源。

 

Database Control SQL 优化指导

Database Control 和 SQL 优化指导

从 Oracle Enterprise Manager 访问 SQL 优化指导最简单的方法是使用“Advisor Central(指导中心)”页。在主页中,单击位于“Related Links(相关链接)”部分中的“Advisor Central(指导中心)”链接打开“Advisor Central(指导中心)”页。

在“Advisor Central(指导中心)”页上,单击“SQL Advisors(SQL 指导)”链接。在“SQL Advisors(SQL 指导)”页中,单击“SQL Tuning Advisor(SQL 优化指导)”链接。此时将转到“Schedule SQL Tuning Advisor(调度 SQL 优化指导)”页。在此页中,您会发现到其它不同页的链接。单击“Top Activity(顶级活动)”链接打开“Top Activity(顶级活动)”页。

 

运行 SQL 优化指导:示例

运行 SQL 优化指导:示例

可以使用 Database Control 确定高负载或顶级 SQL 语句。可以从 Database Control 中的多个位置中为所确定的一条或多条 SQL 语句(即 STS)启动 SQL 优化指导:

  • 优化 ADDM 确定的 SQL 语句:ADDM 的“Finding Details(查找结果详细资料)”页会显示 ADDM 确定的高负载 SQL 语句。其中每条高负载 SQL 语句都消耗一个或多个系统资源(例如 CPU 时间、缓冲区获取数、磁盘读取数等等)的很大一部分。可以使用此页对所选高负载 SQL 语句启动 SQL 优化指导。
  • 优化顶级 SQL 语句:另一个 SQL 源是顶级 SQL 语句列表。本幻灯片展示了这种情形。您可以通过查看在所选时间范围内累积的语句执行统计信息,确定顶级 SQL 语句的列表。用户可以选择由 SQL ID 标识的一条或多条顶级 SQL 语句,并对其启动
    SQL 优化指导。
  • 优化一个 SQL 优化集:还可以查看不同用户创建的不同 STS。可能已通过从 AWR 创建的一系列快照中选择 SQL 语句,或通过选择自定义 SQL 语句,基于顶级 SQL 语句列表创建了 STS。

 

实施建议

实施建议

启动 SQL 优化指导之后,Oracle Enterprise Manager 会自动创建优化任务,前提是用户有相应的 ADVISOR 权限来执行此操作。Oracle Enterprise Manager 在“Schedule SQL Tuning Advisor(调度 SQL 优化指导)”页上显示优化任务及其自动默认设置,如上一张幻灯片所示。在此页上,用户可以更改与优化任务相关的自动默认设置。

其中一个重要选项是选择优化任务的范围。如果选择“Limited(有限制)”选项,SQL 优化指导会根据统计信息检查、访问路径分析和 SQL 结构分析来生成建议。将范围设为“Limited(有限制)”时不会生成 SQL 概要文件建议。如果选择“Comprehensive(综合)”选项,SQL 优化指导不仅会执行“Limited(有限制)”范围下的所有建议,如果适用,还会在 SQL 概要分析模式下调用优化程序来构建 SQL 概要文件。使用“Comprehensive(综合)”选项时,还可以指定优化任务的时间限制,这个时间限制的默认值是 30 分钟。另一个有用的选项是立即运行优化任务,或将其安排在以后的时间运行。

可以在“Schedule Advisor(调度指导)”页配置优化任务。要执行此操作,请选择“Schedule SQL Tuning Advisor(调度 SQL 优化指导)”操作,然后单击“Go(执行)”返回“Top Activity(顶级活动)”页后,您可以单击优化过的语句,打开“SQL Details(SQL 详细资料)”页,以便查看优化信息。
这会显示已完成的优化任务。通过单击此任务,可以查看其常规 SQL 优化结果。通过单击“View(查看)”按钮,可以查看其详细资料。如图所示,已创建了 SQL 概要文件;在查看了新计划后,如果需要,则可以实施它。

 

SQL 访问指导:概览

SQL 访问指导:概览

如何定义适当的访问结构以优化 SQL 查询一直是开发人员所关心的问题。因此,为了解决该问题,相关人员已经写了大量的论文和脚本,还开发了一些高端工具。此外,随着分区和实体化视图技术的发展,确定访问结构也变得更加复杂。
作为 Oracle Database 10g  和 11g 中的可管理性增强功能的一部分,引入了 SQL 访问指导来解决这个非常关键的需求。

SQL 访问指导可以建议要创建、删除或保留的索引、实体化视图、实体化视图日志或分区,从而确定并帮助解决与执行 SQL 语句相关的性能问题。可以从 Database Control 或者从命令行使用 PL/SQL 过程来运行 SQL 访问指导。

SQL 访问指导可以接受实际工作量作为输入,或者根据方案推导出一个假想工作量。然后,它会推荐合适的访问结构以使用速度较快的执行路径。SQL 访问指导具有以下优点:

  • 不需要拥有专业知识
  • 根据基于成本的优化程序 (CBO) 中实际存在的规则做决定
  • 与优化程序以及 Oracle DB 增强功能同步
  • 是涵盖 SQL 访问方法所有方面的单个指导
  • 提供用户友好的简单 GUI 向导
  • 生成可用于实施建议的脚本

SQL 访问指导:使用模型

SQL 访问指导:使用模型

SQL 访问指导可接受从以下多个来源派生而来的工作量作为输入:

  • SQL 高速缓存,接受 V$SQL 的当前内容
  • 假想工作量,根据维模型生成一个可能工作量。在初始设计系统时,这个选项比较
    有用
  • SQL 优化集,来自工作量资料档案库

SQL 访问指导还提供强大的工作量过滤功能,可用于确定优化目标。例如,用户可以指定 SQL 访问指导只观察工作量中 30 个资源最密集的语句(根据优化程序开销确定)。对于指定的工作量,SQL 访问指导随后会执行以下操作:

  • 同时考虑索引解决方案、实体化视图解决方案、分区解决方案或者全部三个解决方案的组合
  • 考虑存储的创建和维护成本
  • 不为部分工作量生成删除建议
  • 优化实体化视图以最大化查询重写使用率和快速刷新
  • 建议用于快速刷新的实体化视图日志
  • 建议对表、索引和实体化视图进行分区
  • 将类似的索引组合为单个索引
  • 生成支持多个工作量查询的建议

可能的建议

建议 综合 有限制
对表或实体化视图添加新的(分区的)索引。
删除未使用的索引。
通过更改索引类型修改现有索引。
通过在末尾添加列修改现有的索引。
添加新的(分区的)实体化视图。
删除未使用的实体化视图(日志)。
添加新的实体化视图日志。
修改现有的实体化视图日志以添加新列或子句。
对现有的未分区表或索引进行分区。

 

SQL 访问指导会仔细考虑建议的整体影响,并仅使用已知的工作量和提供的信息生成建议。可以使用两种工作量分析方法:

  • 综合:SQL 访问指导通过这种方法解决优化分区、实体化视图、索引和实体化视图日志的所有方面。SQL 访问指导假定工作量包含一个完整的有代表性的应用程序 SQL 语句集。
  • 有限制:与综合工作量方法不同,有限制的工作量方法假定工作量仅包含有问题的 SQL 语句。因此,将寻求提高一部分应用程序环境性能的建议。

如果选择了综合工作量分析,则 SQL 访问指导将生成一个较好的全局优化优化集,但所需分析时间会比较长。如表中所示,选择的工作量方法决定了 SQL 访问指导生成的建议类型。

:仅对至少包含 10,000 行的表和在 NUMBER 或 DATE 类型的列上有一些谓词或联接的工作量给出分区建议。只能针对这些类型的列生成分区建议。此外,只能为单列间隔分区和散列分区生成分区建议。间隔分区建议可能输出为范围语法,但默认值是间隔。执行散列分区只是为了利用智能化分区联接。

SQL 访问指导会话:初始选项

SQL 访问指导会话:初始选项

接下来的几张幻灯片将介绍一个典型的 SQL 访问指导会话。可以通过单击数据库主页上的“Advisor Central(指导中心)”链接访问 SQL 访问指导,也可以通过单个预警页或性能页进行访问,这些页可能包含用于帮助解决性能问题的链接。SQL 访问指导包括多个步骤,可在执行这些步骤的过程中提供要优化的 SQL 语句,以及要使用的访问方法类型。

在“SQL Access Advisor: Initial Options(SQL 访问指导: 初始选项)”页中,可以在启动向导前选择用来填充默认选项的模板或任务。可以单击“Continue(继续)”启动向导,或者单击“Cancel(取消)”返回到“Advisor Central(指导中心)”页。

:在生成建议的过程中,SQL 访问向导可以被打断,从而允许您查看结果。

有关使用 SQL 访问指导的常规信息,请参阅《Oracle Data Warehousing Guide》“SQL Access Advisor”一课中的“Overview of the SQL Access Advisor”部分。

 

SQL 访问指导会话:初始选项1

如果在“Initial Options(初始选项)”页上选择了“Inherit Options from a Task or Template(从任务或模板继承选项)”选项,则可以选择一个现有的任务或模板以继承 SQL 访问指导的选项。默认情况下,将使用 SQLACCESS_EMTASK 模板。

通过选择相应的对象并单击“View Options(查看选项)”,可以查看任务或模板定义的各种选项。

 

SQL 访问指导:工作量来源

SQL 访问指导:工作量来源

可以从三个不同的来源中选择工作量来源:

  • Current and Recent SQL Activity(当前和最近的 SQL 活动):此来源对应于仍缓存在系统全局区 (SGA) 中的 SQL 语句。
  • Use an existing SQL Tuning Set(使用现有的 SQL 优化集):您也可以创建并使用存放语句的 SQL 优化集。
  • Hypothetical Workload(假想的工作量):此选项将提供允许指导搜索维表并生成工作量的方案。此来源在初始设计方案时很有用。

使用“Filter Options(过滤选项)”部分可以进一步过滤工作量来源。过滤选项有:

  • Resource Consumption(资源消耗):按优化程序成本、缓冲区获取数、CPU 时间、磁盘读取数、所用时间、执行数排序的语句数量
  • Users(用户)
  • Tables(表)
  • SQL Text(SQL 文本)
  • Module IDs(模块 ID)
  • Actions(操作)

SQL 访问指导:建议选项

SQL 访问指导:建议选项

在“Recommendations Options(建议选项)”页中,可以选择是否限制 SQL 访问指导基于单个访问方法提出建议。可以选择 SQL 访问指导要推荐的结构的类型。如果没有选择三个可能值中的任何一个,则 SQL 访问指导将评估现有的结构,而不尝试推荐新结构。

可以使用“Advisor Mode(指导模式)”部分,以两种模式之一运行指导。这些模式会影响建议的质量和处理所需的时间。在“Comprehensive Mode(综合模式)”中,指导将搜索候选的大型池,以便得到最高质量的建议。在“Limited Mode(限制模式)”中,SQL 访问指导将快速执行,通过仅处理最高成本的语句来限制候选建议。

:可以单击“Advanced Options(高级选项)”以显示或隐藏选项,这些选项可用于设置空间限制、优化选项和默认存储位置。

SQL 访问指导:安排和复查

SQL 访问指导:安排和复查

SQL 访问指导:结果

SQL 访问指导:结果

通过“Advisor Central(指导中心)”页,可以检索用于您的分析的任务详细资料。通过选择“Advisor Central(指导中心)”页上“Results(结果)”部分中的任务名称,可以访问“Results for Task(任务结果)”的“Summary(概要)”页;可在此页上看到 SQL 访问指导查找结果的概览。该页中显示了图表和统计信息,为建议提供了整体工作量性能和改善查询执行时间方面的可能性。使用该页可以显示语句计数和建议操作计数。

SQL 访问指导:结果和实施

SQL 访问指导:结果和实施

要查看 SQL 访问指导任务结果的其它方面,可单击该页上其它三个选项卡之一:“Recommendations(建议)”、“SQL Statements(SQL 语句)”或“Details(详细
资料)”。

在“Recommendation(建议)”页上,可以细化到各个建议。对于其中的每个建议,可以查看“Select Recommendations for Implementation(选择要实施的建议)”表中的重要信息。然后,可以选择一个或多个建议,并安排实施。

如果单击特定建议的 ID,则将进入“Recommendation(建议)”页,该页显示了指定建议的所有操作,可以根据需要修改语句的表空间名称。完成了任何更改后,单击“OK(确定)”将应用更改。在“Recommendation(建议)”页中,可以查看一个操作的完整文本,方法是单击指定操作的“Action(操作)”字段中的链接。单击“Show SQL(显示 SQL)”可以查看建议中所有操作的 SQL。

“SQL Statements(SQL 语句)”页(本幻灯片没有显示此页)显示了一个图表和一个对应的表,其中列出了最初按成本改善程度由高到低排序的 SQL 语句。最上面的 SQL 语句通过实施关联建议可得到最大程度的改善。

“Details(详细资料)”页显示了创建任务时所用的工作量和任务选项。此页还提供了在任务执行过程中记录的所有日记条目。

还可以通过单击“Schedule Implementation(安排实施)”按钮来安排建议的实施。

SQL 优化循环

SQL 优化循环1

Oracle Database 10g 引入了 SQL 优化指导,用于帮助应用程序开发人员改善 SQL 语句的性能。该指导用于解决 SQL 编写不当这一问题;这些 SQL 语句没有采用最有效的方式进行设计。此外,该优化指导还可以解决 SQL 语句执行效果较差的问题(此问题较常见),对于这些 SQL 语句,优化程序由于缺乏精确的相关数据统计信息而生成了较差的执行计划。在所有情况下,该指导都会提供具体的建议来提高 SQL 性能,但是否实施建议由用户决定。

除了 SQL 优化指导以外,Oracle Database 10g 还有一个自动进程,可确定系统中的高负载 SQL 语句。ADDM 就是这样的进程,它可自动确定应进行优化的高负载 SQL 语句。

但是,还是存在一些重要问题:虽然 ADDM 确实可以确定一些应该进行优化的 SQL,但用户仍必须手动查看 ADDM 报表,然后根据这些报表运行 SQL 优化指导以进行优化。

自动 SQL 优化

自动 SQL 优化

Oracle Database 11g 可以确定有问题的 SQL 语句,对这些语句运行 SQL 优化指导,并实施获得的 SQL 概要文件建议来优化语句,不需要用户的干预,因而进一步提高了 SQL 优化进程的自动化程度。自动 SQL 优化通过在默认情况下每晚运行的名为“自动 SQL 优化”的新任务使用 AUTOTASK 框架。下面简要描述了 Oracle Database 11g 中的自动 SQL 优化过程:

  • 步骤 1:根据 AWR 顶级 SQL 标识(在以下四个不同时间段处于顶级的 SQL:过去一周、过去一周中的任何一天、过去一周中的任何一小时或者单个响应时间),自动 SQL 优化可以确定自动优化目标。
  • 步骤 2 和 3:在维护窗口中执行自动 SQL 优化任务时,将通过调用 SQL 优化指导自动优化以前确定的 SQL 语句。因此,如果需要,将为这些语句创建 SQL 概要文件。但是,在做出决定之前,需要认真测试新的概要文件。
  • 步骤 4:您在任何时间点都可以请求有关这些自动优化活动的报表。
    然后,可以选择检查优化的 SQL 语句以验证或删除生成的自动 SQL 概要文件。

 

自动优化过程

自动优化过程

在优化过程中,将考虑并报告所有建议类型,但只能自动实施 SQL 概要文件(ACCEPT_SQL_PROFILES 任务参数设置为 TRUE 时)。在其它情况下,仅在自动 SQL 优化报表中报告创建 SQL 概要文件的建议。

在 Oracle Database 11g 中,性能改善系数必须至少等于三,才会实施 SQL 概要文件。正如我们所看到的,自动 SQL 优化过程仅自动实施 SQL 概要文件建议。在 SQL 优化过程中会生成其它建议(用于创建新索引、刷新过时统计信息或调整 SQL 语句),但并不实施这些建议。您需要对这些建议进行检查,然后在适当的情况下手动实施。

下面简要描述了常规自动优化过程:

优化以语句为单位执行。因为只能实施 SQL 概要文件,所以不需要考虑此类建议对工作量的整体影响。对于每条语句(按重要性排序),优化过程将执行以下各个步骤:

  1. 使用 SQL 优化指导优化语句。查找 SQL 概要文件;如果找到了此概要文件,则验证其基础优化程序统计信息是否为最新。
  1. 如果建议了某个 SQL 概要文件,则执行以下操作:

-通过在使用该建议和不使用该建议两种情况下执行语句,测试新的 SQL 概要
文件。

-如果生成了 SQL 概要文件,并且该文件导致优化程序为该语句选择了一个不同的执行计划,则优化指导必须确定是否实施 SQL 概要文件。优化指导将根据幻灯片中的流程图做出决定。虽然此处的性能提高阈值适用于 CPU 时间和输入/输出 (I/O) 时间的总和,但是,如果其中任意一方的统计信息表现出性能下降,就不会接受 SQL 概要文件。因此,要求 CPU 时间和 I/O 时间的总和改善三倍,并且其中任意一方的统计信息中没有表现出性能下降。通过这种方式,语句的运行速度将比不使用概要文件时快,即使出现 CPU 或 I/O 的争用情况也是如此。

  1. 如果发现了过时或丢失的统计信息,则将此类信息提供 GATHER_STATS_JOB。

自动实施优化建议仅适用于 SQL 概要文件,因为 SQL 概要文件的风险较小,还原实施很容易。

:所有 SQL 概要文件都是以标准 EXACT 模式创建的。系统会根据 CURSOR_SHARING 参数的当前值匹配和跟踪这些概要文件。您负责为工作量正确地设置 CURSOR_SHARING。

 

自动 SQL 优化控制

  • 自动任务配置:

–打开/关闭开关

–运行优化任务的维护窗口

–优化任务的 CPU 资源消耗

  • 任务参数:

–SQL 概要文件实施自动/手动开关

–优化任务的全局时间限制

–优化任务的每个 SQL 的时间限制

–禁用测试-执行模式以节省时间

–为每个执行以及从整体上自动实施的最大 SQL 概要
文件数

–任务执行有效期

 

 

以下是自动 SQL 优化任务的一个 PL/SQL 控制示例:

BEGIN
dbms_sqltune.set_tuning_task_parameter(‘SYS_AUTO_SQL_TUNING_TASK’, ‘LOCAL_TIME_LIMIT’, 1400);
dbms_sqltune.set_tuning_task_parameter(‘SYS_AUTO_SQL_TUNING_TASK’, ‘ACCEPT_SQL_PROFILES’, ‘TRUE’);
dbms_sqltune.set_tuning_task_parameter(‘SYS_AUTO_SQL_TUNING_TASK’, ‘MAX_SQL_PROFILES_PER_EXEC’, 50);
dbms_sqltune.set_tuning_task_parameter(‘SYS_AUTO_SQL_TUNING_TASK’, ‘MAX_AUTO_SQL_PROFILES’, 10002);
END;
此示例中的最后三个参数仅在自动 SQL 优化任务中受支持。您还可以使用 LOCAL_TIME_LIMIT 或 TIME_LIMIT 之类的参数;这些参数是传统 SQL 优化任务的有效参数。一个重要的示例是通过使用 TEST_EXECUTE 参数,禁用测试-执行模式(以节省时间),并仅使用执行计划成本做出有关性能的决定。

此外,还可以控制自动 SQL 优化任务的运行时间以及允许使用的 CPU 资源。

 

自动 SQL 优化任务

自动 SQL 优化任务

如前所述,自动 SQL 优化是作为自动维护任务实施的;该任务本身称为“自动 SQL 优化”。在“Automated Maintenance Tasks(自动维护任务)”页中可以看到与最近运行的自动 SQL 优化任务相关的一些高级别信息:要打开此页,请在 Database Control 主页中单击“Server(服务器)”选项卡。在打开的“Server(服务器)”选项卡式页中,单击“Tasks(任务)”部分中的“Automated Maintenance Tasks(自动维护任务)”链接。

在“Automated Maintenance Tasks(自动维护任务)”页上,可以看到预定义的任务。然后,单击相应的链接访问每个任务,获取有关任务本身的详细信息(如幻灯片中所示)。单击“Automatic SQL Tuning(自动 SQL 优化)”链接或最近的执行的图标(时间表上的绿色区域)时,“Automatic SQL Tuning Result Summary(自动 SQL 优化结果概要)”页就会打开。

 

配置自动 SQL 优化

配置自动 SQL 优化

可以使用“Automatic SQL Tuning Settings(自动 SQL 优化设置)”页配置各种自动 SQL 优化参数。

要定位至该页,请单击“Automated Maintenance Tasks(自动维护任务)”页上的“Configure(配置)”按钮。此时您会看到“Automated Maintenance Tasks Configuration(自动维护任务配置)”页,可在其中查看 Oracle Database 11g 提供的各种维护窗口。

默认情况下,自动 SQL 优化可在 MAINTENANCE_WINDOW_GROUP 中的所有预定义维护窗口上运行。可以针对一周中的特定日期禁用自动 SQL 优化。在此页上,还可以编辑每个窗口以更改其特性,方法是单击“Edit Window Group(编辑窗口组)”按钮。

要定位至“Automatic SQL Tuning Settings(自动 SQL 优化设置)”页,请在“Task Setting(任务设置)”部分中单击与“Automatic SQL Tuning(自动 SQL 优化)”对应的行上的“Configure(配置)”按钮。

在“Automatic SQL Tuning Settings(自动 SQL 优化设置)”页上,可以指定幻灯片中显示的参数。默认情况下,“Automatic Implementation of SQL Profiles(自动实施 SQL 概要文件)”处于未选中状态。

:如果将 STATISTICS_LEVEL 设置为 BASIC,使用 BMS_WORKLOAD_REPOSITORY 关闭 AWR 快照,或者 AWR 保留期限少于七天,也会停止自动 SQL 优化。

 

自动 SQL 优化:结果概要

自动 SQL 优化:结果概要

此外,“Automatic SQL Tuning Result Summary(自动 SQL 优化结果概要)”页还包含各种概要图形,您可以用来控制自动 SQL 优化任务。幻灯片中显示了一个示例。“Overall Task Statistics(总体任务统计信息)”部分的第一个图形按指定时段的查找结果类型显示细分。通过选择“Time Period(时段)”列表中的值,可以控制要为其生成报表的时段。示例中使用了“Customized(定制)”,显示的是最近一次运行。可以选择“All(所有)”涵盖迄今为止该任务的所有执行。用户可以请求过去一个月中任何时段的运行,因为这是优化指导保留其优化历史记录的时间期限。然后,单击“View Report(查看报表)”生成报表。

在“Breakdown by Finding Type(按照查找结果细分)”图形上,可以清楚地看到仅 SQL 概要文件可以实施。虽然还推荐了许多其它概要文件,但并非所有概要文件都被自动实施,原因如前所述。类似地,创建索引的建议以及其它类型的建议不会被实施。但是,如果希望以后实施这些建议,优化指导会保留与所有这些建议有关的历史信息。

在“Profile Effect Statistics(概要文件效果统计信息)”部分,可以看到“Tuned SQL DB Time Benefit(优化后的 SQL DB 时间优势)”图形,该图形显示了实施概要文件和其它建议前后的 DB 时间。

 

自动 SQL 优化:结果详细资料

自动 SQL 优化:结果详细资料

在“Automatic SQL Tuning Result Details(自动 SQL 优化结果详细资料)”页上,还可以看到各个自动优化的 SQL 语句的重要信息,包括语句的 SQL 文本和 SQL ID、SQL 优化指导执行的建议类型、经过验证的性能提高百分比、是否自动实施了特定建议以及建议的日期等。

在此页中,可以单击 SQL 语句的相应 SQL ID 链接细化到 SQL 语句本身;也可以选择其中一条 SQL 语句,然后单击“View Recommendations(查看建议)”按钮,了解有关该语句的建议的其它详细资料。

:所显示的每个建议的性能提高百分比是使用以下公式得出的:
bnf% = (time_old – time_new)/(time_old)。使用此公式,您可以看出三倍性能优势(例如,time_old = 100、time_new = 33)的对应值为 66%。因此,该系统实施所有性能提高超过 66% 的概要文件。根据此公式,98% 表示获得 50 倍的优势。

自动 SQL 优化结果详细资料:细化

自动 SQL 优化结果详细资料:细化

在“Recommendations for SQL ID(以下 SQL ID 的建议)”页上,可以看到对应的建议,可以手动实施这些建议。

单击“SQL Test(SQL 测试)”链接可以访问“SQL Details(SQL 详细资料)”页;在此页上可以看到优化历史记录以及与 SQL 语句关联的计划控制。

在幻灯片中,可以看到自动 SQL 优化已经优化了该语句,并且已自动实施了关联的概要文件。

 

自动 SQL 优化注意事项

  • 自动 SQL 优化不考虑的 SQL:

–临时 SQL 或极少重复的 SQL

–并行查询

–概要分析后长时间运行的查询

–递归 SQL 语句

–DML 和 DDL

  • 仍可使用 SQL 优化指导对上述语句进行手动优化。

自动 SQL 优化并不力求解决系统中出现的所有 SQL 性能问题。它不考虑以下类型的 SQL:

  • 临时 SQL 或极少重复的 SQL:如果某条 SQL 不以相同的形式执行多次,则优化指导将忽略该语句。在一周内没有重复出现的 SQL 也不在考虑之列。
  • 并行查询。
  • 长时间运行的查询(概要分析后):如果某个查询在经过 SQL 概要分析后运行的时间太长,则进行测试-执行就不很实际,因此优化指导将其忽略。请注意,这并不意味着优化指导将忽略所有长时间运行的查询。如果优化指导可以找到一个 SQL 概要文件,让原本花费几小时的查询在几分钟内运行,则可能接受此概要文件,因为仍然可以进行测试-执行。优化指导会用足够长的时间执行旧计划,确定旧计划劣于新计划后,就会终止测试-执行而不等待旧计划完成,并因此切换执行的顺序。
  • 递归 SQL 语句
  • DML,例如 INSERT SELECT 或 CREATE TABLE AS SELECT

除了真正的临时 SQL,上述限制仅适用于自动 SQL 优化。仍可手动运行 SQL 优化指导对上述语句进行优化。

 

 

沪ICP备14014813号

沪公网安备 31010802001379号