如何对数据库进行监控检查

oracle自动工作负载库(AWR):采集与性能相关的统计数据,并从统计的数据中导出性能量度,以跟踪数据库潜在的问题。

如何生成oracle数据库的自动负载库报告。

手工生成一份oracle数据库的快照:

SQL>execute dbms_workload_repository.create_snapshot();

oracle自动负载库的sql脚本一般位于$ORACLE_HOME/rdbms/admin目录下,文件名为awrrpt.sql,如下图所示:

执行oracle自动工作负载库的sql脚本:

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

其中“@”表示在oracle的命令窗口中执行SQL脚本,而“?”表示$ORACLE_HOME目录。

根据提示输入自动负载库的类型,默认是html格式,可以输入txt格式。

选择要分析哪天的数据库性能,如果输入1,将会列出当天的数据库快照和对应的时间点,如果输入2,将会列出最近两天的数据库快照和对应的时间点,以此类推。咱们这里输入2,如下图:

选择一个开始和一个结束的快照号,这两个快照号的时间段内数据库不能重启过。

按提示进行操作,生成报告后输入:exit退出数据库。

SQL>exit

使用ftp工具将linux下的报告传到windows下打开。

oracle数据库自动负载报告如下:

WORKLOAD REPOSITORY report for

DB Name


DB Id


Instance


Inst num


Startup Time


Release


RAC


ORCL


1384228360


orcl


1


17-Sep-14 11:09


11.2.0.1.0


NO

Host Name


Platform


CPUs


Cores


Sockets


Memory (GB)


localhost.localdomain


Linux IA (32-bit)


2


2


1


1.98

 

Snap Id


Snap Time


Sessions


Cursors/Session


Begin Snap:


13


17-Sep-14 12:00:57


27


1.6


End Snap:


14


17-Sep-14 13:00:23


29


1.3


Elapsed:

 
59.43 (mins)

   

DB Time:

 
1.22 (mins)

   
Report Summary

Cache Sizes

 

Begin


End

   

Buffer Cache:


324M


324M


Std Block Size:


8K


Shared Pool Size:


144M


144M


Log Buffer:


5,012K

Load Profile

 

Per Second


Per Transaction


Per Exec


Per Call


DB Time(s):


0.0


0.2


0.01


0.07


DB CPU(s):


0.0


0.0


0.00


0.01


Redo size:


737.2


7,917.8

   

Logical reads:


22.2


237.9

   

Block changes:


2.8


30.2

   

Physical reads:


0.2


2.5

   

Physical writes:


0.2


2.6

   

User calls:


0.3


3.3

   

Parses:


2.1


22.3

   

Hard parses:


0.0


0.4

   

W/A MB processed:


0.0


0.2

   

Logons:


0.1


0.6

   

Executes:


3.6


38.5

   

Rollbacks:


0.0


0.0

   

Transactions:


0.1

     

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %:


99.99


Redo NoWait %:


100.00


Buffer Hit %:


98.95


In-memory Sort %:


100.00


Library Hit %:


96.22


Soft Parse %:


98.22


Execute to Parse %:


42.02


Latch Hit %:


99.99


Parse CPU to Parse Elapsd %:


100.95


% Non-Parse CPU:


92.74

Shared Pool Statistics

 

Begin


End


Memory Usage %:


73.00


79.85


% SQL with executions>1:


56.93


82.26


% Memory for SQL w/exec>1:


51.68


71.33

Top 5 Timed Foreground Events

Event


Waits


Time(s)


Avg wait (ms)


% DB time


Wait Class


DB CPU

 
15

 
19.90

 

log file sync


67


2


23


2.09


Commit


db file sequential read


28


0


2


0.09


User I/O


switch logfile command


1


0


38


0.05


Administrative


asynch descriptor resize


7,534


0


0


0.03


Other

Host CPU (CPUs: 2 Cores: 2 Sockets: 1)

Load Average Begin


Load Average End


%User


%System


%WIO


%Idle


0.05


0.00


0.3


0.2


0.6


95.2

Instance CPU

%Total CPU


%Busy CPU


%DB time waiting for CPU (Resource Manager)


0.3


7.3


0.0

Memory Statistics

 

Begin


End


Host Mem (MB):


2,026.8


2,026.8


SGA use (MB):


484.0


484.0


PGA use (MB):


49.4


53.8


% Host Mem used for SGA+PGA:


26.32


26.53

