10g新特性,flashback系列之一 —— flashback database

biti_rainy

其他几个 flashback  table 功能我不想多说，和9i的原理基本差不多

3、Oracle Flashback Drop
Oracle 10g开始提供一个类似垃圾站的功能，来恢复不小心被drop的表


这个功能，其实，结合oracle触发dbwr的其中一个条件：  当发生 表的ddl 的时候会触发dnwr写数据文件。  这个功能，当初导致的是一个表被drop后，如果立即关机，可以使用dul从数据文件中把该表的内容 抓 出来
起实现的原理不过就是只对数据字典发生了变化而segment 本身还没有丢失，而触发dbwr也是为了让这个没有来得及被覆盖的segment的数据完整

10g中充分利用了这点，采用了数据库功能的方式恢复这个没有被覆盖的segment。所以这个功能的前提必须是 该表被drop后该表的segment的空间还没有被覆盖！


btw:  这些论点并不是来自oracle document ,而是看见这个功能后结合oracle的特征做出的推断。我坚信事实就是这样的。 oracle的很多新功能的推出都是基于以前的一些特性上的进一步完善而已

piner

最初由 biti_rainy 发布
[B]这东西，还使得rman真正地完美地实现 增量备份

以前的增量备份rman虽然备份的是block，但是必须读取所有的block然后来跟以前的备份中的block来比较，现在则无须这个比较过程，直接从该log中就可以知道哪些block发生了变化而直接拷贝这些block。  当然，依然收到时间限制

但这个功能的实现：
1： 可能空间成本比较大，有一点需要注意的是 10% 的块发生过变化，和 10%的块发生过重复多次的变化，对空间的需求应该是大不一样的。虽然我没有证实过，但相信是这样的。我也相信oracle的原理是这样的（除非，在 falshback  logs  中也建立回滚段，但我相信至少现在没这样做，将来是不是可能我不清楚，这只是解决比如一个block每天被更新了多次的特殊情况）

2：该功能必然对io繁忙系统的 I造成很大的影响！道理么，显然，写了额外的大量文件么 [/B]

10g的rman有的很大的改善，但是我觉得，如果记录日志的改变，那么将在平常导致io的增加，如果不记载日志，仅仅是备份的时候导致整个数据库扫描，毕竟备份的时间是不长的，这种特性的得失我觉得还不好定论。。。

10g的rman改善最好的地方，我觉得就是对增量备份的改进了，不仅能缩短备份时间，也减少了恢复时间。。。

至于rman的recover test，10g与9i还是有同样的问题，明显能恢复的，但是test却是恢复不了。10g的restore的preview还不错。

piner

最初由 biti_rainy 发布
[B]其他几个 flashback  table 功能我不想多说，和9i的原理基本差不多

3、Oracle Flashback Drop
Oracle 10g开始提供一个类似垃圾站的功能，来恢复不小心被drop的表


这个功能，其实，结合oracle触发dbwr的其中一个条件：  当发生 表的ddl 的时候会触发dnwr写数据文件。  这个功能，当初导致的是一个表被drop后，如果立即关机，可以使用dul从数据文件中把该表的内容 抓 出来
起实现的原理不过就是只对数据字典发生了变化而segment 本身还没有丢失，而触发dbwr也是为了让这个没有来得及被覆盖的segment的数据完整

10g中充分利用了这点，采用了数据库功能的方式恢复这个没有被覆盖的segment。所以这个功能的前提必须是 该表被drop后该表的segment的空间还没有被覆盖！


btw:  这些论点并不是来自oracle document ,而是看见这个功能后结合oracle的特征做出的推断。我坚信事实就是这样的。 oracle的很多新功能的推出都是基于以前的一些特性上的进一步完善而已 [/B]

其它的几个flashback我都将有系统的描述。
falshback database是采用日志
falsgback drop是采用表空间的空间
其它的都是与undo有关。。。

