[20170308]关于redo dump.txt

[20170308]关于redo dump.txt

--//前一阵子在探究是否可以备库的备用日志来恢复主库,当主库在线日志丢失的情况下.遇到一些问题.

DUMP OF REDO FROM FILE '/mnt/ramdisk/book/redo01.log'
Opcodes *.*
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
VALIDATE ONLY
FILE HEADER:
    Compatibility Vsn = 186647552=0xb200400
    Db ID=1337401710=0x4fb7216e, Db Name='BOOK'
    Activation ID=1337448558=0x4fb7d86e
    Control Seq=36141=0x8d2d, File size=102400=0x19000
    File Number=1, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000695, SCN 0x0003175d9565-0xffffffffffff"
thread: 1 nab: 0xffffffff seq: 0x000002b7 hws: 0x1 eot: 1 dis: 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

--不理解这里 hws: 0x1 eot: 1 dis: 0 分别表示什么?刘工给我的答复是:
eot : End Of Thread: indicates if this is the last log
hws = Hdr Write Seq#
dis : DISabled - true if thread disabled at end of this log

--eot 我个人理解就是当前主库正在使用的在线日志.就是状态STATUS=CURRENT.
--dis 就是thread disable的日志.
--hws header write seq# ,我自己还真不好猜测.

--//还是通过例子来猜测看看.

1.环境:
SYS@book> @ &r/ver
BANNER
--------------------------------------------------------------------------------
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

SYS@book> @ &r/logfile
GROUP# STATUS TYPE       MEMBER                           IS_ GROUP# THREAD# SEQUENCE#       BYTES BLOCKSIZE MEMBERS ARC STATUS     FIRST_CHANGE# FIRST_TIME          NEXT_CHANGE# NEXT_TIME
------ ------ ---------- -------------------------------- --- ------ ------- --------- ----------- --------- ------- --- ---------- ------------- ------------------- ------------ -------------------
     1        ONLINE     /mnt/ramdisk/book/redo01.log     NO       1       1       704    52428800       512       1 YES INACTIVE     13277044174 2017-03-08 09:13:23  13277055255 2017-03-08 10:59:38
     2        ONLINE     /mnt/ramdisk/book/redo02.log     NO       2       1       705    52428800       512       1 NO  CURRENT      13277055255 2017-03-08 10:59:38 2.814750E+14
     3        ONLINE     /mnt/ramdisk/book/redo03.log     NO       3       1       703    52428800       512       1 YES INACTIVE     13277042336 2017-03-08 09:01:26  13277044174 2017-03-08 09:13:23
     4        STANDBY    /mnt/ramdisk/book/redostb01.log  NO
     5        STANDBY    /mnt/ramdisk/book/redostb02.log  NO
     6        STANDBY    /mnt/ramdisk/book/redostb03.log  NO
     7        STANDBY    /mnt/ramdisk/book/redostb04.log  NO
7 rows selected.

2.eot : End Of Thread: indicates if this is the last log

SYS@book> alter session set events 'immediate trace name redohdr level 10';
Session altered.

$ grep hws /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_6964.trc | grep eot
thread: 1 nab: 0x3ddb seq: 0x000002c0 hws: 0x9 eot: 0 dis: 0
thread: 1 nab: 0xffffffff seq: 0x000002c1 hws: 0x1 eot: 1 dis: 0
thread: 1 nab: 0x1d29 seq: 0x000002bf hws: 0x6 eot: 0 dis: 0

--//seq# =0x2c1 = 705,就是当前日志,eot=1.表示End Of Thread: indicates if this is the last log.

--//shutdown immediate,再启动到mount状态,执行:
SYS@book> alter session set events 'immediate trace name redohdr level 10';
Session altered.

$ grep hws /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_7143.trc | grep eot
thread: 1 nab: 0x3ddb seq: 0x000002c0 hws: 0x9 eot: 0 dis: 0
thread: 1 nab: 0x119f seq: 0x000002c1 hws: 0x2 eot: 1 dis: 0
thread: 1 nab: 0x1d29 seq: 0x000002bf hws: 0x6 eot: 0 dis: 0

