分布式数据库的备份，历史数据的移出问题。

yyy

建立表空间data2001(包括一个数据文件data2001.dbf)专门存放2001年的data，表空间data2002(包括一个数据文件data2002.dbf)专门存放2002年的data，....每个表空间上的data都是通过分区表的分区条件自动归位的。
另外注意每个带这种时间概念的表空间上的对象都必须是分区条件符合该时间规则的表分区。
这样做的好处就是：你可以随意的让某个表空间offline，然后简单的用操作系统copy来进行备份，或者实在没用的话彻底删除掉该表空间，都不会影响数据库的正常运转，开销自然是很小的。
当然这最好是在数据库的设计阶段做，对正在运行的系统进行修改会需要较多的操作。

yangbright

我们当初和你们说的一样是后来才建立的,现在也是运行还可以.只有刚开始比较麻烦

microsky

ORACLE的数据仓库书里有一些历史数据移植的基本注意事项，主要是在目标数据库里建立中间层（快照表-历史表-概要表 等，可以根据需要增加），在历史表里加时间戳，根据时间戳更新概要表。源数据库可以等数据传到数据仓库中后做删除。
我现在有一个项目是保存APPLICATION11中的关键数据到另一个数据仓库，然后删除APPLICATION中的历史数据。我做了一个DBLINK，写一个SQL直接COPY源数据，把它加一个时间戳后INSERT到目标数据库的历史表（大概有90个表，共2-3GB）。然后再从历史表里整理数据到概要表。
但是我们有一个问题一直解决不了—— 当源表中的数据做删除时不能判定这些数据是因为用户做错了而做的DELETE还是系统为了性能问题而做的PURGE，不知各位有什么高见？有谁做过ORACLE APPLICATION的类似项目吗？能不能说一下设计思想？

yyy

只读快照不可以被update或delete但可以被truncate。

因此，一种清除快照表记录的方法就是：
先把快照表中有用的数据都转到别的数据表中，然后truncate！

那这样truncate与drop掉快照后重建有何重要区别呢？
重建快照会象新建快照时一样进行隐式的complete refresh(即便refresh type是fast)，而truncate后不会，因此不会跟重建那样————跟没做似的。

另外，truncate后的快照仍然有些隐忧：
如果删除基表中的某条老记录，则truncate后的快照不会出错，也不会发生任何事。
如果更新基表中某条的老记录，则truncate后的快照中会重新出现一条该记录————更新过的、包括所有字段内容的整条记录。

以上都是经过我的实验得出的结论，另外实验用的是根据rowid进行的fast刷新。

yangbright

好像是不行，快照要和原来的一样不过可以用快照+程序来实现的

cgh_chen

多谢yyy的，
不知道我如何用程序实现数据传递功能

cgh_chen

上面说得不是很清楚。
如何使用两个数据库中，两个表之间的数据同步。
：
建立一个更新记录表，如Oracle的快照日志那样。再用一个JOb定期执行。
不知我是记录rowid，还是主关键字好。rowid对应删除，要想不能记录必要的原始信息（究竟删除哪一条记录）。
不知道大家都是如何实现，这个功能。
大家一致说复制快照不太好，你们的实现方法，能够具体介绍一下吗？