标签: sql-server-2017

我很快将迁移到 SQL Server 2017，因此我正在努力美化我们数据库中一些被忽视的方面。一方面是文件组：我的 DBA 前任创建了多个文件组，但是没有人真正被告知大多数对象只是转到默认文件组 (PRIMARY)。

现在我想强制人们创建表和索引实际上命名他们的对象应该驻留的文件组。含义：没有“ON [Filegroup]”的 CREATE TABLE 或 CREATE INDEX 应该回滚，并显示文件组丢失的错误。有什么方法可以做到这一点，您会建议继续采用这种方法吗？我刚刚发现基于策略的管理无法阻止在默认文件组上创建对象。

这样做的要点是，someboy 应该首先为对象选择文件组，而不是在默认文件组中创建它们，然后必须根据 DBA 的咆哮移动对象:-)。

我想过两种技术......但是由于缺少知识而无法开始使用它们中的任何一种：

• 使用数据库触发器检查是否有 on 子句，如果没有回滚 --> 这似乎很脆弱，因为它取决于命令文本的文本分析
• 使主文件组的大小非常小（100KB？），以便系统表仍然能够适应，但其他中等大小的表会导致错误，因为没有足够的空间-> 可能是一个坏主意，因为这可能对数据库可用性产生严重的副作用，并且在阻止在默认文件组中创建每个用户定义的表或索引方面不够精确

非常感谢您的帮助

马丁

随着 SQL Server 2017 附带的 Python 功能的引入，我想知道是否有人能够使用 SSMS v17.x 并运行需要用户输入的 Python 脚本。这是一个示例基本脚本：

execute sp_execute_external_script  @language = N'Python', 
@script =N' print ("This is a PYTHON test")
userinput = int(input ("Enter LBs to convert to KG")) 
converted = userinput * 0.453592     
print (converted) '

该脚本在 SSMS 中无休止地运行，而如果它只是一个打印语句；成功完成并产生打印结果。

我知道我可以使用像 Pycharm 这样的 Python IDE 控制台，但我想知道 SSMS 是否有这样的功能。我在互联网上的研究并没有那么富有成效。Python的大部分使用都与建模和分析有关。

我在 SQL 2017 上启用了查询存储，并且我在查询中看到频繁发生SELECT *在特定表上的查询。

我想缩小此请求的来源范围，看看我们是否可以找到比执行SELECT *.

当然，我有一个来自 Query Store 的查询 ID。我最近还要求我的开发人员在他们的连接字符串中包含应用程序名称，很多人都这样做了。

有没有办法（例如，可能使用 DMV）找出与此查询关联的应用程序名称？

我有一个包含约 100 个数据库的环境，所有数据库都具有相同的架构。每个数据库上都有一个存储过程，它创建一个#temp 表并删除它，并且运行非常频繁（每个用户每 30 秒左右，并且有 1000 多个用户）。它的作用远不止于此：我们正在将潜在的数千行加载到这个临时表中，然后将整个内容转储出来，基本上它聚合了一堆数据。

由于所有数据库都创建相同的临时表，它们是否都相互竞争？还是每个数据库都在 tempdb 中获得了自己的临时表版本？

似乎他们有争用，因为我看到大量PAGE_LATCH等待，都在 tempdb ( 2:3:1041580)的同一页面上，这不是 GAM、SGAM 或 PFS 页面，并且 90% 的等待似乎来自同一个页面跨所有数据库的存储过程。这些等待占服务器总等待的 90%，并导致阻塞。

我做了一个DBCC PAGE，它似乎是sysobjvalues（来自标题中的 object_ID 60）。我跑了：

SELECT OBJECT_Name(object_ID), * 
FROM sys.dm_db_database_page_allocations(2,60,NULL,NULL,'DETAILED')

我得到 153 行，不确定我在这里看到的是什么。看起来像它IN_ROW_DATA和LOB_DATA在allocation_unit_type_desc。

