标签: sql-server

我希望能够运行查询以获取有关数据库状态的关键信息。即，我希望查询能够判断数据库是否处于良好状态。

这是我为此检查继承的查询：

SELECT name AS [SuspectDB],
  DATABASEPROPERTY(name, N'IsSuspect') AS [Suspect],
  DATABASEPROPERTY(name, N'IsOffline') AS [Offline],
  DATABASEPROPERTY(name, N'IsEmergencyMode') AS [Emergency],
  has_dbaccess(name) AS [HasDBAccess]
FROM sysdatabases
WHERE (DATABASEPROPERTY(name, N'IsSuspect') = 1)
   OR (DATABASEPROPERTY(name, N'IsOffline') = 1)
   OR (DATABASEPROPERTY(name, N'IsEmergencyMode') = 1)
   OR (has_dbaccess(name) = 0)

如果该查询返回任何结果，则假定数据库处于可疑或潜在的不良状态。

有一个更好的方法吗？

我们有一个非常大的数据库（~6TB），其事务日志文件被删除（SQL Server 关闭时。我们尝试过：

1. 分离和重新附加数据库；和
2. 取消删除事务日志文件

...但到目前为止没有任何效果。

我们目前正在运行：

ALTER DATABASE <dbname> REBUILD 
LOG ON (NAME=<dbname>,FILENAME='<logfilepath>')

...但考虑到数据库的大小，这可能需要几天时间才能完成。

问题

• 上面的命令和下面的命令有区别吗？

    DBCC CHECKDB ('<dbname>', REPAIR_ALLOW_DATA_LOSS)
  

  Run Code Online (Sandbox Code Playgroud)

• 我们应该执行REPAIR_ALLOW_DATA_LOSS吗？

值得注意的是，数据来自其他来源，因此可以重建数据库，但是我们怀疑修复数据库比再次重新插入所有数据要快得多。

更新

对于那些记分者：ALTER DATABASE/REBUILD LOG命令在大约 36 小时后完成并报告：

警告：数据库“dbname”的日志已重建。事务一致性已丢失。RESTORE 链被破坏，服务器不再拥有先前日志文件的上下文，因此您需要知道它们是什么。
您应该运行 DBCC CHECKDB 来验证物理一致性。数据库已置于 dbo-only 模式。当您准备好使数据库可供使用时，您将需要重置数据库选项并删除任何额外的日志文件。

然后我们运行了一个DBCC CHECKDB（大约需要 13 小时），它成功了。假设我们都了解了数据库备份的重要性（以及授予项目经理访问服务器的权限......）。

在 SQL Server 中，我总是发现获取数据集的最大行数很痛苦，我正在寻找一个方法列表来检索最大行数，并提供一些有关性能和可维护性的指导。

示例表：

DECLARE @Test TABLE (ID INT IDENTITY(1,1), name VARCHAR(50), 
                     dateOfBirth DATETIME, TaxNumber varchar(10))

INSERT INTO @Test (name, dateOfBirth, TaxNumber)
SELECT 'Fred', convert(datetime, '25/01/1976', 103), '123' UNION ALL
SELECT 'Bob', convert(datetime, '03/03/1976', 103), '234'  UNION ALL
SELECT 'Jane', convert(datetime, '13/06/1996', 103), '345' UNION ALL
SELECT 'Fred', convert(datetime, '14/02/1982', 103), '456' UNION ALL
SELECT 'Bob', convert(datetime, '25/10/1983', 103), '567' UNION ALL
SELECT 'Jane', convert(datetime, '12/04/1995', 103), '678' UNION ALL
SELECT 'Fred', convert(datetime, '03/03/1976', 103), '789'

select * from …

当我注意到我的一些插入花费的时间比预期的要长时，我正在做一个涉及 CCI 的演示。要重现的表定义：

DROP TABLE IF EXISTS dbo.STG_1048576;
CREATE TABLE dbo.STG_1048576 (ID BIGINT NOT NULL);
INSERT INTO dbo.STG_1048576
SELECT TOP (1048576) ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) RN
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

DROP TABLE IF EXISTS dbo.CCI_BIGINT;
CREATE TABLE dbo.CCI_BIGINT (ID BIGINT NOT NULL, INDEX CCI CLUSTERED COLUMNSTORE);

对于测试，我将从临时表中插入所有 1048576 行。只要它没有因某种原因被修剪，这就足以填充一个压缩的行组。

如果我插入所有整数 mod 17000，它需要不到一秒钟的时间：

TRUNCATE TABLE dbo.CCI_BIGINT;

INSERT INTO dbo.CCI_BIGINT WITH (TABLOCK)
SELECT ID % 17000
FROM dbo.STG_1048576
OPTION (MAXDOP 1);

SQL Server 执行时间：CPU 时间 = 359 …

在我们的数据库中，我们有多个带有 caron/hatschek 的条目。现在我们的用户希望在搜索没有的条目时找到包含 caron/hatschek 的条目。我将通过一个简单的例子来说明这一点：

在我们的数据库中，我们有条目（联系人姓名）

Millière

所以这个名字在这个人居住的国家是正确的。

在我们国家，我们没有任何带有 caron/hatschek 的字符，因此我们的用户搜索Milliere. 没有结果出现，因为è显然不匹配e。

我不知道这是如何实现的，因为é, è，ê还有更多可用的（这只是字母的一个例子e......）。

（另一种方法会容易得多，因为我可以简单地将所有带有 caron/hatschek 的字母替换为基本字母。显然，我们的用户确实想要数据库中名称的正确版本，而不是残缺的名称。）

鉴于此表：

CREATE TABLE test (
    id INT NOT NULL,
    description NVARCHAR(100) COLLATE Modern_Spanish_CI_AS NOT NULL
);
INSERT INTO test (id, description) VALUES (1, 'CO2');

我意识到我无法解决排版问题：

SELECT * FROM test WHERE id = 1;
UPDATE test SET description = 'CO?' WHERE id = 1;
SELECT * FROM test WHERE id = 1;

因为更新匹配但没有效果：

id          description
----------- -----------
1           CO2

(1 affected rows)

(1 affected rows)

id          description
----------- -----------
1           CO2

(1 affected rows)

就好像 SQL Server 确定了这一点，因为? 显然只是一个很小的2 …

我们有运行 SQL Server（2008 SP4 和 2016 SP1）的 PC，它们经常断电。显然，这有时会导致 SQL Server 数据库的（索引）损坏，我们需要稍后恢复。

我知道 SQL Server 不是为这种情况设计的，正确的解决方案是修复断电的原因（如果您好奇，请在下面详细介绍）。尽管如此，我可以设置 SQL Server 中的任何调整选项来降低断电时数据库损坏的风险吗？

背景：“PC”是安装在叉车上的 Windows 平板电脑。当用户关闭叉车时，平板电脑就会断电。我们曾尝试教用户在关闭叉车之前正确关闭 Windows，但失败了（可能是因为在大多数情况下只是将其关闭“有效”）。我们目前还在研究其他选项，例如添加一个 UPS，它会在断电时向平板电脑发出信号关闭。

从其他编程语言转向 SQL，递归查询的结构看起来很奇怪。一步步走过来，仿佛分崩离析。

考虑以下简单示例：

CREATE TABLE #NUMS
(N BIGINT);

INSERT INTO #NUMS
VALUES (3), (5), (7);

WITH R AS
(
    SELECT N FROM #NUMS
    UNION ALL
    SELECT N*N AS N FROM R WHERE N*N < 10000000
)
SELECT N FROM R ORDER BY N;

让我们来看看吧。

首先，执行锚成员并将结果集放入 R。因此 R 被初始化为 {3, 5, 7}。

然后，执行低于 UNION ALL 并且第一次执行递归成员。它在 R 上执行（即，在我们目前手头的 R 上：{3, 5, 7}）。这导致 {9, 25, 49}。

这个新结果有什么用？它是否将 {9, 25, 49} 附加到现有的 {3, 5, 7}，标记结果联合 R，然后从那里继续递归？或者它是否将 R 重新定义为这个新结果 {9, 25, 49} 并在以后进行所有联合？

两种选择都没有意义。 …

SQL Server 2019 CTP 2.3 向 sys.databases 添加了一些新列，包括 is_result_set_caching_on：

SQL Server 2019 的新增功能和ALTER DATABASE 页面中尚未记录。

我尝试使用与加速数据库恢复相同的语法只是为了笑：

ALTER DATABASE StackOverflow2013 SET RESULT_SET_CACHING ON;

但没有运气：

Msg 5058, Level 16, State 12, Line 8
Option 'RESULT_SET_CACHING' cannot be set in database 'StackOverflow2013'.

我需要截断一个包含 170 亿行的表，该表位于作为 AG 一部分的数据库中。

此操作对 AG 延迟和日志备份大小有什么影响？

有推荐的方法吗？