ORACLE資料庫一次意外宕機的分析處理實記(ora-1578)

來源:互聯網
上載者:User

  一個安靜的下午,測試環境中一台裝有ORACLE資料庫的AIX小機因意外斷電而導致其上的oracle資料庫宕機了。由於是測試環境,安排了一個工程師過去解決了,具體是這樣解決的:首先重啟了小機伺服器,啟動完後,發現oracle所在的/app目錄沒有mount上。然後通過smitty fs修複了一下,mount上了app,再接著啟動oracle就起來了。

 事後搜集了system.txt 系統日誌(通過errpt -a獲得)和alert_soa.log以及oracle的追蹤記錄檔trc,分析trc日誌看到如下:

 /app/oracle/product/10.2.0/admin/soa/bdump/soa_mmon_307366.trc

Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

ORACLE_HOME = /app/oracle/product/10.2.0

System name: AIX

Node name: data2

Release: 3

Version: 5

Machine: 00CE993C4C00

Instance name: soa

Redo thread mounted by this instance: 1

Oracle process number: 11

Unix process pid: 307366, image: oracle@data2 (MMON)

*** 2013-03-01 14:06:10.308

*** SERVICE NAME:(SYS$BACKGROUND) 2013-03-01 14:06:10.212

*** SESSION ID:(161.1) 2013-03-01 14:06:10.212

Hex dump of (file 3, block 49259)

Dump of memory from 0x07000000C5934000 to 0x07000000C5936000

7000000C5934000 06A20000 00C0C06B 0178F614 00000104  [.......k.x......]

7000000C5934010 45A30000 010A0025 0000224D 0178F614  [E......%.."M.x..]

7000000C5934020 00000000 1F023200 00C0C069 00010003  [......2....i....]

又觀察另兩個檔案,發現有較多ORA-1578報錯和DISK OPERATION ERROR。

分析:一般在進行CLUSTER雙機切換、意外斷電或其它情況下,有時會發生某個共用盤MOUNT不上的情況,需要使用FSCK對共用盤進行修複,然後再MOUNT.當修複完成後,順利的話資料庫可以直接起來,否則在資料庫啟動過程中就會報出"資料區塊損壞,無法啟動資料庫"的現象。此時,我們可以根據不同的資料區塊損壞類型,檢測並修複錯誤並確定問題的解決方案。

 

一、資料區塊損壞產生原因:

1. 硬體問題磁碟控制卡問題或磁碟本身故障問題)

2. 物理級的資料區塊損壞通常由前一原因造成)

3、邏輯的資料區塊損壞

二、壞塊的原理分析:

Oracle的資料區塊有固定的格式和結構,分三層: Cache layer、Transaction layer和Data layer.

對資料區塊進行讀寫操作時,做一致性檢查:

–Block type

–DBA

–Scn

–Header and tail

發現不一致,標記為壞塊。壞塊有兩種: 物理壞塊和邏輯壞塊。壞塊產生的影響:資料字典表、復原段表、臨時段和使用者資料表和索引。

 

三、確定故障原因與對應的解決辦法:

1、查看alert.log檔案中,還有無其它ORA-的錯誤,如果報錯指向不同磁碟的檔案,則是磁碟控制卡的問題,查看V$DATAFILE,看有哪些檔案位於該控制器下,需要尋找磁碟控制卡(一般控制器有兩個A控和B控)是否正常。

2、 如果報錯指向相同磁碟的不同檔案,則是磁碟的問題,需要查看磁碟有無警示,LVM有無報錯等。

3、 如果指向相同磁碟的同一個檔案,則可以執行以下語句尋找檔案名稱:

SELECT SEGMENT_NAME,SEGMENT_TYPE FROM DBA_EXTENTS WHERE FILE_ID=<檔案號> AND <塊號> BETWEEN BLOCK_ID AND BLOCK_ID+BLOCKS-1;

