标签: perfmon

我正在分析 SQL Server 2005 的一个实例，通过 PerfMon 的SQLServer:SQL Statistics - SQL Compilations/sec指标，我看到平均值约为 170 左右。

我拿出 SQL Profiler 并寻找 SP:Compile 或 SQL:Compile 事件。显然它们不存在。我确实发现Stored Procedure/SP:Recompile和TSQL/SQL:StmtRecompile事件。我在 Profiler 中看到的数据量表明这些是错误的事件，尽管我不确定。

所以我的问题。对其中任何一个的回答都会很棒。

1. 如何查看 SQL Server 中编译的内容？
2. 我是否选择了错误的指标来查看？在 Perfmon 或 SQL Profiler 中？
3. 至于Stored Procedure/SP:Recompile和TSQL/SQL:StmtRecompile事件在SQL事件探查器，他们不包括持续时间度量。如果这些事件无法查看对系统的时序影响，我该如何衡量这些事件对系统的影响。

扩展事件似乎是一种更好的技术，对服务器的压力更小，但 SQL Profiler/perfmon 具有更好的工具。此外，扩展事件似乎具有更陡峭的学习曲线。每个应该在什么上下文中使用？是否值得通过陡峭的学习曲线来利用扩展事件？

我一直在与 DBA 和几个硬件人员争论我们 SQL 服务器上的性能问题。通常一切都很好，但是在过去的几周里，我们在 sql server 中遇到了巨大的滞后峰值。很明显，SQL Server 正在等待磁盘 I/O。但是我一直被告知这是因为 SQL Server 要求异常高的 I/O。事实并非如此。从运行中可以看出没有任何异常，所有DBA关心的只是导致阻塞的原因等等，这是无用的。例如，我们看到备份的主要内容是对 ASPState 数据库的操作，我们使用它来管理 Web 服务器上的 ASP 会话状态。这些操作通常不会出现在 Sp_who2 活动结果上，因为它们发生得如此之快。数据库处于简单恢复模式，日志记录很少。然而，在这些延迟高峰期间，我们可以看到数据库上的大量选择和更新操作被阻塞或等待。我确信正在发生的事情是某人或某项工作正在运行导致用于该数据库日志和数据文件的 RAID 阵列上大量磁盘使用的东西。问题是要证明这一点，因为没有人愿意承认他们正在做一些正在扼杀我们网站的事情。

我的问题是什么性能计数器或我可以记录的任何内容将有助于显示 SQL Server 正在等待 I/O，但不是因为它要求比正常情况更多，而是因为磁盘忙于响应来自 sql server 的请求像往常一样快吗？

我在 Windows 7 x64 上运行 SQL Server 2008 R2 Developer 作为默认实例。出于某种原因，SQL Server 的性能计数器似乎消失了。SELECT * FROM sys.dm_os_performance_counters返回零行。

我试过跑步lodctr /T:perf-MSSQLSERVERsqlctr.ini。尽管它完成没有错误，但它没有修复任何问题，即使在重新启动远程注册表服务之后也是如此。事实上，现在 perfmon 中缺少计数器。unlodctr MSSQLSERVER仍然说计数器没有安装，但lodctr /Q:MSSQLSERVER说它们存在并启用。常规的 Windows 和 .NET 计数器工作正常。

在 Windows 错误日志中，我看到错误 8317：

无法查询与注册表项“HKLM\SYSTEM\CurrentControlSet\Services\MSSQLSERVER\Performance”关联的值“First Counter”。SQL Server 性能计数器已禁用。

我怀疑该问题可能是由安装失败的 SQL 2012 RC0 触发的。除了重新安装 SQL Server 2008 R2 之外，对如何恢复有什么建议吗？

我已手动将 mdf/ndf 文件调整为较大的大小，以避免对 SQL Server 数据库进行自动增长操作。由于文件较大，磁盘分区上的可用空间很少，系统管理员不断提醒我空间不足。

因为我调整了它们的大小，所以数据文件中有很多可用空间，但在查看文件大小/磁盘可用空间时不会注意到它。

如何监控数据文件的实际使用百分比？我更喜欢使用 perfmon 计数器。我担心当文件真的用完空间时，SQL Server 将无法分配足够的空间并且会崩溃。