我在与其他文件不同的卷上有 8 个 tempdb 文件。我有 16 个内核，但我的理解是，由于它不是分配页面，因此可能无助于增加文件数量。使用 SQL Server 2017 企业版。

我觉得最好的办法是告诉开发人员在这里删除临时表，但这需要重新处理逻辑并且需要一些时间。在等待开发修复时，我还能做些什么来避免这些页面闩锁？

考虑以下：

CREATE DATABASE [Foo]
ALTER DATABASE [Foo] ADD FILEGROUP XTP CONTAINS MEMORY_OPTIMIZED_DATA
ALTER DATABASE [Foo] ADD FILE (NAME=XTP,FILENAME='C:\Program Files\Microsoft SQL Server\MSSQL14.MSSQLSERVER\MSSQL\DATA\Bar_XTP') TO FILEGROUP XTP 
GO
USE [Foo]
CREATE TABLE dbo.A(
    ID INT NOT NULL CONSTRAINT PK_A_ID PRIMARY KEY NONCLUSTERED, 
    [Start] DATETIME2 GENERATED ALWAYS AS ROW START,
    [End] DATETIME2 GENERATED ALWAYS AS ROW END,
    PERIOD FOR SYSTEM_TIME([Start], [End]),
    INDEX IX_A_CCS CLUSTERED COLUMNSTORE
) WITH (
    MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_AND_DATA,  
    SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.A_History)
)

这个奇妙的装置结合了 SQL Server …

我有一个由 2 个 SQLServer 2016 实例（WSFC 中的 2 个 Windows 2016 服务器）组成的旧可用性组 我还有 2 个新的 SQLServer 2017 实例（2 个 Windows Server 2016），我最初想加入 2016 AG。

这是一个 0 停机迁移场景，一旦数据库与 2017 年的数据库对齐，2016 年的服务器应该被解雇。

令我非常失望的是，我发现无法将 2017 实例加入现有的 2016 AG，但我无法承担停止生产、获取和恢复备份、等待数据库同步、更改名称（以及可能的新 AG 的 ip) 与原始 AG 匹配，除非作为最后一个资源......

然后我遇到了名为“Distributed AG Group”的 2016 年新服务，我开始考虑将它用于我的迁移场景......基本上是这样的：

1. 使用 SQL 2017 实例创建一个新的 AG
2. 在原来的2016 AG和新的2017 AG之间创建一个分布式AG（应用继续连接2016的监听器）
3. 等待 DB 同步在 2017 AG 中发生
4. 以 2017 AG 为主
5. 从分布式 AG 中删除 2016 AG（应用程序停机时间短）
6. 更改 2017 监听器的名称和 ip（应用程序再次启动）
7. 移除分布式AG

是否可行？我可以在分布式 AG 中混合 2016 和 2017 …

Table_1
Name   |   Activity  | LogTime
A      |    0        | 2018-12-17 10:16:04.877 
A      |    1        | 2018-12-15 10:16:04.877
A      |    0        | 2018-12-16 10:16:04.877
A      |    0        | 2018-12-10 10:16:04.877
A      |    0        | 2018-12-10 10:10:04.877
B      |    1        | 2018-12-16 10:16:04.877
B      |    0        | 2018-12-17 10:16:04.877
C      |    1        | 2018-12-14 10:16:04.877
C      |    1        | 2018-12-12 10:16:04.877
C      |    1        | 2018-12-18 10:16:04.877

想要的结果

Name |   TOTALActivity_0  | TOTALActivity_1  |  LatestActivity_0_Logtime  | LatestActivity_1_Logtime
A    |      4             | …

我试图了解强制使用全扫描更新统计信息对执行计划估计的影响。

我目前在一个非常简单的 SELECT 查询的执行计划中有以下结果：

如您所见，它相差 5 行。

然后我运行：

