标签: sql-server-2017

我们有一个 SQL Server：

Microsoft SQL Server 2017 (RTM-CU14-GDR) (KB4494352) - 14.0.3103.1 (X64) 2019 年 3 月 22 日 22:33:11 Windows Server 2016 Datacenter 10.0 上的企业版（64 位）（内部版本 14393：）（虚拟机管理程序）

尝试安装“SQL Server 2017 累积更新包 18 - KB4527377” https://www.microsoft.com/en-us/download/details.aspx?id=56128

安装程序做了 15 分钟的事情，安装和更新文件，停止/启动服务，看起来会成功，但最后它显示：

需要采取的行动：

使用以下信息解决错误，然后再次尝试安装过程。

功能失败原因：

该功能的设置过程中发生错误。

错误详情：

安装 SQL Server 数据库引擎服务实例功能时出错
注册表中的用户日志目录无效。
验证实例配置单元下的 DefaultLog 键是否指向有效目录。
错误代码：0x851A0044 访问https://go.microsoft.com/fwlink?LinkId=20476&ProdName=Microsoft+SQL+Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=14.0.3257.3&EvtType=0xD8FB5EBA%400x97A656BB%401306%4068&E vtType=0xD8FB5EBA%400x97A656BB% 401306%4068获取故障排除帮助。

是什么阻止了 CU18 安装？

对于几个场景，我们很少看到在存储过程上执行 sp_recompile 以提高性能。

作为一名 DBA，我了解执行 sp_recompile 时涉及的一些注意事项以及为什么它可以提高性能。

我们的管理层一直在争论，当他们看到上述性能问题时，为应用程序/开发 DBA 提供执行 sp 重新编译的访问权限。只是为了减少 DBA 的参与，APP 开发人员可以在性能问题期间继续运行

我很犹豫，因为我认为它会带来一些不需要的行为，有时甚至会恶化其他 proc 的性能。

我正在寻求专家的一般指导和经验，为什么这在可能的不同情况下或在理想情况下可能是个坏主意。您的输入可能会帮助我设计，并可能以不同的方式解释该方法。

仅供参考 - 在看到参数嗅探等问题时，上述问题不仅被认为是一个应用程序，而且被认为是其他少数应用程序的自动化。

我有几个表的索引高度碎片化（超过 90% 碎片化）并且大小足够大（数十 GB）
对这些表进行碎片整理的目标是减少上述表的空间消耗

我想避免执行 REBUILD 操作，因为它太资源密集
还试图避免记录到事务日志和日志增长，以及大事务日志备份大小作为结果

这就是为什么选择 REORGANIZE 操作而不是 REBUILD 来处理高碎片化
关于 REORGANIZE，有以下问题：

1. 如果同时在单独的索引上运行多个 REORGANIZE 操作（比如 10+，在单独的 SSMS 窗口/会话中） - 是否会导致数据损坏或任何其他已知问题？

2. REORGANIZE 操作是否以任何方式/根本没有记录到事务日志中？

3. REORGANIZE 持有什么样的锁？哪些查询会受到影响？

我正在运行查询存储以使数据库性能更好。到目前为止，它一直工作正常。当我尝试加载最后一天的热门持续时间时，我花了 26 分钟来加载屏幕。

我运行的 SQL 版本是： Microsoft SQL Server 2017 (RTM-CU27) (KB5006944) - 14.0.3421.10 (X64) Oct 14 2021 00:47:52 版权所有 (C) 2017 Microsoft Corporation Standard Edition (64-bit) o​​n Windows Server 2019 Datacenter 10.0（内部版本 17763：）（虚拟机管理程序）

QS 中弹出查询：

/*
This query text was retrieved from showplan XML, and may be truncated.
*/

SELECT TOP (@results_row_count)
    p.query_id query_id,
    q.object_id object_id,
    ISNULL(OBJECT_NAME(q.object_id),'') object_name,
    qt.query_sql_text query_sql_text,
    ROUND(CONVERT(float, SUM(rs.avg_duration*rs.count_executions))*0.001,2) total_duration,
    SUM(rs.count_executions) count_executions,
    COUNT(distinct p.plan_id) num_plans
FROM sys.query_store_runtime_stats rs
    JOIN sys.query_store_plan p ON p.plan_id = rs.plan_id
    JOIN …

我们正在运行本地 SQL Server 2017 来支持数据仓库数据库。数据库按计划通过 SSIS 加载，主要是通过使用临时表和 MERGE 函数。最近，我们开始看到错误“资源池‘内部’中没有足够的系统内存来运行此查询。”。在过去的几周里，这种现象变得越来越猖獗。

我们已经尝试过：

1. 关闭查询存储
2. 通过 CU27 更新 SQL Server
3. 跟踪查询（没有好的结果）
4. 运行尽可能多的报告来查明问题

与错误发生时间相关的最新更改：

1. 打开查询存储
2. 添加大量索引

其他信息：

