Oracle10gR2 Logical Standby(七)日常管理与优化
有一段时间没怎么写技术性的文章了，继续前面的逻辑备库系列，这是第七篇。
对于逻辑备库来说，日常管理主要需要关注SQL Apply。切换是很少发生的动作，而logminer的速度相对于sql apply来说是很快的，恢复的进度主要还是取决于SQL Apply的进度。
一、SQL Apply进程
SQL Apply实际上是一组后台并行进程，包括reader,preparer,builder,analyzer,coordinator,applier 六种不同作用的进程：
- reader：读取redo记录传递给preparer进程
- preparer: 根据redo记录和数据字典信息生成LCR
- builder: 将同一个事务的LCR打包。对于大事务(eager transaction)，可能被打成多个事务包(transaction chunk)，那么可能有些包里是不包含commit的，每一个事务包都可能交给不同的applier进程。
- analyzer:分析事务包之间的依赖关系
- coordinator:将分析好的事务包交给applier进程
- applier:将事务包应用，如果事务包依赖其他事务包，则需要等待相应的事务包完成。事务能否commit，可能还需要根据不同的情况从coordinator获得相应的信息。
Oracle如何设置备用归档路径
Oracle可以设置备用归档路径，如果首要归档路径不可用，可以自动切换到备用路径，而平时备用路径不启用，这在一些对高可用要求比较高的环境中还是有实用价值，无法正确归档将会导致数据库挂起。启用该特性需要配置的参数如下：
log_archive_dest_1='location=/arc/archive/test alternate=log_archive_dest_2 noreopen' log_archive_dest_2='location=/arc1/archive/test' log_archive_dest_state_1=enable log_archive_dest_state_2=alternate
log_archive_dest_1需要设置noeopen或者reopen=0属性，否则无法迅速切换到备用路径，可能导致数据库无法归档。
此时归档路径状态如下：
SQL> select dest_name,destination,status,error from v$archive_dest; DEST_NAME DESTINATION STATUS ERROR -------------------- ------------------ ---------- --------------------- LOG_ARCHIVE_DEST_1 /arc/archive/test VALID LOG_ARCHIVE_DEST_2 /arc1/archive/test ALTERNATE LOG_ARCHIVE_DEST_3 standby VALID LOG_ARCHIVE_DEST_4 INACTIVE LOG_ARCHIVE_DEST_5 INACTIVE LOG_ARCHIVE_DEST_6 INACTIVE LOG_ARCHIVE_DEST_7 INACTIVE LOG_ARCHIVE_DEST_8 INACTIVE LOG_ARCHIVE_DEST_9 INACTIVE LOG_ARCHIVE_DEST_10 INACTIVE
你的数据库使用了哪些特性?
Oracle10g中增加了一张叫做DBA_FEATURE_USAGE_STATISTICS的视图，只要你使用过的一些特性都会记录下来，而且这些信息可能在一些trace文件比如RDA收集的结果中存在，没买license而使用了这些特性的要注意了。不过透过这个视图，也能了解到系统的很多情况，或许很多东西都是作为DBA的你都不曾注意到的吧，呵呵
SQL> select name,detected_usages as "usage",currently_used,first_usage_date,last_usage_date 2 from dba_feature_usage_statistics; NAME usage CURRE FIRST_USAGE_ LAST_USAGE_D -------------------------------------------------- ---------- ----- ------------ ------------ Protection Mode - Maximum Availability 0 FALSE Protection Mode - Maximum Performance 36 TRUE 04-FEB-08 06-OCT-08 Protection Mode - Maximum Protection 0 FALSE Protection Mode - Unprotected 0 FALSE Real Application Clusters (RAC) 0 FALSE Recovery Area 0 FALSE Recovery Manager (RMAN) 32 TRUE 03-MAR-08 06-OCT-08 RMAN - Disk Backup 32 TRUE 03-MAR-08 06-OCT-08 RMAN - Tape Backup 0 FALSE Resource Manager 0 FALSE Segment Advisor 34 TRUE 18-FEB-08 06-OCT-08 Server Parameter File 36 TRUE 04-FEB-08 06-OCT-08 Undo Advisor 0 FALSE Virtual Private Database (VPD) 0 FALSE Shared Server 0 FALSE Spatial 0 FALSE SQL Access Advisor 0 FALSE SQL Tuning Advisor 0 FALSE SQL Tuning Set 0 FALSE Standby Archival - LGWR 23 TRUE 17-MAR-08 06-OCT-08 Standby Archival - ARCH 9 FALSE 03-MAR-08 12-MAY-08 Standby Transmission 32 TRUE 03-MAR-08 06-OCT-08 Streams (system) 36 TRUE 04-FEB-08 06-OCT-08 Streams (user) 0 FALSE Transparent Gateway 0 FALSE Advanced Replication 0 FALSE Advanced Security 0 FALSE Audit Options 0 FALSE Automatic Database Diagnostic Monitor 0 FALSE Automatic Segment Space Management (system) 36 TRUE 04-FEB-08 06-OCT-08 Automatic Segment Space Management (user) 36 TRUE 04-FEB-08 06-OCT-08 Automatic SQL Execution Memory 36 TRUE 04-FEB-08 06-OCT-08 Automatic Storage Manager 0 FALSE Automatic Undo Management 36 TRUE 04-FEB-08 06-OCT-08 Automatic Workload Repository 0 FALSE Change-Aware Incremental Backup 0 FALSE Client Identifier 0 FALSE CSSCAN 0 FALSE Character Semantics 0 FALSE Character Set 36 TRUE 04-FEB-08 06-OCT-08 Data Guard 32 TRUE 03-MAR-08 06-OCT-08 Data Guard Broker 0 FALSE Data Mining 0 FALSE Dynamic SGA 0 FALSE File Mapping 0 FALSE Flashback Database 0 FALSE Internode Parallel Execution 0 FALSE Label Security 0 FALSE Locally Managed Tablespaces (system) 36 TRUE 04-FEB-08 06-OCT-08 Locally Managed Tablespaces (user) 36 TRUE 04-FEB-08 06-OCT-08 Messaging Gateway 0 FALSE MTTR Advisor 21 FALSE 04-FEB-08 23-JUN-08 Multiple Block Sizes 0 FALSE OLAP - Analytic Workspaces 0 FALSE OLAP - Cubes 0 FALSE Oracle Managed Files 0 FALSE Parallel SQL DDL Execution 2 FALSE 17-MAR-08 24-MAR-08 Parallel SQL DML Execution 0 FALSE Parallel SQL Query Execution 26 TRUE 14-APR-08 06-OCT-08 Partitioning (system) 36 TRUE 04-FEB-08 06-OCT-08 Partitioning (user) 32 TRUE 03-MAR-08 06-OCT-08 PL/SQL Native Compilation 0 FALSE SQL> select * from v$version; BANNER ---------------------------------------------------------------- Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi PL/SQL Release 10.2.0.3.0 - Production CORE 10.2.0.3.0 Production TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Productio NLSRTL Version 10.2.0.3.0 - Production
rebuild index online的锁机制浅析(续)
上一篇文章介绍了Oracle10.2.0.4中rebuild index online的锁机制，在开始和结束的时候需要对表加一个模式为4的TM锁，导致在这两个时刻会短暂的阻塞DML。到了Oracle11g，这种情况有所变化，还是通过同样的实验来观察一下Oracle11g到底做出了怎样的改进，对于DBA来说又有怎样的好处。实验环境为Oracle11.1.0.6。
session 1：
SQL> delete from t where object_id=28; 1 row deleted.
session 2：
SQL> alter index ix_t rebuild online;
session 2同样被挂起，查看v$lock：
SQL> select sid,type,id1,id2,lmode,request from v$lock where type in('DL','TM','TX');
SID TY ID1 ID2 LMODE REQUEST
---------- -- ---------- ---------- ---------- ----------
137 DL 13596 0 3 0
137 DL 13596 0 3 0
137 TX 458781 377 0 4
170 TM 13596 0 3 0
137 TM 13596 0 2 0
137 TM 13599 0 4 0
170 TX 458781 377 6 0
137 TX 524304 402 6 0
其中170为session 1，137为session 2。可以看到session 2正在请求一个模式为4的TX锁，注意和Oracle10.2.0.4请求的TM锁是不一样的，而且在我们以前的概念中，TX锁的模式都是6，这里出现了模式4的TX锁请求，应该是Oracle11g中新引入的。那么模式4的TX锁和TM锁有什么不同呢？我们继续前面的实验步骤：
session 3：
SQL> delete from t where object_id=46; 1 row deleted.
session 3的DML操作顺利完成，没有被阻塞。而在10g当中，session 3是会被session 2请求的TM锁所阻塞的，这一点改进是非常有意思的，这样即使rebuid online操作被session 1的长事务阻塞，其他会话的DML操作，只要不和session 1冲突，都可以继续操作，在Oracle10g及以前版本中的执行rebuild index online而造成锁等待的风险被大大的降低了。
接下来在session 1执行rollback，观察rebuild index online执行期间的锁的情况，136是session 3：
SID TY ID1 ID2 LMODE REQUEST
---------- -- ---------- ---------- ---------- ----------
137 DL 13596 0 3 0
137 DL 13596 0 3 0
137 TM 13596 0 2 0
137 TM 13599 0 4 0
136 TM 13596 0 3 0
136 TX 327684 414 6 0
137 TX 524304 402 6 0
137 TX 524321 402 6 0
等待一段时间，rebuild index online临近结束，再次观察锁的情况：
SID TY ID1 ID2 LMODE REQUEST
---------- -- ---------- ---------- ---------- ----------
137 DL 13596 0 3 0
137 DL 13596 0 3 0
137 TX 327684 414 0 4
137 TM 13596 0 2 0
137 TM 13599 0 4 0
136 TM 13596 0 3 0
136 TX 327684 414 6 0
137 TX 524304 402 6 0
可以看到session 2又在请求一个模式为4的TX锁，同样的，这个锁也不会阻塞其他的DML。由于session 3的事务没有提交，session 2被阻塞，这时再将session 3执行提交或者rollback，则session 2的rebuild立即完成。
Oracle11g在很多细节方面确实做了不少的优化，而且像这样的优化，对于提高系统的高可用性的好处是不言而喻的，在Oracle11g中，执行rebuild index online的风险将比10g以及更老版本中小得多，因为从头至尾都不再阻塞DML操作了，终于可以算得上名副其实的online操作了。
