我的编程空间,编程开发者的网络收藏夹
学习永远不晚

AMDU数据恢复的方法是什么

短信预约 -IT技能 免费直播动态提醒
省份

北京

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团
手机号立即预约

请填写图片验证码后获取短信验证码

看不清楚,换张图片

免费获取短信验证码

AMDU数据恢复的方法是什么

这篇文章主要介绍“AMDU数据恢复的方法是什么”,在日常操作中,相信很多人在AMDU数据恢复的方法是什么问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”AMDU数据恢复的方法是什么”的疑惑有所帮助!接下来,请跟着小编一起来学习吧!

A.M.D.U数据恢复

客户环境:

操作系统:RedHat Enterprise AS Linux 4.6 x64

数据库DBOracle Enterprise Database 10g(10.2.0.4) no psu

集群系统:Oracle Real Application Cluster 10g(10.2.0.4) no psu

问题背景:

       在一个寂静的夜晚被一阵急促的电话铃声吵醒,打来电话的是我的老朋友J,他告知我说数据库起不来了,业务全部中断,存储狂扇,频繁的告警亮灯,寻求我的紧急帮助。我首先安慰老朋友J,说这个可能是存储有问题,比较棘手,还是有修复的可能。J听到我这么一说长舒了一口气,缓缓的吐了几个字说:“吴哥,你得帮帮我!”我说没问题,随即梦醒打了个飞的直奔故障现场。了解到了客户环境:比想象中的更为复杂,上线后就没有任何备份,是一个部署在RHEL4.6环境下的10g(10.2.0.4)的RAC,用的是8盘位DFT低端SAS存储。

问题分析:

       在了解到问题环境之后需要对问题进行进一步的分析和解决,思考了半个小时,CRS服务无法启动,没有数据库备份无法恢复;10gRAC ASM无法mount,内部视图无法查询,磁盘组无法正常加载,给数据恢复带来诸多不便......,看来常规方法是不行了,只能考虑一些非常规的数据恢复方法:DUL? AUL? ODU? 这几个工具一直在大脑中回荡,后来冷静思考,咨询了行业里面的牛人,告诉我说通过11g下的AMDU可以在磁盘组加载之前将ASM元数据抽出来,用于诊断及起库open,之后再重做RAC恢复数据即可。且该工具可以向后兼容,引入到10g中。

       说完就干~!

处理过程:

 

1.1.基础环境准备

       在Oracle官网下载最新的AMDU工具,在任意节点挂载外置移动硬盘,上传到挂载外置移动硬盘的节点上,进去后赋予oracle:oinstall权限并用oracle用户解压,配置参数文件amdu_par,包含如下内容:

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:`pwd`

export PATH=$PATH:`pwd`

1.2. 初始化amdu工具

用oracle用户执行如下命令,将自动生成一个以时间命名的目录,其下的报告

文件记录了磁盘组的相关信息。

./amdu
amdu_2019_03_30_12_26_32

该报告的主要信息如下:

-*-amdu-*-
 
******************************* AMDU Settings ********************************
ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1
System name:Linux
Node name:  rac1
Release:  2.6.9-78.ELlargesmp
Version:  #1 SMP Wed Jul 9 16:03:59 EDT 2008
Machine:x86_64
amdu run:      30-MAR-19 12:26:32
Endianess:     1
 
--------------------------------- Operations ---------------------------------
 
------------------------------- Disk Selection -------------------------------
 -diskstring ''
 
------------------------------ Reading Control -------------------------------
 
------------------------------- Output Control -------------------------------
 
********************************* DISCOVERY **********************************
 
----------------------------- DISK REPORT N0001 ------------------------------
                Disk Path: /dev/raw/raw1
          Unique Disk ID: 
               Disk Label: 
    Physical Sector Size: 512 bytes
                Disk Size: 199 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
 
----------------------------- DISK REPORT N0002 ------------------------------
                Disk Path: /dev/raw/raw2
          Unique Disk ID: 
               Disk Label: 
    Physical Sector Size: 512 bytes
                Disk Size: 299 megabytes