UPDATE STATISTICS  Person.Address WITH FULLSCAN
UPDATE STATISTICS  Person.Address [PK_Address_AddressID] WITH FULLSCAN
GO
EXEC sp_recompile 'Person.Address';
GO
SELECT * FROM Person.Address OPTION(RECOMPILE)

但是，它仍然相差 5 行。为什么？

我知道除非有性能问题，否则我不应该担心。但是，我试图了解完整统计信息更新的实际效果

最近，在我们进行统计更新时，我们的阻止进程仪表板一直在报告被阻止的进程。

很快就找到了原因：更新统计作业步骤 (T-SQL) 在辅助 SQL Server 实例和主 SQL Server 实例上都启动。该作业更新同一数据库的多个统计信息，该数据库是 AlwaysOn 可用性组的一部分。我希望这会在辅助实例上失败。

故障转移历史的简要概述：

由于许可而应保持活动状态的服务器 A（将被命名为活动服务器），在 20/02 晚上 9 点意外故障转移到服务器 B（被动服务器）。

在计划外故障转移之后，我们在 2002 年 2 月 21 日中午 12 点进行了另一次（但这次是计划内的）手动故障转移回 Active Server。

工作经历

在第一次故障转移之前一切都很好，活动服务器是唯一运行该作业的服务器。

一项工作正在运行。 我们看到在活动端运行的统计更新。（这是当时的主要副本）

在无源服务器作为主要副本的短时间内，我们没有任何监控并且作业历史记录被清除。

故障转移后，回到“正常”状态，在被动节点上处于主节点不到 24 小时后，被动实例上的作业步骤也已在主动实例上启动并运行。

（我杀死了会话）。

现在对我来说有趣的部分是，这两个作业都在活动服务器上运行，似乎该作业正在使用侦听器访问数据库。但这可能是一个完全不同的原因。

有一个复制作业 PowerShell 任务在每晚凌晨 01 点运行 (dbatools)：

powershell.exe Copy-DbaAgentJob -ExcludeJob "CopyJobs,CopyLogins" -Source INDCSPSQLA01  -Destination  INDCSPSQLP01     -Force

我的猜测现在是针对一次，作业复制发生在主动、次要节点 --> 带有 -Force 的主要被动节点。这发生在 21/02 01 AM。

问题

为什么被动实例上的作业步骤在主动实例的数据库上执行？

清单

在这两种情况下，作业目标都是本地的：

EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'

服务器名称正确

select …

在 SQL 2017 中，除了2017年添加的之外，还有一个新的执行指标“日志内存”我没有找到任何关于它的信息。

执行指标：（SQL 2017）

CPU 时间、持续时间、执行计数、逻辑读取、逻辑写入、内存消耗、物理读取、CLR 时间、并行度 (DOP)、行计数、日志内存、TempDB 内存和等待时间

我相信我了解所有其他指标是什么以及我为什么会关心。

我在几个特定时期运行了前 5 个资源消耗查询的所有指标。我记录了，现在我正在检查结果。我知道“日志内存”的（非常大）值以 KB 为单位。

指标“日志内存”究竟是什么？

编辑，收到两个答案我检查

LowlyDBA的回答表明它是来自 5 个相关领域的组合sys.query_store_runtime_stats

使用jadarnel27 在他们的回答中提供的代码来验证

我创建了数据库 '231682' 并运行了 5 个字段的测试查询，我得到的结果非常相似

我总结（用于=SUM()在Excel中）我的价值观，并得到1383040（字节）

我查看了查询存储，对于使用的日志内存 (KB)，它显示的值为 354,058,240 (KB)，这个数字要大几个数量级，与字节相比也是 KB，以字节为单位，它将是 354,058,240,000（字节）

我把所有字段的总数相加，只得到 1,655,236（字节）

SELECT *
FROM sys.query_store_runtime_stats qsrs
WHERE qsrs.avg_log_bytes_used > 0;

我怀疑我的问题的答案是 SQL 2017 中的“日志内存”指标没有任何实际价值。这个小实验中显示的值是 354GB，高得不切实际。