以优化之名

以优化之名

存储优化导致表空间误删除案例

一人蛇先成，引酒且饮之，乃左手持卮，右手画蛇曰：“吾能为之足！”为蛇足者，终亡其酒。

——《战国策•齐二》

嘉招欲覆杯中渌，丽唱仍添锦上花。

——宋•王安石《即事》

宁锦上添花，勿画蛇添足。

在很多数据灾难中，我们看到很多原本是可有可无的操作，或者是锦上添花的工作，最后却由于处置不当、准备不足或认知不够，导致了数据灾难，当事人后悔不迭。

所谓数据无小事，在和数据打交道时，我们一定要谨而慎之，切勿一失足而至追悔莫及。

灾难描述

2011年12月31日，我们接到一个紧急的数据救援请求。据粗略了解，事情大致是这样的。

1.      年底，开发商帮助用户进行数据库性能优化。

2.      优化内容之一是存储优化。

3.      存储优化的方法是进行表空间重建。

4.      开放商先删除表空间（成功），然后重建表空间（失败）。

5.      用户发现删除的表空间中的数据未备份。

6.      灾难形成。

对于这则案例，如果数据库不进行优化，那么稳定运行的问题还是不大的。然而，准备不足的这些维护操作，则使数据库彻底陷入了瘫痪的困境。

同样在2011年底，我们还遇到了另外一则完全类似的案例，情形大致如下。

1.      客户数据库的安全性要求极高。

2.      客户要定期接受上级单位的例行检查。

3.      为了满足安全评估要求，客户决定对系统进行全新重构。

4.      在导出备份之后，将主机格式化并重建数据库。

5.      在重建后恢复时发现，导出的备份文件有错误，无法导入数据库中。

6.      灾难形成。

现场分析发现，导出文件大小是正确的，但是通过十六进制模式查看发现文件末尾全是空白，没有数据，推测可能是通过移动硬盘备份时出现了问题，未正常退出或插拔移动硬盘导致数据损失。这个导出文件是不足以用来恢复了。后来通过存储级别的恢复，在格式化后的硬盘上找到了之前的历史备份，最终总算恢复了大部分数据。

有时一个良好的设想因为执行不当可能成为灾难的源头，然而在完成了基本的保障之后，无为而治在有些情况下却能保证数据库的安全稳定运行，折腾是数据灾难之源。

案例警示

这两个数据灾难带给了我们如下教训。

1.      在任何破坏性操作之前，必须严格验证备份的有效性

这里所说的破坏性操作包括删除表空间、数据文件、数据表等。

严格验证备份的有效性，如果可能，应该进一步演进到，操作之前进行全面有效的备份。有时候不要相信别人传达的诸如已经备份、存在备份、有人备份之类的信息，因为不同方式的备份可能不适合你的操作恢复，别人的备份也可能存在你所不知道的问题，一旦需要的数据未成功备份，灾难就会出现。

所以，重要的环节需要亲自确认，避免传递错误带来的不确定性。

2.      在可能情况下保留多份备份介质

很多事实显示，有时候单纯一份备份是不可靠的，磁带、移动硬盘等介质的备份更不可靠。所以，如果可能，对于重要数据的备份，最好保留多份介质，尤其是要对原有环境进行破坏、迁移、重构等情况时。

通常的备份策略，还应当结合物理备份和逻辑备份、表结构备份等来实施。对于极其重要的核心表，要保持经常性备份，多一份备份就多一份安全。

3.      避免使用无法把握的新技术

前述案例的客户使用了自动存储管理技术（Oracle ASM）。ASM使用裸设备，这造成了用户无法直接看到数据文件，也就无从直接进行文件级别的复制备份，因而增加了备份的复杂性和难度。

显然用户和开发商运维人员都不能够深入了解这一技术。从这个意义上说，并非先进的技术就适合任何环境，好的技术要和好的运维结合起来才能为用户创造价值。客户在选择Oracle数据库的同时，必须要同时接受因此而可能支付的运行维护成本。

当然，系统架构人员也应当从用户的实际出发，为用户建议适合的系统架构，只有真正适合用户的技术才是最好的技术。

4.      必须有人能够把握技术全局

在这个案例中，显然没有人能够从整体方案上把握全局。如果在核心的数据运维中没有人能把握全局，那么任何操作都应当极其慎重，或者干脆选择放弃进行破坏性数据维护操作。

典型地，如果没有回退方案，任何破坏性的数据操作都不应当进行。

5.      制订方案并且按照方案的步骤执行

重要的维护工作应当制订方案，并且列出明确的操作步骤和命令。这些步骤和命令应当是通过测试验证的。在执行过程中，遵循方案的步骤来进行相关操作，一旦遇到异常必须停下来进行分析或者回退。

严格对数据负责，不因主观的重要和非重要判断行事。

6.      数据库维护操作应当通过命令行完成，避免使用图形化工具

虽然图形化工具会为工作带来便利，但是其背后隐藏着不确定性和风险。通常用户很难确定图形后面默认和非默认的选项，任何一个错误的勾选都可能使情况变得复杂。

鉴于已经有很多用户在图形工具上遭遇挫折，我们建议用户通过命令行完成对数据库的维护操作，比如使用SQL*Plus工具。命令行会迫使你明确所发出的每一个指令，无形中可减少风险的出现。

明确工具的风险和用途，这也是对DBA的一个专业素质要求。

 

充足的数据备份和良好的维护计划是数据安全的守护者，在数据运维中要时刻注意。

 

本文节选自《Oracle DBA手记4：数据安全警示录》一书

盖国强著

电子工业出版社出版

图书详细信息:http://blog.csdn.net/broadview2006/article/details/7744623