ITPub博客

分 享 预 告618马上就要到了，各位亲们都准备好秒杀点什么呢？随着网上商务的不断普及，各种购物狂欢节也层出不穷。作为DBA，面对购物狂欢节，你首先想到的是什么呢？事务风暴？商品库存表出现行锁等待？……笔者今天和大家分享的就是和双十一秒杀系统有关的一个小故事，当然了，没有核心系统特别大的故障，否则出现大故障，大家都会知道的了。故事里，有的是对一线DBA工作状态、现场支持压力的描述以及笔者从事件中衍

前言：对于DBA来说，掌握数据库的各种特性是保证数据库性能稳定的重要前提之一；统计信息的准确性通常是我们日常运维的难题之一，如何保证统计信息的及时更新有效，而在此过程中是否会引起其他的问题？今天的分享给大家带来的CASE将展示此中隐患，同时通过CASE我们来看看我们如何使用trace文件的分析快速定位问题，并最终给出日常运维的几条建议。不一样的任务对于长期处于一线的DBA来说，处理性能故障的最好方

  前言       关于SQL的问题，老猫最常遇见的就是让客户头大分析起来麻烦的性能问题，巴特，对于老猫这种作为长期支持各种客户的老司机，这根本不叫搞事情呀！       对客户而言，最怕遇到的就是trouble shooting有一定难度，原因还多样的wrong result了，因为目前的应用多

分享预告一个生产系统告警，如何让它成为技术新手的上手机会，通过使用ORACLE的基本技能，分析出较复杂问题的根本原因所在，在分析过程中大胆猜测，步步推进，并最终形成一个非常有警示性的风险提示，给出规避方案和解决方案，老K希望能给大家一些不一样的启示。技术的锲子熟悉老K的朋友都知道老K平常很大一部分时间是待在某总行级数据中心支持日常运维工作，该总行数据中心拥有自己的DBA团队数十人，高手技术了得，但

   记得几年前，当小y在mos上找到”Bug 17208793 Producing an AIX system crash dumps on clusterwareinitiated reboots”这篇文章的时候，几乎泪奔了。作为读者的你，可能没有意识到什么，但是对小y而言，简直是如获至宝；因为小y常年处理的case中，其中有一类case叫做RAC节点驱逐。我们知道，当RA

序幕&进入角色4月24日，早上七点，老K为迎接某国有大型银行批次投产后开门营业作现场支持该行运维团队的工作；根据以往的经验，该行每次批次投产会有数十套系统的软件/环境版本变化、系统迁移等操作，在投产后的第一个工作日开门营业后，多少会有一些问题；而ORACLE数据库作为各业务系统中的重要一环，往往是领导们关注的重点。时间大约在8点左右，应用维护团队报出问题来：某套系统的某关键业务在开门前，需

分享预告你的系统中是否存在间歇性的IO性能问题，或者一直以来都IO性能不佳呢？文章的最后，将给出共性的风险提示和检查方法，还犹豫什么呢，也查一查您的系统吧^_^。这次我们分享的主题 --- 看中国最美DBA一次价值连城的系统优化！通过系统的优化，将某客户一个关键业务系统经常性卡顿和白屏的性能问题彻底解决!首先让大家提前看一下Oracle数据库优化前后的效果比对图吧，一会再看..

2月14日，情人节前夕，某数据中心一套Oracle 11.2.0.4 RAC宕了！隔了几天，又有一套RAC宕了！几天后，紧接着又有一套RAC宕了...作为运维的你，听到其他客户出现这样的宕机潮时，是不是心底会泛起一阵莫名的恐慌?那么问题来了，贵司的数据中心到会不会也将出现类似的宕机潮呢？这些故障是什么原因引起的呢？这股宕机潮会继续疯狂延续下去么… 如果不能及时找到问题真相，那么小y相信，

编者注：此问题的难点在于其隐蔽性，有时候故障现象可能不明显。例如表空间使用率瞬间从10%激增到50%时，你并没有察觉，因为没有达到告警阀值，但你却在默默承受着空间泄漏之殇。即使告警了，不明原因的客户也只是扩容表空间来简单粗暴的解决。当这个问题多年后被人行重新提起，我们不要再视而不见了，对于版本匹配的小伙伴们要做好监控和预防工作，也不枉小亦的一篇苦心。前言最近，我们维护的很多银行客户都收到了来自人民

橙色预警：Oracle游标泄露（open_cursor耗尽）1前言编者注，本文的知识点较多，请补充足够正能量后阅读，看完会让你质疑你的DBA生涯，作者的水平代表着国内Oracle TroubleShooting最高水平。很早就想把ORA-1000的问题，总结成一个话题。机缘巧合，最近恰好遇上几个此类问题，特分享分析过程出来供大家参考。首先，ORA-1000报错是什么意思呢？我们来看看官方的解释：非

