Hannah Vernon's questions

我不是 PostgreSQL 专家，但是最近在代码审查过程中遇到了一些 PostgreSQL 代码，它创建和删除临时表的方式与我们在 SQL Server 中执行的典型方式一致。例如，在 SQL Server 中我们会这样做：

DROP TABLE IF EXISTS #temp_data;
CREATE TABLE #temp_data
(
    i int NOT NULL
);

代码审查显示了以下代码：

BEGIN;
DROP TABLE IF EXISTS temp_data;
COMMIT;

BEGIN;
CREATE TEMP TABLE IF NOT EXISTS temp_data(
    i int NOT NULL
);
COMMIT;

Stack Overflow 上的这个答案声称您不应该因为pg_attribute膨胀而频繁地删除并重新创建临时表。

ChatGPT（gah！）对膨胀有这样的看法pg_attribute：

在 PostgreSQL 中，频繁创建临时表可能会导致数据库膨胀pg_attribute，因为每个新临时表都会添加元数据，即使删除该表后，这些元数据仍会保留在系统目录中。为避免数据库过度膨胀，请考虑以下最佳实践：

1. 使用ON COMMIT DELETE ROWS而不是删除表：

CREATE TEMP TABLE temp_data (
   i int NOT NULL
) ON COMMIT DELETE ROWS;

2. pg_temp对会话级临时表使用架构

CREATE TEMP TABLE pg_temp.temp_data (
    id SERIAL PRIMARY KEY,
    value TEXT
);

由于我对任何大型语言模型所作的任何声明的真实性都深表怀疑，我应该选择哪种方法？事实上，这两种方法都有效吗？

我正在尝试添加扩展事件会话来跟踪备份完成事件。

我这样做是在可用性组的辅助节点上执行此操作的先导RESTORE HEADERONLY ... LOADHISTORY，目的是两个 AG 节点在msdb.dbo.backupset相关表中都具有准确的详细信息。 由于我们使用的是 SQL Server 2019，因此无法选择包含可用性组。我们还使用分布式可用性组，这排除了包含 AG，因此即使我们可以升级到 SQL Server 2022，包含 AG仍然无济于事。

扩展事件定义是：

CREATE EVENT SESSION [backup_finished]
ON SERVER 
ADD EVENT [D5149520-6282-11DE-8A39-0800200C9A66].[sqlserver].[backup_restore_progress_trace]
(
    ACTION
    (
          [sqlserver].[client_app_name]
        , [sqlserver].[client_hostname]
        , [sqlserver].[database_name]
        , [sqlserver].[nt_username]
        , [sqlserver].[server_principal_name]
        , [sqlserver].[session_id]
        , [sqlserver].[sql_text]
    )
    WHERE 
    (
        /* this is the database name where the BACKUP operation took place, not the database being backed up. */
            [CE79811F-1A80-40E1-8F5D-7445A3F375E7].[sqlserver].[database_name] = N'maintenance' 
        /* this is the name of the database that was backed up */
        AND [database_name] = N'<database_of_interest>'
        /* 'Backup' or 'Restore' */
        AND [operation_type] = N'Backup'
        /* 
            0 -> Information of major steps in the operation
            1 -> Verbose I/O related information 
        */
        AND [trace_level] = 0 
        AND 
        (
            /* the trace_message contains one or more characters at the end */
               [trace_message] LIKE N'BACKUP DATABASE finished%'
            OR [trace_message] LIKE N'BACKUP LOG finished%'
        )
    )
)
WITH
(
      MAX_MEMORY = 4096 KB
    , EVENT_RETENTION_MODE = ALLOW_SINGLE_EVENT_LOSS
    , MAX_DISPATCH_LATENCY = 30 SECONDS
    , MAX_EVENT_SIZE = 0 KB
    , MEMORY_PARTITION_MODE = NONE
    , TRACK_CAUSALITY = OFF
    , STARTUP_STATE = OFF
);
GO

[D5149520-6282-11DE-8A39-0800200C9A66]是 的模块 GUID sqlmin.dll，其中包含扩展事件的代码[backup_restore_progress_trace]。

[CE79811F-1A80-40E1-8F5D-7445A3F375E7]是 的模块 GUID sqllang.dll，其中包含大部分[sqlserver]扩展事件代码。

在 where 子句中，我有两个谓词[database_name]; 第一个[CE79811F-1A80-40E1-8F5D-7445A3F375E7].[sqlserver].[database_name] = N'maintenance' 将捕获的事件限制为在数据库上下文中执行的语句maintenance。该谓词完全使用模块 GUID 进行限定，以将其与同名的[database_name]事件字段名称区分开来。

[database_name]、[operation_type]、[trace_level]和谓词[trace_message]不完全限定，因为我无法确定如何完全限定它们。

我尝试使用我能找到的每个模块 GUID 来限定不合格谓词，但是它们都没有解析，当我尝试创建扩展事件时返回此错误：

消息 25706，级别 16，状态 8，第 62
行 找不到事件属性或谓词源“6D503F55-3041-4A62-BB8C-57C3CF081B7B.sqlserver.database_name”。
消息 15151，级别 16，状态 22，第 105 行
无法更改事件会话“backup_finished”，因为它不存在或您没有权限。

此查询中列出了模块列表及其 guid：

