AnySQL.net » Tuning http://www.anysql.net SQLULDR2, DataCopy, DataSync, WebChart, OraMon, AUL/MyDUL, 性能优化及容量分析 Wed, 14 Jul 2010 09:27:19 +0000 en hourly 1 http://wordpress.org/?v=3.0 AIX下获得HBA卡的IO流量信息 http://www.anysql.net/dba/get-aix-hba-iostat.html http://www.anysql.net/dba/get-aix-hba-iostat.html#comments Wed, 14 Jul 2010 09:21:26 +0000 anysql http://www.anysql.net/?p=769     IO历史是调优的兵家必争之地, 然而存贮厂商对IO的性能数据接口采用了保守的态度, 不对用户免费开放, 只提供定向开发服务, 没办法只能从主机这块入手了. 在AIX下可以用scsistat小程序来实时查看HBA卡上的流量.

    在命令行不带参数运行时, 会将IO性能数据直接写在屏幕上.

[oracle@test:/home/oracle/xinloufx]scsistat.bin
2010-07-14 17:07:15,test,fscsi2,2368,32,150,148,4
2010-07-14 17:07:15,test,fscsi3,2368,48,151,148,2
2010-07-14 17:07:15,test,fscsi0,2352,32,149,147,0
2010-07-14 17:07:15,test,fscsi1,2368,32,150,148,2
2010-07-14 17:07:25,test,fscsi2,2304,32,146,144,1
2010-07-14 17:07:25,test,fscsi3,2320,32,147,145,2
2010-07-14 17:07:25,test,fscsi0,2288,80,148,143,3
2010-07-14 17:07:25,test,fscsi1,2320,48,148,145,5

    各个列的数据依次为: 时间, 主机名, 光纤通道, RBLKS, WBLKS, XFERS, XRATE, IOTIME. 可以将数据用file选项输出到文件, 然后进行数据处理.

scsistat.bin file=scsistat.dat wait=60

    上面的命令将会每分钟收集一次性能数据，并将性能数据写入到scsistat.dat文件. 画成曲线分析，将会更显效果.

    上面的曲线可用AnySQL DataReport轻松制作出来.

Relative Posts:

]]> http://www.anysql.net/dba/get-aix-hba-iostat.html/feed 0 Linux下获取IO压力数据 http://www.anysql.net/dba/get-linux-iostat.html http://www.anysql.net/dba/get-linux-iostat.html#comments Fri, 18 Jun 2010 08:16:49 +0000 anysql http://www.anysql.net/?p=765     Linux 2.6内核版本后, 在proc文件系统中, 加入了存入磁盘IO访问数据的文件diskstats, 查看文件就可以获得某一时刻的累计访问值.

$ cat /proc/diskstats
  ……
  8    0 sda 130767120 478199 2848404253 865895766 …
  8    1 sda1 58 740 1598 96 2 0 4 0 0 96 96
  8    2 sda2 4031326 3249 64502142 3693948 5273723 …
  8    3 sda3 142 3261 4030 865 538334 302764 …
  8    4 sda4 1 0 2 3 0 0 0 0 0 3 3
  8    5 sda5 57717 8304 2083594 152577 2023051 …
  8    6 sda6 3283 617 126914 18536 1965077 …
  8    7 sda7 31 1062 1348 164 0 0 0 0 0 121 164
  8    8 sda8 63475 1067 1170446 364557 1050986 …
  8    9 sda9 409 1423 4454 2141 579616 2614979 …
  8  10 sda10 30 352 1668 130 0 0 0 0 0 125 130
  ……

    在实际的编程中, 有两个问题要处理, 一个是如何找出磁盘, 并将分区过滤掉, 因为Linux会同步更新磁盘分区及磁盘的数据, 如果不加区分, 数据就会不准确, 这个可以通第2列及第3列加以区分, 第二列为16的倍数的表示是磁盘而非分区, 第三列是磁盘名字, 一般的系统中磁盘都是小写的sd开头的. 对于普通的scsi磁盘, 只要找出第二列是16的倍数, 并且第三列前两个字母是”sd”的, 就表示是真正的磁盘, 比如前面的数据中, 只能取第一行. 为什么是16的倍数, 估计和一块盘最多有16个分区有关吧.

    磁盘中, 第四列后的都是性能数据, 各列的官方解释如下.

Field  1 — # of reads completed
    This is the total number of reads completed successfully.
