[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/

--//看了一些文档,在论坛问一下,感觉修改组号以及eot=1就ok了,hws不用修改.到现在还不理解hws表示什么??
--//我在论坛问hws等表示什么?链接
http://www.itpub.net/thread-2084723-1-1.html
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=1明显表示当前日志,而备用日志这里是0,感觉修改这里才是关键.
--//测试看看这样的情况:

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 NO  CURRENT      13276910949 2017-02-28 14:40:12 2.814750E+14
     2        ONLINE  /mnt/ramdisk/book/redo02.log    NO       2       1       693    52428800       512       1 YES INACTIVE     13276889179 2017-02-27 08:59:01  13276910486 2017-02-28 14:40:06
     3        ONLINE  /mnt/ramdisk/book/redo03.log    NO       3       1       694    52428800       512       1 YES ACTIVE       13276910486 2017-02-28 14:40:06  13276910949 2017-02-28 14:40:12
     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.

--//一些操作参考,不再重复:
http://blog.itpub.net/267265/viewspace-2134816/

2.拷贝备用日志到主机:
$ scp /mnt/ramdisk/book/redostb01.log oracle@192.168.100.78:/mnt/ramdisk/book/redo01.log
oracle@192.168.100.78's password:
redostb01.log      100%   50MB  25.0MB/s   00:02

--//注意这样因为redo的文件头不一样,oracle不会认为那个文件group#1的.

3.修改备用日志文件.

$ bvi80 -s 512 -b 512 /mnt/ramdisk/book/redo01.log
00000200  01 22 00 00 01 00 00 00 B7 02 00 00 00 80 9C B5 ................
00000210  00 00 00 00 00 04 20 0B 6E 21 B7 4F 42 4F 4F 4B ...... .n!.OBOOK
00000220  00 00 00 00 2D 8D 00 00 00 90 01 00 00 02 00 00 ....-...........
00000230  04 00 02 00 6E D8 B7 4F 00 00 00 00 00 00 00 00 ....n..O........
          ~~
00000240  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000250  00 00 00 00 00 00 00 00 00 00 00 00 54 68 72 65 ............Thre
00000260  61 64 20 30 30 30 31 2C 20 53 65 71 23 20 30 30 ad 0001, Seq# 00
00000270  30 30 30 30 30 36 39 35 2C 20 53 43 4E 20 30 78 00000695, SCN 0x
00000280  30 30 30 33 31 37 35 64 39 35 36 35 2D 30 78 66 0003175d9565-0xf
00000290  66 66 66 66 66 66 66 66 66 66 66 00 FF FF FF FF fffffffffff.....
000002A0  B0 1E 71 35 06 20 0E 00 00 00 00 00 02 00 00 00 ..q5. ..........
000002B0  01 00 00 00 65 95 5D 17 03 00 00 00 4C BB DB 37 ....e.].....L..7
000002C0  FF FF FF FF FF FF 00 00 00 00 00 00 00 00 00 02 ................
                                              ~~
000002D0  06 20 0E 00 00 00 00 00 B0 1E 71 35 65 95 5D 17 . ........q5e.].
000002E0  03 00 00 00 4C BB DB 37 00 00 00 00 00 20 82 00 ....L..7..... ..
000002F0  00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 ................
00000300  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000310  00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 ................
00000320  00 00 00 00 7A C9 21 31 00 00 00 00 00 00 00 00 ....z.!1........
00000330  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000340  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000350  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000360  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000370  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000380  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000390  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003A0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003B0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003C0  12 E9 26 F7 7B 40 C0 80 DC 71 6E 8A 26 4C 32 9F ..&.{@...qn.&L2.
000003D0  27 F7 6C 1F 74 8A 40 20 48 9C 47 0B 46 31 76 E0 '.l.t.@ H.G.F1v.
000003E0  05 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
000003F0  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000400 }

--//修改0x230处 0x04=>0x01. 将group#=1
--//修改0x2CA处 0x00=>0x01. 将eot=1.
--//9CB5 0400 0100 0000 0100  重新做异或操作

$ xor.sh a.txt
9CB5
0400
0100
0000
0100
xor result: 98B5

--//修改0x14,0x15 9CB5=>98B5
--//做异或参考链接:http://blog.itpub.net/267265/viewspace-2134945/

