Category Archives: Oracle

数据库有故障怎么了?

数据库故障是不可避免的,任何软件,无论是开源类还是商业类,只要是人创造的,就一定会存在产品缺陷(bug),软件越复杂,承载任务越繁多,触发bug的概率就越大,这是IT人的基本常识。 快速定位能力的关键性 真正重要的是,在出现故障时,如何迅速而有效地应对故障,定位故障根因并给出有效的解决方案,这才是确保业务连续性和稳定性的关键。也是决定一款数据库是否成熟的一项关键指标。 可是,也不知道当下风气是怎么了,好多人吧,不踏下心来好好研究自家产品,反而喜好打听别家谁出了啥故障,打听到后就跟中了彩票一样兴奋,之后就开始大作文章,跟客户直接说这产品不行。不晓得这些人是纯粹的天真,不知道这个道理,还只是为了各自利益,揣着明白装糊涂呢? 聊到数据库的故障,这里先抛开其他除数据库本身之外进而引发数据库故障的复杂情况不说,也暂不去讨论因用户操作使用不当这类导致的故障,就只是单纯的聊下所谓很严重的产品本身bug导致的故障。 为了客观,避免有些人又喜欢去对号入座,我们就以业界公认领先的,各方面指标均很优秀的商业数据库产品Oracle来举例,因为它本身承载着当今世界众多重要客户的核心系统,这些人总不能去喷Oracle这款数据库产品也不行吧。 Oracle产品本身bug多么? Oracle产品本身bug多么? 其实真的很多。 但凡你有在生产环境部署过Oracle数据库,应用过PSU/RU补丁集,就会发现光是建议应用的这些补丁集列表中的bug就非常多,opatch lsinventory 列出的bug号码都能铺满好几页屏幕。 可是,因这些产品bug导致的故障多么? 如果单拎出来某一个客户来讲,其实是不多的,甚至还存在许多自使用以来从未遇到任何软件bug导致故障的幸运客户,尤其一些IT建设比较薄弱的客户,虽然购买了Oracle,但也没打啥补丁,甚至一直连MOS都没登录过,压根儿就没遇到任何产品bug引发的问题。 但是每个bug其实都直接或间接的对应了某个场景下的故障,那这么多隐秘的bug在测试时都没发现,最终又都是咋发现的呢? 反而是因为Oracle太流行,用户太多太广了,开头也提到了,bug这东西本身触发概率并不高,再举个量化的例子,比如说某个bug只有万分之一的概率被用户触发,也就是说1万个用户里面估计也只有一个人能有幸遇到,于是他遇到过提交给官方,出补丁,其他客户定期更新补丁集,就不会再遇到这个bug。 另外,如此庞大复杂的软件其实bug有很多的,但因为你这个场景遇到了A bug,我这个场景遇到了B bug,他那个场景遇到了C bug… 不断完善,你要是想成为全球第一个遇到某个bug的用户,其实都不太容易呢,所以产品稳定性得到了保障。 如果你的IT管理很有章程,按照官方的建议,定期更新推荐的补丁集,实际上就很难遇到bug带来的影响;即使有的客户因各种原因没有及时应用推荐的补丁集,某一天好巧不巧的触发了某个bug,基本MOS一查现象,也大概率会是已知bug,别人早就遇到了,补丁都是现成的,你只需要及时应用这个补丁即可解决。 小概率事件就可以忽略吗? 既然这样,那用户真的就可以无为而治,万无一失了吗? 也不是,小概率事件不等价于不可能发生事件,为了万无一失,还是要确保你所使用的版本在支持周期之内。这也是为什么有的用户讲我不用你新版本的new feature,为啥也要跟着升级版本的原因之一。 很多人会抱着侥幸心理觉得无所谓,自己不会那么倒霉,但一旦真的不幸遇到就会痛苦不堪。 这里再举个实际的例子吧,比如最近就遇到了一个case,简单说的确是因为产品本身bug导致的故障,现象是ADG的Redo Apply缓慢,这个bug其实也非常隐蔽,因为正常平时延迟都是0,根本发现不了,可运气不好的是,恰好在某个重要保障节点,因为OOM类的原因导致ADG同步被意外终止,且也没有被及时监控到,等用户感知到时,已经有了数小时的延迟,正常情况下,这问题也不大,重新启动同步进程Redo Apply也是很快会追平,可此时不幸的发现追日志的效率异常缓慢,基本相当于延迟多久就追了多久,虽然MOS能查到这个问题,也是一个已知的bug,但更不幸的是,目前在MOS上针对这个bug只有Linux平台的现成补丁,而客户的系统是AIX,并没有找到对应补丁,同时与后台SR进一步确认,确认是真没有,且研发也不会再出这个补丁了。 为什么呢? 因为这是一个老的数据库版本,已经不在支持周期内,研发不会为此提供新的补丁。 好在这个bug不算硬伤,追上这次意外的gap之后就可以保持同步,可风险其实依然存在,在升级之前,我们也只能加强监控,避免类似问题发生影响,并强烈建议尽快把版本升级提上日程。 可能有人会讲,一个已知bug,别的平台都出了补丁,为啥就不能也给出个其它平台的补丁呢?要知道打个one-off的patch是很轻松的事情,但大版本升级可是一个大动作,还要协调应用测试配合,干嘛搞这么复杂呢? 其实这样的策略才是真正的对客户负责,也是很合理的,首先Oracle一直都建议用户要使用当前有效期内的LTS长期支持的版本,这样才能集中更多人来更好的保证你的稳定性,Oracle的LTS其实已经是支持周期非常久的了。 而且,不升级的话,就算研发帮你修复了这个bug,但是后续的风险其实会更大,这种已不在支持周期内的版本,万一下次遇到的bug是非常严重的呢? 数据库有故障怎么了? 最后,回到正题,数据库有故障怎么了? 还是那句话,数据库是一个软件,而且是一款非常复杂的软件,遇到故障是再正常不过的,如何迅速而有效地应对故障,定位故障根因并给出有效的解决方案,这才是确保业务连续性和稳定性的关键。 如果说谁家的数据库产品至今为止,都没有任何产品bug导致的故障案例,那并不代表这个数据库产品有多稳定,反而大概率是这个产品的用户量不够,没有积累到足够量的用户去踩到坑而已。 … Continue reading

