另辟蹊径解决数据库运维技术难题VIP

1、另辟蹊径解决数据库运维技术难题技术创新，变革未来数据库服务是做什么的？数据库服务驻场工程师故障处理数据库服务驻场工程师重症监护室的故事一个医院，在重症监护室， 死亡率从某个时候起突然 高起来，而经过医生的分 析，每天早上8点的死亡 率，比其他时间段高很多案例1：系统突然卡顿客户系统某天告警，15:10-15:25 系统卡顿RAC环境的GC等待GC等待，本质上就是节点间的交互gc buffer busy *gc current block *gc cr *- 并发访问- 获取当前块- 获取一致性块gc current与gc cr语句都是最简单的insert相关：insert into xxx v

2、alues(,)current请求就是访问数据块本身, 发生于DMLcr请求就是根据不同情况访问数据块本身或者前镜像(undo),主要发生于select解决GC等待的常见方法最常见：应用分区，避免访问同样数据其次：优化内联网- 万兆网卡- IB网卡其他：bug进程繁忙采取第一步措施客户已经做了严格的应用分区其中一个节点（节点2）完全不跑应用内联网为万兆RAC相关进程CPU正常采取第一步措施检查x$bh/v$bh, 发现部分块在节点2也存在，怀疑是统 计信息收集select count(*),ownerfrom x$bh h ,dba_objects o where o.data_object_

3、id = h.obj措施：强制统计信息收集在节点1上运行强行flush 节点2的buffer cachealter system flush buffer cache;问题未能解决第二天接近的时间点，问题再次发生第三天接近的时间点，问题再再次发生罪魁祸首一个医院，在重症监护室，死亡 率从某个时候起突然高起来，而 经过医生的分析，每天早上8点的 死亡率，比其他时间段高很多罪魁祸首一个医院，在重症监护室，死亡 率从某个时候起突然高起来，而 经过医生的分析，每天早上8点的 死亡率，比其他时间段高很多原来，每天8点清洁阿姨拔掉呼吸机的电源，开始 打扫卫生是否存在同样的规律？由于主机间的块传输由lms进

4、程负责，检查故障期间的Lms进程日志，发现如下日 志：2020-09-26 15:31:30.766 = Two consecutive receive calls took in 5945 ms = 2020-09-26 15:31:30.767 = Two consecutive receive calls took in 7274 ms = 2020-09-26 15:31:30.807 = Two consecutive receive calls took in 8494 ms = 2020-09-26 15:31:30.835 = Two consecutive receive c

5、alls took in 6355 ms =是否存在同样的规律？awk /Two consecutive receive calls took/ t=substr($2,1,5);wait=$(NF-2)/1000;if( wait=3;cnt3t+); if( wait=2;cnt2t+); if( wait=1;cnt1t+); ENDfor (i in cnt1)print i,cnt1i,cnt2i,cnt3i *lms*.trc是否存在同样的规律？每六小时出 现一次哪个阿姨每六个小时打扫一次卫生？与客户配合，发动所有力量主机工程师网络工程师监控负责人存储工程师应用开发人员排除了在操作

6、系统、网络、监控中6个小时为周期的工作。而数据库和应 用本身也不存在6个小时为周期的任务。CRS？回到crs,检查集 群日志oswps.datOracle自治数据库寻根问底What is OraJavaAgentDriver?搜索Oracle官网，发现OraJavaAgentDriver对应的是Oracle的cvu组件，全称是Cluster Verification Utility,是Oracle CRS健康检查的一个工具，在CRS作为资源存在，名字是ora.cvu。ora.cvu是6个小时打扫一次卫生的阿姨吗?crsctl stat res ora.cvu -p21600=3600*6解决问

7、题由于Oracle CVU主要是初始安装时用来检查系统状况是否符合安装标准，如果后续整个集群没有硬件和操作系统变更，理论上来说，不会有变化，因此，该组件可以禁用。禁用方法如下： crsctl stop ora.cvu crsctl disable ora.cvu数据库问题不仅仅是数据库本身头痛医头？脑部问题？ 运动过量？心脏供血不足？ 氧气含量低?吸入有毒气体？ 发烧？。案例：数据库hung节点2在10月1日12点36分时候突然抛出无法在操作系统上创建生成任 务进程的异常：Thu Oct 01 12:35:30 GMT+08:00 2020ARC1: Standby redo logfile

8、selected for thread 2 sequence 109637 for destination LOG_ARCHIVE_DEST_2Thu Oct 01 12:36:24 GMT+08:00 2020kkjcre1p: unable to spawn jobq slave process Thu Oct 01 12:36:24 GMT+08:00 2020Errors in file /oracle/admin/epmdb/bdump/epmdb2_cjq0_5243470.trc:Thu Oct 01 12:41:29 GMT+08:00 2020ksvcreate: Proce

9、ss(m000) creation failedThu Oct 01 12:46:35 GMT+08:00 2020kkjcre1p: unable to spawn jobq slave process Thu Oct 01 12:46:35 GMT+08:00 2020Errors in file /oracle/admin/epmdb/bdump/epmdb2_cjq0_5243470.trc:主机资源占用正常CPU占用正常 内存用量正常procstack和ps elf hung* SESSION ID:(3904.1) 2020-10-01 12:32:20.508Waited for

10、 process J003 to initialize for 60 seconds* 2020-10-01 12:32:20.514swap info: free_mem = 136988.31M rsv = 612.00M alloc = 651.48M avail = 156672.00M swap_free = 156020.52Mskgpgcmdout: read() for cmd /bin/sh -c /usr/bin/procstack 13697324 2&1 timed out after 18.798 secondsskgpgcmdout: read() for cmd /bin/ps -elf | /bin/egrep PID | 18022634 | /bin/grep -v grep timed out after 15.000 seconds主机工程师介入，发现是操作系统