SYS@book> alter system dump logfile '/mnt/ramdisk/book/redo01.log' validate;
System altered.

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: 0x2 eot: 1 dis: 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
resetlogs count: 0x35711eb0 scn: 0x0000.000e2006 (925702)
prev resetlogs count: 0x3121c97a scn: 0x0000.00000001 (1)
Low  scn: 0x0003.175d9565 (13276910949) 02/28/2017 14:40:12
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
Enabled scn: 0x0000.000e2006 (925702) 11/24/2015 09:11:12
Thread closed scn: 0x0003.175d9565 (13276910949) 02/28/2017 14:40:12
Disk cksum: 0xb598 Calc cksum: 0xb598
Terminal recovery stop scn: 0x0000.00000000
Terminal recovery  01/01/1988 00:00:00
Most recent redo scn: 0x0000.00000000
Largest LWN: 0 blocks
End-of-redo stream : No
Maximize performance mode
Miscellaneous flags: 0x822000
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
Zero blocks: 0
Format ID is 2
redo log key is 12e926f77b40c080dc716e8a264c329f
redo log key flag is 5
Enabled redo threads: 1
END OF REDO DUMP

--//注意看~部分.

4.测试恢复:

SYS@book> recover database  ;
ORA-00279: change 13276910487 generated at 02/28/2017 14:40:06 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/archivelog/book/1_694_896605872.dbf
ORA-00280: change 13276910487 for thread 1 is in sequence #694
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto
ORA-00283: recovery session canceled due to errors
ORA-00338: log 1 of thread 1 is more recent than control file
ORA-00312: online log 1 thread 1: '/mnt/ramdisk/book/redo01.log'
ORA-01112: media recovery not started

SYS@book> recover database  until cancel;
ORA-00279: change 13276910949 generated at 02/28/2017 14:40:12 needed for thread 1
ORA-00289: suggestion : /u01/app/oracle/archivelog/book/1_695_896605872.dbf
ORA-00280: change 13276910949 for thread 1 is in sequence #695
Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
/mnt/ramdisk/book/redo01.log
Log applied.
Media recovery complete.

--//最终确定仅仅修改日志组号以及eot标识为1.

SYS@book> SELECT file#, CHECKPOINT_CHANGE#, CHECKPOINT_TIME,CREATION_CHANGE#  , RESETLOGS_CHANGE#,status, CHECKPOINT_COUNT,fuzzy,name,tablespace_name  FROM v$datafile_header where file#=1;
FILE# CHECKPOINT_CHANGE# CHECKPOINT_TIME     CREATION_CHANGE# RESETLOGS_CHANGE# STATUS     CHECKPOINT_COUNT FUZ NAME                           TABLESPACE_NAME
----- ------------------ ------------------- ---------------- ----------------- ---------- ---------------- --- ------------------------------ ---------------
    1        13276911100 2017-02-28 14:42:35                7            925702 ONLINE                  839 NO  /mnt/ramdisk/book/system01.dbf SYSTEM

--//scn = 13276911100.

--//剩下的重复链接http://blog.itpub.net/267265/viewspace-2134816/操作.
--//确认这个文件记录的是seq#=694的日志文件.
$ scp /mnt/ramdisk/book/redostb02.log oracle@192.168.100.78:/mnt/ramdisk/book/redo03.log
oracle@192.168.100.78's password:
redostb02.log       100%   50MB  50.0MB/s   00:01

$ bvi80 -b 512 -s 512 /mnt/ramdisk/book/redo03.log
--//仅仅需要修改0x230处 0x0500 => 0x0300,重新计算检查和.
2B19
0500
0300
----
2D19

--//这个过程略.
SYS@book> alter database clear  logfile group 2 ;
Database altered.

alter database clear  logfile group 4 ;
alter database clear  logfile group 5 ;
alter database clear  logfile group 6 ;
alter database clear  logfile group 7 ;

5.打开看看:

SYS@book> alter database open ;
alter database open
*
ERROR at line 1:
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open

SYS@book> alter database open noresetlogs;
Database altered.
--//还第一次这样打这个命令使用noresetlogs打开.
--//ok,可以确定日志组号以及eot标识就ok了.

