【故障处理】DG环境主库丢失归档情况下数据文件的恢复

【故障处理】DG环境主库丢失归档情况下数据文件的恢复

 BLOG文档结构图

wps50E2.tmp 

 

 前言部分

 

2.1  导读和注意事项

各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~

① BBED的编译

② BBED修改文件头让其跳过归档从而可以ONLINE(重点)

 OS命名格式转换为ASM的命名格式

④ DG环境中备库丢失数据文件的情况下的处理过程(重点)

⑤ 数据文件OFFLINE后应立即做一次RECOVER操作

⑥ BBED环境中kscnwrp的使用

⑦ 查询表空间的大小,表空间大小为空,数据文件大小为空的情况

 

  Tips

① 本文在itpubhttp://blog.itpub.net/26736162)、博客园(http://www.cnblogs.com/lhrbest)和微信公众号(xiaomaimiaolhr)有同步更新

② 文章中用到的所有代码,相关软件,相关资料请前往小麦苗的云盘下载(http://blog.itpub.net/26736162/viewspace-1624453/

③ 若网页文章代码格式有错乱,推荐使用360浏览器,也可以下载pdf格式的文档来查看,pdf文档下载地址:http://blog.itpub.net/26736162/viewspace-1624453/,另外itpub格式显示有问题,也可以去博客园地址阅读

④ 本篇BLOG中命令的输出部分需要特别关注的地方我都用灰色背景和粉红色字体来表示,比如下边的例子中,thread 1的最大归档日志号为33thread 2的最大归档日志号为43是需要特别关注的地方;而命令一般使用黄色背景和红色字体注;对代码或代码输出部分的注释一般采用蓝色字体表示

  List of Archived Logs in backup set 11

  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time

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

  1    32      1621589    2015-05-29 11:09:52 1625242    2015-05-29 11:15:48

  1    33      1625242    2015-05-29 11:15:48 1625293    2015-05-29 11:15:58

  2    42      1613951    2015-05-29 10:41:18 1625245    2015-05-29 11:15:49

  2    43      1625245    2015-05-29 11:15:49 1625253    2015-05-29 11:15:53

[ZHLHRDB1:root]:/>lsvg -o

T_XLHRD_APP1_vg

rootvg

[ZHLHRDB1:root]:/>

00:27:22 SQL> alter tablespace idxtbs read write;

====2097152*512/1024/1024/1024=1G

本文如有错误或不完善的地方请大家多多指正,ITPUB留言或QQ皆可,您的批评指正是我写作的最大动力。

2.2  相关参考文章连接

BBED

 

【推荐】 【BBED】 SYSTEM文件头损坏的恢复(4)

http://blog.itpub.net/26736162/viewspace-2084329/

【推荐】 【BBED】 sys.bootstrap$ 对象的恢复

http://blog.itpub.net/26736162/viewspace-2083621/

【推荐】 【BBED】丢失归档文件情况下的恢复

http://blog.itpub.net/26736162/viewspace-2079337/

【推荐】 【BBED】编译及基本命令(1)

http://blog.itpub.net/26736162/viewspace-2075216/

【BBEDbbed常用命令

http://blog.itpub.net/26736162/viewspace-2123465/

 

 故障分析及解决过程

 

3.1  故障环境介绍

 

项目

源库

DG

db 类型

RAC

RAC

db version

11.2.0.3.7

11.2.0.3.7

db 存储

ASM

ASM

OS版本及kernel版本

AIX 64位 7.1.0.0

AIX 64位 7.1.0.0

关系

主备库为RAC+RAC的物理DG环境

 

3.2  故障发生现象及报错信息

今天查询一套DG环境的表空间大小的时候,发现一个表空间的返回值为空,很奇怪,起初我以为是自己的脚本问题,可是这个脚本是自己写的,而且用了很长时间的了,还花了几分钟的时间又仔细审核了一下脚本,没发现有什么不对的地方。

查询表空间大小的脚本:

set pagesize 9999 line 9999

col TS_Name format a30

WITH WT1 AS

(SELECT TS.TABLESPACE_NAME,

         DF.ALL_BYTES,

         DECODE(DF.TYPE,

                'D',

                NVL(FS.FREESIZ, 0),

                'T',

                DF.ALL_BYTES - NVL(FS.FREESIZ, 0)) FREESIZ,

         DF.MAXSIZ,

         TS.BLOCK_SIZE,

         TS.LOGGING,

         TS.FORCE_LOGGING,

         TS.CONTENTS,

         TS.EXTENT_MANAGEMENT,

         TS.SEGMENT_SPACE_MANAGEMENT,

         TS.RETENTION,

         TS.DEF_TAB_COMPRESSION,

         DF.TS_DF_COUNT,

         TS.BIGFILE,

         TS.STATUS

    FROM DBA_TABLESPACES TS,

         (SELECT 'D' TYPE,

                 TABLESPACE_NAME,

                 COUNT(*) TS_DF_COUNT,

                 SUM(BYTES) ALL_BYTES,

                 SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES)) MAXSIZ

            FROM DBA_DATA_FILES D

           GROUP BY TABLESPACE_NAME

          UNION ALL

          SELECT 'T',

                 TABLESPACE_NAME,

                 COUNT(*) TS_DF_COUNT,

                 SUM(BYTES) ALL_BYTES,

                 SUM(DECODE(MAXBYTES, 0, BYTES, MAXBYTES))

            FROM DBA_TEMP_FILES D

           GROUP BY TABLESPACE_NAME) DF,

         (SELECT TABLESPACE_NAME, SUM(BYTES) FREESIZ

            FROM DBA_FREE_SPACE

           GROUP BY TABLESPACE_NAME

          UNION ALL

          SELECT TABLESPACE_NAME, SUM(D.BLOCK_SIZE * A.BLOCKS) BYTES

            FROM GV$SORT_USAGE A, DBA_TABLESPACES D

           WHERE A.TABLESPACE = D.TABLESPACE_NAME

           GROUP BY TABLESPACE_NAME) FS

   WHERE TS.TABLESPACE_NAME = DF.TABLESPACE_NAME

     AND TS.TABLESPACE_NAME = FS.TABLESPACE_NAME(+))

