数据库性能检查指导方案 - Part I

数据|数据库|性能

数据库性能检查指导方案

 

Author: Kamus

Date:2004-9

 

在系统稳定之后,应该按照本指导方案每个月检查一次产品数据库。

该指导方案适用于Oracle9i数据库,因为有些脚本在9i中才可以运行。

检查方式均为以sysdba身份登录数据库以后在SQLPLUS中执行命令脚本(每小节的“检查方法”部分有详细的命令脚本)。

登陆数据库的命令:

sqlplus “sys/password as sysdba”

 

一.内存性能评估

在内存性能评估的时候,我们使用内存性能指数(MPI, Memory Performance Index),下表列出了MPI中的各项指数,这个评分系统并不意味着对内存的使用和分配的全方位评估,而只是代表一个晴雨表,反映当前系统内存的使用和分配状况。

 

MPI指数

分类

所需等级

最高分

缓冲区命中率(Buffer Cache)

>98%

30

数据字典命中率(Dictionary Cache)

>98%

30

库缓存命中率(Library Cache)

>98%

30

内存中的排序(Sort in Memory)

>98%

30

空闲的数据缓冲区比例

10-25%

30

使用最多的前10个SQL占用的内存

<5%

60

是否已经调整使用最多的前25个SQL

30

是否尝试固定高速缓存中经常使用的对象

10

MPI指数

总分

250

 

1. 缓冲区命中率

显示了对于数据总读取量而言,非磁盘读取(缓冲区命中)的百分比。当然,十分高的命中率并不代表数据库性能一定优良,也有可能是糟糕的SQL引起了大量的缓冲区读操作,只有在已经调整过首要的查询之后,这个命中率才能更好地反映数据库性能。

 

检查方法:

select (1 - (sum(decode(name, 'physical reads', value, 0)) /
       (sum(decode(name, 'db block gets', value, 0)) +
       sum(decode(name, 'consistent gets', value, 0))))) * 100
       "Hit Ratio"
  from v$sysstat;

 

评估准则:

等级

分数

<90%

0

90-94%

10

95-98%

20

>98%

30

 

2. 数据字典命中率

显示了对数据字典和其它对象的内存读操作的百分比。

 

检查方法:

select (1 - (sum(getmisses) / sum(gets))) * 100 "Hit Ratio"
  from v$rowcache;

 

评估准则:

等级

分数

<85%

0

86-92%

10

92-98%

20

>98%

30

 

3. 库缓存命中率

显示了对SQL和PL/SQL对象的内存读操作的百分比。同样注意,很高的命中率并不总是反映数据库性能优秀。

 

检查方法:

select sum(pins) / (sum(pins) + sum(reloads)) * 100 "Hit Ratio"
  from v$librarycache;

 

评估准则:

等级

分数

<90%

0

90-94%

10

94-98%

20

>98%

30

 

4. 内存中的排序

根据初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE的值,用户的排序操作可能在内存中执行,也可能在临时表空间中执行。这个检查用以显示在内存中排序占总排序的百分比。

 

检查方法:

select a.value "Disk Sorts",
       b.value "Memory Sorts",
       round((100 * b.value) /
             decode((a.value + b.value), 0, 1, (a.value + b.value)),
             2) "Pct Memory Sorts"
  from v$sysstat a, v$sysstat b
 where a.name = 'sorts (disk)'
   and b.name = 'sorts (memory)';

 

评估准则:

等级

分数

<90%

0

90-94%

10

94-98%

20

>98%

30

 

5. 空闲的数据缓冲区比例

空闲的记录数除以X$BH表中的记录总数(即所分配的数据块缓冲区的总数)得到的空闲缓冲区百分比。同样注意,拥有众多空闲缓冲区的数据库不一定是最佳环境,因为可能是缓冲区设置过大,浪费内存。

 

检查方法:

select decode(state,
              0,
              'FREE',
              1,
              decode(lrba_seq, 0, 'AVAILABLE', 'BEING USED'),
              3,
              'BEING USED',
              state) "Block Status",
       count(*)
  from x$bh
 group by decode(state,
                 0,
                 'FREE',
                 1,
                 decode(lrba_seq, 0, 'AVAILABLE', 'BEING USED'),
                 3,
                 'BEING USED',
                 state);

 

评估准则:

等级

分数

<5%

0

5-19%

30

20-25%

20

>25%

0

 

 

6. 最浪费内存的前10个语句占全部内存读取量的比例

通常一个没有优化系统中,10个最常用的SQL语句的访问量会占到整个系统中内存读操作的50%以上。这些SQL是最需要进行优化的部分,也是优化工作中优先级很高的部分。

 

检查方法:

