ITPub博客

前 言在客户现场处理各种各样的问题，很多问题会涉及到数据库、存储、操作系统甚至应用代码，只有先定位问题的根源在哪个或哪几个方向，才能做出针对性的分析，否则就很有可能在处理问题的过程中南辕北辙，无的放矢，无法快速解决问题；今天分享的问题，可能到最后，并不是DBA可以控制的部分，然而作为DBA，时不时需要解释两个问题：我们什么都没有变化，出了问题跟我们有关吗？为什么以前没有问题，现在有问题了呢？事实上

ASSM机制是oracle在段内进行空间自动管理的机制；通常来说，这个机制能很好的帮我们查找、定位、分配相关的段空间；然而，所有的机制都不是那么完美的，在具体的CASE中，我们需要充分理解它，才能更好的掌控它；今天的CASE分享，希望大家能对ASSM机制有真正充分的理解。1问题来了“我们这一个奇怪的问题吧，一个简单的insert语句居然执行了上百秒。”在一个投产上线后的某一天，负责应用维护的同事描

前言作为经验丰富的DBA，我们经常会遇到各式各样的bug；然而，并不是每个bug都可以简单的直接通过现象匹配出来，很多时候，我们可能需要通过不同的维度先收集很多信息，甚至先找出问题的解决/绕行方案，再来确定问题的bug的源头；今天的分享，我们就来看一个用特别的方法来定位、确认bug的案例，通过这个案例，我们可以举一反三，触类旁通的了解更多oracle的小技巧；在案例分享中，方法比结论来的更重要！升

前言：通常SQL优化的常见手段包括，收集统计信息，创建索引，重写SQL语句，而大家日常遇到的CASE中是否也有遇到过，SQL已经看似没有优化空间，系系统整体性能也非常良好，但是SQL语句就是达不到预期执行效率的呢？今天作者给大家分享的就是一个不算SQL优化的“SQL优化"，希望大家能有所启发；     批量语句太慢了某日早上，客户应用维护的同事提出问题，有一

前言一个复杂问题通常可以拆解成若干个简单问题来分析，如何从各个维度来分析和确认一个问题，并最终给出合理的解决方案却又是一个比较复杂的过程；今天给大家分享的就是，从一个"简单"的报错最后定位到bug，并最终结合具体CASE给出解决方案的案例，希望大家能从中领悟到解决问题过程中的各种技巧和思路，同时告诉大家有些oracle bug并不可怕，其实我们自己就可以给出解决方案。“简单”的

前言：上线前检查已经是老生常谈了，通常上线前检查完后，就应该当做生产系统对待，不应该随意修改系统的相关配置，然而，很多老司机会认为，自己对系统很有把握，修改一些系统配置，重启系统后没有任何问题，就此认为一切正常；殊不知，很可能一个不经意的操作，给你的系统就已经带来了无法预知的隐患。发现隐患客户新搭建了一套11g的RAC+DATAGUARD环境，CRS、数据库已经运行了一段时间了，正准备投产上线，这

现象描述数据库大版本升级的过程是相对复杂和繁琐的，非标准流程下100套系统可能会遇到100个不同的问题，这种问题相对好解决，那么本期的问题来了，在使用EXPDP/IMPDP工具，从Oracle 10.2.0.4迁移到11.2.0.4之后，约束比对时发现，原生产环境10.2.0.4的数据库比新生产11.2.0.4环境中多了27个约束：select owner,CONSTRAINT_TYPE,STAT

前言：时间一晃已经来到了6月，技术人生系列文章已经半年没有更新了，在过去的半年时间里，我们技术人生系列文章的作者们一直奋战在工作一线，同时不忘积累和总结，为我们的文章提供更深厚的底蕴；如今，技术人生系列将携中亦课堂正式回归，依旧严谨深刻，生动再现客户现场处理问题的点点滴滴，希望在传递更多知识点的同时给大家带来更多深度的思考。在这里，首先感谢一直以来支持技术人生系列的小伙伴们，你们的支持与转发是我们

问题来了某客户发现生产库上的跑批脚本经常跑了180+ 分钟，而在测试库跑完脚本只要60分钟；客户觉得生产服务器的配置比测试服务器高，而且数据库的压力很小，出现这种生产比测试还慢的情况无法理喻，怀疑是ORACLE数据库有问题，所以联系小编进一步排查。负载性能先看生产库的AWR，面对这种数据库总体性能问题，从AWR入手可以直观而且全面地了解一个数据库的性能和问题；生产库运行在AIX平台上8C 32GB

一、问题描述某大型国有银行的一套业务系统，近期由小型机迁移至X86环境。据项目组反映部分DB_LINK查询比原来小型机慢。这不对啊，相同的存储，CPU也更多，内存也更大。于是DBA随手挑出一张大表，做个简单的COUNT(*)查询，发现Linux比AIX慢了6倍。重复执行多次，结果也类似。难道委屈项目组了，这套X86就是比小机慢？于是找上中亦，深入分析下问题原因。执行时间对比AIX下执行时间为3分1

上线前的压力测试，是系统上线过程中重要一环；一轮好的压力测试，不仅能发现系统配置方面的不足，更重要的是能发现应用设计上的缺陷；压测时发现问题之时，事实上也是我们结合应用逻辑提出有效解决方案的大好机会；这个时候的改动，代价更小、调整更方便，而且还能直接看到压力环境下的测试效果；也就能验证你提出的解决方案是否有效了。 今天笔者要跟大家分享的问题，是一个压测过程中与"enq: TX

线上的生产系统，因为一些原因，时不时会出现一些意想不到的性能问题，当紧急问题出现时，我们如果无法立即解决，有时通过调整系统硬件资源是一种快速有效的解决应急方式，确保系统能正常运行后，再做根因分析，从根本上解决问题； 最近老K遇到了客户的应急策略导致了数据库重启的案例，翻了翻邮件历史，竟是N年前就已经遇到过了；问题本身不算复杂，然而却可以造成数据库直接重启，影响生产，这里特别分享出来，给大

相信大家做DBA的，都看到过很多数据库专家缜密思考、抽丝剥茧、层层推进最终找到问题答案的精彩案例。Jason每次看到这样的案例，都被专家们丰富的经验，执着的态度和强大的逻辑推理能力折服。但这是不是诊断数据库问题的唯一方法论呢？可不可以讲近来大热的机器学习思想引入其中，通过统计学（深度学习的基础）来诊断问题呢？Jason在近期遇到的一个问题上，做了些许尝试，这里分享给大家。。。　问题描述　在Jaso

写在前面如果你的数据库性能经常抖动，时快时慢，你会怎么入手，又会怎么一步步排查解决的？是先看等待事件？还是看AWR或ASH？接下来优化SQL？调整参数？甚至更换硬件？本次分享一个我在GCS处理的案例，希望大家读后会有新的收获。问题来了在一个宁静的早晨，本来打算能够看会儿书，做几个实验来打发时间，刚刚拿起书，电话就如期而至，让本来宁静的早晨变成了工作的开始。仔细想想，这就是运维人的常态吧，也就释然了

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

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

不知不觉技术人生系列已经来到了第四十期，前面我们分享了各种精彩案例，在与众多读者的交流中发现许多读者有对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: