场景

之前写了一篇文章,是redo日志全部丢失的情况下,数据库实例恢复的方式。但是,这次特殊在,实例恢复失败的情况下。非常规打开数据库(数据库已经不一致了,但是可以通过expdp导出,导出重要的数据)

可以通过下列命令,完成实例恢复

SYS@oradb> recover database until cancel;
完成介质恢复。
SYS@oradb> alter database open resetlogs;

此用户的情况用上述命令,无法恢复!!!!!

首先,数据库的归档满了。无法checkpoint。

其次,redo日志全部没有了。

因此,关闭数据库之后。进行上述操作。alert日志报了如下错误

SQL> recover database until cancel;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done SQL> recover database using backup controlfile until cancel;
ORA-00279: 更改 142116346 (在 09/22/2020 20:06:05 生成) 对于线程 1 是必需的 ORA-00289:
建议: /blqy/oracle/flashback/ARPDB/archivelog/2020_10_16/o1_mf_1_920_%u_.arc
ORA-00280: 更改 142116346 (用于线程 1) 在序列 #920 中

运气不好的是,没有

/blqy/oracle/flashback/ARPDB/archivelog/2020_10_16/o1_mf_1_920_%u_.arc日志文件。

因此,使用隐藏参数

Oracle 的隐含参数:
_allow_resetlogs_corruption=TRUE
SYS>alter system set "_allow_resetlogs_corruption"=true scope=spfile;
SYS>alter system reset "_allow_resetlogs_corruption" scope=spfile; 清除隐含参数
Oracle 不推荐使用这个隐含参数
该参数的含义是:允许数据库在不一致性的情况下强制打开数据库。

然后再次关闭数据库,在启动数据库,如下:

SQL> shutdown immediate;
ORA-01109: 数据库未打开 已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。 Total System Global Area 2505338880 bytes
Fixed Size 2255832 bytes
Variable Size 620758056 bytes
Database Buffers 1862270976 bytes
Redo Buffers 20054016 bytes
数据库装载完毕。
数据库已经打开。

数据库被强制打开。速度做了expdp的逻辑备份。保证了数据。

一则current日志损坏的数据库恢复实例,隐藏参数的使用的更多相关文章

  1. sql日志损坏造成数据库置疑解决办法

    --如果确定是日志损坏造成,请用下面的方法恢复日志文件.--第一步--use mastergo sp_configure 'allow updates', 1reconfigure with over ...

  2. Oracle redo 日志损坏的几种情况下的恢复

    Oracle redo 日志损坏的几种情况下的恢复 第一:损坏的redo为非正在使用的redo log 1.归档模式,不是当前正在日志损坏,数据库打开模式. 模拟损坏:SQL> select * ...

  3. oracle-不完全数据库恢复-被动恢复-ORA-00313/ORA-00366

    继上一篇不完全恢复 oracle-不完全数据库恢复-被动恢复-ORA-00313/ORA-00366 场景2:数据库拥有备份,CURRENT状态日志组中所有的在线日志头损坏,在发生日志切换时实例被自动 ...

  4. 第16周翻译:SQL Server中的事务日志管理,级别3:事务日志、备份和恢复

    源自: http://www.sqlservercentral.com/articles/Stairway+Series/73779/ 作者: Tony Davis, 2011/09/07 翻译:刘琼 ...

  5. 浅谈SQL Server中的事务日志(四)----在完整恢复模式下日志的角色

    简介 生产环境下的数据是如果可以写在资产负债表上的话,我想这个资产所占的数额一定不会小.而墨菲定律(事情如果有变坏的可能,无论这种可能性有多小,它总会发生)仿佛是给DBA量身定做的.在上篇文章介绍的简 ...

  6. oracle 11g 数据库恢复技术 ---01 重做日志

    一 redo log Oracle数据库中的三大核心文件分别是数据文件(data file).重做日志(redo log)和控制文件(control file).数据文件保证了数据库的持久性,是保存修 ...

  7. 大话RAC介质恢复---联机日志损坏

    对联机日志的损坏要根据日志状态进行分析,联机日志一般会有Current.Active和Inactive三种状态.Inactive状态不会造成数据丢失.而Active和Current状态的日志一般会造成 ...

  8. [转帖]超详细的Oracle数据库在不同损坏级别的恢复总结

    超详细的Oracle数据库在不同损坏级别的恢复总结 原创 波波说运维 2019-07-20 00:02:00 概述 在 DBA 的日常工作中不可避免存在着数据库的损坏,今天主要介绍 Oracle 数据 ...

  9. Oracle数据块损坏的恢复实例

    测试环境:11.2.0.4 1.构建数据块损坏的测试环境 2.有备份:常规恢复坏块 3.无备份:跳过坏块 1.构建数据块损坏的测试环境 1.1 创建测试表 --Create Table t_test ...

  10. OCA读书笔记(16) - 执行数据库恢复

    16. Performing Database Recovery 确定执行恢复的必要性访问不同接口(EM以及命令行)描述和使用可用选项,如RMAN和Data Recovery Advisor执行恢复- ...

