oracle通过修改控制文件scn推进数据库scn

数据库当前scn

 代码如下 复制代码

idle> select   checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
         271743118

idle> shutdown abort

ORACLE 例程已经关闭。
分析控制文件中scn

 


这里我们可以看到加粗部分为数据库scn

 代码如下 复制代码

SQL>select to_number('10327a59','xxxxxxxxx') from dual;

TO_NUMBER('10327A59','XXXXXXXXX')
---------------------------------
                        271743577

这里的scn值和在数据库中查询的值有小差别,因为查询时间点和我完全关闭数据库有个时间差,而这个时间差有scn变化.细红框部分为控制文件对块的验证信息

修改控制文件scn和验证信息
验证信息修改为全部0,scn信息你可以根据你的需求去修改,这里把数据库的scn修改为57253932971026,按照数据库的原理,启动后的scn应该稍微大于该scn值.


 代码如下 复制代码

SQL>select to_number('341278563412','xxxxxxxxxxxxxxxxx') from dual;

TO_NUMBER('341278563412','XXXXXXXXXXXXXXXXX')
---------------------------------------------
                               57253932971026

启动数据库
idle> startup mount
ORACLE 例程已经启动。

 代码如下 复制代码
Total System Global Area  400846848 bytes
Fixed Size                  2440024 bytes
Variable Size             289408168 bytes
Database Buffers          100663296 bytes
Redo Buffers                8335360 bytes

数据库装载完毕。

 代码如下 复制代码

idle> recover database;
完成介质恢复。
idle> alter database open;

数据库已更改。

idle> select   checkpoint_change# from v$database;

CHECKPOINT_CHANGE#
------------------
    57253932991028

数据库启动后查询scn为57253932991028(数据库当前scn)果然微大于57253932971026(修改控制文件scn),证明我们通过修改控制文件scn,实现数据库scn推近完全OK.不实验风险较大,请勿在生产环境上测试,负载后果自负

时间: 2024-07-29 11:07:19

oracle通过修改控制文件scn推进数据库scn的相关文章

当oracle丢失所有控制文件后可以重新创建控制文件来恢复数据库

当oracle丢失所有控制文件后可以重新创建控制文件来使数据库正常打开 重新创建控制文件的方法如下: 第一步是查询出该数据的所有日志文件,数据文件和控制文件 SQL> select member from v$logfile; MEMBER -------------------------------------------------------------------------------- D:\ORACLE\PRODUCT\10.1.0\ORADATA\OCP\REDO03.LOG

解读Oracle 9201的控制文件

oracle|控制  Oracle 9201的控制文件内容列表:     控制文件头... 数据库项... 检查点进度记录(该项从Oracle8开始引入)... 扩展的数据库项(该项从Oracle9i开始引入)... 重做线程项... 日志文件项... 数据文件项... 临时文件记录项(该项从Oracle9i开始引入)... 表空间记录项(该项从Oracle8开始引入)... Rman配置记录项(该项从Oracle9i开始引入)... 日志文件历史记录项... 脱机范围记录项(该项从Oracle

探索ORACLE之RMAN_07控制文件丢失恢复

探索ORACLE之RMAN_07控制文件丢失恢复 作者:吴伟龙   Name:Prodence Woo QQ:286507175  msn:hapy-wuweilong@hotmail.com 1.     控制文件(controlfile)丢失恢复 基于控制文件的复合多路径性,它的丢失分为两种,一种是其中某个控制文件的损坏或丢失,另外一种是所有控制文件均丢失.基于第一种情况,只需把好的控制文件复制一份在损坏或丢失的那个控制文件路径下即可.第二种情况下则需要通过备份信息来对控制文件进行恢复或手工

Oracle 基于备份控制文件的恢复(unsing backup controlfile)

    Oracle 基于备份控制文件的恢复(unsing backup controlfile)     有关RMAN的备份恢复与管理请参考     RMAN 概述及其体系结构     RMAN 配置.监控与管理     RMAN 备份详解     RMAN 还原与恢复     RMAN catalog 的创建和使用     基于catalog 创建RMAN存储脚本     基于catalog 的RMAN 备份与恢复     RMAN 备份路径困惑     使用RMAN实现异机备份恢复(WIN

Oracle基于备份控制文件的恢复

通常在当前控制文件丢失,或者当前的控制文件与需要恢复的控制文件不一致的情况下,我们需要重新创建一个控制文件或者使用 unsingbackup controlfile方式来恢复控制文件.说简单点,只要是备份的控制文件与当前的控制文件不一致进行恢复数据库,就需要使用到 unsingbackup controlfile方式,而一旦使用了该方式,则需使用resetlgos选项来打开数据库. 一.基于备份控制文件的恢复注意事项(无论是否使用恢复目录catalog) 1.即使没有数据文件需要还原,当使用un

Oracle 控制文件(CONTROLFILE)

--============================= -- Oracle 控制文件(CONTROLFILE) --=============================   一.Oracle 控制文件         为二进制文件,初始化大小由CREATE DATABASE指定,可以使用RMAN备份         记录了当前数据库的结构信息,同时也包含数据文件及日志文件的信息以及相关的状态,归档信息等等         在参数文件中描述其位置,个数等等.通常采用分散放开,多路复用

Oracle 快照控制文件(snapshot control file)

      听说过Oracle 控制文件,还有快照控制文件这个说法呢?没错,尽管快照控制文件很少被提及,但确实是存在,只不过在使用RMAN时这个快照控制文件被使用.回顾一下 Oracle 控制文件,我们知道控制文件是Oracle体系结构中的重要组成部分之一,记录了当前数据库的结构信息,同时也包含数据文件及日志文件的信息以及相关的状态,归档信息,也记录了系统当前SCN的值等等.那快照控制文件也就是控制文件的一个副本,本文介绍了什么是快照控制文件以及何时被使用.   1.快照控制文件     快照控

ORACLE 移动数据文件 控制文件 重做日志文件

ORACLE数据库有时候需要对存储进行调整,增加分区.IO调优等等,此时需要移动数据文件.重做日志文件.控制文件等等,下文结合例子总结一下这方面的知识点. 进行数据文件.重做日志文件.控制文件的迁移前,需要总体了解一下当前Linux服务器的磁盘.分区信息,以及服务器文件使用情况,如下所示 查看Linux服务器的文件使用情况 1: [root@DB-Server ~]# df -h 2:  3: Filesystem Size Used Avail Use% Mounted on 4:  5: /

批量迁移Oracle数据文件,日志文件及控制文件

   有些时候需要将Oracle的多个数据文件以及日志文件重定位或者迁移到新的分区或新的位置,比如磁盘空间不足,或因为特殊需求.对于这种情形可以采取批量迁移的方式将多个数据文件或者日志文件实现一次性迁移.当然备份恢复也是其中的方式之一.本文主要描述如何使用批量方式来迁移数据文件,日志文件.如需要也可以将整个数据库迁移到新的位置以及重命名数据库. 1.环境及需求 robin@SZDB:~> cat /etc/issue Welcome to SUSE Linux Enterprise Server