SELECT (SELECT A.TS#

          FROM V$TABLESPACE A

         WHERE A.NAME = UPPER(T.TABLESPACE_NAME)) TS#,

       T.TABLESPACE_NAME TS_NAME,

       ROUND(T.ALL_BYTES / 1024 / 1024) TS_SIZE_M,

       ROUND(T.FREESIZ / 1024 / 1024) FREE_SIZE_M,

       ROUND((T.ALL_BYTES - T.FREESIZ) / 1024 / 1024) USED_SIZE_M,

       ROUND((T.ALL_BYTES - T.FREESIZ) * 100 / T.ALL_BYTES, 3) USED_PER,

       ROUND(MAXSIZ / 1024 / 1024 / 1024, 3) MAX_SIZE_G,

       ROUND(DECODE(MAXSIZ, 0, TO_NUMBER(NULL), (T.ALL_BYTES - FREESIZ)) * 100 /

             MAXSIZ,

             3) USED_PER_MAX,

       ROUND(T.BLOCK_SIZE) BLOCK_SIZE,

       T.LOGGING,

       T.BIGFILE,

       T.STATUS,

       T.TS_DF_COUNT

  FROM WT1 T

UNION ALL

SELECT TO_NUMBER('') TS#,

       'ALL TS:' TS_NAME,

       ROUND(SUM(T.ALL_BYTES) / 1024 / 1024, 3) TS_SIZE_M,

       ROUND(SUM(T.FREESIZ) / 1024 / 1024) FREE_SIZE_M,

       ROUND(SUM(T.ALL_BYTES - T.FREESIZ) / 1024 / 1024) USED_SIZE_M,

       ROUND(SUM(T.ALL_BYTES - T.FREESIZ) * 100 / SUM(T.ALL_BYTES), 3) USED_PER,

       ROUND(SUM(MAXSIZ) / 1024 / 1024 / 1024) MAX_SIZE,

       TO_NUMBER('') "USED,% of MAX Size",

       TO_NUMBER('') BLOCK_SIZE,

       '' LOGGING,

       MAX(T.BIGFILE),

       MAX(T.STATUS),

       TO_NUMBER('') TS_DF_COUNT

  FROM WT1 T

ORDER BY TS#;

 结果如下图:

wps50E3.tmp

因为表空间是ONLINE的,若是OFFLINE的话,结果自然为空,由于只有一个数据文件,那就看看数据文件的状态:

SELECT * FROM v$datafile d WHERE d.FILE#=64;

wps50E4.tmp 

果然数据文件是64,数据文件为OFFLINE状态,而且去备库查看的时候数据文件也是OFFLINE的。这里有一个LAST_TIME需要注意,日志为2015421号,而现在都2016921号了,看来是很久很久很久没有用这个数据文件了。好吧,很久没有写BLOG了,今天就以这个案例为主,说说其修复过程把。

