[20160407]bbed修改文件头2(补充).txt

[20160407]bbed修改文件头2(补充).txt

--昨天被别人问一个问题,就是我的测试修改数据文件相应的CHECKPOINT_CHANGE#就ok了.偏移量是block=1的offset=484.
--链接 http://blog.itpub.net/267265/viewspace-2075424/

--不过别人问的是这个时间是如何存储的.我以前也做过一些.链接:
--http://blog.itpub.net/267265/viewspace-746222/

--我的感觉在11.2.0.3下要修改CHECKPOINT_CHANGE#, CHECKPOINT_COUNT,时间不用修改.实际上如果要跳过修改CHECKPOINT_COUNT,可以
--通过重建控制文件的方法实现,我自己从来没有做这个测试.

--//后记:
--//更正:严重错误,应该按照如下公式计算:
time = (((((yyyy - 1988) * 12 + mm - 1) * 31 + dd - 1) * 24 + hh) * 60 + mi) * 60 + ss;
--//参考新链接:
http://blog.itpub.net/267265/viewspace-2135046/

SYS@book> @ &r/stamp 908533461
     STAMP STAMP_CONV_TIME
---------- -------------------
 908533461 2016-04-07 10:24:21

SYS@book> @ &r/stamp 908506808
     STAMP STAMP_CONV_TIME
---------- -------------------
 908506808 2016-04-07 03:00:08

--//这样与视图v$datafile_header 的CHECKPOINT_TIME一样,特此更正!!

SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header ;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                             TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------- ---------------
    1        13227551841 2016-04-07 10:24:21                7       13227286650 ONLINE              1011 YES /mnt/ramdisk/book/system01.dbf   SYSTEM
    2        13227551841 2016-04-07 10:24:21             1834       13227286650 ONLINE              1007 YES /mnt/ramdisk/book/sysaux01.dbf   SYSAUX
    3        13227551841 2016-04-07 10:24:21           923328       13227286650 ONLINE               927 YES /mnt/ramdisk/book/undotbs01.dbf  UNDOTBS1
    4        13227551841 2016-04-07 10:24:21            16143       13227286650 ONLINE              1011 YES /mnt/ramdisk/book/users01.dbf    USERS
    5        13227551841 2016-04-07 10:24:21           952916       13227286650 ONLINE               924 YES /mnt/ramdisk/book/example01.dbf  EXAMPLE
    6        13227551841 2016-04-07 10:24:21          1314508       13227286650 ONLINE               940 YES /mnt/ramdisk/book/sugar01.dbf    SUGAR
    7        13227536676 2016-04-07 03:00:08      13227207527       13227286650 OFFLINE               32 YES /mnt/ramdisk/book/tea01.dbf      TEA
7 rows selected.
============

摘抄一段:

The file header is stored in the first block cf the data file. We can use bbed tc examine the blcck and show
the block map. The header blocks contain a single data structure — kcvfh. Oracle considers four attributes
of this data structure when determining if a data file is sync with the other data files of the database:

kscnbas  (at offset 484) -- SCN of last change to the datafile.
kcvcptim (at offset 492) -- Time of the last change to the datafile.
kcvfhcpc (at offset 140) -- Checkpoint count.
kcvfhccc (at offset 148) -- Unknown, but is always l less than the checkpoint point count.

The first two attributes are stored in the kcvfhckp sub-structure. The second two are attributes in their own
right. We can use the print command to display them all for the file that requires recovery:

--下面看看时间如何保存的:

1.环境:

SCOTT@book> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SCOTT@book> alter database datafile 7 offline ;
Database altered.

SCOTT@book> alter system checkpoint ;
System altered.

