Mark Freeman's questions

当我执行这个时：

DROP TABLE IF EXISTS #QueryHashes;
CREATE TABLE #QueryHashes (query_hash BINARY(8) NOT NULL PRIMARY KEY);

PRINT CAST(0x0169857CCD5BBBE4E AS BINARY(8)); -- just testing that the value is a legitimate BINARY(8)

/* Insert your query_hash values inside the outer parenthesis below, 
   each wrapped in parenthesis, comma-separated (for example, "(0x89E35F2D4C638298), (0x89E35F2D4C638298)") 
*/
INSERT INTO #QueryHashes (query_hash)
VALUES (0x0169857CCD5BBBE4E);

PRINT CAST(0x0169857CCD5BBBE4E AS BINARY(8)); -- just testing that the value is a legitimate BINARY(8)

我收到此错误：

0x00169857CCD5BBBE 消息 2628，级别 16，状态 1，第 9 行 字符串或二进制数据将在表“tempdb.dbo.#QueryHashes_________________________________________________________________________________________________________000000000D06”列“query_hash”中被截断。截断值：''。该语句已终止。0x00169857CCD5BBBE

请注意，错误消息中的值似乎是一个空字符串。

显然，插入物失效了，而铸件却可以工作。谁能帮助我理解插入或表定义有什么问题？即使我删除“NOT NULL PRIMARY KEY”，我仍然收到相同的错误。

（最终的目的是向表中插入一些值，并将其连接到一个大查询中。）

为什么这两个查询会产生不同的结果（但彼此相差大约一分钟）？

SELECT  StartTime   =   sqlserver_start_time
  FROM  sys.dm_os_sys_info;

SELECT  StartTime   =   DATEADD(MILLISECOND, sqlserver_start_time_ms_ticks - ms_ticks, GETDATE()) 
  FROM  sys.dm_os_sys_info;

哪个更准确？

当我在 Azure SQL 数据库 (v12) 或 SQL Server 2016 实例中执行以下代码时，我在 EstimatedRowsRead 列中获得了值，但在EstimatedRows列中却没有，我不明白为什么。有任何想法吗？

SET NOCOUNT ON;
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

WITH XMLNAMESPACES(DEFAULT 'http://schemas.microsoft.com/sqlserver/2004/07/showplan')
,PlanHandles AS (
    SELECT  plan_handle
            ,total_elapsed_time =   SUM(total_elapsed_time)
            ,execution_count    =   SUM(execution_count)
      FROM  sys.dm_exec_query_stats
     GROUP  BY plan_handle
)
,Plans AS (
    SELECT  ph.plan_handle, qp.query_plan, ph.total_elapsed_time, ph.execution_count
      FROM  PlanHandles ph
            OUTER APPLY sys.dm_exec_query_plan(ph.plan_handle) qp
)
SELECT  p.total_elapsed_time
        ,p.execution_count
        ,p.plan_handle
        ,p.query_plan
        ,NodeId                 =   s.i.value(N'@NodeId', N'INT') 
        ,EstimatedRowsRead      =   s.i.value(N'(@EstimatedRowsRead)[1]', N'FLOAT')
        ,EstimatedRows          =   s.i.value(N'(@EstimatedRows)[1]', N'FLOAT')
  FROM  Plans p
        CROSS APPLY query_plan.nodes('/ShowPlanXML/BatchSequence/Batch/Statements/*') q(n)
        CROSS APPLY n.nodes('.//RelOp[IndexScan and IndexScan/Object[@Schema!="[sys]"]]') s(i)
 WHERE  s.i.value(N'(@EstimatedRowsRead)[1]', N'FLOAT') > 1.0;

我在查询存储中的 Azure SQL 数据库（强制参数化 = FORCED、参数嗅探 = ON 和查询优化器修复 = ON）中看到以下查询：

delete from [CMS_WebFarmTask] 
where [TaskIsAnonymous] = @0 
and [TaskID] not in ( select [TaskID] from [CMS_WebFarmServerTask] ) 
and [TaskCreated] < dateadd ( minute , @1 , getdate ( ) )

它有大量的计划（最后一小时有 17 个），尽管两个参数都是整数，每个计划中的值都相同：

        <ParameterList>
          <ColumnReference Column="@1" ParameterDataType="int" ParameterCompiledValue="(-3)" />
          <ColumnReference Column="@0" ParameterDataType="int" ParameterCompiledValue="(0)" />
        </ParameterList>

为什么不只使用一个计划？