--//shutdown abort,再启动到mount状态,执行:
SYS@book> alter session set events 'immediate trace name redohdr level 10';
Session altered.

$ grep hws /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_7236.trc | grep eot
thread: 1 nab: 0x3ddb seq: 0x000002c0 hws: 0xa eot: 0 dis: 0
thread: 1 nab: 0x119f seq: 0x000002c1 hws: 0x4 eot: 0 dis: 0
thread: 1 nab: 0xffffffff seq: 0x000002c2 hws: 0x2 eot: 1 dis: 0

--//可以发现eot=1就是当前日志.status=CURRENT.
--//另外我也在备库做了一次转储,发现eot=0.这也可能是我为什么使用它在主库恢复使用until canecl时的原因.
--//估计该eot标识就ok了.

3.dis : DISabled - true if thread disabled at end of this log
--//正好我们有一个数据库原来是rac环境,存在2个thread,现在已经改成单机使用,thread已经disable,看看这个的情况:

SYS@xxxxx> @ &r/ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- ----------------------------------------------------------------
x86_64/Linux 2.4.xx            10.2.0.4.0     Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi

SYS@xxxxx> @ &r/logfile
GROUP# STATUS     TYPE       MEMBER                                    IS_ GROUP# THREAD# SEQUENCE#       BYTES MEMBERS ARC STATUS     FIRST_CHANGE# FIRST_TIME
------ ---------- ---------- ----------------------------------------- --- ------ ------- --------- ----------- ------- --- ---------- ------------- -------------------
     1            ONLINE     +G0/xxxxx/onlinelog/group_1.545.772789051 NO       1       1     51377    52428800       2 YES INACTIVE     17771842553 2017-03-08 11:18:51
     1            ONLINE     +G0/xxxxx/onlinelog/group_1.546.772789051 YES      1       1     51377    52428800       2 YES INACTIVE     17771842553 2017-03-08 11:18:51
     2            ONLINE     +G0/xxxxx/onlinelog/group_2.547.772789053 YES      2       1     51378    52428800       2 NO  CURRENT      17771844804 2017-03-08 11:30:17
     2            ONLINE     +G0/xxxxx/onlinelog/group_2.548.772789051 NO       2       1     51378    52428800       2 NO  CURRENT      17771844804 2017-03-08 11:30:17
     3            ONLINE     +G0/xxxxx/onlinelog/group_3.549.772789053 NO       3       2        97    52428800       2 YES INACTIVE      1301639448 2012-01-19 10:44:25
     3            ONLINE     +G0/xxxxx/onlinelog/group_3.550.772789055 YES      3       2        97    52428800       2 YES INACTIVE      1301639448 2012-01-19 10:44:25
     4            ONLINE     +G0/xxxxx/onlinelog/group_4.551.772789055 NO       4       2        98    52428800       2 YES ACTIVE        1301654779 2012-01-19 11:03:25
     4            ONLINE     +G0/xxxxx/onlinelog/group_4.552.772789055 YES      4       2        98    52428800       2 YES ACTIVE        1301654779 2012-01-19 11:03:25
     5            ONLINE     +G0/xxxxx/onlinelog/group_5.553.772789057 NO       5       1     51375    52428800       2 YES INACTIVE     17770789460 2017-03-08 10:34:59
     5            ONLINE     +G0/xxxxx/onlinelog/group_5.554.772789057 YES      5       1     51375    52428800       2 YES INACTIVE     17770789460 2017-03-08 10:34:59
     6            ONLINE     +G0/xxxxx/onlinelog/group_6.555.772789059 NO       6       1     51376    52428800       2 YES INACTIVE     17771481949 2017-03-08 11:08:53
     6            ONLINE     +G0/xxxxx/onlinelog/group_6.556.772789059 YES      6       1     51376    52428800       2 YES INACTIVE     17771481949 2017-03-08 11:08:53
     7            ONLINE     +G0/xxxxx/onlinelog/group_7.557.772789061 NO       7       2        95    52428800       2 YES INACTIVE      1301630320 2012-01-19 10:27:49
     7            ONLINE     +G0/xxxxx/onlinelog/group_7.558.772789061 YES      7       2        95    52428800       2 YES INACTIVE      1301630320 2012-01-19 10:27:49
     8            ONLINE     +G0/xxxxx/onlinelog/group_8.559.772789061 NO       8       2        96    52428800       2 YES INACTIVE      1301633802 2012-01-19 10:35:17
     8            ONLINE     +G0/xxxxx/onlinelog/group_8.560.772789063 YES      8       2        96    52428800       2 YES INACTIVE      1301633802 2012-01-19 10:35:17
