drop table后将救回数据的原理！

biti_rainy

最初由 wing hong 发布
[B]

I have thought of this before, butI still can't figure out why Oracle want to  write the dirty buffers back to file when it drops a table.

why bother to do it since it drops the table anyway. Any idea ?

thanks [/B]

很早前我也思考过这个问题

没什么很明确的结论，我这样想过，假定在drop table 的当时不把 dirty  buffer 写回datafile,则会否带来 buffer 管理的复杂度。

如果由于drop table释放了 extent ，则当其他表扩展需要用到该extent的时候，是否带来了 额外的成本。

oracle 是否认为 ddl 发生的概率比较小，而写出buffer成本相对来说也并不高，但是会带来 其他额外的收益。 如果不写出，在buffer的管理的其他程序中肯定需要额外的判别处理。


我没有一个很好的理由，但是oracle这么做肯定是权衡了很多因素而决定的。至于后来DUL用到了这个特点可以恢复数据，到后来  flashback table 的实现，都不过是恰好利用了oracle的这个特点。

wing hong

Thanks biti_rainy. Good to know I am not the only one to be confused by this issue.

d.c.b.a

drop tablespace时数据可以救回来的，不过很麻烦，就象dul没有系统表空时一样

wing hong

最初由 biti_rainy 发布
[B]


很早前我也思考过这个问题

没什么很明确的结论，我这样想过，假定在drop table 的当时不把 dirty  buffer 写回datafile,则会否带来 buffer 管理的复杂度。

如果由于drop table释放了 extent ，则当其他表扩展需要用到该extent的时候，是否带来了 额外的成本。

oracle 是否认为 ddl 发生的概率比较小，而写出buffer成本相对来说也并不高，但是会带来 其他额外的收益。 如果不写出，在buffer的管理的其他程序中肯定需要额外的判别处理。


我没有一个很好的理由，但是oracle这么做肯定是权衡了很多因素而决定的。至于后来DUL用到了这个特点可以恢复数据，到后来  flashback table 的实现，都不过是恰好利用了oracle的这个特点。 [/B]

I have checked with  Jonathan Lewis on this . still no luck on the exact reason.

below is the email exchange:

This is the reply I got from  Jonathan Lewis.

" I don't have a clue why Oracle does this.
It seems to be a totally unnecessary action.
But that's what happens. "


This is my original question.

> Hi Mr.Lewis,
>
> In your book "Practical Oracle 8i", you mentioned that when Oracle drops a table, it
> will also write out all the dirty buffers of the table to disk.
>
> I am a little bit confused by this, why Oralce bothers to do this ? Could you please
> explain it a little further ?