SQL Server 缓存在存储过程中创建的临时表，并且仅在过程结束并随后执行时重命名它们。我的问题与 tempdb 空间何时释放有关。我读过该表在程序结束时被截断。我在评论中读到这是在每个会话的基础上处理的，并且在 MSDN上看到了一个关于是否需要清理的问题。但是如果它从来没有被同一个会话执行两次呢？

我还听说有一个后台垃圾收集进程，一旦表超出范围，就会释放该空间。

在创建临时表的存储过程结束时截断临时表似乎会导致表在 tempdb 中用于释放数据的空间比不使用 truncate 语句时释放得更快，尽管预期相反。为什么？

使用或不使用这样的截断语句对性能有何影响？使用 SNAPSHOT 隔离时，tempdb 经常受到压力，我认为尽快从大型临时表中释放 tempdb 中使用的空间可以防止 tempdb 不必要的增长。这种潜在的空间节省会以性能为代价吗？

这是一些重现问题的代码（主要来自@TheGameiswar，有一些更改）：

SET NOCOUNT ON;
GO
ALTER PROC usp_test
AS
BEGIN
    IF object_id('tempdb..#temp') IS NOT NULL
        DROP TABLE #temp

    SELECT *
    INTO #temp
    FROM [dbo].[Event_28] -- This is a table with 15313 rows, using 35648 KB according to sp_spaceused

    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS BeforeTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;
 --   TRUNCATE TABLE #temp
    --SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    --  ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    --  ,getdate() AS AfterTruncate
    --FROM tempdb.sys.dm_db_file_space_usage;

END
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'before'
FROM tempdb.sys.dm_db_file_space_usage;

EXEC usp_test
GO

SELECT SUM(user_object_reserved_page_count) AS [user object pages used]
    ,(SUM(user_object_reserved_page_count) * 1.0 / 128) AS [user object space in MB]
    ,getdate() AS 'final'
FROM tempdb.sys.dm_db_file_space_usage;
GO 40

注释的行在某些运行中被注释掉，而在其他运行中未注释。当TRUNCATE被注释掉时，tempdb.sys.dm_db_file_space_usage查询结果（多 4472 页和大 34.9375 MB）与执行过程之前的结果匹配需要 2.25 到 4.5 秒。在未注释行（包括TRUNCATE）的情况下，只需要大约 0.11 - 0.9 秒。这些结果来自实时系统，在此实验期间源表中有一些小数据增长。

注释掉代码的示例输出（从第一个到最后一个“最终”条目的 2.69 秒）：

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:42.197

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.423

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.533

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.643

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.883

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:42.990

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.100

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.450

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.650

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.767

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:43.993

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.103

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.213

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.437

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.553

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.663

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:44.887

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6000                   46.875000                               2017-10-04 21:03:45.003

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:03:45.113

未注释代码的示例结果（从第一个到最后一个“最终”条目的 0.11 秒）：

user object pages used user object space in MB                 before
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:39.807

user object pages used user object space in MB                 BeforeTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

user object pages used user object space in MB                 AfterTruncate
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:39.923

Beginning execution loop
user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
6016                   47.000000                               2017-10-04 21:07:40.160

user object pages used user object space in MB                 final
---------------------- --------------------------------------- -----------------------
1536                   12.000000                               2017-10-04 21:07:40.270

在我目前管理的大约 50 个实例中，我有两个几乎每晚都有一个死锁，涉及“INSERT INTO msdb.dbo.sysjobhistory”（始终是受害者）和由“EXEC”调用的“DELETE FROM msdb.dbo.sysjobhistory” msdb.dbo.sp_purge_jobhistory”，这两个会话都由 SQL Server 代理服务帐户运行。我从来没有在任何其他情况下遇到过这样的僵局，也没有在任何以前的工作中遇到过这样的僵局。在每台服务器中，死锁发生在夜间的不同时间（sp_purge_jobhistory 每周计划运行的周六 1:30 或 syspolicy_purge_history 的夜间计划中的每一步运行的 2:01）。

这两个“问题”实例与其他任何实例之间似乎没有任何明显不同。一个是 2012 SP3 CU3 测试服务器，另一个是 2012 SP2 生产实例。

关于如何防止这种情况的任何想法？

sp_Blitz (20160715) 在很少使用的 2012 SP2 CU12 测试实例（开发人员版）上报告“可用内存过多”，该实例仅包含由 SSRS 创建和使用的数据库。详情如下：

SQL Server 的缓冲池中有 0GB 的可用内存，即 0GB。您可能认为大量可用内存会很好，但请查看 URL 以获取更多信息。

我修改了查询以返回原始值并得到 Free = 587,896 和 Total = 1,052,256。我改变的查询：