** NOT A VALID ASM DISK HEADER. BAD VALUE IN FIELD blksize_kfdhdb **
 
----------------------------- DISK REPORT N0003 ------------------------------
                Disk Path: ORCL:VOL1
          Unique Disk ID: 
               Disk Label: VOL1
    Physical Sector Size: 512 bytes
                Disk Size: 2047997 megabytes
               Group Name: ORADATA_DG1
                Disk Name: VOL1
      Failure Group Name: VOL1
              Disk Number: 0
           Header Status: 3
      Disk Creation Time: 2011/01/04 15:51:21.126000
         Last Mount Time: 2019/03/30 13:15:19.625000
   Compatibility Version: 0x0a100000
        Disk Sector Size: 512 bytes
        Disk size in AUs: 2047997 AUs
        Group Redundancy: 1
     Metadata Block Size: 4096 bytes              ---------元数据块大小,4KB
                  AU Size: 1048576 bytes                 -------------AU大小:1MB
                   Stride: 113792 AUs
     Group Creation Time: 2011/01/04 15:51:21.013000
 File 1 Block 1 location: AU 2                            ---------文件使用,从AU 2 开始
 
----------------------------- DISK REPORT N0004 ------------------------------
                Disk Path: ORCL:VOL2
          Unique Disk ID: 
               Disk Label: VOL2
    Physical Sector Size: 512 bytes
                Disk Size: 2047997 megabytes
               Group Name: ORADATA_DG2
                Disk Name: VOL2
      Failure Group Name: VOL2
              Disk Number: 0
           Header Status: 3
      Disk Creation Time: 2011/01/04 15:51:43.512000
         Last Mount Time: 2019/03/30 13:15:19.851000
   Compatibility Version: 0x0a100000
        Disk Sector Size: 512 bytes
        Disk size in AUs: 2047997 AUs
        Group Redundancy: 1
     Metadata Block Size: 4096 bytes                         ----------元数据块大小,4KB
                  AU Size: 1048576 bytes            --------------AU大小:1MB
                   Stride: 113792 AUs
     Group Creation Time: 2011/01/04 15:51:43.370000
 File 1 Block 1 location: AU 2                                ---------文件使用,从AU 2 开始
 
----------------------------- DISK REPORT N0005 ------------------------------
                Disk Path: ORCL:VOL3
          Unique Disk ID: 
               Disk Label: VOL3
    Physical Sector Size: 512 bytes
                Disk Size: 2047997 megabytes
               Group Name: ORADATA_DG3
                Disk Name: VOL3
      Failure Group Name: VOL3
              Disk Number: 0
           Header Status: 3
      Disk Creation Time: 2011/01/04 15:52:05.086000
         Last Mount Time: 2019/03/30 13:15:20.093000
   Compatibility Version: 0x0a100000
        Disk Sector Size: 512 bytes
        Disk size in AUs: 2047997 AUs
        Group Redundancy: 1
     Metadata Block Size: 4096 bytes                         ---------元数据块大小,4KB
                  AU Size: 1048576 bytes            --------------AU大小:1MB
                   Stride: 113792 AUs
     Group Creation Time: 2011/01/04 15:52:04.949000
 File 1 Block 1 location: AU 2                                ---------文件使用,从AU 2 开始
 
----------------------------- DISK REPORT N0006 ------------------------------
                Disk Path: ORCL:VOL4
          Unique Disk ID: 
               Disk Label: VOL4
    Physical Sector Size: 512 bytes
                Disk Size: 1484867 megabytes
               Group Name: RECOVER_DG
                Disk Name: VOL4
      Failure Group Name: VOL4
              Disk Number: 0
           Header Status: 3
      Disk Creation Time: 2011/01/04 15:52:31.026000
         Last Mount Time: 2019/03/30 13:15:20.336000
   Compatibility Version: 0x0a100000
        Disk Sector Size: 512 bytes
        Disk size in AUs: 1484867 AUs
        Group Redundancy: 1
     Metadata Block Size: 4096 bytes
                  AU Size: 1048576 bytes        ----元数据块大小,4KB
                   Stride: 113792 AUs        --------AU 大小:1MB
     Group Creation Time: 2011/01/04 15:52:30.929000
 File 1 Block 1 location: AU 2              ---------文件使用,从AU 2 开始
 