SELECT 
      [module_guid] = QUOTENAME([dxp].module_guid)
    , [package_name] = QUOTENAME([dxp].[name])
    , [module_file_name] = RIGHT([dolm].[name], CHARINDEX(N'\', REVERSE([dolm].[name])) - 1)
FROM 
    [sys].[dm_xe_packages] [dxp]
    INNER JOIN [sys].[dm_os_loaded_modules] [dolm] ON [dxp].[module_address] = [dolm].[base_address]
ORDER BY 
    [dxp].[name];

我的服务器的结果：

有谁知道我应该使用什么来完全限定不合格的谓词？

我有一个两节点 SQL Server 2019 可用性组，其数据库为多个表启用了CDC 。CDC 用于跟踪尚未捕获到数据仓库中的事务。

可用性组配置了多子网故障转移，并具有可读的辅助组。

应用程序使用sp_repltrans复制通过 CDC 捕获的事务，以获取事务列表，然后通过未记录的函数读取该列表fn_dump_dblog。一旦捕获事务并将其集成到数据仓库中，应用程序就会通过sp_repldone将该事务标记为已复制。我们将其配置为ApplicationIntent=ReadOnly自动连接到可用性组的可读辅助节点。

捕获/集成过程似乎运行良好，并且在可用性组故障转移期间恢复良好，根据需要自动切换到其他节点以维持与可读辅助节点的连接。事务被捕获到数据仓库中。

一旦事务被复制到数据仓库中，应用程序就会sp_repldone在辅助数据库上执行，看起来成功了，但事务从未在主数据库上被标记为已复制，导致事务日志REPLICATION在log_reuse_wait_desc列中报告sys.databases。

应用程序调用sp_repldone如下：

EXEC sys.sp_repldone
        @xactid = NULL
      , @xact_seqno = NULL
      , @numtrans= 0
      , @time= 0
      , @reset= 1;

以上是通过扩展事件捕获的sp_statement_completed。扩展事件捕获会话还配置为捕获错误事件，并且不会报告任何事件。

如果我手动运行sp_repltrans以获取未复制事务的列表，然后sp_repldone在辅助数据库上针对该列表运行，它似乎成功而没有问题，但主数据库仍然认为事务尚未被复制。sp_repltrans即在主服务器上运行仍然显示事务正在等待复制。

我在 sp_repldone 的文档中没有看到任何内容表明它可以或不能从可读的辅助设备运行；事实上，我猜测如果它无法将事务标记为已复制，它会返回错误，但也许在实现中存在错误。诚然，这种配置可能并不那么常见。如果我们将捕获/集成进程配置为附加到主节点，通过删除ApplicationIntent=ReadOnly，然后sp_repldone针对主节点执行确实可以正常运行，并且所有事务都被标记为已复制，从而允许事务日志重用。

是否需要更改某些内容才能使其针对可读的辅助工作？

我已通过 Azure 反馈网站报告了该行为（此处）。

考虑以下最小、完整且可验证的示例代码（请参阅此处的 dbfiddle）：

CREATE TABLE [dbo].[test]
(
      [i] bigint NOT NULL 
        identity(1,1) 
        PRIMARY KEY CLUSTERED
    , [d] varchar(10) NOT NULL
);
GO

使用INSTEAD OF INSERT, UPDATE触发器：

CREATE TRIGGER [dbo_test_trigger]
ON [dbo].[test]
INSTEAD OF INSERT, UPDATE
AS
BEGIN
    IF ROWCOUNT_BIG() = 0 RETURN;

    SET NOCOUNT ON;

    MERGE INTO [dbo].[test] [target]
    USING [inserted] [source] ON [target].[i] = [source].[i]
    WHEN NOT MATCHED THEN
        INSERT
        (
            [d]
        )
        VALUES 
        (
            [source].[d]
        )
    WHEN MATCHED THEN 
        UPDATE
        SET [target].[d] = [source].[d];
END;
GO

我正在对表进行插入，希望获得插入的标识值，但是返回的值是0：

DECLARE @output TABLE
(
      [i] bigint NOT NULL
    , [d] varchar(10) NOT NULL
);

INSERT INTO [dbo].[test]
(
    [d]
)
OUTPUT 
      [inserted].[i]
    , [inserted].[d]
INTO @output 
(
      [i]
    , [d]
) 
VALUES ('test');

/* shows [i] is 0 */
SELECT *
FROM @output;

/* shows [i] is 1 */
SELECT *
FROM [dbo].[test];

结果是：

和

期望的结果是两组输出匹配，但事实并非如此。

我究竟做错了什么？

我已经看到了这一点，但是这似乎很不同，因为我根本没有使用视图。在我的示例中，触发器位于桌子上。

我有一个 SQL Server 代理作业，旨在重新配置自身以响应作业启动时的条件。

因此，本质上，第一步更新了第二步。这种情况是正确的，但 SQL Server 代理进程似乎不知道第二步已更新，并运行了步骤 2 命令的旧缓存副本。我尝试添加sp_update_job到第一步，试图让代理进程更新其缓存，但并不高兴。

这是一个mcve供您欣赏：

BEGIN TRANSACTION
DECLARE @ReturnCode INT
SELECT @ReturnCode = 0
IF NOT EXISTS (SELECT name FROM msdb.dbo.syscategories WHERE name=N'[Uncategorized (Local)]' AND category_class=1)
BEGIN
EXEC @ReturnCode = msdb.dbo.sp_add_category @class=N'JOB', @type=N'LOCAL', @name=N'[Uncategorized (Local)]'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback

END

DECLARE @jobId BINARY(16)
EXEC @ReturnCode =  msdb.dbo.sp_add_job @job_name=N'Test self-updating job', 
        @enabled=1, 
        @notify_level_eventlog=0, 
        @notify_level_email=0, 
        @notify_level_netsend=0, 
        @notify_level_page=0, 
        @delete_level=0, 
        @description=N'No description available.', 
        @category_name=N'[Uncategorized (Local)]', 
        @owner_login_name=N'sa', @job_id = @jobId OUTPUT
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'step 1 - update step 2', 
        @step_id=1, 
        @cmdexec_success_code=0, 
        @on_success_action=3, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'TSQL', 
        @command=N'USE [msdb];
GO
DECLARE @job_name sysname = N''Test self-updating job'';

DECLARE @command nvarchar(max);
IF EXISTS
(
    SELECT 1
    FROM [msdb].[dbo].[sysjobsteps] [sjs]
        INNER JOIN [msdb].[dbo].[sysjobs] [sj] ON [sjs].[job_id] = [sj].[job_id]
    WHERE [sj].[name] = N''Test self-updating job''
        AND [sjs].[step_id] = 2
        AND [sjs].[command] = N''PRINT N''''A'''';''
)
BEGIN
    SET @command = N''PRINT N''''B'''';''; 
END
ELSE
BEGIN
    SET @command = N''PRINT N''''A'''';''; 
END;
EXEC [msdb].[dbo].[sp_update_jobstep] @job_name = @job_name, @step_id = 2, @command = @command;
EXEC [msdb].[dbo].[sp_update_job] @job_name = @job_name, @automatic_post = 1;
', 
        @database_name=N'master', 
        @flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobstep @job_id=@jobId, @step_name=N'step 2 - do the work', 
        @step_id=2, 
        @cmdexec_success_code=0, 
        @on_success_action=1, 
        @on_success_step_id=0, 
        @on_fail_action=2, 
        @on_fail_step_id=0, 
        @retry_attempts=0, 
        @retry_interval=0, 
        @os_run_priority=0, @subsystem=N'TSQL', 
        @command=N'PRINT N''A'';', 
        @database_name=N'master', 
        @flags=0
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_update_job @job_id = @jobId, @start_step_id = 1
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
EXEC @ReturnCode = msdb.dbo.sp_add_jobserver @job_id = @jobId, @server_name = N'(local)'
IF (@@ERROR <> 0 OR @ReturnCode <> 0) GOTO QuitWithRollback
COMMIT TRANSACTION
GOTO EndSave
QuitWithRollback:
    IF (@@TRANCOUNT > 0) ROLLBACK TRANSACTION
EndSave:
GO

测试作业从第二步开始，在打印A或B每次运行之间交替。即第一次运行时，应该打印B，然后下次运行时应该打印A，然后下次运行时，应该打印，B依此类推。

运行作业并检查作业历史记录显示输出为A，但是检查第二步的命令显示输出为PRINT N'B';。因此，步骤命令正在更新，但代理实际上正在运行旧的预更新步骤代码。

有没有办法让 SQL Server 代理运行步骤 2 中更新的代码而不是旧的过时代码？

在实际工作中，第二步是使用代理运行的 cmdExec 命令，因此我不能仅在一步中使用动态 SQL。

如何确定在 Linux 上运行的 11.5 DB2 实例的默认隔离级别？

我从这个 IBM 文档中看到有一个“特殊寄存器” ，但是我不是 DB2 专家，所以我不确定在哪里可以找到它，或者如何“查看”“特殊”寄存器的值。

我也看过这个，但我也没有运气了解如何从中获得当前的隔离。

我的家庭实验室设置包括四台服务器，这些服务器在两台物理主机上运行在 HyperV 中。SQL Server 实例是 SQLAG101、SQLAG102、SQLAG201 和 SQLAG202。

SQLAG101 和 SQLAG102 是 SQLAG100 可用性组的成员，并且位于 192.168.0.0/24 网络上。

SQLAG201 和 SQLAG202 是 SQLAG200 可用性组的成员，并且位于 192.168.2.0/24 网络上。

流量在两个子网之间路由，这两个子网都在我的实验室本地（即涉及的延迟非常少）。

SQLDAG 是一个分布式可用性组，跨越 SQLAG100 和 SQLAG200。这已经运行了大约 6 个月，AG 成员服务器之间的自动故障转移和两个 AG 之间的手动故障转移都正常工作，并且没有数据丢失。

在我的测试服务器上，我在我的 Distributed AG Forwarder 上看到以下错误FILESTREAM：

操作系统在“F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8”上尝试“CreateFileW”时返回错误“2（系统找不到指定的文件。）” -922c-4821-904e-7555c031630d\0000008f-000292b0-0006' 在 'fsdohdlr.cpp' (2474)。

数据库“dag_test_db”的 Always On 可用性组数据移动已暂停，原因如下：“系统”（源 ID 3；源字符串：“SUSPEND_FROM_CAPTURE”）。要恢复数据库上的数据移动，您需要手动恢复数据库。有关如何恢复可用性数据库的信息，请参阅 SQL Server 联机丛书。

^{（喜欢 Books Online 参考，顺便说一句）}

为了排除故障，我已经完全dag_test_db从转发器和次要转发器中删除了。dag_test_db然后，我从主数据库中获取了完整备份，并将其恢复到转发器，并在将备份添加回转发器可用性组之前根据需要通过恢复日志备份进行前滚ALTER DATABASE [dag_test_db] SET HADR AVAILABILITY GROUP = SQLAG200;

最初，转发器 AG (SQLAG200) 的可用性组仪表板显示数据库正在同步，但大约一个小时后显示同步状态NOT SYNCHRONIZING并且同步健康原因描述显示SUSPEND_FROM_CAPTURE。

chkdsk /f在 F: 驱动器上运行不会报告任何错误。

dbcc checkdb (dag_test_db)从主要返回没有错误。

我写了一个查询来从文件流中读取所有数据；也许这会显示一些有趣的东西。获得该测试的结果后，我将更新问题。查询使用ApplicationIntent=ReadOnly通过 sqlcmd.exe 连接到转发器实例。这是查询，对于那些感兴趣的人：

USE [dag_test_db];
GO
DECLARE @d varbinary(max);
DECLARE @f nvarchar(260);
DECLARE cur CURSOR LOCAL FORWARD_ONLY READ_ONLY
FOR
SELECT
      [f].[file_data]
    , [f].[original_file_name]
FROM [dbo].[files] [f];

OPEN cur;
FETCH NEXT FROM cur INTO @d, @f;
WHILE @@FETCH_STATUS = 0
BEGIN
    PRINT @f + N': ' + CONVERT(nvarchar(11), LEN(@d), 0);
    FETCH NEXT FROM cur INTO @d, @f;
END
CLOSE cur;
DEALLOCATE cur;

也许一些勇敢的年轻 Microsoft 工程师可以帮助我理解是什么导致了错误fsdohdlr.cpp at 2474？

DBCC CHECKDB ([dag_test_db]) WITH NO_INFOMSGS;在全球主要显示没有腐败。

将报错信息中的文件名转换为十进制的LSN，fn_dblog在global primary上使用显示日志内容显示：

错误消息中引用的文件确实存在于转发器的文件系统中：

C:\Users\Hannah>目录 F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c0316 30d\0000008f-000292b0-0006
 驱动器 F 中的卷没有标签。
 卷序列号是 90BA-CEC3

 F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d目录

2023 年 4 月 28 日晚上 10:27 797,346 0000008f-000292b0-0006
               1 文件 797,346 字节
               0 目录 123,663,937,536 字节空闲

icacls对于转发器上的相关路径显示：

icacls F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d
F:\SQLServer\HV2019\FILESTREAM\dag_test_db\dag_test_db_fg_fs_f01\3e6a0757-7405-4ee2-b8a8-df878b8cd7ce\a10e3ae8-922c-4821-904e-7555c031630d NT SERVICE\MSSQL$ HV2019:(I)(OI)(CI)(F )
                                                                                                                                           所有者权利：(I)(OI)(CI)(F)
                                                                                                                                           内置\管理员：(I)(OI)(CI)(F)

成功处理1个文件；处理 0 个文件失败

从我所看到的来看，权限看起来不错——SQL Server 服务作为对文件的完全控制，实际上整个文件夹结构来自F:\SQLServer\HV2019.

我正在 Windows Server 2019 上的 SQL Server 2019 中配置可用性组。

我们有两个 Windows 服务器，UT01 和 UT02，配置了一个网络适配器，使用 Active Directory 域上的静态 IP 地址。

网络组为集群虚拟计算机对象分配了一个静态 IP 地址，UTCL，192.168.0.12。他们还为可用性组监听器分配了一个静态 IP 地址，UTAG，192.168.0.13。

服务器团队配置了 Windows Server 故障转移集群，我配置了 SQL Server 和可用性组。两个 SQL Server 都配置为命名实例；所以是返回的UT01\INS名称UT02\INS@@SERVERNAME;

从本地子网 (192.168.0.0/24) 上的任何计算机，我可以使用 sqlcmd 连接到可用性组，如下所示：

sqlcmd -S UTAG\INS

当我运行时PRINT @@SERVERNAME;，返回UT01\INS或UT02\INS，具体取决于哪个节点当前正在运行可用性组的主节点。

我可以使用 sqlcmd 通过路由器从本地子网外的网络连接到各个 SQL Server，即sqlcmd -S UT01\INS并sqlcmd -S UT02\INS正常工作，为@@SERVERNAME.

到目前为止一切都很好，完全符合预期。

但是，当我尝试通过非本地子网连接到 AG 名称时，AG 仅在 UT01 运行主节点时响应。当 UT02 运行主节点时，我们会遇到典型的连接错误：

建立与 SQL Server 的连接时发生了与网络相关或特定于实例的错误。服务器未找到或不可访问。检查实例名称是否正确以及 SQL Server 是否配置为允许远程连接。

UT02 上的 SQL Server 错误日志显示没有失败的登录（默认配置为审核失败的登录）。

ping UTAG返回正确的 IP 地址 192.168.0.13，无论我在哪里运行它。 ping UTAG从本地子网正常工作，当 AG 在 UT01 上运行时从远程子网工作，但当 UT02 是主要子网时则不能。

我在 UT01 和 UT02 上都安装了 WireShark 以查看是否可以确定发生了什么。我过滤了 WireShark 的输出：

((tcp.port == 2136) || (udp.port == 1434)) && ((ip.dst == 192.168.0.13 || ip.src == 192.168.0.13))

SQL Server AG 侦听器端口配置为侦听端口 2136，并且两个实例也配置为侦听端口 2136。SQL Server 配置管理器显示网络配置配置为侦听所有 IP 地址。

在 UT01 上观察 WireShark，当尝试从位于另一个子网上的客户端连接到 AG 时，无论哪个节点是 AG 主节点，都会显示端口 2136 上的传入 TCP 流量和端口 1434 上的 UDP 流量。当 AG primary 在 UT01 上运行时，连接到 AG 正常，当 AG primary 在 UT02 上时，连接到 AG 失败。

两台服务器都是虚拟机，运行在不同的物理主机上。交换机（虚拟或其他）清楚地知道哪个节点正在运行主节点，因为ping UTAG无论哪个节点拥有 UTAG IP 地址，本地子网都可以工作。 ping UTAG来自任何其他子网的请求仅在 AG 在 UT01 上运行时响应。

有任何想法吗？

我正在尝试优化从 REST API 获得的值的提取，该 API 在数组中返回 json 值。

这是一个最小的、完整的、可验证的例子，它准确地反映了我正在做的事情。

USE tempdb;

DROP TABLE IF EXISTS dbo.json_test;

CREATE TABLE dbo.json_test
(
    json_test_id                int                 NOT NULL
        IDENTITY(1,1)
    , some_uniqueidentifier     uniqueidentifier    NULL
    , some_varchar              varchar(100)        NULL
    , the_json                  nvarchar(max)       NULL
);

INSERT INTO dbo.json_test (some_uniqueidentifier, some_varchar, the_json)
SELECT 
        some_uniqueidentifier       = NEWID()
      , some_varchar                = CONVERT(varchar(100), CRYPT_GEN_RANDOM(64), 1)
      , the_json = (
            SELECT st.* 
            FROM sys.tables st
                CROSS JOIN sys.tables st2
            WHERE st.object_id = t.object_id FOR JSON AUTO
            )
FROM sys.tables t;

;WITH src AS 
(
    SELECT jt.some_uniqueidentifier
        , jt.some_varchar
        , top_array.[key]
        , top_array.[value]
    FROM dbo.json_test jt
        CROSS APPLY OPENJSON(jt.the_json, N'lax $') top_array
),
src2 AS
(
    SELECT src.some_uniqueidentifier
        , src.some_varchar
        , src.[key]
        , src.[value]
        , inner_key = inner_array.[key]
        , inner_value = inner_array.[value]
    FROM src
        CROSS APPLY OPENJSON(src.[value], N'lax $') inner_array
)
SELECT src2.some_uniqueidentifier
    , src2.some_varchar
    , src2.[key]
    , [name]                                = MAX(CASE WHEN src2.[inner_key] = 'name'                               THEN src2.[inner_value] ELSE NULL END)
    , [object_id]                           = MAX(CASE WHEN src2.[inner_key] = 'object_id'                          THEN src2.[inner_value] ELSE NULL END)
    , [principal_id]                        = MAX(CASE WHEN src2.[inner_key] = 'principal_id'                       THEN src2.[inner_value] ELSE NULL END)
    , [schema_id]                           = MAX(CASE WHEN src2.[inner_key] = 'schema_id'                          THEN src2.[inner_value] ELSE NULL END)
    , [parent_object_id]                    = MAX(CASE WHEN src2.[inner_key] = 'parent_object_id'                   THEN src2.[inner_value] ELSE NULL END)
    , [type]                                = MAX(CASE WHEN src2.[inner_key] = 'type'                               THEN src2.[inner_value] ELSE NULL END)
    , [type_desc]                           = MAX(CASE WHEN src2.[inner_key] = 'type_desc'                          THEN src2.[inner_value] ELSE NULL END)
    , [create_date]                         = MAX(CASE WHEN src2.[inner_key] = 'create_date'                        THEN src2.[inner_value] ELSE NULL END)
    , [modify_date]                         = MAX(CASE WHEN src2.[inner_key] = 'modify_date'                        THEN src2.[inner_value] ELSE NULL END)
    , [is_ms_shipped]                       = MAX(CASE WHEN src2.[inner_key] = 'is_ms_shipped'                      THEN src2.[inner_value] ELSE NULL END)
    , [is_published]                        = MAX(CASE WHEN src2.[inner_key] = 'is_published'                       THEN src2.[inner_value] ELSE NULL END)
    , [is_schema_published]                 = MAX(CASE WHEN src2.[inner_key] = 'is_schema_published'                THEN src2.[inner_value] ELSE NULL END)
    , [lob_data_space_id]                   = MAX(CASE WHEN src2.[inner_key] = 'lob_data_space_id'                  THEN src2.[inner_value] ELSE NULL END)
    , [filestream_data_space_id]            = MAX(CASE WHEN src2.[inner_key] = 'filestream_data_space_id'           THEN src2.[inner_value] ELSE NULL END)
    , [max_column_id_used]                  = MAX(CASE WHEN src2.[inner_key] = 'max_column_id_used'                 THEN src2.[inner_value] ELSE NULL END)
    , [lock_on_bulk_load]                   = MAX(CASE WHEN src2.[inner_key] = 'lock_on_bulk_load'                  THEN src2.[inner_value] ELSE NULL END)
    , [uses_ansi_nulls]                     = MAX(CASE WHEN src2.[inner_key] = 'uses_ansi_nulls'                    THEN src2.[inner_value] ELSE NULL END)
    , [is_replicated]                       = MAX(CASE WHEN src2.[inner_key] = 'is_replicated'                      THEN src2.[inner_value] ELSE NULL END)
    , [has_replication_filter]              = MAX(CASE WHEN src2.[inner_key] = 'has_replication_filter'             THEN src2.[inner_value] ELSE NULL END)
    , [is_merge_published]                  = MAX(CASE WHEN src2.[inner_key] = 'is_merge_published'                 THEN src2.[inner_value] ELSE NULL END)
    , [is_sync_tran_subscribed]             = MAX(CASE WHEN src2.[inner_key] = 'is_sync_tran_subscribed'            THEN src2.[inner_value] ELSE NULL END)
    , [has_unchecked_assembly_data]         = MAX(CASE WHEN src2.[inner_key] = 'has_unchecked_assembly_data'        THEN src2.[inner_value] ELSE NULL END)
    , [text_in_row_limit]                   = MAX(CASE WHEN src2.[inner_key] = 'text_in_row_limit'                  THEN src2.[inner_value] ELSE NULL END)
    , [large_value_types_out_of_row]        = MAX(CASE WHEN src2.[inner_key] = 'large_value_types_out_of_row'       THEN src2.[inner_value] ELSE NULL END)
    , [is_tracked_by_cdc]                   = MAX(CASE WHEN src2.[inner_key] = 'is_tracked_by_cdc'                  THEN src2.[inner_value] ELSE NULL END)
    , [lock_escalation]                     = MAX(CASE WHEN src2.[inner_key] = 'lock_escalation'                    THEN src2.[inner_value] ELSE NULL END)
    , [lock_escalation_desc]                = MAX(CASE WHEN src2.[inner_key] = 'lock_escalation_desc'               THEN src2.[inner_value] ELSE NULL END)
    , [is_filetable]                        = MAX(CASE WHEN src2.[inner_key] = 'is_filetable'                       THEN src2.[inner_value] ELSE NULL END)
    , [is_memory_optimized]                 = MAX(CASE WHEN src2.[inner_key] = 'is_memory_optimized'                THEN src2.[inner_value] ELSE NULL END)
    , [durability]                          = MAX(CASE WHEN src2.[inner_key] = 'durability'                         THEN src2.[inner_value] ELSE NULL END)
    , [durability_desc]                     = MAX(CASE WHEN src2.[inner_key] = 'durability_desc'                    THEN src2.[inner_value] ELSE NULL END)
    , [temporal_type]                       = MAX(CASE WHEN src2.[inner_key] = 'temporal_type'                      THEN src2.[inner_value] ELSE NULL END)
    , [temporal_type_desc]                  = MAX(CASE WHEN src2.[inner_key] = 'temporal_type_desc'                 THEN src2.[inner_value] ELSE NULL END)
    , [history_table_id]                    = MAX(CASE WHEN src2.[inner_key] = 'history_table_id'                   THEN src2.[inner_value] ELSE NULL END)
    , [is_remote_data_archive_enabled]      = MAX(CASE WHEN src2.[inner_key] = 'is_remote_data_archive_enabled'     THEN src2.[inner_value] ELSE NULL END)
    , [is_external]                         = MAX(CASE WHEN src2.[inner_key] = 'is_external'                        THEN src2.[inner_value] ELSE NULL END)
    , [history_retention_period]            = MAX(CASE WHEN src2.[inner_key] = 'history_retention_period'           THEN src2.[inner_value] ELSE NULL END)
    , [history_retention_period_unit]       = MAX(CASE WHEN src2.[inner_key] = 'history_retention_period_unit'      THEN src2.[inner_value] ELSE NULL END)
    , [history_retention_period_unit_desc]  = MAX(CASE WHEN src2.[inner_key] = 'history_retention_period_unit_desc' THEN src2.[inner_value] ELSE NULL END)
    , [is_node]                             = MAX(CASE WHEN src2.[inner_key] = 'is_node'                            THEN src2.[inner_value] ELSE NULL END)
    , [is_edge]                             = MAX(CASE WHEN src2.[inner_key] = 'is_edge'                            THEN src2.[inner_value] ELSE NULL END)
FROM src2
GROUP BY src2.some_uniqueidentifier
    , src2.some_varchar
    , src2.[key]
ORDER BY src2.some_uniqueidentifier
    , src2.some_varchar
    , src2.[key];

无论输入表中包含多少行，查询计划都使用几个嵌套循环连接。想必这是使用CROSS APPLY运算符的神器。为了您的乐趣，我已经设置了一个DB Fiddle。

有没有更有效的方法将数据从 json 格式转换为“真实”的列集？

我使用我的本地 SQL Server 2019 实例创建了上面的代码，但是目标将是 Azure SQL 数据库，因此所有最新和最好的选项都可用。

我有一个几何值表，其中一些行与其他行相交。

我需要一个几何与其他行重叠的行列表，但我希望列表尽可能简洁。

这是设置：

USE tempdb;
DROP TABLE IF EXISTS dbo.t;

CREATE TABLE dbo.t
(
    n varchar(100) NOT NULL
    , i geometry NOT NULL
);

INSERT INTO dbo.t (n, i)
VALUES ('poly1', geometry::STGeomFromText('POLYGON ((1 2, 1 4, 1 5, 4 6, 1 2))', 4326))
     , ('poly2', geometry::STGeomFromText('POLYGON ((1 2, 1 3, 2 5, 4 6, 1 2))', 4326))
     , ('poly3', geometry::STGeomFromText('POLYGON ((7 9, 8 7, 9 6, 7 9))', 4326))

SELECT t1.n
    , t2.n
FROM dbo.t t1
    INNER JOIN dbo.t t2 ON t1.i.STIntersects(t2.i) = 1
WHERE 
    t1.n <> t2.n;

输出如下所示：

但是，为了简洁起见，我只想要一行。即因为 poly1 重叠 poly2和poly2 重叠 poly1 我得到两行返回我只想要一个，如：

考虑以下设置，您可以在dbfiddle.uk进行修改：

在第一批中，我们设置了三个简单的表，并为每个表添加一行：

CREATE TABLE t1 (x int NOT NULL);
CREATE TABLE t2 (y int NOT NULL);
CREATE TABLE t3 (z int NOT NULL);

INSERT INTO t1 (x) VALUES (1);
INSERT INTO t2 (y) VALUES (2);
INSERT INTO t3 (z) VALUES (3);

接下来，我们将创建三个存储过程：

DELIMITER //

CREATE PROCEDURE proc1()
BEGIN
    UPDATE t1 SET x = x + 1;
END
//

CREATE PROCEDURE proc2()
BEGIN
    UPDATE t2 SET y = y - 1;
END
//

CREATE PROCEDURE proc3()
BEGIN
    UPDATE t3 SET z = z / 0;
END
///

接下来我们将启动一个事务，运行三个 proc，然后回滚事务。请注意，我们正在显式禁用自动提交，即使这不是严格要求的，因为我们有一个显式事务：

SET autocommit = 0;
START TRANSACTION
CALL proc1();
CALL proc2();
CALL proc3();
ROLLBACK

现在，如果我们检查三个表的内容，我们注意到回滚似乎没有发生。事实上，这些行就像没有事务一样，即看起来好像自动提交已打开。

SELECT *
FROM t1;

SELECT *
FROM t2;

SELECT *
FROM t3;

结果：

╔═══╗
║×║
╠═══╣
║ 2 ║
╚═══╝
╔═══╗
║是║
╠═══╣
║ 1 ║
╚═══╝
╔═══╗
║z║
╠═══╣
║ 3 ║
╚═══╝

这里发生了什么，当第三个明显失败时，我如何回滚前两个 proc 的动作？

仅供参考，这已经在 MySQL 5.7.2 上进行了测试，并通过 DBFiddle.uk 在 MySQL 8.0.22 上进行了测试。

varchar(max)ASE中的 SQL Server 数据类型等价物是什么？

ASE 我指的是过去被称为 Sybase ASE 的东西，它现在归 SAP 所有。

我正在尝试执行一段超过 8,000 个字符的动态构造的 T-SQL。

如果我用 声明一个变量varchar(max)，ASE 会阻塞：

关键字“max”附近的语法不正确。

我的下一个想法是尝试text数据类型。可惜：

您为包含“立即执行”命令字符串的变量指定了不正确的数据类型。

一个最小的、完整的、可验证的例子：

DECLARE @cmd varchar(max) --change this to varchar(4000) and it works
SET @cmd = 'SELECT 1;'
EXEC (@cmd);
GO

将变量声明更改为text或任何适合您的目的。我需要执行一个可能有 50,000 个字符长的动态命令。

或者，我可以使用游标，但我不熟悉游标在 ASE 上的工作方式。

请注意，在 SQL Anywhere 中，您可以将 varchar(max) 数据类型的等价物定义为declare @cmd long varchar;，但这在 ASE 中不起作用。

在以下错误消息中，给出的原因是“无效的保护选项”。这说明什么？

SQL Server 检测到基于逻辑一致性的 I/O 错误：无效的保护选项

出于这个问题的目的，我不需要知道任何关于“如何运行 DBCC”或“检查损坏”的信息。收到。我只是对“根本原因”部分以及可能导致这种基于逻辑一致性的 I/O 错误的原因感到好奇。

采用以下最低限度完整且可验证的示例¹代码：

USE tempdb;

DROP TABLE IF EXISTS dbo.t;
GO
CREATE TABLE dbo.t
(
    t_id int NOT NULL
        CONSTRAINT t_pk
        PRIMARY KEY 
        CLUSTERED
        IDENTITY(1,1)
    , k sysname NOT NULL
        INDEX t_001
    , s sysname NOT NULL
        INDEX t_002
    , somedata varchar(1000) NOT NULL
        CONSTRAINT t_somedata_df
        DEFAULT REPLICATE('A', 1000)
    , INDEX t_003 (k, s)
);

INSERT INTO dbo.t (s, k)
SELECT sc1.name, sc2.name
FROM sys.syscolumns sc1
    CROSS JOIN sys.syscolumns sc2;

CREATE STATISTICS t_st001 ON dbo.t (k) WITH FULLSCAN;
CREATE STATISTICS t_st002 ON dbo.t (s) WITH FULLSCAN;

以下查询故意使用了错误的变量类型。我希望查询计划包含一个隐式转换警告，但它没有。

DECLARE @k char(128) = 'a';
DECLARE @s char(128) = '';
SELECT s 
FROM dbo.t 
    LEFT JOIN sys.syscolumns sc ON t.s = sc.name
WHERE dbo.t.s = @s
    OR dbo.t.k = @k;

这是为什么？

查询计划在这里。

^{1 - 这是我的网站，顺便说一句}

我最近将 RedHat Enterprise Linux 7.6 上的 SQL Server 2017 Developer Edition 升级到 SQL Server 2019 CTP 3.0。

mssql-server 服务将不再启动。/var/opt/mssql/log/errorlog 显示以下内容：

2019-06-12 09:36:31.98 服务器 Microsoft SQL Server 2019 (CTP3.0) - 15.0.1600.8 (X64)
2019 年 5 月 17 日 00:56:19
版权所有 (C) 2019 Microsoft Corporation
Developer Edition (64-bit) o​​n Linux (Red Hat Enterprise Linux)
2019-06-12 09:36:32.04 服务器 UTC 调整：-5:00
2019-06-12 09:36:32.05 服务器 (c) Microsoft Corporation。
2019-06-12 09:36:32.07 服务器 版权所有。
2019-06-12 09:36:32.08 服务器服务器进程 ID 为 32。
2019-06-12 09:36:32.09 服务器在文件“/var/opt/mssql/log/errorlog”中记录 SQL Server 消息。
2019-06-12 09:36:32.10 服务器注册表启动参数：
-d /var/opt/mssql/data/master.mdf
-l /var/opt/mssql/data/mastlog.ldf
-e /var/opt/mssql/log/errorlog
2019-06-12 09:36:32.15 服务器命令行启动参数： --accept
-eula
2019-06 -12 09:36:32.18 服务器 SQL Server 检测到 1 个插槽，每个插槽有 4 个内核，每个插槽有 4 个逻辑处理器，总共 4 个逻辑处理器；使用 4 个基于 SQL Server 许可的逻辑处理器。这是一条情报信息; 无需用户操作。
2019-06-12 09:36:32.20 服务器 SQL Server 以正常优先级基础 (=7) 启动。这只是一条信息性消息。无需用户操作。
2019-06-12 09:36:32.23 服务器检测到 7856 MB 的 RAM。这是一条情报信息; 无需用户操作。
2019-06-12 09:36:32.24 服务器在内存管理器中使用常规内存。
2019-06-12 09:36:32.28 Linux 平台不支持服务器缓冲池扩展。
2019-06-12 09:36:32.29 服务器错误：17128，严重性：16，状态：1。
2019-06-12 09:36:32.29 服务器初始化数据：内核缓冲区没有内存。

/var/opt/mssql/mssql.conf 内容：

[sqlagent]
启用 = 假

systemctl status mssql-server显示：

mssql-server.service - Microsoft SQL Server 数据库引擎
已加载：已加载（/usr/lib/systemd/system/mssql-server.service；已启用；供应商预设：已禁用）
活动：自 2019 年星期一以来失败（结果：启动限制） -06-17 13:57:45 CDT；26 分钟前
文档：https
://learn.microsoft.com/en-us/sql/linux 进程：71357 ExecStart=/opt/mssql/bin/sqlservr（code=exited，status=1/FAILURE）
主 PID：71357（代码=退出，状态=1/失败）
任务：0
CGroup：/system.slice/mssql-server.service

6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：mssql-server.service：主进程退出，代码=退出，状态=1/FAILURE
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd [ 1]：单元 mssql-server.service 进入失败状态。
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：mssql-server.service 失败。
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：mssql-server.service 延迟时间结束，计划重启。
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：停止 Microsoft SQL Server 数据库引擎。
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：mssql-server.service 的启动请求重复太快
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：无法启动 Microsoft SQL Server 数据库引擎。
Jun 17 13:57:45 rhel72-sqlserver.localdomain systemd[1]：单元 mssql-server.service 进入失败状态。
6 月 17 日 13:57:45 rhel72-sqlserver.localdomain systemd[1]：mssql-server.service 失败。

我试过yum remove mssql-server了，然后是yum install mssql-server，但没有改变。

有任何想法吗？

尝试以mssql-conf setuproot 身份运行可执行文件会导致以下结果：

[root@rhel72-sqlserver bin]# sudo ./mssql-conf setup
usermod: no changes
选择 SQL Server 的版本：
1) 评估（免费，无生产使用权，180 天限制）
2) 开发人员（免费，无生产使用权）
3) Express（免费）
4) Web (PAID)
5) Standard (PAID)
6) Enterprise (PAID) - CPU 核心利用率限制为 20 个物理/40 个超线程
7) Enterprise Core (PAID) - CPU 核心利用率最多操作系统
8) 我通过零售渠道购买了许可证，并且有一个产品密钥可以输入。

有关版本的详细信息，请访问
https://go.microsoft.com/fwlink/?LinkId=852748&clcid=0x409

使用此软件的付费版本需要通过
Microsoft 批量许可计划单独获得许可。
通过选择付费版本，您正在验证您是否拥有适当
数量的许可证来安装和运行该软件。

输入您的版本 (1-8)： 2
此产品的许可条款可在
/usr/share/doc/mssql-server 中找到或从以下网址下载：
https ://go.microsoft.com/fwlink/?LinkId=855862&clcid =0x409

可以在以下位置查看隐私声明：
https ://go.microsoft.com/fwlink/?LinkId=853010&clcid=0x409

输入 SQL Server 系统管理员密码：
确认 SQL Server 系统管理员密码：
配置 SQL Server...

这是一个评估版本。评估期还剩 [153] 天。
此程序遇到致命错误，无法在 2019 年 6 月 17 日星期一 14:35:43 继续运行
以下诊断信息可用：

  Reason: 0x00000007  
  Status: 0xc0000218  
 Message: Cannot open or read the persistent registry: \SystemRoot\security.hiv.  

Stack Trace:
000000006bd347d0
000000006bd31af7
000000006bd31d3a
000000006bd30ea5
000000006bd2faf7
000000006bd73371
Process: 75209 - sqlservr
Thread: 75213 (application thread 0x4)
Instance Id: ffcf27f9-18a5-485a-8a9d-34482c5efe06
Crash Id: cb1238f4-2504-457c-bbb3-d7ecad750aec
Build stamp: fbef7d3acfbedcf62a42c8909366dbba3852b92cabb497c2169680835fd60276
分布：红帽企业 Linux
处理器：4
总内存：16637898752 字节
时间戳：2019 年 6 月 17 日星期一 14:35:43

Red Hat Enterprise Linux正在
将核心转储和信息捕获到 /var/opt/mssql/log...
提示：您目前看不到来自其他用户和系统的消息。
'systemd-journal' 组中的用户可以看到所有消息。通过 -q
关闭此通知。
由于权限不足，未打开任何日志文件。
提示：您目前看不到来自其他用户和系统的消息。
'systemd-journal' 组中的用户可以看到所有消息。通过 -q
关闭此通知。
由于权限不足，未打开任何日志文件。
/usr/bin/tail：无法打开“/var/log/messages”进行阅读：权限被拒绝
尝试使用 paldumper
捕获转储 使用 paldumper
/usr/bin/find 捕获转储：'/usr/share/polkit-1/rules.d'：权限被拒绝
/usr/bin/find：'/usr/libexec/initscripts /legacy-actions/auditd'：权限被拒绝
核心转储和信息正在后台压缩。完成
后，可以在以下位置找到它们：
/var/opt/mssql/log/core.sqlservr.06_17_2019_14_35_43.75209.tbz2
Microsoft SQL Server 的初始设置失败。请查阅
/var/opt/mssql/log 中的错误日志以获取更多信息。
[root@rhel72-sqlserver bin]#

我以 身份登录服务器root，所以我不明白为什么我会看到“拒绝访问”错误。

进行以下复制：

USE tempdb;

IF OBJECT_ID(N'dbo.t', N'U') IS NOT NULL
DROP TABLE dbo.t
GO
CREATE TABLE dbo.t
(
    id int NOT NULL 
        PRIMARY KEY 
        NONCLUSTERED 
        IDENTITY(1,1)
    , col1 datetime NOT NULL
    , col2 varchar(800) NOT NULL
    , col3 tinyint NULL
    , col4 sysname NULL
);

INSERT INTO dbo.t (
      col1
    , col2
    , col3
    , col4
    ) 
SELECT TOP(100000) 
      CONVERT(datetime, 
         DATEADD(DAY, CONVERT(int, CRYPT_GEN_RANDOM(1)), '2000-01-01 00:00:00'))
    , replicate('A', 800)
    , sc2.bitpos
    , CONVERT(sysname, CHAR(65 + CRYPT_GEN_RANDOM(1) % 26) 
        + CHAR(65 + CRYPT_GEN_RANDOM(1) % 26) 
        + CHAR(65 + CRYPT_GEN_RANDOM(1) % 26))
FROM sys.syscolumns sc
    CROSS JOIN sys.syscolumns sc2;

在这里，我将聚集索引添加到一组不唯一的列上，并且是典型的单列非聚集索引：

CREATE CLUSTERED INDEX t_cx 
ON dbo.t (col1, col2, col3);

CREATE INDEX t_c1 ON dbo.t(col4); 

此查询强制 SQL Server 查找聚集索引。请原谅使用索引提示，这是获得重现的最快方法：

SELECT id
    , col1
    , col2
    , col3
FROM dbo.t aad WITH (INDEX = t_c1)
WHERE col4 = N'JSB'
    AND col1 > N'2019-05-30 00:00:00';

实际查询计划在非聚集索引扫描的输出列表中显示一个不存在的列：

从表面上看，这表示在非唯一聚集索引中使用的唯一标识符。是这样吗？像这样命名的列是否总是聚集索引 uniqifier？

考虑以下简单的 MCVE：

SET STATISTICS IO, TIME OFF;
USE tempdb;

IF OBJECT_ID(N'tempdb..#t1', N'U') IS NOT NULL DROP TABLE #t1;
CREATE TABLE #t1
(
    r int NOT NULL
);

IF OBJECT_ID(N'tempdb..##t1', N'U') IS NOT NULL DROP TABLE ##t1;
CREATE TABLE ##t1
(
    r int NOT NULL
);

IF OBJECT_ID(N'dbo.s1', N'U') IS NOT NULL DROP TABLE dbo.s1;
CREATE TABLE dbo.s1 
(
    r int NOT NULL
        PRIMARY KEY CLUSTERED
);

INSERT INTO dbo.s1 (r)
SELECT TOP(10000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM sys.syscolumns sc1
    CROSS JOIN sys.syscolumns sc2;
GO

当我运行以下插入时，插入#t1显示临时表没有统计 I/O。但是，插入##t1 确实会显示临时表的 stats I/O。

SET STATISTICS IO, TIME ON;
GO

INSERT INTO #t1 (r)
SELECT r
FROM dbo.s1;

统计输出：

SQL Server 解析和编译时间：
   CPU 时间 = 0 毫秒，经过时间 = 1 毫秒。
表's1'。扫描计数 1，逻辑读取 19，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

 SQL Server 执行时间：
   CPU 时间 = 16 毫秒，经过时间 = 9 毫秒。

（10000 行受影响）

INSERT INTO ##t1 (r)
SELECT r
FROM dbo.s1;

SQL Server 解析和编译时间：
   CPU 时间 = 0 毫秒，经过时间 = 1 毫秒。
表'##t1'。扫描计数 0，逻辑读取 10016，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。
表's1'。扫描计数 1，逻辑读取 19，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob 预读读取 0。

 SQL Server 执行时间：
   CPU 时间 = 47 毫秒，经过时间 = 45 毫秒。

（10000 行受影响）

当我只插入时，为什么 ##temp 表上有这么多读取？

使用通过程序集内置到 Microsoft.Net 的 Microsoft.Net v4.0 SqlClient 连接System.Data.SqlClient，特定机器无法连接到特定的一组服务器。尝试连接时，会引发以下错误：

System.Data.SqlClient.SqlException (0x80131904): 与服务器建立连接成功，但是在登录过程中出现错误。（提供者：SSL Provider，错误：0 - 现有连接被远程主机强行关闭。）---> System.ComponentModel.Win32Exception (0x80004005)：现有连接被远程主机强行关闭
   在 System.Data.SqlClient.SqlInternalConnection.OnError（SqlException 异常，布尔 breakConnection，Action`1 wrapCloseInAction）
   在 System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning（TdsParserStateObject stateObj，布尔调用者HasConnectionLock，布尔异步关闭）
   在 System.Data.SqlClient.TdsParserStateObject.SNIWritePacket（SNIHandle 句柄，SNIPacket 数据包，UInt32& sniError，布尔 canAccumulate，布尔调用者HasConnectionLock）
   在 System.Data.SqlClient.TdsParserStateObject.WriteSni（布尔值 canAccumulate）
   在 System.Data.SqlClient.TdsParserStateObject.WritePacket（字节flushMode，布尔canAccumulate）
   在 System.Data.SqlClient.TdsParser.TdsLogin(SqlLogin rec)
   在 System.Data.SqlClient.SqlInternalConnectionTds.AttemptOneLogin（ServerInfo serverInfo，字符串 newPassword，SecureString newSecurePassword，布尔型 ignoreSniOpenTimeout，TimeoutTimer 超时，布尔型 withFailover）
   在 System.Data.SqlClient.SqlInternalConnectionTds.LoginNoFailover（ServerInfo serverInfo，字符串 newPassword，SecureString newSecurePassword，布尔重定向用户实例，SqlConnectionString 连接选项，SqlCredential 凭据，TimeoutTimer 超时）
   在 System.Data.SqlClient.SqlInternalConnectionTds.OpenLoginEnlist（TimeoutTimer 超时，SqlConnectionString 连接选项，SqlCredential 凭据，字符串 newPassword，SecureString newSecurePassword，布尔重定向用户实例）
   在 System.Data.SqlClient.SqlInternalConnectionTds..ctor（DbConnectionPoolIdentity 标识，SqlConnectionString connectionOptions，SqlCredential 凭据，对象 providerInfo，String newPassword，SecureString newSecurePassword，Boolean redirectedUserInstance，SqlConnectionString userConnectionOptions）
   在 System.Data.SqlClient.SqlConnectionFactory.CreateConnection（DbConnectionOptions 选项，DbConnectionPoolKey poolKey，对象 poolGroupProviderInfo，DbConnectionPool 池，DbConnection owningConnection，DbConnectionOptions userOptions）
   在 System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection（DbConnection owningConnection，DbConnectionPoolGroup poolGroup，DbConnectionOptions userOptions）
   在 System.Data.ProviderBase.DbConnectionFactory.TryGetConnection（DbConnection owningConnection，TaskCompletionSource`1 重试，DbConnectionOptions userOptions，DbConnectionInternal& 连接）
   在 System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection（DbConnection outerConnection，DbConnectionFactory connectionFactory，TaskCompletionSource`1 重试，DbConnectionOptions userOptions）
   在 System.Data.SqlClient.SqlConnection.TryOpen（TaskCompletionSource`1 重试）
   在 System.Data.SqlClient.SqlConnection.Open()
   在 ConsoleApplication1.Module1.Main()

我可以使用相同的二进制文件从其他机器连接到相同的目标服务器而不会出现问题。如果我针对 Microsoft.Net v2.0 重新编译二进制文件，我也可以从有问题的服务器连接。

目标服务器配置为审核失败的登录，但是由于此问题，SQL Server 错误日志中没有记录任何失败 -如果我使用无效的 SQL Server 登录名登录，我可能会导致审核条目，以确保审核正常工作.

我用来测试这个问题的代码是：

Module Module1

    Sub Main()

        Dim bUseSSL As Boolean = False

        If My.Application.CommandLineArgs.Contains("/SSL") Then
            bUseSSL = True
        End If

        If bUseSSL Then
            Console.WriteLine("Encryption enabled")
        Else
            Console.WriteLine("Encryption disabled")
        End If

        Dim cb As New Data.SqlClient.SqlConnectionStringBuilder
        cb.ApplicationName = "SqlClientTest"
        cb.DataSource = "<server_name_here>"
        cb.IntegratedSecurity = True
        cb.Encrypt = bUseSSL
        'cb.TrustServerCertificate = True
        cb.NetworkLibrary = "dbmssocn"

        Try
            Using sqlconnection As New System.Data.SqlClient.SqlConnection(cb.ConnectionString)
                Try
                    sqlconnection.Open()
                    Console.WriteLine("Connected to " & cb.DataSource)
                    Dim sqlcommand As New System.Data.SqlClient.SqlCommand("SELECT @@SERVERNAME;", sqlconnection)
                    Dim sqlreader As System.Data.SqlClient.SqlDataReader = sqlcommand.ExecuteReader
                    While sqlreader.Read
                        Console.WriteLine(sqlreader.GetString(0))
                    End While
                    sqlreader.Close()
                Catch ex As Exception
                    Console.WriteLine(cb.ConnectionString)
                    Console.WriteLine("")
                    Console.WriteLine(ex.ToString)
                End Try
                Console.WriteLine("Press 'q' to quit.")
                Dim cki As ConsoleKeyInfo = Console.ReadKey
                While cki.KeyChar.ToString.ToLower <> "q"
                    cki = Console.ReadKey
                End While
            End Using
        Catch ex As Exception
            Console.WriteLine(cb.ConnectionString)
            Console.WriteLine("")
            Console.WriteLine(ex.ToString)
        End Try
    End Sub

End Module

无论加密设置如何，无论设置如何，都会记录相同的失败TrustServerCertificate。

即使我通过连接字符串将其禁用，某些东西似乎也在强制这台机器上的 .Net SqlClient v4.0 使用 SSL。

任何想法要检查什么？

我正在尝试获取具有 ROW_OVERFLOW_DATA 行的表的页面列表。我可以从未记录的 DMV 中获取已分配页面的列表sys.db_db_database_page_allocations，但是，该 DMV 的输出中似乎没有列出 ROW_OVERFLOW_DATA 页面。还有其他一些我根本找不到的 DMV 吗？

最小的、完整的和（希望！）可验证的示例：

USE tempdb;

IF OBJECT_ID(N'dbo.t', N'U') IS NOT NULL
DROP TABLE dbo.t;
GO

CREATE TABLE dbo.t
(
    rownum int NOT NULL IDENTITY(1,1)
        PRIMARY KEY CLUSTERED
    , on_row_data varchar(30) NOT NULL
        DEFAULT ('on_row_data')
    , off_row_data varchar(MAX) NOT NULL
        DEFAULT REPLICATE('A', 20000) --PLENTY BIG ENOUGH!
) WITH (DATA_COMPRESSION = NONE); --not compressing those pages!

INSERT INTO dbo.t DEFAULT VALUES;

DECLARE @ObjectID int = (SELECT o.object_id FROM sys.objects o WHERE o.name = 't');
DECLARE @PageID int;
DECLARE @PageTypeDesc varchar(100);

SELECT FileID = dpa.allocated_page_file_id
    , PageID = dpa.allocated_page_page_id
    , PageTypeDesc = dpa.page_type_desc
FROM sys.dm_db_database_page_allocations(DB_ID(), @ObjectID, NULL, NULL, 'DETAILED') dpa

输出看起来像：

╔════════╦════════╦══════════════╗
║ 文件 ID ║ 页面 ID ║ PageTypeDesc ║
╠════════╬════════╬══════════════╣
║ 1 ║ 1598 ║ IAM_PAGE ║
║ 3 ║ 105368 ║ DATA_PAGE ║
║ 3 ║ 105369 ║ 空 ║
║ 3 ║ 105370 ║ 空 ║
║ 3 ║ 105371 ║ 空 ║
║ 3 ║ 105372 ║ 空 ║
║ 3 ║ 105373 ║ 空 ║
║ 3 ║ 105374 ║ 空 ║
║ 3 ║ 105375 ║ 空 ║
╚════════╩════════╩══════════════╝

这是有道理的，除了缺少 ROW_OVERFLOW_DATA 页面。我们有一个单独的索引分配映射页面，以及一个完整的 8KB 数据页面，其中只有一个实际分配了页面。

同样，如果我使用未记录的sys.fn_PhysLocCracker函数来显示每行所在的页面，如：

SELECT *
FROM dbo.t
CROSS APPLY sys.fn_PhysLocCracker(%%PHYSLOC%%)

我只看到DATA_PAGE列出的：

╔════════╦═════════════╦═════════════════════╦════ ═════╦═════════╦═════════╗
║ rownum ║ on_row_data ║ off_row_data ║ file_id ║ page_id ║ slot_id ║
╠════════╬═════════════╬═════════════════════╬════ ═════╬═════════╬═════════╣
║ 1 ║ on_row_data ║ AAAAAAAAAAAAAAAAAAA ║ 3 ║ 105368 ║ 0 ║
╚════════╩═════════════╩═════════════════════╩════ ═════╩═════════╩═════════╝

同样，如果我使用，DBCC IND(database, table, index)我只会看到列出的两个页面：

DBCC IND (tempdb, t, 1);

输出：

╔═════════╦═════════╦════════╦════════╦═══════════ ═╦═════════╦═════════════════╦════════════════════ ═╦════════════════╦══════════╦════════════╦═══════ ══════╦═════════════╦═════════════╦═════════════╦═ ═╗
║ PageFID ║ PagePID ║ IAMFID ║ IAMPID ║ ObjectID ║ IndexID ║ PartitionNumber ║ PartitionID ║ iam_chain_type ║ PageType ║ IndexLevel ║ NextPageFID ║ NextPagePID ║ PrevPageFID ║ PrevPagePID ║ ║
╠═════════╬═════════╬════════╬════════╬═══════════ ═╬═════════╬═════════════════╬════════════════════ ═╬════════════════╬══════════╬════════════╬═══════ ══════╬═════════════╬═════════════╬═════════════╬═ ═╣
║ 1 ║ 1598 ║ NULL ║ NULL ║ 2069582411 ║ 1 ║ 1 ║ 6989586877272752128 ║ 行内数据 ║ 10 ║ NULL ║ 0 ║ 0 ║ 0 ║ 0 ║
║ 3 ║ 105368 ║ 1 ║ 1598 ║ 2069582411 ║ 1 ║ 1 ║ 6989586877272752128 ║ 行内数据 ║ 1 ║ 0 ║ 0 ║ 0 ║ 0 ║ ║
╚═════════╩═════════╩════════╩════════╩═══════════ ═╩═════════╩═════════════════╩════════════════════ ═╩════════════════╩══════════╩════════════╩═══════ ══════╩═════════════╩═════════════╩═════════════╩═ ═╝

如果我查看实际页面内容，使用DBCC PAGE，看起来我仍然看不到关于哪个页面包含 ROW_OVERFLOW_DATA 的任何信息 - 我确定它一定在那里，我可能只是不知道要看什么：

DBCC PAGE (tempdb, 3, 105368 , 3) WITH TABLERESULTS;

如果我包括内存转储行，结果太大而不适合这里，但这是标头输出：

╔══════════════╦════════════════════════════════╦═ ══════════════════════════════╦═══════════════════ ════════════╗
║ 父对象 ║ 对象 ║ 字段 ║ 值 ║
╠══════════════╬════════════════════════════════╬═ ══════════════════════════════╬═══════════════════ ════════════╣
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bpage ║ 0x000002431A8A2000 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bhash ║ 0x0000000000000000 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bpageno ║ (3:105368) ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bdbid ║ 2 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ 参考 ║ 0 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bcputicks ║ 0 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bsampleCount ║ 0 ║
║ 缓冲器： ║ BUF @0x000002437E86D5C0 ║ bUse1 ║ 63172 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bstat ║ 0x10b ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ 博客 ║ 0x212121cc ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bnext ║ 0x0000000000000000 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bDirtyContext ║ 0x000002435DA77160 ║
║ 缓冲区： ║ BUF @0x000002437E86D5C0 ║ bstat2 ║ 0x0 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_pageId ║ (3:105368) ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_headerVersion ║ 1 ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_type ║ 1 ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_typeFlagBits ║ 0x0 ║
║页眉：║页@0x000002431A8A2000║m_level║0║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_flagBits ║ 0xc000 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_objId (AllocUnitId.idObj) ║ 3920762 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_indexId (AllocUnitId.idInd) ║ 512 ║
║页眉：║页面@0x000002431A8A2000║元数据：AllocUnitId║144115445026914304║
║页眉：║页面@0x000002431A8A2000║元数据：PartitionId║6989586877272752128║
║ 页眉：║ 页 @0x000002431A8A2000 ║ 元数据：IndexId ║ 1 ║
║页眉：║页面@0x000002431A8A2000║元数据：ObjectId║2069582411║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_prevPage ║ (0:0) ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_nextPage ║ (0:0) ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ pminlen ║ 8 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_slotCnt ║ 1 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_freeCnt ║ 66 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_freeData ║ 8124 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_reservedCnt ║ 0 ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_lsn ║ (36:47578:1) ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_xactReserved ║ 0 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_xdesId ║ (0:0) ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ m_ghostRecCnt ║ 0 ║
║ 页眉： ║ 页@0x000002431A8A2000 ║ m_tornBits ║ 0 ║
║ 页眉： ║ 页 @0x000002431A8A2000 ║ 数据库片段 ID ║ 1 ║
║ 页眉： ║ 分配状态 ║ GAM (3:2) ║ 已分配 ║
║ 页眉： ║ 分配状态 ║ SGAM (3:3) ║ 未分配 ║
║ 页眉： ║ 分配状态 ║ PFS (3:105144) ║ 0x40 ALLOCATED 0_PCT_FULL ║
║ 页眉： ║ 分配状态 ║ 差异 (3:6) ║ 未更改 ║
║ 页眉： ║ 分配状态 ║ ML (3:7) ║ NOT MIN_LOGGED ║
║ PAGE HEADER: ║ Slot 0 Offset 0x60 Length 8028 ║ Record Type ║ PRIMARY_RECORD ║
║ PAGE HEADER: ║ Slot 0 Offset 0x60 Length 8028 ║ Record Attributes ║ NULL_BITMAP VARIABLE_COLUMNS ║
║ 页眉： ║ 槽 0 偏移量 0x60 长度 8028 ║ 记录大小 ║ 8028 ║
╚══════════════╩════════════════════════════════╩═ ══════════════════════════════╩═══════════════════ ════════════╝

考虑以下代码：

DECLARE @db sysname;
DECLARE @filename varchar(260);
DECLARE cur CURSOR LOCAL FORWARD_ONLY STATIC READ_ONLY
FOR
SELECT d.name
FROM sys.databases d;
OPEN cur;
FETCH NEXT FROM cur INTO @db
WHILE @@FETCH_STATUS = 0
BEGIN
    SET @filename = 'C:\temp\create_database_' + @db + '.txt';
    :setvar c @filename
    :out $(c)
    PRINT $(c);
    FETCH NEXT FROM cur INTO @db
END
CLOSE cur;
DEALLOCATE cur;

我期望在 中创建多个文件C:\temp，每个数据库一个，但没有创建任何文件，SQL Server 也没有报告错误。

我尝试使用 SQLCMD 模式在 SSMS 中运行它，我也尝试从 sqlcmd.exe 运行它