16 rows selected.

SYS@xxxxx> alter session set events 'immediate trace name redohdr level 10';
Session altered.

$ grep hws /u01/app/oracle/admin/xxxxx/udump/xxxxx_ora_14297.trc | grep eot
thread: 1 nab: 0x14b8c seq: 0x0000c8b1 hws: 0x2 eot: 0 dis: 0
thread: 1 nab: 0xffffffff seq: 0x0000c8b2 hws: 0x1 eot: 1 dis: 0
thread: 2 nab: 0x2 seq: 0x00000061 hws: 0x2 eot: 0 dis: 0
thread: 2 nab: 0x2 seq: 0x00000062 hws: 0x2 eot: 1 dis: 2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
thread: 1 nab: 0x14b84 seq: 0x0000c8af hws: 0x2 eot: 0 dis: 0
thread: 1 nab: 0x14b7f seq: 0x0000c8b0 hws: 0x2 eot: 0 dis: 0
thread: 2 nab: 0x2 seq: 0x0000005f hws: 0x2 eot: 0 dis: 0
thread: 2 nab: 0x2 seq: 0x00000060 hws: 0x2 eot: 0 dis: 0

--//慢慢体会DISabled - true if thread disabled at end of this log.也就是没有disable的话.这里应该都是0.
--//这里等于2,表示thread号.

4.hws = Hdr Write Seq#

--//header write seq# 什么意思?

SYS@book> alter session set events 'immediate trace name controlf level 3';
Session altered.

$ grep hws /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_7265.trc
siz: 0x19000 seq: 0x000002c0 hws: 0xa bsz: 512 nab: 0x3ddb flg: 0x1 dup: 1
siz: 0x19000 seq: 0x000002c1 hws: 0x4 bsz: 512 nab: 0x119f flg: 0x1 dup: 1
siz: 0x19000 seq: 0x000002c2 hws: 0x2 bsz: 512 nab: 0xffffffff flg: 0x8 dup: 1
siz: 0x19000 seq: 0x00000000 hws: 0x1 bsz: 512 nab: 0x2 flg: 0x21 dup: 1
siz: 0x19000 seq: 0x00000000 hws: 0x1 bsz: 512 nab: 0x2 flg: 0x21 dup: 1
siz: 0x19000 seq: 0x00000000 hws: 0x1 bsz: 512 nab: 0x2 flg: 0x21 dup: 1
siz: 0x19000 seq: 0x00000000 hws: 0x1 bsz: 512 nab: 0x2 flg: 0x21 dup: 1

SYS@book> alter session set events 'immediate trace name redohdr level 10';
Session altered.

$ grep hws /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_7281.trc | grep eot
thread: 1 nab: 0x3ddb seq: 0x000002c0 hws: 0xa eot: 0 dis: 0
thread: 1 nab: 0x119f seq: 0x000002c1 hws: 0x4 eot: 0 dis: 0
thread: 1 nab: 0xffffffff seq: 0x000002c2 hws: 0x2 eot: 1 dis: 0
thread: 0 nab: 0x2 seq: 0x00000000 hws: 0x1 eot: 0 dis: 0
thread: 0 nab: 0x2 seq: 0x00000000 hws: 0x1 eot: 0 dis: 0
thread: 0 nab: 0x2 seq: 0x00000000 hws: 0x1 eot: 0 dis: 0
thread: 0 nab: 0x2 seq: 0x00000000 hws: 0x1 eot: 0 dis: 0

