ORACLE數(shù)據(jù)庫中出現(xiàn)ora-1578錯誤怎么辦

這篇文章主要介紹了ORACLE數(shù)據(jù)庫中出現(xiàn)ora-1578錯誤怎么辦，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

測試環(huán)境中一臺裝有ORACLE數(shù)據(jù)庫的AIX小機(jī)因意外斷電而導(dǎo)致其上的oracle數(shù)據(jù)庫宕機(jī)了。由于是測試環(huán)境，安排了一個工程師過去解決了，具體是這樣解決的：首先重啟了小機(jī)服務(wù)器，啟動完后，發(fā)現(xiàn)oracle所在的/app目錄沒有mount上。然后通過smitty fs修復(fù)了一下，mount上了app，再接著啟動oracle就起來了。

 事后搜集了system.txt 系統(tǒng)日志(通過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, p_w_picpath: 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....]

又觀察另兩個文件，發(fā)現(xiàn)有較多ORA-1578報錯和DISK OPERATION ERROR。

分析：一般在進(jìn)行CLUSTER雙機(jī)切換、意外斷電或其它情況下，有時會發(fā)生某個共享盤MOUNT不上的情況，需要使用FSCK對共享盤進(jìn)行修復(fù)，然后再MOUNT.當(dāng)修復(fù)完成后，順利的話數(shù)據(jù)庫可以直接起來，否則在數(shù)據(jù)庫啟動過程中就會報出"數(shù)據(jù)塊損壞，無法啟動數(shù)據(jù)庫"的現(xiàn)象。此時，我們可以根據(jù)不同的數(shù)據(jù)塊損壞類型，檢測并修復(fù)錯誤并確定解決問題的方案。

一、數(shù)據(jù)塊損壞產(chǎn)生原因：

1． 硬件問題（磁盤控制器問題或磁盤本身故障問題）

2． 物理級的數(shù)據(jù)塊損壞（通常由前一原因造成）

3、邏輯的數(shù)據(jù)塊損壞

二、壞塊的原理分析：

Oracle的數(shù)據(jù)塊有固定的格式和結(jié)構(gòu)，分三層： Cache layer、Transaction layer和Data layer.

對數(shù)據(jù)塊進(jìn)行讀寫操作時，做一致性檢查：

–Block type

–DBA

–Scn

–Header and tail

發(fā)現(xiàn)不一致，標(biāo)記為壞塊。壞塊有兩種： 物理壞塊和邏輯壞塊。壞塊產(chǎn)生的影響：數(shù)據(jù)字典表、回滾段表、臨時段和用戶數(shù)據(jù)表和索引。

三、確定故障原因與對應(yīng)的解決辦法：

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

2、 如果報錯指向相同磁盤的不同文件，則是磁盤的問題，需要查看磁盤有無報警，LVM有無報錯等。

3、 如果指向相同磁盤的同一個文件，則可以執(zhí)行以下語句查找文件名：

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

其中，文件號與塊號在報錯日志中可以查到，如果該查詢持續(xù)指向某表或索引，則重建它們即可。

4、如果文件是SYSTEM表空間，或處于NOARCHIVELOG模式，在數(shù)據(jù)庫還在運行狀態(tài)時，EXP導(dǎo)出全部數(shù)據(jù)，重建庫，再IMP灌入新庫即可。

5、如果數(shù)據(jù)庫處于ARCHIVELOG模式，可以使用DBV校驗壞塊，然后通過RMAN來修復(fù)壞塊，成功后啟動數(shù)據(jù)庫。

   或者另一種方案

   關(guān)閉數(shù)據(jù)庫，如果不能關(guān)閉數(shù)據(jù)庫，則將相應(yīng)的數(shù)據(jù)文件脫機(jī)：

   ALTER DATABASE DATAFILE '文件名' OFFLINE；

  試著將數(shù)據(jù)文件拷貝到別的磁盤。如果拷貝失敗，則文件將丟失。

  然后STARTUP MOUNT; 

  將數(shù)據(jù)文件重命名為成功拷貝到別的磁盤的文件名

  ALTER DATABASE RENAME FILE '老路徑文件名' TO '新路徑文件名';

  ALTER DATABASE OPEN;

  RECOVER DATAFILE 文件名;

  ALTER DATABASE DATAFILE '文件名' ONLINE;

四、本例的解決辦法

 由于本案例中，數(shù)據(jù)庫有備份和歸檔且備份可用，所以使用rman命令修復(fù)壞塊

先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 /

恢復(fù)管理器: Release 10.2.0.1.0 - Production on 星期五 3月 1 15:07:14 2013

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

連接到目標(biāo)數(shù)據(jù)庫: soa (DBID=1281151392)

RMAN> blockrecover datafile 3 block 49259;

啟動 blockrecover 

使用目標(biāo)數(shù)據(jù)庫控制文件替代恢復(fù)目錄

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=187 devtype=DISK

通道 ORA_DISK_1: 正在恢復(fù)塊

通道 ORA_DISK_1: 正在指定要從備份集恢復(fù)的塊

正在恢復(fù)數(shù)據(jù)文件 049259 的塊

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

\2013_02_28\O1_MF_NNNDF_TAG201302287_3\YCS579G_.BKP

通道 ORA_DISK_1: 已從備份段 1 恢復(fù)塊

通道 ORA_DISK_1: 塊恢復(fù)完成, 用時: 00:00:02

正在開始介質(zhì)的恢復(fù)

介質(zhì)恢復(fù)完成, 用時: 00:00:05

完成 blockrecover 于 1-3-13

RMAN> exit

恢復(fù)管理器完成。

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

  COUNT(*)

----------

      3298 

壞塊修復(fù)后，并不會更新v$database_block_corruption，需要下次備份的時候更新

SQL> select * from  v$database_block_corruption;

     FILE#     BLOCK#     BLOCKS CORRUPTION_CHANGE# CORRUPTIO

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

         3     49259          1                  0 CHECKSUM

$rman target /

恢復(fù)管理器: Release 10.2.0.1.0 - Production on 星期日 3月 1 16:09:43 2013

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

連接到目標(biāo)數(shù)據(jù)庫: soa (DBID=1281151392)

RMAN> backup validate datafile 3;

啟動 backup 

使用目標(biāo)數(shù)據(jù)庫控制文件替代恢復(fù)目錄

分配的通道: ORA_DISK_1

通道 ORA_DISK_1: sid=132 devtype=DISK

通道 ORA_DISK_1: 啟動全部數(shù)據(jù)文件備份集

通道 ORA_DISK_1: 正在指定備份集中的數(shù)據(jù)文件

通道 ORA_DISK_1: 備份集已完成, 經(jīng)過時間:00:00:03

完成 backup 于 1-3-13

RMAN> exit

恢復(fù)管理器完成。

SQL> select * from  v$database_block_corruption;

未選定行

注：如果數(shù)據(jù)庫沒有備份的話，可以考慮使用dbms_repair包來補救，但是會丟數(shù)據(jù)庫。

至此數(shù)據(jù)庫恢復(fù)完成，再次重啟已正常。

感謝你能夠認(rèn)真閱讀完這篇文章，希望小編分享的“ORACLE數(shù)據(jù)庫中出現(xiàn)ora-1578錯誤怎么辦”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關(guān)注億速云行業(yè)資訊頻道，更多相關(guān)知識等著你來學(xué)習(xí)!