曾几何时，我构建了自己的 SQL 服务器，并且可以控制驱动器配置、RAID 级别等。传统的数据、日志、tempdb、备份分离建议（取决于预算！）始终是一个非常重要的部分SQL 服务器设计过程。
现在有了企业级 SAN，我只需为新 SQL 服务器请求特定数量的驱动器空间，分为用于数据、备份和文件共享的逻辑驱动器。当然让我的工作更轻松，但我的一部分感觉并不完全舒服，我无法真正窥视“幕后”，看看那里到底发生了什么。
我的理解是，SAN 团队不会以任何不同的方式配置不同“类型”的驱动器（优化数据驱动器以进行随机访问，而优化日志驱动器以进行流式写入）。其中一些可能取决于 SAN 产品本身（我们有 HP XP12000 和 HP XP24000），但我确信 HP 软件会进行各种动态性能配置（观察 IO 热点并动态重新配置以优化这些 LUN），这样应用程序团队和 DBA 就无需担心任何这些事情。关于“将所有服务器的负载分散到大量主轴上”之类的东西。
我的问题/讨论：
在不与 SAN 团队树敌的情况下，我如何让自己和应用程序开发人员放心，我们的 SQL 服务器不会受到配置不当的存储的困扰？只使用性能统计？其他基准，如sqlio？
如果我在这些 SAN 驱动器上进行负载测试，这是否真的为我提供了一个可靠的、可重复的衡量我们上线时将看到的内容？（假设 SAN 软件可能在不同的时间点以不同的方式“动态配置”。）
SAN 的某一部分（比如 Exchange 服务器）中的大量 IO 会影响我的 SQL 服务器吗？（假设他们没有为每个服务器提供专用磁盘，我被告知他们没有）
请求为不同功能的逻辑驱动器（数据 vs 日志 vs tempdb）分离逻辑驱动器在这里有帮助吗？SAN 会看到这些不同的 IO 活动并以不同的方式优化配置它们吗？
我们现在有点空间紧缩。应用程序团队被告知要修剪数据存档等。空间问题是否会导致 SAN 团队就如何配置可能影响服务器性能的内部存储（RAID 级别等）做出不同的决定？
感谢您的想法（在这个 SF 问题中简要讨论了类似的主题）
我知道有真正的三个种类的碎片，我需要被关心的DBA：
SQL 数据文件中的索引碎片，包括聚集索引（表）碎片。使用 DBCC SHOWCONTIG（在 SQL 2000 中）或 sys.dm_db_index_physical_stats（在 2005+ 中）识别这一点。
SQL 日志文件中的VLF 碎片。运行 DBCC LOGINFO 以查看每个 SQL 日志文件中有多少 VLF。
硬盘驱动器上数据库文件的物理文件碎片。使用 Windows 中的“磁盘碎片整理程序”实用程序对此进行诊断。（灵感来自这篇优秀的博客文章）
很多注意力都集中在索引碎片上（请参阅Paul Randall 的这个出色的 Serverfault 回答），所以这不是我的问题的重点。
我知道我可以在最初创建数据库时通过规划合理的预期数据文件和日志大小来防止物理碎片（和 VLF 碎片），因为这种碎片最常发生于频繁的增长和收缩，但我有一些关于如何修复的问题一旦识别出物理碎片：
首先，物理碎片是否与企业 SAN 相关？我可以/应该在 SAN 驱动器上使用 Windows 碎片整理程序，还是 SAN 团队应该使用内部碎片整理实用程序？在 SAN 驱动器上运行时，我从 Windows 工具获得的碎片分析是否准确？
物理碎片对 SQL 性能的影响有多大？（让我们假设一个内部驱动器阵列，等待上一个问题的结果。）它比内部索引碎片更重要吗？或者它真的是同一类问题（驱动器必须进行随机读取而不是顺序读取）
如果驱动器存在物理碎片，碎片整理（或重建）索引是否是在浪费时间？在我解决另一个问题之前，我需要先修复一个吗？
在生产 SQL 机器上修复物理文件碎片的最佳方法是什么？我知道我可以关闭 SQL 服务并运行 Windows Defrag，但我也听说过一种技术，您可以执行完整备份，删除数据库，然后从备份还原到空驱动器。是否推荐使用后一种技术？从这样的备份中恢复是否也会从头开始构建索引，从而消除内部索引碎片？或者它只是将页面顺序返回到与备份时相同的顺序？（如果这很重要，我们正在使用带有压缩的 Quest Lightspeed 备份。）
更新：到目前为止，关于是否对 …
从备份还原 SQL 数据库是否会从头开始重建其表和索引？或者它是否保持与备份时相同的内部物理顺序？
我们将 SQL 2000 与 Quest Lightspeed 压缩备份一起使用，如果这有什么不同的话。
如果您接到有关 SQL Server 性能问题的电话/页面，您首先做什么？
开始追踪？弹出 Perfmon？打开活动监视器？
这些都是有用的工具，但是您的故障排除“顺序”是什么？
很多文章（请参阅Slava Oks 的原始 SQL 2000 文章和Kevin Kline 的 SQL 2005 更新）建议在 SQL 服务器上禁用超线程，或者至少在服务器上启用超线程之前测试您的特定工作负载。
随着真正的多核处理器取代超线程处理器，这个问题逐渐变得不那么重要，但目前在这个问题上的智慧是什么？这个建议是否对 SQL 2005 64 位、SQL 2008 或 Windows Server 2008 有任何改变？
理想情况下，这应该在登台环境中提前进行测试，但是对于已经启用 HT 的服务器呢？如何判断我们遇到的性能问题是否与 HT 相关？与我在提高 SQL 性能时通常追求的所有其他事情相反，是否有一些特定的 perfmon 计数器组合可能会指向这个方向？
编辑：这特别有吸引力，因为我的一些高 cpu 服务器有可能得到全面改进，但客户端将希望看到一些具体的东西，以帮助我确定哪些服务器真正可以从禁用超线程中受益。当然，传统的性能故障排除正在进行中，但有时任何一点点帮助。
在我们的 SQL 服务器（2000、2005 和 2008）上，我们每天晚上运行一次完整备份，每 2 小时运行一次事务日志备份。我们并没有真正担心这两个过程会发生冲突，但最近我们遇到了以下一些问题：
在一台服务器上，trans log 备份偶尔会阻塞全量备份，必须手动停止全量备份才能完成
我们有时最终会得到一个超大的 trans log 备份文件（有时比完整备份还大！），它似乎是在完整备份运行的同时发生的。
我找到了一个参考，表明这些“不允许”同时运行，无论这意味着什么：SQL 2000 Books Online和SQL 2005 Books Online。我不确定这是否意味着服务器会简单地阻止它们同时运行，或者我们是否应该在完整备份运行时明确停止日志备份。
那么这些之间是否存在已知的冲突/问题？SQL 版本之间的答案是否不同？我是否应该让 trans log 备份作业在执行之前检查完整备份是否正在运行？（我该怎么做……？）
我们混合使用 SQL 2000、2005 和 2008 服务器，并且我们总是在完全备份之前每晚运行一次 DBCC CHECKDB，理论上您希望在备份之前确保数据库处于良好状态. （显然，备份的完整验证只能通过测试还原来完成，但这是一个稍微不同的主题。）
假设我无法将 DBCC 卸载到备份服务器或其他东西（这将是理想的），那么 DBCC CHECKDB 后跟 FULL BACKUP 是最佳顺序吗？
我发现讨论此问题的唯一“最佳实践”文档是我在 TechNet 上找到的 2006 年SAP SQL Server 维护的最佳实践：
理想情况下，应该在执行联机数据库备份之前运行使用 DBCC CHECKDB 的一致性检查。
这个建议正确吗？它是否适用于所有版本的 SQL？
（如果这有帮助，提出这个问题的部分动机是 DBCC 运行时似乎每晚都有相当大的变化，所以我们不能确切地依赖备份何时完成，这使得我们的磁带存档计划工作困难。另外，如果维护时间很长并且由于任何原因必须取消，我宁愿备份可靠地完成而不是 DBCC。）
我有一个 64 位的 Windows 2003 服务器，它有 48 个 CPU 内核和 128GB 的 RAM，运行单个应用程序（SQL 2008 Analysis Services）。SSAS 目前使用大约 50GB 的内存。
SSAS 在很大程度上依赖于 Windows 文件缓存来保存经常使用的数据（例如，请参阅本文）。在我的服务器上，windows 文件缓存通常在 10-15GB 范围内，但偶尔会突然下降到 5-6GB ( Memory\System Cache Resident Bytes)。发生这种情况时，所有 SSAS 页面读取都必须转到磁盘，并且查询开始超时，直到文件缓存重新填充。
我有第二台服务器（只有 24 个内核，但在其他方面几乎相同）没有表现出相同的症状，甚至运行完全相同的 SSAS 实例、相同的查询和相同的负载（这是一个负载平衡的环境） .
我在 dba.stackexchange.com 上问了一个以SSAS 为重点的详细问题，但有几个关于 Windows 行为的问题：
有没有办法知道为什么 SSAS 数据库文件被刷新出缓存？
我可以预先填充文件缓存或以某种方式主动管理它吗？（我不确定在我们的环境中是否可以选择使用 RAMDRIVE）
有一次，我们确实将服务器上的网络优化设置更改为“最大化文件共享的数据吞吐量”以匹配另一个框，但这似乎没有产生显着差异。
编辑：增加了赏金。如果我们不能回答“为什么”，那么也许只是一种更好地了解当前正在使用缓存的进程，或者其中有哪些文件，或者可能引导我们走向正确方向的东西的一种方式。
我们被要求从过去某个时间的存在方式恢复特定的 SQL 2005 作业。我们有那个时间段的 MSDB 数据库备份，但我不能覆盖当前的 MSDB 数据库，因为我不想丢失该服务器上其他作业的最新更改。
如果我将其恢复为副本（称为 MSDB_old 或其他名称），我如何提取该作业的信息？或者我是否需要通过临时服务器上的 MSDB 数据库来恢复它？
试图找出如何确保特定的 Windows Perfmon 计数器日志在服务器重新启动时自动恢复日志记录。
这是一个 Windows 2003 服务器，所以可能不会有人在重新启动后立即登录它。我看到了这个类似的问题，但不认为计划任务在没有人登录的情况下执行...
编辑：好的，看起来计划任务可以设置为在每个服务器启动时运行一个命令，但还有几个问题：
最后一个策略问题：如果我想以这种方式在短时间内监控少数服务器，我最好直接在每台服务器上设置这些监控器，还是直接在我的工作站上运行，远程收集数据?
有没有办法在不加载特定数据库的情况下启动 SQL 2000 实例？我们有一个数据库在数据库恢复过程中的某个时间点使服务器崩溃，我们将尝试从备份中恢复。但是当实例不断重新启动时，我们无法启动恢复。
（如果你很好奇，一个巨大的表重新索引变坏了。它被取消，并试图回滚，但由于某种原因，SQL 服务在回滚期间重新启动。现在我们的情况是服务重新启动，它尝试恢复数据库，然后在中间的某个地方卡住并再次重新启动服务。）
任何帮助或想法表示赞赏。
我在 SQL 2005 上有一个 SPID，它在活动监视器中显示为“ROLLBACK”模式（因为事务日志已满，而不是因为它被手动杀死）。我试着看看还有多少时间可以回滚
KILL 115 WITH STATUSONLY
但它只是说“无法获取状态报告。进程 ID 115 的回滚操作不在进行中。”
我可以安全地发出“KILL 115”以便我可以看到回滚状态吗？这实际上对当前回滚的 spid有什么作用吗？
假设我不能把所有东西都放在 RAID10 上，SQL 的哪些部分（数据文件、日志文件、TempDB、备份等）从 RAID 10 而不是 RAID5 上受益最大？
它是否取决于数据库的类型（OLTP vs Reporting vs Analysis）？
从 RAID5 到 RAID10，我应该看到什么样的实际性能提升？10%？50%？200%？？
技术细节：新的 HP XP24000 磁盘阵列，使用 300GB 15k 驱动器
我们必须预先做出一些决定，将配置为 RAID5 (28x4) 还是 RAID10 (4+4)。这是一次性配置，以后无法更改，因此我们试图在成本/GB 与性能优势之间找到正确的平衡点。