Field  2 — # of reads merged, field 6 — # of writes merged
    Reads and writes which are adjacent to each other may be merged for
    efficiency.  Thus two 4K reads may become one 8K read before it is
    ultimately handed to the disk, and so it will be counted (and queued)
    as only one I/O.  This field lets you know how often this was done.
Field  3 — # of sectors read
    This is the total number of sectors read successfully.
Field  4 — # of milliseconds spent reading
    This is the total number of milliseconds spent by all reads (as
    measured from __make_request() to end_that_request_last()).
Field  5 — # of writes completed
    This is the total number of writes completed successfully.
Field  7 — # of sectors written
    This is the total number of sectors written successfully.
Field  8 — # of milliseconds spent writing
    This is the total number of milliseconds spent by all writes (as
    measured from __make_request() to end_that_request_last()).
Field  9 — # of I/Os currently in progress
    The only field that should go to zero. Incremented as requests are
    given to appropriate struct request_queue and decremented as they finish.
Field 10 — # of milliseconds spent doing I/Os
    This field is increases so long as field 9 is nonzero.
Field 11 — weighted # of milliseconds spent doing I/Os
    This field is incremented at each I/O start, I/O completion, I/O
    merge, or read of these stats by the number of I/Os in progress
    (field 9) times the number of milliseconds spent doing I/O since the
    last update of this field.  This can provide an easy measure of both
    I/O completion time and the backlog that may be accumulating.

    另一个问题, 当Linux接到存贮时, 可能会有多条通路, 形成很多的虚盘, 这时不能取虚盘的性能数据, 比如连到EMC的存贮时, 第三列的名字应当为emcpower开头, 而不是sd开头了. 在Linuxmon程序中, 可以通过disk参数, 指定磁盘的前缀名字.

$ linuxmon.bin disk=emcpower
… Read RTim Writ WTim Busy Time
…  70    0  57    0    0  39
…  65    0  55    0    0  40
…  100    0  162    0    0  112
…  70    0  57    0    0  36
…  65    0  70    0    0  64
…  76    0  55    0    0  33
…  105    2  98    0    0  74
…  65    0  54    0    0  38
…  155    0  102    0    0  85
…  76    0  63    0    0  49
…  64    0  54    0    0  38
…  53    0  34    0    0  22

    如果上面的理解有问题, 欢迎指出来, 正在学习之中, 有理解错误也是难免的.

Relative Posts:

]]> http://www.anysql.net/dba/get-linux-iostat.html/feed 4 oramon新增三个性能数据 http://www.anysql.net/tools/oramon-arclog-undo-logfilesync.html http://www.anysql.net/tools/oramon-arclog-undo-logfilesync.html#comments Thu, 05 Nov 2009 11:46:13 +0000 anysql http://www.anysql.net/?p=715     自从上次加了OS的性能指标后, 已经好久没有更新oramon了, 根据最近获得的经验, 发现还是有必要加上以下三个数据: 可重用日志组数(ARCLOG), 回滚段使用(UNDO), 日志同步时长(LGFC).

    可重用日志组数指数据库中已经归档, 并且状态为不活动(INACTIVE)的联机日志的组数, 可以用于监控归档速度及日志切换速度, 并根据这个数据进行报警. 回滚段使用指的是所有回滚段占用的空间的总大小, 在OLTP数据库中, 如果UNDO表空间满了, 可能会遇到Bug, 引起数据库表空间锁的争用. 日志同步时长可以用来评价日志写出去的速度, 或Oracle面临的事务压力.

    下面是在笔记本上获得的数据库性能数据.

www.AnySQL.net  Arc Undo Lgfc
11/05-18:59:17    0  62    5
11/05-18:59:27    0  62  10
11/05-18:59:37    0  62  10
11/05-18:59:47    0  62  10
11/05-18:59:57    0  62  10
11/05-19:00:07    0  62  10
11/05-19:00:17    0  62  10
11/05-19:00:27    0  62    0
11/05-19:00:37    0  62    0
11/05-19:00:47    0  62    0
11/05-19:00:57    0  62  10

    收集了数据后, 可以根据数据轻松地增加监控点, 或者将数据显示在WebChart的图上, 以供性能或容量分析. 在真实的苛刻的环境下的应用, 会使oramon越来越成熟, 为诊断Oracle的疑难杂症提供有力的数据依据.

