标签: sql-server-2017

在for T-SQL的文档中CREATE SEQUENCE，可以看到该CREATE SEQUENCE命令没有ORDER参数。

为了进行比较，Oracle 文档CREATE SEQUENCE显示了ORDER/NOORDER选项：

ORDER

指定ORDER以保证按请求顺序生成序列号。如果您将序列号用作时间戳，则此子句很有用。对于用于生成主键的序列，保证顺序通常并不重要。

ORDER如果您将 Oracle 数据库与 Real Application Clusters 一起使用，则仅需要保证有序生成。如果使用独占模式，则始终按顺序生成序列号。

NOORDER

指定NOORDER是否不想保证按请求顺序生成序列号。这是默认设置。

Microsoft SQL Server 是否为SEQUENCEs提供了强排序约束？或者微软一般不认为它很重要？

我正在运行带有 SQL Server 实例的云 VPS。因为它是供个人使用的，所以我使用的是 express 版（我不能使用开发者版，因为我在技术上运行了生产应用程序，而且我买不起 Standard+）。

我正在尝试使用Brent Ozar 的教程使用sp_BlitzFirst. 我遇到的问题是，无论当时的实际 CPU 使用情况如何，ProcessUtilizationinsys.dm_os_ring_buffers总是100以 形式出现。

虚拟机信息

@@version： Microsoft SQL Server 2017 (RTM-CU15) (KB4498951) - 14.0.3162.1 (X64) May 15 2019 19:14:30 版权所有 (C) 2017 Microsoft Corporation Express Edition（64 位）Linux (Ubuntu 18.04) .2 LTS)

主机： 1 & 1 Ionos VPS

lscpu 输出

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per …

Run Code Online (Sandbox Code Playgroud)

我正在做一些字符串聚合，并注意到对我来说看起来像一个错误。STRING_AGG在具有不同分隔符参数的同一查询中使用了两次。但是，两者都产生了相同的结果（在两种情况下都使用“第一个”分隔符）。它似乎只在某些情况下发生。这是错误还是记录在案的行为？

首先，设置：

CREATE TABLE #Data
  ([Group] INT
 , Member  CHAR(1));

INSERT INTO #Data
VALUES (1, 'a'), (1, 'b')
     , (2, 'c'), (2, 'd');

从表与VALUES构造函数。没有WITHIN GROUP ORDER BY，一切都很好。有了它，bug就出现了

SELECT Commas = STRING_AGG(Member, ', ') --WITHIN GROUP(ORDER BY Member)
     , Colons = STRING_AGG(Member, '::') --WITHIN GROUP(ORDER BY Member)
FROM #Data;

SELECT Commas = STRING_AGG(Member, ', ') --WITHIN GROUP(ORDER BY Member)
     , Colons = STRING_AGG(Member, '::') --WITHIN GROUP(ORDER BY Member)
