标签: sql-server

sql server上下文中的DOP是什么意思？

像 sa 这样的已知帐户名是否对数据库构成安全威胁？在 SQL Server 上使用 Windows 身份验证时，它是否强加了相同的密码策略（如果设置为 5 次后帐户锁定）？

据我所知，有三种可能的方式来备份您的 SQL Server 数据库

1. 完整备份
2. 差异备份
3. 日志传送

每种策略的优缺点是什么，应该在什么情况下使用？

我正在将 ReportServer 数据库的恢复模型从 FULL 更改为 SIMPLE。

是否有任何理由，为什么我不希望这样做？除了失去时间点恢复的明显答案？（反正我不会在这个数据库上做事务日志备份。）

我已经将动态 SQL 用于许多任务并不断遇到相同的问题：打印动态 T-SQL 语句中使用的变量的值。

例如：

Declare @SQL nvarchar(max), @Params nvarchar(max), @DebugMode bit, @Foobar int
select @DebugMode=1,@Foobar=364556423

set @SQL='Select @Foobar'
set @Params=N'@Foobar int'

if @DebugMode=1 print @SQL
exec sp_executeSQL @SQL,@Params
    ,@Foobar=@Foobar

上面代码的打印结果就是“Select @Foobar”。有没有办法动态打印正在执行的sql的值和变量名？或者在打印时，用实际值替换参数以便 SQL 可以重新运行？

我曾尝试创建一两个函数来完成类似的事情，但涉及数据类型转换、模式匹配截断问题和非动态解决方案。我很好奇其他开发人员如何在不手动打印每个变量的情况下解决这个问题。

我正在尝试找出提高非常慢查询性能的方法。它有更明显的问题，但我注意到的一件事是 WHERE 子句中的条件之一是 'AND t.data IS NOT NULL' 而表 t 的 'data' 列没有为 NULL 的条目并且确实有一个 NOT NULL 约束。

所以我想知道查询优化器是否能够忽略条件。我的想法是，它不能仅仅因为约束而这样做（因为不能保证它是否是用 NOVALIDATE 创建的），但可能足够“聪明”以使用有关列中 NULL 字段数量的统计信息。

我自己的测试是不确定的，我无法找到有关此主题的任何进一步信息。

我一直在使用旧提供程序 (SQLNCLI) 的链接服务器，没有任何问题，正如Microsoft推荐的那样，我计划切换到新提供程序 (MSOLEDBSQL)。安装驱动程序后，我可以使用以下 T-SQL 添加链接服务器

EXEC sp_addlinkedserver     
   @server=N'SQL02\DEV1',   
   @srvproduct=N'',  
   @provider=N'MSOLEDBSQL',   
   @datasrc=N'SQL02,1933';  

不幸的是，当我尝试查询新的链接服务器时出现以下错误：

我试过的查询：

--- example 1
select * from OPENQUERY ([SQL02\DEV1], 'select name from sys.databases');

--- example 2
select name from [SQL02\DEV1].master.sys.databases;


--- example 3 (without linked server dependency)
SELECT c.* FROM OPENROWSET(
      'MSOLEDBSQL'
    , 'Server=SQL02,1933;Database=master;Integrated Security=True;'
    , 'SELECT name FROM sys.databases;'
    ) c;

从所有示例中得到相同的错误：

不支持 OLE DB 提供程序“MSOLEDBSQL”与 SQL Server 的进程外使用。

这是否真的意味着 SQL-2016 不支持使用新的提供程序 MSOLEDBSQL，尤其是在链接服务器中，或者除了重新安装驱动程序和重新启动 SQL Server 之外，我还有什么遗漏。

这个问题带来了查询优化器在简单查询的现有谓词中选择不好的搜索谓词的情况。运行一些测试后，我得出的结论是，糟糕的决定是由于使用了本地临时表而不是全局临时表或常规表。

db fiddle：本地临时表、全局临时表、常规表。

我在临时表文档中找不到任何可以解释我们在使用本地临时表而不是全局临时表或常规表时看到的不同行为的特征。这有合乎逻辑的原因还是可能是错误？