Posted in Oracle故障处理 | Comments Off on 数据库有故障怎么了?

同样的SQL,怎么突然就慢了?

本篇文章素材来源于某银行系统的一次性能问题分析。 许久没写这种troubleshooting类型的技术文章了,因为曾在服务公司呆过多年,工作原因,这方面之前做的多,听的更多,导致已经达到在自己认知维度下的一个小瓶颈,纯技术型的问题,稍微常见的基本都遇到过,非常少见的也基本是bug类(软件缺陷只能通过补丁或一些workaround的方式绕过去),感觉实在是没啥可写的。 另外注意,我这里说的“常见”指的是所有客户群中相对常见,而对单个具体客户而言,就非常可能从没有见过,这也是纯甲方技术人员(这里的纯甲方是指毕业就在一个甲方呆着,只能看到自己公司系统运行情况)的局限性,在早些年时,一些行业前辈们还会建议新的技术从业者即使想去甲方,也要先在乙方吃几年苦,能多见一些场景,再去甲方,这样会有比较准确的判断力,不至于轻易被乙方忽悠,也不会瞎挑毛病挑不到点子上让人鄙视。 前些日子有客户遇到问题,申请出差过去现场帮客户分析解决了,这个分析过程还是有些意思的,但最终结论简单来说就是DPR(直接路径读)问题,定位那一刻就觉得没啥可写的了,相关文章也太多了,今天突然想换个思路,看能否以故事线的方式来呈现这个问题,并解释所有技术细节,试图能够让所有人(包括技术小白)都能看得懂,所有用户相关信息均已做遮蔽处理。 首先你要忘掉这是个DPR的问题,让我们一起体会下这个分析问题的历程。 起初是被同事叫来帮忙一起分析客户问题,搞了一个微信群,客户先发了一些所谓异常时间的AWR、ASH、ADDM报告。 说明环境是普通X86服务器上的一套Oracle RAC数据库,版本是11.2.0.4,有应用补丁,触发BUG风险相对较低。嗯,还是要强调下,这里说的低只是说主观感觉上,因为11g已经摸爬滚打了那么多年,无数客户曾趟出的bug也都做了修复,遇到新bug的概率相对小而已,但并不是遇不到,一旦运气不好遇到就麻烦了,所以我们现在会强烈建议你升级到现有的LTS(长期支持版本)19c,可不要再用11g了。 这里提到非常有用的报告: AWR(Automatic Workload Repository) ASH(Active Session History) ADDM(Automatic Database Diagnostic Monitor) 其中ADDM相对用的少,它可以自动分析 AWR 中的性能数据,识别潜在的性能问题,并生成相应的建议报告。对于复杂问题可能不够准确,但至少也能给我们提供一个思路。 AWR可以记录某个时段下的真实负载情况,ASH可以在某个时段下看到是哪些会话在运行,非常好用,对等待事件的细致划分程度,也是其他数据库梦寐以求的东西。 和应用配合明确这个业务感知慢的SQL是否是AWR中显示的Top SQL,同时明确对应的具体sql_id,开始深入分析。 起初明确的sql_id,有一个对应的是一个存储过程,但此时没有进一步去查。 因为另外一个sql_id被认为更值得关注,这是一条简单的SQL,查询一个分区表,谓词条件只有一个定位到某一天的日期,该表是按月分区的。该SQL奇怪是正常的时候1分钟以内完成,异常的时候要接近10分钟完成,前者客户认为正常可接受,后者认为无法接受。 同样的SQL,查询不同日期,效率差距如此明显,另外客户反馈每天数据量基本相当,并没有数量级的差异。 此时最先想要排查的是是否有不同的执行计划? 可结果并不是,执行计划虽然是全表扫,但是前后并没有任何变化。 当时给的AWR中,我也看了IO部分,但只有3.3G的量级,感觉影响并不大,就忽略掉了。 后来去现场,实际动手分析发现,其实故障时刻远没有之前的AWR报告那样轻描淡写,重新收集后续故障时刻的AWR(1小时间隔)可以看到此时的DPR非常显著,达到了314G+,要是之前做紧急救援服务,看到这就已经结束了,直接凭借经验断定,DPR禁用掉再看效果。因为再慢的话,会影响其他客户问题的处理进度。 其实那种凭借历史经验直接判断问题虽然有很快很厉害的感觉,但却是不严谨的,现在我们要进一步确认细节,确认是否是这个问题。既然是DPR,再看TOP SQL中通过Reads的排序,发现Top 2都值得关注,因为物理读几千万,和后面SQL存在数量级上的差异: Top 1是一个存储过程,Top 2是一个SQL,经确认这个SQL也是存储过程之内的一条SQL,但是并不是之前我们分析的那条SQL,说明之前提供的方向有一定错误。这也说明这个Top 2才是问题根本。 同时配合ASH也可以看到的确就是这SQL引发的DPR,导致性能严重下降。 … Continue reading