Relative Posts:

]]> http://www.anysql.net/tools/oramon-arclog-undo-logfilesync.html/feed 3 一次简单C程序的性能优化 http://www.anysql.net/developer/simple-c-program-tuning.html http://www.anysql.net/developer/simple-c-program-tuning.html#comments Tue, 27 Oct 2009 08:53:17 +0000 anysql http://www.anysql.net/?p=711     下面这段简单的程序, 如何优化?

#include <stdio.h>

void main ()
{
  int i;
  for (i=0;i<20000000;i++)
  {
      printf(“%012d\n”,i);
  }
}

    下午居然想到要来优化这段程序, 并且写出了更好的程序, 性能提升了30%, 从18秒提升到了12秒.

#include <stdio.h>

typedef struct _NUMERLIST
{
    int len;
    char buf[5];
} NUMBERLIST;

void printNumber(int num, NUMBERLIST numlist[])
{
    int v_num,i,j,k,pos=0;
    char tmpbuf[32];
    memset(tmpbuf,0,32);
    v_num=num;
    for(i=3;i>=0;i–)
    {
  v_num = num;
  for(k=0;k<i;k++) v_num = v_num/1000;
  v_num = v_num % 1000;
  if (v_num > 999)
      pos = pos + sprintf(tmpbuf+pos,”%03d”, v_num);
        else
  {
      memcpy(tmpbuf+pos, numlist[v_num].buf,3);
      pos = pos + 3;
  }
    }
    printf(“%s\n”, tmpbuf);
}

void main ()
{
  NUMBERLIST numlist[1000];
  int i;
  for (i=0;i<1000;i++)
  {
      sprintf(numlist[i].buf, “%03d”, i);
  }
  for (i=0;i<20000000;i++)
  {
      printNumber(i, numlist);
  }
}

    如果优化一下两个程序的IO, 采用缓冲输出, 估计第二段程序更显优势.

Relative Posts:

]]> http://www.anysql.net/developer/simple-c-program-tuning.html/feed 5 SQL执行filter条件的顺序问题 http://www.anysql.net/dba/oracle-where-filter-order.html http://www.anysql.net/dba/oracle-where-filter-order.html#comments Thu, 09 Jul 2009 03:01:27 +0000 anysql http://www.anysql.net/?p=681     SQL中不可能让Where中的所有条件都走上索引, 不能走索引的部份条件就成了表上的filter条件, 在极端情况下, filter的顺序问题会影响SQL的执行结果. 例如我们建立这样一个表, 并输入两条数据.

create table TEST_FILTER
(
    COL1 NUMBER(10) NOT NULL,
    COL2 VARCHAR2(10) NOT NULL
);
INSERT INTO TEST_FILTER VALUES (1,’A');
INSERT INTO TEST_FILTER VALUES (2,’9′);

    然后分别在不同的优化器版本(可通过修改会话级optimizer features enable参数)下执行如下SQL语句, 会发现10g下这两个SQL都能返回正确的结果, 而在9i下, 第一个SQL会报不合法的数字(Invalid Number)的错误.

SELECT * FROM TEST_FILTER
    WHERE COL1=2 AND TO_NUMBER(COL2) < 100;
SELECT * FROM TEST_FILTER
    WHERE TO_NUMBER(COL2) < 100 AND COL1=2;

    观察一下两个SQL语句的执行计划, 区别只在于filter中的顺序问题.

filter(TO_NUMBER(“COL2″)<100 AND “COL1″=2)
filter(“COL1″=2 AND TO_NUMBER(“COL2″)<100)

    当出现第一个filter顺序时, SQL执行就出错了, 而在第二个时, SQL就能正确执行. Oracle 9i中filter的顺序会按从右到左执行, 而在10g中会先执行没有函数转换的过滤条件.

Relative Posts:

]]> http://www.anysql.net/dba/oracle-where-filter-order.html/feed 2 分区表用哪个级别的统计信息? http://www.anysql.net/dba/partition-table-statistics-choose.html http://www.anysql.net/dba/partition-table-statistics-choose.html#comments Tue, 30 Jun 2009 16:09:45 +0000 anysql http://www.anysql.net/?p=678     这几天有几个分区表上的SQL执行计划不正常, 感觉上不应当, 已经设置了几个容易引起优化器选错执行计划的参数了.

