ehxz 发表于 2007-12-5 11:20:28

在SQL Server问题发生之前敲响你的警钟

  问题:

  犯错、失误、心不在焉、过分扩展……只要你能想得到的情况,都有可能发生,而且当这些不妙的情况发生在你或者你的团队其他人身上时,后果可能会比想象中还要糟糕。当然,你可能见证过发生在许多人身上的各种不同的错误,不过对于我而言,最大错误莫过于明知道问题存在但是要么无动于衷忽视掉,要么采取拖延政策,迟迟不采取解决措施。不想再要抛下手头一切事务去解决一个原本可以防止发生的问题?本文主要集中探讨了一些原本可预防的SQL Server问题。看看你有没有碰到过这些问题。

  解决方案:

  现实没有什么东西是绝对完美的,所以我们作为专业技术人员就需要尽量以可以利用的时间和预算打造最实用的问题解决方案,然后跟业务人员进行沟通,让他们认识到潜在的问题和可能发生的情况。如果商务这边的人觉得问题的风险太高,可以考虑给技术人员更多的时间和经费进行解决方案的开发和实施,从而满足他们的需求。但是,很不幸的是,这很简单的一步往往是最经常被忽略的一步。企业里技术部门和经营部门之间缺乏这关键一步的沟通往往会导致问题的发生。

  以下列举了一些常发生的问题,分为开发和操作两大类,不过其中会有一些重叠的部分。看看自己是否可能会遭遇到这类问题,然后给自己敲响一个警钟。

  开发类

  网速——我们常常听到各种部门的人嘴里蹦出“网速”这个词。然而概念泛滥的后果就是不少编程人员往往不考虑需求、不进行详细计划就针对网速进行编码。后果可想而知,导致了编程人员需要进行一而再甚至再而三的修改,有时甚至又一下把所有不完整的代码删除。一般的环境里可以这么做。但是在一些成熟的大企业里,做任何细小的改动都需要经过周密的考虑计划过程才能够付诸实践,才能防止需要进行大规模修补维护工作的噩梦。许多人可能都参与过规模较小的编程项目,那么应该知道为了防止大量的重写工作,编程人员需要花多少心思在确定企业经营的需求然后才能开始进行编程工作,更不要说那些规模更大的编程项目了。

  总是使用文本数据——尽管文本数据类型能够存储大量的数据,但是这个数据类型对于你大多数的应用软件来说往往不是正确的数据类型。最起码你要确保对于要存储到表里的数据选择了正确的数据类型,否则,当你发现自己使用了不正确的数据类型而导致应用软件性能低下的时候,就不要大惊小怪了。

  应用软件中无错误处理——不应该让用户在使用软件过程中收到奇怪的信息导致其工作效率降低或者对软件失去信心。编程设计的时候认真地考虑一下你要设计的错误处理设定。虽然编程人员不可能考虑到所有可能发生的错误,但是至少应该尽量以更友善的方式就用户使用软件时发生的错误跟用户进行沟通。

  不要设置压力测试——如果你非要为你的应用软件开发出一个新版本,修改了表、索引、存储过程、视图、函数等等,那你就不要再期望这个系统的性能能够跟以前一样好。如果你对SQL Server这么干,系统没有挡掉就算你走运了。从功能角度考虑,让一个用户对应用软件进行测试还算合理,但是如果是做软件压力测试就不太现实了,除非这个软件系统比较小,逻辑比较简单,数据量和用户人数都比较少。

  为了防止软件性能低下而删除触发器——触发器的创建都是有其作用的,有的是为了审计,有的为了确保顺从性,有的是为了调整、报告或者内部业务需求。所以,不要仅仅因为触发器稍微妨碍到你的软件运作就把它删除掉。使用SQL Server 2005可以启或禁用触发器。只是记得要确保你做的修改不会违反你的商业法规。

  软件系统一直出于可连接状态——确保要关闭应用软件系统的连接。如果连接数不断增加达到某个点,SQL Server就不能再增添更多的连接,如果你够幸运的话,你可能能够连接到机器在它重启的时候把SQL Server完全关闭。关闭连接可以防止SQL Server由于新创建连接数不断增多而性能下降。这很简单的一个步骤可以有效防止系统出现不必要的停工。

  宁缺毋滥——选择正确的技术解决方案并在正确的应用软件层面进行不是件容易的事情。尤其是有时候问题的可选解决方案太多,需要在有限的时间和预算下建立所需的解决方案。所以,与其使用没有数据库支持的拥有最漂亮的界面和最有趣的特性的应用软件,不如选择一个功能实用、切合企业需求的软件。

  操作

  当团队所有的资深员工都在休假中——当你需要实施一个重要方案的时候,确保有重要的资深技术员在场可以随时满足项目的要求。不要以为一个初级技术员就可以轻易实施一个方案,尤其是在没有进行最起码的测试的情况下。当出现问题的时候,最需要资深技术人员的丰厚知识和经验来解决。如果团队里这些资深的技术人员都碰巧出去休假了,那么你最好等到有人回来之后,再在团队在场的情况下实施方案,以便应对任何突发情况。

  孤注一掷——当你需要进行一个企业全面升级的时候,不管是应用软件的升级或者是硬件的升级,切记不要一次性把所有的系统都同时进行升级(包括DR)。稍等一下,至少保留一些系统在短期之内不要与其他系统同步升级,在其他系统升级达到稳定的状态,再慢慢地把这些系统植入这个稳定的平台中,以免出现突发情况。

  没有每天进行备份文件验证——确保自己保持每天更新一份数据一致、可靠的备份,这样发生严重问题的时候至少有一道坚实的防线。还要跟营业部门协调确保备份文件不做法律或法规用途。

  没有更改密码——作为数据库系统管理员,你拥有通往这个系统王国的钥匙,所以你必须清楚认识到自己的责任。所以,设置一个复杂的管理员密码,需要经常更改密码,并且切记绝对不能把密码告诉任何人。如果是团队共享的密码,当团队成员有人离开团队时,必须更改密码,并且撤消他的账户,或者启用VPN访问权限等等。

  密码过期——这个跟上面一项几乎完全相反。SQL Server 2005的密码管理原则可以对标准的登录账户设定密码过期的设置,当账户密码过期,账户就会被锁定,而无法登录访问应用软件。所以密码过期设置可以发挥很大作用,不过要记得经常更改密码,并通知共享密码的团队其他成员。但是不要在系统繁忙的时候启用这个设置。

  任由主文件组增长——随着数据的不断增长,如果不限制数据库的大小并且每月、每日甚至每天对数据库的大小进行监控,你就只能任由数据库自动地无限增长了。不管怎么样,都要随时注意你的磁盘剩余空间,不然很可能就“突然”出现“您的主文件组已满”或“您的磁盘驱动器已满”。

  高温的数据中心——高温意味着服务器不能正常运作。要么电子控制卡失灵,要么磁盘驱动器出问题。但是有的企业的服务器中心常常高温持续3、4个月都没有意识到问题的严重性。所以,要记住确保工作环境的温度调节,并且应该准备一个后备的空调系统。
页: [1]
查看完整版本: 在SQL Server问题发生之前敲响你的警钟