标签: sql-server

我们有一些数据库有宽表COLUMNSTORE压缩（21 或 30 COLUMNS）和 2500 个分区（按日期）。该数据库中大约有 4000 个 stats 对象，其中大部分是分区表上的 INCREMENTAL 列统计信息。

sys.dm_db_stats_properties在这些数据库上运行时，这个表函数的性能极差。我们正在查看每行大约 1 秒 - 即此表函数的每次“运行”。

下面是一个简单查询生成的查询计划示例，其CROSS APPLY语法用于针对 1605 个 stats-table 组合执行此表函数。

这里没有什么非常有帮助的 - DMV 的表现显然很差。

我目前的理论是，由于数据库中统计对象的性质，对 OPENROWSET 内部表的查询优化不佳（可能是TOP 1，这就是导致速度变慢的原因。

CREATE FUNCTION sys.dm_db_stats_properties (@object_id int, @stats_id int)
RETURNS TABLE
AS
RETURN SELECT TOP 1 -- The first row in the TVF will be the root; avoid scanning entire TVF to find any additional rows.
    object_id, -- Columns now explicit since underlying tvf …

四天前，一个用户在一个有 400,000,000 行的表上运行了下面的命令。它仍在运行，日志文件的大小也在增加。

delete from [table-name]

该表确实有一个未启用检查的外键约束，我知道另一个表中不存在任何行。

数据库正在启用“Is Read Committed Snapshot On”并处于简单恢复模式下运行。

在这运行了几个小时之后，我发出了一个终止会话命令，因为我们的日志文件磁盘空间不足。我添加了另一个日志文件以允许系统继续运行。

日志文件继续增长，当我使用 statusonly 运行 kill session 时，它返回此消息：

SPID 123: transaction rollback in progress. Estimated rollback completion: 0%. Estimated time remaining: 0 seconds.

我不知道如何处理这个查询以使其回滚并且也只是了解正在发生的事情，任何人都可以建议我可以查看什么？

我的数据库目前被隔离在它自己的实例和 VM 中。我的客户正在淘汰该服务器，我需要将数据库迁移到新环境。我的数据库使用 CLR，所以新环境需要启用它。

客户建议使用现有服务器和现有 SQLServer 2014 标准实例托管来自其他软件供应商的数据库。我担心会产生一种“你破坏它，你买了它”的责任，因为我不能保证其他数据库或其前端的安全策略。我不想做会带来重大风险的事情。

我不时遇到与其他客户类似的情况。我是一名数据库开发人员。我偶尔会为我的中小型企业客户提供与我自己的产品相关的 DBA 服务，但我绝不是一名熟练的 DBA。每个客户都有不同的预算、优先级、IT 人员和安全策略，但通常他们都没有 IT/DBA 可以理解和/或在此详细级别进行称职的风险评估。

在共享实例上启用 CLR 会如何影响其他 DB 的安全性？（我不是在询问数据库级别的权限集级别，只是启用 CLR 本身）。我需要充分了解风险（如果有的话），以便能够建议“最佳实践”和特定于客户的“足够安全”的替代方案。

这里我们有两个类似的查询，使用grouping sets whereSELECT子句包含一些在聚合中计算的表达式：

SELECT RN10, RN10 / 10, COUNT(*) FROM 
(
       SELECT RN, RN/10 AS RN10, RN/100 AS RN100 FROM 
       (
               SELECT RN = -1 + ROW_NUMBER() OVER (ORDER BY 1/0) 
               FROM master..spt_values
       ) A
) B
GROUP BY GROUPING SETS ((RN10), (RN10 / 10), ())
ORDER BY 1, 2

它的计划在这里：第一个查询计划

和

SELECT RN10, SUBSTRING(RN,3,99), COUNT(*) FROM 
(
       SELECT RN, SUBSTRING(RN,2,99) AS RN10 FROM 
       (
               SELECT RN = CAST(-1 + ROW_NUMBER() OVER (ORDER BY 1/0) AS …

我在 Mac 上的 docker 中运行 SQL Server。我从 Windows 中获取了 SQL Server 备份，并在 mac SQL Server docker 实例中恢复了它。现在我想从 SQL Server docker 实例中进行备份并将其恢复回 Windows。当我尝试在 Windows 上恢复时，我收到“系统表 sysfiles1 已损坏”。是否可以从 SQL Server Linux 进行备份并在 SQL Server Windows 上恢复它？

我们正在考虑在应用程序中保存记录历史的不同方法。

部分负责人担心，这是SQL server比较新的特性，微软可能会停止支持。

这些担忧是否合理？
是否有此功能的路线图，说明 Microsoft 打算在未来使用此功能做什么？

我有一个关于 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。

我们有一个场景，我们希望将生产数据库（包括列）的排序规则从 SQL_Scandinavian_Pref_CP850_CI_AS 更改为 Finnish_Swedish_CI_AS。我们已经开发了脚本来做到这一点。但是在超过 100GB 的大型数据库中执行此脚本将需要相当长的时间，而且我们不能承受很长时间的停机时间。因此，我们决定使用以下策略来减少停机时间：

1. 我们将设置事务复制，我们将使用数据库备份方法初始化订阅者。
2. 发布者数据库将与应用程序一起使用，其事务将通过事务复制传递到订阅者数据库。
3. 我们将在订阅者端执行排序规则更改脚本，当 SQL Server 对发布者和订阅者数据库相同时，它确实允许我们执行此脚本。我们最近在 SQL Server 2019 中发现了这一点。
4. 现在，痛点是，当 varchar、char 列的数据包含诸如“åÅääÄöÖ”之类的特殊字符时，它无法正确复制。在订阅者方面，我们收到了像“†„Ž”™“这样的奇怪字符

您能否建议我们如何解决此错误或任何替代架构，以在更改数据库排序规则（包括列）时最大限度地减少生产停机时间？

此外，我的排序规则更改脚本正在订阅者数据库上执行以下任务以更改其排序规则：

1. 删除外键约束
2. 删除包括主键在内的索引
3. 删除检查和默认约束
4. 删除用户统计
5. 删除视图、计算列、SP 以解决对象绑定错误
6. 执行上述步骤后，表已准备好进行整理更改。因此，脚本将一一更改每个表的列的排序规则。
7. 成功执行第 6 步后，重新创建上面列出的约束。

在阅读了一篇日期为2012年的关于未记录的函数fn_dblog 和 fn_dump_dblog的文章后，我想知道如果它们已经存在很长时间并且非常有用，为什么它们仍然未记录且不受支持。与这篇2004 年的sp_msforeachtable 和 sp_msforeachdb文章相同。