啟用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
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個多小時，真是極大的提高。