备库报警邮件的分析案例(三)(r7笔记第16天)

继前两篇分析了一个看似非常普通的报警邮件,结果在分析问题的时候八面玲珑,相关因素都给分析了一下,没想到还真是有不小的收获。 前两篇地址:

备库报警邮件的分析案例(二) (r7笔记第15天)备库报警邮件的分析案例(一) (r7笔记第14天) 最后通过手工定位监控的方式终于把罪魁祸首揪了出来,为什么在备库使用ash无果,因为还是10g的库,还没有这个特性,在11g中才可以。这个也算是在10g中的一个监控盲点吧。 最后得到的语句是下面这样的形式每天凌晨都会在备库查询一次,资源消耗极大,目前临时表空间为98G都不能满足需求。

select c.cn as cn, c.uin as uin from (select cn from test_cn_bind where enabled='Y' group by cn having count(cn)>1) t, test_cn_bind c where t.cn = c.cn and c.enabled='Y' order by cn 所以这个问题和开发同事沟通了一下,才得知了缘由。原来test_cn_bind这个表有一个字段cn,目前是nonunique的,业务上需要为 unique的,但是在线修改目前还是没有机会的,如果真是出现了这种情况,会在业务上有一些问题,但是几率很低,所以开发部门最后建议在备库上执行这么 一个查询。 这么来看,原来在设计阶段这个问题就没有考虑完善,后续就会有各种的补救措施。 既然业务上确实需要,但是目前的改进空间还比较大,比如走个并行,比如更快的存储介质上。 因为这是个一主两备的环境,第二个备库是最近申请的,里面有SSD,所以在满足同样需求的情况下,可以考虑把语句挪到SSD所在的备库上来。 那么先来看看在SSD上执行的效果。结果运行竟然还报错了。 SQL> select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1); select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1) * ERROR at line 1: ORA-01157: cannot identify/lock data file 1003 - see DBWR trace file ORA-01110: data file 1003: '/U01/app/oracle/oradata/testmdb/temp03.dbf' Elapsed: 00:00:07.81 根据提示说在/U01下没有这个临时数据文件。在文件系统中查看,确实是不存在,但是在这个备库有路径映射,是/U01 映射 /U03,临时数据文件在/U03下面。临时数据文件确实在/U03下面。 使用dg broker把备库置为online,然后开始尝试offline drop. SQL> alter database datafile '/U01/app/oracle/oradata/testmdb/temp01.dbf' offline drop; alter database datafile '/U01/app/oracle/oradata/testmdb/temp01.dbf' offline drop * ERROR at line 1: ORA-01516: nonexistent log file, datafile, or tempfile "/U01/app/oracle/oradata/testmdb/temp01.dbf" 看来只能做rename了。 SQL> recover managed standby database cancel; Media recovery complete. SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp01.dbf' to '/U03/app/oracle/oradata/testmdb/temp01.dbf'; alter database rename file '/U01/app/oracle/oradata/testmdb/temp01.dbf' to '/U03/app/oracle/oradata/testmdb/temp01.dbf' * ERROR at line 1: ORA-01511: error in renaming log/data files ORA-01275: Operation RENAME is not allowed if standby file management is automatic. 修改失败,发现备库文件管理有auto的影响,限制为manual修改。 SQL> show parameter standby NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ standby_file_management string AUTO SQL> alter system set standby_file_management=manual; System altered. 再次修改就没有问题了,三个临时数据文件都修改一下。 SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp01.dbf' to '/U03/app/oracle/oradata/testmdb/temp01.dbf'; Database altered. SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp02.dbf' to '/U03/app/oracle/oradata/testmdb/temp02.dbf'; Database altered. SQL> alter database rename file '/U01/app/oracle/oradata/testmdb/temp03.dbf' to '/U03/app/oracle/oradata/testmdb/temp03.dbf'; Database altered. 修改完成之后再置为auto SQL> alter system set standby_file_management=auto; System altered. 当然这种变化,备库中肯定会有影响。 DGMGRL> show configuration; Configuration Name: testmdb Enabled: YES Protection Mode: MaxPerformance Fast-Start Failover: DISABLED Databases: testmdb - Primary database stestmdb2 - Physical standby database stestmdb - Physical standby database Current status for "testmdb": Warning: ORA-16607: one or more databases have failed $ dgmgrl / Connected. DGMGRL> show database verbose stestmdb2; Database Name: stestmdb2 Role: PHYSICAL STANDBY Enabled: YES Intended State: ONLINE Instance(s): testmdb Properties: InitialConnectIdentifier = 'stestmdb2' ObserverConnectIdentifier = '' LogXptMode = 'ARCH' Dependency = '' DelayMins = '0' Binding = 'OPTIONAL' MaxFailure = '0' MaxConnections = '1' ReopenSecs = '300' NetTimeout = '180' LogShipping = 'ON' PreferredApplyInstance = '' ApplyInstanceTimeout = '0' ApplyParallel = 'AUTO' StandbyFileManagement = 'AUTO' ArchiveLagTarget = '0' LogArchiveMaxProcesses = '2' LogArchiveMinSucceedDest = '1' DbFileNameConvert = '/U01/app/oracle/oradata/testmdb, /U03/app/oracle/oradata/testmdb' LogFileNameConvert = '/U01/app/oracle/oradata/testmdb, /U02/app/oracle/oradata/testmdb' FastStartFailoverTarget = '' StatusReport = '(monitor)' InconsistentProperties = '(monitor)' InconsistentLogXptProps = '(monitor)' SendQEntries = '(monitor)' LogXptStatus = '(monitor)' RecvQEntries = '(monitor)' HostName = 'acc223.cyou.com' SidName = 'testmdb' LocalListenerAddress = '(ADDRESS=(PROTOCOL=TCP)(HOST=10.127.65.223)(PORT=1521))' StandbyArchiveLocation = '/U01/app/oracle/admin/testmdb/arch' AlternateLocation = '' LogArchiveTrace = '0' LogArchiveFormat = '%t_%s_%r.dbf' LatestLog = '(monitor)' TopWaitEvents = '(monitor)' Current status for "stestmdb2": Error: ORA-16766: Redo Apply unexpectedly offline 需要手动开启日志应用。 DGMGRL> edit database stestmdb2 set state='READ-ONLY'; Succeeded. 然后再次尝试就可以了,通过下面的top信息可以看到在执行并行的大查询过程中,io wait是相对很低的。 top - 19:29:59 up 310 days, 8:48, 2 users, load average: 1.04, 0.53, 0.20 Tasks: 488 total, 2 running, 486 sleeping, 0 stopped, 0 zombie Cpu(s): 1.6%us, 0.4%sy, 0.0%ni, 96.7%id, 1.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 132050764k total, 131731368k used, 319396k free, 789588k buffers Swap: 16771776k total, 399208k used, 16372568k free, 125815688k cached 使用MegaCli来查看一下SSD的配置信息 /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aAll -NoLog |less Raw Size: 745.211 GB [0x5d26ceb0 Sectors] Non Coerced Size: 744.711 GB [0x5d16ceb0 Sectors] Coerced Size: 744.625 GB [0x5d140000 Sectors] Sector Size: 0 Firmware state: Online, Spun Up Device Firmware Level: 0270 Shield Counter: 0 Successful diagnostics completion on : N/A SAS Address(0): 0x4433221102000000 Connected Port Number: 2(path0) Inquiry Data: BTTV428102EV800JGN INTEL SSDSC2BA800G3 5DV10270 FDE Capable: Not Capable FDE Enable: Disable Secured: Unsecured Locked: Unlocked Needs EKM Attention: No Foreign State: None Device Speed: 6.0Gb/s Link Speed: 6.0Gb/s Media Type: Solid State Device Drive: Not Certified Drive Temperature :26C (78.80 F) PI Eligibility: No Drive is formatted for PI information: No PI: No PI Drive's NCQ setting : N/A Port-0 : Port status: Active Port's Linkspeed: 6.0Gb/s Drive has flagged a S.M.A.R.T alert : No 这样问题就基本能够定位了,在备库2中运行,发现效率确实好了很多。所以就给开发同学提出了四点建议。