SELECT Free = cFree.cntr_value, Total = cTotal.cntr_value
FROM sys.dm_os_performance_counters cFree
INNER JOIN sys.dm_os_performance_counters cTotal ON cTotal.object_name LIKE N'%Memory Manager%'
    AND cTotal.counter_name = N'Total Server Memory (KB)                                                                                                        '
WHERE cFree.object_name LIKE N'%Memory Manager%'
    AND cFree.counter_name = N'Free Memory (KB)                                                                                                                '
    AND CAST(cTotal.cntr_value AS BIGINT) * .3 <= CAST(cFree.cntr_value AS BIGINT)
     AND CAST(SERVERPROPERTY('edition') AS VARCHAR(100)) NOT LIKE '%Standard%'

dbo.sp_BlitzCache (@BringThePain = 1) 显示 316 行，显然都是内置的 SSRS 管理语句。是否更有可能：

1. 我遇到了https://www.brentozar.com/blitz/too-much-free-memory/中描述的问题 ，或者
2. sp_Blitz 查询的 WHERE 子句需要调整以避免在这种情况下出现误报

在 SQL Server 2012 中，我有一个 Job Agent Alert 设置如下：

EXEC msdb.dbo.sp_add_alert @name=N'Deadlock Alert', 
        @message_id=0, 
        @severity=0, 
        @enabled=1, 
        @delay_between_responses=0, 
        @include_event_description_in=1, 
        @category_name=N'[Uncategorized]', 
        @performance_condition=N'Locks|Number of Deadlocks/sec|_Total|>|0', 
        @job_id=N'00000000-0000-0000-0000-000000000000'

我有一个计划在每个工作日下午 5:30 运行的作业执行此步骤：

EXEC msdb.dbo.sp_update_alert @name = N`enter code here`'Deadlock Alert', @enabled = 0;

我有另一个在每个工作日的上午 8:00 重新启用警报。在许多情况下，这两项工作（和警报）都可以正常工作数月。但是周五下午 5:30 的工作在一个实例中失败，并显示以下消息：

指定的 object_name ('Locks') 不存在。[SQLSTATE 42000]（错误 14262）指定的对象名称（“数据库”）不存在。[SQLSTATE 42000]（错误 14262）。该步骤失败。

如果我直接为该警报执行 sp_update_alert 命令（启用设置为 0 或 1）。我收到此错误：

消息 14262，级别 16，状态 1，过程 sp_verify_performance_condition，第 50 行指定的对象名称（“锁”）不存在。

我尝试使用 SSMS UI 禁用警报并得到：

指定的 object_name ('Locks') 不存在。（Microsoft SQL 服务器，错误：14262）

这对作业在所有其他实例中仍在正常运行，没有错误。是什么导致 sp_update_alert 失败，这只是在一个实例中，而且是从星期五开始的？

[添加：]

启用和禁用作业还启用和禁用另一个警报，该警报查看 SQLServer:Databases|Data File(s) Size (KB)|tempdb 计数器，这些命令抛出错误“指定的对象名称（‘数据库’）不存在”。同样，仅在这一次。相同的作业和警报在同一台服务器上的另一个实例上仍然可以正常工作。

我在 Visual Studio Professional 2015 中使用 SSDT 14.0.50730.0。我正在比较两个实例之间的数据库，发现存在与其签名不匹配的存储过程。

在这两种情况下，证书都是在每个实例中使用相同的脚本创建的，并且签名也是由 CERTIFICATE 使用密码在每个实例中使用相同的脚本添加的。

但是，架构比较显示源和目标中的过程都显示为具有带有不匹配的签名值的签名的证书。生成的发布脚本删除证书签名，修改过程，然后添加证书签名带签名。签名值与源实例中显示的相匹配。但是，脚本失败并显示消息“公钥的签名无效”。

我必须做什么才能使这些程序同步？

我已经执行了以下操作：

USE [MyDatabase];
GO
CREATE LOGIN [MyDomain\MyAccount] FROM WINDOWS WITH DEFAULT_DATABASE=[MyDatabase];
CREATE USER [MyDomain\MyAccount] FOR LOGIN [MyDomain\MyAccount];
GRANT EXECUTE   ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];
GRANT SELECT    ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];
GRANT INSERT    ON SCHEMA::[MySchema] TO [MyDomain\MyAccount];

（我没有授予任何角色，因为我不希望此登录名能够访问此数据库中的任何其他模式。）

我以 MyDomain\MyAccount 身份运行 SSMS（以其他用户身份运行）。然后我尝试连接到这个实例。但是，我得到：

无法打开用户默认数据库。登录失败。
用户“MyDomain\MyAccount”登录失败。（Microsoft SQL Server，错误：4064）