3.2.1  健康检查报告

一、 运行

用自己的健康检查报告看一下能否发现这个问题呢?

wps50F5.tmp 

wps50F6.tmp 

跑完之后,生成的报告在当前目录,报告的目录大概如下所示:

巡检服务概要

数据库总体概况

数据库基本信息

数据库大小

资源使用情况

组件和特性

参数文件

所有的初始化参数

关键的初始化参数

隐含参数

spfile文件内容

Statistics Level

表空间情况

表空间状况信息

闪回空间使用情况

临时表空间使用情况

Undo表空间使用情况

表空间扩展状况

数据文件状况

控制文件

ASM磁盘监控

ASM磁盘使用情况

ASM磁盘组使用情况

ASM磁盘组参数配置情况

ASM实例

JOB情况

作业运行状况

数据库job报错信息

 

巡检服务明细

RMAN信息

RMAN备份状况

RMAN配置情况

RMAN所有备份

RMAN所有备份详情

控制文件备份

spfile文件备份

RMAN归档文件备份

数据库闪回

归档信息

归档日志设置

归档日志生成情况

归档日志占用率

近7天日志切换频率分析

每天日志切换的量

日志组大小

SGA信息

SGA使用情况

SGA配置信息

SGA建议配置

SGA动态组件

PGA TARGET 建议配置

文件IO信息

文件IO分析

文件IO时间分析

全表扫描情况

排序情况

SQL监控

逻辑读TOP10SQL

物理读TOP10SQL

执行时间TOP10SQL

执行次数TOP10SQL

解析次数TOP10SQL

版本TOP10SQL语句

内存TOP10SQL语句

DISK_SORT严重的SQL

垃圾SQLRUNNING_11G

垃圾SQLRUNNING_10G

LAST快照中SQL情况

LAST快照中执行时间最长SQL

执行时间最长SQL

执行时间最长的SQL报告

闪回归档

闪回归档配置

开启了闪回归档的表

闪回归档空间

DG

DG库配置情况

DG库运行情况

主库DG进程

主库standby日志

备库日志应用情况

 

数据库安全

数据库用户

数据库用户一览

拥有DBA角色的用户

拥有SYS角色的用户

角色概况

密码为系统默认值的用户

整个用户有多大

近一周登录错误的用户

系统表空间用户

SYSTEM为缺省表空间的用户

SYSTEM为临时表空间的用户

系统表空间上的对象

数据库审计

审计参数配置

审计表情况

DB中所有审计记录

 

数据库对象

段情况

对象汇总

段的汇总

体积最大的10个段

扩展最多的10个段

LOB

不能扩展的对象

扩展超过1/2最大扩展度的对象

Undo 

表空间所有者

表情况

行链接或行迁移的表

超过10W行无主键的表

无数据有高水位的表

分区表情况

表大小超过10GB未建分区

分区最多的前10个对象

分区个数超过100个的表

无效对象

无效的对象

无效的普通索引

无效的分区索引

无效的触发器

索引情况

索引个数超过5个的表

大表未建索引

组合索引与单列索引存在交叉

位图索引和函数索引

外键未建索引

大索引从未使用

索引列个数大于3

索引高度大于3

索引的统计信息过旧

并行度

表带有并行度

索引带有并行度

其他对象

告警日志

数据库目录

本页内容版权归属为原作者,如有侵犯您的权益,请通知我们删除。
Flashback Data Archive 闪回数据归档概述: 一句话就是undo的长期保存      我们知道关系型数据库要保证一致性,例如A用户update一条数据,未提交,此时为保证一致性B用户是看不到A更改后的数据的,那么此时B用户需要从undo表空间里面查看数据的前镜像,如果找不到前镜像就会报错,非常经典的ora-01555快照过旧的错误,还有就是闪回表和闪回查询也要依靠UNDO表空间记录的回滚信息, 然而undo表空间里面的数据是循环复写的,具体循环复写的规则请见 http://blog.i

ORACLE 死锁分析过程 - 2016-09-23 18:09:05

