除了使用 SQL Server Profiler 之外，还有什么方法可以跟踪正在使用的存储过程，或者至少是上次执行它们的时间？

是否有人在实际生产中使用 HierarchyId 使用合理大小的表，超过几千行？它可靠/性能好吗？到目前为止，我还没有发现任何与供应商无关的人推荐它，并且 Paul Nielsen在这里建议不要使用它。

您在实际生产系统中使用 HierarchyId 的经验是什么？

当您选择 HierarchyId 而不是其替代品时，您使用了哪些标准？

SELECT这段代码中的三个语句

USE [tempdb];
GO

SET NOCOUNT ON;

CREATE TABLE dbo.persist_test (
      id            INT NOT NULL
    , id5           AS (id * 5)
    , id5p          AS (id * 5) PERSISTED
);

INSERT INTO dbo.persist_test (id)
VALUES (1), (2), (3);

SELECT id
FROM dbo.persist_test;

SELECT id5
FROM dbo.persist_test;

SELECT id5p
FROM dbo.persist_test;

DROP TABLE dbo.persist_test;

生成这个计划：

为什么SELECT选择持久值的 final生成计算标量运算符？

我必须跟踪 SQL Server 2008 R2 中的数据。SQLFiddle

架构：

创建表 [dbo].[ICFilters](
   [ICFilterID] [int] IDENTITY(1,1) 非空，
   [ParentID] [int] NOT NULL DEFAULT 0,
   [FilterDesc] [varchar](50) NOT NULL,
   [Active] [tinyint] NOT NULL DEFAULT 1,
 约束 [PK_ICFilters] 主键聚集 
 ( [ICFilterID] ASC ) 与 
    PAD_INDEX = 关闭，
    STATISTICS_NORECOMPUTE = 关闭，
    IGNORE_DUP_KEY = 关闭，
    ALLOW_ROW_LOCKS = 开，
    ALLOW_PAGE_LOCKS = 开
 ) 在 [主要]
) 在 [主要]

INSERT INTO [dbo].[ICFilters] (ParentID,FilterDesc,Active)
价值观 
(0,'产品类型',1),
(1,'ProdSubType_1',1),
(1,'ProdSubType_2',1),
(1,'ProdSubType_3',1),
(1,'ProdSubType_4',1),
(2,'PST_1.1',1),
(2,'PST_1.2',1),
(2,'PST_1.3',1),
(2,'PST_1.4',1),
(2,'PST_1.5',1),
(2,'PST_1.6',1),
(2,'PST_1.7',0),
(3,'PST_2.1',1),
(3,'PST_2.2',0),
(3,'PST_2.3',1),
(3,'PST_2.4',1), …

我有 2 个存储过程，其中第二个存储过程是第一个的改进。

我正试图通过究竟有多少改进来衡量。

1. clock time由于执行时间不同，因此测量似乎不是一种选择。更糟糕的是，有时（很少，但确实发生过）第二个存储过程的执行时间比第一个过程的执行时间大（我猜是因为当时服务器的工作量）。

2. Include client statistics 也提供不同的结果。

3. DBCC DROPCLEANBUFFERS，DBCC FREEPROCCACHE很好，但同样的故事......

4. SET STATISTICS IO ON 可能是一种选择，但是由于我的存储过程中涉及许多表，我怎么能获得总分呢？

5. Include actual execution plan也可以是一个选择。我得到estimated subtreecost的0.3253的第一个存储过程，以及0.3079为第二个。我可以说第二个存储过程快 6% (=0.3253/0.3079) 吗？

6. 使用 SQL Server Profiler 中的“读取”字段？

那么我怎么能说第二个存储过程比第一个过程快 x%，无论执行条件如何（服务器的工作量，执行这些存储过程的服务器等）？

如果不可能，我如何证明第二个存储过程比第一个存储过程具有更好的执行时间？

我试图UNPIVOT在sys.databases2005 年到 2012 年的各种版本的 SQL Server 中包含的各种列上运行。

在UNPIVOT与以下错误消息失败：

Msg 8167, Level 16, State 1, Line 48

“CompatibilityLevel”列的类型与 UNPIVOT 列表中指定的其他列的类型冲突。