******************************* END OF REPORT ********************************

1.3.抽取控制文件

       由于磁盘组不能Mount,控制文件也无法访问,因此需要首先分析数据库的文件分布情况,进而通过文件的ASM 存储序号来进行文件抽取,通过告警日志,可以找到数据库的控制文件信息。如下所示,控制文件的ASM 文件号是270。

grep control_file $ORACLE_BASE/admin/$ORACLE_SID/bdump/alert_$ORACLE_SID.log
 
control_files = "+ORADATA_DG1/ORADB/CONTROLFILE/Current.260.739555035"
..........
 
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.260
amdu_2019_03_30_12_29_43/

1.4. 通过控制文件获取RedoLog 和DataFile

       取得控制文件之后,可以通过控制文件内容获得数据库的数据文件及日志文件分布情况。以下是从控制文件中获得的信息输出。

[root@rac1 ~]# strings ORADATA_DG1_260.f |grep -v archivelog |grep -v oracle/ |grep ORAD| sort
+ORADATA_DG1/oradb/idx_jsnet.dbf
+ORADATA_DG1/oradb/idx_jsnet.dbf
+ORADATA_DG1/oradb/idx_jsnet.ora
+ORADATA_DG1/oradb/idx_jsnet.ora
+ORADATA_DG1/oradb/redo01.log
+ORADATA_DG1/oradb/redo01.log
+ORADATA_DG1/oradb/redo02.log
+ORADATA_DG1/oradb/redo02.log
+ORADATA_DG1/oradb/redo03.log
+ORADATA_DG1/oradb/redo03.log
+ORADATA_DG1/oradb/redo04.log
+ORADATA_DG1/oradb/redo04.log
+ORADATA_DG1/oradb/sysaux01.dbf
+ORADATA_DG1/oradb/sysaux01.dbf
+ORADATA_DG1/oradb/system01.dbf
+ORADATA_DG1/oradb/system01.dbf
+ORADATA_DG1/oradb/tbs_jsnet.dbf
+ORADATA_DG1/oradb/tbs_jsnet.dbf
+ORADATA_DG1/oradb/tbs_jsnet.dbf
+ORADATA_DG1/oradb/tbs_jsnet.dbf
+ORADATA_DG1/oradb/temp01.dbf
+ORADATA_DG1/oradb/temp01.dbf
+ORADATA_DG1/oradb/undotbs01.dbf
+ORADATA_DG1/oradb/undotbs01.dbf
+ORADATA_DG1/oradb/undotbs02.dbf
+ORADATA_DG1/oradb/undotbs02.dbf
+ORADATA_DG1/oradb/users01.dbf
+ORADATA_DG1/oradb/users01.dbf

1.5. 恢复文件

       根据控制文件中的文件分布信息,可以通过amdu工具将所有文件提取出来,根据以数据文件和日志文件信息,创建如下脚本以抽取对应的日志文件和数据文件。

先恢复RedoLog File:

