启用ODM极速调优IO (r2笔记66天）

在平时的工作中，数据库所处的文件系统是vxfs的话，可以考虑启用veritas的odm特性。
ODM(Oracle Dsk Manager)是在oracle 9i之后开放出来管理数据文件，可以提高oracle数据库的输入输出数据吞吐量。
Veritas提供了ODM的扩展，可以在VxFS文件系统的基础上，为oracle提供更高的读写速率和更简便的管理，其在VxFS文件系统上的读写速率和裸设备属于同一量级。

裸设备的速度和性能是相当的好，但是有一些限制，如果在vxfs的基础上使用veritas的odm扩展，速度会有特别好的提高，当然了这部分组件功能是需要licence的。
首先可以查看你工作的数据库环境是否基于vxfs文件系统。
使用如下命令查看的结果类似下面的格式。

>df -F vxfs
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/vx/dsk/vgarcsPT901/lvol2
                      10485760     21087   9810635   1% /dbarcsPT1/oracle/PETARC1
/dev/vx/dsk/vgarcsPT901/lvol1
                      41943040  26734808  14257868  66% /opt/app/oracle/dbarcspt1
/dev/vx/dsk/vgarcsPT901/lvol9

在ORACLE_HOME/lib下可以查看是否odm已经启用。

-rw-r--r-- 1 xxxxx  dba 60487 Sep  4  2010 libnfsodm11.so
-rw-r--r-- 1 xxxxx dba  7426 Sep  4  2010 libodm11.a
lrwxrwxrwx 1 xxxxx dba    57 Aug 16 16:31 libodm11.so -> /opt/app/oracle/dbccbspr1/product/11.2.0/lib/libodmd11.so
-rw-r--r-- 1 xxxxx cbs1 dba 12315 Sep  4  2010 libodmd11.so
-rw-r--r-- 1 xxxxx dba 12315 Aug 16 16:21 libodmd11.so.bak

还可以通过查看alert日志看odm是否被启用,以下是生产中的数据库日志
  db_name                  = "xxxxx"
  open_cursors             = 3000
  _optimizer_cost_based_transformation= "OFF"
  _optimizer_skip_scan_enabled= FALSE
  parallel_adaptive_multi_user= FALSE
  optimizer_index_cost_adj = 10
  optimizer_index_caching  = 90
  pga_aggregate_target     = 6G
  optimizer_dynamic_sampling= 0
  _optimizer_sortmerge_join_enabled= FALSE
  deferred_segment_creation= FALSE
  _optimizer_use_feedback  = FALSE
  aq_tm_processes          = 0
Deprecated system parameters with specified values:
  background_dump_dest
  user_dump_dest
End of deprecated system parameter listing
Oracle instance running with ODM: Veritas 6.0.100.000 ODM Library, Version 2.0
Sat Aug 16 00:05:06 2014
PMON started with pid=2, OS id=6089
Sat Aug 16 00:05:06 2014
PSP0 started with pid=3, OS id=6104
Sat Aug 16 00:05:07 2014
VKTM started with pid=4, OS id=6303 at elevated priority
VKTM running at (1)millisec precision with DBRM quantum (100)ms
Sat Aug 16 00:05:07 2014
GEN0 started with pid=5, OS id=6311
Sat Aug 16 00:05:07 2014
DIAG started with pid=6, OS id=6314
Sat Aug 16 00:05:07 2014
DBRM started with pid=7, OS id=6317
Sat Aug 16 00:05:07 2014
DIA0 started with pid=8, OS id=6319
Sat Aug 16 00:05:07 2014
MMAN started with pid=9, OS id=6322
Sat Aug 16 00:05:07 2014
DBW0 started with pid=10, OS id=6324



当然了在系统层面，quick IO和ODM的使用是有冲突的，两者只能取其一。
而且如果要启用quick IO，需要重新格式化，这个操作风险还是不小。
如果系统在vxfs文件系统,file_system_option为setall也是不会起作用的，
而异步io在10g,11g中已经默认开启。
关于ODM的性能，最近几天饱受困扰，因为生产数据迁移对于速度要求是极为高的。尤其是大批量的数据情况下。
以下是一个最近几天做的测试结果，数据都是真实的生产数据。

redo的日志文件时1G大小。我们在15号的下午开始做了一轮测试，但是结果很不理想，几百G的数据迁移持续了将近5个小时，性能在最开始的一个小时redo的切换达到了153次，最开始速度极快和undo的资源也有一定关系，但是在记下来的几个小时里，性能极剧下降。最后的几个小时，几乎就是在干等着了。 从系统层面的监控结果看到，在接下来的几个小时，cpu使用率极低，iowait又很高，导致速度急剧下降，但是到底wait在那个方面，一直也找不到根本的原因。 而在第二天的凌晨，大家情绪都很低落，但是升级的时间将近，在公司资深专家的建议下，说启用odm,然后系统级的direct选项。 开启odm可以参考如下的步骤。 Use libODM Symbolically link $ORACLE_HOME/lib/libodm11.so (for Oracle 11 or libodm10.so for Oracle 10) to /opt/VRTSodm/lib/libodm.so e.g. ln -s /opt/VRTSodm/lib64/libodm.so $ORACLE_HOME/lib/libodm11.so to back out ln –s $ORACLE_HOME/lib/libodm11.so $ORACLE_HOME/lib/libodm11.so 移除系统级的direct mount point Remove following option from FS mount point and /etc/fstab mincache=direct convosync=direct 在凌晨又开始了新的一轮测试，结果就有了根本的变化。 将近2倍的数据量，在短短的几个小时内，redo的切换是达到了极致。这个也是衡量并发处理情况的一个指标。

  GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1      24161          2       1024 YES INACTIVE
         2          1      24162          2       1024 YES INACTIVE
         3          1      24163          2       1024 NO  CURRENT
         4          1      24160          2       1024 YES INACTIVE
Redo Switch times per hour                                              PRODB                                                     2014-Aug-16 16:39:27
MON DA   00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08  14    2    1    0    8    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    1    0    0
08  15    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0   62  153  102   47   78   64   37    3
08  16   17  238  192  254   31    0    0    0    0    0    0    0    0    0    0    0    2    0    0    0    0    0    0    0

一个小时的redo切换达到了200多次，然后看着cpu的使用率高高在上，数据的导入速度也是很稳定的在推进。 让人有一种满足感。 在未启用odm的时候，系统的io wait一直比较高，最后一直稳定在20~30%左右。 cpu的使用率也搞不到哪里去，最高在50%~70%徘徊。可以看到启用的并行进程的使用率一直上不去，cpu的消耗主要都在vxfs_thread这个进程上。

top - 16:51:15 up 1 day, 20:10, 20 users, load average: 55.82, 53.21, 31.14 Tasks: 954 total, 2 running, 951 sleeping, 0 stopped, 1 zombie Cpu(s): 11.4%us, 3.6%sy, 0.0%ni, 76.2%id, 8.4%wa, 0.1%hi, 0.3%si, 0.0%st Mem: 189675188k total, 154634164k used, 35041024k free, 421080k buffers Swap: 377487328k total, 10308k used, 377477020k free, 86277304k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 29690 root 11 -5 0 0 0 S 55.2 0.0 235:54.99 [vxfs_thread] 25696 oraccbs1 16 0 18.3g 139m 48m R 36.2 0.1 0:06.07 oracleCUST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 9934 oraccbs1 16 0 18.3g 133m 29m S 29.4 0.1 1:47.47 ora_p042_CUST01 10457 oraccbs1 16 0 18.3g 98m 21m S 29.0 0.1 1:38.65 ora_p074_CUST01 30094 oraccbs1 16 0 18.4g 170m 39m S 29.0 0.1 0:13.25 oracleCUST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 2124 oraccbs1 16 0 18.4g 170m 61m S 25.8 0.1 0:04.06 oracleCUST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 10000 oraccbs1 16 0 18.2g 37m 24m S 17.0 0.0 0:35.22 ora_p061_CUST01 32398 root RT 0 160m 14m 2868 S 17.0 0.0 45:00.37 /sbin/multipathd 9991 oraccbs1 15 0 18.2g 37m 23m S 16.0 0.0 0:36.44 ora_p057_CUST01 9989 oraccbs1 15 0 18.2g 37m 25m S 14.7 0.0 0:36.08 ora_p056_CUST01 9998 oraccbs1 16 0 18.2g 37m 25m S 14.7 0.0 0:34.74 ora_p060_CUST01 10003 oraccbs1 16 0 18.2g 45m 31m S 14.4 0.0 0:35.28 ora_p062_CUST01 10006 oraccbs1 16 0 18.2g 37m 24m S 14.0 0.0 0:35.10 ora_p063_CUST01 9996 oraccbs1 15 0 18.2g 37m 24m S 13.7 0.0 0:34.14 ora_p059_CUST01 启用之后，新的进程vxodm_ioreap出现了,cpu使用率急剧提升。iowait也很低，都在5%以内。

top - 18:53:58 up 1 day, 22:13, 17 users, load average: 21.50, 20.59, 16.43 Tasks: 917 total, 13 running, 901 sleeping, 2 stopped, 1 zombie Cpu(s): 20.7%us, 5.3%sy, 0.0%ni, 69.9%id, 2.0%wa, 0.3%hi, 1.7%si, 0.0%st Mem: 189675188k total, 88444120k used, 101231068k free, 376216k buffers Swap: 377487328k total, 10308k used, 377477020k free, 21088928k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 27208 oraccbs1 18 0 18.3g 133m 37m R 94.7 0.1 6:17.55 ora_p030_CUST01 30988 oraccbs1 19 0 18.3g 117m 30m R 93.1 0.1 3:58.75 ora_p066_CUST01 18180 oraccbs1 17 0 18.4g 218m 55m R 63.5 0.1 0:04.55 oracleCUST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 26586 oraccbs1 17 0 18.3g 63m 22m S 37.2 0.0 1:12.62 ora_arc0_CUST01 26362 oraccbs1 16 0 18.2g 36m 19m D 31.6 0.0 7:28.76 ora_dbw0_CUST01 26368 oraccbs1 16 0 18.2g 32m 16m D 31.2 0.0 6:55.70 ora_dbw3_CUST01 18471 oraccbs1 16 0 18.2g 37m 22m R 29.9 0.0 1:05.07 ora_p000_CUST01 26364 oraccbs1 16 0 18.2g 32m 14m D 28.6 0.0 7:00.60 ora_dbw1_CUST01 26366 oraccbs1 16 0 18.2g 36m 17m D 28.0 0.0 7:07.51 ora_dbw2_CUST01 18475 oraccbs1 16 0 18.2g 37m 22m R 27.0 0.0 1:06.83 ora_p002_CUST01 18477 oraccbs1 16 0 18.2g 37m 22m R 27.0 0.0 1:07.41 ora_p003_CUST01 30804 oraccbs1 16 0 18.3g 53m 30m D 26.6 0.0 0:43.14 ora_p059_CUST01 30798 oraccbs1 16 0 18.2g 45m 23m R 26.3 0.0 3:47.97 ora_p056_CUST01 30806 oraccbs1 16 0 18.3g 53m 24m R 26.0 0.0 2:59.42 ora_p060_CUST01 30800 oraccbs1 16 0 18.3g 53m 31m R 25.6 0.0 2:54.35 ora_p057_CUST01 30808 oraccbs1 16 0 18.2g 45m 23m R 25.6 0.0 2:51.63 ora_p061_CUST01 30810 oraccbs1 16 0 18.2g 45m 23m D 25.3 0.0 2:49.49 ora_p062_CUST01 30812 oraccbs1 16 0 18.3g 53m 31m D 25.0 0.0 2:47.45 ora_p063_CUST01 18473 oraccbs1 16 0 18.2g 37m 22m R 24.3 0.0 1:05.34 ora_p001_CUST01 18481 oraccbs1 15 0 18.2g 30m 23m S 22.0 0.0 2:20.29 ora_p005_CUST01 18479 oraccbs1 15 0 18.2g 30m 23m S 21.4 0.0 2:19.19 ora_p004_CUST01 18483 oraccbs1 15 0 18.2g 30m 23m S 21.4 0.0 2:18.60 ora_p006_CUST01 。。。。。

9856 root 15 0 0 0 0 D 12.2 0.0 14:00.77 [vxodm_ioreap] 隔了积分钟抓了一个新的top情况。iowait都控制在1%以内。

top - 18:54:26 up 1 day, 22:14, 17 users, load average: 21.12, 20.60, 16.54 Tasks: 915 total, 16 running, 896 sleeping, 2 stopped, 1 zombie Cpu(s): 25.1%us, 4.1%sy, 0.0%ni, 69.0%id, 0.3%wa, 0.2%hi, 1.3%si, 0.0%st Mem: 189675188k total, 88196360k used, 101478828k free, 376344k buffers Swap: 377487328k total, 10308k used, 377477020k free, 21089340k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 31008 oraccbs1 19 0 18.3g 85m 27m R 98.5 0.0 4:33.78 ora_p076_CUST01 29302 oraccbs1 21 0 18.3g 149m 35m R 92.0 0.1 7:36.09 ora_p042_CUST01 27208 oraccbs1 18 0 18.3g 117m 36m R 91.0 0.1 6:37.53 ora_p030_CUST01 31010 oraccbs1 15 0 18.3g 69m 22m S 71.5 0.0 3:47.42 ora_p077_CUST01 18180 oraccbs1 18 0 18.4g 219m 56m R 44.2 0.1 0:14.83 oracleCUST01 (DESCRIPTION=(LOCAL=YES)(ADDRESS=(PROTOCOL=beq))) 18501 oraccbs1 18 0 18.3g 103m 28m D 37.9 0.1 4:08.29 ora_p015_CUST01 30802 oraccbs1 18 0 18.5g 277m 34m D 37.9 0.1 5:47.46 ora_p058_CUST01 31042 oraccbs1 15 0 18.3g 53m 27m S 37.2 0.0 2:26.21 ora_p079_CUST01 18495 oraccbs1 18 0 18.3g 102m 27m R 36.3 0.1 4:13.83 ora_p012_CUST01 18477 oraccbs1 15 0 18.2g 28m 24m S 35.9 0.0 1:14.42 ora_p003_CUST01 18497 oraccbs1 18 0 18.3g 102m 24m D 35.6 0.1 4:13.73 ora_p013_CUST01 31012 oraccbs1 15 0 18.3g 53m 27m S 35.3 0.0 4:03.96 ora_p078_CUST01

最后数据的加载速度在2个小时内轻松完成。相比之前的5个多小时，真是极大的提高。