如果我在连接属性中将默认数据库设置为 MyDatabase，我会得到相同的结果。

我运行了 Profiler 跟踪并看到错误 18456 状态 38：

用户“MyDomain\MyAccount”登录失败。原因：无法打开明确指定的数据库“MyDatabase”。[客户：我的IP地址]

随后是错误 18456 状态 40：

用户“MyDomain\MyAccount”登录失败。原因：无法打开登录属性中指定的数据库“MyDatabase”。[客户：我的IP地址]

MyDatabase 在线，我可以通过不同的登录名轻松连接到它。我需要向 MyDomain\MyAccount 授予哪些额外权限？还有什么我想念的吗？

我有一份僵局报告告诉我存在涉及的冲突

waitresource="KEY: 9:72057632651542528 (543066506c7c)"

我可以看到这个：

<keylock hobtid="72057632651542528" dbid="9" objectname="MyDatabase.MySchema.MyTable" indexname="MyPrimaryKeyIndex" id="locka8c6f4100" mode="X" associatedObjectId="72057632651542528">

<resource-list>元素内。

我希望能够找到键的实际值（例如 id = 12345）。我需要使用什么 SQL 语句来获取该信息？

我在两个不同的生产服务器中有一个数据库。我想保持两者之间的模式一致。一个具有调用引用链接服务器的存储过程的作业。另一个不（也不应该）包含那些作业或与第一台服务器中同名的链接服务器，但我希望两台服务器都具有相同的存储过程。但是，SQL Server 拒绝在没有设置链接服务器的服务器上创建引用链接服务器的过程。我理解为什么会发生这种情况，但我需要一个不涉及更改过程代码的解决方法（例如使用动态 SQL 来隐藏编译器的引用）。

我尝试创建一个指向本地服务器的预期名称的链接服务器，但 SQL Server 足够聪明，可以看到该链接服务器上不存在引用的表。如果我为不存在的服务器创建一个，则 SQL 在创建过程期间会超时，说它无法连接到远程服务器。

有没有办法创建一个虚拟链接服务器，这样 SQL Server 就不会尝试验证链接服务器上的表名？

在 SQL Server 2012 SP2 标准版实例中，我在数据库 A 中有一个用户需要能够在该数据库中的模式 foo 中运行存储过程。他们不应该做任何其他事情。例如，他们不应该能够直接从任一数据库中的任何视图或表进行 SELECT。

存储过程从数据库 A 和 B 中的表中选择。我创建了 WITH EXEC AS OWNER 过程。数据库 A 归 sa 所有，sa 具有 sysadmin 角色，因此应该可以访问这两个数据库。我跑了这个：

USE [master]
GO
CREATE LOGIN [foo] WITH PASSWORD=N'foo', DEFAULT_DATABASE=[A]
GO
USE [A]
GO
CREATE USER [foo] FOR LOGIN [foo]
ALTER ROLE [db_executor] ADD MEMBER [foo];
GO
GRANT EXECUTE ON SCHEMA :: [Bar] TO [foo];

然后我以 [foo] 身份连接并执行该过程，但收到错误消息：

消息 916，级别 14，状态 1，过程 GetReport，第 10 行 服务器主体“sa”无法在当前安全上下文中访问数据库“A”。

将 TRUSTWORTHY 设置为 ON 似乎打开的东西比可接受的要多得多。还有其他解决方案吗？

在 SQL Server 2012 SP1 实例中，我在表的 PK 列上有一个筛选索引，如下所示：

CREATE INDEX [RF_IXF_Orders_OrderNumber] ON [dbo].[Orders]
(
    [OrderNumber] ASC
)
WHERE [OrderSource]='MO'
AND [Cancelled]=(0)
AND [NumItems]>(0)
AND [OrderDate]>'2014-05-15';

索引的 Row Count (dm_db_partition_stats.row_count) 为 8416，Rows Changed (sysindexes.rowmodctr) 为 16803 (193.6%)，Auto Update Statistics 为 True。已有 8400 次 user_scans 和 50,088 次 user_updates。最后一次 user_scan 是今天，但统计数据已经大约一周没有更新了。

为什么统计数据不会自动更新？

我有一个正在更新的包。该包由 Job Agent 作业执行。删除包并部署新版本后，我运行一个脚本来执行任何必要的 [create_environment]、[create_environment_reference]、[create_environment_variable] 和 [set_object_parameter_value] 语句。

但是，当我开始作业时，它会失败并显示以下错误消息（其中“n”是一个数字，它不会作为任何类型的 id 出现在任何相关的 SSISDB 表或视图中）：

