启用ODM极速调优IO

在平时的工作中，数据库所处的文件系统是vxfs的话，可以考虑启用veritas的odm特性。
ODM(Oracle Disk 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个多小时，真是极大的提高。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1252507/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/23718752/viewspace-1252507/