我们有一个带有 Key Lookup 的查询，它估计每次执行有数千行。据我了解，每次执行应该只有一行。我知道统计数据可能会产生误导，但优化器不明白主键是唯一的吗？

此查询中涉及的表具有以下形式的聚集主键：

/****** Object:  Index [PK_Table_Name]    Script Date: 6/16/2021 9:52:12 AM ******/
ALTER TABLE [dbo].[Table_Name] ADD  CONSTRAINT [PK_Table_Name] PRIMARY KEY CLUSTERED 
(
    [Table_Name_ID] ASC
)WITH (STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GO

据我了解，主键提供了对表中单行的唯一引用。

因此，对于它在非聚集索引中找到的每一行，它应该能够使用该索引对聚集索引的引用来检索它所需的单行，以满足其正在处理的行的其余查询过滤。（这是一个嵌套循环连接运算符。）

那么为什么它估计将近 4000 行将作为 Key Lookup 的一部分返回？（不是“对于所有执行”，大约 36,000,000 是 4000 和它期望从非聚集索引查找中得到的 9000 行的乘积。）

运行时统计数据显示该聚集索引查找有 2851 行和 2851 次执行，这正是我所期望的。

如果有帮助，这是在 Azure SQL 数据库中，带有@@version：

Microsoft SQL Azure (RTM) - 12.0.2000.8 
    Apr 29 2021 13:52:20 …

我们的主数据库的大小已经减少了大约 8 GB。这反映在备份以及我们查看可用空间和可用空间时。

一切似乎都在工作，我们找不到任何数据丢失的迹象，但我们以前从未见过这种情况。我们有点担心可能会发生一些不愉快的事情。

谁能告诉我们 8 GB 的数据是如何消失的？如果这是一件正常的事情，我们想了解它是如何发生的，因为能够将数据库备份的大小减半实际上有点有用。

我们在 Windows Server 2019 上运行 SQL Server Enterprise 版本 14.0.3391.2

我们的主数据库每天午夜后备份。备份目标是本地磁盘。每次备份运行时，都会为每个数据库创建一个新文件。我们的恢复模式很简单。备份不会被压缩。至少在过去几年中，每个备份大约为 15 GB。自 6 月 11 日以来，文件大小已缩减至略高于 7 GB。

做一些研究，DBA StackExchange 上的一个线程与不小心在单个文件中创建多个备份的人有关。我RESTORE HEADERONLY FROM DISK对 6 月 10 日（15 GB）和 6 月 11 日（7 GB）的备份进行了测试。两者似乎都包含一个备份。我也没有看到任何其他值得注意的差异。

恢复数据库后，我观察到当前和恢复的数据库的总大小约为 30 GB。当前数据库上的可用空间约为 19 GB，而在恢复的数据库上约为 11 GB。8 GB 的差异，就像备份一样。我们的备份未压缩。

我们没有注意到我们的应用程序中缺少任何我们非常依赖的数据。我已经使用 SSDT 来比较当前数据库和恢复数据库中的架构和数据。

使用此数据库的应用程序正在不断开发中，因此在当前数据库中添加了一些列和表以支持新功能，但没有删除。

同样，在当前数据库中也有一些行被编辑或删除，但关联表在恢复的数据库中所占的比例远低于 100 MB，因此即使它们被完全删除，也不会导致大约 8 GB 的数据消失。

我们有一个人来开发应用程序。数据库管理由那个人和我共享。我们都不相信我们做了任何会导致这种变化的事情。

我们使用数据库的方式没有任何重大变化，如果有的话，备份应该变得更大。

我们是一家小公司，不太可能有人进行过数据清理。这也应该在 SSDT 的数据比较中显示出来。

我在日志文件中没有发现任何表明未经授权访问或备份失败的信息。

我目前正在从 6 月 11 日 (7 GB) 恢复备份，看看这是否能告诉我任何信息，尽管我并不期望从中获得太多见解。

我们不会自动删除备份，而是手动删除，这时我们发现了大小差异。

我不相信任何索引已被删除-有人对最佳检查方法有建议吗？碎片整理似乎是一个完全可能的原因 …