SYS@bookdg> @ &r/dg/dg
PROCESS       PID STATUS       CLIENT_P GROUP# THREAD#  SEQUENCE#     BLOCK#     BLOCKS DELAY_MINS
--------- ------- ------------ -------- ------ ------- ---------- ---------- ---------- ----------
RFS         25707 IDLE         UNKNOWN  N/A          0          0          0          0          0
RFS         25709 IDLE         LGWR     3            1        697         19          1          0
ARCH        25658 CLOSING      ARCH     4            1        695          1        154          0
MRP0        25701 APPLYING_LOG N/A      N/A          1        697         19     102400          0
--//日志传输与应用没有问题.

时间： 2025-01-07 12:06:13

[20170309]dg环境下在线日志损坏13.txt的相关文章

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

视角 | 多容器环境下的日志管理难？有人做起了这个生意

本文讲的是视角 | 多容器环境下的日志管理难?有人做起了这个生意,[编者的话]本文介绍了一个新的工具SPM,它用于解决在多容器环境下日志管理所遇到的问题,同时它整合了多种功能,避免了以往需要安装多种工具的麻烦,配合Kibana的展示功能,使得该工具还是值得一试的. 在微服务流行的今天,日志路由和解析的传统静态配置方法已经有点吃力:事实上,它还带来了额外的复杂度和资源消耗.相对的,这使得不能运行在单机上的微服务的数量降低了. 在SPM for Docker整合的日志管理功能中,对微服务进行了支持,

lnmp环境下网站日志进行分割配置

这个教程适用于Nginx用户及lnmp用户参考的参考,其他环境下,大叔不鸡道哈! 首先我们得用root 登陆执行 #!/bin/bash #function:cut nginx log files for lnmp v0.5 and v0.6 #set the path to nginx log files log_files_path="/home/wwwlogs/" log_files_dir=${log_files_path}$(date -d "yesterday&q

【DG】DG环境的日常巡检

DG环境的日常巡检 目录 1.DG环境的日常巡检4 1.1.主库环境检查4 1.1.1.主库实例启动状态检查4 1.1.2.主库启动模式检查4 1.1.3.主库DG环境的保护模式检查4 1.1.4.主库用于控制日志同步的参数检查4 1.1.5.主库查看是否开启强制日志功能5 1.1.6.主库上查看设置的归档日志路径是否可用5 1.1.7.主库上查询归档日志的应用情况6 1.1.8.主库上查看DG环境进程的状态6 1.1.9.主库上查看DG的状态信息7 1.1.10.主库SWITCH OVER角色

如何使用线程局部存储实现多线程下的日志系统

概述 通常来说,在应用程序中需要日志来记录程序运行的状态,以便后期问题的跟踪定位.在日志系统的设计中,通常会有一个总的日志系统来统一协调这些日志的设置如位置.输出级别和内容等.在多线程编程中,当每个线程都需要输出日志时,因为要考虑线程间的同步,日志系统的设计更加复杂. 在单线程应用程序中,通常使用一个日志单例向某个文件输出应用运行过程中的重要日志信息,但是在多线程环境中,这样做显然不好,因为各个线程打印出的日志会错综复杂从而使得日志文件不容易阅读和跟踪.比较好的办法是主线程记录自己的日志,各个子

【故障处理】DG环境主库丢失归档情况下数据文件的恢复

[故障处理]DG环境主库丢失归档情况下数据文件的恢复 1  BLOG文档结构图     2  前言部分   2.1  导读和注意事项 各位技术爱好者,看完本文后,你可以掌握如下的技能,也可以学到一些其它你所不知道的知识,~O(∩_∩)O~: ① BBED的编译 ② BBED修改文件头让其跳过归档从而可以ONLINE(重点) ③ OS命名格式转换为ASM的命名格式 ④ DG环境中备库丢失数据文件的情况下的处理过程(重点) ⑤ 数据文件OFFLINE后应立即做一次RECOVER操作 ⑥ BBED环境

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

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

jar-weblogic环境下调用接口报错，急，在线等！org.w3c.dom.Node.setUserData

问题描述 weblogic环境下调用接口报错,急,在线等!org.w3c.dom.Node.setUserData 之前在测试环境中测试是可以的,后来部署到正式环境就挂掉了,tomcat下也是正常的.项目的weblogic.xml也配置了优先加载项目的jar包,还是不行. ava.lang.LinkageError: loader constraint violation: when resolving interface method "org.w3c.dom.Node.setUserData