Posted in Oracle性能优化, Oracle故障处理 | Tagged | Comments Off on 同样的SQL,怎么突然就慢了?

如何快速获取AWR中涉及到的表

最近遇到一个很少见的需求,是关于应用测试方面的。 具体来说,这个应用的测试需求要基于一个固定的时间点数据,而且只能测试一轮,再测试就需要还原到测试前状态。 因为我们使用的存储是分层的(热数据在Flash上,冷数据在传统机械盘),但因为每次测试都需要将数据库闪回还原到固定时间点,效果不佳,所以需要尽可能的预热测试涉及的对象。 方法也很简单,尽可能将所有使用到的相关对象提前全扫下,将其预热。 而相关对象,最佳方式是应用直接提供,这样最准确;但是各种原因,应用无法提供,那么DB层面观察,从测试期间的AWR获取,可以有不同维度: 1.精确找到所有I/O慢的TOP SQL,收集相关表进行预热 2.尽可能找更多AWR中的SQL,收集相关表进行预热 如果是第一种方式,需要人工去定位,SQL数量会很少的几条。 如果是第二种方式,会列出大量SQL,但工作量很大。 那有什么简单的方式吗? AWR本质就是文本内容,我们可以依据通常出现在表名前的关键字来定位。同样是有多种维度,比如SELECT语句表名前会有FROM关键字。 通过Shell列出: grep -o -i ‘\bFROM\s\+\(\w\+\)’ awr.html | sort -u 上面会把所有from关键字及之后的名字列出,然后再人为过滤下不是表的行,好为预热脚本做准备。 这个命令将使用 grep 工具, -o 表示只输出匹配的部分 -i 表示不区分大小写 \b 表示单词边界 FROM 表示匹配 FROM 关键字 \s+ 表示一个或多个空白字符 (\w+) 表示一个或多个字母数字字符(表名或视图名) sort … Continue reading

