标签: sql-server

有没有人（内部？）了解备份压缩如何与 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 编写维护脚本吗？

这是我今天早些时候正在解决的一个问题，并最终找到了答案。不介意更好的东西，但想将它提供给同样需要的人。

首先，在 Azure VM 上，您可以免费获得一个 D:\ 驱动器，即 SSD。需要注意的是，当 VM 重新启动时，它通常会被破坏。MS 高写入量的最佳做法是将此驱动器用于 tempdb。他们没有讨论的是它没有被格式化为 64kb。隐藏的 pagefile.sys 驻留在此处，因此如果您尝试重新格式化（它会失败），则需要考虑到这一点。

从这里：https : //cloudblogs.microsoft.com/sqlserver/2014/09/25/using-ssds-in-azure-vms-to-store-sql-server-tempdb-and-buffer-pool-extensions/

您需要将他们的启动 powershell 脚本更改为更类似于下面的内容，我首先将页面文件完全删除，然后格式化为 64k，按照通常的脚本创建文件，然后在开始之前将 pagefile.sys 放回原处启动服务。

$SQLService=”SQL Server (MSSQLSERVER)”
$SQLAgentService=”SQL Server Agent (MSSQLSERVER)”
$tempfolder=”D:\SQLTEMP”
if (!(test-path -path $tempfolder)) {
    (Get-WmiObject -Class Win32_PageFileSetting).Delete() 
    Format-Volume -DriveLetter D -FileSystem NTFS -AllocationUnitSize 65536 -NewFileSystemLabel "Temporary Storage"  -Confirm:$false
    New-Item -ItemType directory -Path $tempfolder
    Set-WMIInstance -Class Win32_PageFileSetting -Arguments @{ Name = 'D:\pagefile.sys';} 
}
Start-Service $SQLService
Start-Service $SQLAgentService

有没有人有更好的东西或在这个过程中看到任何漏洞？

为了给其他人更多的自动化/帮助，我还编写了上面的脚本以及创建它的触发器，并在启动后使用下面的 30 秒运行它。这基本上允许某人自动执行我引用的 cloudblogs 文章中的步骤。

#1 - …

我们正在将客户从 SQL Server 2012 环境迁移到 2019。

我一直在尝试让日志像在旧环境中一样发送和运行，但我不断遇到错误。

我得到的第一个错误是在辅助服务器上的还原作业中：

2020-02-25 16:04:04.77  Skipped log backup file. Secondary DB: 'DB_Name', File: 'E:\LogShipping\DB_Name_20200225154501.trn'
2020-02-25 16:04:04.77  Error: Could not log history/error message. Microsoft.SqlServer.Management.LogShipping)
2020-02-25 16:04:04.77  Error: Failed to convert parameter value from a SqlGuid to a String.(System.Data) 
2020-02-25 16:04:04.77  Error: Object must implement IConvertible.(mscorlib) 

如果你用谷歌搜索，它会引导你到一个页面，建议修复是安装累积更新 2：https : //support.microsoft.com/sq-al/help/4537869/fix-log-shipping-agent-is-not -能够记录历史和错误信息

我尝试安装它，但立即开始注意到一个问题，当您打开作业活动监视器时，作业列表未加载，并且您收到一条错误消息，其中包含文本“无法检索此请求的数据”。您也无法为受影响的服务器执行诸如编辑日志传送计划之类的操作。在受影响的服务器上重新启动 SQL Server 代理之前，什么都不会起作用。如果检查作业历史记录，可以看到在 SQL Server 代理停止期间没有运行任何计划任务。SQL Server 代理似乎没有完全崩溃，这在某种程度上是一种耻辱，因为在这种情况下它应该重新启动。

搜索此错误会将您带到 dba.stackexchange.com 页面，该页面描述了相同的问题，唯一的解决方案是卸载 CU2。

我尝试卸载 CU2，但立即返回到原始错误消息。

这让我相信 SQL Server 2019 中的日志传送被破坏了。

真的有人成功使用过吗？

您是否遇到过这些问题中的任何一个并设法解决它们？

我应该在 2019 年考虑镜像还是复制，还是 …