老熊的三分地-Oracle及数据恢复

一个客户的重要生产系统，一个USER被删除了，USER下所有的对象都被删除了。还好是下班时间，也有有效的备份，数据得以完全恢复，也没有对生产造成重大影响。

引起这个事故的，除了人为因素之外，ORACLE的BUG要负一半的责任。通过操作录像（客户对系统内做系统管理的所有机器的操作都作了录像，这点非常好），我们搞清楚了数据被删除的经过。

一个开发人员，通过OEM（Oracle Enterprise Manager Console）连接到数据库上，经过他确认OEM上的那个连接字符串是正确的，然后对USER做了删除操作，但很快发现，生产库的数据被删除了。操作录像也证明那个连接字符串是正确的，那么问题出在哪里呢？

操作的那台机器（Windows系统），在系统环境变量（我的电脑=>属性=>高级=>环境变量=>系统变量）中设置了TNS_ADMIN，指向了另外的目录。现在，TNS_ADMIN指向的目录（下面简称TNS_ADMIN目录）和%ORACLE_HOME%\NETWORK\ADMIN（下面简称ORACLE目录）下都有TNSNAMES.ORA这个文件。在TNS_ADMIN中，TNSNAMES.ORA有一TNSNAME，指向生产库。在ORACLE目录中，TNSNAMES.ORA中有一同样的名称的TNSNAME指向开发库。

OEM在处理TNS_ADMIN上是有问题的。OEM在启动后，在左边的数据库目录树，是从ORACLE目录的TNSNAMES.ORA中解析出来的，完全忽略了TNS_ADMIN环境变量，就算是执行”将数据库添加到树“操作，也是完全忽略了TNS_ADMIN变量，操作的是ORACLE目录中的TNSNAMES.ORA文件，显示的连接字符串信息也是从那个文件中得到的。下面是显示信息的截图：

然而，在用这个TNSNAME进行连接数据库时，却是按照TNS_ADMIN目录中的TNSNAMES.ORA文件的配置进行连接的，如果这两个TNSNAMES.ORA都有这个TNSNAME，那么不幸就发生了，本来我们期望是连接到OEM中显示的那个数据库上，结果却连接到了另一个库上。这可以是说OEM的重大BUG。

这里谈到的OEM是9i的版本，NetCA也有这个问题，但Net Manager没有这个问题。

事情虽然过去了，但是以下几件事情我们仍然值得我们牢记：

• 有效的备份，特别是归档模式下的有效物理备份，是保证数据不会被丢失的前提。
• 数据库用户权限的管理，需要遵循”最少权限“的原则，不可忽视。很多数据库管理人员为了方便，给Oracle用户太大的权限，甚至是DBA角色权限。这是非常危险的。
• 有了备份仍然不够，需要做恢复测试，避免出现问题发现备份不能恢复，否则悔之晚矣。这次事故中，由于第三方的备份软件问题，导致数据恢复至少多花了三个小时的时间。要是之前有做过完整的测试，则会发现备份软件的问题。
• 一些危险的操作，如删除用户，删除表等操作，一定要有规范的流程，确认无误后再执行。

还有以下我的一些个人观点：

• 数据库管理时，尽量少用图形化的软件，一次DEL按键就能葬送整个系统。
• 尽量将生产系统、测试系统与开发库隔离，比如禁止在开发机器上直接连接生产库，开发完成后，需要部署到生产库时，遵循专门的流程进行。也就是要规范开发流程。