影响数据库扩容成功的七宗罪：
1.系统升级前的被动等待
在系统进行性能和升级测试前，用户总是容易被其他的琐事吸引而不采取积极行动。常见的局限是用户经常会被动等待直到系统正式准备就绪。确实，测试是很现实的因为这样用户可以运行真实的数据库和应用软件，但是如果等你发现其中的错误，经常面临的后果就是任何补救都为时晚矣。因此在你应用之前别忽略升级测试。
2.依靠不切实际的期望
人们认为没有建立数据库的需求。而事实上情况经常会更糟；人们管理数据库时自以为是的假设系统将满足所有的期望，以为系统的表现可以完美无缺。但这是不切实际的，用户应该按照实际能够满足的期望值去建立数据库。
3.忽略需求
用户经常不知道他们的需求是什么。因此你必须帮助他们将最新的业务流程和提供支持的需求具体化。举例来说，目前你每个季度都要将巨大的产品目录用电子邮件的形式发送给所有的客户，现在你的想法是将每个专用目录的100封目标邮件发送给大约2%的客户。如果是这样，我们要做的是，首先讨论最新的电子邮件流程会是什么，如何实现每年比常规25倍的次数发送。其次，开发信息容量来支持这个流程。然后制定数据库使用方法和开发必需的工作负载，服务级别和其他需求。不要忽略这些需求，否则你就会在竞争中落伍。
4.忽略风险分析
一旦你开发出自己的需求，就要对可能出现的风险进行确认，测试和管理。
5.接受脆弱的证据
不要轻易接受销售人员对所谓测试结果的解释。也不要让厂商来定义测试的结果。如果你没有这方面的专业经验，你可以向具备这方面专业经验的咨询师求助，这些咨询师必须熟知测试复杂数据管理系统的基准规格。你的测试必须能准确捕捉扩容和性能测试的关键挑战。
6.低估本年度需求的增长率
基础架构和平台建设将花费较长的时间部署，改变的过程亦是如此。项目需求可能需要两到三年的时间。不要假设数据的增长率会 和业务的增长率相同。事实上数据和工作负载的增长速度通常都会超过相关业务的增长速度，因为数据随着业务的发展使用的更加广泛。
7.忽略扩容的规模
数据量是最容易测算的数据，但是工作负载，数据复杂性，查询复杂性，可用性和数据延迟量几乎是同等重要的。无论你是否在正确的平台上他们都能推动配置规模。要把他们都考虑在内。
就数据库扩容本身来说，对企业是有好处的，但是，当一个企业考虑数据库扩容时，不要是一时的心血来潮，要考虑周全了各方面的条件，只有这样才能使数据库扩容成为企业前进的动力，否则，会产生反效果。
【编辑推荐】
SQLserver2008删除数据库表能找回来吗
如果你的数据库模式是完全或者大容量日志，也可能可以恢复，据说可以从日志中恢复数据，但是，我不知道方法。 一般操作之前，可以先按delete的条件select一次数据，符合要求后再改成delete。 或者干脆先将要delete的数据select into一张临时表，检查无误后再drop掉临时表。
有什么工具可以跟踪完整的sql语句
访问到数据库的sql吗？如果是mysql数据库的话1、可以开启全量日志，这个会记录所有的sql，当然这个会影响数据库性能，高于40%cpu使用的服务器不建议开启，当然只是短时的使用，不影响业务情况下，是可以的。2、使用mysql抓包工具MySQL Sniffer这样的，不仅跟踪来源ip，还能追寻查哪个库，sql是什么
SQL中表示事务执行成功的语句是什么
展开全部if(mysql_affected_rows() > 0) {echo 成功;}int mysql_affected_rows ( [resource link_identifier] ) :执行成功则返回受影响的行的数目，如果最近一次查询失败的话，函数返回 -1。
发表评论