环境引用 n 与项目无关

我正在使用带有 SQL Server Data Tools 的 Visual Studio 2012 Professional 和 SQL Server 2012 标准版数据库实例。
我无法在我的开发机器或托管 SQL Server 实例的服务器上找到 master.dacpac 文件。

我怎样才能获得这个文件，所以我可以摆脱如下警告：

SQL71502: Procedure: <ProcedureName> has an unresolved reference to object [sys].[objects]  

我在 Job Agent 中安排了一份工作（更新工单），其中有一个单独的时间表“每天中午 12:00:00 到晚上 11:59:59 之间每 30 分钟发生一次。时间表将从 11/ 开始使用4/2013。” 当我使用日志文件查看器查看此作业的历史记录时，我在昨天的 2.5 小时内没有看到任何条目。同一台服务器上的其他作业在此作业执行期间运行。

该作业从链接服务器的 OpenQuery 中执行 SELECT 中的 INSERT。如果网络或其他问题导致无法成功连接到数据源，我仍然希望在日志中看到作业失败消息，但我根本看不到它的任何条目。SQL Server 日志、SQL Server Agent 日志以及 Windows 系统或应用程序日志均未显示间隔期间的任何相关信息。

造成这种情况的可能原因是什么？

谢谢，

标记

我希望有人能对这种我没有预料到的关于 SNAPSHOT 隔离与 TRUNCATE 的行为有所了解。

数据库：允许快照隔离 = True；是否已提交读取快照打开 = False。

过程 1（用大量连接替换长时间运行的复杂 SELECT 表 foo 的内容）：

BEGIN TRAN; 
TRUNCATE TABLE foo; 
INSERT INTO foo SELECT...; 
COMMIT;

程序 2（从表 foo 中读取）：

SET TRANSACTION ISOLATION LEVEL SNAPSHOT; 
SELECT * FROM foo;

如果在执行 Procedure2 时 Procedure1 正在运行，则 Procedure2 将等待 LCK_M_SCH_S 等待（根据 sp_WhoIsActive），直到 Procedure1 完成。当 Procedure2 完成时，它会引发此异常：

数据库“DatabaseName”中的快照隔离事务失败，因为自该事务开始以来，该语句访问的对象已被另一个并发事务中的 DDL 语句修改。这是不允许的，因为元数据没有版本化。如果与快照隔离混合，对元数据的并发更新可能会导致不一致。

但是，Microsoft 并未将 TRUNCATE 列为 SNAPSHOT 隔离下不允许的 DDL 语句：http: //msdn.microsoft.com/en-us/library/bb933783.aspx

显然我没有正确理解某些东西，因为我本以为 Procedure2 的最佳情况会在 TRUNCATE 之前立即从表中返回最近提交的数据，或者最坏的情况是被 Procedure1 阻止，然后返回新的内容桌子。你能帮我吗？

我继承了一个带有 80 GB 日志的 10 GB 数据库[根据 DBCC SQLPERF(logspace)，只有 3% 正在使用]。可以假设极端的日志增长是由于我被录用很久之前的问题造成的。

主服务器有一个日志传送备份作业，每 15 分钟运行一次。主服务器具有每 15 分钟运行一次的复制和恢复作业。

当我尝试收缩日志时，我得到“无法收缩日志文件 2 (DatabaseName_log)，因为位于文件末尾的逻辑日志文件正在使用中。” 我已经重试了几次，间隔 15 分钟甚至几天，但总是得到相同的结果。

DBCC LOGINFO 显示 784 个 VLF，只有前 245 个，最后一个打开，状态为 2。 p_WhoIsActive 显示最长的打开事务已运行不到 2 小时（由于第三方 Microsoft，这里长时间事务并不罕见访问有 ODBC 驱动程序问题的应用程序）。

如何成功缩小此日志（不会为用户造成中断）？

谢谢，马克

基于查询性能和多语句表值函数等文章，SQL Server 假设多行表值函数返回一行。如果调用语句实际上返回许多行，这会导致为调用语句选择一个糟糕的执行计划。

添加SCHEMABINDING到函数是否会导致函数返回值集的基数估计更正确？

如果我们假设我们将一个UserId传递给这个函数并返回一个允许用户访问的RecordId值表，并且一些用户只被允许看到一些记录，而一些用户被允许看到很多甚至所有记录，函数或调用语句（或包含它们的过程）是否会从使用中受益RECOMPILE？函数中的使用会SCHEMABINDING改变这个答案吗？

我意识到我可以通过实验来解决这个问题，但我希望有人已经找到了答案。指向有据可查的地方的指针会很有帮助。