ORACLE 死锁分析 关于死锁一般3种处理方式 1、事前预测 2、资源分级 3、事后检测释放 我知道的ORACLE MYSQL都是采用第三种在行锁级别上的话。 这里分析一个ORACLE死锁,首先一个死锁肯定会生成一个TRACE文件,这里会记录很多信息如: Deadlock graph:                        ---------Blocker(s)--------  ---------Waiter(s)--------- Resource Name          process
传输表空间综述: 不论是数据字典管理的表空间还是本地管理的表空间,都可以使用传输表空间技术;从9i开始传输表空间不需要在源数据库和目标数据库之间具有同样的DB_BLOCK_SIZE块大小;使用传输表空间迁移数据比使用数据导入导出工具迁移数据的速度要快,这是因为传输表空间只是复制包含实际数据的数据文件到目标数据库的指定位置,而使用数据导入导出工具将传输表空间对象的元数据到目标数据库。 我们知道oracle利用imp/impdp传输表空间transport_tablespace需要满足以下条件: 1.字符集相

在线重定义的补充测试 - 2016-09-22 17:09:04

    在很多时候,我们都是需要保持业务的可持续性,尽管说DDL的过程持续时间很短,但是在线业务出现,就会阻塞DML,导致业务访问中断,事务收到影响,所以在有些场景下,高可用的需求可能比性能的需求优先级还要高一些。     比如一个分区表,突然发现分区的规则存在一些问题,如果需要重新规划分区,部署,可能对于在线业务影响较大,能不能平滑的过渡到重新规划的分区模式下。     比如一个普通表,随着数据量的增加发现已经存在一些管理瓶颈,比如历史数据的清理比较麻烦,想改为分区表的方式     比如一个表需要添加若干

oracle手动删除数据库 - 2016-09-21 14:09:23

有时候,无法使用图形界面时,我们需要手动删除数据库,具体操作步骤如下: 一、手动删除文件系统数据库    1.停止监听,防止有新的连接产生,同时,在数据库配置了em的,也需要停止        $ lsnrctl stop listener_name        $ emctl stop dbconsole    2.获得数据文件,日志文件及控制文件的相关信息,包含归档              $ sqlplus /as sysdba        SQLshow parameter control
  【 技巧 】如何让普通用户可以杀掉自己用户的会话   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  如何让普通用户可以杀掉自己用户的会话(重点)     Tips : ①  本文在 itpub ( http://blog.itpub.net/26736162 )、博客园 ( http://www.cnblogs.com/lhrbest )

聊聊Data Guard中的DG Broker - 2016-09-20 18:09:07

    DG Broker是Oracle为Data Guard维护提供的一个很不错的工具,从我的实际使用来看,早期的版本中似乎大家都还是存在一定的思维定式,认为手工维护已经足够了。这个工具就不那么需要了,我们完全可以脱离开这些工具来直观的使用命令行的方式来维护,这个观点也没错,不过从与时俱进的角度来看,本来能够让你更轻松的一个工具,如果不用实在是太可惜了。     DG Broker在数据库端需要启用一个后台进程dmon来维护,这个后台进程启动,需要设置dg_broker_start为true即可,如果要停
报名缘起   去年年底,崔老师发微信说12c OCM可以提上日程了。先不说那不菲的考试费用,单一个C(loud)就够我冷静一下了。最近几次参加线下分享活动,很多主题都离不开Cloud,听得云里雾里的。我问了一下自己,我可以吗?要不再等等吧。   过完年后,几个小伙伴蠢蠢欲动,看着朋友圈有朋友晒出的12c战袍还蛮帅的,走,报名去! 12c OCM考试号称“史上最难”   Oracle于2015年正式推出12c OCM升级考试,和以往的10g、11g OCM不同的是,12c OCM考试还要求考生每场达到最低分
  【 等待事件 】等待事件系列( 3+4 ) --System IO (控制文件) + 日志类等待   1    BLOG 文档结构图     2    前言部分   2.1    导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识, ~O(∩_∩)O~ : ①  控制文件类等待 ② 日志类等待   2.2    相关参考文章链接 【推荐】 等待事件系列(1)--User I/O类型(下) http://blog.itpub.net/26736162/v
今儿需要部署一个Oracle环境,为了简单些,选择了Oracle提供的Linux版本介质:OracleLinux-R6-U2-Server-x86_64-dvd.iso,在安装的过程中碰见了几个常见的问题,简要记录下,便于日后查找。 问题1:无法登陆图形界面   按照正常流程安装后,默认是没有安装图形界面的,因此进入的是命令行界面,若不用静默安装或克隆安装,则必须需要图形界面。于是按照常规做如下操作:  (1) 修改/etc/inittab中id:3:initdefault的3为5。  (2) start