作者:eygle
出处:
http://www.eygle.com/blog日期:June 26, 2005
本文链接:
http://www.eygle.com/archives/2005/06/oracleeaoieiear.html« 使用Oracle9i的新特性Flashback Query恢复误删除数据 | Blog首页 | 《Oracle数据库性能优化》一书热销 »
平台:SunOS 5.8 Generic_108528-23 sun4u sparc SUNW,Ultra-Enterprise
数据库:8.1.5.0.0
症状:响应缓慢,应用请求已经无法返回
登陆数据库,发现redo日志组除current外都处于active状态
oracle:/oracle/oracle8>sqlplus "/ as sysdba"
SQL*Plus: Release 8.1.5.0.0 - Production on Thu Jun 23 18:56:06 2005
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to:
Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 520403 31457280 1 NO ACTIVE 1.3861E+10 23-JUN-05
2 1 520404 31457280 1 NO ACTIVE 1.3861E+10 23-JUN-05
3 1 520405 31457280 1 NO ACTIVE 1.3861E+10 23-JUN-05
4 1 520406 31457280 1 NO CURRENT 1.3861E+10 23-JUN-05
5 1 520398 31457280 1 NO ACTIVE 1.3860E+10 23-JUN-05
6 1 520399 31457280 1 NO ACTIVE 1.3860E+10 23-JUN-05
7 1 520400 104857600 1 NO ACTIVE 1.3860E+10 23-JUN-05
8 1 520401 104857600 1 NO ACTIVE 1.3860E+10 23-JUN-05
9 1 520402 104857600 1 NO ACTIVE 1.3861E+10 23-JUN-05
9 rows selected.
SQL> /
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS FIRST_CHANGE# FIRST_TIM
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ---------
1 1 520403 31457280 1 NO ACTIVE 1.3861E+10 23-JUN-05
2 1 520404 31457280 1 NO ACTIVE 1.3861E+10 23-JUN-05
3 1 520405 31457280 1 NO ACTIVE 1.3861E+10 23-JUN-05
4 1 520406 31457280 1 NO CURRENT 1.3861E+10 23-JUN-05
5 1 520398 31457280 1 NO ACTIVE 1.3860E+10 23-JUN-05
6 1 520399 31457280 1 NO ACTIVE 1.3860E+10 23-JUN-05
7 1 520400 104857600 1 NO ACTIVE 1.3860E+10 23-JUN-05
8 1 520401 104857600 1 NO ACTIVE 1.3860E+10 23-JUN-05
9 1 520402 104857600 1 NO ACTIVE 1.3861E+10 23-JUN-05
9 rows selected.
|
如果日志都处于active状态,那么显然DBWR的写已经无法跟上log switch触发的检查点。
接下来让我们检查一下DBWR的繁忙程度:
SQL> !
oracle:/oracle/oracle8>ps -ef|grep ora_
oracle 2273 1 0 Mar 31 ? 57:40 ora_smon_hysms02
oracle 2266 1 0 Mar 31 ? 811:42 ora_dbw0_hysms02
oracle 2264 1 16 Mar 31 ? 16999:57 ora_pmon_hysms02
oracle 2268 1 0 Mar 31 ? 1649:07 ora_lgwr_hysms02
oracle 2279 1 0 Mar 31 ? 8:09 ora_snp1_hysms02
oracle 2281 1 0 Mar 31 ? 4:22 ora_snp2_hysms02
oracle 2285 1 0 Mar 31 ? 9:40 ora_snp4_hysms02
oracle 2271 1 0 Mar 31 ? 15:57 ora_ckpt_hysms02
oracle 2283 1 0 Mar 31 ? 5:37 ora_snp3_hysms02
oracle 2277 1 0 Mar 31 ? 5:58 ora_snp0_hysms02
oracle 2289 1 0 Mar 31 ? 0:00 ora_d000_hysms02
oracle 2287 1 0 Mar 31 ? 0:00 ora_s000_hysms02
oracle 2275 1 0 Mar 31 ? 0:04 ora_reco_hysms02
oracle 21023 21012 0 18:52:59 pts/65 0:00 grep ora_
|
DBWR的进程号是2266。
使用Top命令观察一下:
oracle:/oracle/oracle8>top
last pid: 21145; load averages: 3.38, 3.45, 3.67 18:53:38
725 processes: 711 sleeping, 1 running, 10 zombie, 3 on cpu
CPU states: 35.2% idle, 40.1% user, 9.4% kernel, 15.4% iowait, 0.0% swap
Memory: 3072M real, 286M free, 3120M swap in use, 1146M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
11855 smspf 1 59 0 1355M 1321M cpu/0 19:32 16.52% oracle
2264 oracle 1 0 0 1358M 1316M run 283.3H 16.36% oracle
11280 oracle 1 13 0 1356M 1321M sleep 79.8H 0.77% oracle
6957 smspf 15 29 10 63M 14M sleep 107.7H 0.76% java
17393 smspf 1 30 0 1356M 1322M cpu/1 833:05 0.58% oracle
29299 smspf 5 58 0 8688K 5088K sleep 18.5H 0.38% fee_ftp_get
21043 oracle 1 43 0 3264K 2056K cpu/9 0:01 0.31% top
20919 smspf 17 29 10 63M 17M sleep 247:02 0.29% java
25124 smspf 1 58 0 16M 4688K sleep 0:35 0.25% smif_status_rec
8086 smspf 5 23 0 21M 13M sleep 41.1H 0.24% fee_file_in
16009 root 1 35 0 4920K 3160K sleep 0:03 0.21% sshd2
25126 smspf 1 58 0 1355M 1321M sleep 0:26 0.20% oracle
2266 oracle 1 60 0 1357M 1317M sleep 811:42 0.18% oracle
11628 smspf 7 59 0 3440K 2088K sleep 0:39 0.16% sgip_client_ltz
26257 smspf 82 59 0 447M 178M sleep 533:04 0.15% java
|
我们注意到,2266号进程消耗的CPU不过0.18%,显然并不繁忙,那么瓶颈就很可能在IO上。
使用IOSTAT工具检查IO状况。
gqgai:/home/gqgai>iostat -xn 3
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
......
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t6d0
1.8 38.4 32.4 281.0 0.0 0.7 0.0 16.4 0 29 c0t10d0
1.8 38.4 32.4 281.0 0.0 0.5 0.0 13.5 0 27 c0t11d0
24.8 61.3 1432.4 880.1 0.0 0.5 0.0 5.4 0 26 c1t1d0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 9.1 0 0 hurraysms02:vold(pid238)
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
........
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t6d0
0.3 8.3 0.3 47.0 0.0 0.1 0.0 9.2 0 8 c0t10d0
0.0 8.3 0.0 47.0 0.0 0.1 0.0 8.0 0 7 c0t11d0
11.7 65.3 197.2 522.2 0.0 1.6 0.0 20.5 0 100 c1t1d0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 hurraysms02:vold(pid238)
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
........
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t6d0
0.3 13.7 2.7 68.2 0.0 0.2 0.0 10.9 0 12 c0t10d0
0.0 13.7 0.0 68.2 0.0 0.1 0.0 9.6 0 11 c0t11d0
11.3 65.3 90.7 522.7 0.0 1.5 0.0 19.5 0 99 c1t1d0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 hurraysms02:vold(pid238)
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
........
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t6d0
0.0 8.0 0.0 42.7 0.0 0.1 0.0 9.3 0 7 c0t10d0
0.0 8.0 0.0 42.7 0.0 0.1 0.0 9.1 0 7 c0t11d0
11.0 65.7 978.7 525.3 0.0 1.4 0.0 17.7 0 99 c1t1d0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 hurraysms02:vold(pid238)
extended device statistics
r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device
........
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 c0t6d0
0.3 87.7 2.7 433.7 0.0 2.2 0.0 24.9 0 90 c0t10d0
0.0 88.3 0.0 436.5 0.0 1.8 0.0 19.9 0 81 c0t11d0
89.0 54.0 725.4 432.0 0.0 2.1 0.0 14.8 0 100 c1t1d0
0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0 0 hurraysms02:vold(pid238)
|
我们注意到,存放数据库的主要卷c1t1d0的繁忙程度始终处于99~100,而写速度却只有500K/s左右,这个速度是极为缓慢的。
(%b percent of time the disk is busy (transactions in progress)
Kw/s kilobytes written per second)
根据我们的常识T3盘阵通常按Char写速度可以达到10M/s左右,以前测试过一些Tpcc指标,可以参考:
Use bonnie to Test system IO speed。
而正常情况下的数据库随机写通常都在1~2M左右,显然此时的磁盘已经处于不正常状态,经过确认的确是硬盘发生了损坏,Raid5的Group中损坏了一块硬盘。
经过更换以后系统逐渐恢复正常。
Posted by eygle at June 26, 2005
分享到:
相关推荐
Oracle DG下修改redo log和standby redo log日志大小.txt
确认原有Redo Log日志组不再处于活跃状态后,可以执行删除操作: ```sql ALTER DATABASE DROP LOGFILE GROUP 1; ALTER DATABASE DROP LOGFILE GROUP 2; ALTER DATABASE DROP LOGFILE GROUP 3; ALTER DATABASE DROP ...
在Oracle数据库管理中,调整redo日志文件大小是一项重要的维护工作,这直接影响到数据库的性能与稳定性。本文将深入探讨如何在Oracle环境中修改redo日志文件的大小,以及这一操作的具体步骤和注意事项。 ### 一、...
Oracle数据库管理系统是全球广泛使用的大型关系型数据库系统之一,尤其在企业级应用中占据着重要地位。本课程“Oracle数据库管理--初级”旨在为初学者提供一个基础的Oracle DBA(数据库管理员)学习路径,帮助他们...
在Oracle数据库环境中,当面临丢失全部数据库文件及所有redo log文件的情况时,恢复过程变得非常复杂,因为这涉及到了数据库的全部数据文件、重做日志文件、控制文件甚至SPFILE。在这种极端情况下,通常只能依赖于...
SGA是数据库进程共享的一块内存区域,包含如数据缓冲区、redo log buffer、共享SQL区等组件,用于缓存数据和存储执行过程的信息。而PGA则属于每个单独的数据库进程,用于存储私有数据和执行计划。 在实验环节,课程...
Oracle重做日志(Redo Log)是Oracle数据库的一个关键组成部分,它记录了数据库的所有操作变化,保证了数据的完整性和一致性。在了解Oracle redo log之前,首先需要了解几个基础概念: 1. 数据库变化历史:Oracle ...
- **Redolog Files**: 用于记录事务操作的日志文件,对于数据库的恢复至关重要。 - **Instance**: 实例是一个数据库在内存中的表现形式,它由系统全局区(SGA)和后台进程(Background Processes)组成。 - **SGA...
1. **Redo Log文件**:是Oracle数据库中用于存储所有事务更改记录的一组文件。这些文件对于数据库的完整性和一致性至关重要。 2. **Redo Buffer**:位于SGA(System Global Area)中的一个内存区域,用于暂存即将写入...
- **Redo log 文件**:检查重做日志文件的状态和大小,防止日志切换过慢影响性能。 - **归档Redo log 文件**:确认归档日志模式下,归档日志的生成和清除正常,防止日志空间耗尽。 - **数据文件**:检查数据文件...
下面将详细介绍如何利用Oracle的重做日志(Redo Log)和归档日志(Archived Logs)来分析数据库的变更记录。 ### Oracle日志系统概览 Oracle数据库的日志系统主要包括重做日志(Redo Log)和归档日志(Archived ...
Redo Log Buffer的状态对于理解数据库的重做日志活动非常重要,可以通过以下查询来获得相关信息: ```sql SELECT member, status, sequence#, bytes/(1024*1024) "Size in MB" FROM v$logfile WHERE status = '...
redo log,或者称为重做日志,是数据库系统中用于记录事务对数据的更改操作的重要组件,特别是对于保证数据的一致性和恢复性至关重要。在Oracle、MySQL等数据库系统中,redo log扮演着不可或缺的角色。标题和描述...
MySQL数据库中的redo log(重做日志)是数据库高可用、事务提交等关键功能的核心组件之一。它的主要作用是在系统发生故障时,能够确保数据库能够恢复到故障点之前的正确状态,确保数据的持久性和一致性。在MySQL中,...
总结来说,Oracle数据库redo文件的恢复涉及多个层面的策略,需要根据具体状况灵活应对,包括理解redo的状态、数据库的归档设置、脏块状态以及数据库运行状态,结合Oracle的恢复工具和命令,如归档日志应用、不正常...
- 在整个过程中,应密切检查数据库的日志文件(redo logs, alert logs, trace files),以获取更多关于错误的线索。这些日志可能会提供导致ORA-00600错误的具体操作或事件。 5. **数据文件和控制文件的检查**: -...
- 归档日志是联机重做日志(Online Redo Log)的备份,当一个redo log group切换时,如果数据库配置为归档模式,那么当前日志组的内容会被复制到归档日志中。 - 归档日志有两种模式:非归档模式(Noarchivelog)和...
2. **增加日志组数量**:增加redo log group的数量,可以在一组日志文件写满时无缝切换到下一组,这样可以分散I/O负载并提高系统并发处理能力。每个日志组应保持相同大小,以确保均衡使用。 在给出的部分内容中,...
Oracle 数据库联机日志文件丢失处理方法包括使用命令清空日志组、alter database clear logfile group 命令和 alter database clear unarchived logfile group 命令等方法。这些方法可以帮助我们恢复丢失的联机日志...
Redo日志(Redo Log)是数据库事务日志的重要组成部分,它主要用于事务的恢复和数据的一致性保证。在MySQL数据库中,InnoDB存储引擎使用Redo日志来记录事务性的操作,并通过日志缓冲区(Redo Log Buffer)来缓存Redo...