Oracle的awr报表分析数据库性能

简介:

早上群里喊数据库挂了,开始阶段服务登录不上,等登录系统后发现系统负载很高。

运行的oracle服务,今天就用oracle的awr作了一把分析,步骤如下:

一、登录数据库

[root@iZ233j4mpnbZ ~]# su - oracle

[oracle@iZ233j4mpnbZ ~]$ sqlplus sys as sysdba

 

SQL*Plus: Release 11.2.0.1.0 Production on Tue Jun 21 14:36:31 2016

 

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

 

Enter password: 

 

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

 

SQL> 

二、数据异常时间段的参数

输入完后,将输出在当前文件夹下。

 #执行对应的awrrpt.sql脚本文件

SQL> @?/rdbms/admin/awrrpt.sql

 

Current Instance

~~~~~~~~~~~~~~~~

 

   DB Id    DB Name Inst Num Instance

----------- ------------ -------- ------------

  745948352 XFIREORC1 xfireorc

 

 

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

#输入文件类型,默认为html

Enter value for report_type: html

 

Type Specified:  html

 

 

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

   DB Id     Inst Num DB Name   InstanceHost

------------ -------- ------------ ------------ ------------

* 745948352    1 XFIREORC   xfireorciZ233j4mpnbZ

 

Using  745948352 for database Id

Using       1 for instance number

 

 

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed.  Pressing <return> without

specifying a number lists all completed snapshots.

 

 #列出多少天内的快照

Enter value for num_days: 1

 

Listing the last day's Completed Snapshots

 

Snap

Instance     DB Name    Snap Id    Snap Started    Level

------------ ------------ --------- ------------------ -----

xfireorc     XFIREORC       9501 21 Jun 2016 00:00   1

      9502 21 Jun 2016 01:00   1

      9503 21 Jun 2016 02:00   1

      9504 21 Jun 2016 03:00   1

      9505 21 Jun 2016 04:01   1

      9506 21 Jun 2016 05:00   1

      9507 21 Jun 2016 06:00   1

      9508 21 Jun 2016 07:00   1

      9509 21 Jun 2016 08:00   1

      9510 21 Jun 2016 09:00   1

      9511 21 Jun 2016 10:00   1

      9512 21 Jun 2016 11:00   1

      9513 21 Jun 2016 12:00   1

      9514 21 Jun 2016 13:00   1

      9515 21 Jun 2016 14:00   1

 

 

 #对应的输入编号,指定分析一个具体时间段内的快照。

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 9511

Begin Snapshot Id specified: 9511

 

Enter value for end_snap: 9512

End   Snapshot Id specified: 9512

 

 

 

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrrpt_1_9511_9512.html.  To use this name,

press <return> to continue, otherwise enter an alternative.

 #输入文件名

Enter value for report_name: report10-11

 

Using the report name report10-11

三、分析

将输出的报告,拷贝到本地进行分析。里边的内容有很多,但是真的很强大。也很易懂。

1、分析单条语句造成的Physical Reads(物理读)次数


2、分析语句占用cpu的总的时间

目录
相关文章
|
4月前
|
负载均衡 算法 关系型数据库
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
本文聚焦 MySQL 集群架构中的负载均衡算法,阐述其重要性。详细介绍轮询、加权轮询、最少连接、加权最少连接、随机、源地址哈希等常用算法,分析各自优缺点及适用场景。并提供 Java 语言代码实现示例,助力直观理解。文章结构清晰,语言通俗易懂,对理解和应用负载均衡算法具有实用价值和参考价值。
大数据大厂之MySQL数据库课程设计:揭秘MySQL集群架构负载均衡核心算法:从理论到Java代码实战,让你的数据库性能飙升!
|
6月前
|
SQL 关系型数据库 MySQL
如何优化SQL查询以提高数据库性能?
这篇文章以生动的比喻介绍了优化SQL查询的重要性及方法。它首先将未优化的SQL查询比作在自助餐厅贪多嚼不烂的行为,强调了只获取必要数据的必要性。接着,文章详细讲解了四种优化策略:**精简选择**(避免使用`SELECT *`)、**专业筛选**(利用`WHERE`缩小范围)、**高效联接**(索引和限制数据量)以及**使用索引**(加速搜索)。此外,还探讨了如何避免N+1查询问题、使用分页限制结果、理解执行计划以及定期维护数据库健康。通过这些技巧,可以显著提升数据库性能,让查询更高效流畅。
|
6月前
|
物联网 测试技术 API
时序数据库 InfluxDB 3.0 版本性能实测报告:写入吞吐量提升效果验证
TSBS 测试表明,对于少于 100 万台设备的数据集,InfluxDB OSS 3.0 的数据写入速度实际上比 InfluxDB OSS 1.8 更慢。 对于 100 万台及以上设备的数据集,InfluxDB OSS 3.0 的数据写入性能才开始超过 InfluxDB OSS 1.8。 InfluxDB OSS 3.0 的数据写入接口与 InfluxDB 1.8 并不兼容,用户无法顺利迁移。
384 7
|
7月前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
|
7月前
|
数据库
【YashanDB 知识库】误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降
**标题:误配置 SYSTEM 级别的 STATISTICS_LEVEL 参数为 ALL 导致数据库性能下降** **简介:** 数据库性能骤降至正常水平的百分之一,主要表现为大量 free buffer wait 等待事件。原因是系统级别 STATISTICS_LEVEL 被误设为 ALL。解决方法是将其恢复为默认值 TYPICAL,执行命令:`ALTER SYSTEM SET statistics_level=&#39;TYPICAL&#39; SCOPE=BOTH;` 以恢复正常性能。
|
6月前
|
存储 NoSQL MongoDB
从 MongoDB 到 时序数据库 TDengine,沃太能源实现 18 倍写入性能提升
沃太能源是国内领先储能设备生产厂商,数十万储能终端遍布世界各地。此前使用 MongoDB 存储时序数据,但随着设备测点增加,MongoDB 在存储效率、写入性能、查询性能等方面暴露出短板。经过对比,沃太能源选择了专业时序数据库 TDengine,生产效能显著提升:整体上,数据压缩率超 10 倍、写入性能提升 18 倍,查询在特定场景上也实现了数倍的提升。同时减少了技术架构复杂度,实现了零代码数据接入。本文将对 TDengine 在沃太能源的应用情况进行详解。
290 0
|
6月前
|
存储 监控 数据挖掘
消防行业如何借助时序数据库 TDengine 打造高效的数据监控与分析系统
本篇文章来自“2024,我想和 TDengine 谈谈”征文活动的优秀投稿,深入探讨了如何在消防行业中运用 TDengine 进行业务建模。文章重点介绍了如何通过 TDengine 的超级表、标签设计和高效查询功能,有效管理消防监控系统中的时序数据。作者详细阐述了实时监控、报警系统以及历史数据分析在消防行业中的应用,展示了 TDengine 在数据压缩、保留策略和分布式架构下的强大优势。
164 0
|
7月前
|
Cloud Native 关系型数据库 分布式数据库
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
世界第一!阿里云PolarDB刷新全球数据库性能及性价比记录
220 0

推荐镜像

更多