AnySQL.net

    今天在MSN有一个人说他将数据库搞坏了, 我问他如何搞坏的, 没有细说, 有可能是在练习dd或bbed这样的软件时搞坏的吧, 总之现在的SYSTEM表空间上有坏块了. 不想让公司知道, 要不然面子上过不去. 问我如何出售AUL的许可证, 他已经用AUL试过了, 可以读出部份数据.

    个人以为, 不管发生什么情况, 数据还是公司的, 如果要恢复这些数据, 应当是公司来承担恢复的成本, 而不是让DBA偷偷地去处理掉. 发生这种情况, 作为公司要重新审视很多的事情:

1, 信息对你的公司有多重要?

2, 对你的职业和未来有多重要?

3, 用什么制度来保证数据的安全性和可靠性?

4, 了解手下或公司的DBA常要处理的重要工作吗?

5, 提供了足够的资源来进行数据备份吗?

6, 是否给手下的人提供了培训的机会, 让他们可以轻松胜任工作?

7, 是否有思考, 那些已经存贮信息是最重要的, 那些是次要的?

    作为个人要支持这个恢复费用, 当然不是一件很爽的事了, 给得多了自已心疼, 给的少了, 换个角度考虑考虑? 当然一个重要的观点是"到低数据是谁的? 是DBA的吗?"

    最后我重新声明一下, 我不恢复个人的数据.

    今收到一个控制文件和一堆数据文件, 要在我的笔记本上打开这个库, 我是很不愿意用open resetlogs选项的, 因为控制文件和数据文件是一致的, 是在关闭数据库的情况下备份出来的. 结果发现日志文件原来是在E盘, 而我的笔记本上只有C盘, 直接Clear是不行的, 直接重命名也是不行的, 通过添加新日志组和删除旧日志组也不行, 因为其中有一组是当前Active的, 因此根本就不让删除.

SQL> SELECT MEMBER FROM V$LOGFILE;