我觉得，drop没有必要触发dbwr，这个与dbwr没有关系，dbwr还是原来的底层的后台进程，该干什么还是干什么。

应当是oracle对drop做了改进，原来是删除数据字典，标记空间为可以使用的空间（如果是字典管理，则修改数据字典，如果是本地管理，则修改位图）。现在，drop过程简单的变为了重令名过程。

biti_rainy

最初由 piner 发布
[B]


其它的几个flashback我都将有系统的描述。
falshback database是采用日志
falsgback drop是采用表空间的空间
其它的都是与undo有关。。。

我觉得，drop没有必要触发dbwr，这个与dbwr没有关系，dbwr还是原来的底层的后台进程，该干什么还是干什么。

应当是oracle对drop做了改进，原来是删除数据字典，标记空间为可以使用的空间（如果是字典管理，则修改数据字典，如果是本地管理，则修改位图）。现在，drop过程简单的变为了重令名过程。 [/B]

drop 当然有触发  DBWR ! 这不是你我说了算的

若不触发DBWR，那么你的这个表的数据存在可能就丢失在 内存 中 ，还怎么来 undrop  ?

biti_rainy

最初由 piner 发布
[B]

10g的rman有的很大的改善，但是我觉得，如果记录日志的改变，那么将在平常导致io的增加，如果不记载日志，仅仅是备份的时候导致整个数据库扫描，毕竟备份的时间是不长的，这种特性的得失我觉得还不好定论。。。

[/B]

记录 数据库block变量的前映像，也就是所谓的  falshback  logs 的实际操作可能性有待考究，增加了大量的  IO 和 磁盘空间需求

带来的主要是 回退database  和 rman 增量备份等功能的完善

所以，是否实际实用，得根据具体环境来定了

piner

最初由 biti_rainy 发布
[B]

drop 当然有触发  DBWR ! 这不是你我说了算的

若不触发DBWR，那么你的这个表的数据存在可能就丢失在 内存 中 ，还怎么来 undrop  ? [/B]

我是觉得，drop触不触发dbwr，
还是与以前一样，dbwr并不多干其它工作。

flashback drop应当是在drop命令上做了改动。

piner

最初由 biti_rainy 发布
[B]


记录 数据库block变量的前映像，也就是所谓的  falshback  logs 的实际操作可能性有待考究，增加了大量的  IO 和 磁盘空间需求

带来的主要是 回退database  和 rman 增量备份等功能的完善

所以，是否实际实用，得根据具体环境来定了 [/B]

除了flashback log，10g还有一种rman的增量日志
如
alter database enable block change tracking using file '/rman_bkups/change.log';

如果是OLTP系统，也将导致大量的附加IO，DSS系统可能无所谓。

biti_rainy

最初由 piner 发布
[B]

我是觉得，drop触不触发dbwr，
还是与以前一样，dbwr并不多干其它工作。

flashback drop应当是在drop命令上做了改动。 [/B]

dbwr 是不是多干工作不好说，比如一个block 可能被修改了10次却被写文件一次 和被修改5次写文件一次。这不过是触发时机的不一样而已。
在8i的时候 drop 就已经触发  DBWR 了
只不过文档一般没有说而已

我只是说明dbwr把 buffer写进数据文件 是 undrop 的物理基础。而至于  数据字典的变化 和 flashback  drop 的功能，是具体的功能表现


rman 的 log 的问题，我没深究，多谢指出

Alex_wws

SQL> FLASHBACK DATABASE to timestamp(to_date('2004-04-14 10:51:30','yyyy-mm-dd hh24:mi:ss'));
SP2-0734: 未知的命令开头 "FLASHBACK ..." - 忽略了剩余的行。

piner

最初由 Alex_wws 发布
[B]SQL> FLASHBACK DATABASE to timestamp(to_date('2004-04-14 10:51:30','yyyy-mm-dd hh24:mi:ss'));
SP2-0734: 未知的命令开头 "FLASHBACK ..." - 忽略了剩余的行。 [/B]

你是10g吗？