1. 我们服务器上有32GB内存，分配26GB给sql server
2. MERGE 的 TARGET 表是 CLUSTERED COLUMNSTORE INDEX
3. MERGE的SOURCE表是一个HEAP
4. 随着时间的推移/多次失败，暂存更改记录的 SOURCE 表已增长到超过 200,000 条记录。TARGET 表大约有 1000 万行。

任何帮助，将不胜感激。在过去的几天里，我在互联网上进行了搜索，以寻求任何指导。到目前为止我所看到的只是：

1. 更新 SQL 版本
2. 修改您的查询
3. 给服务器添加内存

合并语句：

 DROP TABLE IF EXISTS #Changes;
DROP TABLE IF EXISTS #TransformedChanges;

CREATE TABLE #Changes
(
    [Change Type] VARCHAR(100)
);
MERGE [dbo].[FactOrderLine] AS TARGET
USING ( SELECT
[FactOrderLine].[OrderLine_Key],
[FactOrderLine].[BookedDate_Date_Key],
[FactOrderLine].[BookedDate_Time_Key],
[FactOrderLine].[Account_Key],
[FactOrderLine].[CCN_Key],
[FactOrderLine].[BillTo_SalesOffice_Key],
[FactOrderLine].[BillTo_Territory_Key],
[FactOrderLine].[ShipTo_SalesOffice_Key], …

我有一个 SQL-Server 数据库，其中包含按 datetime2(2) 列分区的大型表。某些（旧）文件组标记为 READ_ONLY。

我定期使用 READ_WRITE_FILEGROUPS 选项进行备份。我可以成功地从读写分区恢复数据。

但是，我无法读取恢复的数据，出现以下错误：

表“dbo.myorders”的索引“pk_myorderid”的一个分区（分区 ID 72057594043105280）驻留在文件组（“YEAR2021”）上，该文件组因脱机、正在恢复或失效而无法访问。这可能会限制查询结果。

如果我将数据类型更改为 DATETIME 或 datetime2(7)，则不会发生错误（当然，如果我从恢复的范围请求数据）

除了这个问题之外，其他一切都工作正常。

我创建了一个测试脚本来说明问题。该脚本创建一个测试数据库、填充表、备份和恢复数据库。

如果在此脚本中将 datetime2(7) 更改为 datetime2(2) ，则恢复后数据将变得无法访问。

测试脚本：

USE MASTER

-- Reset environment
IF DB_ID('PartialDatabase') IS NOT NULL
BEGIN
    EXEC msdb.dbo.sp_delete_database_backuphistory @database_name = N'PartialDatabase'
    ALTER DATABASE PartialDatabase SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
    DROP DATABASE PartialDatabase
END
GO
IF DB_ID('PartialDatabase_Recovery') IS NOT NULL
BEGIN
    EXEC msdb.dbo.sp_delete_database_backuphistory @database_name = N'PartialDatabase_Recovery'
    ALTER DATABASE PartialDatabase_Recovery SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
    DROP DATABASE PartialDatabase_Recovery
END
GO


-- Create …

我们的应用程序使用 SQL Server 应用程序锁，并且在某些情况下我们需要查看给定的锁是否存在。为此，我们从 中检索和过滤信息sys.dm_tran_locks。

这是可行的，但即使是SELECT * FROM sys.dm_tran_locks我们系统中针对此 DMV 的最简单查询 ( ) 也需要超过 100 毫秒（CPU 和持续时间），有时可能会超过 500 毫秒。这是无论是否以超级管理员用户身份运行、是否从 SSMS 运行时的情况。

full 最多返回大约 10,000 行SELECT，并且我们在具有充足 CPU 和 RAM 以及快速磁盘子系统的 VM 上运行。这个查询似乎不应该花费这么长时间。

有人以前见过这个或者知道这里可能发生什么吗？如果有帮助的话，我很乐意提供更多信息。

批处理模式内存授予反馈是2017 查询处理器中一系列功能的一部分，其中包括：

• 批处理模式自适应连接
• 交错执行
• 批处理模式内存授予反馈

那么批处理模式内存授予反馈是如何工作的呢？

我们有一个在生产中使用 SQL-Server 2014 的正在运行的生产。它在多个数据中心运行复制和部分订阅者。我有一个要求在 Linux 上评估 SQL Server 2017，以便它可以为在 Linux 上运行的新应用程序提供服务。问题是它也应该是订阅者，而且微软似乎还没有在开发中进行复制。

有人已经以任何方式处理过这个复制问题吗？

Linux 上的 SQL Server 是否支持复制？

我打开了一个连接，也许你们中的一些人会投票支持它。

提前致谢

我正在寻找一个很好的资源来细分 SQL Server 2017 企业版和标准版之间的功能差异？我想确保没有陷阱，否则我会错过任何真正有益于标准的东西。

我已经阅读了 Microsoft 的许可指南，但是它没有涵盖任何其他显着的功能差异吗？

“高级自适应查询处理”、“企业数据管理”和“高级安全”等模糊描述的功能差异是什么？