#1建议语句修改为

select c.cn as cn,c.uin from cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1;

#帮忙查看一下调用逻辑是否有问题

同时之前的查询会有多个会话(差不多8个这样的会话)进行同样的查询,请帮忙看一下是否存在调用问题,

数据库用户 TEST_SHINK 客户端用户为:webadmin

#在备库2(5.23)中进行同类查询。

因为存在两个备库,在备库2(5.23 使用SSD)上对比发现,同样的语句在备库2上效果要好很多,可以使用备库2来做此类查询

数据库IP 为10.127.5.23:1523 数据库为:testmdb 需要开通防火墙权限,请备注。

#降低查询频率

查看数据查询的情况,时间可以从37分钟改进到近12分钟左右,可以看到目前为止不存在这类问题(查询结果为0),是否可以考虑把执行频率也降低,比如一周一次。

--SSD的备库

SQL> select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1);

COUNT(*)

----------

0

Elapsed: 00:12:11.73

--普通盘的备库

SQL> select count(*) from (select c.cn as cn,c.uin from test_cn_bind c where enabled='Y' group by c.cn,c.uin having count(c.cn) >1);

COUNT(*)

----------

0

Elapsed: 00:37:08.85

所以这么一个案例从头到尾详细分析了一遍,感觉还是牵扯到方方面面。对于抖动的情况,在业务需求之外的,还是需要引起重视。我喜欢跟开发的同事说,报错不是关键,没有报错不一定没问题。

