小编She*_*ola的帖子

数据库 SQL Server 2017 Enterprise CU16 14.0.3076.1

我们最近尝试从默认的 Index Rebuild 维护作业切换到 Ola Hallengren IndexOptimize。默认的索引重建作业已经运行了几个月没有任何问题，并且查询和更新的执行时间在可接受的范围内。在IndexOptimize数据库上运行后：

EXECUTE dbo.IndexOptimize
@Databases = 'USER_DATABASES',
@FragmentationLow = NULL,
@FragmentationMedium = 'INDEX_REORGANIZE,INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationHigh = 'INDEX_REBUILD_ONLINE,INDEX_REBUILD_OFFLINE',
@FragmentationLevel1 = 5,
@FragmentationLevel2 = 30,
@UpdateStatistics = 'ALL',
@OnlyModifiedStatistics = 'Y'

性能极度下降。之前花费 100 毫秒的更新语句在之后IndexOptimize花费了 78.000毫秒（使用相同的计划），并且查询的性能也差了几个数量级。

由于这仍然是一个测试数据库（我们正在从 Oracle 迁移生产系统），我们恢复到备份并禁用IndexOptimize，一切恢复正常。

但是，我们想了解什么IndexOptimize与Index Rebuild可能导致这种极端性能下降的“正常”不同，以确保我们在投入生产后避免这种情况。任何关于寻找什么的建议将不胜感激。

更新语句缓慢时的执行计划。即
IndexOptimize 之后的
实际执行计划（即将推出）

我一直无法发现差异。
快速时为同一个查询做
计划 实际执行计划

我一直在使用旧提供程序 (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 之外，我还有什么遗漏。

我正在运行带有 SQL Server 实例的云 VPS。因为它是供个人使用的，所以我使用的是 express 版（我不能使用开发者版，因为我在技术上运行了生产应用程序，而且我买不起 Standard+）。

我正在尝试使用Brent Ozar 的教程使用sp_BlitzFirst. 我遇到的问题是，无论当时的实际 CPU 使用情况如何，ProcessUtilizationinsys.dm_os_ring_buffers总是100以 形式出现。

虚拟机信息

@@version： Microsoft SQL Server 2017 (RTM-CU15) (KB4498951) - 14.0.3162.1 (X64) May 15 2019 19:14:30 版权所有 (C) 2017 Microsoft Corporation Express Edition（64 位）Linux (Ubuntu 18.04) .2 LTS)

主机： 1 & 1 Ionos VPS

lscpu 输出

Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              2
On-line CPU(s) list: 0,1
Thread(s) per …

Run Code Online (Sandbox Code Playgroud)

我对我的一项发现感到惊讶，即使用 aFORMAT ()确实对行大小和数据大小有很大影响。它几乎是不应用的大小的 250 倍FORMAT ()。

我的问题是：
1）为什么使用FORMAT()对大小有这么大的影响？对我来说，只有 1.23 美元与 1.23 美元的差异，这可能是 1 个字符的差异。这么大的尺寸有关系吗？

2) 为什么我们仍然鼓励FORMAT()在 SQL Server 中使用而不是使用字符串连接，如下所示。由于下面只有 2 倍的数据大小，使用格式返回 250 倍的数据大小。或者数据大小不是一个关键的衡量标准？

SELECT '$' + CONVERT(varchar(10), UnitPrice) FROM Sales.SalesOrderDetail;

3) 数据大小为 464MB 是否意味着我将向客户端返回 464MB 的数据？

================================================== ======

以下是我对 AdventureWorks2012 数据库的发现。

SELECT UnitPrice FROM Sales.SalesOrderDetail;

实际行
数：121317
估计行数：121317估计行大小：15B
估计数据大小：1777KB

SELECT '$' + CONVERT(varchar (10), UnitPrice) FROM Sales.SalesOrderDetail;

实际行数：121317
估计行大小：26B
估计数据大小：3060KB

SELECT FORMAT(UnitPrice, 'c') FROM Sales.SalesOrderDetail;

实际行数：121317
估计行大小：4011B
估计数据大小：464MB

我目前正在调查一个应用程序，该应用程序似乎针对它正在查询的数据库生成 99% 的即席查询计划。我可以通过运行以下语句来检索查询计划缓存中的对象摘要来验证这一点：

_{抱歉无法在 SE 编辑器中输入代码，因此截图}

^{参考：计划缓存和优化临时工作负载(SQLSkills.com / K. Tripp) 稍作修改}

上述查询的结果如下：

CacheType            Total Plans          Total MBs                               Avg Use Count Total MBs - USE Count 1                 Total Plans - USE Count 1
-------------------- -------------------- --------------------------------------- ------------- --------------------------------------- -------------------------
Adhoc                158997               5749.520042                             2             2936.355979                             126087
Prepared             1028                 97.875000                               695           46.187500                               576
Proc                 90                   69.523437                               39659         21.187500                               21
View                 522                  75.921875                               99            0.453125                                3
Rule                 4                    0.093750                                22            0.000000                                0
Trigger              1                    0.070312                                12            0.000000                                0    

