首頁 資料庫 mysql教程 ORACLE数据库一次意外宕机的分析处理实记(ora-1578)

ORACLE数据库一次意外宕机的分析处理实记(ora-1578)

Jun 07, 2016 pm 05:41 PM

一个安静的下午,测试环境中一台装有ORACLE数据库的AIX小机因意外断电而导致其上的oracle数据库宕机了。由于是测试环境,安排了一个工程师过去解决了,具体是这

  一个安静的下午,测试环境中一台装有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包来补救,但是会丢数据库。

至此数据库恢复完成,再次重启已正常。

本文出自 “滴水穿石” 博客,谢绝转载!

,香港虚拟主机
本網站聲明
本文內容由網友自願投稿,版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容,請聯絡admin@php.cn

熱AI工具

Undresser.AI Undress

Undresser.AI Undress

人工智慧驅動的應用程序,用於創建逼真的裸體照片

AI Clothes Remover

AI Clothes Remover

用於從照片中去除衣服的線上人工智慧工具。

Undress AI Tool

Undress AI Tool

免費脫衣圖片

Clothoff.io

Clothoff.io

AI脫衣器

Video Face Swap

Video Face Swap

使用我們完全免費的人工智慧換臉工具,輕鬆在任何影片中換臉!

熱工具

記事本++7.3.1

記事本++7.3.1

好用且免費的程式碼編輯器

SublimeText3漢化版

SublimeText3漢化版

中文版,非常好用

禪工作室 13.0.1

禪工作室 13.0.1

強大的PHP整合開發環境

Dreamweaver CS6

Dreamweaver CS6

視覺化網頁開發工具

SublimeText3 Mac版

SublimeText3 Mac版

神級程式碼編輯軟體(SublimeText3)

與MySQL中使用索引相比,全表掃描何時可以更快? 與MySQL中使用索引相比,全表掃描何時可以更快? Apr 09, 2025 am 12:05 AM

全表掃描在MySQL中可能比使用索引更快,具體情況包括:1)數據量較小時;2)查詢返回大量數據時;3)索引列不具備高選擇性時;4)複雜查詢時。通過分析查詢計劃、優化索引、避免過度索引和定期維護表,可以在實際應用中做出最優選擇。

可以在 Windows 7 上安裝 mysql 嗎 可以在 Windows 7 上安裝 mysql 嗎 Apr 08, 2025 pm 03:21 PM

是的,可以在 Windows 7 上安裝 MySQL,雖然微軟已停止支持 Windows 7,但 MySQL 仍兼容它。不過,安裝過程中需要注意以下幾點:下載適用於 Windows 的 MySQL 安裝程序。選擇合適的 MySQL 版本(社區版或企業版)。安裝過程中選擇適當的安裝目錄和字符集。設置 root 用戶密碼,並妥善保管。連接數據庫進行測試。注意 Windows 7 上的兼容性問題和安全性問題,建議升級到受支持的操作系統。

說明InnoDB全文搜索功能。 說明InnoDB全文搜索功能。 Apr 02, 2025 pm 06:09 PM

InnoDB的全文搜索功能非常强大,能够显著提高数据库查询效率和处理大量文本数据的能力。1)InnoDB通过倒排索引实现全文搜索,支持基本和高级搜索查询。2)使用MATCH和AGAINST关键字进行搜索,支持布尔模式和短语搜索。3)优化方法包括使用分词技术、定期重建索引和调整缓存大小,以提升性能和准确性。

InnoDB中的聚類索引和非簇索引(次級索引)之間的差異。 InnoDB中的聚類索引和非簇索引(次級索引)之間的差異。 Apr 02, 2025 pm 06:25 PM

聚集索引和非聚集索引的區別在於:1.聚集索引將數據行存儲在索引結構中,適合按主鍵查詢和範圍查詢。 2.非聚集索引存儲索引鍵值和數據行的指針,適用於非主鍵列查詢。

mysql:簡單的概念,用於輕鬆學習 mysql:簡單的概念,用於輕鬆學習 Apr 10, 2025 am 09:29 AM

MySQL是一個開源的關係型數據庫管理系統。 1)創建數據庫和表:使用CREATEDATABASE和CREATETABLE命令。 2)基本操作:INSERT、UPDATE、DELETE和SELECT。 3)高級操作:JOIN、子查詢和事務處理。 4)調試技巧:檢查語法、數據類型和權限。 5)優化建議:使用索引、避免SELECT*和使用事務。

mysql 和 mariadb 可以共存嗎 mysql 和 mariadb 可以共存嗎 Apr 08, 2025 pm 02:27 PM

MySQL 和 MariaDB 可以共存,但需要謹慎配置。關鍵在於為每個數據庫分配不同的端口號和數據目錄,並調整內存分配和緩存大小等參數。連接池、應用程序配置和版本差異也需要考慮,需要仔細測試和規劃以避免陷阱。在資源有限的情況下,同時運行兩個數據庫可能會導致性能問題。

mysql用戶和數據庫的關係 mysql用戶和數據庫的關係 Apr 08, 2025 pm 07:15 PM

MySQL 數據庫中,用戶和數據庫的關係通過權限和表定義。用戶擁有用戶名和密碼,用於訪問數據庫。權限通過 GRANT 命令授予,而表由 CREATE TABLE 命令創建。要建立用戶和數據庫之間的關係,需創建數據庫、創建用戶,然後授予權限。

RDS MySQL 與 Redshift 零 ETL 集成 RDS MySQL 與 Redshift 零 ETL 集成 Apr 08, 2025 pm 07:06 PM

數據集成簡化:AmazonRDSMySQL與Redshift的零ETL集成高效的數據集成是數據驅動型組織的核心。傳統的ETL(提取、轉換、加載)流程複雜且耗時,尤其是在將數據庫(例如AmazonRDSMySQL)與數據倉庫(例如Redshift)集成時。然而,AWS提供的零ETL集成方案徹底改變了這一現狀,為從RDSMySQL到Redshift的數據遷移提供了簡化、近乎實時的解決方案。本文將深入探討RDSMySQL零ETL與Redshift集成,闡述其工作原理以及為數據工程師和開發者帶來的優勢。

See all articles