T-SQL：

DECLARE @dbname SYSNAME;
SET @dbname = DB_NAME();

SELECT [Database]            = unpvt.DatabaseName
    , [Configuration Item]   = unpvt.OptionName
    , [Configuration Value]  = unpvt.OptionValue
FROM (
    SELECT 
        DatabaseName = name 
        , RecoveryModel                 = CONVERT(VARCHAR(50), d.recovery_model_desc)
        , CompatibilityLevel            = CONVERT(VARCHAR(50), CASE d.[compatibility_level] WHEN 70 THEN 'SQL Server 7' WHEN 80 THEN 'SQL Server 2000' WHEN 90 THEN 'SQL …

最近在遇到恢复数据库的脚本时，我对为什么必须使用“ FILE = 1 ”产生疑问？没有那个语句我们就不能恢复数据库吗！？基本上，它是用来做什么的？

根据此博客，函数或存储过程的参数如果不是OUTPUT参数，则本质上是按值传递的，如果它们是参数，则基本上被视为按引用传递的更安全版本OUTPUT。

起初我认为强制声明 TVP 的目的READONLY是向开发人员明确表示 TVP 不能用作OUTPUT参数，但必须有更多的进展，因为我们不能将非 TVP 声明为READONLY. 例如以下失败：

create procedure [dbo].[test]
@a int readonly
as
    select @a

消息 346，级别 15，状态 1，过程测试
参数“@a”不能声明为 READONLY，因为它不是表值参数。

1. 由于统计信息未存储在 TVP 上，因此阻止 DML 操作的基本原理是什么？
2. 是否与OUTPUT出于某种原因不希望 TVP 成为参数有关？

产生“Excessive Grant”执行计划警告的条件是什么？

查询内存授予检测到“ExcessiveGrant”，这可能会影响可靠性。授权大小：初始 5128 KB，最终 5128 KB，已用 16 KB。

安全管理系统

计划浏览器

展示计划 xml

<Warnings>
    <MemoryGrantWarning GrantWarningKind="Excessive Grant"
        RequestedMemory="5128" GrantedMemory="5128" MaxUsedMemory="16" />
</Warnings>

简单的问题

SQL Server Quantum (4 ms) 如何与 Server OS Quantum（通常：187.5 ms）同步？

简单问题解释

在使用 184 ms 的 OS 量程后（对应于 46 个完整的 SQL 量程），OS 量程有 3.5 ms 的时间，然后它必须将调度移交给不同的进程。SQL 操作系统启动一个时间段（4 毫秒），在 3.5 毫秒后，操作系统时间段决定停止当前的 SQL 操作系统线程，该线程在它产生计划之前还有 0.5 毫秒。现在会发生什么？

深入了解 OS Quantum

在接下来的几节中，我将写出迄今为止我所发现的关于 OS 量程以及如何计算量程的持续时间。操作系统“量子”的持续时间基于“滴答”，而“滴答”本身的持续时间基于“时钟间隔”，通常为 15.625000 毫秒。但是让我详细说明一下......

打钩

在博客文章Know Thy Tick 中，作者 Jim 解释了时钟间隔（又名“滴答”）的基础知识以及它们的用途。

当我读到诸如“时钟间隔……对于大多数 x86 多处理器大约为 15 毫秒”之类的内容时，我不得不确定我的时钟或“滴答”间隔的值。幸运的是，我在书中读到了这句话，Windows Internals第四版提供了一个参考来帮助我解决我的痛苦。... 上述书籍的作者 Mark Russinovich 慷慨地在其网站上提供了ClockRes实用程序。运行此实用程序，我能够确定我的 x86 多处理器 PC 上的时钟间隔为 15.625000 毫秒。有趣，但我好奇的头脑想知道更多。

量子

文章作者在他的第二篇文章中继续解释 那...

当然，tick 间隔重要的真正原因是它会影响线程调度。Windows 调度程序在允许另一个具有相同优先级的任务运行之前，为每个线程提供一个“时间”来执行。调度程序分配给线程的量程是滴答间隔的倍数。为特定线程选择的特定量子值有点超出我想在本文中讨论的内容。

好的，所以我知道什么是量子，但不知道量子将运行多长时间。 …