数据库最差实践 – 新城镇、新工作和新灾难
可能对任何业务致命的 5 个数据库最差实践。
引言
与其写最佳实践，我打算写一些我在现实世界中经常看到的糟糕实践。有些坏到让我常常想知道那些仍然使用它们的人是如何做到至今还能继续工作的。让我们来看一下我在业界观察到的一些最差实践。
我的日志文件太大了——我在没有备份的情况下截断了日志。
这必须是最糟糕的实践之首。每次我遇到这样的说法，我的心跳都快漏了一拍。在我继续之前，让我承认，在职业生涯的开始，我也这样做过。过了一段时间，我吃够了苦头才学到教训。这绝不是一个好习惯；截断日志文件不可取。我之所以将其评为最糟糕的实践的原因是：这个错误可能会导致数据库无法恢复。当有人在没有备份的情况下截断日志文件时，就没有恢复的可能了。
以下是我撰写的一些关于如何防止日志文件过大的文章
我每天收缩数据库以重新获得空间。
这是另一个流行的糟糕实践。我见过管理员在一天结束时收缩数据库以节省空间，结果第二天又丢失了这些空间。收缩是一个非常糟糕的操作。它会增加碎片，降低性能，并浪费资源。我强烈建议不要这样做。
以下是我之前就此主题撰写的一些文章。
- 收缩数据库很糟糕——增加碎片——降低性能
- 对SQL Server中的每个数据库执行SHRINKDATABASE
- 收缩NDF和MDF文件——读者的意见
- SQL Server 2008中的SHRINKFILE和TRUNCATE日志文件
聚集索引使表每次都排序。我的任何表上都没有聚集索引。
对于OLTP系统，索引非常重要，聚集索引是最重要的索引（在我看来）。聚集索引强制对表进行排序，并消除数据库中的“转发记录”问题。就我个人而言，我认为没有聚集索引的表的性能是不可接受的？在我的OLTP系统中，我总是建议所有表都应该具有聚集索引。
这是一个可以帮助识别数据库中没有聚集索引的表的快速脚本。
TempDB不重要；所以我把它放在我的慢速驱动器上。
我个人非常尊重TempDB。即使它在服务器每次重启时都会重置，它也是系统中所有其他数据库共享的最重要的单个数据库。此数据库用于排序、临时对象、触发器、行版本和其他操作。将其放在慢速驱动器上不是解决方案，但现实情况是，它只会为整个系统创建许多与性能相关的问题。如果您的TempDB已满，请将其移动到其他驱动器。
以下是我撰写的一些关于TempDB的博文
- 查找有关TempDB详细信息的T-SQL脚本
- TempDB已满。将TempDB从一个驱动器移动到另一个驱动器
- 减少TempDB上的页面争用
- TempDB的改进
- TempDB限制——临时数据库限制
- 理想的TempDBFileGrowth值
我对完整、差异和日志备份感到困惑
无法理解正确的恢复模型是另一种糟糕的实践。我见过人们在恢复数据库时恢复许多差异备份。我经常看到日志文件备份间隔非常大，大于差异备份间隔。有许多因素可能导致灾难和数据丢失，有时会导致人们在新城寻找新工作。如果您对什么是尾日志备份感到困惑，那么请停下来，在实施备份策略之前从在线书籍中学习。即使您不负责实施备份策略，我仍然建议您阅读如何进行正确的备份，因为您永远不知道它何时会严重影响您的工作！
以下是一些关于此主题的有趣文章
- 备份时间线和在完全恢复模型中理解数据库恢复过程
- 恢复序列和理解NORECOVERY和RECOVERY
- 镜像备份和恢复以及拆分文件备份
- 无需备份或使用备份恢复数据库——关于恢复和备份的一切
- 使用SQL脚本(T-SQL)恢复数据库备份
我可以写更多实践，但我认为这五个是最糟糕的实践。欢迎发表您的意见和建议。
参考：Pinal Dave (http://blog.SQLAuthority.com)