ALTER SYSTEM SET OPTIMIZER_DYNAMIC_SAMPLING=0;
ALTER SYSTEM SET “_optim_peek_user_binds”=false;

    按照现行的表分析原则, 只统计了表的全局索引, 不统计表分区上的索引, 因为分区会有增减操作, 不是每个分区都有数据, 也没有定下来要经常分析表, 而是分析后如果不出问题就不再分析. 现在SQL走错了, 可能的原因有什么呢? 重新分析一下不行, 看了一下执行计划, 发现全表扫描的COST值很底, 估计是用了分区上的统计信息了, 于是手动将全局的统计信息复制到每一个分区上得以解决.

    为了得到原因, 回顾了一下当时的SQL, 发现有一个特征, 就是出问题的SQL都能定位到某个分区或某些分区, 今天就模拟了一下情况, 先只有全局统计信息. 首先用分区列范围查询, 去试了一下, 发现用的是分区级的统计信息.

SQL> select * from database_perf_statistics
  2  where day > sysdate – 100 and day < sysdate + 300;

—————————————————————-
| Id  | Operation                 | Cost (%CPU)| Pstart| Pstop |
—————————————————————-
|   0 | SELECT STATEMENT          |     3   (0)|       |       |
|*  1 |  FILTER                   |            |       |       |
|   2 |   PARTITION RANGE ITERATOR|     3   (0)|   KEY |   KEY |
|*  3 |    TABLE ACCESS FULL      |     3   (0)|   KEY |   KEY |
—————————————————————-

    然后全表扫描, 涉及所有的分区时, 用的是全局的统计信息.

SQL> select * from database_perf_statistics;
             
———————————————————-
| Id  | Operation           | Cost (%CPU)| Pstart| Pstop |
———————————————————-
|   0 | SELECT STATEMENT    |  2196   (1)|       |       |
|   1 |  PARTITION RANGE ALL|  2196   (1)|     1 |     4 |
|   2 |   TABLE ACCESS FULL |  2196   (1)|     1 |     4 |
———————————————————-

    再测试一个开包的查询条件, 发现用的也是分区的统计信息.

SQL> select * from database_perf_statistics where day > sysdate – 100;

—————————————————————
| Id  | Operation                | Cost (%CPU)| Pstart| Pstop |
—————————————————————
|   0 | SELECT STATEMENT         |     3   (0)|       |       |
|   1 |  PARTITION RANGE ITERATOR|     3   (0)|   KEY |     4 |
|*  2 |   TABLE ACCESS FULL      |     3   (0)|   KEY |     4 |
—————————————————————

    重新设置了一下各分区的统计信息, 再验证一下上面的SQL的COST值, 就确定了是这个原因引起的, 需要更改一下我们的分析策略了.

Relative Posts:

]]> http://www.anysql.net/dba/partition-table-statistics-choose.html/feed 2 oramon如何收集V$SYSTEM_EVENT数据? http://www.anysql.net/tools/oramon-system-event.html http://www.anysql.net/tools/oramon-system-event.html#comments Thu, 25 Jun 2009 07:45:29 +0000 anysql http://www.anysql.net/?p=675     基于等待事件的性能调优方法, 自从提出来后就一直很管用, 很快就替换掉了根据命中率来调优的老方法. 当然oramon也同样关于等待事件的数据, 同样以10秒钟的频率计算出10秒内发生的等待事件数据, 并用如下格式保存.

06/25-15:23:44 206-49792:416125:83, 203-18279:89351:48, 157-8436:47502:56, 21-153:1438:93, 4-397:1360:34, 195-10382:906:0, 209-128:726:56, 210-26:514:197, 372-1409:24:0, 233-111:15:1, 207-1:10:100, 234-50:0:0, 152-2:0:0,
06/25-15:23:54 206-49756:414376:83, 203-18221:90461:49, 157-10301:52368:50, 4-448:1543:34, 209-161:1007:62, 21-180:973:54, 195-10376:926:0, 210-36:566:157, 372-1343:21:0, 207-2:13:65, 233-61:0:0, 234-50:0:0, 152-3:0:0,

    每一个时间点一行, 按总等待时间降序排列各个事件的数据, 单个事件的格式为”事件号-等待次数:等待时间:平均时长”, 需要注意的是平均时长的单位是万分之一秒, 而不是千分之一秒(毫秒). 可以从目标库(不同版本会有差异)中根据事件号来查询等待事件名称.

SQL> select name from v$event_name where event#=206;

NAME
——————————————–
db file sequential read

    象上面的例子中, 可以看到平均单块读的时间为8毫秒, 这个值可以用来评价OLTP系统的存贮响应时间. 利用10秒钟的等待事件数据, 帮我们发现了Oracle中超长log file sync等待的问题, 并成功绕过这个Bug, 有利于保持数据库系统的稳定运行.

