ITPub博客

线上的生产系统，出现故障是大家都不愿意看到的。但是当出现故障，造成业务影响，涉及事后追责的时候，运维与开发，运维各团队之间，很容易出现相互推诿、各说各话的情况，毕竟，故障责任这个锅，谁也不想背！ 解决这类问题的最有效途径是什么呢？答案是根因分析！通常做到根因分析后，很容易重现并模拟故障，一切都会变得更加容易。 小y今天为大家分享这么一个案例:一支批量程序跑了好几年了，都好好的。

前言：我们首先要欢迎本文作者高斌正是加入中亦科技，高斌此前在oracle工作10年有余，绝对称得上是资深元老级人物，在oracle RAC、一体机方面更是独树一帜；如今加入中亦科技，也让中亦科技的oracle 技术服务力量如虎添翼；在此也欢迎各路高手加入中亦科技，为客户提供更好的技术服务。话不多说，我们来看今天分享的技术案例。问题来了：用户一套11.2.0.3 的双节点RAC系统安装在A

最近有朋友和小y反馈：他们的一台IBM的X86服务器（现在属于联想）出现硬件损坏，维护人员通过管理口收集诊断日志给厂商时，服务器上运行的好好的一套ORACLE 11.2的RAC数据库，突然有一个节点重启了..这是是什么情况? 听到这里，小y基本上猜到了原因，类似的问题，以前分析和处理过几次，分析过程也不复杂，但是没想到，类似的故障现在居然还在发生.因此有必要把这个风险提示出来!这里，小y

不知不觉技术人生系列已经来到了第四十期，前面我们分享了各种精彩案例，在与众多读者的交流中发现许多读者有对SQL优化的案例的需求，通常我们认为，SQL优化涉及的信息会比较多，比如需要各种表的数据分布信息，索引信息，统计信息等，有时还跟业务逻辑紧密相关，所以SQL优化的案例在我们技术人生系列的分享中出现的次数较少；不过今天，我们要分享的SQL优化案例能充分体现SQL优化的技巧，忍不住要将精彩奉献给大家

问题来了客户DBA发来微信，说有个字段，在sqlplus里查询时报错：客户很资深，找到典型数据的特征：最后那个C9是半个字符。老猫：『数据是通过什么接口进去的？』客户小A：『C语言』老猫：『OCI，还是pro*c?』客户小A：『不知道，要是有空麻烦过来跟我们开发聊一下』地铁2号线上，盯着薛之谦『弹个车』那个破广告，脑子飞快地转动，这类问题我遇到过，在原厂处理SR时解决过，给某农商行的强人女DBA也

Oracle 12C已经开始逐渐开始走上各客户的生产系统了，大家对12C的各种新特新是怎样理解的呢？通过读白皮书还是其他的官方文档？如果遇到问题了，我们如何一步一步定位到新特性上？今天我们迎来CESOUG成员海猫的分享，看看他对12C的新特性的认识。 正常情况下truncate一张表需要多长时间？我们应该如何判定一个truncate操作的时间阈值？如果truncate操作我们无法找到对应

11月25日，周五晚上，正在家里看电视,电话响了，是一位银行客户资深DBA的来电，也是我的好朋友、好兄弟，看来，他遇到麻烦了…“远邦,11月20号晚上例行跑批的时候，在1分钟内出现了多笔联机交易超时！当时的CPU不高，内存很富余，没有换页。异常的SQL_ID是15vru8xqgdkjf，就是我们的联机交易会插入的交易报文表，这个表和批量没有关系。最严重的一笔，就是2016-11-20 20:44:

前言：为了加快SQL语句的执行速度，你都用过哪些方法呢？我常常听到不少DBA总结道：“调优也没什么难的，常用的不就那三板斧吗：收集表的统计信息；给执行计划中产生全表扫的表加索引；再不行就给语句加上并行…”每每听到这样的说法，我倒也无法直接反驳，上面说的方法确实是我们常用的方法，但是，我深知其中涉及的知识远不止口头上说的那么简单，而是在深刻分析后得出的轻巧。比如，如果我们看到下面的执行计划，你会觉得

01某客户数据库服务器的文件系统经常会被撑满，导致数据库不可用。原来出现过几次解决均是客户清理了文件系统中的trace文件。但是当问题反复频繁出现，客户自然会想到300G的文件系统，怎么说满就满了呢？是不是数据库出现了什么问题了呢？否则怎么会总有那么多trace文件产生？于是这一次，客户采取的是先删除部分trace，保留了一些信息，然后将系统恢复到正常状态后，联系到了我们，做一次深入的分析。问题初

