没有运行 SQL 备份的维护计划或作业。

但sql日志显示数据库的i/o冻结，数据库的i/o已恢复，数据库已备份，备份数据库已成功处理x页。

在哪里可以找到已配置的备份？

我们正在解决性能问题，需要维护执行计划以进行故障排除。需要维护执行计划并确保计划缓存在升级到 2019 时不会被刷新。

升级期间计划缓存是否会被清除？有没有办法维护并确保执行计划不被清除？

我有下面的代码，我正在使用参数，但它仍然生成许多重复的 SQL 执行计划。请问出了什么问题以及如何修复？

    string cmdString = @"INSERT INTO tb_RA_GLID (glid_StoreNumber, 
                                          glid_StoreName, 
                                          glid_FirstBusinessDate, 
                                          glid_LastBusinessDate, 
                                          glid_DateCreated, 
                                          glid_TimeCreated, 
                                          glid_ExportVersion, 
                                          glid_GLMappingVersion, 
                                          glid_POSModelOrType, 
                                          glid_POSVersion) 
                                          VALUES (@StoreNumber    , @StoreName    , @FirstBusinessDate    , @LastBusinessDate    , @DateCreated     , @TimeCreated   , @ExportVersion    , @GLMappingVersion    , @POSModelOrType    , @POSVersion     );
                                                 "; //SELECT SCOPE_IDENTITY();";
    using (SqlConnection conn = new SqlConnection(connectionString))
    {
        conn.ConnectionString = connectionString;
        using (SqlCommand comm = new SqlCommand())
        {
            comm.Connection = conn;
            comm.CommandText = cmdString;
            comm.Parameters.AddWithValue("@StoreNumber", columns[1]);
            comm.Parameters.AddWithValue("@StoreName", columns[2]);
            comm.Parameters.AddWithValue("@FirstBusinessDate", DateTime.ParseExact(columns[3], "yyyyMMdd", CultureInfo.InvariantCulture));
            comm.Parameters.AddWithValue("@LastBusinessDate", DateTime.ParseExact(columns[4], "yyyyMMdd", CultureInfo.InvariantCulture));
            comm.Parameters.AddWithValue("@DateCreated", DateTime.ParseExact(columns[5], …

更新：

基本答案：我要求的东西不属于 AOAG 设计的一部分。

在我看来，这“不是一个好问题”。除非这冒犯了某人，否则我会将其保留在这里，以防万一有人有和我一样的坏主意。

请原谅我使用的术语，因为我不是 DBA。

我正在咨询一个很可能需要 700-900 个数据库的项目。该软件无法利用多个 SQL 实例，并且必须将所有数据库托管在同一 SQL 实例名称上。

客户的DBA解释了为什么在AlwaysOn可用性组上托管数百个以上的数据库可能是不合理的，并且微软官方文档虽然没有说明上限，但确实声明微软仅使用100个数据库进行测试。
AlwaysOn 故障转移群集不是一个选项，因为数据是共享的而不是复制的。

我的理解是，AOAG 可以作为 SQL 实例进行寻址，并且我无法在多个 AOAG 之间共享实例名称。

有人向我提到，也许可以做到这一点 - 添加一个额外的 AG 并将这些额外的数据库放在同一 SQL 实例名称下，但我无法通过搜索找到此选项的描述。

要么我使用错误的术语搜索相关信息，要么我假设 AG 与 SQL 实例是 1:1，甚至可能是 1:m，但每个实例都不是多个 AG。

更新

我（认为我）理解的术语：

• 主机：运行一个或多个 SQL Server 实例的服务器。
• 实例：在主机上运行的 SQL Server 进程的副本，可通过实例名称进行访问。
• 实例名称：实例的逻辑地址，由hostname\instance
• 数据库 - 实例中数据的容器。

没有 AOAG 的关系：

Host --1:n--> Instance --1:n--> database

我迷路的地方：

（如果我这里说错了，请纠正我）

• AG - 一组 SQL Server 实例以及用于管理跨多个主机复制的托管数据的逻辑寻址的附加服务，这些实例可以在单个逻辑实例名称下进行寻址。

关系？与 AOAG 一起：

AO Cluster (logical name AO\All)
  +-- AG …

我正在 Stackoverflow 数据库上进行测试，以找出 SQL Server 不建议在执行计划中使用索引的可能情况，但是如果我们引入索引，它将有很大帮助！

对于 Group by、Order by Clause 和聚合函数（计数函数 - 表的最小副本）来说，这很容易吗？我编写了一个随机查询，其中我知道引入支持性索引肯定会有所帮助，但是缺少索引建议将仅在连接条件上而不是在 order by 子句上。

查询如下：

select top 100 Location from Users U join Badges B
on B.UserId = U.Id
order by Location desc

引入以下索引来提高性能：

create index Location on Users(Location)
go
create index UsersId on Badges(UserId)
go

优化器按照上述查询的预期使用索引：

逻辑读取和时间统计如下：

现在，我想测试仅在位置列上的用户表上建立索引并且在徽章（UserId）表上没有索引的情况下的性能，这里性能变得很糟糕（需要大约 7 分钟）：

逻辑读取和时间统计如下：

用户表上的索引被大量使用，从执行计划和逻辑读取可以明显看出，但是执行聚集索引扫描和表假脱机（惰性假脱机）会导致大部分问题。

以上所有测试均在 SQL Server 2019 上以 SQL Server 2016 兼容模式（130）进行。

如果有人可以就根本问题提供建议，将会有很大帮助。

这里还要注意一点，当这两个表中的任何一个上都没有非聚集支持索引时，相同的查询会在 9 秒内完成。下面是执行计划：

逻辑读取和时间统计：

出于测试目的，我将兼容性级别更改为 2019(150)，令我惊讶的是 - 之前的相同查询仅在用户（位置）表上有索引，而不在徽章表上有索引，在 2 秒内完成，而在 SQL Server 2016 中需要 …

ASYNC_NETWORK_IO 等待类型主要是由于客户端应用程序无法足够快地处理从 SQL Server 到达的数据而引起的。

当查询执行时，当结果开始可供使用时，客户端应用程序开始使用结果。假设结果由 4 个线程保存，那么，在结果完全被客户端应用程序消耗之前，保存数据的线程是否保持锁定状态？

sys.dm_exec_requests - 这些是活动请求

sys.dm_exec_sessions - 这些是活动会话

一个会话可以有 1 个或多个请求。

从检测和解决阻塞的角度出发，我正在探索上述dmvs。我观察到 sys.dm_exe_sessions 中存在的 session_id 在 sys.dm_exec_requests 中不存在。

例如 - 在 sys.db_exec_requests 中，有一条记录，等待类型为LCK_M_X，等待资源为KEY: 2......。相应的阻塞会话 ID 未显示在 sys.dm_exec_requests 中。

它在 sys.dm_exec_sessions 中显示，状态为sleeping。这种情况意味着什么 - 即 - 由于休眠会话而导致请求被阻止？

我一直在挠头，重新阅读MSFT帮助，但我仍然无法理解sys.dm_db_index_operational_stats和sys.dm_db_index_physical_stats中的forwarded_fetch_count和forwarded_record_count之间的区别。让我用下面的例子来说明我理解观点的问题。

我运行了以下查询：

;with heaps as ( \nselect \n    DB_NAME(DB_ID()) dbname, object_name ( p.object_id ) objname, sum(row_count) row_count,\n    DB_ID() database_id, p.object_id objectid\nfrom \n    sys.dm_db_partition_stats p\n    join sys.objects o on o.object_id = p.object_id \nWHERE \n    index_id = 0 and o.is_ms_shipped = 0 --and row_count > 0\n    group by p.object_id ) \nselect \n    h.*, \n    forwarded_fetch_count\nfrom heaps h\n    cross apply sys.dm_db_index_operational_stats(database_id, objectid, 0, null) ps\n    WHERE forwarded_fetch_count > 0 ORDER BY forwarded_fetch_count DESC\xc2\xa8\n

和

SELECT …

我最近读完 《SQL Server 2008 中的计划缓存》 ，我感到很困惑。看起来，除了完全刷新计划缓存或明确要求重新编译存储过程之外，从 SQL Server 2008 开始，存储过程的重新编译都是在语句级别而不是存储过程级别完成的。

那么，除了显式刷新缓存或要求重新编译（例如WITH RECOMPILE）之外，什么可以在 SQL Server 2019 中重新编译完整的存储过程，而不仅仅是重新编译单个语句呢？

举一个我感到困惑的例子，请考虑以下过程。

CREATE PROCEDURE FOO AS
BEGIN
   SELECT * INTO #temp1 FROM table1
   INSERT BAR1 SELECT * FROM #temp1
   INSERT BAR2 SELECT * FROM #temp1
END

我可以想到很多可能导致SELECT * INTO #temp1 FROM table1重新编译的事情，但是如果没有下一行也重新编译，那么重新编译会很奇怪。这让我觉得 SQL Server 中一定有一些东西会导致整个存储过程重新编译。

昨天，我运行了一个大型临时查询，但没有保存。今天，我想再看一遍。我想我应该在计划缓存中寻找。令我惊讶的是，我可以找到较旧的查询和较新的查询，但找不到我运行的查询。为什么会这样？

我知道我应该打开查询存储，但我还没有这样做。