标签: sql-server

我们最近将表转换为内存优化数据。我们的备份已经全部膨胀（3x300GB 文件到 3x600GB 的完整文件，3x50GB 到 3x250GB 的差异文件），并且启动越来越慢。

为了避免这些问题，我们将有问题的表转换为 SCHEMA_ONLY 持久性，但现在数据库不会离开“恢复中”状态。

错误日志最初每 20 秒更新一次恢复状态，预测分析需要大约 9 天才能完成，但是大约一个小时后，更新停止了。

SP_WHO2 显示只有一个进程使用命令访问有问题的数据库XTP_DB_RECOVERY，但不SELECT * FROM sys.dm_db_xtp_checkpoint_files返回任何行。

我有什么办法吗？或者如何查看此XTP_DB_RECOVERY命令的估计剩余时间？

有没有人（内部？）了解备份压缩如何与 SQL Server（2016+ 版）上的 TDE 配合使用。

一般来说，我认为压缩加密数据的好处很小，但是我们注意到，使用 TDE，当我们使用压缩进行完整备份时，我们仍然看到备份文件大小显着减少。这让我们怀疑备份过程是否会解密数据、压缩数据、加密结果，然后将其备份到磁盘。显然，由于需要解密和重新加密数据，这将增加备份过程的 CPU 消耗。

细节

select @@version

Microsoft SQL Server 2017 (RTM) - 14.0.1000.169 (X64) 2017 年 8 月 22 日 17:04:49 版权所有 (C) 2017 Microsoft Corporation Developer Edition（64 位），Windows 10 Enterprise 10.0（内部版本 17763：）（Hypervisor）

TSQL脚本

备份数据库 TestTDE 到磁盘 = 'c:\Test\TestTDE_Compressed.bak' WITH COMPRESSION, MAXTRANSFERSIZE = 65537

还是以不同的方式实现了空间节省？

我想知道我们需要为我的 PROD 数据库启用自动增长设置时需要考虑的因素。

我已经检查了数据库增长历史，并且数据库每天（平均）每天增长 1 到 1.5 GB。

当前数据库大小为 600 GB。此外，我检查了可用的可用空间，我们有足够的空间让文件增长。但是，如果我现在将自动增长设置为 1 GB，那么这个空间将在一段时间后被填满。

请建议我一些应该考虑的更多因素，以便我可以有效地利用这些可用的可用空间，从而消除至少 10-12 个月对新磁盘的需求。

如果一个存储过程（或视图）当前正在长时间运行的游标中使用，而我更改了该存储过程，游标是否会继续使用存储过程的旧实例，直到游标完成？

我最近查看了我的生产 SQL Server 的累积线程池等待时间，这确实是几天的等待时间。所以我开始做一些挖掘。

我在 32 核 64 位服务器上（在 EC2 上运行）。Max workers 在配置中正确设置为 0，以下 DMV 报告了正确的预期数字：

SELECT max_workers_count FROM sys.dm_os_sys_info

Output: 960

看看我的工人总数，我很少看到超过 300-400 的：

SELECT count(*) FROM sys.dm_os_workers

Output: 372

然而，如果我运行以下 DMV，我总是会列出线程：

SELECT * FROM sys.dm_os_waiting_tasks
WHERE wait_type = 'THREADPOOL'

SELECT dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine , [Num Workers] = COUNT(1) 
FROM sys.dm_os_workers dow 
GROUP BY dow.state , dow.is_preemptive , dow.is_sick , dow.is_in_polling_io_completion_routine;

以毫秒为单位的等待通常很短，一般为 20-200 毫秒，它们也很快消失，但它们增加了整体累积线程池数字。他们也从来没有阻塞会话。

当我有这么多可用的工作人员时，我很困惑为什么会遇到线程池等待。数百个可用的工作人员不应该在没有任何线程进入线程池的情况下立即处理这些请求吗？

我很感激这里的任何输入或方向。

