关于CLAER LOGFILE的疑问

ccsnmoracle

原帖由 empoli 于 2010-2-25 10:31 发表
。。

晕 你CLEAR完干吗又ALTER SYSTEM SWITCH LOGFILE两次啊
壮态当然会变啊
这不是很正常吗
你CLEAR完不要切日志
马上查不就好了

没看懂你要说什么？

empoli

。。
等一下等一下
你是CLEAR还是DROP啊
不是要损坏吗~
是把它DROP掉才是损坏吧
CLEAR只是把它墨掉 没删 所以当然还在啊

empoli

。。
第二个报错很正常啊
晕 因为你把ONLINE LOG给膜掉了
DB 在启动时会简查两个号
一个大号 SCN号
一个小号 LOG SEQUENCE
发现不匹配 自然开不起来

empoli

。。
把ONLINE LOG给删了
只能不完全恢复了
只要归挡了 CLEAR就没事 下次重新写就行了
还要分是  CURRENT    ACTIVE  INACTIVE的

ccsnmoracle

原帖由 empoli 于 2010-2-25 11:22 发表
。。
第二个报错很正常啊
晕 因为你把ONLINE LOG给膜掉了
DB 在启动时会简查两个号
一个大号 SCN号
一个小号 LOG SEQUENCE
发现不匹配 自然开不起来

您再仔细看看我遇到的情况。
等于什么都没说。。。

empoli

。。
一：你是WINDOWS还是LINUX上做这些操作
二：你所胃的重建是又建一个LOG FILE GROUP 1出来吗 还是只是CLEAR完就没了
三：你如果删完后 没有重新DROP 再 CREATE一遍  那你的ALTER SYSTEM SWITCH LOGFILE只是在内存中操作
四：有正常关机SHUTDOWN IMMEDIATE？

ccsnmoracle

原帖由 empoli 于 2010-2-25 16:46 发表
。。
一：你是WINDOWS还是LINUX上做这些操作
二：你所胃的重建是又建一个LOG FILE GROUP 1出来吗 还是只是CLEAR完就没了
三：你如果删完后 没有重新DROP 再 CREATE一遍  那你的ALTER SYSTEM SWITCH LOGFILE只是在内存中操作
四：有正常关机SHUTDOWN IMMEDIATE？

一：我是在LINUX下进行的实验。
二：我就所谓重建的方法就是CLEAR
四：可以正常关机，但之后就无法正常启动了。

三：你如果删完后 没有重新DROP 再 CREATE一遍  那你的ALTER SYSTEM SWITCH LOGFILE只是在内存中操作
不太理解你的意思。

我之所以删除REDO文件，是为了模拟REDO文件全部损坏的的场景。
我在不删除文件的情况下，如果进行CLEAR操作，那么一切都是正常的。
可如果我把文件删除了，在进行CLEAR操作，那么就不行了。

我觉得，在文件全部丢失的情况下，CLEAR操作是发挥不了全面的作用。
或者说，在文件全部丢失的情况下，通过CLEAR所生成的文件本身就是不可用的。。。

empoli

..
明白了
你在OS上删完日志
还能CLEAR明白是为什么吗？因为REDO已经缓在内存了 你所有的操作都是对内存的操作 哪怕它应该有往下写REDO文件的操作
（你正常关机，应该是都往下写了） 这个时候你会有个移问 为什么OS上的文件删了 它还能往下写 我只能说 这就是LINUX强罕的地方
你是往下写 但是机器认为你还是写内存 一个字 强  所以为什么大型DB都在UNIX/LINUX上 换作WINDOWS早抱消了

而你在开机 会报错 很正常啊 因为OS上的日志被你删了 DB找不到了 那个LOG SEQUENCE号找不到了

这样 你做个EXPERIMENT
删完OS的REDO 再DROP LOGFILE 然后再 CREATE LOGFILE 然后再正常关机 你就都明白了

对于资料上写的东西  如果实验做不出来 那它要么是错的 要么是理解的问题

我觉得是这样   你要挑战它
OK

ccsnmoracle

empoli sir

你说的那个实验，我之前就做过，是成功的。
并且我认为当一个处于UNACTIVE的已经归档的REDO GROUP，
在所有文件丢失的情况下，只能用您刚才所说的方法，DROP之后，再重新建立。

您以上的解释，只是解释了，为什么能够switch和正常关闭数据库。

并不能解释，为什么当文件全部丢失时，通过CLEAR重新建立的日志文件不能正常使用的原因。

在REDO文件存在的情况下，我先CLEAR，在把CLEAR后的REDO文件，SWITCH到CURRENT的状态。
一切正常，可以DUMP。以下是dump的内容。这可能是一个REDO文件，最初始的状态。
在REDO文件不存在的情况下，我先CLEAR，在把CLEAR后的REDO文件，SWITCH到CURRENT的状态，DUMP操所无法进行。

empoli sir，
我觉得可能是这样，CLEAR操作是，需要REDO文件原来的内容为依据的，比如文件头呀或者是什么。。。（瞎猜）

简单地说，文件都无存在的这种损害，CLEAR操作用不了，不适合。




DUMP OF REDO FROM FILE '/export/home/oracle/app/oracle/oradata/mytest/redo03.log'
Opcodes *.*
RBAs: 0x000000.00000000.0000 thru 0xffffffff.ffffffff.ffff
SCNs: scn: 0x0000.00000000 thru scn: 0xffff.ffffffff
Times: creation thru eternity
FILE HEADER:
        Compatibility Vsn = 169869568=0xa200100
        Db ID=2410150662=0x8fa7fb06, Db Name='MYTEST'
        Activation ID=2410847424=0x8fb29cc0
        Control Seq=4142=0x102e, File size=102400=0x19000
        File Number=3, Blksiz=512, File Type=2 LOG
descrip:"Thread 0001, Seq# 0000000006, SCN 0x000000089eca-0xffffffffffff"
thread: 1 nab: 0xffffffff seq: 0x00000006 hws: 0x1 eot: 1 dis: 0
resetlogs count: 0x2a6bc2fe scn: 0x0000.00087132 (553266)
resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
prev resetlogs count: 0x2a69532f scn: 0x0000.0007e555 (517461)
prev resetlogs terminal rcv count: 0x0 scn: 0x0000.00000000
Low  scn: 0x0000.00089eca (564938) 02/24/2010 03:55:49
Next scn: 0xffff.ffffffff 01/01/1988 00:00:00
Enabled scn: 0x0000.00087132 (553266) 02/23/2010 07:55:42
Thread closed scn: 0x0000.00089eca (564938) 02/24/2010 03:55:49
Disk cksum: 0x1147 Calc cksum: 0x1147
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
Unprotected mode
Miscellaneous flags: 0x0
Thread internal enable indicator: thr: 0, seq: 0 scn: 0x0000.00000000
END OF REDO DUMP
----- Redo read statistics for thread 1 -----
Read rate (ASYNC): 4Kb in 0.19s => 0.02 Mb/sec
Total physical reads: 4096Kb
Longest LWN: 0Kb, moves: 0/8 (0%), moved: 0Mb
Last redo scn: 0x0000.00089ed9 (564953)
----------------------------------------------

empoli

..
再把那些基础的概念看一遍~再把整个思路理一遍~再想一遍~也许有助于您理解这个问题~

I think i explained the question clearly.
understand the difference between clear and drop.