Posted in Oracle性能优化 | Tagged | Comments Off on 如何快速获取AWR中涉及到的表

如何计算DG环境下Redo传输所需的带宽?

MOS有篇文章:
How To Calculate The Required Network Bandwidth Transfer Of Redo In Data Guard Environments (Doc ID 736755.1)
还提供了一个参考公式 Continue reading

Posted in Oracle最佳实践 | Tagged | Comments Off on 如何计算DG环境下Redo传输所需的带宽?

部署19c ADG过程中的问题处理

回忆起来也是有些年没亲自动手搭建ADG了,今天正好有个机会重温,客户环境是19.16,恍惚记得上一次搭ADG还是在11.2.0.4的时代,时光荏苒啊。正好看下19c的ADG和11g的ADG在部署方面有啥不同? Continue reading

Posted in Oracle安装部署 | Tagged | Comments Off on 部署19c ADG过程中的问题处理

Oracle多租户架构之如何快速创建一个PDB

Oracle自从12c版本开始引入多租户的架构,整个管理理念也发生了很大的变化。
比如之前再小的业务只要选择了Oracle,DBA都会选择新建一套独立的数据库,因为传统的架构只能在schema级别作区分,而schema级别有很多问题,隔离不彻底,且最常见的就是出现同名的情况,而如今有了多租户架构之后,一切都已经变得简单起来.. Continue reading

Posted in Oracle体系原理 | Tagged , | Comments Off on Oracle多租户架构之如何快速创建一个PDB

关于Oracle多租户架构下的每个PDB的dbtime查询

有客户咨询在19c多租户这样的架构中,除了查询cdb本身外,还想查询具体pdb的负载(DB Time),但是使用之前的脚本发现查询不到,只显示cdb自己的结果.. Continue reading

Posted in Oracle体系原理 | Tagged , , , , | Comments Off on 关于Oracle多租户架构下的每个PDB的dbtime查询

小知识:安装系统后唯独搜不到自己的Wi-Fi

遇到的问题,笔记本在安装Win10系统后在可用Wi-Fi热点中唯独搜不到自己的Wi-Fi… Continue reading

Posted in Oracle | Comments Off on 小知识:安装系统后唯独搜不到自己的Wi-Fi

关于SUPPLEMENTAL_LOG_DATA_MIN的设置问题

Oracle数据库开启附加日志,用于Logminer或基于Logminer的一些操作。
客户咨询关于开启附加日志,SUPPLEMENTAL_LOG_DATA_MIN显示为啥是implicit,如何改成yes呢? Continue reading

Posted in Oracle日常运维 | Tagged | 1 Comment

12c/19c新特性官方文档快速参考

工作中会经常遇到被询问Oracle某一个新特性,是在哪个版本开始引入,通常都去查官方文档New Features部分章节,下面列出从12.1.0.1 到 19c的对应在线官方文档的链接,方便快速检索 Continue reading

Posted in New Features | Tagged , | Comments Off on 12c/19c新特性官方文档快速参考