|
对于数据库管理员来说不可预测的灾难虽然让他们很头疼但是并不可怕可拍的是没有为可能发生的灾难做好相关的准备以至于当灾难发生的时候素手无策由于硬件故障服务器被偷或者其他意外事故数据库管理员很难避免数据库管理员能够做的就是采取哪些措施来为未来可能发生的灾难最好准备笔者在这方面虽然不能够说做的面面俱到但是也算是做得不错了笔者就在这里跟大家分享一下这方面的管理经验帮助大家来应对这些不可预知的灾难 措施一定时的对备份文件进行测试 为了在数据库出现故障的时候迅速利用备份文件进行恢复数据库管理员往往会设计比较合理地备份策略如在SQL Server数据库汇中可以通过完全备份与差异备份相结合的策略来对数据库进行备份这一步大部分数据库管理员都做的很好但是他们只做到这一步而已而很少有数据库管理员会对这些备份文件进行测试看看能否利用这些备份文件进行顺利恢复 笔者有一个朋友以前就犯过这个错误他配制好数据库备份策略以后以为就万事大吉了但是一次当数据库出现故障利用这个备份文件恢复之后就出现了一些问题在数据库中有些视图的列采用了中文名字但是可能在数据部署的时候配置不当或者其他的原因导致在恢复的过程中这些中文备注显示的是乱码;而字段名称或者视图名字中包含中文汉字的则就无法正确恢复过去还是这些内容不是很多平时工作中又作了详细的工作笔记为此发现这个问题后马上可以重建这些视图虽然这次事故最终没有造成很大的损失但是也给我们数据库管理员提了一个醒数据库备份之后并不是万无一失了数据库管理员最好能够不定时的对备份文件进行测试以确保这些备份文件的准确性;以及确保可以从这些备份文件中恢复需要的数据 笔者现在给企业部署SQL Server数据库的时候都会要求企业的数据库管理员至少每隔一个月需要对备份文件进行恢复测试一方面用来测试这些备份文件的准确性防止因为不正确的备份而造成无法挽回的损失另一方面也是锻炼企业数据库管理员对于数据库恢复的熟练程度让他们能够在遇到数据库服务器故障的时候能够在最短时间内恢复数据库软件如果平时不怎么关注这个恢复过程的话则这些数据库管理员一段时间没做的话很可能都会还给笔者了为此进行数据库备份文件的还原测试即可以用来判断备份文件是否准确;也可以让企业数据库管理员熟悉还原流程一举多得数据库管理员要定时不定时的做好还原测试 措施二设计并运行一些基本的功能脚本 作为数据库管理员来说最悲惨的事情就是自己是最后一个知道问题的人可能某些故障如备份失败或者某个触发器无法正常运行已经发生了很长的一段时间但是由于数据库管理员可能在忙于其他的事情没有注意到这方面的内容久而久之当故障发生后才发现因为这些故障而导致原来针对这些灾难的安全措施都不起作用了所以说数据库管理员必须实时的了解这些安全措施的运行情况但是数据库管理员毕竟精力有限没有这么多的时间来跟蹤这方面的内容 为此笔者建议作为数据库管理员最好能够自己开发或者直接采用数据库系统中的一些功能性脚本这些脚本主要用来自动检测数据库的运行状况如果数据库运行有问题如在差异备份过程中有错误则这些功能性脚本就会探测到这个问题并通过邮件或者其他方式来告知数据库管理员让他们能够及时的采取措施来解决这个问题简单的说这些基本功能脚本就是为数据库管理员提供了一种自动检测数据库的机制可以用来炎症数据库是否可以回到可工作状态以确认所有的作业都是在按预想的方式进行 通常情况下笔者认为可能需要对如下的一些作业进行监控以确保他们时刻都是有效的一是数据库的备份策略需要确保数据库在规定的时间内完成特定的备份(如差异备份与完全备份等等)二是需要考虑某些触发器是否有效有些触发器主要用来完成一些约束或者级联更新的功能数据库管理员需要确保这些触发器是时刻有效的不然的话很可能导致数据库中数据一致性的破坏如果由于触发器无效导致级联更新的失败这也是一种灾难而且由于这个灾难比较难以发现为此其危害度可能比服务器故障还要严重的多所以说需要通过基本功能脚本来自动检测这些触发器的有效性 在上一篇《如何了解触发器的执行信息》文章中笔者也介绍了一些查询触发器执行情况的手段各位数据库管理员可以参看这篇文章的一些建议来追蹤触发器的执行情况但是手工监督的话工作量比较大而且时间相隔也会比较久为此比较理想的情况是数据库管理员能够设计并运行一些基本的功能脚本用来监督这些触发器的执行与生效情况 为此笔者认为通常情况下数据库管理员最好能够在灾难恢复计划中部署一些基本功能脚本以确认所有事情都是在按管理员的预期方式运行通过这些脚本可以帮助数据库管理员来监督与检测数据库的运行情况而不用等到用户来反映问题 措施三审议用户的操作以减少灾难发生的几率 在实际工作中服务器等出现故障的几率是比较少的其实数据库运行中的很多灾难可能是人为造成的也就是说数据库灾难中其七分是人祸造成的;而只有三分可能是一些不能够预测的自然灾难所造成的为此数据库管理员应该审议用户的操作以减少灾难发生大几率 笔者在数据库维护过程中就遇到过这方面的事情那时用户为了数据导入的方便就直接在数据库中而不是通过前台的应用程序导入数据为此虽然符合了数据库中的强制规范性要求如字段非空或者其他的一些约束性条件但是却违反了前台应用程序的一些处理规则如字段过长数据类型不匹配数据必须为非空等等由于数据库与前台应用程序业务逻辑的不一致性这些灾难性问题很难查找最后不得不重新初始化数据库来清空数据并重新导入 这个灾难还算比较小笔者还遇到一些更大的人祸有家企业为了导入数据的方便竟然把数据库中的约束全部禁用了本来他的想法可能是先把约束禁用掉以方便数据导入等到数据导入完成后在启用约束但是这往往是行不通的因为稍微复杂一点的数据库其表与表之间的约束字段的约束就好像一张渔网一样缠绕在一起很难分清楚最后这家企业只好求助于我让我们帮他们处理遇到这个问题笔者也束手无策笔者最后只好快到斩乱码恢复数据库然后在约束不取消的情况下让企业导入数据此时的话由于系统约束的限制会自动对导入的数据进行完整性检查如果发现有问题的数据则会马上反映出来如此的话就可以保证导入数据库中的数据都是符合数据库约束条件的这就可以有效防止人为的不正常操作给数据库带来灾难性的后果 为此笔者认为数据库管理员应该审议用户的日常操作防止因为各种不正常的操作而给数据库带来灾难性的后果如通过数据库中的事件通知功能或者跟蹤事件功能以追蹤各种可疑的SQL语句并汇报给数据库管理员如此的话即使最终的灾难不可避免但是数据库管理员凭借这些信息也可以知道这些灾难可能是什么原因所造成的凭借这些信息数据库管理员可以在最短的时间内排除故障毕竟在数据库故障排除中查找问题的原因是其中最花时间最花精力的一项工作而这些SQL跟蹤或者事件通知功能则可以帮助数据库管理员在发生数据库灾难事件中找出问题发生的原因迅速解决故障打个形象的比喻这就好像是飞机中的黑匣子可以帮助管理员记录用户操作数据库过程中的不正常情况以减少数据库管理员应对由此带来的灾难性故障所需要的时间 |