在计划缓存中的 158'997 个即席查询中，126'087 个查询只执行了一次。 …

哪个查询更快：

查询 A

SELECT I.ItemName
FROM Location L
INNER JOIN Items I ON I.LocationID = L.LocationID
WHERE L.LocationID = 1

执行计划

查询 B

SELECT ItemName
FROM Items 
WHERE ItemID IN (
SELECT ItemID
FROM  Items
WHERE LocationID = 1)

执行计划

我最近开始使用包含的数据库，但我不明白包含的数据库用户是否/如何拥有过期的密码。

MSDN 文档说他们这样做 - 使用 SQL Server 登录，有强制密码过期的选项框，但对于包含的数据库用户来说，这不存在（据我所知）。

这些包含的数据库帐户已经存在一段时间了，我们的域策略是每 6 个月重置一次密码，但我们从未更改过这些密码，而且应用程序在过去几年中使用相同的密码连接得很好。

我的第一个问题是我怎么知道对包含的数据库用户强制执行“密码过期”？对于 SQL 登录is_expiration_checked，sys.sql_logins.

使用传统的 SQL 登录，我可以使用以下函数来获取更改 SQL Server 登录的时间

LOGINPROPERTY('login','PasswordLastSetTime')  

包含的数据库用户是否有类似的东西？

我们有一个大型数据库（500GB 并且正在扩展）。95% 以上的数据存储在 3 个表中（一个表有 20 亿多行）。数据在很大程度上是不可变的 - 即一旦添加，它就只能在之后读取。我们无法存档旧数据。

我们正在使用允许压缩备份的 SQL Server 2017，但即便如此，备份和通过网络复制到备份服务器也需要很长时间。

我们想加快这个过程（并且出于灾难恢复目的，在云中备份 - 可能是 Azure） - 差异备份足够小，但我认为我们仍然需要定期进行完整备份（例如每个周末完整备份）每晚的差异对我们来说仍然是一个问题）

我的感觉是使用分区来分割一些合理列上的大表（集群在身份 ID 上），然后我们可以只备份旧分区一次并将它们标记为只读，而无需再次全部备份。

这不是一个理想的情况，因为我们将来需要不断添加更多分区。此外，数据库无法关闭超过几分钟，所以我想我将不得不使用分区制作数据的影子版本，然后进行一些切换，以减少停机时间，这有点冒险和复杂。

如果有人对这种数据库配置有他们认为会更好的备份策略（或者可以确认考虑到我的限制，这似乎是一个好主意）我很高兴听到:)

附加信息：

当前备份计划：

1. 完整备份（每晚） - 压缩备份大约100 GB（500 GB 未压缩），大约需要40 分钟（压缩）

2. 日志备份（每 10 分钟） - 几乎是即时的，每个只有大约 20 MB。

现在我知道，对于某些人来说，40 分钟并不是很长的时间，100 GB 也不是一个很大的文件，但我也知道，鉴于 95% 以上的数据是不可变的，并且只能安全备份一次，备份可能需要不到几分钟的时间，并且可能需要几 GB（这是保守的）。

我相信分区是用于帮助管理备份的工具之一，特别是对于这种类型的场景，我希望让有实际经验的人（或我的场景中基于 SQL Server 的替代方案）能够说明一些问题什么对他们有用。

我们有许多日志传送的 SQL 2017 数据库，我们希望以 15 分钟的时间表开始使用 Microsoft Azure 备份服务器（本地和云）进行备份。

有谁知道 Azure 备份服务器是否可以挂钩 SQL Server 日志传送所做的日志备份？

我有 Windows Server 2016 和 SQL Server 2017，发现 Windows 日志应用程序充满了登录失败消息（如下）：

用户“sa”登录失败。原因：密码与提供的登录密码不匹配。[客户： ****]

客户端的IP地址多种多样。我在 SQL Server 中没有任何维护计划

有什么问题？

我正在阅读 Carter 的“Pro SQL Server 2019 Administration”一书，在详细介绍 HA 和 DR 选项时，没有提到“复制”：

为什么省略？复制会很快被弃用吗？

我有一个 .net 应用程序。它试图创建表、视图并将数据插入/更新到许多表中。应用程序运行时出现错误。

我尝试在 SQL Profiler 中跟踪查询，但没有发现任何错误。有什么方法可以跟踪错误语句，或者我需要在探查器中添加任何其他事件。

我已经尝试过以下事件（例外）：

• RPC：已完成
• RPC：开始
• SP：开始
• SP：已完成
• SP：开始
• SP：StmtCompleted
• SQL：批量启动
• SQL：批量完成