我有一个删除语句，它在存储过程中运行时使用了一个错误的计划，但在临时运行时选择了一个更好的计划。
我已经为查询使用的表重建了所有索引并删除了所有缓存。优化器仍然为存储过程选择了错误的计划。
我想知道为什么优化器对存储过程使用不同的执行计划而不是临时 SQL。
更新：我想它毕竟一定是参数 - 当我运行带有硬编码变量的临时代码时，我可以获得具有正确值的“坏”计划（它是一个日期，值是一岁似乎产生了“好”的计划）。现在尝试通过使用查询提示在 proc 上强制执行“好”计划。
解决方案：我最终通过使用 OPTIMIZE FOR UNKNOWN 提示获得了我想要的计划。
我们正在使用 SQLCLR 存储过程来激活服务代理，我想监视 CLR 代码使用的内存。查看sys.dm_os_memory_clerks，我看到只有 NUMA 节点 1 具有与该MEMORYCLERK_SQLCLR类型关联的任何页面。服务器有两个 8 核 CPU，运行 SQL 2014 CU6。
这是预期的吗？或者我应该像我一样看到两个节点上使用的内存MEMORYCLERK_SQLBUFFERPOOL？
询问：
SELECT DOMC.memory_node_id
, DOMC.pages_kb
, DOMC.virtual_memory_reserved_kb
, DOMC.virtual_memory_committed_kb
FROM sys.dm_os_memory_clerks DOMC where type = 'MEMORYCLERK_SQLCLR'
结果：
memory_node_id pages_kb virtual_memory_reserved_kb virtual_memory_committed_kb
-------------- -------------------- -------------------------- ---------------------------
0 88232 12607744 1408652
1 0 0 0
64 0 0 0
我在上周有两个实例，其中DROP扩展事件会话的命令花费了一天的时间来完成，等待：PREEMPTIVE_XE_CALLBACKEXECUTE。
谁能解释一下这种等待类型是什么意思？
更多背景信息：
首先，我运行了一个 T-SQL 命令来删除会话，一天后它完成了。使用 时sp_whoisactive，我看到查询正在等待PREEMPTIVE_XE_CALLBACKEXECUTE。
在此期间，对象资源管理器收集元数据的查询被阻止并收到锁定超时，但没有其他抱怨（或者我当时认为）。
我试图在星期五放弃另一个会话，并且发生了相同的行为，只是它不像第一次事件那样在一天后消失。相反，我今天早上发现客户端应用程序无法连接。它被DROP EVENT SESSION查询阻止了。
重新启动 SQL 服务清除了阻塞查询。
我找不到任何有助于诊断这是什么等待类型的东西……以及为什么我的事件会话不会像它们应该的那样下降。你能帮我吗？
服务器信息： SQL 2008 R2 Enterprise with SP2
我正在从 CLR 存储过程调用 T-SQL 存储过程。并且THROWT-SQL 中的语句在不进入catch块的情况下停止 CLR 的执行。是否可以在我的代码中更改某些内容以导致 CLR 过程执行该catch块？
T-SQL：
CREATE TABLE t1 (ID INT PRIMARY KEY clustered);
CREATE TABLE t2 (ID INT CONSTRAINT fk_1 FOREIGN KEY REFERENCES t1(ID))
GO
CREATE PROC dbo.TestThrow
AS
BEGIN
BEGIN TRY
INSERT INTO t2 VALUES (1)
END TRY
BEGIN CATCH
THROW
END CATCH
END
GO
克莱尔：
public static void TestThrow()
{
String query = "EXEC DBO.TESTTHROW";
using (SqlConnection connection = new SqlConnection("context connection=true"))
{
connection.Open();
try
{ …最近，我更改了 SQL Server 2008 R2 服务器上某些数据库的 Autogrow 设置。这些都涉及数据库镜像配置，主体在SERVER1 上，镜像在SERVER2 上。
本周我失败了三个数据库 - 现在SERVER1是镜像，而SERVER2是这些数据库的主体。似乎自动增长设置没有正确转移到SERVER2，因为数据库现在显示它们增长了一个百分比（两个设置为 32768%，另一个设置为 131072%）。
这与过去的设置不同（我相信这是默认值 - 10%），也与我在SERVER1 上设置的 256MB 不同。
更令人困惑的是，这仅发生在主文件上 - 辅助文件和日志文件保留了我在SERVER1上设置的设置。
我怀疑这是一个错误 - 我在更改自动增长设置后修补了 SQL。我的问题是 - 有没有人见过这种情况？有没有一种方法可以确保两台服务器上的所有设置都正确，而不会使所有数据库都失败？
更新：使用我称为DB1的第 4 个数据库，我将SERVER1上的自动增长设置为 512MB（在数据库故障、目睹相同问题并将其故障恢复后）。之后我将其故障转移到SERVER2 时，它显示了 65536% 的增长。要点是is_autogrow_percentin的值sys.master_files不会移动到SERVER2，但growth值是。
UPDATE2：在SERVER1上使用DB1时，我将自动增长更改为 10% 并将其失败为SERVER2。10% 的价值仍然存在。然后我重复了这一点，这次将 autogrow 设置回 256MB。同样，值改变了，但没有。 …
我有一个 CLR 存储过程（除其他外）调用 TSQL 存储过程。TSQL 存储过程运行一些动态 SQL，并在运行前打印 SQL 以进行调试。PRINT语句中没有任何内容显示在客户端中。当我们需要排除故障时，有什么好方法可以让我们看到这些命令？
示例代码：
dll中的C#代码
public static void Print_CLR()
{
using (SqlConnection conn = new SqlConnection("context connection=true"))
{
conn.Open();
using (SqlCommand c = new SqlCommand("exec dbo.Print_TSQL", conn))
{
c.ExecuteNonQuery();
}
}
}
CLR 调用的 Proc
public static void Print_CLR()
{
using (SqlConnection conn = new SqlConnection("context connection=true"))
{
conn.Open();
using (SqlCommand c = new SqlCommand("exec dbo.Print_TSQL", conn))
{
c.ExecuteNonQuery();
}
}
}