Oracle 的AWR 报告是很出名的，通过他可以获得数据库很多的信息，并对数据库的操作和调整有着指导的意义，而PG 如何在不花钱的情况下，完成这个工作，并且还要做的更好，更完美。谁说花钱的就更好？？？
首先不会Oracle的我觉得也可以听懂。哈哈，因为我不会专门讲oracle里的太细的东西。这部分的内容比较通用，可以借鉴思路。 我会在我的平台里面糅合这些思想，总之有货有料之后，加上时间和精力，就好比阳光空气水。 ppt有一部分是我在InfoQ的一次大会上做的一个简单的分享，今天在原来的ppt基础上重新做了一番解读。 这是我眼中的一些问题，有些Oracle已经做好了，对于一个成熟的商业软件来说，尽管功能上满足了，还是有些地方值得改进，或者说他们做得还不够好的地方。 这也体现了处理问题的几个阶段，有
某年某月某日的一个下午，接收到监控服务器的一条告警短信：尊敬的运维工程师 XX，你好：“192.168.136.200”数据库服务器 CPU 异常，CPU 使用率 98.7%，请尽快处理。看到这个消息浑身一紧，赶紧掐灭手中的烟，跑回办公室。
被问问题是经常的事情, 但有些问题是在是让人想起一个著名的包子品牌, 具体是那个,估计中国人都知道,那个是一个坑.
在Oracle的世界里，在DBA与Oracle开发人员的世界里，有几个名字不可或缺，Thomas Kyte是其中之一，他的几本重量级著作影响了几代DBA，他所宣讲的Oracle新特性总是被最多关注、理解和应用的一些；而Graham则少为人知，可是在Oracle内部，他被称为AWR之父，如果你还在用Oracle数据库，诊断分析性能，你就不得不知道他；而Andrew领导了RWP团队，在真实的用户世界中，为性能而奋斗，常常他为用户带来数百倍和上千倍的惊奇。 三位核心专家，一场精彩演出 就是这样三位专家，组成了RW
今天来给大家分享一下DBtime抖动的诊断案例。讲到的不足之处还希望大家多多指正，共同提高。案例会分下面几个方面来说。 首先来说问题的背景。因为使用的数据库环境多且复杂，数据库不只有Oracle,
目前一共包含6个脚本，若脚本的扩展名为“.sql”则表示该脚本为sql脚本，若脚本的扩展名为“.pl”则表示该脚本为perl脚本。
最近在和MYSQL的监控方法的事情在嫐裱，深感周遭的事情变化快，一步跟不上就的紧倒持。
之前的几篇文章： 《一个执行计划异常变更的案例 - 前传》 《一个执行计划异常变更的案例 - 外传之绑定变量窥探》 《一个执行计划异常变更的案例 - 外传之查看绑定变量值的几种方法》 《一个执行计划异常变更的案例 - 外传之rolling invalidation》 《一个执行计划异常变更的案例 - 外传之聚簇因子(Clustering Factor)》 《一个执行计划异常变更的案例 - 外传之查询执行计划的几种方法》
黄凯耀 (Kaya) ACOUG核心会员，高级技术专家 曾经工作于Oracle Real World Database Performance Group，一个隶属于Oracle公司总部数据库产品管理的核心团队。大学及研究生时期专注于Linux应用开发和Linux内核开发工作。 编辑手记：AWR是Oracle数据库中一个非常重要的诊断工具，通过度量而展现问题，每一个DBA都应当深入理解这其中的知识，本文通过讲解和分析，展示AWR分析的过程。 概述：本篇文章重点对 AWR 报告中的 DB Time、DB
往期专题请查看www.zhaibibei.cn 这是一个坚持Oracle，Python,MySQL原创内容的公众号 今天为： Oracle AWR报告全解析-SQL Statistics 大家点击
爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱 IT，喜欢在互联网里畅游，擅长摄影、厨艺，不会厨艺的 DBA 不是好司机，didi~
目前在规划、开发性能自动化执行框架，其中有个环节很有意思，就是如何通过框架自动获得场景执行期间的Oracle awr报告。虽然Oracle客户端提供的awrrpt.sql脚本可以提供交互方式生成awr报告，但并不能直接使用在自动化框架中，至少需要做一些改造，将交互的模式变成可以静默执行。
对于SQL调优，局部SQL，我们可以直接使用执行计划等直接调优，而对于整个系统来说？这时候就可以用Oracle系统自带的报告对系统进行整体分析了，Oracle提供好几种性能分析的报告，比如AWR、ASH、ADDM等等 这篇博客主要介绍AWR
是否为归档模式 数据库是否为归档模式，可以使用archivelog list查看 是否为force logging模式 数据库是否启用了force logging 是否使用spfile 这个新特性，其实还是比较实用的，建议开启，对于变更都能够及时统筹管理。所以这个特性mysql还是可以借鉴一下。 归档频率是否过高 数据库的归档频率是否过高，每个小时的归档日志量是否过大。比如500M为一个基准。 内核参数设置是否得当 内核参数设置的情况需要提前规律，是否存在不合理的
Oracle AWR 报告是分析数据库问题的十分有效的报告，我以前也写过不少 AWR 报告导读方面的文章。Oracle 12C 以后，AWR 报告的内容有了较大的变化，增加了很多内容。昨天正好有个网友发来一份做 BENCHMARK 测试时采集的 AWR 报告，以此为例，原本想写一篇导读文章，不过时间有限，“导读”写成“导读片段”了，因此今天只能给大家展示其中的一个问题分析的案例，希望今后有机会多写几篇此类的文章，把我对 AWR 分析的经验传递给大家。
作者简介： 罗海雄 云和恩墨优化专家 ITPUB论坛数据库管理版版主，2012 ITPUB全国SQL大赛冠军得主，他还是资深的架构师和性能优化专家，对 SQL 优化和理解尤其深入；从开发到性能管理，他
AWR(Automatic Workload Repository) 是自动负载信息库的英文缩写，是oracle提供的性能收集和分析工具，通常以小时粒度提供系统资源使用情况，可用来进行oracle性能监控、系统优化、故障定位。 oracle 12c中通常有以下几类awr报告： 单实例 AWR 报告： @$ORACLE_HOME/rdbms/admin/awrrpt.sql RAC AWR报告： @$ORACLE_HOME/rdbms/admin/awrgrpt.sql RAC环境中特定数据库实例的 AW
ASH（Active Session History，活动会话历史信息）、AWR（Automatic Workload Repository，自动负载信息库）、ADDM（Automatic Database Diagnostic Monitor，数据库自动诊断监视工具）是Oracle性能调整的三把利剑，需要深入地了解，但是面试一般都问得比较简单，主要问到的是AWR。
作者 | 邓秋爽：云和恩墨技术工程师，有超过七年超大型数据库专业服务经验，擅长 Oracle 数据库优化、SQL 优化和 Troubleshooting。
awr报告是oracle 10g及以上版本提供的一种性能收集和分析工具，它能提供一个时间段内整个系统资源使用情况的报告，通过这个报告，我们就可以了解Oracle数据库的整个运行情况，比如硬解释的比例，Catch命中率等，这就像一个人全面的体检报告。
AWR报告是数据库性能评估和优化的重要参考，将数据库的问题已量化的形式展现出来，给DBA带来了很多便利。然而AWR中的内容是非常多的，如何才能以最佳的方式解读AWR报告，最高效地找出数据库的性能问题所在呢？ 在刚刚过去的OOW2017大会上，AWR之父Graham 做了一个主题分享，名为“AWR Analysis for Admins, Developers and Architects” 运维、开发及架构师都应该一读的AWR报告分析。演讲ppt已在oow官网公开，接下来我们简单解读一下分享的主要内容。希
编辑手记：祝贺罗海雄老师加入Oracle ACE社区，他是数据库SQL开发和性能优化专家，也是ITPUB论坛的资深版主，我们整理了罗老师一篇AWR裸数据分析的文档，供大家学习参考
六一儿童节，虽然是大家快乐的假期，但是也宣告了2018年进入中场。在DB-Engines的6月排行榜上，不同的数据库产品竞争也进入中场。先预祝大家中场收获满满！
AWR是Oracle 10g版本推出的特性，全称叫做 Automatic Workload Repository 全自动负载信息库 。Oracle启动后，会有后台进程定时采集并保存系统快照信息，也可以手工创建快照。AWR通过对比两个时间点的快照信息，生成该时间段的AWR报告，帮助DBA或开发人员了解 Oracle 数据库的运行情况。Oracle 还提供了 ASH、ADDM等工具，本文不进行探讨。
近日，在给客户做了单机到集群的数据迁移后，发现集群的在线重做日志切换频繁，进而产生了大量的归档日志，对服务器造成了不小的压力。本文是对上述问题的分析处理过程。
Oracle收集大量有关性能和活动的统计信息。这些信息在内存中积累，并定期写入数据库：写入到构成自动工作负荷知识库（Automatic Workload Repository，AWR）的表中。AWR作为SYSAUX表空间中的一组表和其他对象而存在。AWR与数据字典相关，但又与数据字典不同，因为AWR对于运行数据库而言并不是必需的。数据写入AWR，并存储一段时间，最终被最近的信息覆盖。
Oracle中的AWR，全称为Automatic Workload Repository，自动负载信息库。它收集关于特定数据库的操作统计信息和其他统计信息，Oracle以固定的时间间隔(默认为1个小时)为其所有重要的统计信息和负载信息执行一次快照，并将快照存放入AWR中。这些信息在AWR中保留指定的时间(默认为1周)，然后执行删除。执行快照的频率和保持时间都是可以自定义的。
Oracle 的11g版本正式发布到今天已经10年有余，最新版本也已经到了20c，但是Direct Path Read（直接路径读）导致性能问题的案例仍时有发生，很多12c的用户还是经常遇到这个问题，所以有必要把这个事情再跟大家讲一遍，通过2个典型案例加深理解。
每天工作中会碰到一些问题，圈内朋友也会有各种问题，解决问题总是能够带来很大的成就感，有时候感觉在做两份工作。：） 帮助别人的意义就在于别人碰到的坑，你可能也会碰到，别人遇到的坎，也可能是以后你会面临的，坑填平了，坎越过去了，对己对人都是好事，知道那些坑，自己就会绕过去尽量规范，不要去犯；有哪些坎，出了问题之后，自己也知道该怎么处理，所以说是双赢，何乐而不为。 当然了，帮助别人，本职工作是保证。本职工作也要不断改进优化，其实你没意识到的问题，其他人可能早就用更高级的方法来做了。 ###问题1 比如之前自己使用
我写的SQL调优专栏：https://blog.csdn.net/u014427391/article/category/8679315
在MySQL中，对于性能问题诊断，最开始的时候总是感觉有些束手无策，如果一个人问你，MySQL数据库响应慢了，该怎么办，如果数据库服务器CPU 100%了该怎么吧，或者数据库连接不上了，业务提示无法连接该怎么办，看起来好像没有太大的关系的问题，其实我们能够分析的一个入口就是日志。
请访问 Oracle-AWR管理包 DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS
当把问题定位到某个或某些SQL后，我们接下来就要针对不同的场景和条件，通过各种工具和方法进行SQL的分析，而针对不同的环境和场景，我们选择的工具可能也有所不同。
讲师简介： 罗海雄 云和恩墨性能优化总监 ITPUB论坛数据库管理版版主，2012 ITPUB全国SQL大赛冠军得主，他还是资深的架构师和性能优化专家，对 SQL 优化和理解尤其深入；从开发到性能管理
许久没写这种troubleshooting类型的技术文章了，因为曾在服务公司呆过多年，工作原因，这方面之前做的多，听的更多，导致已经达到在自己认知维度下的一个小瓶颈，纯技术型的问题，稍微常见的基本都遇到过，非常少见的也基本是bug类（软件缺陷只能通过补丁或一些workaround的方式绕过去），感觉实在是没啥可写的。
如果问你，你的数据库性能如何，你会怎么回答呢？ DBA 甲： db file sequential read等待事件经常出现，不知道什么原因。 DBA 乙：平常负载不高，但偶尔周一业务高峰期就撑不住挂掉了。 DBA 丙：有一些SQL语句执行非常慢，但业务不给改，也没有办法。 以上会不会恰好也是你的答案？ 我们都在做运维，但往往被人问起才发现，自己并不懂自己的数据库。数据库的性能分析是一个很广泛的话题，涉及到的内容非常多，对于大多数的DBA来说都是一个复杂的让人头疼的问题，优化更是难上加难。今天，有一个人，他
AWR你好（1）文中提到过，AWR、ASH和ADDM三者之间有些猫腻，那在对ASH简单做了介绍以后，那这次我们就来看ADDM.
oracle性能分析入门学习中，遇到oracle数据库的性能问题，一般首要的步骤就是导出AWR的分析报告，awr报告是oracle自带的监控报告，会自带很多监控数据，那么本篇博客就是介绍如何导出awr报告
sys的初衷 MySQL 5.7的sys自从推出以来，整体的反响似乎没有预期的那么高，而我看到这个sys库的时候，第一感觉是越发和Oracle像了，不是里面的内容像，而是很多设计的方式越来相似。所以按照这种方式，我感觉离AWR这样的工具推出也不远了。 对于实时全面的抓取性能信息，MySQL依旧还在不断进步的路上。因为开源，所以有很多非常不错的工具，产品推出。myawr算是其中的一个，现在看来当初的设计方式和现在sys库很有相似之处，感兴趣的可以自行搜索查看。 所以对于sys库的学习，
AWR是Automatic Workload Repository的简称，中文叫着自动工作量资料档案库。既然是仓库，又是保存负载数据，所以保存的是数据库性能相关的数据。即特定数据库或者实例在过去运行期间整个性能表现。AWR能实现性能数据的收集，处理，维护，以及给出调整参考等。这些收集到的数据被定期保存到磁盘，可以从数据字典查询以及生成性能报告等。
用户系统有一个每隔1分钟执行的工作任务（JOB），通常会在1左右秒结束。 但是在最近发生过2次问题：由于等待”log file sync”事件，导致该工作任务（JOB）的会话等待几十分钟，不能正常完成。 发生问题的时间如下：
最近看 awr 报告时，经常会看到一些 enq: TX - row lock contention 的等待事件，所以简单研究一下如何排查，仅为个人所见，如有异议或者修正还请评论指出，谢谢！
“log file sync”是等待事件中非常常见的一种，他排在AWR的top5中有时是正常情况，有时则需要格外注意。昨天也听了一次Oracle的网络研讨会，介绍的是AWR相关的分析，从中学习到最重要的一点，就是对于AWR报告中若干信息的判断不能独立地看，需要综合起来，一个参数值大，不一定代表有问题，也可能是正常的，需要具体问题具体分析，其实和日常生活是一样的，头疼，不一定是感冒，也可能是缺少睡眠。
最近在“云和恩墨微信大讲堂”中，有很多朋友遇到性能问题，但是往往没有及时的诊断信息。我将之前书中的一章摘录出来和大家略为分享。 在数据库系统的诊断中，通常须要综合分析两个方面的因素： 主机系统的采样分析数据； 数据库系统的采样分析数据。 其中主机的采样数据可以通过操作系统的相关工具来收集，Nmon（可以用于AIX和Linux）和Oracle的OSWatcher都是很不错的轻量级采样工具；数据库的采样分析数据则可以通过Oracle的AWR采样数据获得，前者需要手工部署，后者自Oracle Database
在探究awr第一篇中介绍了awr的一些基本操作 http://blog.itpub.net/23718752/viewspace-1123134/ 在这一篇中，我们来分析几个awr报告来探究一下awr的一些信息，其实在报告中有很多的信息是互相印证的。对于我们深入理解awr报告还是很哟帮助的。 首先来看看CPU负载的分析，这个也是理解awr的一个切入点。 CPU资源的考虑也是衡量系统系统的一个很好的标准，CPU的信息有基于系统级的，实例级的，通过awr报告的几个部分来互相印证。 在11g中，我们可以从报告的开
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
实时音视频
即时通信 IM
对象存储