SCOTT@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header ;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS  CHECKPOINT_COUNT FUZ NAME                             TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ------- ---------------- --- -------------------------------- ---------------
    1        13227551841 2016-04-07 10:24:21                7       13227286650 ONLINE              1011 YES /mnt/ramdisk/book/system01.dbf   SYSTEM
    2        13227551841 2016-04-07 10:24:21             1834       13227286650 ONLINE              1007 YES /mnt/ramdisk/book/sysaux01.dbf   SYSAUX
    3        13227551841 2016-04-07 10:24:21           923328       13227286650 ONLINE               927 YES /mnt/ramdisk/book/undotbs01.dbf  UNDOTBS1
    4        13227551841 2016-04-07 10:24:21            16143       13227286650 ONLINE              1011 YES /mnt/ramdisk/book/users01.dbf    USERS
    5        13227551841 2016-04-07 10:24:21           952916       13227286650 ONLINE               924 YES /mnt/ramdisk/book/example01.dbf  EXAMPLE
    6        13227551841 2016-04-07 10:24:21          1314508       13227286650 ONLINE               940 YES /mnt/ramdisk/book/sugar01.dbf    SUGAR
    7        13227536676 2016-04-07 03:00:08      13227207527       13227286650 OFFLINE               32 YES /mnt/ramdisk/book/tea01.dbf      TEA
7 rows selected.

2.通过bbed观察:

BBED> p dba 7,1 kcvfhckp.kcvcptim
ub4 kcvcptim                                @492      0x3626b6b8

BBED> p dba 1,1 kcvfhckp.kcvcptim
ub4 kcvcptim                                @492      0x36271ed5

SCOTT@book> select dump(sysdate,16) from dual ;
DUMP(SYSDATE,16)
------------------------------------------------
Typ=13 Len=8: e0,7,4,7,a,1a,24,0

SCOTT@book> create table tt (cr date);
Table created.

SCOTT@book> insert into tt values ('2016-04-07 10:24:21');
1 row created.

SCOTT@book> commit ;
Commit complete.

--注意我这里有点不规范,直接使用字符变量,因为我定义了环境变量,这样带入没有问题.
$ env | grep NLS
NLS_LANG=AMERICAN_AMERICA.zhs16gbk
NLS_TIMESTAMP_TZ_FORMAT=YYYY-MM-DD HH24:MI:SS.FF TZH:TZM
NLS_TIMESTAMP_FORMAT=YYYY-MM-DD HH24:MI:SS.FF
NLS_DATE_FORMAT=YYYY-MM-DD HH24:MI:SS

SCOTT@book> select dump(cr,16) c40,cr from tt;
C40                                      CR
---------------------------------------- -------------------
Typ=12 Len=7: 78,74,4,7,b,19,16          2016-04-07 10:24:21

--注意保存在数据块的直接dump(sysdate)的不一样,即使这样明显对不上.一般linux表示使用从1970/1/1的秒数.
--所以上面的保存理论讲应该也是秒数.

SCOTT@book> @ &r/16to10 36271ed5
16 to 10 DEC
------------
   908533461

SCOTT@book> select to_date('1970/1/1','yyyy/mm/dd')+908533461/86400 c40 from dual ;
C40
----------------------------------------
1998-10-16 10:24:21

--明显也不对.

SCOTT@book> @ &r/16to10 3626b6b8
16 to 10 DEC
------------
   908506808

SCOTT@book> select 908533461-908506808 from dual ;
908533461-908506808
-------------------
              26653

SCOTT@book> select  (to_date('2016-04-07 10:24:21','yyyy/mm/dd hh24:mi:ss') -  to_date('2016-04-07 03:00:08','yyyy/mm/dd hh24:mi:ss'))*86400 N20 from dual ;
       N20
----------
     26653

--可以发现正好对上,也就是上面的记数单位还是秒.只不过起点不上1970/1/1.

SCOTT@book> select  to_date('2016-04-07 10:24:21','yyyy/mm/dd hh24:mi:ss') - 908533461/86400  c30 from dual ;
C30
------------------------------
1987-06-24 00:00:00

--也就是从这个时间开始记数的.还记得以前写的blog吗?
--[20160119]V$RMAN_OUTPUT的stamp.txt http://blog.itpub.net/267265/viewspace-1979123/
--那里的时间是1987-06-26 00:00:00.相差2天.

--研究这个没什么意思,仅仅当作play!!

时间: 2024-09-17 10:08:37

