SQL Server 2005 数据库移动和合理化 - 推荐的维护流程

Question

我们正在将 SQL Server 2005 数据库迁移到新服务器并升级到 2008，我正在寻找一些建议和保证我们的方法是正确的。

我继承了这个数据库，但说实话，我发现它有点混乱 - 最重要的是，我基本上已经学会了在这台服务器上成为一名 SQL Server 开发人员（没有计算方面的教育背景），所以我做了很多我自己的错误。我们作为一个部门（公共部门）资金不足，因​​此缺乏专业知识，只能靠自己的力量自力更生。数据库一开始只是一个后台的东西，但对我们的组织来说已经变得非常重要，因此坦率地说，性能令人尴尬。

所以我们有这样的问题

• Autoshrink 使用历史
• 存储空间不足的历史 - 服务器上从来没有足够的空间让数据库增长，所以我猜这些文件可能在内部很碎片化。
• 有多种归类类型（无缘无故），
• text到处都是不合适的数据类型（很多Nvarchar, nchar，ntext当我们不需要 ascii 字符时，text哪里varchar更合适）

新服务器是 64 位虚拟服务器，存储在 RAID 上。

我安装和升级后的计划是：

• 删除大量我们已经确定（有信心）冗余的表（大约是数据库大小的 1/3！）
• 将排序规则归一化为 1 种类型（经过一些分析和测试，我们确信这不会给我们带来问题——我们不需要区分大小写）
• 将text数据类型规范化为varchar/char
• 将数据库文件大小设置为未来 2 年的预期使用量加上 50%

在这些流程之后/之前，我还有什么应该考虑的吗？这里的任何决定是否看起来不合时宜？例如文件大小问题 - 这是我在 RAID 上需要担心的事情吗？

Answer 1

收缩和存储

启用“即时文件初始化”

禁用自动收缩

适当调整存储大小（每个驱动器 15% 免费）

RAID什么？RAID 级别很重要，SQL Server 以不同的方式访问文件。日志文件访问通常是顺序的，而数据通常是随机的。

临时数据库

分离数据和日志文件（参见下面的 RAID） - 获得一个好的tempdb策略。我们tempdb在日志驱动器上有日志，tempdb在自己的驱动器上有我们的文件（内核数的 1/4-1/2）。当您使用它时，请确保其tempdb具有适当数量的数据文件，它们的初始大小完全相同，并且它们具有完全相同的增长因子。在此期间，请阅读Trace Flag 1118

架构更改

如果您要进行这些更改，请确保您有一个良好、持久的备份。当有人真正需要这些表时，9 个月后会发生什么？

您的应用程序实际上可以承受的变化NVARCHAR，NCHAR和NTEXT？当您使用它时，NTEXT不推荐使用，因此移动到TEXT不会很好。退房VARBINARY或VARCHAR(MAX)代替。

您可以随意更改排序规则，但不会影响任何现有数据。

兼容性

如果可以，将数据库兼容性级别更改为 100。

调整选项

查看这些跟踪标志中的一些，它们可能都不合适。其中一些可能是，“这取决于”。另外，请阅读有关跟踪标志 4199 的信息。

工装

我还建议使用一个好的工具集进入这个安装。DBA为此工具包创建一个数据库。我将从sp_WhoIsActiveAdam Machanic 和sp_BlitzBrent Ozar 开始。我还会寻找 Kendra Little 在安排和存储来自sp_WhoIsActive. 最后，我将启动一种捕获等待和队列的方法，以便您拥有服务器配置文件的良好历史记录。

考虑获得监控解决方案。

最后（也许是第一次），请查看 Glenn Berry 的关于配置新 SQL Server 实例的优秀系列。

第 1 部分、第 2部分和第 3 部分