最近几天的批量确认的Tuning的经历(一)

1437人阅读 评论(0) 收藏 举报

前几天开始测试批量确认的性能,作了几次测试。第一次是在800万的数量上做测试,确认3万多人大概耗时15分钟,比较满意。第二次在9700万的基础上作批量确认测试,60万人居然花了11个多小时,我faint。随后通过观察数据库的状态(我的程序主要是在存储过程处理业务逻辑,swing+oracle),根据top sql和top session中,发现对于大表A20的update占有相当大的比重,v$session_wait中,比较大的是db file sequential read,证明数据库的读取等待是核心,通过P1参数确定了热点的数据文件。另外还有一个严重的等待是log switch compeletion,说明数据库的日志切换的等待也很厉害。

第一次解决办法:

1.将redo log的数量增加,并且增大redo log的大小从50M到100M;将redo log文件从普通磁盘上转移到了磁盘阵列上。

2.修改db_file_multiblock_read_count参数,从默认的16修改为128,这样提高了每次IO的读取的block的数量,可以明显的从监控图中看到db file sequenctial read所占用的读取时间明显下降,以前大概是5分钟计算后有一次3分钟的db file sequencetial read的等待,现在变为1分钟,而且波谷明显变窄,不在触底。

3.修改SQL语句,将每个人update一次a20改为若干数据量的更新,减少了update的次数,但这样的效果似乎并不明显。

预计的解决办法:

通过这一次的调整,时间并没有减少多少,反到有些增长,从11小时提高到了13小时,faint。因为在a20上并没有作分区,打算通过使用分区、放在裸设备上再进行一次测试。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:1713379次
    • 积分:20462
    • 等级:
    • 排名:第401名
    • 原创:493篇
    • 转载:112篇
    • 译文:19篇
    • 评论:221条
    文章存档
    最新评论
    老婆