在平时的工作中，数据库所处的文件系统是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个多小时，真是极大的提高。