Relative Posts:

]]> http://www.anysql.net/tools/oramon-system-event.html/feed 3 oramon如何从V$SESSION收集性能数据? http://www.anysql.net/tools/oramon-session-history.html http://www.anysql.net/tools/oramon-session-history.html#comments Thu, 25 Jun 2009 05:23:12 +0000 anysql http://www.anysql.net/?p=674     当我们真正遇到数据库的负载问题时, 一般都会有大量的活动会话，处理执行或是处于等待状态, 要解决问题或找出问题的根源, 就要知道那时这些活动会话在做些什到或等待什么? 在Oracle 10g中我们可以查询V$SESSION获得这些信息, 在Oracle 9i及更早的版本中, 则需要将V$SESSION和V$SESSION_WAIT关联起来.

    oramon中就记录了这些信息, 记录的数据如下, 格式为”事件号:SQL Hash Value-会话数”. 表示在某个时间点有多少个会话在执行这个SQL, 这些会话处理什么样的等待状态.

……
10/30-20:02:37  205:2815233029:1, 372:4160993935:1
10/30-20:02:47  205:1623840268:1, 372:1569451005:1, 372:4160993935:1
10/30-20:02:57  205:374916427:1, 372:3179818757:1, 372:4160993935:1
10/30-20:03:07  205:1623840268:1, 372:860679981:1, 372:4160993935:1
10/30-20:03:17  372:4160993935:1
10/30-20:03:27  372:270817213:1, 372:4160993935:1
10/30-20:03:37  372:4160993935:1
……

    oramon每10秒执行一次查询并记录数据, 因此遇到问题时, 可以用记录的数据进行跟踪分析, 或进行事后分析. 为解决突发类的负载问题, 提供了有力的数据支持, 从我的经验中, 这些信息是非常有用的, 帮我找出了很多性能问题的根本原因, 从而切实解决了很多的问题.

Relative Posts:

]]> http://www.anysql.net/tools/oramon-session-history.html/feed 0 oramon如何从V$SYSSTAT收集性能数据? http://www.anysql.net/oracle/oramon-system-statistics.html http://www.anysql.net/oracle/oramon-system-statistics.html#comments Wed, 24 Jun 2009 00:09:10 +0000 anysql http://www.anysql.net/?p=671     Oracle系统级的性能统计数据对于解决性能问题十分有用, 因此在8, 8i, 9i, 10g, 11g的发展过程中, 性能统计项一直在不断增加. 要充分发挥这些数据的作用, 关键是如何展示这些性能数据, 以利于性能问题分析, 例如关于Oracle中物理读的一些统计值.

SQL> SELECT name, value FROM V$SYSSTAT WHERE STATISTIC# IN (54,120,56);

NAME                                VALUE
—————————— ———-
physical reads                       2373
physical reads direct                  39
physical reads direct (lob)             0

    如果只看绝对值, 是没有多少作用的, 从中看不到什么有用的信息.

20:10:24 SQL> select name,value from v$sysstat where statistic#=54;

NAME                                VALUE
—————————— ———-
physical reads                       3340

……

20:10:36 SQL> select name,value from v$sysstat where statistic#=54;

NAME                                VALUE
—————————— ———-
physical reads                       6371

    执行两次, 差值(6371 – 3340 = 3031)表示Oracle在两次收集的12秒时间(20:10:24 to 20:10:36)内总共从磁盘上读取了3031个数据块, 平均每秒钟303个块, 就很好地告诉了我们数据库的物理IO压力情况. 用oramon可以将不同的性能指标数据和时间显示成二维矩阵, 方便我们查看和分析问题.

www.AnySQL.net Exec BGets RReq Read Writ Redo …
11/27-20:15:47   54   206   15   15    0    0 …
11/27-20:15:57  196   718   41   41    0  664 …
11/27-20:16:07   64   637   19   61    0 6192 …
11/27-20:16:17   17    16    0    0    0    0 …
11/27-20:16:27   17    13    0    0    0    0 …
11/27-20:16:37   16     6    0    0    0    0 …

    用oramon工具可以较高频率(10秒一次)来收集数据, 更容易抓取瞬间的数据负载变化, 通过分析这段时间的各个性能数据, 如: Exec=执行次数, BGets=逻辑读, RReq=读请求, Read=特理读, Writ=物理写, Redo=日志量, 等等, 便可以知道负载升高的精确原因, 从而去采取有效措辞.