FROM (VALUES (1, 'a'), (1, …

我有一个繁忙的数据库，它已经繁忙多年，并且我看到事务日志大小每天约为几 GB。

在过去几周内，事务日志大小已增加到每 6 小时 40-50 GB。这对我的备份产生了很大的影响，并且磁盘的大小也令人担忧。

我每隔一天进行一次完整备份，每 6 小时进行一次日志备份。

日志备份按预期减少了事务日志使用量的大小，但它又开始迅速增加。

如何发现导致交易量相对突然增加的原因？

• 我的开发人员正在对可能影响过去几周的变化进行空白
• 没有长时间运行的进程
• 没有计划的作业来执行索引操作
• Redgate 监控未显示任何过度写入

我该如何进一步调查？

我从查询存储开始，它有问题:-( 没有生成 Top Resource Consuming Queries 的报告。它只是一直说“等待”几个小时和几个小时。后台查询（请参见下面的示例）不是能够完成并消耗大量 CPU。无论我如何更改配置选项，它一直在等待和等待（甚至最后一小时报告）。这是查询存储的现实吗？听起来是一个很棒的工具，但完全是实际无法使用？

我的查询存储大小约为 1.7 GB。我正在以 1 小时的间隔和自动捕获模式收集 7 天的数据 - 所以对我来说这似乎是合理的设置。

这是一个从未完成的后台查询示例：

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 sys.query_store_query q ON q.query_id = p.query_id
    JOIN sys.query_store_query_text qt ON q.query_text_id = qt.query_text_id
WHERE NOT (rs.first_execution_time > @interval_end_time OR rs.last_execution_time < @interval_start_time)
GROUP BY p.query_id, qt.query_sql_text, q.object_id
HAVING COUNT(distinct p.plan_id) >= 1 …

我有一个 1 TB 的数字串。给定一个 12 个字符的数字序列，我想获取该序列在原始字符串（charindex函数）中的起始位置。

我已经使用 SQL Server 使用 1GB 字符串和 9 位子字符串对此进行了测试，并将字符串存储为varchar(max). Charindex需要 10 秒。将 1GB 字符串分解为 900 字节重叠块并创建一个表（StartPositionOfChunk、Chunkofstring），其中包含二进制排序规则的 chunkofstring，索引时间不到 1 秒。10GB,10 位子字符串的后一种方法将 charindex 提高到 1.5 分钟。我想找到一种更快的存储方法。

例子

数字串：0123456789 - 要搜索的子字符串 345
charindex('345','0123456789') 给出 4

方法 1：我现在可以将其存储在包含一列的 SQL Server 表 strtable 中colstr并执行：

select charindex('345',colstr) from strtable

方法2：或者我可以通过拆分原始字符串来组成一个表strtable2（pos，colstr1）：1;012 | 2;123 | 3;234 aso然后我们可以进行查询

select pos from strtable2 where colstr1='345'

方法 3：我可以通过将原始字符串拆分成更大的块来组成一个表strtable2 (pos2,colstr2) …

我们一直在监控一些SQLServer: Memory Manager指标，并注意到在DBCC CheckDB工作后，指标

Database Cache Memory (KB)

大幅下降。准确地说，它从 140 GB 缓存数据库内存下降到 60 GB。之后，在一周内再次缓慢上升。（“ Free Memory KB”的数量，紧随其后从 20 GB 增加到 100 GB CheckDB）

DBCC CheckDB 每周日运行，因此数据库缓存内存必须每周再次增加

What is the behavior of this ? Why CheckDB pushes database pages out of memory ?

第二个问题是为什么“ buffer cache hit ratio”DBCC CheckDB完成后没有变化？

平均为 99.99%，在DBCC CheckDB工作后它下降到 ~98.00%，并很快恢复到 99%，而我预计“ buffer cache hit ratio”会显着下降，因为数据库数据必须再次从存储读取到 RAM？

我在 Mac 上的 docker 中运行 SQL Server。我从 Windows 中获取了 SQL Server 备份，并在 mac SQL Server docker 实例中恢复了它。现在我想从 SQL Server docker 实例中进行备份并将其恢复回 Windows。当我尝试在 Windows 上恢复时，我收到“系统表 sysfiles1 已损坏”。是否可以从 SQL Server Linux 进行备份并在 SQL Server Windows 上恢复它？

我们的客户安装 CU25 后，存储过程 sp_pkeys 出现问题。如果主键有多个列，它现在可能会返回错误的顺序。

可以在代码本身中找到它。这是 2017 款 CU25 变体：

create procedure sys.sp_pkeys
(
    @table_name      sysname,
    @table_owner     sysname = null,
    @table_qualifier sysname = null
)
as
    declare @table_id           int
    -- quotename() returns up to 258 chars
    declare @full_table_name    nvarchar(517) -- 258 + 1 + 258
    
    if @table_qualifier is not null
    begin
        if db_name() <> @table_qualifier
        begin   -- If qualifier doesn't match current database
            raiserror (15250, -1,-1)
            return
        end
    end
    
    if @table_owner is null
    begin   -- If unqualified table name
        select …

我正在 SQL Server 2017 中运行扩展事件会话，该会话仅记录module_end特定数据库的事件。出现此痕迹的原因有两个：

1. 我想查看调用存储过程的频率（或缺乏频率）。
2. 我试图获取每个过程调用的一些细节（例如谁调用它、从哪里调用、花费了多长时间、返回了多少记录等）。

在查看一些结果时，我注意到列表中的一些过程执行了数千万次，但从来没有一次大于row_count0。还有很多其他记录的事件row_count似乎填充正确，因此我最初认为那些从未返回结果的应用程序被引用它们的应用程序错误调用了。然而，事实并非如此。

为了更好地查看调用过程所使用的参数，我启动了一个 Profiler 会话，仅监视这些过程调用。我正在检查的特定过程被非常频繁地调用，并且我很快就收到了大量示例调用，并关闭了探查器。从中注意到以下几点：

1. 这些调用具有合法的参数。
2. 在未对扩展事件会话进行任何更改的情况下，在探查器处于活动状态期间记录的过程调用神奇地开始row_count正确记录1为而不是0。

以下是我正在使用的扩展事件的定义：

Create Event Session [Test Event] On Server
    Add Event sqlserver.module_end
    (
        Action (sqlserver.database_name, sqlserver.session_id)
        Where
        (
            sqlserver.database_name = N'TestDatabase' 
        And object_type = 'P'
        )
    )
    Add Target package0.ring_buffer (Set max_events_limit = 10000, max_memory = 51200)
    With
    (
        Max_Memory = 4096KB,
        Event_Retention_Mode = Allow_Single_Event_Loss,
        Max_Dispatch_Latency = 30 Seconds,
        Max_Event_Size = 0KB,
        Memory_Partition_Mode = None, …