我正在努力减少在我们的 SQL Server 上进行关键查找的事务量。

首先，我想为该指标的正常或可容忍数字定义一个基线，并且由于我们在生产中不断发布版本，然后，我想基于它创建一个自动化，当它下降时通知我。

我遇到的问题实际上是在perfmon或 SQL DMV上找到正确的计数器来获取数据。

我查看了明显的对象SQL Server，访问方法对象，但找不到特定的对象。我还尝试了其他计数器或 SQL 视图，但找不到。

任何建议将不胜感激！

某些返回自启动以来递增的各种统计信息的 DMV 查询将用作性能计数器。

例如，取：

SELECT wait_type, wait_time_ms FROM sys.dm_os_wait_stats;

大多数监控工具都知道如何获取递增的数字并将其转换为速率，因为这就是 SNMP 计数器的工作方式。有没有人知道任何将这些类型的统计数据转换为 DMV 查询的预先存在的工具？

我一直在查看我们客户的一个 SQL Server 实例上的各种 PerfMon 指标，试图很好地衡量我们的数据库（或服务器）可以在哪里使用改进。

让我感到困惑的一项衡量标准是两个 PerfMon 指标的比率：编译/秒和批处理请求/秒。

根据这篇文章，“一般的经验法则是编译/秒应为总批处理请求数/秒的 10% 或更少”。

我们的应用程序有一个 Windows 服务，它每小时对数据库调用一次预定计算。就像发条一样，在我的 PerfMon CSV 数据中，我可以看到 Compilations/sec 和 Batch Requests/sec 的峰值。我没想到的是编译数/秒超过了批处理请求/秒。

我正在查看来自 PerfMon 的 15 秒样本，这些样本以我们的计算开始的时间为中心：

这通常表明什么？这甚至有意义吗？为什么我们要编译更多的语句而不是执行？我错过了什么吗？

我在这里读到（http://www.databasejournal.com/features/mssql/article.php/3932406/Top-10-SQL-Server-Counters-for-Monitoring-SQL-Server-Performance.htm）具有高PageSplits/sec 的值与 BatchRequests/sec 的值相比（在我发布的链接中，参考值为 20%）这是一件坏事，可能是 I/O 问题）。

我尝试使用性能监视器在生产系统中跟踪这两个值，这就是我得到的：

在 RED 中，它是 PageSplits/sec.，另一个是 BatchRequests/sec。

两者的比例都是 1,0（我希望我不会在比较它们时失败）。

有问题吗？

编辑：

由于 Datagod 要求对所涉及的表进行描述，因此我在此处发布了最大表的创建脚本以及可能导致我们性能问题的罪魁祸首。这张表包含大约 350 万行，通常是读密集型和写密集型

/****** Object:  Table [dbo].[e1_tur_ordini_giorno]    Script Date: 11/09/2015 17:31:09 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

SET ANSI_PADDING ON
GO

CREATE TABLE [dbo].[e1_tur_ordini_giorno](
    [id] [varchar](36) NOT NULL CONSTRAINT [DF__e1_tur_ordin__id__5E7FE7D2]  DEFAULT (N'0'),
    [dt_ordine_giorno] [date] NULL CONSTRAINT [DF__e1_tur_or__dt_or__5F740C0B]  DEFAULT (NULL),
    [n_ore] [decimal](10, 2) NULL CONSTRAINT [DF__e1_tur_or__n_ore__60683044]  DEFAULT (NULL),
    [hh_inizio] [varchar](10) NULL CONSTRAINT [DF__e1_tur_or__hh_in__615C547D]  DEFAULT (NULL),
    [hh_fine] [varchar](10) …

我已经用谷歌搜索过这个，到目前为止，没有运气，所以向所有伟大的专家寻求帮助。

我试图弄清楚是否有办法使用 t-sql 获取性能计数器“内存：页/秒”，因为我试图将其添加为我们的 Ignite 监控工具中的自定义指标。我查看了 sys.dm_os_performance_counters DMV 但没有在那里找到它。

有人知道这样做的方法吗？提前致谢 ：）