Relative Posts:

]]> http://www.anysql.net/oracle/oramon-system-statistics.html/feed 1 从oramon新报警中受益 http://www.anysql.net/dba/benefit-from-oramon-perf-alert.html http://www.anysql.net/dba/benefit-from-oramon-perf-alert.html#comments Fri, 22 May 2009 15:38:57 +0000 anysql http://www.anysql.net/wordpress/uncategorized/%e4%bb%8eoramon%e6%96%b0%e6%8a%a5%e8%ad%a6%e4%b8%ad%e5%8f%97%e7%9b%8a.html     依据oramon的数据进行报警, 相比以前仅有的Load Average和Active Session(上个oramon版本)的报警, 报警点更多了, 原来担心会有太多的报警扰乱DBA的生活. 但从过去的两天报警的真实情况来统计, 基本没有误报, 而是真实地发现了更多应当值得注意的问题.

    有了更多的性能数据后, 报警的内容更多了, 从最早只有Nagios的Load Average报警, 如下所示:

WARNING – load average: 9.03, 5.70, 4.36

    到老版本的oramon, 新增了Active session的信息, 如下所示:

High Active Session on xxxxxx,
05/21-10:41:01 Load 2.73, Act: 45, Enq: 0

    在最新的oramon版本时, 增加了更多的性能数据, 如下所示:

High Load on xxxxxx, 2009.05.21 10:41:01
Load 2.73, CPU:7/29/19 Swap: 1, Act: 45, Enq: 29, PQ: 0

    昨天因为Enq值过高报的警, 让我们提早注意到了应用程序中并发更新的问题, 在用户数及业务量飞速增长的情况下, 这方面要提前进行逻辑优化.

Relative Posts:

]]> http://www.anysql.net/dba/benefit-from-oramon-perf-alert.html/feed 1 用oramon的数据进行报警 http://www.anysql.net/dba/oramon-database-perf-alert.html http://www.anysql.net/dba/oramon-database-perf-alert.html#comments Thu, 21 May 2009 07:03:30 +0000 anysql http://www.anysql.net/wordpress/uncategorized/%e7%94%a8oramon%e7%9a%84%e6%95%b0%e6%8d%ae%e8%bf%9b%e8%a1%8c%e6%8a%a5%e8%ad%a6.html     对于互联网企业后台的数据库来讲, 有效的性能监控与报警是非常重要的, 一般来说数据库上的并发事务大, 任何地方出错后, 就会导至数据库进入恶性循环, 如果未及时解决, 要么数据库挂起, 要么让应用挂起, 方能得到最后解脱. 有钱的单位请专门的人员进行7×24小时监控, 专门盯着数据库主机Load的变化, 或者是安装监控程序进行5分钟数据采样, 并根据Load或CPU利用率情况进行报警, 如Nagios等.

    从实际情况看来, 专人看管和5分钟的监控都不够好, 5分钟可以重起一次一般的数据库了. 监控的频率很难选择, 监控报警的标准很难确定. 关键在于要有良好的性能数据, 及根据这些性能数据的有效报警机制. 用oramon收集Oracle的运行性能数据, 将报警机制集成到实时采集oramon数据的程序中, 就完美解决了这个事情.

    昨天用Perl重写了oramon数据采集程序, 一是要集成报警功能, 二是性能测试库不一定用Oracle, 可能会用MySQL, 以后也可以用Postgre SQL等, 还是选用脚本型语言较好. oramon以十秒的频率采集数据, 在报警时没有根据一个点的数据来确认是否报警, 而一律根据最后5个采样点的数据, 也就是接近一分钟内5个数据的平均值来判断. 经过一天的测试, 最后的报警条件设置如下.

    活动会话: 如果最近5个点的活动会话数都大于大于某个值(根据各个数据库的情况, 设置不同的值)就报警. Enq会话: 如果最近5个点的处理Enqueue等待的会话数都大于10就报警. IO等待: 如果最近5个点CPU WIO的比例值都大于40就报警. CPU使用率: 如果最近5个点CPU User的比例值都大于80就报警. 并行进程: 如果最近5个点活动并行进程的值都大于4就报警.

    利用oramon收集的数据, 可以根据很多有意义的性能数据进行报警设置, 如Swap IO情况, 如physical read, db file scatter read, 平均db file sequential read的等待时间, 还可以根据从Oracle层面计算出来的IOPS量进行报警.

    将报警机制集成在数据扫描程序中, 可以使报警变得很及时, 出现情况一分钟就可以报出来. 另外根据5个点的数据来报警, 误报的机率大大降低. 例如今天就根据Enqueue等待的报警及时发现了问题. 有这样的报警系统才能掌控数据库的运行, 才能做到心中有数, 安心睡觉.