select sum(pct_bufgets)
  from (select rank() over(order by buffer_gets desc) as rank_bufgets,
               to_char(100 * ratio_to_report(buffer_gets) over(), '999.99') pct_bufgets
          from v$sqlarea)
 where rank_bufgets < 11;

 

评估准则:

等级

分数

<5%

60

5-19%

50

20-25%

30

>25%

0

 

7. 调整前25个最浪费内存的语句

在没有调整的情况下,绝大多数系统中,访问量占前25位的语句的内存读操作将占用整个系统所有内存读操作的75%,对这部分语句进行调整是至关重要的。这部分脚本用于获得访问量占前25位的SQL语句。

 

检查方法:

set serveroutput on size 1000000
declare
  top25 number;
  text1 varchar2(4000);
  x     number;
  len1  number;
  cursor c1 is
    select buffer_gets, substr(sql_text, 1, 4000)
      from v$sqlarea
     order by buffer_gets desc;
begin
  dbms_output.put_line('Gets' || '     ' || 'Text');
  dbms_output.put_line('--------' || ' ' || '---------------');
  open c1;
  for i in 1 .. 25 loop
    fetch c1
      into top25, text1;
    dbms_output.put_line(rpad(to_char(top25), 9) || ' ' ||
                         substr(text1, 1, 66));
    len1 := length(text1);
    x    := 66;
    while len1 > x - 1 loop
      dbms_output.put_line('"        ' || substr(text1, x, 66));
      x := x + 66;
    end loop;
  end loop;
end;
/

 

评估准则:

本部分没有评估准则,需要开发人员或者DBA去确认在这25个SQL中属于应用系统的语句是否都已经作过调优。

 

8. 固定缓存对象

尝试在内存中固定(pin)经常使用的对象,包括表,存储过程等。

检索需要在共享池中要求大于100K连续空间的对象:

select *
  from v$db_object_cache
 where sharable_mem > 100000
   and type in ('PACKAGE', 'PACKAGE BODY', 'PROCEDURE', 'FUNCTION');

 

考察返回的结果,确认是否需要pin到共享池中,返回结果中的KEPT字段如果是YES,那么表示该对象已经固定在了共享池中,为NO,则表示还没有固定。

如果需要固定,使用下面的语句:

exec dbms_shared_pool.keep('SYS.STANDARD');            

 

数据库默认安装的时候没有创建dbms_shared_pool包,所以需要先创建该包。

cd $ORACLE_HOME/rdbms/admin

sqlplus “/ as sysdba”

@dbmspool.sql

 

如果我们要固定表,那么可以在创建表的时候或者修改表属性时使用CACHE关键字,将表放置到Buffer Cache的LRU列表的MRU端。通常我们需要对于较小的但是频繁使用的表进行这种操作。

alter table table_name cache;

我们也可以将需要频繁使用的表放置到另外一个独立的Buffer Cache中,比如KEEP池。这种操作可以使这些表的数据不至于很快被清除出Default Buffer Cache。

alter table table_name storage (buffer pool keep);

 

评估准则:

本部分没有评估准则,需要开发人员或者DBA在系统分析以后谨慎执行。

 

二.存储性能评估

三.Statspack报表中需要首先查看的十项内容

 

 

本文参考:

Oracle9i Performance Tuning Tips & Techniques - Richard J.Niemiec

Oracle9i Database Concepts - tahiti.oracle.com

Oracle9i Database Reference - tahiti.oracle.com

 

时间: 2024-11-02 04:12:43

数据库性能检查指导方案 - Part I的相关文章

数据库性能检查指导方案 - Part II

数据|数据库|性能     存储性能评估 在存储性能评估的时候,我们使用磁盘性能指数(DPI, Disk Performance Index),下表列出了DPI中的各项指数,这个评分系统并不意味着对磁盘的使用和分配的全方位评估,而只是代表一个晴雨表,反映当前磁盘的使用和分配上是否存在需要改进或者注意的地方.   MPI指数 分类 所需等级 最高分 调整表和索引 是 30 表的行连接问题 无 30 分离关键的Oracle文件 是 30 回滚段的平衡   30 临时段的平衡   30 使用最多的前1

oracle数据库性能优化方案精髓整理收集回顾

