我们正在将 SQL Server 2005 数据库移动到新服务器并升级到 2008，我正在寻求一些建议和保证我们的方法是正确的。
我继承了这个数据库，它让我有点乱，说实话 - 最重要的是，我基本上学会了成为这台服务器上的 SQL Server 开发人员（没有计算方面的教育背景）所以我做了很多我自己的错误就可以了。作为一个部门（公共部门），我们资金不足，因此缺乏专业知识，只能靠自力更生。数据库最初只是一个后台的东西，但对我们的组织来说已经变得非常重要，鉴于此，性能坦率地说是令人尴尬的。
所以我们有这样的问题
- Autoshrink 使用历史
- 存储空间不足的历史 - 服务器上从来没有足够的空间来增长数据库，所以我猜这些文件可能在内部非常分散。
- 有多种排序规则类型（没有充分理由），
- 到处都是不合适
text的数据类型（很多Nvarchar,nchar,ntext当我们不需要 ascii 字符时，text哪里varchar更合适）
新服务器是一个 64 位的虚拟服务器，存储在 RAID 上。
安装和升级后我的计划是：
- 删除大量我们已确定（有信心）为冗余的表（大约 1/3 的数据库大小！）
- 将归类规范化为一种类型（经过一些分析和测试，我们确定这不会给我们带来问题——我们不需要区分大小写）
text将数据类型规范化为varchar/char- 将数据库文件大小设置为未来 2 年的预期使用量加上 50%
在这些过程之后/之前，还有什么我应该考虑的吗？这里的任何决定是否看起来不合时宜？例如文件大小问题——这是我在 RAID 上需要担心的问题吗？
收缩和存储
启用“即时文件初始化”
禁用自动收缩
适当调整存储容量（每个驱动器 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 部分
我很高兴你有机会做这个清理工作。我不会太担心设置数据库文件大小。只要你有足够的磁盘空间，SQL Server在这方面可以飞起来
但是，一般来说，您的问题应该不会影响性能，并且在清理后这可能仍然是一个问题。解决方案是查找并改进长时间运行的查询。您可以使用 SQL Server Profiler 来查找问题查询，通过分解它们并在 SQL Server Management Studio 中运行它们，查看执行时间和执行计划，我学到了很多东西。祝你好运！