Relative Posts:

]]> http://www.anysql.net/dba/oramon-database-perf-alert.html/feed 3 新版oramon正式上线 http://www.anysql.net/tools/deploy_new_oramon_version.html http://www.anysql.net/tools/deploy_new_oramon_version.html#comments Wed, 20 May 2009 01:06:15 +0000 anysql http://www.anysql.net/wordpress/uncategorized/%e6%96%b0%e7%89%88oramon%e6%ad%a3%e5%bc%8f%e4%b8%8a%e7%ba%bf.html     最近几周在改进oramon, 不停地在增减收集的数据点, 既要增加有用的数据, 又要去掉无用的数据, 断继续续地搞了近一个月, 今天终于将新版本oramon应用到生产环境中去了. 新版本最直接的好处是可以将更多的性能数据, 比较方便地装载到性能数据库中. 以方便第三方平台(如WebChart)来进行展示, 下面是新版本发布后, 增加的一些图形.

    CPU利用率, 包括SYS, WIO和USER, 将所有核心数据库的CPU利用率显示在一起, 进行横向比较.

    Oracle中单块读(sequential read)和多块读(scatter read)的等待次数, 将所有核心数据库的物理读等待次数显示在一起, 进行横向比较.

    Oracle中单块读(sequential read)和多块读(scatter read)的等待时间, 将所有核心数据库的物理读等待时间显示在一起, 进行横向比较.

    Oracle中数据块写(db file parallel write)和日志写(log file parallel write)的等待次数, 将所有核心数据库的物理写等待次数显示在一起, 进行横向比较.

    Oracle中数据块写(db file parallel write)和日志写(log file parallel write)的等待时间, 将所有核心数据库的物理写等待时间显示在一起, 进行横向比较.

    Oracle中单块读(db file parallel write)的平均等待时间, 将所有核心数据库的单块读平均时间显示在一起, 进行横向比较.

    Oracle中所有的读和写的等待次数累加起来当作IOPS次数, 将所有核心数据库的Oracle IOPS次数显示在一起, 进行横向比较.

    还收集了很多Oracle数据库中的其他指标, 留下几个图明天或后天再画吧.

Relative Posts:

]]> http://www.anysql.net/tools/deploy_new_oramon_version.html/feed 4 分析性能数据之二 http://www.anysql.net/dba/analyze_perf_data_two.html http://www.anysql.net/dba/analyze_perf_data_two.html#comments Sat, 09 May 2009 00:53:22 +0000 anysql http://www.anysql.net/wordpress/uncategorized/%e5%88%86%e6%9e%90%e6%80%a7%e8%83%bd%e6%95%b0%e6%8d%ae%e4%b9%8b%e4%ba%8c.html     Oracle中有很多的性能数据可以分析, 有些数据反应的不仅仅是数据库的, 而且可以反应出应用的或架构上的信息, 作为DBA应当主动分析, 并提供给相关的人员, 以协助技术决策. 比如, 应用程序中连接池的设置, 最大允许多少个连接连到数据库中?

    粗略一看, 好象DBA没有办法得到这些信息, 应当从应用日志中去统计不能获得连接或连接超时的报警信息. 在真实应用中, 大部份的数据库连接都是保持的, 也就是用了连接缓冲池, 会话不会经常断开重连, 因此可以通过持续观察应用服务器在数据库上产生的连接数来分析, 如果真实连接数持续达到了设置的最大值, 就表示需要增大最大连接数的设置了.

    用如下SQL来取得连接数据, 每5分钟取一次, 然后保存到一张表中,

select sysdate day, INSTANCE_NAME,
      machine, username, count(*) conncount
  from v$session, v$instance
  group by machine, username, instance_name

    用WebChart来显示某台机器, 最近两天或三天的连接数, 就可以看出需不需要扩大连接设置了.

    这其实很简单, 但结果是使我们的应用程序数据库连接设置有数据可依, 真实地发挥了作用.

