标签: sql-server-2019

SQL Server 2019 引入了一个新的（且未记录的）系统存储过程：

sys.xp_delete_files

这个新的扩展存储过程究竟有什么作用？它与xp_delete_file已经存在多年的有什么不同？它代替xp_delete_file吗？

我正在针对 SQL Server 2019 CU14 进行测试。我有一个纯行模式查询，它从复杂的视图中选择前 50 行。完整查询在 MAXDOP 1 时需要 25426 毫秒的 CPU 时间，在 MAXDOP 2 时需要 19068 毫秒的 CPU 时间。并行查询总体上使用较少的 CPU 时间并不令我感到惊讶。并行查询适用于位图运算符，并且查询计划在一些方面有所不同。然而，令我惊讶的是前 N 个排序的操作员时间的巨大差异。

在串行计划中，根据运算符执行统计数据，前 N 个排序占用了大约 10 秒的 CPU 时间：

MAXDOP 2 计划报告相同的前 N ​​排序大约需要 1.6 秒的 CPU 时间：

我不明白为什么两个不同的查询计划之间会报告如此大的差异。父运算符中的计算标量非常简单，无法解释运算符时间的差异。它们是这样的：

[Expr1055] = Scalar Operator(CASE WHEN COLUMN_1 IS NULL THEN (0) ELSE datediff(day,COLUMN_1,getdate()) END),
[Expr1074] = Scalar Operator(CASE WHEN [Expr1074] IS NULL THEN (0) ELSE [Expr1074] END)

计划的不同部分还有其他计算标量。我上传了匿名的实际计划如果有人想查看的话，

当我将不带 TOP 的完整查询结果加载到临时表中并对临时表执行 TOP 50 排序时，并行计划和串行计划都需要大约 1200 毫秒的 …

我正在研究SQL Server 2019。

我有一个表dbo.AllDates其中包含从1990到2050的所有日期。我有另一个表dbo.ActualExchangeRates，其中我有在给定来源中找到汇率的日期某些货币的实际汇率。

我正在尝试编写一个查询来获取2010 年至2020 年之间所有日期的所有货币。如果找到比率，则写入比率，否则写入NULL。

鉴于这种情况和下面给出的代码，有人可以帮助我理解为什么SELECT查询没有生成任何结果，甚至无法看到估计的执行计划吗？

CREATE TABLE dbo.AllDates(Date date)
CREATE TABLE dbo.ActualExchangeRates(Date date, Currency char(3), Rate real)

--Query 1: Not generating any results or estimated plan
SELECT      d.Date, m.Currency, c.Rate
FROM        dbo.AllDates d
INNER JOIN  (
    select
      currency,
      '20100101' as mindate,
      '20201231' as maxdate
    from dbo.ActualExchangeRates
    group by currency
) as m on d.date between m.mindate and m.maxdate
LEFT …

SQL Server 2019 引入了标量 UDF 内联，又名“Froid”。这“.. 在调用 SQL 查询中嵌入 [标量 UDF]。”

以前，标量 UDF 在它们自己的执行上下文下运行，与周围的查询分开。这样做的一个后果是，在读取提交的快照隔离 (RCSI) 下，该函数可能会看到一组与包含查询所看到的值不同的值集 ( link )。

包含标量函数的查询是否有可能在 RCSI 中以并发写入运行时，会根据函数是否内联而产生不同的结果？

我已将 SQL Server 2012 数据库（大小为 8GB）移至具有相同内存和 CPU 配置的新设置的 SQL Server 2019 虚拟机，并将兼容级别更改为 SQL Server 2019。

我的应用程序中的所有内容都运行良好，除了一个存储过程，它包含一个带有两个参数的大 SQL 查询（并且没有花哨的选项）。当这个 SP 执行时，它让 SQL Server 进程的内存上升到指定的最大级别，然后返回错误：

“内存不足，无法运行此查询”

当我在 SSMS 的单独查询窗口中执行 SQL 查询（在存储过程中）时，它会立即执行并返回预期的 300 行。此外，当我将数据库的兼容性级别更改为“SQL Server 2017”并执行存储过程时，一切正常。

我首先认为这可能是参数嗅探问题，但没有一种解决方法有帮助（例如OPTION (RECOMPILE)）。

我已经将问题深入到标量值函数的调用中。每次调用这个函数，都会出现内存错误。

这是该函数的 DDL（抱歉，部分是德语）：

CREATE FUNCTION [dbo].[GetWtmTime] (
    @WorkTimeModelID uniqueidentifier,
    @Date DATETIME,
    @SequenceNo TINYINT)
  RETURNS VARCHAR(5)
AS
BEGIN
    -- SET DATEFIRST 7; has to be executed before calling this function
    DECLARE @WtmTime VARCHAR(5)
    DECLARE @WtmWeeks INT
    DECLARE @WtmTakeHolidays BIT
    DECLARE @WtmMaxMemberCount TINYINT
    SELECT @WtmWeeks …

SQL Server 2019 已发布，但我似乎没有可供下载的 LocalDB 版本。有谁知道是否会发布 LocalDB 版本，或者 2017 年是否是最后一个版本？

SQL Server 2019。这是 xml 计划要点的链接。

您好，我花了很长时间才明白为什么当它找不到包含其中一种状态的记录时，为什么这个查询需要 0.02 秒才能执行。当它找到具有包含状态之一的记录时，它往往要快得多。我猜这是因为一旦找到匹配的 1 行，查询就会停止。

SELECT TOP 1 IDNum,
             FORMAT(Date, 'M/d/yy') AS theDate,
             Status,
             Rate
FROM   theDB
       INNER JOIN DomainTable
               ON theDB.IDNum = DomainTable.IDNum
WHERE  DomainIP = '127.0.0.1'
       AND status IN ( 'Active', 'To ReActivate', 'To Deactivate', 'Deactivate ASAP',
                       'SUSPENDED', 'SUSPENDED X', 'SUSPENDED Y', 'SUSPENDED Z' )
ORDER  BY theDB.IDNum DESC 

（DomainIP属于DomainTable，其他属于DB）

在执行计划中，最大的成本是 TOP N SORT，占 33% 聚集索引搜索占 29% 对 DomainTable 的键查找使用了 29% 在 DomainTable 上搜索 IP 的索引是 9%

我的问题是：

有没有办法让TOP N不那么重？

0.02 …

安装 CU2 后，我们的 SQL 服务器代理随机停止工作。如果您通过打开作业活动监视器来检查代理的状态，它会出现一段时间的空白，然后抛出错误：

无法检索此请求的数据。(Microsoft.SqlServer.Management.Sdk.Sfc)

如需帮助，请单击：https : //go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476

- - - - - - - - - - - - - - - 附加信息：

执行 Transact-SQL 语句或批处理时发生异常。(Microsoft.SqlServer.ConnectionInfo)

---

当前命令发生严重错误。结果，如果有的话，应该被丢弃。（Microsoft SQL Server，错误：0）

如需帮助，请单击：http : //go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=15.00.4013&EvtSrc=MSSQLServer&EvtID=0&LinkId=20476

任何线索可能导致这种情况？

我有一个带有触发器的视图instead of，我尝试将其与 EF Core 一起使用，EF Core 尝试以merge语句的形式将批量插入一起。这是我的表格和视图：

create table tbl (id uniqueidentifier not null primary key, data nvarchar(max) null)
go
create view vwTbl as select * from tbl
go
create trigger vwTblInsert on vwTbl instead of insert as
    insert into tbl (id, data)
    select id, data
    from inserted
go

以下是 EF 生成的近似 SQL：

declare @inserted1 table ([id] uniqueidentifier);
merge vwTbl using (
    values (newid(), 'xxx') 
) as i (id, data) on 1=0
when not matched then …

假设应用程序已与 SQL\xc2\xa0Server 建立了两个连接。

\n
1. 会话正在主动运行查询
\n
2. 会话正在休眠，等待下一条指令
\n

通过任务管理器终止此应用程序是否会终止两个 SQL 连接？