随机推荐

  1. quartus之LPM_COMPARE测试

    quartus之LPM_COMPARE测试 1.IP描述 比较器的IP,可以比较两路数据是否相等.相等输出为1,不等输出为0的aeb信号是需要测试的量. 2.基础测试 module compare_t ...

  2. 关于 kafka 消息的顺序问题一二

    顺序就像就是 12345,任何 12354.12543.51234等都不行. 因为是 mq,所以必然涉及三个主体:发送方.消息服务器.消费方. 一.kafka 消息服务器 kafka brokers ...

  3. CTFshow pwn49 wp

    PWN49 用ida打开我们发现是静态编译的,所以先要通过libc库来打是不可能的了,程序里面有一个栈溢出点,找一下有没有system函数,发现并没有 那么我们找一下有没有mprotect函数如果有这 ...

  4. OTP/HOTP/TOTP的资料

    参考资料 [加解密]动态令牌-(OTP,HOTP,TOTP)-基本原理 每天一个小知识:HOTP HOTP和TOTP算法图解 RFC HMAC: Keyed-Hashing for Message A ...

  5. OpenHarmony社区运营报告(2022年11月)

    本月快讯 • 11月24日,第二十届中日韩三国IT局长OSS会议暨东北亚开源软件推进论坛以在线形式成功召开.经审核评选认定,OpenAtom OpenHarmony(以下简称"OpenHar ...

  6. 如何保存/同步多架构容器 Docker 镜像

    前言 随着容器.芯片技术的进一步发展,以及绿色.节能.信创等方面的要求,多 CPU 架构的场景越来越常见.典型的应用场景包括: 信创:x86 服务器 + 鲲鹏 ARM 等信创服务器: 个人电脑:苹果 ...

  7. Java实现打包压缩文件或文件夹生成zip以实现多文件批量下载

    有时候在系统中需要一次性下载多个文件,但逐个下载文件比较麻烦.这时候,最好的解决办法是将所有文件打包成一个压缩文件,然后下载这个压缩文件,这样就可以一次性获取所有所需的文件了. 下面是一个名为Comp ...

  8. Unity-PC 端调用SpVoice语音 (文字转语音)

    第一步引用文件 在VS当中 点击项目->添加引用-> 搜索Microsoft Speech Objecet Library 然后选中前面的白色方块点击确定就行了 插入之后 你的引用库中会多 ...

  9. Linux-搭建内网yum源

    部署要求: 服务器:CentOS7 YUM源:阿里云 空间要求:CentOS6+CentOS7 50G,考虑后期更新预留,LVS空间100G 1.在服务器配置CentOS7的yum源和CentOS6的 ...

  10. iOS系统崩溃的捕获

    iOS系统崩溃的捕获 相信大家在开发iOS程序的时候肯定写过各种Bug,而其中最为严重的Bug就是会导致崩溃的Bug(一般来说妥妥的P1级).在应用软件大大小小的各种异常中,崩溃确实是最让人难以接受的 ...