Relative Posts:

]]> http://www.anysql.net/dba/analyze_perf_data_two.html/feed 5 分析性能数据之一 http://www.anysql.net/dba/analyze_perf_data_one.html http://www.anysql.net/dba/analyze_perf_data_one.html#comments Fri, 08 May 2009 19:01:11 +0000 anysql http://www.anysql.net/wordpress/uncategorized/%e5%88%86%e6%9e%90%e6%80%a7%e8%83%bd%e6%95%b0%e6%8d%ae%e4%b9%8b%e4%b8%80.html     Oracle中有很多的性能数据可以分析, 有些数据反应的不仅仅是数据库的, 而且可以反应出应用的或架构上的信息, 作为DBA应当主动分析, 并提供给相关的人员, 以协助技术决策. 比如, 系统中会有很多种不同类型的应用服务器, 但数据库往往是少数几个, 在进行多机房应用及数据布局时, 就需要知道各个应用服务器和数据库的交互量, 同一个库上各个不同的应用发起的SQL的百分比.

    粗略一看, 好象DBA没有办法得到这些信息, 应当从应用日志中去统计分析. 在真实应用中, 大部份的数据库连接都是保持的, 也就是用了连接缓冲池, 会话不会经常断开重连, 因此可以通过会话级的统计值(execute count)得到上面的数据. 具体过程如下, 在一个可以查数据字典的用户下, 创建一个表来保留统计值信息.

create table TMP_SESSION_EXECUTES
(
    ID NUMBER(38),
    SID NUMBER(12),
    serial# number(12),
    machine varchar2(64),
    username varchar2(30),
    execute number(38)
);

    然后创建一个序列, 来表示一次收集的ID, 如下所示:

create sequence seq_temp_sesstat;

    执行以下代码几个小时, 就可以收集到不少数据, 足以进行上述分析了.

declare
  ver number:=0;
begin
loop
  select seq_temp_sesstat.nextval into ver from dual;
  insert into TMP_SESSION_EXECUTES
  select ver, a.sid,
    a.serial#, a.machine, a.username, b.value
  from v$session a, v$sesstat b
  where a.sid=b.sid
    and b.STATISTIC#=238;
  commit;
  dbms_lock.sleep(300);
end loop;
end;
/

    上面收集到的是累计值, 要前后两个ID相减计算差量值, 可用如下SQL语句.

SELECT MACHINE, USERNAME,  SUM(EXECUTE) EXECUTE
FROM (
SELECT A.MACHINE, A.USERNAME,
  A.EXECUTE – NVL(B.EXECUTE,0) EXECUTE
FROM TMP_SESSION_EXECUTES A, TMP_SESSION_EXECUTES B
WHERE A.ID=B.ID+1
  AND A.SID=B.SID
  AND A.SERIAL#=B.SERIAL#
  AND A.MACHINE=B.MACHINE
  AND A.USERNAME=B.USERNAME
  AND A.EXECUTE > NVL(B.EXECUTE,0) )
GROUP BY MACHINE, USERNAME

    这样就得到了在某个时间段内每台机器在某个用户下的SQL执行量了, 算一下比例就是十分有用的信息.

Relative Posts:

]]> http://www.anysql.net/dba/analyze_perf_data_one.html/feed 1 用图表显示oramon数据 http://www.anysql.net/tools/display_oramon_perf_data.html http://www.anysql.net/tools/display_oramon_perf_data.html#comments Wed, 22 Apr 2009 06:30:07 +0000 anysql http://www.anysql.net/wordpress/uncategorized/%e7%94%a8%e5%9b%be%e8%a1%a8%e6%98%be%e7%a4%baoramon%e6%95%b0%e6%8d%ae.html     用WebChart来显示数据库中的数据, 是非常方便的, 因此当oramon中的数据进入数据库后, 就可以用WebChart来进行分析了, 例如某个数据库主机上CPU的数据.

    当然可以将更多的图, 例如某数据库的各个性能数据, 显示在一个页面中, 可以根据这个页面的源代码, 轻松地编写出很多个WebChart的页面, 如显示所有数据库的CPU使用情况, 进行横向比较.

    再用HTML树(Tree)做一个导航页面, 用scanomon将oramon和WebChart连接起来, 严然就是一个数据库性能分析与监控系统了, 在数据库性能分析上胜过很多的商业软件.

    在不耻努力地推动和介绍下, 有几个在集成公司的好朋友已经开始试用oramon和WebChart了.

Relative Posts:

]]> http://www.anysql.net/tools/display_oramon_perf_data.html/feed 7