性能调优之redo切换频率

简介: 生产系统的一个库(负责容错处理的),目前遇到了严重的性能问题,数据量也大的出奇,一个分区表一百多个分区,blob字段达到了800多G. 查看 AWR 系统负载倒不重,但是根据反馈响应速度很慢。

生产系统的一个库(负责容错处理的),目前遇到了严重的性能问题,数据量也大的出奇,一个分区表一百多个分区,blob字段达到了800多G.

查看 AWR 系统负载倒不重,但是根据反馈响应速度很慢。


Snap Id Snap Time Sessions Cursors/Session
Begin Snap: 4512 17-Jul-13 10:00:04 24 2.0
End Snap: 4513 17-Jul-13 11:00:06 41 19.5
Elapsed:   60.03 (mins)    
DB Time:   70.09 (mins)    

Load Profile

Per Second Per Transaction
Redo size: 2,061,966.68 840,400.17
Logical reads: 28,242.96 11,511.05
Block changes: 4,749.98 1,935.96
Physical reads: 1,990.22 811.16
Physical writes: 244.15 99.51
User calls: 303.93 123.87
Parses: 80.30 32.73
Hard parses: 0.02 0.01
Sorts: 91.59 37.33
Logons: 0.04 0.02
Executes: 132.32 53.93
Transactions: 2.45  
  

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 99.67 Redo NoWait %: 99.95
Buffer Hit %: 96.06 In-memory Sort %: 100.00
Library Hit %: 99.98 Soft Parse %: 99.97
Execute to Parse %: 39.31 Latch Hit %: 97.11
Parse CPU to Parse Elapsd %: 2.80 % Non-Parse CPU: 99.69

Parse CPU to Parse Elapsd指标很低,而且memory的使用情况也只有40%,50%.
但是每秒的redo数达到了近2M.

想看看日志切换频率,但是似乎从报告中找不到明显的地方,
可以用以下sql来。填上自己需要关注的时间段。
select sequence#,first_time,nexttime,round(((first_time-nexttime)*24)*60,2) diff from (select sequence#,first_time,lag(first_time) over(order by sequence#) nexttime from v$log_history where thread#=1 and to_char(first_time,'yyyy-mm-dd')='2013-07-17')  order by sequence# desc;
 SEQ# FIRST_TIME          NEXTTIME                   DURATION(mins)
    167868 2013-07-17 10:15:37 2013-07-17 10:15:10        .45
    167867 2013-07-17 10:15:10 2013-07-17 10:14:59        .18
    167866 2013-07-17 10:14:59 2013-07-17 10:14:46        .22
    167865 2013-07-17 10:14:46 2013-07-17 10:14:32        .23
    167864 2013-07-17 10:14:32 2013-07-17 10:14:22        .17
    167863 2013-07-17 10:14:22 2013-07-17 10:14:15        .12
    167862 2013-07-17 10:14:15 2013-07-17 10:14:09         .1
    167861 2013-07-17 10:14:09 2013-07-17 07:09:19     184.83
    167860 2013-07-17 07:09:19 2013-07-17 03:01:32     247.78
可以看到在负载高的时候,日志切换极快。

查看当前的redo情况,是四组日志,每组100M,看来明显不够。
但是需要设置为多少合适呢,发现了问题,给出对应的指标值也是很重要的。
根据oracle的建议,20分钟内切换算是一个指标。跑了一个addm报告,也轻松的得到了结果,addm建议调为2048M.
oracle还估算了调优这个会节省多少时间, IMPACT : 26% impact (1099 seconds)

此外还惊喜的得到了调整cursor的建议,这个问题最近得到开发的反馈说会碰到:ORA-01000 max open cursors exceed...
看来addm确实是个好东西,但是在报告里面没有给出明显的理由。在awr报告里找cursor相关的指标

soft parsing of SQL statements was consuming significant database time.

Statistic

Begin Value

End Value

session pga memory max

15,053,354,632

15,249,597,664

session cursor cache count

383,435

386,192

session uga memory

4.4E+13

4.5E+13

opened cursors current

48

800

logons current

24

41

session uga memory max

44,030,880,616

44,314,080,728

session pga memory

13,478,131,336

13,655,531,424

给出的建议如下:

ACTION: Consider increase parameter open_cursors more then 300.

               increase parameter session_cached_cursors to 150

now parameter details:  open_cursors=300  session_cached_cursors=100

IMPACT: 3.9% impact (163 seconds)

此外还发现了一些top sql,但是没有明显的调优方向,我没有马上动手,我觉得这些需要以上的系统级配置生效以后需要做持续性的调整。

lob的调优还需要多补补。在后续章节分享。



目录
相关文章
|
3月前
|
缓存 固态存储 关系型数据库
MySQL性能优化指南:深入分析重做日志刷新到磁盘的机制
MySQL性能优化指南:深入分析重做日志刷新到磁盘的机制
|
弹性计算 网络协议 容灾
PostgreSQL 时间点恢复(PITR)在异步流复制主从模式下,如何避免主备切换后PITR恢复(备库、容灾节点、只读节点)走错时间线(timeline , history , partial , restore_command , recovery.conf)
标签 PostgreSQL , 恢复 , 时间点恢复 , PITR , restore_command , recovery.conf , partial , history , 任意时间点恢复 , timeline , 时间线 背景 政治正确非常重要,对于数据库来说亦如此,一个基于流复制的HA架构的集群,如果还有一堆只读节点,当HA集群发生了主备切换后,这些只读节点能否与新的主节点保持
1656 0
|
9月前
|
NoSQL
XLOG段文件跳号现象分析
XLOG段文件跳号现象分析
29 0
|
存储 SQL 运维
Oracle--活跃回滚段损坏故障恢复
当前数据库由活跃事务时活跃回滚段损坏无备份时处理过程。
209 0
|
网络协议 Windows
【错误集】不定时更新
文章目录 前言 一、内容 二、服务(配置文件) 2.1 DNS服务无效(文件无权
126 0
【错误集】不定时更新
|
Oracle 关系型数据库 数据库
Redo的管理与优化
Oracle优化案例
|
SQL Oracle 关系型数据库
PostgreSQL 使用逻辑decode实现异步主从切换后,时间线分歧变化量补齐、修复
PostgreSQL 使用逻辑decode实现异步主从切换后,时间线分歧变化量补齐、修复
1286 0

相关实验场景

更多