其中,檔案號與塊號在報錯日誌中可以查到,如果該查詢持續指向某表或索引,則重建它們即可。

4、如果檔案是SYSTEM資料表空間,或處於NOARCHIVELOG模式,在資料庫還在運行狀態時,EXP匯出全部資料,重建庫,再IMP灌入新庫即可。

5、如果資料庫處於ARCHIVELOG模式,可以使用DBV校正壞塊,然後通過RMAN來修複壞塊,成功後啟動資料庫。

   或者另一種方案

   關閉資料庫,如果不能關閉資料庫,則將相應的資料檔案離線:

   ALTER DATABASE DATAFILE '檔案名稱' OFFLINE;

  試著將資料檔案拷貝到別的磁碟。如果拷貝失敗,則檔案將丟失。

  然後STARTUP MOUNT; 

  將資料檔案重新命名為成功拷貝到別的磁碟的檔案名稱

  ALTER DATABASE RENAME FILE '老路徑檔案名稱' TO '新路徑檔案名稱';

  ALTER DATABASE OPEN;

  RECOVER DATAFILE 檔案名稱;

  ALTER DATABASE DATAFILE '檔案名稱' ONLINE;

四、本例的解決辦法

 由於本案例中,資料庫有備份和歸檔且備份可用,所以使用rman命令修複壞塊

先DBV校正壞塊

$show parameter  db_block_size
$select BYTES/2048 from v$datafile where FILE#=3;
$dbv file=/app/oracle/product/10.2.0/oradata/soa/user01.dbf blocksize=8192

$rman target /

復原管理員: Release 10.2.0.1.0 - Production on 星期五 3月 1 15:07:14 2013

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

串連到目標資料庫: soa (DBID=1281151392)

RMAN> blockrecover datafile 3 block 49259;

啟動 blockrecover 

使用目標資料庫控制檔案替代恢複目錄

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=187 devtype=DISK

通道 ORA_DISK_1: 正在恢複塊

通道 ORA_DISK_1: 正在指定要從備份組恢複的塊

正在恢複資料檔案 049259 的塊

通道 ORA_DISK_1: 正在讀取備份段ORACLE\FLASH_RECOVERY_AREA\DB01\BACKUPSET

\2013_02_28\O1_MF_NNNDF_TAG201302287_3\YCS579G_.BKP

通道 ORA_DISK_1: 已從備份段 1 恢複塊

通道 ORA_DISK_1: 塊恢複完成, 用時: 00:00:02

正在開始介質的恢複

介質恢複完成, 用時: 00:00:05

完成 blockrecover 於 1-3-13

RMAN> exit

復原管理員完成。

SQL> select count(*) from buffer.t;

  COUNT(*)

----------

      3298 

壞塊修複後,並不會更新v$database_block_corruption,需要下次備份的時候更新

SQL> select * from  v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO

---------- ---------- ---------- ------------------ ---------

         3     49259          1                  0 CHECKSUM

$rman target /

復原管理員: Release 10.2.0.1.0 - Production on 星期日 3月 1 16:09:43 2013

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

串連到目標資料庫: soa (DBID=1281151392)

RMAN> backup validate datafile 3;

啟動 backup 

使用目標資料庫控制檔案替代恢複目錄

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=132 devtype=DISK

通道 ORA_DISK_1: 啟動全部資料檔案備份組

通道 ORA_DISK_1: 正在指定備份組中的資料檔案

通道 ORA_DISK_1: 備份組已完成, 經過時間:00:00:03

完成 backup 於 1-3-13

RMAN> exit

復原管理員完成。

SQL> select * from  v$database_block_corruption;

未選定行

註:如果資料庫沒有備份的話,可以考慮使用dbms_repair包來補救,但是會丟資料庫。

至此資料庫恢複完成,再次重啟已正常。

本文出自 “滴水穿石” 部落格,謝絕轉載!

相關文章

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.