--//很明显控制文件也记录类似的信息.但是还是不明白hws表示什么??

时间： 2024-07-29 21:39:58

[20170308]关于redo dump.txt的相关文章

[20170411]bbed计算redo检查和.txt

[20170411]bbed计算redo检查和.txt --前一阵子做测试,需要一个计算器做异或的操作,链接http://blog.itpub.net/267265/viewspace-2134945/ --正好前几天开会遇到熟人,谈起我写的脚本很实用.我说不支持管道操作不是很好,对方讲支持,他自己就是这样用的. $ cat ~/bin/xor.sh #! /bin/bash # just play , calc xor!! s='0' for i in $(cat $1| tr 'a-f' '

[20130520]统计那个对象生成的redo多.txt

[20130520]统计那个对象生成的redo多.txt http://timothyhopkins.net/2009/09/summarise-redo-by-object/ 如果统计那个对象生成的redo多,一直是我比较头疼的问题.我以前遇到3次程序员编程错误,导致生成大量redo,要找到这些问题可以通过awr,ash等报表,logminer来确定是那个对象执行问题,但是有时候定位问题并不是很好. 昨天找到以上链接,通过dump redo或者archivelog就可以知道那些对象生成的red

[20141111]11G redo暴涨.txt

[20141111]11G redo暴涨.txt --新上线生产系统日志出现暴涨,当天达到了400G,正常业务每天7G上下,导致dataguard,备份出现问题,磁盘空间不足 --自己做一些调查: SYS@xxxx> @ ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- -----------------------------------

[20170308]再谈hugepages.txt

[20170308]再谈hugepages.txt --//节前跟别人的交流,不幸被我言中.当时是去年5月份的事前,系统迁移,我去观摩,我感觉很奇怪的是内存128G的机器,不知道为什么不 --//应用hugepages,让我吃惊对方并不知道.因为毕竟是别的系统,别人如何做我无权过问.我当时只是提醒如果连接用户数量大,按照他们 --//当时的是设置,有可能会出现内存不足的情况. --//我在链接http://blog.itpub.net/267265/viewspace-2128811/的测试中:

[20170215]再次理解flush redo.txt

[20170215]再次理解flush redo.txt --链接: http://blog.itpub.net/267265/viewspace-1992583/ http://blog.itpub.net/267265/viewspace-1992840/ 在Oracle 11g里,Data Guard 切换多了一个新的功能:flush redo. flush redo就是出现问题时,Flush可以把没有发送的redo从主库传送到standby数据库.而只要主库能启动到mount状态,那么F

[20170310]oracle内部时间戳的转换.txt

[20170310]oracle内部时间戳的转换.txt --//昨天验证v$archived_log.stamp时,链接如下http://blog.itpub.net/267265/viewspace-2135044/,才发现自己以前犯了严重错误. --//想起http://www.juliandyke.com/Diagnostics/Dumps/RedoLogs.php转储redo时time参数使用: TIME The minimum and maximum time is a decima

[20170412]分析重做日志.txt

[20170412]分析重做日志.txt --//自己很少做重做日志转储,测试看看. 1.环境: SCOTT@book> @ &r/ver1 PORT_STRING                    VERSION        BANNER ------------------------------ -------------- ------------------------------------------------------------------------------

[20170302]异常恢复scn到那里3.txt

[20170302]异常恢复scn到那里3.txt --//如果oracle数据库异常关闭,打开数据库自动执行实例恢复,这个恢复scn到那里呢? --//通过例子说明:实际上http://blog.itpub.net/267265/viewspace-2134551/链接已经提到,重复测试: 1.环境: SYS@book> @ &r/ver BANNER ---------------------------------------------------------------------

[20170309]关于在线日志与归档2.txt

[20170309]关于在线日志与归档2.txt --//当日志写满了,或者执行手工了切换,再或者rman备份时有时也会触发日志切换: alter system switch logfile ; alter system archive log current ; --//本文简单探究日志归档是如何保存的.探查日志文件头块. 1.环境: --//启动到mount状态. SYS@book> @ &r/ver BANNER ------------------------------------