Author Archives: Alfred Zhao
数据库有故障怎么了？
数据库故障是不可避免的，任何软件，无论是开源类还是商业类，只要是人创造的，就一定会存在产品缺陷（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 数据库有故障怎么了？
您好，2024！
首先，2023是非常充实的一年，虽然很难，但增强了抗压能力，心态也变乐观了。 2024主要计划是延续2023的大方向继续努力前行。 工作&学习篇： 1.博客园继续保持更新；（已成为习惯） 2.从用户视角重新认识全栈技术，重点项目用心做；（需要主动性） 3.重点产品XD深入学；（软硬件等） 4.典型国产DB代表多了解；（OB架构设计、版本迭代） 5.PPT功底继续提升；（软技能） 6.英语能力全面提升；（软技能） 生活篇： 7.锻炼身体逐步达成目标；（游泳健身） 8.自驾游探亲；（计划今年暑假时期） 9.出国旅游；（非今年） 工作&学习篇： 1.博客园继续保持更新；（已成为习惯） 2023依然坚持，且开始同步微信公众号，文章开始注重故事性叙述，降低阅读门槛，增强趣味性。 2024会继续保持。 2.从用户视角重新认识全栈技术，重点项目用心做；（需要主动性） 2023有重点项目在进行中； 2024会继续支持有价值的项目，实现双赢。 3.重点产品XD深入学；（软硬件等） 最新的X10M软硬件情况有过了解，后续关注更广的维度，将XD作为DBA了解硬件和扩展知识体系的方式。 2024会继续深入，包括但不限于独特特性，相关专利，关于白皮书中可量化的性能指标等。 4.典型国产DB代表多了解；（OB架构设计、版本迭代） 2023因为精力分配问题，了解不够多，只是粗浅的案例层面； 2024会加强这方面的学习，可以参考OBCP的课件做整体了解，并关注最新版本发展情况。 5.PPT功底继续提升；（软技能） 目前满足工作需求； 2024如果有时间会精进，但不作为重点关注点。 6.英语能力全面提升；（软技能） 目前提升ing，没有量化的指标，不给具体的压力。 口语带孩子互动练； idea：模拟情景剧，比如新概念题材，和孩子一起学习。 英语精读，贯穿全文，找到整个文章各个段落之间的关系； 之前极客时间有课程材料，可作为素材。 英语写作，结合精读的方法，加强写作训练。 先从工作邮件加强，再逐步扩展到其他方面。 生活篇： 7.锻炼身体逐步达成目标；（学习游泳） 2023已自学游泳； … Continue reading
同样的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
如何快速获取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
Oracle CloudWorld 2023:Safra Catz主题演讲——把客户的成功放在首要位置
Safra Catz在Oracle CloudWorld 2023的开场演讲主题是“把客户的成功放在首要位置”。她强调了客户的重要性，并说大家通过合作和技术可以实现几乎一切。她感谢在场的观众，强调了学习和分享的重要性，以及公司致力于为客户提供更好服务的承诺。 在演讲中，她还邀请了来自其他公司的高管一同演讲，展示了在拥有适当技术和正确思维方式时所能实现的各种可能性。这些演讲突出了Oracle公司关注客户需求、强调合作伙伴关系、推动技术创新以及鼓励教育和知识分享的承诺，以实现客户的成功和公司的持续增长。 下面，我们就一起来具体看看Safra和这些高管的精彩演讲内容吧： 第1位嘉宾：Uber的CEO, Dara Khosrowshahi Uber是一家主要提供乘车服务的科技公司。 Dara Khosrowshahi和Safra Catz在演讲讨论时强调了关注客户的重要性：Dara充分理解满足客户需求的重要性，对话中还提到他自己亲自驾驶Uber来了解客户的需求。这也说明了关注客户的重要性。 而在技术和变革方面，对话讨论了技术和变革对企业的影响，以及如何在增长和盈利之间取得平衡。Oracle Cloud被认为是Uber成功增长和盈利的关键组成部分。他们强调了Uber与Oracle之间的紧密合作，以实现共同的目标。Dara 还提到了Uber Direct，这是一项与Oracle技术共同支持的服务，为客户提供快速的产品交付。Safra Catz强调了合作伙伴之间的信任和合作，以实现共同目标的重要性。 Safra和Dara的对话突出了对客户的关注、重视客户的成功，最终达到双赢的目标。 第2位嘉宾：AON的CEO, Lori Goltermann AON是一家全球领先的专业服务公司，为客户提供风险、退休和健康方面的筹划咨询和解决方案。 Lori Goltermann将在演讲中分享AON的客户导向战略：AON以客户需求为中心，致力于建立紧密的客户关系，提供相关性的服务，以及实现业务影响。这表明AON的核心战略是确保客户的成功和满意度。 在技术的关键作用方面：Lori强调了Oracle CX Cloud在帮助构建有效战略和实现客户成功方面的关键作用。她指出，技术是实现这一目标的关键要素之一。 同时Lori还提到AI将成为重要话题，特别是AI如何根据不同行业的需求进行定制。她还分享了AON正在快速但谨慎地探索AI的应用，以提高效率。 Safra和Lori的对话突出了客户导向、技术的关键作用以及对AI的探索。这些因素对于实现客户成功和推动业务增长同样至关重要。 第3位嘉宾：Loblaw的EVP, David Markwell Loblaw Companies Limited 是一家加拿大零售商，包括在 22 个区域和细分市场运营公司和特许经营超市，以及药店、银行和服装。 David … Continue reading
Mac上使用Royal TSX快速连接到OCI主机
问题： 每次使用Royal TSX连接到OCI主机都要交互式输入opc这个用户名，次数多了也蛮烦。 那如何既指定用户名，又想要通过ssh私钥登陆机器呢？ 这个需求确实很初级，但也着实困扰过我，因为开始我真的以为不支持，认为这两种连接方式只能选其一。结果没想到人家是可以组合使用实现这样的需求。 具体操作方法就是： 在“Credential”选择“Specify username and password”时，这里是可以支持只输入用户名，密码那里可以不填写的； 然后再同时去设置“Private Key File”指向你的ssh私钥即可。 具体设置如下截图所示： 1.指定用户名： 2.指定ssh密钥： 这样如此配合使用后，每次连接就不需要交互式的去输入用户名了，直接双击连接，属实方便多了。
小知识：PPT的幻灯片放映设置
最近给某客户讲课时，碰到了幻灯片自动翻页的情况，发现是因为之前做过粗略的计时演练，有些片子就快速过了。 问题现象： 结果导致放映时也出现了某些片子快速被自动翻页。 解决方案： 设置成手动推进幻灯片的方式即可解决，具体如下图所示： 我是第一次遇到此问题。问题虽简单，但很可能在遇到时正给客户演示，一时找不到原因就会很捉急，还好我有同事提示，同时也记录下来分享给遇到此问题的朋友们。
如何计算DG环境下Redo传输所需的带宽？
MOS有篇文章：
How To Calculate The Required Network Bandwidth Transfer Of Redo In Data Guard Environments (Doc ID 736755.1)
还提供了一个参考公式 Continue reading
部署19c ADG过程中的问题处理
回忆起来也是有些年没亲自动手搭建ADG了，今天正好有个机会重温，客户环境是19.16，恍惚记得上一次搭ADG还是在11.2.0.4的时代，时光荏苒啊。正好看下19c的ADG和11g的ADG在部署方面有啥不同？ Continue reading
Excel快速调整单元格行高和列宽
之前使用的是鼠标双击的方法，但是只适用于少量调整时。 Continue reading