[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.263
amdu_2019_03_30_12_32_38/
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.264
amdu_2019_03_30_12_33_12/
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.267
amdu_2019_03_30_12_34_11/
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.268
amdu_2019_03_30_12_34_22/

再恢复数据文件:

IDX_JSNET.ora:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.276
amdu_2019_03_30_12_38_42/
 
IDX_JSNET:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.298
 
TBS_JSNET:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.277
 
SYSAUX:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.257
 
SYSTEM:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.256
 
TEMP:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.265
 
UNDOTBS1:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.258
 
UNDOTBS2:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.266
 
USER:
[oracle@rac1 amdu_2019_03_30_12_26_32]$ amdu -diskstring
'/dev/oracleasm/disks/VOL*' -extract ORADATA_DG1.259

1.6. 校验文件

       到这里文件已经全部恢复出来了,途中未见报错,接下来需要用dbv对文件进行个校验,检查下是否有逻辑坏块:

[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_
amdu_2019_03_30_12_29_43/ amdu_2019_03_30_12_33_12/ amdu_2019_03_30_12_38_42/ amdu_2019_03_30_12_43_30/
amdu_2019_03_30_12_29_56/ amdu_2019_03_30_12_34_11/ amdu_2019_03_30_12_40_08/ amdu_2019_03_30_12_44_47/
amdu_2019_03_30_12_30_07/ amdu_2019_03_30_12_34_22/ amdu_2019_03_30_12_40_45/
amdu_2019_03_30_12_32_38/ amdu_2019_03_30_12_37_22/ amdu_2019_03_30_12_42_13/
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_38_42/ORADATA_DG1_276.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:00:33 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_12_38_42/ORADATA_DG1_276.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 25600
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 8
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 25592
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 753000 (0.753000)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_40_08/ORADATA_DG1_298.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:00:53 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_12_40_08/ORADATA_DG1_298.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 32000
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 28786
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 1062
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg)  : 0
Total Pages Empty            : 2152
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 697113994 (0.697113994)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_40_45/ORADATA_DG1_277.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:01:09 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_12_40_45/ORADATA_DG1_277.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 101120
Total Pages Processed (Data) : 95455
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 353
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 3290
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 2022
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 697223552 (0.697223552)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_42_13/ORADATA_DG1_257.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:01:17 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_12_42_13/ORADATA_DG1_257.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 107520
Total Pages Processed (Data) : 41691
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 33473
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 18814
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 13542
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 697247738 (0.697247738)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_43_30/ORADATA_DG1_256.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:01:59 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_12_43_30/ORADATA_DG1_256.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 64000
Total Pages Processed (Data) : 38706
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 7385
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 2067
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 15842
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 697247727 (0.697247727)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_12_44_47/ORADATA_DG1_265.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:02:25 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY: Skipping temporary file amdu_2019_03_30_12_44_47/ORADATA_DG1_265.f
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_13_10_37/ORADATA_DG1_258.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:03:18 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_13_10_37/ORADATA_DG1_258.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 23680
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 23432
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 248
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 667630094 (0.667630094)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_13_14_27/ORADATA_DG1_266.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:03:43 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_13_14_27/ORADATA_DG1_266.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 27080
Total Pages Processed (Data) : 0
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 0
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 27080
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 0
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 697247738 (0.697247738)
[oracle@rac1 amdu_2019_03_30_12_26_32]$ dbv file=amdu_2019_03_30_13_15_29/ORADATA_DG1_259.f
 
DBVERIFY: Release 10.2.0.4.0 - Production on Sat Mar 30 14:04:03 2019
 
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
 
DBVERIFY - Verification starting : FILE = amdu_2019_03_30_13_15_29/ORADATA_DG1_259.f
 
 
DBVERIFY - Verification complete
 
Total Pages Examined         : 640
Total Pages Processed (Data) : 15
Total Pages Failing   (Data) : 0
Total Pages Processed (Index): 2
Total Pages Failing   (Index): 0
Total Pages Processed (Other): 593
Total Pages Processed (Seg)  : 0
Total Pages Failing   (Seg) : 0
Total Pages Empty            : 30
Total Pages Marked Corrupt   : 0
Total Pages Influx           : 0
Highest block SCN            : 598900 (0.598900)

1.7. 验证数据库版本及补丁信息

[oracle@rac1 amdu_2019_03_30_12_26_32]$ $ORACLE_HOME/OPatch/opatch lsinv
Invoking OPatch 10.2.0.4.2
 
Oracle Interim Patch Installer version 10.2.0.4.2
Copyright (c) 2007, Oracle Corporation.  All rights reserved.
 
 
Oracle Home       : /u01/app/oracle/product/10.2.0/db_1
Central Inventory : /u01/app/oraInventory
  from           : /etc/oraInst.loc
OPatch version    : 10.2.0.4.2
OUI version       : 10.2.0.4.0
OUI location      : /u01/app/oracle/product/10.2.0/db_1/oui
Log file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollogs/opatch/opatc h3019-03-30_13-56-47PM.log
 
Lsinventory Output file location : /u01/app/oracle/product/10.2.0/db_1/cfgtoollo gs/opatch/lsinv/lsinventory2019-03-30_13-56-47PM.txt
 
--------------------------------------------------------------------------------
Installed Top-level Products (3):
 
Oracle Database 10g                                                 10.2.0.1.0
Oracle Database 10g Products                                        10.2.0.1.0
Oracle Database 10g Release 2 Patch Set 3                            10.2.0.4.0
There are 3 products installed in this Oracle Home.
 
 
There are no Interim patches installed in this Oracle Home.
 
 
Rac system comprising of multiple nodes
 Local node = rac1
 Remote node = rac2
 
--------------------------------------------------------------------------------
 
OPatch succeeded.

2、构建新的环境

2.1. 安装相同版本数据库

       不要建库,只需安装数据库软件即可。

过程(略)

 

2.2. 创建数据库启动参数文件

       编辑好参数文件,将数据库启动到nomount状态:

[oracle@rac1 dbs]$ cat initoradb.ora
db_name=oradb
db_files = 80
db_file_multiblock_read_count = 8
db_block_buffers = 100
shared_pool_size = 123232153
log_checkpoint_interval = 10000
processes = 50
parallel_max_servers = 5
log_buffer = 32768
max_dump_file_size = 10240
global_names = TRUE
control_files = '/oracle/oradata/oradb/control01.ctl'

2.3. 将数据库启到nomount状态

[oracle@rac1 dbs]$ sqlplus / as sysdba
 
SQL*Plus: Release 10.2.0.4.0 - Production on Sat Apr 6 12:47:26 2019
 
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
 
Connected to an idle instance.
 
SQL> startup nomount;
ORACLE instance started.
 
Total System Global Area 4294967296 bytes
Fixed Size                  2089472 bytes
Variable Size            4269805056 bytes
Database Buffers            8388608 bytes
Redo Buffers               14684160 bytes

2.4. mount数据库

SQL> alter database mount;
 
Database altered.
 
SQL> select instance_name,status from gv$instance;
 
INSTANCE_NAME    STATUS
---------------- ------------
oradb            MOUNTED

接下来就可以修改控制文件里面对应的数据文件及RedoLog的路径,并open数据库了。

2.5 修改路径

       修改控制文件中的数据文件和RedoLog对应路径信息。

RedoLog File RENAME FILE: 

alter database rename file '+ORADATA_DG1/oradb/redo02.log' to '/oracle/oradata/oradb/amdu_2019_03_30_12_33_12/ORADATA_DG1_264.f';
alter database rename file '+ORADATA_DG1/oradb/redo01.log' to '/oracle/oradata/oradb/amdu_2019_03_30_12_32_38/ORADATA_DG1_263.f';
alter database rename file '+ORADATA_DG1/oradb/redo03.log' to '/oracle/oradata/oradb/amdu_2019_03_30_12_34_11/ORADATA_DG1_267.f';
alter database rename file '+ORADATA_DG1/oradb/redo04.log' to '/oracle/oradata/oradb/amdu_2019_03_30_12_34_22/ORADATA_DG1_268.f';
 
ter database rename file '+ORADATA_DG1/oradb/users01.dbf'   to '/oracle/oradata/oradb/amdu_2019_03_30_13_15_29/ORADATA_DG1_259.f';
alter database rename file '+ORADATA_DG1/oradb/sysaux01.dbf'  to '/oracle/oradata/oradb/amdu_2019_03_30_12_42_13/ORADATA_DG1_257.f';
alter database rename file '+ORADATA_DG1/oradb/undotbs01.dbf' to '/oracle/oradata/oradb/amdu_2019_03_30_13_10_37/ORADATA_DG1_258.f';
alter database rename file '+ORADATA_DG1/oradb/system01.dbf'  to '/oracle/oradata/oradb/amdu_2019_03_30_12_43_30/ORADATA_DG1_256.f';
alter database rename file '+ORADATA_DG1/oradb/undotbs02.dbf' to '/oracle/oradata/oradb/amdu_2019_03_30_13_14_27/ORADATA_DG1_266.f';
alter database rename file '+ORADATA_DG1/oradb/tbs_jsnet.dbf' to '/oracle/oradata/oradb/amdu_2019_03_30_12_40_45/ORADATA_DG1_277.f';
alter database rename file '+ORADATA_DG1/oradb/idx_jsnet.dbf' to '/oracle/oradata/oradb/amdu_2019_03_30_12_40_08/ORADATA_DG1_298.f';

 

 Temp File RENAME FILE:

alter database rename file '+ORADATA_DG1/oradb/temp01.dbf' to '/oracle/oradata/oradb/amdu_2019_03_30_12_44_47/ORADATA_DG1_265.f';

 

3.启动数据库

[oracle@redhat5 ~]$ sqlplus / as sysdba
 
SQL*Plus: Release 10.2.0.4.0 - Production on Sun Mar 31 03:50:55 2019
 
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
 
 
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
 
SQL> alter database open;
alter database open
*
ERROR at line 1:
ORA-00369: Current log of thread 1 not useable and other log being cleared
ORA-00312: online log 1 thread 1:
'/oracle/oradata/oradb/amdu_2019_03_30_12_32_38/ORADATA_DG1_263.f'
 
 
SQL> alter database clear unarchived logfile group 1;
 
Database altered.
 
SQL> alter database open;
 
Database altered.
 
SQL> select instance_name,status from v$instance;
 
INSTANCE_NAMESTATUS
---------------- ------------
oradb            OPEN

4. 数据库业务方面确认

SQL> select username,default_tablespace from dba_users where account_status='OPEN';
 
USERNAME                 DEFAULT_TABLESPACE
------------------------------ ------------------------------
SYSTEM                       SYSTEM
SYS                      SYSTEM
SYSMAN                      SYSAUX
DBSNMP                     SYSAUX
MGMT_VIEW               SYSTEM
woo                             TBS_JSNET
 
6 rows selected.
 
col OWNER format a8
col OBJECT_NAME format a25
select owner,object_name,status from dba_objects where owner='MAM42SYS';
 
 
OWNER  OBJECT_NAME              STATUS
-------- ------------------------- -------
WOO      WOO_NAVBONTMOL         VALID
WOO     WOO_NAVTONTCOL          VALID
WOO     WOO_NAV2GATIWN           VALID

到此,关于“AMDU数据恢复的方法是什么”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!

免责声明:

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的,并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据,供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

AMDU数据恢复的方法是什么

下载Word文档到电脑,方便收藏和打印~

下载Word文档

猜你喜欢

raid数据恢复的方法是什么

这篇文章主要介绍了raid数据恢复的方法是什么的相关知识,内容详细易懂,操作简单快捷,具有一定借鉴价值,相信大家阅读完这篇raid数据恢复的方法是什么文章都会有所收获,下面我们一起来看看吧。【物理服务器与逻辑存储介绍】 客户使用一台IBM
2023-06-04

mysql恢复数据库的方法是什么

MySQL恢复数据库的方法主要有以下几种:1. 使用备份文件恢复:如果有事先备份的数据库文件,可以使用MySQL提供的命令行工具(如mysql命令)或可视化工具(如phpMyAdmin)进行导入,将备份文件中的数据重新导入到数据库中。2.
2023-10-09

sqlserver数据库恢复的方法是什么

SQL Server数据库的恢复方法通常有以下几种:使用备份文件恢复:可以利用SQL Server Management Studio (SSMS)或T-SQL命令来还原数据库备份文件来恢复数据库。使用事务日志恢复:如果数据库发生了意外故障
sqlserver数据库恢复的方法是什么
2024-04-09

sqlserver恢复表数据的方法是什么

在SQL Server中,恢复表数据的方法通常包括以下几种:使用事务日志备份进行恢复:如果表数据被意外删除或修改,可以通过还原事务日志备份来恢复表数据到之前的状态。使用备份进行恢复:如果有定期备份数据库的策略,可以通过还原数据库备份来恢复表
sqlserver恢复表数据的方法是什么
2024-04-09

mysql数据库恢复的方法是什么

MySQL数据库恢复的方法有以下几种:通过备份文件恢复:如果有定期备份数据库的文件,可以使用备份文件进行恢复。首先,停止MySQL服务,然后将备份文件拷贝到MySQL数据目录下,最后启动MySQL服务即可完成恢复。利用二进制日志进行恢复:M
mysql数据库恢复的方法是什么
2024-04-09

mongodb分片数据恢复的方法是什么

MongoDB分片数据恢复的方法主要有以下几种:1. 使用备份和恢复工具:可以使用MongoDB提供的mongodump和mongorestore工具进行备份和恢复操作。首先使用mongodump将分片集群中的数据备份到文件中,然后使用mo
2023-08-23

linux系统数据恢复的方法是什么

这篇文章主要介绍“linux系统数据恢复的方法是什么”的相关知识,小编通过实际案例向大家展示操作过程,操作方法简单快捷,实用性强,希望这篇“linux系统数据恢复的方法是什么”文章能帮助大家解决问题。工具: hexedit、fdisk下文内
2023-06-17

mysql日志恢复数据的方法是什么

MySQL的日志恢复数据方法主要有两种:基于二进制日志的恢复和基于事务日志的恢复。1. 基于二进制日志的恢复:- 首先,通过`mysqlbinlog`命令将二进制日志文件转换为可读的SQL语句。例如,使用以下命令将二进制日志文件转换为SQL
2023-09-22

redis宕机数据恢复的方法是什么

Redis宕机后可以通过以下方法恢复数据:重新启动Redis服务:首先尝试重启Redis服务,看是否能够恢复数据。如果Redis服务能够重新启动并且数据没有丢失,那么恭喜你,数据已经恢复了。使用AOF文件进行恢复:如果Redis使用AOF持
redis宕机数据恢复的方法是什么
2024-04-09

mysql数据库增量数据恢复的方法是什么

本篇内容介绍了“mysql数据库增量数据恢复的方法是什么”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!一、工作场景(1)MySQL数据库每晚
2023-06-02

云服务器恢复数据的方法是什么

云服务器恢复数据的方法可以通过以下几种方式:1. 数据备份:在云服务器上定期进行数据备份,将数据复制到另一个安全的存储空间,以便在需要时进行恢复。可以使用云服务提供商的备份服务或者自行设置定期备份任务。2. 快照恢复:云服务器提供商一般会提
2023-09-22

云服务器恢复数据的方法是什么

云服务器恢复数据方法云服务器数据丢失时,可通过备份恢复、操作系统工具、第三方软件、云服务商工具等方式恢复。具体步骤包括:识别数据丢失情况。根据丢失情况选择恢复方法。执行恢复操作。验证恢复结果。建议定期备份数据,保存快照备份,测试恢复流程,遵守安全原则,并选择可靠的云服务商。
云服务器恢复数据的方法是什么
2024-04-11

Db2数据库故障恢复的方法是什么

DB2数据库故障恢复的方法可以分为以下几种:利用数据库备份恢复:如果有定期备份数据库的策略,可以利用备份文件来恢复数据库。可以使用DB2的RESTORE命令来恢复数据库。利用事务日志进行恢复:如果备份文件不可用,还可以利用事务日志文件来进行
Db2数据库故障恢复的方法是什么
2024-03-08

mongodb数据备份和恢复的方法是什么

在MongoDB中,可以使用mongodump和mongorestore命令来备份和恢复数据。下面是备份和恢复数据的步骤:备份数据:使用mongodump命令可以备份MongoDB数据库的数据。以下是备份数据的命令:mongodump -
mongodb数据备份和恢复的方法是什么
2024-04-10

oracle时间戳恢复数据的方法是什么

要恢复使用Oracle数据库的时间戳数据,可以使用以下方法:使用Flashback技术:Oracle数据库提供了Flashback技术,可以用来在指定时间点恢复数据。可以使用Flashback Query来查询某个特定时间点的数据,或者使用
oracle时间戳恢复数据的方法是什么
2024-04-09

编程热搜

目录