ITPub博客

在sql调优中使用dbms_sqltune是一个很高效的工具，如果说awr发现了性能问题sql,addm可以给出调优建议，sql monitor能够监控性能问题sql和执行计划，那么dbms_sqltune就是最后的优化顾问了，它给出的建议是经过深思熟虑的。而且相对来说更加权威。尤其是对于老DBA而言，在这个地方其实就有些吃亏，因为这个功能着实太强大了...

在学习Oracle的时候，必然会接触到sql解析的过程。这个过程大体是这样的步骤。1.对sql的文法检查，查看是否有文法错误，比如from,select拼写错误等。2.在数据字典里校验sql涉及的对象是否存在。3.将对象进行名称转换，比如同义词转义成对应的对象。比如select * from t t是一个同义词指向hr.test4.检查语句的用户是否具...

在前几天搭建好备库之后，因为同步文件着实花了些时间，首先配置备库能够正常接收归档，然后内核参数也基本没有设置，简单使用脚本算出一个Hugepage的值，就直接改了。当时从数据库日志中确实也没有发现hugepage启用的情况，但是因为不是很影响备库的性能，自己就没有重视。结果早上的时候，首先受到了一封报警邮件。ZA...

今天有个同学问我一个问题，也是一个实际的案例，我简单分析了一下，发现还是有很多可以考究的地方。仅做参考。问题是，系统里目前有一个大表，因为历史数据的沉淀，目前有60多亿的数据，不是分区表，现在得到反馈说insert的操作比较满，想优化一下，同时把部分历史数据需要做一些清理。对于这类操作，要求停机时间尽可能...

继前两篇分析了一个看似非常普通的报警邮件，结果在分析问题的时候八面玲珑，相关因素都给分析了一下，没想到还真是有不小的收获。前两篇地址：http://blog.itpub.net/23718752/viewspace-1827685/http://blog.itpub.net/23718752/viewspace-1829630/最后通过手工定位监控的方式终于把罪魁祸首揪了出来，为什么在备库使...

test

今天早上到了公司后，收到了这样一封报警邮件，发现收到备库的报警案例也比较多，着实颠覆了我对备库基本不需要关注管理的观点。后面可以把几个案例做成一个主题来说说。报警邮件的内容如下： ZABBIX-监控系统:------------------------------------报警内容: DG_issue------------------------------------报警...

之前分享过一篇关于merge语句导致的CPU使用率过高优化的案例。的http://blog.itpub.net/23718752/viewspace-1819471/后续的跟进没有补充，也“秀”一张图，红色的火焰是原来的系统负载，右边的部分是最近的逻辑读情况，不过惭愧的是，这个不是优化的效果，因为应用的高峰期已经处理完了，后面的sql调用频率极低，所以感觉...

在之前写过 记一次数据同步需求的改进(一)之后，就开始着手对这个需求进行实践。所谓实践出真知，在实际做的时候才发现可能计划的再好，做的时候还真不是那么回事。在之前的邮件中已经确认目标库是一个统计分析库，首先拿到这个环境，先调查一番，发现了一个奇怪的现象。查看这个库的归档情况的时候发现这个库每天的凌晨...

今天有一个数据库有点反常，早上的时候报出了CPU使用率的警告。警告内容如下：ZABBIX-监控系统: ------------------------------------报警内容: CPU utilization is too high------------------------------------报警级别: PROBLEM------------------------------------监控项目: CPU idle time：44.61 % ----...

今天下午收到一条报警邮件ZABBIX-监控系统: ------------------------------------报警内容: Free disk space is less than 20% on volume /U01------------------------------------报警级别: PROBLEM------------------------------------监控项目: Free disk space on /U01 (percentage)：9.7 % ---------------...

最近收到一封报警邮件，提示还是DB time突然提高，时间发生在早晨的时候，想必大过节的也不会有人这么卖力工作把数据库负载弄上去。<br />############ DB time抖动 被平均<br />ZABBIX-监控系统: <br />------------------------------------<br />报警内容: DB time is too high<br />-----------------------------...

继昨天对系统进行了初步的调优后，效果还是比较显著，DB time从500%降到了100%以内，当然过程还是充满艰辛，期间也是各种工具和分析语句斟酌了再三。<br />今天也没有收到任何报警，所以感觉问题似乎已经彻底解决了。在下午的时候查看了一下，发现在凌晨的时候有一个大的抖动，然后DB time基本持续在300%~400%左右。比预期...

继昨天使用DB time能够快速灵活的定位sql语句之后，发现分析问题更快捷，高效了。今天就牛刀小试，把一个数据库从500%的负载调到不到100%的负载。前提是确实有可提升可改进的空间。首先查看了在快照57611的时间段里DB time很快，也收到了zabbix的邮件通知，

今天来给大家分享一下DBtime抖动的诊断案例。讲到的不足之处还希望大家多多指正，共同提高。案例会分下面几个方面来说。 首先来说问题的背景。因为使用的数据库环境多且复杂，数据库不只有Oracle,所以通过gc...

最近使用zabbix监控之后，都会在凌晨收到1台数据库服务器的报警短信，报警的内容为: Nodata received from Orabbix这个错误其实就是orabbix通过jdbc已经接受不到数据库实例的信息了，但是隔了10来分钟之后，又会收到问题恢复的短信。既然问题已经自动修复了，可能在那个时...

最近处理一个问题的时候，先是收到DB time升高的报警，然后查看DB time的情况发现，已经有近1000%的负载了。<br /><img alt="" src="/attachment/201509/16/23718752_1442416530OFsu.png" width="700" height="197" /><br />带着好奇心想看看到底是什么样的一个语句导致如此的情况。<br />先抓取了一个awr报告，因为问题...

在上周五的时候，本来一个例行巡检，想扩充一些表空间，结果弄巧成拙，因为一个drop datafile的操作直接导致了一主两备的两个备库MRP直接抛出了ORA-600错误。<br />在尝试了一些方法和查看了MOS之后，除了重建备库，暂时还没有找到其它相对更快捷的方法。<br />因为是10.2.0.4.0的环境，为了先修复问题，自己先使用rman在...

接着上次分享的关于数据库无法登录的原因http://blog.itpub.net/23718752/viewspace-1791089/其实最终还是因为在短期内生成了大量的redo,造成了频繁的日志切换，导致归档占用了大量的空间，最后无法登录，从这个层面来说，我们可以做一些工作来尽可能长时间的保留近期的归档，但是我们还可以换一个思路，那就是看看...

在前两篇的基础上，对于一个环境中存在的奇怪并行进程问题进行了初步的分析。初步排除了是通过scheduler的job运行导致的，一方面因为运行的时间会有延迟，甚至有很大的差别。所以分析和排查按照scheduler的时间点没有办法抓到任何规律。排除了scheduler的影响之后，在分析ash之后无果，最后无奈使用了自定义...