ORACLE 11g新特性

摘自：http://blog.chinaunix.net/uid-7540710-id-135049.html

11g新特性:SQL Performance Analyzer(SPA)

系统变更会影响SQL的执行计划，比如数据库升级，优化参数调整，表结构变更，索引维护（创建，删除，重建），统计信息收集等，Oracle为了预防系统变更所引起的不良后果，特推出SPA，SPA做为RAT(Real Application Test)的一部分，可以消除一些不知预知的错误，Oracle提供dbms_sqlpa包来实现系统变更前后的性能分析，SPA主要应用在以上方面： ■ Database upgrade ■ Configuration changes to the operating system, hardware, or database ■ Database initialization parameter changes ■ Schema changes, for example, adding new indexes or materialized views ■ Gathering optimizer statistics ■ SQL tuning actions, for example, creating SQL profiles 1 使用SPA的前提条件 由于数据库的复杂性，如果想使用SPA来度量生产库变更对性能影响的话，测试环境的软硬件配置需要与生产环境是一致的，同样DB的初始化参数等也要求与产品库是一致的，可以用RMAN，DATA PUMP等工具创建测试环境。 2 导入负载到测试环境 把生产库上需要测试的SQL装载到SQL Tuning Set(STS)，然后导出STS到测试环境。 3 创建SPA TASK declare VAR v_spa_name VARCHAR2(100); begin :t_name := DBMS_SQLPA.CREATE_ANALYSIS_TASK( sqlset_name => 'my_sts',  task_name => 'my_spa_task'); end; 4 变更前执行SPA TASK EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK( task_name => 'my_spa_task', - execution_type => 'TEST EXECUTE', - execution_name => 'my_exec_BEFORE_change'); 5 执行变更 比如修改优化参数&添加或删除索引&收集表与索引的统计信息等 6 变更后执行SPA TASK EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK( task_name => 'my_spa_task', - execution_type => 'TEST EXECUTE', - execution_name => 'my_exec_AFTER_change'); 7 比较SQL性能 EXEC DBMS_SQLPA.EXECUTE_ANALYSIS_TASK( task_name => 'my_spa_task', - execution_type => 'COMPARE PERFORMANCE', - execution_name => 'my_exec_compare', - execution_params => dbms_advisor.arglist('comparison_metric', 'buffer_gets')); 8 报告SPA分析结果 VAR rep CLOB; EXEC :rep := DBMS_SQLPA.REPORT_ANALYSIS_TASK('my_spa_task','text', 'typical', 'summary'); SET LONG 100000 LONGCHUNKSIZE 100000 LINESIZE 130 PRINT :rep

11g新特性:Automatic SQL Tuning Advisor

在11g中，优化器有两种模式：普通模式与调化模式。优化器在普通模式下，当SQL被执行时，查询优化器将生成SQL的执行计划，如果SQL的可选路径很多，优化器必须是限制时间内，选择一个合适的执行计划；当优化器在调优模式下，优化器需要执行额外的分析去判断优化器在普通模式下产生的执行计划是否有可能被改进，此时优化器输出的不是一个执行计划，而是一系列的动作，根据调优的原理、产生一个更优化的执行计划，优化器需发花费一定的时间去调优单个的sql，自动调优的优化器每次查询都是硬解析。 The Automatic Tuning Optimizer performs four types of tuning analysis: ■ Statistics Analysis ■ SQL Profiling ■ Access Path Analysis ■ SQL Structure Analysis 1 Automatic SQL Tuning Advisor A 从AWR报表中识别High-Load SQL B 调用SQL Tuning Advisor调优识别的High-Load SQL C 执行SQL测试它的SQL Profile 2 Enabling Automatic SQL Tuning BEGIN DBMS_AUTO_TASK_ADMIN.ENABLE( client_name => 'sql tuning advisor', operation => NULL, window_name => NULL); END; / 3 Disabling Automatic SQL Tuning BEGIN DBMS_AUTO_TASK_ADMIN.DISABLE( client_name => 'sql tuning advisor', operation => NULL, window_name => NULL); END; / 4 Configuring Automatic SQL Tuning BEGIN DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER( task_name => 'SYS_AUTO_SQL_TUNING_TASK', parameter => 'ACCEPT_SQL_PROFILES',  value => 'TRUE'); END; / 说明：sys_auto_sql_tuning_task是系统产生的auto task. 5 查看tuning report SQL> set long 1000 SQL> set longchunksize 1000 SQL> set linesize 100 SQL> select dbms_sqltune.report_tuning_task('SYS_AUTO_SQL_TUNING_TASK') from dual; 6 Automatic SQL Tuning Directory SQL> select task_id,task_name from dba_advisor_tasks where task_id = 1; TASK_ID TASK_NAME ---------- ------------------------------------------------------------ 1 SYS_AUTO_SQL_TUNING_TASK SQL> select task_id,name,value from WRI$_ADV_PARAMETERS where task_id = 1; 7 注意事项 由于Automatic SQL Tuning Advisor是从AWR中识别 High-Load SQL，所以它不可能是实时地去工作。。。 11g新特性:database replay workload capture的限制   在11g中，Real Application Testing（RAT）是一个独立的收费选项，所以当我们需要订购此项服务时，我们该了解该服务有那些限制，否则付了钱，发现有许多地方存在或多或少的冲突，有些冲突的消除可能要花费更大的成本，所以在上项目前，可行性技术研究是必不可少的，如果想使用RAT，需要关注现有的数据库系统是否涉及到如下技术： Workload Capture Restrictions: ■ Direct path load of data from external files using utilities such as SQL*Loader ■ Shared server requests (Oracle MTS) ■ Oracle Streams ■ Advanced replication streams ■ Non-PL/SQL based Advanced Queuing (AQ) ■ Flashback queries ■ Oracle Call Interface (OCI) based object navigations ■ Non SQL-based object access ■ Distributed transactions (any distributed transactions that are captured will bereplayed as local transactions) ■ Remote DESCRIBE and COMMIT operations

11g新特性:SQL Management Base(SMB)

在Oracle 11g，SMB是SPM的控制端，SMB是数据字典的一部分，SMB存储在sysaux表空间，SMB存储SQL语句日志，Plan Histories，以及SQL Profiles等，SMB允许每周清除一次未使用的SQL Plan & Log，SMB已经配置了自动存储空间管理。 1 Disk Space Usage SMB默认可以使用sysaux表空间的10%，SMB被允许使用sysaux的存储范围是1%-50%，每周有后台进程来测量SMB使用sysaux的空间，如果SMB超过了允许的范围，就会在al*.log中写入一条警告，可以通过dbms_spm的configure过程设置SMB允许使用存储空间的范围。 BEGIN DBMS_SPM.CONFIGURE('space_budget_percent', 30); END; / 2 Purging Policy 也可以通过dbms_spm的configure过程设置SMB清除策略： BEGIN DBMS_SPM.CONFIGURE('plan_retention_weeks', 105); END; / 3 SMB Configuration Parameters 可以通过DBA_SQL_MANAGEMENT_CONFIG视图来查看配置参数 select parameter_name, parameter_value from dba_sql_management_config; 4 创建stage表 BEGIN DBMS_SPM.CREATE_STGTAB_BASELINE(table_name => 'stage1'); END; / 5 打包需要导出的数据 DECLARE my_plans number; BEGIN my_plans := DBMS_SPM.PACK_STGTAB_BASELINE( table_name => 'stage1', enabled => 'yes', creator => 'dba1'); END; / 6 用exp或expdp导出stage表。 7 用imp或impdb导入stage表 8 把导出的SQL Plan Baselines导入字典中 DECLARE my_plans number; BEGIN my_plans := DBMS_SPM.UNPACK_STGTAB_BASELINE( table_name => 'stage1', fixed => 'yes'); END; /

11g新特性:SQL Plan Management(SPM)

在11g，oracle提供dbms_spm包来管理SQL Plan，SPM是一个预防机制，它记录并评估sql的执行计划，将已知的高效的sql执行计划建立为SQL Plan Baselines，SQL Plan Baseline的功能是保持SQL的性能而不必关注系统的改变。 1 Capturing SQL Plan Baselines 在SQL Plan BaseLines捕获阶段，Oracle记录SQL的执行计划并检测该执行计划是否已经改变，如果SQL改变后的执行计划是安全的，则SQL就使用新的执行计划，因此，Oracle维护单个SQL执行计划的历史信息，Oracle维护的SQL执行计划的历史仅仅针对重复执行的SQL，SQL Plan Baseline可以手工load，也可以设置为自动捕获。 A Automatic Plan Capture 如果要激活自动的SQL Plan Capture，则需要设置OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES，该参数默认为False，如果设置为True，则表示海底捞月活自动捕获SQL Plan，则系统会自动创建并维护SQL Plan History，SQL Plan History包括优化器关注的：比如an execution plan, SQL text, outline, bind variables, and compilation environment。 B Manual Plan Loading 也可以手动装载一个存在的SQL Plan作为SQL Plan Baseline，手动装装的SQL Plan并不校验它的性能： --从SQL Tuning Set中装载: DECLARE my_plans pls_integer; BEGIN my_plans := DBMS_SPM.LOAD_PLANS_FROM_SQLSET(sqlset_name => 'tset1'); END; / --从Cursor Cache中装载 DECLARE my_plans pls_integer; BEGIN my_plans := DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE(sql_id => '7qqnad1j615m7'); END; / 2 Selecting SQL Plan Baselines 在SQL Plan选择阶段，SQL每一次编绎，优化器使用基于成本的方式，建立一下best-cost的执行计划，然后去匹配SQL Plan Baselines中的SQL Plan，如果找到了匹配的SQL Plan，则会使用这个执行计划，如果没有找到匹配的SQL Plan,优化器就会去SQL Plan History中去搜索成本最低的SQL Plan，如果优化器在SQL Plan History中找不到任务匹配的SQL Plan，则该SQL Plan被作为一个Non-Accept Plan被存入SQL Plan History，新的SQL Plan直到它被验证不会引起一下性能问题才会被使用。 --如何激活使用SQL Plan Baselins SQL> alter system set OPTIMIZER_USE_SQL_PLAN_BASELINES = true; 3 Evolving SQL Plan Baselines 在SQL Plan Baselines的演变阶段，Oracle评估新的Plan的性能并将性能较好的Plan存放SQL Plan Baselines中，可以使用dbms_spm package的过程EVOLVE_SQL_PLAN_BASELINE将新的SQL Plan存入已经存在的SQL Plan Baselines中，新的Plan将会作为已经Accept Plan加入到SQL Plan Baselines中。 SET SERVEROUTPUT ON SET LONG 10000 DECLARE report clob; BEGIN report := DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(sql_handle => 'SYS_SQL_593bc74fca8e6738'); DBMS_OUTPUT.PUT_LINE(report); END; / 4 相关的数据字典 dba_sqlset_plans dba_advisor_sqlplans dba_sql_plan_baselines 5 用dbms_xplan显示SQL Plan 在11g中，Oracle增强了dbms_xplan包的显示功能，不仅可以显示单个sql的执行计划，还可以用来显示sql tuning set，以及sql plan baselines等，在此就仅仅对显示sql plan baselines做测试： select * from table(dbms_xplan.display_sql_plan_baseline(sql_handle => '&SYS_SQL_', 11g新特性:Pending Statistics 作者 xzh2000 16:30 |  静态链接网址 |  最新回复 (0) |  引用 (0) | 技术交流 从11g开始，表与索引的统计信息收集完毕后，可以选择收集的统信息立即发布，也可以选择使新收集的统计信息处于pending状态，待确定处于pending状态的统计信息是安全的，再使处于pending状态的统计信息发布，这样就会避免一些因为收集统计信息立即发布而导致SQL执行计划走错的灾难。 1 如何判断是否有pending的统计信息需要生效？ SQL> Select dbms_stats.get_prefs('PUBLISH') publish from dual; PUBLISH -------------------------- TRUE dbms_stats的get_prefs函数返回true，表示对象的统计信息收集后立即生效，如果返回flase，收集的统计信息将处于pending状态。 2 如果查看相关的视图 A 立即生效的统计信息可以通过以下字典可以查看 user_tab_stats user_ind_stats B pending状态的统计信息可以通过以下字典可以查看 user_tab_pending_stats user_ind_pending_stats 3 如何设置表或schema的统计信息的publish状态 用dbms_stats的set_table_prefs或者set_schema_prefs过程可以在表级或schema表设置它们的统计信息是否立即生效，当我们设置tmp_test表的统计信息收集后处于pending状态，那该表收集统计信息后，将存放于user_tab_pending_stats字典中。 SQL> Exec dbms_stats.set_table_prefs('yekai','tmp_test','publish','false'); PL/SQL procedure successfully completed. SQL> select count(*) from user_tab_pending_stats; COUNT(*) ---------- 0 SQL> exec dbms_stats.gather_table_stats('yekai','tmp_test'); PL/SQL procedure successfully completed. SQL> select count(*) from user_tab_pending_stats; COUNT(*) ---------- 1 4 如何测试并使用处于pending状态的统计信息 在11g，新的参数optimizer_pending_statistics将可以来解决这个问题，当我们在session级设置optimizer_pending_statistics为true时，我们就可以使用存放在user_*_pending_stats字典中的统计信息啦，当我们确保该处于pending状态的统计信息是正确时，我们就可以决定是否使它们立即生效。 SQL> alter session set optimizer_pending_statistics = TRUE; 5 如何发布处于pending状态的统计信息 当测试过统计信息有效后，我们可以选择发布pending状态的统计信息 SQL> exec dbms_stats.publish_pending_stats('yekai','tmp_test'); 如果我们不需要该处于pending状态的统计信息，可以选择删除这个pending的统计信息 SQL> exec dbms_stats.publish_pending_stats('yekai','tmp_test');   11g新特性:Extended Statistics Collect   在11g中，dbms_stats package提供了组合列的统计信息的收集，如果在where条件中使用了组合列进行查询，则优化器将会得到更准确的统计信息，进而输出执行计划时，可以输出更接近与真实数据的统计结果，11g的Extended Statistics包含了组合列与表达式统计信息的收集，表过式统计信息收集主要是针对函数索引字段，下面就组合列统计信息的收集做一下测试： SQL> create index idx_object_objtype on tmp_objects(object_type,owner) compute statistics; Index created. SQL> select index_name,BLEVEL,LEAF_BLOCKS,DISTINCT_KEYS,CLUSTERING_FACTOR,NUM_ROWS  from user_indexes  where index_name='IDX_OBJECT_OBJTYPE'; INDEX_NAME BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR NUM_ROWS ------------------------------ ----------- ------------- ----------------- ---------- IDX_OBJECT_OBJTYPE 2 11240 203 208057 3189632 SQL>select count(*)  from tmp_objects  where owner='SYSTEM' and object_type='TABLE'; -------------------------------------------------------------------------------------- | Id | Operation |Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 15 | 58 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 15 | | | |* 2 | INDEX RANGE SCAN|IDX_OBJECT_OBJTYPE| 15712 | 230K| 58 (0)| 00:00:01 | -------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("OBJECT_TYPE"='TABLE' AND "OWNER"='SYSTEM') Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 33 consistent gets 0 physical reads 0 redo size SQL> declare v_name varchar2(30); begin v_name := dbms_stats.create_extended_stats('yekai','tmp_objects','(object_type,owner)'); end; SQL> select dbms_stats.show_extended_stats_name('yekai','tmp_objects','(object_type,owner)') as ex_name from dual;  EX_NAME --------------------------------- SYS_STU_UCG1E7VH65UFFJ55F00#FU SQL> select *  from user_stat_extensions  where table_name='TMP_OBJECTS' TABLE_NAME EXTENSION_NAME EXTENSION CREATOR DROPPA ------------ -------------------------------- -------------------------------- ------------ ------ TMP_OBJECTS SYS_STU_UCG1E7VH65UFFJ55F00#FU ("OBJECT_TYPE","OWNER") USER YES SQL> BEGIN dbms_stats.gather_table_stats( ownname => 'yekai', tabname => 'tmp_objects', method_opt => 'for all columns size skewonly for columns (cust_state_province,country_id) skewonly'); END; SQL> select e.extension col_group, t.num_distinct, t.histogram from user_stat_extensions e, user_tab_col_statistics t where e.extension_name = t.column_name and t.table_name = 'TMP_OBJECTS'; COL_GROUP NUM_DISTINCT HISTOGRAM ------------------------- ------------ ------------------ ("OBJECT_TYPE","OWNER") 203 FREQUENCY SQL>select count(*)  from tmp_objects  where owner='SYSTEM' and object_type='TABLE'; -------------------------------------------------------------------------------------- | Id | Operation |Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 15 | 44 (0)| 00:00:01 | | 1 | SORT AGGREGATE | | 1 | 15 | | | |* 2 | INDEX RANGE SCAN|IDX_OBJECT_OBJTYPE| 11673 | 170K| 44 (0)| 00:00:01 | -------------------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 2 - access("OBJECT_TYPE"='TABLE' AND "OWNER"='SYSTEM') Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 33 consistent gets 0 physical reads 0 redo size 说明：请大家对比收集组合列统计信息前后对tmp_objects进行查询的执行计划，你会发现组合列统计信息收集前SQL的Bytes是230k Cost是58，组合列统计信息收集后SQL的Bytes是170k，Cost是44，这就是组合列统计信息的优势。   11g新特性:Auto Optimizer Statistics Collection   在oracle 10g中，优化统计信息的收集是通过scheduler job来自动完成的，dba可以通过dbms_scheduler package的enable procedure与disable procedure来启动与关闭，在oracle 11g中，oracle提供了全新的package dbms_auto_task_admin来完成统计信息的收集工作，测试脚本如下所示： 启动： BEGIN DBMS_AUTO_TASK_ADMIN.ENABLE( client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL); END; / 关闭： BEGIN DBMS_AUTO_TASK_ADMIN.DISABLE( client_name => 'auto optimizer stats collection', operation => NULL, window_name => NULL); END;   11g新特性:常驻连接池DRCP之一   在oracle中，进程的频繁创建是一个比较消耗资源的开消，在11g之前，oracle提供专用器进程与共享服务器进程供用户选择适合自己的进程机制，在11g中，oracle又推出DRCP(database resident connection pool)，类似于sqlrelay那种轻量级中间件的进程机制为客户服务，DRCP适用于web application（比如php/apache），可以提供成千上万的连接，使用DRCP可以共享主机资源。 一 什么时间使用DRCP 1 使用较小内存的、大量的客户端连接 2 客户端应用是相似的，可以共享或重用会话 3 客户端占用数据库连接的周期相当短 4 会话不需要跨客户请求 5 客户端有众多的主机与进程 二 Dedicated Servers,Shared Servers与DRCP的区别 11g新特性:常驻连接池DRCP之二   三Dedicated Servers,Shared Servers与DRCP的内存需求 一般情况下，由于每个会话需要消耗400k的内存，每个进程需要消耗4m的内存，现在我们以DRCP的pool size是100，shared server的shared server进程是100为例，假如有5000个客户端连接到这些环境，则这些主机的内存分配如下： A Dedicated Server  Memory used = 5000 X (400 KB + 4 MB) = 22 GB B Shared Server Memory used = 5000 X 400 KB + 100 X 4 MB = 2.5 GB Out of the 2.5 GB, 2 GB is allocated from the SGA. C Database Resident Connection Pooling Memory used = 100 X (400 KB + 4 MB) + (5000 X 35KB)= 615 MB 四 使用DRCP时，当实例有活动pooled server，有以下限制： 1 不能shutdown database; 2 不能停掉DRCP; 3 不能用database link连接到不同实例的DRCP; 4 不能使用Advanced Security Option (ASO)，比如encryption等 11g新特性:常驻连接池DRCP之三   五 如何在DB中配置DRCP？ 在11g中，系统默认包含了一个连接池：SYS_DEFAULT_CONNECTION_POOL，这个池默认被创建，但默认该池是不启动的，如果要启动默认的连接池，必须显式地执行启动DRCP的命令，oracle提供dbms_connection_pool package来执行这个工作，如果连接池被显式地启动，必须显式地被停掉，当实例宕掉时，如果DRCP是活动的，则实例启动时，DRCP也将自动实动。 启动DRCP需要以下步骤： A 用sysdba权限连接到sqlplus B 执行exec dbms_connection_pool.start_pool(); C 查看DRCP的状态 六 客户端如何连接到DRCP？ 如果是专用服务器连接，则SERVER=DEDICATED，如果是DRCP连接，则SEVER=POOLED。如果在tnsnames.ora中指定了SERVER=POOLED，但并没有在实例中启动DRCP，则当客户请求连接时，DB会报ORA-12520错误。如果要指定客户端请求到DRCP，则客户端的tnsnames.ora中的连接字符串必须指定连接类型是POOLED，配置方式如下所示： dhcp11g = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.5.26)(PORT = 1521)) (CONNECT_DATA = (SERVER = POOLED) (SERVICE_NAME = dbtest) ) ) 说明：11g的客户端才可以使用DRCP，如果10g的客户端在tnsnames.ora中指定了SERVER=POOLED，则连接时报ORA-56606。 六 如何在DB中掉停DRCP A 用sysdba权限连接到sqlplus B 执行exec dbms_connection_pool.stop_pool(); 七 如何调整DRCP的配置？ DRCP启动时使用的是默认配置参数，如果要调整DRCP的配置参数，需要调用dbms_connection_pool包的configure_pool过程去调整DHCP的高级选项，也可以调用dbms_connection_pool包的alter_param过程只仅改指定的参数而不影响其它的参数，DRCP可调整的参数可以查看dba_cpool_info表，每个参数的具体含义请自己查阅administrator guide手册的p128/129页，具体的语法如下所示： SQL> exec print_table('select * from dba_cpool_info'); CONNECTION_POOL : SYS_DEFAULT_CONNECTION_POOL STATUS : ACTIVE MINSIZE : 4 MAXSIZE : 40 INCRSIZE : 2 SESSION_CACHED_CURSORS : 20 INACTIVITY_TIMEOUT : 300 MAX_THINK_TIME : 120 MAX_USE_SESSION : 500000 MAX_LIFETIME_SESSION : 86400 ----------------- SQL> exec dbms_connection_pool.alter_param ('','minsize','10'); PL/SQL procedure successfully completed. SQL> exec print_table('select * from dba_cpool_info'); CONNECTION_POOL : SYS_DEFAULT_CONNECTION_POOL STATUS : ACTIVE MINSIZE : 10 MAXSIZE : 40 INCRSIZE : 2 SESSION_CACHED_CURSORS : 20 INACTIVITY_TIMEOUT : 300 MAX_THINK_TIME : 120 MAX_USE_SESSION : 500000 MAX_LIFETIME_SESSION : 86400 ----------------- PL/SQL procedure successfully completed. 八 如何恢复DHCP的默认选项 A 用sysdba权限连接到sqlplus B 执行exec dbms_connection_pool.restore_defaults; 九 关于DHCP相关的字典 dba_cpool_info v$cpool_stats v$cpool_cc_stats 十 测试DHCP的总结 在实际的使用，如果要使用DHCP，则需要注意在tnsnames.ora中创建两个TNS连接字符串，将前台短的连接都指向DHCP连接，把后台长的连接则向DEDICATED SERVER连接，这样就可以满足一般轻量权的web application. 11g新特性:database replay   在11g中，很多功能oracle都引导用户通过OEM来操作，但喜欢用API的dba，照样可以写脚本来完成自己的工作，下面给大家介绍一下database replay的配置方法，database replay可以捕捉整个数据库的负载，并且传递到需要进行测试数据库上，然后重演负载以测试系统调优后的效果，当然也可以为升级硬件进行压力测试。 A 创建目录 create directory sqlplay as /home/oracle11g/worksh/sqlplay'; B 启动捕获进程 SQL> BEGIN 2 DBMS_WORKLOAD_CAPTURE.START_CAPTURE ( 3 name => 'capture_by_yekai', 4 dir => 'sqlplay', 5 duration => 600); 6 END; 7 / BEGIN * ERROR at line 1: ORA-20222: Invalid DB State or Input. Input "sqlplay" is not a valid DIRECTORY object! ORA-06512: at "SYS.DBMS_WORKLOAD_CAPTURE", line 783 ORA-06512: at line 2 说明：这个地方dir参数必须是大写的，否则将会报错。 SQL> BEGIN 2 DBMS_WORKLOAD_CAPTURE.START_CAPTURE ( 3 name => 'capture_by_yekai', 4 dir => 'SQLPLAY', 5 duration => 600); 6 END; 7 / PL/SQL procedure successfully completed. C 如果在启动捕获进程时，没有指定duration的话，将必须调用finish_capture过程结束捕获workload. BEGIN DBMS_WORKLOAD_CAPTURE.FINISH_CAPTURE(); END; / D 监控database replay的捕获情况 select * from DBA_WORKLOAD_CAPTURES; E 处理捕获信息 SQL> BEGIN 2 DBMS_WORKLOAD_REPLAY.PROCESS_CAPTURE ( 3 capture_dir => 'SQLPLAY'); 4 END; 5 / PL/SQL procedure successfully completed. F 创建replay目录 create or replace directory sqlreplay as '/home/oracle/worksh/sqlplay' 说明：在初始化前，需要把捕获在sqlplay目录内的文件都拷贝到新的sqlreplay目录内 G 初始化replay Sys@ORA11G> BEGIN 2 DBMS_WORKLOAD_REPLAY.INITIALIZE_REPLAY ( 3 replay_name => 'replay_by_yekai', 4 replay_dir => 'SQLREPLAY'); 5 END; 6 / PL/SQL procedure successfully completed. H 进准备重演状态 Sys@ORA11G> BEGIN 2 DBMS_WORKLOAD_REPLAY.PREPARE_REPLAY (synchronization => TRUE); 3 END; 4 / PL/SQL procedure successfully completed. I 启动database replay客户端 $wrc system/oracle mode=replay replaydir=./replay I 执行重演 Sys@ORA11G> BEGIN 2 DBMS_WORKLOAD_REPLAY.START_REPLAY (); 3 END; 4 / PL/SQL procedure successfully completed. J 结束重演 Sys@ORA11G> BEGIN 2 DBMS_WORKLOAD_REPLAY.CANCEL_REPLAY (); 3 END; 4 / D 监控database replay的重演情况 select * from DBA_WORKLOAD_REPLAYS; 11g新特性:全表扫描的变化   在oracle 11g以前的版本中，如果对大表进行全表扫描，通过v$session_wait可以看到wait event是：db file scattered read；在11g中，如果对大表进行全表扫描，通过v$session_wait可以看到wait event是：direct path read；也就是说，在11g中，大表全表扫描是将数据块直接读入会话的pga区域。 10g： [oracle10g@csdba worksh]$ sh list_sql.sh -------------------------------------------------------------------------- YEKAI(159,235) ospid=5318 hash_value=1577916882 execs=918 els_time=1.04 program=sqlplus@csdba (TNS V1-V3) disk_reads=0 buffer_gets=43658.46 SELECT COUNT(*) FROM TMP_OBJECTS WHERE OBJECT_ID = :B1 -------------------------------------------------------------------------- |SELECT STATEMENT |----- 1577916882 ----| | | 8609 | |SORT AGGREGATE | | 1 | 13 | | | TABLE ACCESS FULL |TMP_OBJECTS | 483 | 6K| 8609 | -------------------------------------------------------------------------- ----------------------------alter system kill session----------------------- alter system kill session '159,235'; [oracle10g@csdba worksh]$ sh list_sql.sh -------------------------------------------------------------------------- YEKAI(159,235) ospid=5318 hash_value=1577916882 execs=919 els_time=1.04 program=sqlplus@csdba (TNS V1-V3) disk_reads=0 buffer_gets=43658.52 SELECT COUNT(*) FROM TMP_OBJECTS WHERE OBJECT_ID = :B1 -------------------------------------------------------------------------- |SELECT STATEMENT |----- 1577916882 ----| | | 8609 | |SORT AGGREGATE | | 1 | 13 | | | TABLE ACCESS FULL |TMP_OBJECTS | 483 | 6K| 8609 | -------------------------------------------------------------------------- ----------------------------alter system kill session----------------------- 11g： [oracle11g@csdba worksh]$ sh list_sql.sh -------------------------------------------------------------------------- YEKAI(137,491) ospid=5324 hash_value=1577916882 execs=719 els_time=1.34 program=sqlplus@csdba (TNS V1-V3) disk_reads=43713.11 buffer_gets=68684.45 SELECT COUNT(*) FROM TMP_OBJECTS WHERE OBJECT_ID = :B1 -------------------------------------------------------------------------- |SELECT STATEMENT |----- 1577916882 ----| | | 11936 | |SORT AGGREGATE | | 1 | 13 | | | TABLE ACCESS FULL |TMP_OBJECTS | 482 | 6K| 11936 | -------------------------------------------------------------------------- ----------------------------alter system kill session----------------------- alter system kill session '137,491'; [oracle11g@csdba worksh]$ sh list_sql.sh -------------------------------------------------------------------------- YEKAI(137,491) ospid=5324 hash_value=1577916882 execs=720 els_time=1.34 program=sqlplus@csdba (TNS V1-V3) disk_reads=43713.2 buffer_gets=68684.58 SELECT COUNT(*) FROM TMP_OBJECTS WHERE OBJECT_ID = :B1 -------------------------------------------------------------------------- |SELECT STATEMENT |----- 1577916882 ----| | | 11936 | |SORT AGGREGATE | | 1 | 13 | | | TABLE ACCESS FULL |TMP_OBJECTS | 482 | 6K| 11936 | -------------------------------------------------------------------------- ----------------------------alter system kill session----------------------- 大家看测试，很明显，在11g中，大表全表扫描时数据块不经过sga而直接进pga，就会造成每次进行大表全表扫描，物理读都是很大，而在10g中，由于全表扫描的数据块在sga中已经存在，所以执行全表扫描时，它的物理读为0；这种变迁，体现了oracle在优化策略上的进步，就是假定大表频繁全表扫描这种现象，在产生库上是不常有的，通过把数据直接读入pga，进而减少了cache buffer的繁忙交换程度，提高了cache buffer的使用效率。。。 11g新特性:实时sql监控增强   在11g以前的版本,SQL的运行情况可以通过监控v$session_longops来了解,当某个操作执行时间超过6秒,就会被v$session_longops感知,通常可以监控到比如全表扫描,全索引扫描,哈希联接,并行查询等;在11g中,当sql并行运行时,马上会被real-time monitor到,当sql单进程运行时,如果运行时间超过5秒,它也会被监控到。 可以通过v$sql_monitor与v$sql_plan_monitor视图查看sql执行的统计信息，可以联合v$active_session_history，v$session，v$session_longops，v$sql, v$sql_plan等视图，查看sql更多的信息。v$sql_monitor收集关键的一些指标，比如：elapsed time, CPU time, number of reads and writes, I/O wait time and various other wait times等，这些信息是每秒刷新一次，当sql执行完比，并不会立即把它从v$sql_monitor中删除，至少保留1分钟，real-time sql monitor也包括收集sql执行计划的统计信息，可以通过v$sql_plan_monitor视图来查看被监控sql的执行计划，这些统计数据也是每秒更新一次，当sql执行完结，它们至少被保留1分钟。 如何生成sql监控报表： 方法一： variable my_rept CLOB; BEGIN :my_rept :=DBMS_SQLTUNE.REPORT_SQL_MONITOR(); END; / print :my_rept 方法二： set long 10000000 set longchunksize 10000000 set linesize 200 select dbms_sqltune.report_sql_monitor from dual; 如何激活或禁止real-time sql monitor? real-time sql monitor需要statistics_level参数等于all或typical，且CONTROL_MANAGEMENT_PACK_ACCESS参数必须是DIAGNOSTIC+TUNING（默认就是如此），还有两个语句级的hints可以激活或禁止real-time sql monitor:/*+ monitor */与/*+ no_monitor */，这两个参数也必须在CONTROL_MANAGEMENT_PACK_ACCESS参数是DIAGNOSTIC+TUNING下才生效，案例： 强制sql使用实时监控： select /*+ monitor */ count(*) from test where title = 'abc'; 取消sql使用实时监控： select /*+ no_monitor */ count(*) from test where title = 'abc'; Sys@ORA11G> set long 10000000 Sys@ORA11G> set longchunksize 10000000 Sys@ORA11G> set linesize 200 Sys@ORA11G> select dbms_sqltune.report_sql_monitor from dual; REPORT_SQL_MONITOR -------------------------------------------------------------- SQL Monitoring Report SQL Text -------------------------------------------------------------- SELECT COUNT(*) FROM TEST WHERE OBJECT_ID = :B1 -------------------------------------------------------------- Global Information Status : DONE (ALL ROWS) Instance ID : 1 Session ID : 122 SQL ID : 2ywfyn7r0ywky SQL Execution ID : 16777216 Plan Hash Value : 1950795681 Execution Started : 08/16/2007 15:48:24 First Refresh Time : 08/16/2007 15:48:28 Last Refresh Time : 08/16/2007 15:48:30 -------------------------------------------------------------------- | Elapsed | Cpu | IO | Other | Fetch | Buffer | Reads | | Time(s) | Time(s) | Waits(s) | Waits(s) | Calls | Gets | | -------------------------------------------------------------------- | 4.30 | 1.36 | 0.01 | 2.93 | 1 | 94869 | 94613 | -------------------------------------------------------------------- SQL Plan Monitoring Details ================================================================== | Id | Operation | Name | Rows | Cost | Time | | | | | (Estim) | | Active(s) | ================================================================== | 0 | SELECT STATEMENT | | | 35310 | 1 | | 1 | SORT AGGREGATE | | 1 | | 1 | | 2 | TABLE ACCESS FULL | TEST | 126 | 35310 | 5 | ================================================================== 接上表: =========================================================== Start | Starts | Rows | Activity | Activity Detail |  Active | | (Actual) | (percent) | (sample #) |  =========================================================== +6 | 1 | 1 | | |  +6 | 1 | 1 | | |  +2 | 1 | 0 | 100.00 | Cpu (5) |  =========================================================== 11g在awr report方面，还是增加了一些吸引眼球的地方，比如增加了对OS等主机配置的报告，对于dba来讲，在接手一个新环境时,或做现场服务时，该报表将会简少一些额外的工作，比如报表中已经可以显示主机名，操作系统，CPU个数，物理内存等，最让人关注的还是增加了主机负载的一些情况，具体变化请看下文： 主机方面: Host Name Platform CPUs Cores Sockets Memory(GB) ----------- ------------------ ---- ----- ------- ---------- log51 Linux IA (32-bit) 4 2 2 3.96 LOAD PROFILE: Load Profile Per Second Per Trans Per Exec Per Call ~~~~~~~~~~~~ ----------- ---------- --------- -------- DB Time(s): 1.0 6.5 0.11 0.29 DB CPU(s): 1.0 6.4 0.11 0.29 Redo size: 1,059.2 6,813.2 Logical reads: 73,493.3 472,724.2 Block changes: 5.7 36.5 Physical reads: 73,465.3 472,544.3 Physical writes: 0.6 3.7 User calls: 3.4 22.1 Parses: 2.1 13.3 Hard parses: 0.0 0.0 W/A MB processed: 9,217.0 59,285.9 Logons: 0.0 0.1 Executes: 8.9 57.3 Rollbacks: 0.1 0.4 Transactions: 0.2 说明:在load profile section，增加了DB Time(s)，DB CPU(s)，W/A MB processed，Rollbacks等，当然也去掉了sorts的统计信息，如果想看memery sort与disk sort等情况，需要在Instance Efficiency Percentages部分来观察,Instance Efficiency Percentages section没有原化。 HOST CPU & LOAD AVG: Host CPU (CPUs: 4 Cores: 2 Sockets: 2) ~~~~~~~~ Load Average Begin End %User %System %WIO %Idle --------- --------- --------- --------- --------- --------- 1.01 1.20 14.2 11.6 0.1 74.2 Instance CPU ~~~~~~~~~~~~ % of total CPU for Instance: 25.1 % of busy CPU for Instance: 97.2 %DB time waiting for CPU - Resource Mgr: 0.0 Memory Statistics ~~~~~~~~~~~~~~~~~ Begin End Host Mem (MB): 4,054.0 4,054.0 SGA use (MB): 600.0 600.0 PGA use (MB): 126.6 126.8 % Host Mem used for SGA+PGA: 17.92 17.92 Operating System Statistics - Detail Snaps: 137-138  Snap Time Load %busy %user %sys %idle %iowait  --------------- -------- -------- -------- -------- -------- --------  16-Aug 08:00:35 1.0 N/A N/A N/A N/A N/A  16-Aug 09:00:37 1.2 25.8 14.2 11.6 0.1 74.2  ------------------------------------------------------------- 关于TOP SQL部分,主要按以下方面进行排序: SQL ordered by Elapsed Time SQL ordered by CPU Time SQL ordered by Gets SQL ordered by Reads SQL ordered by Executions SQL ordered by Parse Calls SQL ordered by Sharable Memory SQL ordered by Version Count   11g新特性:增强的add column   在11g以前的版本中,如果表上存在未提交的事务,则对表进行DDL操作将失败,在11g中,这个限制已经被取消啦,执行ADD COLUMN操作时,并不会受未提交事务的影响,另外,ADD COLUMN还有一个增强,就是在一个非常大的表上执行ADD COLUMN xxx DATATYPE DEFAULT yyy NOT NULL时,它不会再去将默认值更新到表中已经存在的记录,这样改进的好处是非常大的,DBA对表结构的变更将更加容易,而且不会产生大量的library cache lock/pin等,更不会阻塞事务,它是怎么做到的呢? 其实现方法很简单,ORACLE引擎仅仅依赖数据字典中记录的字段的默认值来对新增字段中为空的数据进行解释,比如在test表有1000万的记录，执行alter table TEST add test_add_column number default 1 not null操作，它不会将默认值更新到存在的1000万条记录，当我们进行查询select count(*) from test where test_add_column = 1时，ORACLE引擎扫描到test_add_column存在大量为NULL的记录时,它根据数据字典中记录的test_add_column字段的默认值,将NULL解释为1...     11g stream新特性列表   从最初学习9iR2的stream，以及10gR1，10gR2的stream，到现在的11gR1，可以说oracle在stream上面压了很大的成钱，stream也越来越得到用户的接受，在11gR1中，stream比之前的版本也有较大的改进，比如同步捕获，合并的捕获与应用进程等，以下就简单地列下新增的功能点，感兴趣的可以自己看文档。。。 1 同步捕获 2 支持xmltype类型的字段 3 数据加密 4 分割与合并复制目标 5 跟踪LCRs的被处理过程 6 比较并聚合共享数据库对象 7 当stream异常时OEM自动报警 8 stream性能顾问 9 stream job使用oracle scheduler 10 通知服务改善 11 合并捕获与应用进程的优化 12 新的错误消息代码 11g新特性：DDL锁超时   在11g中，oracle提供了一个新的可动态调整的参数ddl_lock_timeout，该参数允许存在未提交的事务的表上，执行DDL操作，如果事务在ddl_lock_timeout允许的时间内提交，则DDL操作将会成功，否则就会报ORA-00054错误，如果对该表执行ADD COLUMN操作，则会直接提交表上发生的未提交的事务，所以用11g时，有些东西还是要注意的，当然也不排除这是11g的一个bug哦。。。 11g以前的版本测试如下： SESSION 1: 16:18:34 SQL> delete from tmp_lg_log where rownum < 2; 1 row deleted. SESSION 2: 16:21:10 SQL> alter table tmp_lg_log add rn number; alter table tmp_lg_log add rn number * ERROR at line 1: ORA-00054: resource busy and acquire with NOWAIT specified 11g中测试DDL锁超时： SESSION 1: SQL> create table tmp_lg_log (id number,name varchar2(32),rn1 number, rn2 number); Table created. SQL> insert into tmp_lg_log values(1,'abc',1,2); 1 row created. SESSION 2: SQL> show parameter lock NAME_COL_PLUS_SHOW_PARAM TYPE VALUE_COL_PLUS_SHOW_PARAM ------------------------- ----------- --------------------- ddl_lock_timeout integer 0 --修改锁超时时间 SQL> alter system set ddl_lock_timeout=60 scope=both; System altered. --执行ddl(drop column)的操作,事务未在60s内提交,所以报timeout错误 SQL> alter table tmp_lg_log drop column rn2; alter table tmp_lg_log drop column rn2 * ERROR at line 1: ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired --执行ddl(add column)的操作,DDL则立即成功 SQL> alter table tmp_lg_log add rn4 number; Table altered. 11g新特性：stream同步捕获   在测试9iR2,10gR1,10gR2的stream时,非常希望能够有种同步capture的机制,该同步capture机制与log-based real-time capture机制是不同的,它应该是一种内部触发的机制,比如当有活动事务时,DB引擎判断该表配置有stream的同步capture标志,就可以直接把dml打包成LCRs并压入队列... 幸运的是,在10gR1中,已经看到了该功能已经被实现,但通过文档可以看到,oracle建议该功能仅适用于需要复制的表比较少的情况下,也可以理解需要复制的表dml不是很频繁,当然如果是全库进行复制,log-based real-time capture可能更高效一些,毕竟扫描一个500m以上的redo log成本也是很高的. 来自：1.http://book.51cto.com/art/201111/301008.htm               2. http://www.ningoo.net/2007/09/01/oracle_11g_new_feature_flashback_data_archive.htm 闪回数据归档 Flashback data archive 在Oracle 11g中，对闪回技术再次进行了扩展，提供了一个全新的flashback方式，称为闪回数据归档，本节我们将对闪回数据库归档进行介绍。 22.8.1  闪回数据归档概念 这里我们从Oracle 9i开始引进的Flashback Query开始介绍，这是Oracle第一次引入闪回技术，该技术使得一些逻辑误操作不再需要利用归档日志和数据库备份进行时间点恢复。 而在Oracle10g中，引入了Flashback Version Query、Flashback Transaction Query、Flashback Database、Flashback Table、Flashback Drop等特性，大大简化了Flashback Query的使用。 在上面的诸多闪回技术中，除了Flashback Database（依赖于闪回日志）外，其他闪回技术都是依赖于撤销数据，都与数据库初始化参数UNDO_RETENTION密切相关（该参数决定了撤销数据在数据库中的保存时间），都是从撤销数据中读取信息来构造旧数据的。但是存在一个限制，就是undo中的信息不能被覆盖。而undo段是循环使用的，只要事务提交，之前的undo信息就可能被覆盖，虽然可以通过undo_retention等参数来延长undo的存活期，但该参数会影响所有的事务，设置过大，可能导致undo tablespace快速膨胀。 Oracle 11g则为Flashback家族又带来一个新的成员：Flashback Data Archive。该技术与上面所说的诸多闪回技术的实现机制不同，通过将变化数据存储到创建的闪回归档区（Flashback Archive）中，以与undo区别开来，这样就可以通过为闪回归档区单独设置存储策略，使得可以闪回到指定时间之前的旧数据而不影响undo策略。并且，可以根据需要指定哪些数据库对象需要保存历史变化数据，而不是将数据库中所有对象的变化数据都保存下来，这样可以极大地减少空间需求。 Flashback Data Archive并不是记录数据库的所有变化，而只是记录了指定表的数据变化。所以，Flashback Data Archive是针对对象的保护，是Flashback Database的有力补充。 通过Flashback Data Archive可以查询指定对象的任何时间点（只要满足保护策略）的数据，而且不需要利用undo，这在有审计需要的环境，或是安全性特别重要的高可用数据库中是一个非常好的特性。缺点是如果该表变化很频繁，那么对空间的要求可能很高。 22.8.2  闪回数据归档区 闪回数据归档区是闪回数据归档的历史数据存储区域，在一个系统中，可以有一个默认的闪回数据归档区，也可以创建其他闪回数据归档区域。 每一个闪回数据归档区都可以有一个唯一的名称，同时，每一个闪回数据归档区都对应了一定的数据保留策略。例如，可以配置归档区FLASHBACK_DATA_ARCHIVE_1中的数据保留期为1年，而归档区FLASHBACK_DATA_ARCHIVE_2的数据保留期为2天或者更短。以后如果将表放到对应的闪回数据归档区，那就按照该归档区的保留策略来保存历史数据。 闪回数据归档区是一个逻辑概念，是从一个或多个表空间中抽出一定的空间，保存表的修改历史，这样就摆脱了对撤销数据的依赖，方便表不必利用undo就可以闪回到归档策略内的任何一个时间点上。 创建闪回数据归档区可以使用CREATE FLASHBACK ARCHIVE …命令完成。 下面我们通过实例演示如何创建闪回数据归档区。 （1）创建一个系统默认的、磁盘限额为100MB、保留策略为1年的闪回数据归档区。 SQL>create flashback archive default fbar_1 tablespace "USERS" 2 quota 100M    2   retention  1  year;   经过在Oracle 11g数据库上运行该语句发现，必须对tablespace关键字后面的表空间名称用" "引起来，否则无法运行成功。 （2）在TBS_DATA1上创建fbar_2闪回数据归档区，保留策略为2天。 SQL>CREATE FLASHBACK ARCHIVE fbar_2 TABLESPACE "TBS_DATA1"    2   RETENTION 2 DAY;   一个归档区可以不仅对应一个表空间，而且可以增加或删除该归档区的表空间的个数，这样也达到了增加或是减少该归档区空间的目的。 （3）给数据归档区fbar_2增加一个表空间。 SQL>ALTER FLASHBACK ARCHIVE fbar_2 ADD TABLESPACE "TBS_DATA2"   2   QUOTA 100M;   也可以从归档区中删除表空间。注意：此删除仅表示从数据归档区删除，并不删除该表空间。 （4）删除数据归档区fbar_2的表空间TBS_DATA2。 SYS>ALTER FLASHBACK ARCHIVE fbar_2 REMOVE TABLESPACE "TBS_DATA2";  对已经分配给闪回数据归档区的表空间，可以修改归档区对应的磁盘限额。 （5）修改归档区的磁盘限额。 SYS>ALTER FLASHBACK ARCHIVE fbar_2 MODIFY TABLESPACE "TBS_DATA2"    2   QUOTA 200M;   （6）修改归档区的保留策略。 SYS>ALTER FLASHBACK ARCHIVE fbar_1 MODIFY RETENTION 1 month; 22.8.3  使用闪回数据归档（1） 闪回数据归档区创建完成后，就可以指定特定的表，使其对应到特定的数据归档区。把表指定到对应的数据归档区有两种方法，一是在创建时直接指定归档区；二是对现有的表指定归档区。 如果不指定归档区的名称，则指定到默认归档区，否则，就属于指定的数据归档区。 下面我们基于上一节所创建的两个闪回数据归档区fbar_1（默认的闪回数据恢复区）和fbar_2，创建3个表，一个指定到默认归档区fbar_1，一个指定到数据归档区fbar_2，另外一个为了作对比，没有指定到任何数据归档区。 （1）创建表。 SYS@11gR1>connect scott/tiger   Connected.   scott@11gR1>create table test1(a int) flashback archive;   Table created.   scott@11gR1>create table test2(b int);   Table created.   scott@11gR1>alter table test2 flashback archive data_test2;   Table altered.   scott@11gR1>create table test3(c int);   Table created.   （2）在表中插入数据后，进行SELECT查询，显示结果如下： 09:33:38 scott@11gR1>select * from test2;            B    ----------             4             5             6                  09:33:43 scott@11gR1>select * from test3;            C   ----------            7            8            9   09:33:46 scott@11gR1>select to_char(sysdate,'yyyy-mm-dd hh24:mi:ss') time from dual;           TIME    ----    2007-09-04 09:33:52   可以看到，这些数据是在9:33写进的，最新数据保留策略应当是，表test1对应的是默认的数据归档区fbar_1，数据保留策略是一个月，表test2对应的是数据归档区fbar_2，数据保留策略是2天，而表test3没有数据保留策略。然后，对这三个表再进行操作，如删除现有记录，并插入一些新记录，最后，我们不使用undo数据，查询时间点2007-09-04 09:33:52，看是否能找回原来的数据。 （3）对表进行更新操作，查询显示结果。 09:34:19 Piner@11gR1>delete from test1;   3 rows deleted.   09:34:23 Piner@11gR1>delete from test2;    3 rows deleted.   09:34:30 Piner@11gR1>delete from test3;   3 rows deleted.   09:34:35 Piner@11gR1>insert into test1 values(10);   1 row created.   09:34:47 Piner@11gR1>insert into test2 values(20);   1 row created.   09:34:53 Piner@11gR1>insert into test3 values(30);   1 row created.   09:34:58 Piner@11gR1>commit;   Commit complete.   09:36:32 Piner@11gR1>select * from test1;            A   ----------           10   09:36:51 Piner@11gR1>select * from test2;            B   ----------           20   09:36:56 Piner@11gR1>select * from test3;            C   ----------           30   （4）利用闪回功能查询数据，可以获得正确数据，但是，无法确认这些数据是经过undo获得的还是经过数据归档区获得的。 09:43:17 Piner@11gR1>select * from test1 as of timestamp   09:43:17   2  to_timestamp('2007-09-04 09:33:52', 'yyyy-mm-dd hh24:mi:ss');            A   ----------            1            2            3    09:43:17 Piner@11gR1>select * from test2 as of timestamp   09:43:24   2  to_timestamp('2007-09-04 09:33:52', 'yyyy-mm-dd hh24:mi:ss');            B   ----------            4            5            6   09:43:25 Piner@11gR1>select * from test3 as of timestamp   09:43:30   2  to_timestamp('2007-09-04 09:33:52', 'yyyy-mm-dd hh24:mi:ss');            C   ----------            7            8            9   22.8.3  使用闪回数据归档（2） （5）为了证明查询使用的是闪回数据归档，创建新的undo表空间，切换undo表空间，为了确保生效，可以重新启动数据库例程。 切换到新的undo表空间，如果没有，则需要新创建。 SYS@11gR1>ALTER SYSTEM SET undo_tablespace=TBS_UNDO2;   System altered.   删除原来的undo表空间。 SYS@11gR1>drop tablespace UNDOTBS1;   Tablespace dropped.   （6）最后，排除undo查询的可能后，再次执行查询。 scott@11gR1> select * from test3 as of timestamp     2  to_timestamp('2007-09-04 09:33:52', 'yyyy-mm-dd hh24:mi:ss');   select * from test3 as of timestamp                 *   ERROR at line 1:   ORA-01555: snapshot too old: rollback segment number  with name "" too small                scott@11gR1> select * from test1 as of timestamp     2  to_timestamp('2007-09-04 09:33:52', 'yyyy-mm-dd hh24:mi:ss');            A   ----------            1            2            3       scott@11gR1> select * from test2 as of timestamp     2  to_timestamp('2007-09-04 09:33:52', 'yyyy-mm-dd hh24:mi:ss');            B   ----------            4            5            6   可以看到，若没有设置数据归档策略的表test3，则查询时会报01555错误，但是，设置过数据归档策略的表test1与表test2，都能正常查询到数据，可以看到，数据归档已生效。 这里是一个简单的实验，时间可能远远没有达到设置的策略期，但是，却可以证明数据不是经过undo查询获得的。 22.8.4  清除闪回数据归档区数据 前面我们介绍过如何给闪回数据归档区增加空间，本节通过一些具体实例为大家介绍如何清除闪回归档区中的数据。 1．清除所有归档区的数据 SQL>ALTER FLASHBACK ARCHIVE data_test1 PURGE ALL;  2．清除一天以前的数据 SQL>ALTER FLASHBACK ARCHIVE data_test1   2   PURGE BEFORE TIMESTAMP (SYSTIMESTAMP - INTERVAL '1' DAY);  3．清除特定SCN之前的数据 SQL>ALTER FLASHBACK ARCHIVE data_test1 PURGE BEFORE SCN 728969;  4．将指定的表不再设置数据归档 SQL>ALTER TABLE test1 NO FLASHBACK ARCHIVE;  5．删除数据归档区 SQL>DROP FLASHBACK ARCHIVE data_test2;  注意 如果将表指定了闪回数据归档区，则不能对表进行如下操作。 删除、重令名，或者修改列； 做分区或者子分区操作； 转换long到LOB类型； ALTER TABLE…UPGRADE TABLE 操作； DROP、RENAME、TRUNCATE表。 示例： scott@11gR1> drop table test1;   drop table test1              *   ERROR at line 1:   ORA-55610: Invalid DDL statement on history-tracked table   22.8.5  与闪回数据归档有关的视图 可以通过以下视图得到与闪回数据归档有关的信息。 DBA_FLASHBACK_ARCHIVE：DBA视图，闪回归档区信息； DBA_FLASHBACK_ARCHIVE_TS：DBA视图，闪回归档有关表空间； DBA_FLASHBACK_ARCHIVE_TABLES：DBA视图，对应表所对应的闪回归档信息； USER_FLASHBACK_ARCHIVE：用户闪回归档区的创建信息； USER_FLASHBACK_ARCHIVE_TABLES：用户表对应的闪回归档区域。 一.后台进程 Oracle11g为Flashback data archive特性专门引入了一个新的后台进程FBDA，用于将追踪表(traced table，也就是将指定使用flashback data archive的table)的历史变化数据转存到闪回归档区。 NING@11g>select name,description from v$bgprocess where name=’FBDA’; NAME DESCRIPTION —————————— —————————————- FBDA Flashback Data Archiver Process 二.一些限制条件 1.Flashback data archive只能在ASSM的tablespace上创建 NING@11g>create flashback archive test_archive2 2 tablespace “TEST” 3 quota 1 m 4 retention 1 day; tablespace “TEST” * ERROR at line 2: ORA-55627: Flashback Archive tablespace must be ASSM tablespace 2.Flashback data archive要求必须使用自动undo管理 NING@11g>show parameter undo_management; NAME TYPE VALUE ———————————— ———- —————————— undo_management string MANUAL NING@11g>create flashback archive test_archive2 2 tablespace “TEST” 3 quota 1 m 4 retention 1 day; create flashback archive test_archive2 * ERROR at line 1: ORA-55628: Flashback Archive supports Oracle 11g or higher NING@11g>show parameter compatible NAME TYPE VALUE ———————————— ———- —————————— compatible string 11.1.0.0.0 三.空间配额 磁盘配额由quota子句指定，只能使用整数，单位可以是M/G/T/P。如果省略quota子句，则默认为unlimited，但这样则要求用户对于该tablespace必须有unlimited的空间配额，并且指定的quota必须小于用户在该tablespace上的配额限制，在我的试验中，只有flasback data archive的配额小于tablespace的配额84M以上才可以创建成功，否则失败，至于为什么会是84M，暂时还不清楚，我的系统是Redhat AS5，有兴趣的朋友请帮忙测试这个问题。昨天昏了头了，应该是该用户在该tablespace中已经占用了80多M的空间，所以会出现这个问题。 一个Flashback data archive可以使用多个tablespace作为存储空间，创建时指定的tablespace为第一个tablespace，后续还可以通过alter flashback archive … add tablespace增加新的tablespace进来，也可以通过later flashback archive … remove tablespace移除某个tablespace（不会物理删除该tablespace）。 SYS@11g>revoke unlimited tablespace from ning; Revoke succeeded. SYS@11g>alter user ning quota 85m on users; User altered. NING@11g>create flashback archive test_archive2 2 tablespace “USERS” 3 retention 1 day; tablespace “USERS” * ERROR at line 2: ORA-55621: User quota on tablespace “USERS” is not enough for Flashback Archive NING@11g>create flashback archive test_archive2 2 tablespace “USERS” 3 quota 2 m 4 retention 1 day; tablespace “USERS” * ERROR at line 2: ORA-55621: User quota on tablespace “USERS” is not enough for Flashback Archive NING@11g>create flashback archive test_archive2 2 tablespace “USERS” 3 quota 1 m 4 retention 1 day; Operation 218 succeeded. 但是空间配额可以超过该tablespace本身的物理大小 SYS@11g>drop tablespace test including contents and datafiles; Tablespace dropped. SYS@11g>create tablespace test 2 datafile ‘/oracle/oradata/ning/test01.dbf’ size 10m; Tablespace created. SYS@11g>alter user ning quota unlimited on test; User altered. NING@11g>create flashback archive test_archive3 2 tablespace “TEST” 3 quota 100 m 4 retention 1 month; Operation 218 succeeded. 四.空间不足会导致追踪表上的DML操作失败 NING@11g>create table test as select * from all_objects where 1=2; Table created. NING@11g>alter table test flashback archive test_archive1; Table altered. NING@11g>insert into test select * from all_objects; 11873 rows created. NING@11g>insert into test select * from test; … NING@11g>/ 379936 rows created. NING@11g>/ insert into test select * from test * ERROR at line 1: ORA-01536: space quota exceeded for tablespace ‘USERS’ 五.清除闪回归档区的数据 1.清除所有数据 NING@11g>alter flashback archive test_archive1 purge all; Operation 219 succeeded. 2.清除某个时间点，比如一天前的数据 NING@11g>alter flashback archive test_archive1 2 purge before timestamp (systimestamp – interval ’1′ day); Operation 219 succeeded. 3.清除某个SCN之前的历史数据 NING@11g>alter flashback archive test_archive1 2 purge before scn 8570685767554; Operation 219 succeeded. 六.置于Flashback data archive中的table的一些限制 追踪表(Tracked table)，也就是指定将历史数据保存到某个flashback data archive中的table，不能执行DDL操作(add column除外)。 NING@11g>drop table test; drop table test * ERROR at line 1: ORA-55610: Invalid DDL statement on history-tracked table NING@11g>truncate table test; truncate table test * ERROR at line 1: ORA-55610: Invalid DDL statement on history-tracked table NING@11g>alter table test drop column object_id; alter table test drop column object_id * ERROR at line 1: ORA-55610: Invalid DDL statement on history-tracked table NING@11g>alter table test add col_test int; Table altered. 但是可以rename table，这一点和文档上说的不一致 NING@11g>rename test to test1; Table renamed. NING@11g>select table_name,flashback_archive_name from dba_flashback_archive_tables; TABLE_NAME FLASHBACK_ARCHIVE_NAME —————————— —————————— TEST1 TEST_ARCHIVE1 RESULT_CACHE_MODE Property Description Parameter type String Syntax RESULT_CACHE_MODE = { MANUAL | FORCE } Default value MANUAL Modifiable ALTER SESSION, ALTER SYSTEM Basic No RESULT_CACHE_MODE specifies when a ResultCache operator is spliced into a query's execution plan. Values: MANUAL The ResultCache operator is added only when the query is annotated (that is, hints). FORCE The ResultCache operator is added to the root of all SELECT statements (provided that it is valid to do so). For the FORCE setting, if the statement contains a NO_RESULT_CACHE hint, then the hint takes precedence over the parameter setting. 默认情况下，数据库会为SGA 中共享池(Share Pool)内的结果高速缓存分配内存。分配给结果高速缓存的内存大小取决于SGA的内存大小以及内存管理系统。可以通过设置RESULT_CACHE_MAX_SIZE参数来更改分配给结果高速缓存的内存。 如果要使用查询结果高速缓存并将RESULT_CACHE_MODE初始化参数设置为MANUAL，则必须在查询中显式指定RESULT_CACHE 提示。这会在查询的执行计划中引入ResultCache运算符。执行查询时，ResultCache 运算符将查找结果高速缓存，以检查该查询结果是否存在于高速缓存中。如果存在，则直接从高速缓存检索该结果。如果高速缓存中不存在该查询结果，则执行查询。结果将以输出形式返回，也存储在结果高速缓存中。   如果将RESULT_CACHE_MODE 初始化参数设置为AUTO 或FORCE，并且不希望将查询结果存储在结果高速缓存中，则必须在查询中使用NO_RESULT_CACHE 提示。例如，如果在初始化参数文件中RESULT_CACHE_MODE的值为FORCE，并且不希望对EMPLOYEES表使用结果高速缓存，则需要使用NO_RESULT_CACHE 提示。