oracle数据库性能优化总体法则: 一.减少数据访问(减少硬盘房访问次数) 二.返回更少的数据(减少网络传输或磁盘访问) 三.减少交互次数(减少网络传输) 四.减少服务器开销(减少cpu及内存开销) 五.利用更多的资源(增加资源) ===================具体说明================= 一.减少数据访问(减少硬盘房访问次数) 1.减少数据访问 1.1.创建并使用正确的索引 索引会大大增加DML(增删改)的开销[合理的索引会大大提高效率100倍.1000倍,但不合理的索

SQL Server数据库性能的优化

server|数据|数据库|性能|优化 编者按:数据库性能优化和数据库管理系统密切相关,不同的数据库管理系统在具体操作上有很大不同.继本报连续在2003年第48期.49期上刊登<Sybase数据库性能调优>和<Oracle服务器性能调整攻略>,分别讨论了Sybase和Oracle数据库管理系统以后,本期我们将具体介绍SQL Server数据库的性能优化方法. 数据库是企业信息的核心,其应用水平的高低直接影响到企业管理水平.选择了一个高性能的数据库产品不等于就有一个好的数据库应用系统

阿里云数据库CloudDBA智慧解决数据库性能优化和问题诊断难题

背景 我要申请CloudDBA免费体验     阿里云数据库为何推出CloudDBA?问题诊断(trouble shooting) 和 性能优化(performance tunning) 一直都是数据库领域的专业问题,需要资深DBA的专业技能才能胜任解决,但这样的人才是稀缺的,无法及时满足大部分的企业紧急需求.如果有一款产品能够在大多数情况下,客户借助它非常迅速的找出数据库性能隐患点.排查出问题症结所在,这将无疑协助客户解决燃眉之急,可以大大降低风险和提高效率.        先来分析下为什么数

15年老司机的DPM数据库性能分析产品研发之路

本文根据DBAplus社群第87期线上分享整理而成.   讲师介绍  邹德裕 轻维软件首席专家   DBAplus社群联合发起人,OraZ产品作者.Oracle OCM. 15年运维管理经验,在数据库诊断.故障排除.优化.架构设计等方面具有丰富的经验.   主题简介: 1.运维中常见的场景及对应解决案例 2.解密DPM数据库性能分析平台   本次我给大家带来的主题分享为<15年老司机的DPM数据库性能分析产品研发之路>.   我将通过Oracle在实际生产中常见的运维场景及问题处理案例,解析如

阿里云推出CloudDBA,解决数据库性能优化和问题诊断难题

问题诊断(trouble shooting) 和 性能优化(performance tunning) 一直都是数据库领域的专业问题,需要资深DBA的专业技能才能胜任解决,但这样的人才是稀缺的,无法及时满足大部分的企业紧急需求.如果有一款产品能够在大多数情况下,用户借助它能非常迅速的找出数据库性能隐患点.排查出问题症结所在,这将无疑协助用户解决燃眉之急,可以大大降低业务风险和提高效率. 在上周发布性能超越Aurora的自研关系型数据库POLARDB之后,阿里云数据库团队又在9月28日带来一款集阿里

阿里云推出CloudDBA,解数据库性能优化难题

本文讲的是阿里云推出CloudDBA,解数据库性能优化难题[IT168 资讯]问题诊断(trouble shooting) 和 性能优化(performance tunning) 一直都是数据库领域的专业问题,需要资深DBA的专业技能才能胜任解决,但这样的人才是稀缺的,无法及时满足大部分的企业紧急需求.如果有一款产品能够在大多数情况下,用户借助它能非常迅速的找出数据库性能隐患点.排查出问题症结所在,这将无疑协助用户解决燃眉之急,可以大大降低业务风险和提高效率. 在上周发布性能超越Aurora的自

《Oracle数据库性能优化方法论和最佳实践》——1.7 Oracle性能优化的神话和误区

1.7 Oracle性能优化的神话和误区 Oracle性能优化工作是Oracle数据库科学最为神秘莫测的领域,自然也就会流传着各种传言和八卦.本书最主要的目的就是真正使Oracle性能优化成为一门严谨的科学,使任何阅读并且理解本书内容的读者可以比较简单地完成Oracle性能优化工作,使自己在其他人面前成为"巫师"或"神秘的对象".1.7.1 艺术和科学 从百度.Google等网站搜索"性能优化艺术",会出现大量的条目,部分Oracle性能优化的图

MySQL数据库的高可用方案总结_Mysql

高可用架构对于互联网服务基本是标配,无论是应用服务还是数据库服务都需要做到高可用.虽然互联网服务号称7*24小时不间断服务,但多多少少有一些时候服务不可用,比如某些时候网页打不开,百度不能搜索或者无法发微博,发微信等.一般而言,衡量高可用做到什么程度可以通过一年内服务不可用时间作为参考,要做到3个9的可用性,一年内只能累计有8个小时不可服务,而如果要做到5个9的可用性,则一年内只能累计5分钟服务中断.所以虽说每个公司都说自己的服务是7*24不间断的,但实际上能做到5个9的屈指可数,甚至根本做不到