SQL Server 版本：SQL Server 2016 (SP2-CU8) (KB4505830) …

我有一个奇怪的安全问题。我有一个用户在 SQL 2016 服务器上使用 SSMS 18.2。他们是 db_datareader 的成员，但是当他们在 Object Explorer Details 中拉出Row Count列时，它是空白的。尽我所知，它需要 DBO 才能显示行数。

具有读取权限的用户：

具有 dbo 访问权限的用户：

这是一个错误还是故意的？有谁知道是否有较低级别的权限可以提供此行数？我知道有很多其他方法可以获得行数，例如sys.partitions，但是用户坚持认为他们想要使用 OED 窗口。

有什么方法可以完全禁用 FT 日志？我花了几个小时谷歌搜索 - 没有运气。

我每秒钟都会收到大量的“信息”消息。

2020-01-01 10:43:16.48 spid33s     Informational: Full-text Auto population initialized for table or indexed view xxx
2020-01-01 10:43:23.48 spid34s     Informational: Full-text Auto population completed for table or indexed view zzz
2020-01-01 10:43:23.48 spid36s     Informational: Full-text Auto population completed for table or indexed view xxx
2020-01-01 10:43:24.64 spid12s     Informational: Full-text Auto population initialized for table or indexed view xxx
2020-01-01 10:43:25.64 spid12s     Informational: Full-text Auto population completed for table or indexed view xxx
2020-01-01 10:43:26.58 …

我在一家公司工作，该公司定期从客户那里接收大型 SQL 数据库备份以用于支持目的。我们支持多个 SQL 版本和排序规则，但目前必须手动确认我们客户端的 SQL 版本，然后才能恢复到正确的 SQL 实例。我想知道是否有办法自动化这个过程。

我期待：

1. 查找备份数据库的 SQL Server 版本（我们得到 2008 R2 以及 2014 和 2017）
2. 查找数据库的默认排序规则

无需完全恢复到可能不正确的 SQL 实例，由于其大小，这需要大量时间。（也许是零碎的恢复？）

据我所知，SQL Server系统数据库总是具有相同的 ID，而且我在 Internet 上看到许多维护脚本依赖谓词WHERE database_id > 4将它们从脚本的操作中排除。

另外，如果我SELECT name, schema_id FROM sys.schemas;在新的用户数据库上运行，我会得到：

name                 schema_id
dbo                  1
guest                2
INFORMATION_SCHEMA   3
sys                  4
db_owner             16384
db_accessadmin       16385
db_securityadmin     16386
db_ddladmin          16387
db_backupoperator    16389
db_datareader        16390
db_datawriter        16391
db_denydatareader    16392
db_denydatawriter    16393

我在两个不同的实例上运行了该查询，一个是 SQL Server 2016，另一个是 SQL Server 2005，并且都返回了相同的结果。

问题：

1. 是否有任何情况（或 sql server 版本）系统数据库 master、tempdb、model 和 msdb 的 database_id 分别不是 1、2、3、4？
2. 我真的可以相信我列出的架构在任何 SQL Server 实例上都具有相同的 ID，以便我可以根据这些 ID 编写维护脚本吗？

我有一个关于 SQL Server 的 UPDATE 语句的内部工作原理的问题。我试图了解如果同时收到或服务以下 2 个更新语句会发生什么：

 |    Session 1 - Statement 1 | Session 2 - Statement 2
 |   -------------------------+-------------------------
 |    update dbo.Table1       |  update dbo.Table1 
 |    set Value = 10          |  set Value = 20 
 |    where ID = 1            |  where ID = 1 
 ?    and Value = 0;          |  and Value = 0;
(t)

据我了解，更新将首先选择需要使用共享锁更新的行，这意味着两个更新语句都可以选择特定行。然后它请求一个排它锁来更新列值。因此，结果似乎将 Value 设置为 20。

我错过了什么还是我的理解正确？

连接的隔离级别设置为 READ UNCOMMITTED。