前言：又一个时快时慢的SQL，不过这一次，10g与11g执行计划不一致，11g执行计划一致却还是时快时慢，如果遇到这样的问题，你会从哪分析入手，如何给出合理的解释，如何给出进一步优化的建议呢？本期，我们继续有请我们的优化老能手老猫与我们分享又一例经典SQL案例。问题描述~客户Q：『老猫，我这里有个非常诡异的问题，从10g升级到11.2以后，有条SQL，晚上运行非常慢；白天就很快。数据量变化不大，一

看到这个标题，相信不少朋友有类似的感慨：是呀，变更（前）不重启，就是害自己！前人挖坑，后人踩！相信不少朋友有过类似残酷经历，做了一个变更，重启之后，出问题了！到底是本次变更导致还是以前留下的深坑呢? 查不清的只能默默地背锅了…小y的建议是：“         理想情况下，条件允许，做变更前，先重启一

前言：我们曾经在17期，发布了”看中国最美女DBA的一次价值连城的系统优化”的文章,大家表示很好看。很多网友对什么时候可以再看到最美女DBA的文章表示严重的关注，为此，我们在32期再度邀请到中亦科技的小仙女为大家分享她的第二篇技术文章。客户删除大量历史分区，越删越慢，同时系统出现性能问题，请求协助分析和解决。如下图所示,红色底线表示执行时间:删除分区的时间从1秒钟变为2分钟，再到5分钟…如果是你，

小编前言话说，技术人生系列文章已经来到了第三十一期，小编我跟着一路走来，也算是小小的oracle技术达人了；这天主编大人兴致冲冲的过来问我道，考你一个小问题，说“ORACLE中两个表T1，T2，对于语句select * from t1,t2 和select * from t2,t1有什么区别吗？”对于这个问题，小编我虽然二十几年没搞过ORACLE数据库，但是编辑/阅读了三十期的技术人生系列，我也是

问题来了电话响了，是一位证券客户DBA的来电，看来，问题没过两天，又出现了。接起电话，果不其然。“小y,前天那个问题又重现了。重启后恢复正常，这次抓到了hangAnalyze,不过领导在身后一直催，所以没来得及抓取systemstate  dump就重启了。你尽快帮忙分析下吧，hanganalyze的trace文件已经转到你邮箱了。”就在2天前，该客户找到小y,他们有一套比较重要的系统出

一个常见的经典问题，也是一个难缠的业界难题，基于Oracle的程序时快时慢，很多资深的DBA面临这个问题也是束手无策，没有一个最优的解决方案。如果你的数据库正经历各种性能问题，不妨联系中亦科技试一试，看我们如何解决你的数据库忧虑。                        &

小CASE见大问题之足以摧毁整个应用的数据库设计--技术人生系列第二十八期-我和数据中心的故事

作为一名混迹数据库江湖十几年的老DBA，当你对关系型数据库的了解越来越深入时，你会发现，Oracle数据库真的是强大到令人发紫！ Oracle数据库的强大，不仅体现在其对ACID的巧妙实现，其对高并发的完美支持，更重要的是他的可管理性，包括可度量、可回溯，以及出现问题后的问题核查接口和问题检查方法论，真是强大到令人发紫,这是其他关系型数据库短期内还无法超越的。   

前言：中国银行DBA团队是在中行数据中心自主化运维过程中产生的一个顶尖技术团队，团队年轻有活力，中行数据中心的系统运维时时可以看到他们的身影，发起的的技术公开课场场爆满，技术实力在我们所见的众多客户中首屈一指，团队成长速度也是作为乙方的我们大为惊叹的；今天我们有幸邀请到甲方工程师与我们来分享他们的技术故事，大家来看看在国有大型银行做DBA会是一种怎样的体验，需要怎样的专业素养，也希望以后能邀请我们

编者注：今天我们继续邀请到我们的朋友赫总为我们分享他的技术故事；一个安装问题，我们来看Henry在处理的过程中是如何一步一步定位问题，找出真相，最后帮客户解决问题的。如果是读者你，作为老司机，是不是也有可能经历类似的事情，遇到类似的问题你又会如何解决呢？且看我们的RAC专家Henry的分享。如果读完文章有所收获，还请帮忙转发，您的转发是我们持续分享的动力。老司机翻了车用户现场有一位经验丰富的DBA

编者注：今天我们非常荣幸的邀请到了我们的好朋友Allen来给我们分享他的技术故事。Allen也是一名低调的高手，入行十几年，在研究ORACLE技术的过程中也是十分乐于分享；Allen在CRS/RAC的研究方面更是独树一帜，前几年写了一本书《Oracle RAC 核心技术详解》，这本书基本上是编者全面深入了解oracle RAC的指导之作，看完书作，才会发关于oracle RAC我们原来懂得太少，关