标签: sql-server

我们计划通过同步数据库镜像更新两个 SQL 服务器。这将包括配置为见证服务器的第三个环境。

对于标准的 Windows 修补 - 我们应该以什么顺序修补/重新启动服务器？

我正在尝试安装 SQL Server 2005 Service Pack 3，但它一直失败。返回以下内容：

Microsoft SQL Server 2005 - Update 'Service Pack 3 for SQL Server Database Services 2005 ENU (KB955706)' could not be installed. Error code 1603.

详细的转储揭示了以下内容：

MSI (s) (90:C8) [13:50:17:776]: Note: 1: 1729 MSI (s) (90:C8) [13:50:17:776]: Transforming table Error.   
MSI (s) (90:C8) [13:50:17:776]: Note: 1: 2262 2: Error 3: -2147287038 MSI (s) (90:C8) [13:50:17:792]: Transforming table Error.   
MSI (s) (90:C8) [13:50:17:792]: Transforming table Error.    
MSI (s) (90:C8) [13:50:17:792]: Note: 1: 2262 2: Error …

除了浪费数据库空间之外，SQL Server 上不必要的索引会减慢插入和更新操作的速度。缺乏数据库原理经验的开发人员有时倾向于创建对正在运行的查询没有意义的表索引。

是否有适用于 SQL Server 2005/2008 的通用程序或工具来分析数据库工作负载并提示在某个操作数据库上从未使用或不需要哪些索引？

谢谢！

我们公司的一位架构师设计了一个基于64位SQL2005标准版同步镜像的解决方案，在物理（4个四核，32GB RAM）服务器和虚拟DR服务器（4个虚拟CPU，16GB RAM）之间的两个地理远程数据中心之间见证服务器（1 个虚拟 CPU）。两个数据中心的存储都是企业级 SAN。

前端应用程序面向 Web，具有混合读/写用法。

作为一名 DBA（在设计阶段没有咨询过他），我担心这种配置的设计以最大限度地减少冗余为主要标准，并且它不会作为现实世界的解决方案工作 - 网络延迟和虚拟性能box 会导致不可接受的响应时间吗？如果调用故障转移，则性能甚至会更差。

有没有人有类似设置的经验？

与在一个机器上运行多个 SQL 实例相比，使用虚拟有什么好处？

最近我们有一个 SQL 作业插入到数据库中。该查询已不必要地运行了几天，因此使用 KILL SPID 将其终止。然后这个过程开始回滚好几天，似乎只是挂在那里。

运行 KILL SPID WITH STATUSONLY 给出一条消息，指出“估计完成”为 100%，“估计剩余时间”为 0 秒。

最终，我们不得不重新启动删除该进程的 SQL 服务。

我的问题是 - 你应该如何杀死 SQL 进程？这是唯一的方法吗？

SQL Server 许可，是按 CPU 吗？如果是，那么 32 个 CPU 就意味着 150K 的许可？

我们的 SharePoint 数据库设置为（无意义的）1MB 默认自动增长，我需要“说服”我们的应用程序所有者这是错误的。有没有办法监视 SQL Server 的自动增长活动？

我希望能够报告此活动在 1MB 设置下发生的频率。

我们即将对现有的 Sql 2008 Server 进行硬件升级。因此，我正在查看有关硬件的一些最佳实践，例如 HD 的 RAID 级别，并确保 TempDB 位于与 DB 不同的磁盘上，等等。

然后我在这里和这里偶然发现了这两篇文章。他们谈论确保我们的 Windows 2008 服务器具有正确的分区偏移量 大小。

看完这些帖子我有点困惑。他们在不同的地方提到..

默认情况下，Windows Server 2008 对齐分区。

所以，如果我希望有 64K 的分区大小，我需要担心这个吗？请记住，我将重新安装 Windows Server 2008 .... 我不记得在安装过程中看到任何选项，当我们对磁盘进行分区时，用于分区对齐/大小。

任何人都可以用外行的话解释一下吗？

**注意：我不是在谈论 C:\ == 50Gig 大小、D:\ == xxxGig 等。不是那种类型的分区。

提前：对不起，问题的长度......无法在细节和简洁之间取得适当的平衡。

我们的 Web 应用程序的数据库服务器存在问题，其中应该（并且通常会）在很短的时间内（< 10 毫秒）运行的查询在随机情况下需要 1 到 30 秒的时间来执行 - 没有明显的图案。根据我们的分析器跟踪，其中一些甚至是“无所作为”的查询，例如"exec sp_reset_connection"（通常在 0ms 内运行；观察到 3~6s 的峰值）"SET NO_BROWSETABLE ON"，等等。一些示例是：

SELECT * FROM [Localisation].[TimeZoneRule] WHERE [Name] = 'EU'

其中TimeZoneRule5 列大约有 500,000 行。有一个代理主键和一个索引Name。通常需要 0.97ms，在 11s 达到峰值。表永远不会写入（在上线之前预先填充）。Profiler 将其记录为占用 0-15 个 CPU、18-25 个读取、0-1 个写入（不知道为什么要写入）。

UPDATE [Core].[User] SET [LastUsed] = GETUTCDATE() WHERE Id = '<uid>'

其中User大约 10 列（其中之一是 Xml 列）有大约 30,000 行。Id是集群主键。表定期写入和读取。通常需要10~20ms，在26s达到峰值。Profiler 将其记录为占用 0 个 CPU、15-36 次读取、0-1 次写入。

INSERT INTO [Log].[Session] (ASPSessionId, Start, …