[20160407]bbed修改文件头2(补充).txt的相关文章

[20160405]bbed修改文件头.txt

[20160405]bbed修改文件头.txt --以前做过一次,重复测试: http://blog.itpub.net/267265/viewspace-746222/ 如果数据库数据文件损坏,并且archivelog损坏,这样无法完全恢复,如果仅仅某个数据文件的scn与其他文件不同步,导致该数据文件无法mount. 正常可以像odu之类的工具恢复.但是在实际上如果修改数据文件的scn保持同步,这样数据库可以正常打开,选择常规的方法imp/exp以及expdp/impdp 方式恢复,这样虽然丢

[20161111]数据库文件头的修复.txt

[20161111]数据库文件头的修复.txt --这里指文件头实际上数据文件第1块(从0算起). --找到一个链接,http://www.cnblogs.com/hrhguanli/p/4708273.html --要修改的信息相对较多. 1 .改动数据的DBA,rdba_kcbh 2 .改动文件的大小,kccfhfsz 3 .改动文件号,kccfhfno 4 .改动文件创建时SCN,kcvfhcrs 5 .改动文件创建时间,kcvfhcrt 6 .改动表空间号,kcvfhtsn 7 .改动相

[20160526]bbed修改数据记录(不等长).txt

[20160526]bbed修改数据记录(不等长).txt --以前做的测试,有点乱,当时没有很好的理解快速提交.而且做的很乱,链接如下: http://blog.itpub.net/267265/viewspace-1193074/ --今天重复测试看看: 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ ------

[20140624]bbed修改数据记录(不等长).txt

[20140624]bbed修改数据记录(不等长).txt http://www.itpub.net/thread-1872851-1-1.html --给出的问题修改记录时,长度没有变化,如果存在变化,修改与原来的不同,要修改kdbr[0]的值. --还有一些细节的步骤. SCOTT@test> @ver BANNER -------------------------------------------------------------------------------- Oracle

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

[BBED] SYSTEM文件头损坏的恢复   1.1  BLOG文档结构图     1.2  前言部分   1.2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① BBED恢复SYSTEM文件头 ② BBED查看文件头的信息     Tips:        ① 若文章代码格式有错乱,推荐使用QQ.搜狗或360浏览器,也可以下载pdf格式的文档来查看,pdf文档下载地址:http://yunpan.cn/cd

如何使用BBED查看SYSTEM文件头的root dba及bootstrap$

数据库版本11.2.0.4 实验思路是:     --其中数据库OPEN时的TRACE信息,可以参考:http://blog.csdn.net/q947817003/article/details/17025489 file#1 block#1==>root dba==>struct ktetb 即先从SYSTEM的数据文件头:file#1 block#1 找到root dba的位置,然后在root dba所在的块内,找到struct ktetb 所描述的块的位置,然后查看struct kte

[20160405]利用bbed修改跳过损坏的索引.txt

[20160405]利用bbed修改跳过损坏的索引.txt --oracle的启动通过system的第一块的rdba(kcvfhrdb) http://blog.itpub.net/267265/viewspace-2016219/ http://blog.itpub.net/267265/viewspace-2022857/ --如果前obj#<=59对象损坏,不允许重建,假设某个索引损坏,是否可以跳过索引启动数据库呢?自己做一个测试. --以sys.undo$的索引i_undo1为例做测试:

[20160413利用bbed修改跳过损坏的索引.txt

[20160413利用bbed修改跳过损坏的索引.txt --前一阵子做过利用bbed修改跳过损坏的索引,这次测试看看破坏索引SYS.I_OBJ1看看. 1.环境: SYS@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ----------------------------------------------

[20171115]恢复数据文件块头3补充.txt

[20171115]恢复数据文件块头3补充.txt --// 昨天做了恢复数据文件块头,通过备份文件直接取出文件块头,覆盖原来的数据块,然后修复. --//补充几点: --1.文件头损坏,无法使用rman的块恢复功能. --2.文件头损坏,dbv检查发现都是坏块.我感觉主要文件块头损坏,dbv无法定位其它剩下的块. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER --------