该文档包含有关如何删除 SQL Server 的说明。但是，这会留下某些包。如何删除所有痕迹并卸载 SQL Server 2017？

我昨天在我的 Ubuntu 16.04 机器上安装了 SQL Server v.Next 公共预览版并开始工作。但它今天不起作用。

得到以下错误：

root@OraServer:/var/opt/mssql/log# systemctl status mssql-server
? mssql-server.service - Microsoft(R) SQL Server(R) 数据库引擎
   已加载：已加载（/lib/systemd/system/mssql-server.service；已启用；供应商预设：已启用）
   活动：自 2016 年 11 月 27 日 13:34:23 IST 以来的不活动（死）（结果：退出代码）；18 秒前
  进程：6368 ExecStart=/opt/mssql/bin/sqlservr（代码=退出，状态=1/FAILURE）
 主PID：6368（代码=退出，状态=1/FAILURE）

11 月 27 日 13:34:23 OraServer systemd[1]：mssql-server.service：单元进入失败状态。
11 月 27 日 13:34:23 OraServer systemd[1]：mssql-server.service：失败，结果为“退出代码”。
11 月 27 日 13:34:23 OraServer systemd[1]：mssql-server.service：服务延迟时间结束，计划重启。
11 月 27 日 13:34:23 OraServer systemd[1]：停止 Microsoft(R) SQL Server(R) 数据库引擎。
11 月 27 日 13:34:23 OraServer systemd[1]：mssql-server.service：启动请求重复得太快。
11 月 27 日 13:34:23 …

在 SQL Server 2017 (CU3) 上，每当我在我的一个 TDE 数据库上启用备份压缩时，备份过程总是会损坏数据库中的特定页面。如果我在不压缩的情况下运行备份，它不会被损坏。以下是我为验证和重现此问题而采取的步骤：

1. 在数据库“TDE_DB1”上运行 DBCC CheckDB；一切都很好，没有错误；
2. 成功备份数据库，无需压缩；RESTORE VERIFYONLY 表示一切正常；
3. 成功将数据库恢复为“TDE_DB2”；一切都很好，DBCC CheckDB 没有显示错误；
4. 成功备份“TDE_DB1”数据库WITH压缩；RESTORE VERIFYONLY 错误，提示“检测到备份集损坏”；
5. 尝试将数据库恢复为“TDE_DB2”；错误，说“RESTORE 在数据库中的页面 (1:92454) 上检测到错误”
6. 重复步骤1-3；一切都很好;
7. 删除“TDE_DB1”和“TDE_DB2”；从备份中恢复“TDE_DB1”；一切都很好;
8. 重复步骤1-5；得到相同的结果；

总结一下：数据库和常规备份看起来不错，在数据库上运行 CHECKDB 并在备份上运行 VERIFYONLY 不会报告任何错误。使用压缩备份数据库似乎会导致损坏。

下面是有错误的代码示例。（注意：在 TDE 数据库中使用压缩需要 MAXTRANSFERSIZE）

-- Good, completes with no corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';


-- Bad, I …

这是对这个问题的跟进。这也与微软的这个功能请求有关。

然而，许多年过去了，自从它被报道以来，有几个主要版本进入了市场。

问题： SQL Server 2017 是否提供任何机制来轻松找出此错误的根本原因？还是像大约 9 年前报告该问题时一样难以调查？

我正在使用 physical_only 选项执行 checkdb 并且它失败并出现多个错误，如下所示：

Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 1557580587, index ID 1, partition ID 72057594088456192, alloc unit ID 72057594177454080 (type In-row data). The off-row data node at page (1:13282192), slot 3, text ID 6370769698816 is referenced by page (0:0), slot 0, but was not seen in the scan.
Msg 8965, Level 16, State 1, Line 1
Table error: Object ID 1557580587, index ID 1, partition ID 72057594088456192, alloc unit ID 72057594177454080 …

问题

我有一对查询，在可序列化隔离下，会导致 RX-X 锁定。但是，当我使用扩展事件查看锁获取时，RX-X 锁获取从未出现，它只是释放。它从何而来？

再现

这是我的表：

CREATE TABLE dbo.LockTest (
ID int identity,
Junk char(4)
)

CREATE CLUSTERED INDEX CX_LockTest --not unique!
ON dbo.LockTest(ID)

--preload some rows
INSERT dbo.LockTest
VALUES ('data'),('data'),('data')

这是我的问题批次：

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE

BEGIN TRAN

INSERT dbo.LockTest
VALUES ('bleh')

SELECT *
FROM dbo.LockTest
WHERE ID = SCOPE_IDENTITY()

--ROLLBACK

我检查了这个会话持有的锁，并看到了 RX-X：

SELECT resource_type, request_mode, request_status, resource_description
FROM sys.dm_tran_locks
WHERE request_session_id = 72 --change SPID!

但我在lock_acquired和上也有一个扩展事件lock_released。我在适当的 associated_object_id 上过滤它...没有 RX-X。

执行回滚后，我看到 RX-X (LAST_MODE) 被释放，即使它从未被获取。 …

我有一个性能问题，非常大的内存授予处理这个包含几NVARCHAR(4000)列的表。事情是这些列永远不会大于NVARCHAR(260).

使用

ALTER TABLE [table] ALTER COLUMN [col] NVARCHAR(260) NULL

导致 SQL Server 重写整个表（并在日志空间中使用 2 倍的表大小），这是数十亿行，只是什么都不改变，不是一个选项。增加列宽没有这个问题，但减少它。

我曾尝试创建约束CHECK (DATALENGTH([col]) <= 520)或CHECK (LEN([col]) <= 260)SQL Server 仍然决定重写整个表。

有没有办法将列数据类型更改为仅限元数据的操作？无需重写整个表？我使用的是 SQL Server 2017（14.0.2027.2 和 14.0.3192.2）。

这是用于重现的示例 DDL 表：

CREATE TABLE [table](
    id INT IDENTITY(1,1) NOT NULL,
    [col] NVARCHAR(4000) NULL,
    CONSTRAINT [PK_test] PRIMARY KEY CLUSTERED (id ASC)
);

然后运行ALTER.

如果我从 SQL Server 2016 实例备份数据库，然后将其还原到 2017 实例以对其进行一些工作。

然后我可以从 2017 年实例中转身并备份该数据库，并使用它来覆盖 2016 年实例上的原始版本吗？

看看这个查询。它非常简单（有关表和索引定义以及重现脚本，请参见文章末尾）：

SELECT MAX(Revision)
FROM dbo.TheOneders
WHERE Id = 1 AND 1 = (SELECT 1);

注意：“AND 1 = (SELECT 1) 只是为了防止此查询被自动参数化，我觉得这使问题变得混乱 - 尽管有或没有该子句，它实际上获得了相同的计划

这是计划（粘贴计划链接）：

由于那里有一个“top 1”，我很惊讶地看到流聚合运算符。对我来说似乎没有必要，因为保证只有一行。

为了测试这个理论，我尝试了这个逻辑上等效的查询：

SELECT MAX(Revision)
FROM dbo.TheOneders
WHERE Id = 1
GROUP BY Id;

这是那个计划（粘贴计划链接）：

果然，group by 计划能够在没有流聚合操作符的情况下通过。

请注意，两个查询都从索引的末尾“向后”读取并执行“前 1”以获得最大修订。

我在这里缺少什么？ 流聚合是否在第一个查询中真正起作用，还是应该能够消除它（这只是优化器的一个限制，它不是）？

顺便说一下，我意识到这不是一个非常实际的问题（两个查询都报告 0 毫秒的 CPU 和经过时间），我只是对这里展示的内部/行为感到好奇。

这是我在运行上述两个查询之前运行的设置代码：

DROP TABLE IF EXISTS dbo.TheOneders;
GO

CREATE TABLE dbo.TheOneders
(
    Id INT NOT NULL,
    Revision SMALLINT NOT NULL,
    Something NVARCHAR(23),

    CONSTRAINT PK_TheOneders PRIMARY KEY NONCLUSTERED …

我最近在一个有近 5 亿行的表中添加了一个可以为 NULL 的位列。列上没有默认值，但是所有插入都指定了 0 或 1 的值，我运行了一个一次性例程，将 0 或 1 分配给所有现有行（小批量更新行）。现在每一行在该列中都应该有一个 0 或 1。

我想让位列不可为空，但是当我尝试通过 执行此操作时ALTER TABLE t1 ALTER COLUMN c1 bit not null，它开始运行 3 分钟，然后我停止了它，因为它阻止了对表的所有读取，我怀疑它需要很长时间才能完成. 可能不会花太长时间，但我不能冒太多不可用的风险。回滚本身花了 6 分钟。

您对如何使列不可为空而不需要花费数小时才能完成有什么建议吗？ 此外，有什么方法可以估计ALTER TABLE ALTER COLUMN我开始然后取消的语句需要多长时间才能完成？

我使用的是 SQL Server 2017 网络版。