[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.dbf
-rw-r----- 1 oracle oinstall  43M 2017-03-08 15:56:59 0001_0000051935_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-01-24 09:01:13 0001_0000051406_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-01-17 23:03:54 0001_0000051326_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-02-03 09:04:49 0001_0000051495_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-02-13 17:54:24 0001_0000051631_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-01-11 09:01:24 0001_0000051242_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-02-16 09:34:58 0001_0000051668_628034536.dbf
-rw-r----- 1 oracle oinstall  42M 2017-01-11 23:00:25 0001_0000051250_628034536.dbf

--//这样看看这些没有写入日志的数据块情况:

--//看看49M这个位置开始的情况.

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       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.

--// 拿/mnt/ramdisk/book/redo02.log 分析.
--// 49m 位于49*1024*1024=51380224 49*1024*1024/512=100352块位置.

2.探究:

$ xxd -c 16 -seek 51380224 -l 512 -a /mnt/ramdisk/book/redo02.log
3100000: 0122 0000 0088 0100 0000 0000 0080 002a  ...............*
3100010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
31001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

--//可以发现仅仅前面16字节由信息,实际上这个就是日志日志块的header为16bytes.

$ xxd -c 16 -seek 51380224 -l 512 -a /mnt/ramdisk/book/redo01.log
3100000: 0122 0000 0088 0100 0000 0000 0080 002a  ...............*
3100010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
31001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

$ xxd -c 16 -seek 51380224 -l 512 -a /mnt/ramdisk/book/redo03.log
3100000: 0122 0000 0088 0100 0000 0000 0080 002a  ...............*
3100010: 0000 0000 0000 0000 0000 0000 0000 0000  ................
*
31001f0: 0000 0000 0000 0000 0000 0000 0000 0000  ................

$ xxd -c 16 -seek 51380224 -l 512 -a /mnt/ramdisk/book/redo03.log |md5sum
05820513d808b3517ff90a57f093ac82  -
$ xxd -c 16 -seek 51380224 -l 512 -a /mnt/ramdisk/book/redo02.log |md5sum
05820513d808b3517ff90a57f093ac82  -
$ xxd -c 16 -seek 51380224 -l 512 -a /mnt/ramdisk/book/redo01.log |md5sum
05820513d808b3517ff90a57f093ac82  -

--//说明位置一样对于"空白"内容是一样的,而且里面不可能有group#号信息.这样完全可以从一个好的日志文件尾部来合并归档文件来建立
--//一个好的日志文件.从而欺骗oracle.

--//继续探究这16字节内容:
--//偏移0x14-0x15 是检查和.前面测试已经说明.
49*1024*1024=51380224
49*1024*1024/512=100352
100352 = 0x18800

3100000: 0122 0000 0088 0100 0000 0000 0080 002a  ...............*
                   ~~~~~~~~~
--//4个字节颠倒 0001 8800,顺便复习使用od查看(各种命令参数不同意,烦!!,注4个字节我对调显示):

$ od  -j 51380224  -N 512 -t x4 /mnt/ramdisk/book/redo02.log
304000000 00002201 00018800 00000000 2a008000
304000020 00000000 00000000 00000000 00000000
*
304001000
--//也就是第4-7偏移表示块地址.

时间: 2024-11-06 07:26:38

[20170310]关于在线日志与归档4.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 --------------------------------------

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

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

[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特性以及具体位

[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/ --//看了一

[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