首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >启用ODM极速调优IO (r2笔记66天)

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

作者头像
jeanron100
发布2018-03-14 16:09:48
7490
发布2018-03-14 16:09:48
举报
在平时的工作中,数据库所处的文件系统是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个多小时,真是极大的提高。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2014-08-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 杨建荣的学习笔记 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档