是谁动了我的redo?

不知道大家注意到没有rac中的redo log?

(1)如果关闭这个实例,它的redo log还会被写吗?
答案是会,就算实例关闭了,甚至server关闭了,在共享存储上的redo还是会被其他实例所写(redo必须在共享存储上,以便于恢复时使用)。但是这个由谁写(master node还是所有的node)?在什么时候写?写些什么内容?这个目前还是没想明白,如果您知道,不妨在blog留言。
例子:我有一个3节点的实例,目前node3的server已经关闭。

switch logfile之前:

我们在node1上运行switch logfile之后的结果:

我们看到thread1上变了(从30,31变成31,32),但是其他的thread2,和已经被关闭server3的thread3都没变。

难道不会变么?

我们再来几次switch logfile:

看到thread2依然没变,但是thread1变成了32,33——这个在我们的预料之内,但是thread3变成了15,16。谁发起的?有意思吧,是谁动了我的redo。

(2)如果我新增加一个thread 4,会有人去写它吗?
答案也是会,但是需要enable thread。另外,每个instance中都有一个初始化参数thread=n,该参数规定了某个thread的redo只能有某个instance来写。因此,手工switch logfile的时候,只会影响到instance对应的thread,但是却无法影响到自动写的redo。

我们尝试增加redo thread:

同样的,虽然没有instance对应于thread1和thread3(因为node3已经宕机),但是还是会被写。

相关文章

6条评论

  1. 在其它instance使用lsof查看下,,谁在打开此文件? 然后在针对性的做个strace跟踪下不就知道了.

  2. re jametong: redo在asm上,lsof貌似没有版本看到进程。有什么好办法吗?

  3. ASM 确实会比较麻烦.. 因为操作系统文件描述符的管理都被ASM本身给抽象化了.

    可以考虑根据v$session_event抽取出有log file parallel write/log file single write等待事件操作的进程, 一般情况下为LGWR/CKPT 两个进程, (RAC需要不断推进每个库的SCN/checkpoint信息, 这样才能确保恢复以及SCN的整体一致性).

    确定了有此等待事件的进程, 再在Oracle中对这几个进程打开10046的跟踪事件, 基本上就可以定位具体是谁动了你的Redo..

    更进一步的话, 可以使用strace跟踪上一步得到的进程, 还可以知道它(们)都如何动了你的Redo(我个人估计checkpoint信息的可能性大).

  4. 如果oracle不是在尝试制造足够的混乱的话,redo内容应该只会由lgwr进程去写。用lsof看也只有lgwr进程会打开online redo。
    你可以尝试enable private thread再测试一下是否还有相似的情况。

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据