我已经尝试了许多用于监控SQL Server运行状况的技术,包括使用SQL Server 2008中内置的管理数据仓库功能,以及其他商业产品(如Confio Ignite 8),当然还有使用我自己的解决方案. perfmon,性能计数器和从动态管理视图和功能中收集各种信息.
我发现的是,虽然这些方法中的每一种都有自己的相关优势,但它们都有相关的弱点.我觉得实际上让组织内的人员认真监控SQL Server性能无论我们推出什么解决方案都必须非常简单和快速使用,必须提供某种形式的仪表板,并且监控行为必须具有最小化对生产数据库的影响(或许更重要的是,必须有可能证明这是事实).
所以我很想知道其他人正在使用什么来完成这项任务？有什么建议？
目前,我们的一个数据库(SQL Server 2008)通过许多不同的机制进行访问:.Net SqlClient Data Provider; SQL Server Management Studio; 各种.Net应用程序和2007 Microsoft Office系统(基本上是Excel).
我看到在sys.dm_exec_sessions DMV中,可以看到访问当前会话数据库的程序的程序名称.我的问题是:是否有可能拒绝来自特定命名程序的访问？如果可以为任何已命名的程序执行此操作,那么将获得一等奖,但是我们可以从所有Microsoft Office应用程序(尤其是Excel)拒绝访问此特定数据库,从而获得很多好处.
我发现,在具有适当索引的索引视图上,MAX(日期)执行整个索引扫描,然后执行流聚合,而TOP(1)日期最佳地使用索引并且仅扫描单个行.对于大量行,这会导致严重的性能问题.我已经包含了一些代码来演示下面的问题,但有兴趣知道其他人是否可以解释为什么会发生这种行为(它不会出现在具有类似索引的表上)以及它是否是SQL Server优化器中的错误(I已经在2008 SP2和R2上进行了测试,两者都显示了相同的问题).
CREATE TABLE dbo.TableWithDate
(
id INT IDENTITY(1,1) PRIMARY KEY,
theDate DATE NOT NULL
);
CREATE NONCLUSTERED INDEX [ix_date] ON dbo.TableWithDate([theDate] DESC);
INSERT INTO dbo.TableWithDate(theDate) VALUES('1 MAR 2010'),('1 MAR 2010'), ('3 JUN 2008');
-- Test 1: max vs top(1) on the table. They give same optimal plan (scan one row from the index, since index is in order)
SELECT TOP(1) theDate FROM dbo.TableWithDate ORDER BY theDate DESC;
SELECT MAX(theDate) FROM dbo.TableWithDate;
CREATE TABLE dbo.TheJoinTable
(
identId INT IDENTITY(1,1) …我们目前正在TFS数据库中经历重要的等待,并且正在尝试了解这些是否是数据库中tbl_Version版本历史表的大小的结果.
目前,该表包含超过2000万条记录,占用大约6GB的存储空间(总索引空间刚刚超过10GB).查看SQL Server必须处理的查询,只要访问此表,我们就会有高PAGEIOLATCH_SH等待.显然,我们无法控制在数据库中抛出的查询(TFS的所有部分).
目前我们在虚拟机上有TFS,并且本质上想要了解我们是否应该(a)移动到物理机器,(b)尝试减小tbl_version的大小或(c)遵循这些的组合.
在我们的组织中,移动到物理服务器是非常重要的,因此我想在做出任何此类决定之前了解我们的表格大小是否"正常".