11.2.0.3单实例数据库性能极具下降，导致业务停掉百分之八十

caolilin_24

刘大，客户目前有一套数据库，11.2.0.3.0，进去由于业务量突长，目前数据库性能很低，客户反映入库很慢，并且客户没有使用连接池，高峰期连接数在400左右，数据库Process设置为1000。
附件中，一份是3月26号收集的awr报告，从awr报告中发现没有关闭审计，看到审计对客户的影响很大

Elapsed Time (s)        Executions         Elapsed Time per Exec (s)         %Total        %CPU        %IO        SQL Id        SQL Module        SQL Text
853,472.42        41,462        20.58        45.75        0.18        0.51        4vs91dcv7u1p6
JDBC Thin Client         insert into sys.aud$( sessioni...

昨天晚上建议客户关闭审计，今天早上7点-9点，高峰期间客户反映数据库比昨天还要慢…我搜集了awr报告，从报告中看到，
Top 5 Timed Foreground Events
Event        Waits        Time(s)        Avg wait (ms)        % DB time        Wait Class
Disk file operations I/O        1,663        571,294        343532        84.62        User I/O
read by other session        977        79,973        81856        11.85        User I/O
DB CPU                 17,851                 2.64         
db file sequential read        14,936        6,050        405        0.90        User I/O
db file scattered read        3,109        1,607        517        0.24        User I/O

系统主要等待发生在 Disk file operations I/O  ，该等待事件的描述如下 oracle event 'disk file operations i/o'

Disk file operations I/O This event is used to wait for disk file operations (for example, open, close, seek, and resize).
由此，初步怀疑导致07：00 –09：00 时间段性能问题的原因如下：
1，  昨晚数据库关闭，重起后，数据库内存缓冲区被清空，所有数据都需要从磁盘读取。
2，  存储 I/O 性能问题。

测了一下存储性能，（存储工程师检查存储 sun 6180 ，结果是正常）测试结果如下：

Dd 一个 2G 的文件到存储用时： 55 秒
root@m5000a # date;dd  if=/dev/zero  of=/global/myds/tteesstt/test_20130327.tst  bs=1024  count=2000000;date
Wed Mar 27 10:56:36 CST 2013
2000000+0 records in
2000000+0 records out
Wed Mar 27 10:57:31 CST 2013
root@m5000a # ls -l /global/myds/tteesstt/test_20130327.tst
-rw-r--r--   1 root     root     2048000000 Mar 27 10:57 /global/myds/tteesstt/test_20130327.tst

本地到存储复制：用时：71 秒
root@m5000a # df -k
Filesystem            kbytes    used   avail capacity  Mounted on
/dev/md/dsk/d10      60509964 26023668 33881197    44%    /
/devices                   0       0       0     0%    /devices
ctfs                       0       0       0     0%    /system/contract
proc                       0       0       0     0%    /proc
mnttab                     0       0       0     0%    /etc/mnttab
swap                 72742536    2232 72740304     1%    /etc/svc/volatile
objfs                      0       0       0     0%    /system/object
sharefs                    0       0       0     0%    /etc/dfs/sharetab
fd                         0       0       0     0%    /dev/fd
swap                 72740776     472 72740304     1%    /tmp
swap                 72788736   48432 72740304     1%    /var/run
/dev/md/dsk/d60       850350    3670  795659     1%    /global/.devices/node@2
/dev/md/dsk/d30       850350    3671  795658     1%    /global/.devices/node@1
/dev/md/myds/dsk/d100
                     500877398 142398642 353469983    29%    /global/myds
root@m5000a # du -sk /usr
4196305 /usr
root@m5000a # cd /global/myds
root@m5000a # mkdir tteesstt
root@m5000a # cd ttee*
root@m5000a # date; cp /*.dmp . ;date
Wed Mar 27 10:22:39 CST 2013
Wed Mar 27 10:23:50 CST 2013
root@m5000a # ls -l /*.dmp
-rw-r--r--   1 root     root     2669667328 Dec  6  2010 /exprepairs.dmp

本地到/tmp复制：用时：13 秒
root@m5000a # date ; cp /*.dmp /tmp ;date
Wed Mar 27 10:59:08 CST 2013
Wed Mar 27 10:59:21 CST 2013
root@m5000a # ls -l /tmp
total 5214992
-rw-r--r--   1 root     root       61310 Aug 15  2012 1.JPG
-rw-r--r--   1 root     root      104013 Aug 15  2012 2.JPG
-rw-r--r--   1 root     root      114648 Aug 15  2012 3.JPG
-rw-r--r--   1 root     root       97307 Aug 15  2012 4.JPG
-rw-r--r--   1 root     root     2669667328 Mar 27 10:59 exprepairs.dmp
drwxr-xr-x   2 noaccess noaccess     177 Aug  2  2012 hsperfdata_noaccess
drwxr-xr-x   2 root     root         238 Aug  2  2012 hsperfdata_root

本地到本地复制：用时：48 秒
root@m5000a # date;cp /exprepairs.dmp /exprepairs.dmp1 ;date
Wed Mar 27 11:02:35 CST 2013
Wed Mar 27 11:03:23 CST 2013
root@m5000a #

刘大，回请您多多指教，目前数据库的瓶颈在哪里呢？
ps：附件有2份awr，3月26号为开启审计，3月27号为关闭审计以后，高峰时段。

caolilin_24

用户程序是用vc开发的，采用的是短连接：每一步业务操作都是要先连接dbs，然后操作业务，最后断开dbs。例如：查询，购气分别是一个业务。每买一个用户一次气就涉及这两个业务。这种连接方式问题很大吗？

lgang403

联机日志文件太小或组数少

26856649

先改长连接吧，呵呵

sheep_yang678

4wastu58a8jfn        SELECT ROWID from t_ic_userfile where card_id = '0167401507'这种sql是怎么执行2000秒的？

bal

目录是否有满的，还有为何有这么多 TNS-12547: TNS:lost contact

gavintgh

有没有blocking? 发现日志文件数据数太少，考虑增加日志组和日志数量。。。考虑enable ODM, 另外做个AWR DIFF report..坐等专家

dla001

还是应该查查IO，很慢。 监视下OS的各项指标。nmon,osw 都行。如果平时就有这些监视，排查问题会方便很多。

dla001

我家的入门级别存储：
date;dd if=/dev/zero of=/database/001.test bs=1024 count=2000000;date
2013年 03月 27日 星期三 18:43:09 CST
2000000+0 records in
2000000+0 records out
2048000000 bytes (2.0 GB) copied, 8.0727 seconds, 254 MB/s
2013年 03月 27日 星期三 18:43:17 CST

你的存储肯定不正常。

Maclean Liu(刘相兵

11.2.0.3 建议找个空闲时段 测测IO性能到底如何

可以通过下面的过程测试：
11g新特性之IO校准(IO Calibration)
http://www.askmaclean.com/archiv ... io-calibration.html