前言       某大型国有银行一套关键系统10g升级到11g，老K负责升级后第一天早上的运行保障；在升级前甲方客户已经先后做了各种测试，以保证升级后不会存在任何性能问题。然而，事与愿违，老K刚到现场，客户应用团队就已经反馈到客户说批量慢了一段时间，根据应用日志与现场负责协助升级的友商DBA的核查，初步定位问题为升级后使用的存储变慢导致的导出缓慢，拖慢了批量

前言            好消息！本期，小编终于第一次邀请到了中亦科技数据库团队的老猫（mason）做为我们的分享嘉宾，撒花，兴奋，捂脸！    老猫，混迹DBA江湖30载有余,小编心中的真正大神级人物，同时也是我们的段子大湿，为我们team和客户带来了无数的欢乐。  &nbs

       春风轻轻吹走了冬日里的寒气，又到了一年最美的花季，伴随着温暖的阳光老K再次与大家相见！此次的回归老K不仅会继续和大家分享一些自己处理过的小案例，更优化了技术交流模块，希望在探讨的过程中大家可以提高技术等级的同时，也能领略到中亦DBA团队独有的匠人精神。问题来了    某一日的清晨，客户

前言不知不觉，技术人生系列·我和数据中心的故事来到了第十期，小y又和大家见面了！前期我们分享了不少Oracle数据库故障和优化的实战案例，有朋友问，小y是否可以分享一些无备份时数据恢复方面的实战案例呢？答案自然是——当然可以了。小y从来就不是一个藏着掖着的人嘛 ^_^这些年，小y所在的Oracle服务团队，该遇到的和不该遇到的问题，基本都碰到了。所以在无备份的数据恢复这方面做的案例还是很多的，有时

前言今天老K继续与大家分享第九期。周末老K宅在家观战了两局精彩的“人狗”大战。老K既算不上科技迷，也算不上围棋迷，不过对此颇有感触：阿尔法狗不过是通过左右互博的方式不断学习围棋，然而依赖其最优的学习算法（学习方法）却能再短短的数月之内达到人类围棋水平的最顶端；而李世石在却是依赖其已有的经验结合人类特有的灵感下出“神之一手”，人类终究还是可以战胜拥有超强计算能力的阿尔法狗。这些不禁让老K想起了自己在

前言接上一期：（上一期的阅读方法：关注“中亦安图”公众号后回复‘007’）4.3.4SSD中library cache lock的分析接上一期：分析到这步，前边看似毫无头绪的问题似乎理清了，大量cursor:pin S wait on X已经理清楚，所有的矛头走指向了sid 859离真相只差一步了，我们只需要分析library cache lock的源头就能解释整个谜团了，前面老K已经提到了分析l

前言本期我们邀请中亦科技的另外一位Oracle专家老K来给大家分享systemstate dump分析的经典案例。后续我们还会有更多技术专家带来更多诚意分享。老K作为一个长期在数据中心奋战的数据库工程师，看到小y前期的分享，有种跃跃欲试的感觉，也想把我日常遇到的一些有意思的案例拿出来分享讨论，希望我们都能从中获得些许收获，少走弯路。同时本文涉及到很多基础知识，又涉及看似枯燥的trace分析，但老K

前言时间过的真快，技术人生系列·我和数据中心的故事已经来到了第六期，小y又和大家见面了！小y今天要和大家分享的是一个综合型问题的的分析和解决过程。解决该类问题，只懂数据库是不够的，还需要掌握比较扎实的操作系统技能。同时引出了另外一种不太常见形式的优化，内存优化。由于今天要分享的问题具有普遍性，建议大家可以按照文中方法检查自己的系统中有无类似问题。分享的最后将对该共性的风险进行总结和提示。如果觉得分

前言不知不觉，技术人生系列·我和数据中心的故事来到了第五期。小y又和大家见面了！前几期主要发了一些TroubleShooting的案例分享，其实小y最擅长的是性能优化，所以从这期开始，小y会陆续的分享更多的数据库性能优化案例。进入正题，如果您的日终跑批/清算/报表等程序时快时慢，或者从某一天以后就一直变慢，作为运维DBA或开发的您，会怎么下手？还有，除了解决问题外，你要如何解答领导最关心的一个问题

前言不知不觉，技术人生系列·我和数据中心的故事来到了第四期。小y又和大家见面了！当您看到业务系统压测呈现以下波浪形的tps曲线时，你会怎么下手？小y(中亦科技)今天要和大家分享的就是这样一个业务系统压测性能问题的分析和解决过程。这个问题困扰了客户相当长一段时间，幸运的是，小y通过远程在10分钟定位到了问题的原因并帮助客户最终解决了问题。需要说明的是，在这个CASE中，只调整数据库参数是不够的，还需