MEMBER
---------------------------------------------
E:\ORACLE\PRODUCT\ORADATA\PROD\REDO01.LOG
E:\ORACLE\PRODUCT\ORADATA\PROD\REDO02.LOG
E:\ORACLE\PRODUCT\ORADATA\PROD\REDO03.LOG

    没办法了? 当然是有办法的了, 我们可以简单地骗过Oracle, 方法是我在C盘的相应目录中建了三个空文本文件, 大小全是0, 只是名字和日志文件的一样, 然后就启动到Mount方式, 进行重命名日志文件, 然后再清除每一个日志文件组, 最后就直接打开了数据库, 没有使用open resetlogs选项.

    本故事纯属虚构. 但这个方法是行得通的, 你可以试试.

    02年做在一公司作Oracle DBA支持时, 我也经常在客户那儿写开机后自动启动数据库, 关机前自动停止数据库的角本, 那时也特强调要实现自动化, 但经过最近三年半的大公司的DBA经验, 经过三年管理OLTP型的数据库的生涯, 如今我不会再去写这样的角本了, 不是写不出来, 而是不愿写.

    最近的三年中, 唯一自动启动和关闭的数据库是我笔记本上的库, 用来自已玩和做些研究的, 最近还是改成了手工启动. 对于DBA来讲, 数据库的重启是一件很重要的事, 必须要亲自去操心一下的; 数据库的重启还是一种机会, OLTP型的数据库很难得有重启的机会的, 在重机时你可以调整一些参数, 或顺便做一些维护性质的工作, 有时侯为了作一些调整, 如移动文件位置等操作, 等重起的机会还得等几个星期呢. 你说这样的机会能放过吗?

    这几天又在网上看见有人问, 机器重起后, 数据库和监听器不能自动重启了怎么办? 我的回签是, 不能自动重启就手工启吧! 当然你可以写几行角本, 然后双击鼠标(Windows)或是手工执行(Linux/Unix)来启动数据库.

    就算你是领导, 也不要一定强求手下的人用自动化来实现自动启动的功能, 没有必要. 很多数据库出问题都是在半年或一年/几年没有人看的情况下, 为什么不去看? 连最单的活都实现自动化了, 当然不看了, 而是去上上网喝喝茶看看报炒炒股了.

    欢迎不同的意见.

    在Oracle中, Temp Table的结构建好后, 每个会话都可以看到这个表空构, 但看不到数据. 按数据还可以分为是事务范围(On Commit Delete Rows)的还是会话范围(On Commit Preserve Rows)的. 表结构一致有好处有坏处, 好处是每个会话不需要运行建表语句(其他数据库则不然), 坏处是当这个Temp Table被其他会话使用时, 对它做些DDL时会报错.

    在MySQL 5中也有专门的Temp表, 每个会话可以创建结构不同的同名临时表, 当会话结束时, 这个临时表会被自动删除. 并且, 临时表可以和普通的表同名, 并且有优先权, 这点和Oracle不一样了, 显得Name Space没有管理好. 数据没有事务级别和会话级别之分(可能没有看清楚文档).

    所接触的Sybase和SQL Server还是很久以前的老版本了, 不知道现在如何了. 只能使用"Insert ... Into ..."语句来建, 而不是Create Table语句. 建一个只在这个会话看得见的Temp的表的话, 表名要用一个"#"开头, 要建一个后来的会话看得见的Temp Table的话, 则表名用两个"#"开头. 同样的当会话结束后, 表也自动被删除了.

    对于DB2是一无所知, 有人会告诉我吗? 还有一些其他的数据库呢?

    最近国内的数据库不太平安, 首先是磁盘损坏, 刚好坏到了System表空间所在的盘, 当然这是没有System的恢复. 另外还有好多次误删操作引起的问题, 误删单个或几个表, 误删除一个用户, 误删除一整个表空间(数据文件还在), 这些也算是没有System的恢复. 为什么算?

    在System表空间中, 我们可以找出以下信息: 表编号, 数据编号, 表名, 列名, 列类型. 丢了System文件, 当然是没有了这些信息了, 那么误删表, 用户和表空间时, 当然也将表的这些信息删除了, 虽然你的数据库是有一个System的表空间, 但没有这些方便恢复的信息, 也就是没有System的恢复了. 如果还保留有删除操作时的归档日志或联机日志, 则可以从这儿分解出表名和数据编号的对应关系, 则恢复要简单得多.

    在数据文件中, 我们能找到什么呢? 我们只能找到: 数据编号和记录. 由于没有了System信息, 对于这种恢复, 只能扫描所有相应的数据文件, 将记录找出来. 有两个问题, 第一列的类型要猜测, 不准时要人工分析二进制数据回以确定, 因此恢复相当耗时; 第二恢复的结果只有数据文件, 没有办法告诉你, 这些记录是那个表的, 这一步需要懂应用的人来分析一个个生成的数据文件, 来进行人工匹配. 没有System的恢复, 确切地说, 不是指没有System表空间的恢复, 而是指没有相应System字典信息的恢复

    希望这样的解释能让你清楚一些. 为什么说这个问题呢? 有一个人Drop了一个表空间后, 来找我恢复, 由于他不太懂Oracle, 不知道其中的复杂性, 当我告诉他这是没有System的恢复时, 他说他们有System啊, 包括他们的领导怎么都不想信我说的什么没有System的恢复. 在数据文件中有可能扫出比表的数目多得多的数据段, 因为有很多操作, 都会留下一个数据段, 例如建一个临时表, 再删除它, 这时在数据文件上还是留下了一段数据; 或者你移动表后, Oracle会在重组数据到新的地方, 但是旧的数据段还是存在的. 由于没有了System信息, 根本就不知道那个段上的数据是你想要的. 去年在一次国外的数据库恢复中, 原先以为有400个表的, 但实际扫描数据文件后, 发现了1500个数据段, 客户投入了3个人花了整整两个星期, 才只搞定主要的表的恢复.

    因此当你的数据库大到不好备份时(这当然是不负责任的想法), 至少你得想办法定期拷贝备份System表空间的文件, 否则问题很严重, 比你想象的要严重, 因为很多老的系统都不容易找到对应用熟的人, 数据恢复出来了, 也不容易让应用重新跑起来. Good Luck.