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

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

--//当日志写满了,或者执行手工了切换,再或者rman备份时有时也会触发日志切换:
alter system switch logfile ;
alter system archive log current ;

--//本文简单探究日志归档是如何保存的.探查日志文件头块.

1.环境:
--//启动到mount状态.

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       695    52428800       512       1 YES INACTIVE     13276910949 2017-02-28 14:40:12  13276931102 2017-03-09 10:01:48
     2            ONLINE     /mnt/ramdisk/book/redo02.log    NO       2       1       696    52428800       512       1 YES INACTIVE     13276931102 2017-03-09 10:01:48  13276931986 2017-03-09 10:02:36
     3            ONLINE     /mnt/ramdisk/book/redo03.log    NO       3       1       697    52428800       512       1 NO  CURRENT      13276931986 2017-03-09 10:02:36 2.814750E+14
     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.

--//仅仅拿seq#=696 来研究.

$ ls -l /mnt/ramdisk/book/redo02.log /u01/app/oracle/archivelog/book/1_696_896605872.dbf
-rw-r----- 1 oracle oinstall 52429312 2017-03-09 10:02:36 /mnt/ramdisk/book/redo02.log
-rw-r----- 1 oracle oinstall  1626112 2017-03-09 10:02:38 /u01/app/oracle/archivelog/book/1_696_896605872.dbf

--//前面我们探查了日志文件的OS块.下面将继续探究日志的文件头块1.

2.取出文件头保存为二进制以及转储格式
$ dd if=/mnt/ramdisk/book/redo01.log bs=512 count=1 skip=1 of=r1.dd
1+0 records in
1+0 records out
512 bytes (512 B) copied, 6.5894e-05 seconds, 7.8 MB/s

$ dd if=/u01/app/oracle/archivelog/book/1_696_896605872.dbf bs=512 count=1 skip=1 of=d1.dd
1+0 records in
1+0 records out
512 bytes (512 B) copied, 5.7258e-05 seconds, 8.9 MB/s

$ xxd -c 16 d1.dd  > d1.txt
$ xxd -c 16 r1.dd  > r1.txt

$ diff r1.txt d1.txt
1c1
< 0000000: 0122 0000 0100 0000 b802 0000 0080 c7b6  ."............?
---
> 0000000: 0122 0000 0100 0000 b802 0000 0080 d6b6  ."............?
15c15
< 00000e0: 0300 0000 0c4c eb37 0000 0000 0000 8000  .....L?........
---
> 00000e0: 0300 0000 0c4c eb37 0000 0000 1100 8000  .....L?........

--//偏移0x14-0x15是检查和,对于日志文件.仅仅修改了 0xeb-0xef出为0x00008000->0x11008000.

SYS@book> alter system dump logfile '/u01/app/oracle/archivelog/book/1_696_896605872.dbf' validate;
System altered.

DUMP OF REDO FROM FILE '/u01/app/oracle/archivelog/book/1_696_896605872.dbf'
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=36178=0x8d52, File size=102400=0x19000
    File Number=2, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000696, SCN 0x0003175de41e-0x0003175de792"
thread: 1 nab: 0xc68 seq: 0x000002b8 hws: 0x3 eot: 0 dis: 0
resetlogs count: 0x35711eb0 scn: 0x0000.000e2006 (925702)
prev resetlogs count: 0x3121c97a scn: 0x0000.00000001 (1)
Low  scn: 0x0003.175de41e (13276931102) 03/09/2017 10:01:48
Next scn: 0x0003.175de792 (13276931986) 03/09/2017 10:02:36
Enabled scn: 0x0000.000e2006 (925702) 11/24/2015 09:11:12
Thread closed scn: 0x0003.175de41e (13276931102) 03/09/2017 10:01:48
Disk cksum: 0xb6d6 Calc cksum: 0xb6d6
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery  01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 283 blocks
End-of-redo stream : No
Unprotected mode
Miscellaneous flags: 0x800011
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
Zero blocks: 8
Format ID is 2
redo log key is 635b658f7133c1a828b05e569341c54e
redo log key flag is 5
Enabled redo threads: 1
END OF REDO DUMP