oracle数据库的自动诊断工具(ADDM

oracle数据库自动诊断报告脚本一般位于$ORACLE_HOME/rdbms/admin/目录下,文件名为addmrpt.sql

如何生成一个oracle数据库自动诊断报告:

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

按要求一步一步执行即可,最后通过ftp工具将报告传到windows下进行查看。

oracle自动诊断文档内容如下:

ADDM Report for Task ‘TASK_53‘

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

Analysis Period

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

AWR snapshot range from 13 to 14.

Time period starts at 17-SEP-14 12.00.58 PM

Time period ends at 17-SEP-14 01.00.24 PM

Analysis Target

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

Database ‘ORCL‘ with DB ID 1384228360.

Database version 11.2.0.1.0.

ADDM performed an analysis of instance orcl, numbered 1 and hosted at

localhost.localdomain.

Activity During the Analysis Period

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

Total database time was 73 seconds.

The average number of active sessions was .02.

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

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

There are no findings to report.

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

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

Additional Information

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

Miscellaneous Information

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

There was no significant database activity to run the ADDM.

注意:报告的具体说明,详见书。

时间: 2024-10-12 16:13:00

如何对数据库进行监控检查的相关文章

如何对oracle数据库进行监控检查

sqlplus '/as sysdba' 手动生成一个oracle数据库的快照 execute dbbms_workload_repository.create_snapshot(); 执行自动工作负载库的sql脚本 @?/rdbms/admin/awrrpt.sql; @表示在数据库中执行sql脚本,?指$ORACLE_HOME目录 接着输入想要分析的时间数字即可 默认导出的是html格式 生成自动诊断报告 sqlplus / as sysdba @?/rdbms/admin/addmrpt.

5. SQL Server数据库性能监控 - 当前请求

对于在线运行的系统,当前数据库性能监控,通常监视以下几点: (1) 是否有阻塞 (Blocking); (2) 是否有等待 (Waiting),阻塞就是锁 (Lock) 等待; (3) 是否运行时间过长(Long running): (4) 是否有死锁 (Deadlock): sys.dm_exec_query_stats之类,等一些统计性的信息,通常不作为实时告警内容,而是在性能优化时,作为参考. 一. 阻塞/等待/长时间运行 1. SQL Server 2005 及以后版本检查 SELECT

2. SQL Server数据库状态监控 - 错误日志

无论是操作系统 (Unix 或者Windows),还是应用程序 (Web 服务,数据库系统等等) ,通常都有自身的日志机制,以便故障时追溯现场及原因.Windows Event Log和 SQL Server Error Log就是这样的日志, PS: SQL Server 中的错误日志 (Error Log) 类似于 Oracle中的alert 文件. 一. 错误日志简介 1. Windows事件日志与SQL Server 错误日志 Windows事件日志中,应用程序里的SQL Server和

zabbix实现mysql数据库的监控(三)

上面一章“zabbix实现mysql数据库的监控(二)”使用MPM来监控mysql,但是遇到安装问题始终解决不了,这里改用percona-monitoring-plugins进行zabbxi上监控mysql数据库了. percona-monitoring-plugins的详细介绍请见:https://www.percona.com/software/mysql-tools/percona-monitoring-plugins 一.环境准备 php开发环境搭建 下载percona-monitori

关于数据库死锁的检查方法

关于数据库死锁的检查方法 一.        数据库死锁的现象程序在执行的过程中,点击确定或保存按钮,程序没有响应,也没有出现报错. 二.        死锁的原理当对于数据库某个表的某一列做更新或删除等操作,执行完毕后该条语句不提交,另一条对于这一列数据做更新操作的语句在执行的时候就会处于等待状态,此时的现象是这条语句一直在执行,但一直没有执行成功,也没有报错. 三.        死锁的定位方法通过检查数据库表,能够检查出是哪一条语句被死锁,产生死锁的机器是哪一台.1)用dba用户执行以下语

金蝶K3无法创建数据库,请检查目录的错误的解决办法。

无法创建数据库!请检查目录C:\XXX\DATA是否存在,以及系统空间是否充足,或SQL Server服务的启动用户不具备<K3ERP\DBFILE>文件夹的写权限,请修改Windows服务中SQL Server服务的启动用户为Power User组以上的成员. 分析:1.安装路径下的[K3Erp]文件是否有Everyone 权限. 2.确认在安装服务器时,[数据库服务部件是否安装]. 文件夹右键属性没有"安全"选项卡 打开"我的电脑" => 工具

Oracle 数据库健康状态检查

数据库健康状态检查 使用utl指令.statspack.awr来检查数据库的健康状态 前提: > show parameter time_ timed_statistics; NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ timed_statistics boolean TRUE 1:utl ##在8i之前只有这个方式,当然在后续的版本中还是有这个功能

数据库与监控安全

面试题 (数据库与监控_安全篇)选择(每题1分)1.SQL server数据库超级管理员为( )A:Admin B:SaC:sys D:root 2.在SQL语言中,条件"BETWEEN 20 AND 30"表示年龄在20到30之间,且( )a)包括20岁和30岁 b)不包括20岁和30岁c)包括20岁不包括30岁 d)不包括20岁包括30岁 3.为了使索引键的值在基本表中唯一,在建立索引语句中应使用保留字( )a) UNIQUE b) COUNTc) DISDINCT d) UNIO

Lepus搭建企业级数据库全方位监控系统

前言 Lepus(天兔)数据库企业监控系统是一套由专业DBA针对互联网企业开发的一款专业.强大的企业数据库监控管理系统,企业通过Lepus可以对数据库的实时健康和各种性能指标进行全方位的监控.目前已经支持MySQL.Oracle.MongoDB.Redis数据库的全面监控. Lepus可以在数据库出现故障或者潜在性能问题时,根据用户设置及时将数据库的异常进行报警通知到数据库管理员进行处理和优化,帮助企业解决数据库性能监控问题,及时发现性能和瓶颈,避免由数据库潜在问题造成的直接经济损失. Lepu