我在SQL Authority上找到了这个脚本：
USE MyDatabase
GO
EXEC sp_MSforeachtable @ command1 =“print'？' DBCC DBREINDEX（'？'，''，80）“
GO
EXEC sp_updatestats
GO
它将我的插入失败率从100％失败降低到50％。 它比重新索引维护计划更有效。
我是否还要重建索引master和tempdb？ 多常？ （我每天24小时写这个数据库） 我应该注意哪些注意事项？
答案 0 :(得分：1)
NAS上的RAID 5？那是你的杀手。
记录INSERT：它写入.LDF（日志）文件。这个文件是100％写的（好吧，足够接近）。
这种巨大的读写比率会在RAID 5中为每个磁盘产生大量额外写入。
我正在撰写一篇文章（稍后添加）：在100％写入情况下，RAID 5每个磁盘写入的次数是RAID 10的4倍。
<强>解决方案
您至少需要拆分数据库的数据和日志文件。
编辑：澄清这一行： 日志文件需要转到RAID 1或RAID 10驱动器。它对于数据（.MDF）文件并不那么重要。日志文件是100％写入的，因此可以从RAID 1或RAID 10中受益。
还有其他潜在的问题，例如碎片化的文件系统或许多Vlog段（取决于数据库的增长方式），但我要说你的主要问题是RAID 5。
对于3TB数据库，我还会尽可能多地填充（如果是Windows Advanced / Enterprise，则为32GB），并设置PAE / AWE等。这将缓解一些磁盘问题，但仅限于数据缓存。
填充因子85或90是通常的经验法则。如果你的插入是宽的而不是严格单调的（例如int IDENTITY列），那么你将有很多页面拆分更高的东西。
我不是唯一一个不喜欢RAID 5的人：BAARF
再次编辑：
在此SQL Server 2000文章中查找“Write-Ahead Logging (WAL) Protocol”。它仍然相关：它解释了为什么日志文件很重要。
我无法找到关于RAID 5在100％写入负载下与RAID 10相比如何遭受损失的文章。
最后，SQL Server以64k块的形式执行I / O：因此格式化为64k簇的NTFS。
答案 1 :(得分：0)
这可能是任何事情。系统CPU是否受约束？ IO绑定？磁盘是否过于激励？系统分页太多了吗？网络是否超负荷？
你有没有调整过索引？我不记得2000年是否存在索引调整向导，但至少可以运行探查器来创建可由SQL Server 2005索引调整向导使用的工作负载。
答案 2 :(得分：0)
也查看您的查询计划。某些索引可能没有被使用，或者SQL可能完全没有效率。
您有哪些餐桌维护？
表中的所有数据都与今天的处理有关吗？
您可以存储一些数据吗？
你的锁定是什么样的？你锁定了整个桌子吗？
编辑： SQL事件探查器显示与SQL Server的所有交互。它应该是DBA的生命线。
答案 3 :(得分：0)
感谢所有帮助。我不在那里，但变得更好。
我对硬件约束无能为力。 所有可用的RAM都允许SQL Fillfactor设置为95 使用分析器，一小时的跟踪提供了索引调整，建议增加27％的效率。
结果，我成功的INSERTS数量增加了一倍。现在只有四分之一的失败。 现在跟踪，然后调整，看它是否变好。
还不明白锁定。
对于那些将SQL Server维护为专业的人，我是否走在正确的轨道上？