刚学数据库那阵子, 如果谁告诉我说, 那个生产数据库不用归档, 我会吃惊好一阵子. 做的久了, 见的多了, 也就多想了一些.
Oracle中, 归档日志会记录对数据库的所有修改, 这样做的好处是巨大的:
1 可以利用之前的全备份和归档日志将数据库前滚到备份后的任意时间点
2 可在数据库仍然提供服务的情况下, 备份数据库, 也就是在线备份.
3 可对日志运行logminner, 找出曾经执行过的sql语句.
4 可创建物理备用数据库和逻辑数据库
5 ......
|
但是得到这些好处也需要付出一些代价
1 归档进程会占用一些cpu/IO资源
2 归档文件会占用大量磁盘空间, 如果应用写的比较变态, 则这种磁盘空间的占用可能会到达无法忍受的地步.
3 归档日志需要更多的管理工作, 如备份, 删除等~
|
对于一个数据库来说, 是否启用归档模式就要综合考虑归档对于特定数据库带来的好处和需要付出的代价了. 并不是所有的数据库都适合启用归档, 也并不是所有的数据都有归档的必要. 如果选择了不合适的归档模式, 则可能会带来性能的下降, 以及管理管理工作的增加了.
如果一个数据库中的数据全部可以从其他数据库中获取, 或者可以通过某种既定的算法生成, 则这个数据库完全没有必要运行与归档模式, 如果从其他数据库中获取数据的过程, 或者对数据库中的数据的处理过程会生成大量日志, 则将数据库运行于非归档模式能够减少不必要的IO操作, 进而提数据库的性能.
当一个数据库中即有适合运行与归档模式的数据, 又有适合运行与非归档模式的数据, 选择数据库的运行模式, 将会是一个艰难的选择, 选择归档模式需要面临性能下降, 管理工作增加的情况, 选择非归档模式, 又将面临数据库不可恢复的困境. 一个可选方案是将不同性质的数据分开, 需要保证恢复性的数据保存在一个归档模式的数据库中, 不需要保证恢复性, 可以从别处获取的数据, 则存放在一个运行于非归档模式的数据库中. 不过这样做将改变应用程序的运行方式, 如果可以在应用设计之初就考虑到数据库的性能问题, 这些问题就迎刃而解了. 另外一个方案就是改善硬件环境, 增加CPU, 增加内存, 采用高端存储. 这一般是有钱的主采用的方案, 反正有的是钱, 时间, 精力, 这个咱浪费得起.
阅读(2965) | 评论(0) | 转发(0) |