原文发布于微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文发表时间:2015-11-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏数据和云

Oracle 12.2新特性掌上手册 - 第七卷 Big Data and Data Warehousing

编辑手记:也许Oracle 12.2在内核上的智能改进只能让你眼前一亮,那今天基于Big Data和数据仓库的性能优化增强则会让你伸手触Oracle的强大灵魂。...

3027
来自专栏草根专栏

Entity Framework Core 2.1,添加种子数据

EFCore 2.1出来有一段时间了,里面的新功能还没怎么用,今天研究下如何使用EF Core 2.1添加种子数据。

1481
来自专栏杨建荣的学习笔记

DBA和开发同事的一些代沟(三)(r7笔记第29天)

之前写了两篇关于DBA和开发同事的一些代沟,产生了一些共鸣,本身写这个的目的就是能够让DBA也试着从开发的角度来理解问题,开发同学也能够多学习一些DB的知识,D...

3025
来自专栏更流畅、简洁的软件开发方式

利用虚拟硬盘(把内存当作硬盘)来提高数据库的效率(目前只针对SQL Server 2000)可以提高很多

      虚拟硬盘:就是把内存当作硬盘来用,比如有2G的内存,那么可以拿出来1G的内存当作硬盘来用。       自从知道了“虚拟硬盘”这个东东,我就一直在想...

4815
来自专栏hadoop学习笔记

全文检索Solr集成HanLP中文分词

以前发布过HanLP的Lucene插件,后来很多人跟我说其实Solr更流行(反正我是觉得既然Solr是Lucene的子项目,那么稍微改改配置就能支持Solr),...

1753
来自专栏杨建荣的学习笔记

关于dblink锁定带来的问题(r3笔记第20天)

可能在一些分布式环境中,有一些数据访问都需要用到db link。从某种程度上来说dblink是很方便,但是从性能上来说还是有一些的隐患。如果两个环境之间的网络情...

2975
来自专栏杨建荣的学习笔记

通过shell绑定系统进程调优 (r4笔记第34天)

数据库的性能调优,需要基于操作系统的性能指标,如果操作系统级发生了一些状况,那么会潜移默化的影响到数据库层面。而数据库中对应的进程和操作系统级也有一定的映射关系...

3155
来自专栏更流畅、简洁的软件开发方式

细分主键

  主键本身是很简单的,但是围绕他产生的故事就不是那么简单了。 1、 管理 这个是最重要的,没有规矩不成方圆,主键要如何管理一定要实现确定好了,甚至有必要为此写...

2026
来自专栏好好学java的技术栈

java实现沙箱测试环境支付宝支付和整合微信支付和支付宝支付到ssm(附源码)

下载地址:https://docs.open.alipay.com/270/106291/

5097
来自专栏杨建荣的学习笔记

当12C PDB遇上JDBC (r10笔记第59天)

最近整合了几个测试环境,都放入了12c的容器数据库中。今天本来计划再整合几个测试库进来,结果因为碰到了JDBC的问题给耽搁了。 迁移数据库的步骤...

2909

扫码关注云+社区

领取腾讯云代金券