$ egrep "^DUMP|^ Miscellaneous" /u01/app/oracle/diag/rdbms/book/book/trace/book_ora_20294.trc
DUMP OF REDO FROM FILE '/u01/app/oracle/archivelog/book/1_696_896605872.dbf'
Miscellaneous flags: 0x800011
DUMP OF REDO FROM FILE '/u01/app/oracle/archivelog/book/1_695_896605872.dbf'
Miscellaneous flags: 0x802011
DUMP OF REDO FROM FILE '/mnt/ramdisk/book/redo02.log'
Miscellaneous flags: 0x800000

--//感觉就是前面0x80足够.

3.再看看别的服务器:

select 'alter system dump logfile ''' ||name || ''' validate;' from v$archived_log where dest_id=1 and name is not null order by stamp desc,name;
--输出保存文件,执行它:

--//服务器1:
$ egrep "^ Miscellaneous" xxxxx_ora_29111.trc | uniq -c
    100  Miscellaneous flags: 0x800011
--//可以发现仅仅就是修改0x2eb-0x2fe 为0x1100,全是0x800011.

--//服务器1:
$  egrep "^ Miscellaneous" /u01/app/oracle/diag/rdbms/xxxx/xxxx1/trace/xxxx_ora_16752.trc | sort |uniq -c
     78  Miscellaneous flags: 0x800011
     13  Miscellaneous flags: 0x800021
--//嗯,存在2种可能.

$  egrep "^DUMP|^ Miscellaneous" /u01/app/oracle/diag/rdbms/xxxx/xxxx1/trace/xxxx1_ora_16752.trc | grep -B1 0x800021 | grep "'" | cut -d" " -f6
'+RECOC1/xxxx/archivelog/2017_03_09/thread_2_seq_2695.564.938158875'
'+RECOC1/xxxx/archivelog/2017_03_08/thread_1_seq_3401.388.938060823'
'+RECOC1/xxxx/archivelog/2017_03_07/thread_2_seq_2690.1139.937974461'
'+RECOC1/xxxx/archivelog/2017_03_04/thread_2_seq_2683.420.937715223'
'+RECOC1/xxxx/archivelog/2017_03_03/thread_2_seq_2681.1194.937628857'
'+RECOC1/xxxx/archivelog/2017_03_01/thread_2_seq_2676.1138.937456023'
'+RECOC1/xxxx/archivelog/2017_02_28/thread_2_seq_2674.1242.937110459'
'+RECOC1/xxxx/archivelog/2017_02_25/thread_2_seq_2668.951.936851263'
'+RECOC1/xxxx/archivelog/2017_02_24/thread_2_seq_2665.1050.936764823'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3359.1085.936714747'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2663.344.936714739'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3357.832.936714663'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2661.907.936689855'
'+RECOC1/xxxx/archivelog/2017_03_09/thread_2_seq_2695.564.938158875'
'+RECOC1/xxxx/archivelog/2017_03_08/thread_1_seq_3401.388.938060823'
'+RECOC1/xxxx/archivelog/2017_03_07/thread_2_seq_2690.1139.937974461'
'+RECOC1/xxxx/archivelog/2017_03_04/thread_2_seq_2683.420.937715223'
'+RECOC1/xxxx/archivelog/2017_03_03/thread_2_seq_2681.1194.937628857'
'+RECOC1/xxxx/archivelog/2017_03_01/thread_2_seq_2676.1138.937456023'
'+RECOC1/xxxx/archivelog/2017_02_28/thread_2_seq_2674.1242.937110459'
'+RECOC1/xxxx/archivelog/2017_02_25/thread_2_seq_2668.951.936851263'
'+RECOC1/xxxx/archivelog/2017_02_24/thread_2_seq_2665.1050.936764823'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3359.1085.936714747'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2663.344.936714739'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3357.832.936714663'
'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2661.907.936689855'

SELECT distinct creator
    FROM v$archived_log
   WHERE     name IN ('+RECOC1/xxxx/archivelog/2017_03_09/thread_2_seq_2695.564.938158875'
                     ,'+RECOC1/xxxx/archivelog/2017_03_08/thread_1_seq_3401.388.938060823'
                     ,'+RECOC1/xxxx/archivelog/2017_03_07/thread_2_seq_2690.1139.937974461'
                     ,'+RECOC1/xxxx/archivelog/2017_03_04/thread_2_seq_2683.420.937715223'
                     ,'+RECOC1/xxxx/archivelog/2017_03_03/thread_2_seq_2681.1194.937628857'
                     ,'+RECOC1/xxxx/archivelog/2017_03_01/thread_2_seq_2676.1138.937456023'
                     ,'+RECOC1/xxxx/archivelog/2017_02_28/thread_2_seq_2674.1242.937110459'
                     ,'+RECOC1/xxxx/archivelog/2017_02_25/thread_2_seq_2668.951.936851263'
                     ,'+RECOC1/xxxx/archivelog/2017_02_24/thread_2_seq_2665.1050.936764823'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3359.1085.936714747'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2663.344.936714739'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3357.832.936714663'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2661.907.936689855'
                     ,'+RECOC1/xxxx/archivelog/2017_03_09/thread_2_seq_2695.564.938158875'
                     ,'+RECOC1/xxxx/archivelog/2017_03_08/thread_1_seq_3401.388.938060823'
                     ,'+RECOC1/xxxx/archivelog/2017_03_07/thread_2_seq_2690.1139.937974461'
                     ,'+RECOC1/xxxx/archivelog/2017_03_04/thread_2_seq_2683.420.937715223'
                     ,'+RECOC1/xxxx/archivelog/2017_03_03/thread_2_seq_2681.1194.937628857'
                     ,'+RECOC1/xxxx/archivelog/2017_03_01/thread_2_seq_2676.1138.937456023'
                     ,'+RECOC1/xxxx/archivelog/2017_02_28/thread_2_seq_2674.1242.937110459'
                     ,'+RECOC1/xxxx/archivelog/2017_02_25/thread_2_seq_2668.951.936851263'
                     ,'+RECOC1/xxxx/archivelog/2017_02_24/thread_2_seq_2665.1050.936764823'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3359.1085.936714747'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2663.344.936714739'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_1_seq_3357.832.936714663'
                     ,'+RECOC1/xxxx/archivelog/2017_02_23/thread_2_seq_2661.907.936689855')
         AND dest_id = 1;

CREATOR
-------
FGRD
        
--//噢.明白了0x800021是执行alter system archive log current ;(也许还包含全备份时的情况)手工切换日志的标识.前面的服务器1
--//没有因为是测试库,是因为完全没有人执行过这样的命令.
--//参考链接:http://blog.itpub.net/267265/viewspace-1711428/

--//如果你看gv$archived_log视图定义:
字段creator的定义如下,来之底层x$kccal.alflg:

DECODE
       (
          BITAND (alflg, 4)
         ,4, 'RFS'
         ,DECODE
          (
             BITAND (alflg, 16 + 32 + 64 + 128 + 256)
            ,16, 'ARCH'
            ,32, 'FGRD'
            ,64, 'RMAN'
            ,128, 'SRMN'
            ,256, 'LGWR'
            ,'UNKNOWN'
          )
       )

--//查找其中1个.
SYS@xxxx1> select alflg from x$kccal where ALNAM='+RECOC1/xxxx/archivelog/2017_03_07/thread_2_seq_2690.1139.937974461';
     ALFLG
----------
        34

--//对应二进制 10010. 32对应就是FGRD.

--//btw,我也看了一个10g的库.结果如下:
    606  Miscellaneous flags: 0x11
    257  Miscellaneous flags: 0x21
--//感觉10g的数据库格式还不一样.11g做了许多改动.而且Miscellaneous flags: 0x21的creator='FGRD'.再次佐证自己的判断.

--//有此可以得出结论:

--//11g在归档时仅仅修改Miscellaneous flags: 0x800011 或者 0x800021.
0x800011 是正常切换.
0x800021 是手工执行alter system archive log current ;切换.

4.总结:
--//日志文件头在转储成归档时,修改 Miscellaneous flags: 0x800011或者0x800011.偏移位于0x2eb-0x2ef处.当然检查和也需要重新计
--//算.当然也可能存在别的可能,我没有遇到.

时间： 2024-11-06 07:18:44

[20170309]关于在线日志与归档2.txt的相关文章

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

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

[20170310]关于在线日志与归档4.txt

[20170310]关于在线日志与归档4.txt --//如果你顺便看归档日志目录,在线日志50M,你可以发现最大归档43M上下.也就是在线日志大于45M后面这些块基本不会写入日志记录信息. --//比如查询如下: #  ls -l -S -h /data/log/ORCL/archivelog/| head -10 total 27G -rw-r----- 1 oracle oinstall  43M 2017-03-02 10:53:07 0001_0000051850_628034536.

[20170309]dg环境下在线日志损坏13.txt

[20170309]dg环境下在线日志损坏13.txt http://blog.itpub.net/267265/viewspace-2134665/ http://blog.itpub.net/267265/viewspace-2134481/ --//按照如下链接,拷贝备用日志到主库,修改文件头偏移0x230 日志组号.以及hws,eot对应位置,欺骗oracle是正常的日志文件. http://blog.itpub.net/267265/viewspace-2134816/ --//看了一

[20170307]dg环境下在线日志损坏12.txt

[20170307]dg环境下在线日志损坏12.txt http://blog.itpub.net/267265/viewspace-2134665/ http://blog.itpub.net/267265/viewspace-2134481/ --//前面的链接我测试了如果日志实时传输与应用的情况下,主库的崩溃并且在线日志删除的情况下(包括主机的备用日志)情况下, --//利用备库接收日志来恢复主库的情况.做一点点总结: 1.将备用日志拷贝过来,必须执行如下命令,加入最后应用的scn号. r

[20170303]dg环境下在线日志损坏8.txt

[20170303]dg环境下在线日志损坏8.txt --前面的测试,链接http://blog.itpub.net/267265/viewspace-2134481/ --前面的测试必须使用recover database using backup controlfile until change 13276911099; 才能恢复到结尾. --但是由于主备库scn相差1,在open resetlog时备库的数据文件头scn号减1,采用应用日志. --前面学习了解文件头fuzzy特性以及具体位

[20160830]清除日志与跟踪文件.txt

[20160830]清除日志与跟踪文件.txt --我们数据库的dataguard磁盘空间非常紧张,前几天因为一些异常业务操作,导致dataguard磁盘空间不足, --日志切换情况: Date                Day    Total   H0   h1   h2   h3   h4   h5   h6   h7   h8   h9  h10  h11  h12  h13  h14  h15  h16  h17  h18  h19  h20  h21  h22  h23    

ORA-16038的解决(日志无法归档)

ORA-16038的解决 数据库装载完毕. ORA-16038: 日志 3 序列号 5035 无法归档 ORA-19809: 超出了恢复文件数的限制 ORA-00312: 联机日志 3 线程 1: ......REDO03.LOG' DB是归档模式, 每个日志组只有一个文件(新太公司的人通常使用的方法,FT), 没办法, 搜寻文档和晚上的资料, 有如下的解决方法: 损坏非当前联机日志: 1.启动数据库,遇到ORA-00312 or ORA-00313错误,如: ORA-00313: open f

DELETE OBSOLETE不删除归档日志以及归档的备份集

今天遇到一个奇怪的事情,使用OBSOLETE不删除归档日志,而且也不删除过期的归档的BACKUP SET 从delete obsolete的概念来看如下: The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:                                                                                                         

RAC Ora-27054 导致使用NFS的日志不能归档

日志错误如下 WARNING:NFS file system /archive mounted with incorrect optionsWARNING:Expected NFS mount options: rsize>=16384,wsize>=16384,hard,noac/actimeo=0Sat Sep 22 18:29:43 2012Errors in file /home/oracle/product/admin/rac/udump/rac1_ora_23076.trc:ORA