标签: system-tables

由于一些“开发人员”，我们在我们的系统上工作，我们遇到了空表的问题。我们发现在传输到云端的过程中，有几个表被复制了，但其中的数据没有。

我想运行一个查询系统表来查找哪些用户表是空的。我们使用的是 MS SQL 2008 R2。

谢谢您的帮助。

我已将一个数据库导入 SSDT，其中包含对系统视图（特别是 sys.columns）的引用。问题是，当我构建项目时，我会收到有关未解析引用的警告

从我在 MSDN 论坛上看到的情况来看，它看起来可能是一个已知问题：http : //social.msdn.microsoft.com/Forums/en-US/ssdsgetstarted/thread/5a7026bd-0602-42e6-a639- d73bed903c26

现在，我知道我可以关闭警告或忽略它，但是有人知道实际的解决方案吗？

谢谢

谁能解释下面的情况，其中两个看似相等的值没有减少DISTINCT？

上面的查询是SELECT DISTINCT name FROM master.sys.dm_os_spinlock_stats where name = 'SBS_UCS_DISPATCH';

等效方法SELECT name FROM master.sys.dm_os_spinlock_stats where name = 'SBS_UCS_DISPATCH' GROUP BY name;也执行相同的操作，并且添加HAVING COUNT(1) > 1不会产生行。

@@VERSION是Microsoft SQL Server 2019 (RTM-CU13) (KB5005679) - 15.0.4178.1 (X64) 2021 年 9 月 23 日 16:47:49 版权所有 (C) 2019 Microsoft Corporation 企业版：Windows Server 上基于核心的许可（64 位） 2016 标准 10.0（内部版本 14393：）

我们有几个数据库，其中创建和删除了大量表。据我们所知，SQL Server 不对系统基表进行任何内部维护，这意味着它们会随着时间的推移变得非常碎片化并变得臃肿。这会给缓冲池带来不必要的压力，也会对计算数据库中所有表的大小等操作的性能产生负面影响。

有没有人建议尽量减少这些核心内部表上的碎片？一个明显的解决方案可以避免创建如此多的表（或在 tempdb 中创建所有临时表），但对于这个问题，我们假设应用程序没有这种灵活性。

编辑：进一步的研究显示了这个悬而未决的问题，它看起来密切相关，并表明某种形式的手动维护ALTER INDEX...REORGANIZE可能是一种选择。

初步研究

可以在以下位置查看有关这些表的元数据sys.dm_db_partition_stats：

-- The system base table that contains one row for every column in the system
SELECT row_count,
    (reserved_page_count * 8 * 1024.0) / row_count AS bytes_per_row, 
    reserved_page_count/128. AS space_mb
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID('sys.syscolpars')
    AND index_id = 1
-- row_count:       15,600,859
-- bytes_per_row:   278.08
-- space_mb:        4,136

但是，sys.dm_db_index_physical_stats似乎不支持查看这些表的碎片：

-- No fragmentation data is returned by sys.dm_db_index_physical_stats
SELECT *
FROM …

背景：
我有许多带有大量 VIEW 和大量 SYNONYM 的数据库。例如，一个数据库有超过 10k 的 VIEW's 和 2+ 百万的 SYNONYM's。

一般问题：
涉及sys.objects（和一般系统表）的查询往往很慢。涉及sys.synonyms的查询是冰川。我想知道我可以做些什么来提高性能。

具体示例
此命令由第三方工具运行。它在应用程序和 SSMS 中都很慢：

exec sp_tables_rowset;2 NULL,NULL

我的问题：
我怎样才能让它运行得更快？

我试过的：
如果SET STATISTICS IO ON我得到这个输出：

（2201538 行受影响）
表“sysobjrdb”。扫描计数 1，逻辑读取 28，物理读取 0，预读读取 0，lob 逻辑读取 0，lob 物理读取 0，lob
预读读取 0。表 'sysschobjs'。扫描计数1，逻辑读53926，物理读0，预读0，lob逻辑读0，lob物理读0，lob预读0。

我已经能够更新底层系统表的统计信息。这在我的 SQL 2008 R2 或更新的环境中有效：

UPDATE STATISTICS sys.sysobjrdb WITH FULLSCAN
UPDATE STATISTICS sys.sysschobjs WITH FULLSCAN

我还能够执行索引维护。这适用于我的 SQL 2012 或更新的环境。例如运行sp_help 'sys.sysschobjs'标识表上的索引，然后我从那里创建并运行这些命令：

ALTER INDEX clst ON sys.sysschobjs REORGANIZE
ALTER …

我从一开始说，我的问题/问题类似于此之前的一个，但因为我不知道的原因或起始信息是一样的，我决定后，我的问题有一些更多的细节。

手头问题：

• 在一个奇怪的时间（接近工作日结束），一个生产实例开始出现异常行为：
  • 实例的高 CPU（从大约 30% 的基线增加到大约两倍并且仍在增长）
  • 增加的事务数/秒（尽管应用程序负载没有看到任何变化）
  • 增加空闲会话数
  • 从未显示此行为的会话之间的奇怪阻塞事件（即使读取未提交的会话也会导致阻塞）
  • 间隔的顶部等待是非页面闩锁排在第一位，锁排在第二位

初步调查：

• 使用 sp_whoIsActive 我们看到我们的监控工具执行的查询决定运行速度极慢并占用大量 CPU，这是以前从未发生过的；
• 其隔离级别未提交读取；
• 我们查看了我们看到古怪数字的计划：StatementEstRows="3.86846e+010" 有大约 150 TB 的估计数据要返回
• 我们怀疑是监控工具的查询监控功能造成的，所以我们禁用了该功能（我们还向我们的提供商开了一张票，以检查他们是否知道任何问题）
• 从第一个事件开始，它又发生了几次，每次我们终止会话，一切都会恢复正常；
• 我们意识到该查询与MS 在 BOL 中用于查询存储监控的查询之一极为相似- 最近性能下降的查询（比较不同时间点）
• 我们手动运行相同的查询并看到相同的行为（CPU 使用不断增加，增加闩锁等待，意外锁定......等）

有罪查询：

Select qt.query_sql_text, 
    q.query_id, 
    qt.query_text_id, 
    rs1.runtime_stats_id AS runtime_stats_id_1,
    interval_1 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi1.start_time), 
    p1.plan_id AS plan_1, 
    rs1.avg_duration AS avg_duration_1, 
    rs2.avg_duration AS avg_duration_2,
    p2.plan_id AS plan_2, 
    interval_2 = DateAdd(minute, -(DateDiff(minute, getdate(), getutcdate())), rsi2.start_time), 
    rs2.runtime_stats_id AS runtime_stats_id_2
From sys.query_store_query_text AS qt 
Inner Join sys.query_store_query AS …

我正在尝试缩小数据库文件，但遇到了错误。

使用sys.database_files作品中的 file_id ，但使用逻辑文件名会产生错误。

两个语句中的逻辑文件名相同，所以这不是问题。此外，正在连接的数据库是相同的。以下按预期工作：

declare @fileId as int = (select file_id from sys.database_files where name = 'XY')
DBCC SHRINKFILE (@fileId, 0, TRUNCATEONLY)

然而以下...

DBCC SHRINKFILE ('XY' , 0, TRUNCATEONLY)

...将导致错误 8985：

消息 8985，级别 16，状态 1，第 1 行
无法在 sys.database_files 中找到数据库“<我的数据库>”的文件“XY”。该文件要么不存在，要么已被删除。

给定一个 SourceTable 和一个 TargetTable，我想以编程方式创建一个需要所有连接的字符串。

简而言之，我试图找到一种方法来创建这样的字符串：

FROM SourceTable t
JOIN IntermediateTable t1 on t1.keycolumn = t.keycolumn
JOIN TargetTable t2 on t2.keycolumn = t1.keycolumn

我有一个查询返回给定表的所有外键，但是在尝试递归运行所有这些以找到最佳连接路径并生成字符串时遇到了限制。

SELECT 
    p.name AS ParentTable
    ,pc.name AS ParentColumn
    ,r.name AS ChildTable
    ,rc.name AS ChildColumn
FROM sys.foreign_key_columns fk
JOIN sys.columns pc ON pc.object_id = fk.parent_object_id AND pc.column_id = fk.parent_column_id 
JOIN sys.columns rc ON rc.object_id = fk.referenced_object_id AND rc.column_id = fk.referenced_column_id
JOIN sys.tables p ON p.object_id = fk.parent_object_id
JOIN sys.tables r ON r.object_id = fk.referenced_object_id
WHERE fk.parent_object_id = OBJECT_ID('aTable')
ORDER …

在这个问题中，我正在使用sys.sysobjects. 但是，提到的答案之一sys.system_objects。我只是想知道这些表之间有什么区别？

• sys.objects
• sys.system_objects
• sys.sysobjects

sysobjects 有更多的东西。

> SELECT count(*) FROM sysobjects;
2312

> SELECT count(*) FROM sys.system_objects;
2201

> SELECT count(*) FROM sys.objects;
> 111

SELECT count(*)
FROM sys.sysobjects
WHERE NOT EXISTS (
  SELECT 1
  FROM sys.system_objects
  WHERE system_objects.object_id = sysobjects.id
);
> 111

因此，我们已经开始探索在我们的生产数据库之一上使用变更数据捕获。我们想知道每次更改的日期时间。阅读演练和教程等，似乎标准方法是使用 LSN 与cdc.lsn_time_mapping系统表相关联。这种方法有效，但在谈论每天成千上万的变化时不是很直接也不是很有效。

在测试环境中，我对变更跟踪表进行了以下调整。我发布了一个ALTER TABLE声明，在名为的末尾添加一列并将其设为[__ChangeDateTime]默认值GetDate()。该方法似乎有效，更改跟踪仍然正常运行，正在捕获日期时间。 但是乱搞系统表让我有点紧张。

如果这不是微软从一开始就添加的系统字段，他们一定有他们的理由。既然他们选择了 LSN 到 cdc.lsn_time_mapping 方法，我是否通过这种方式创建自己的 hack 来解决问题？

更新：

在测试期间发现 GetDate() 有时不足以满足我们的需求 - 多个更改同时共享。建议使用sysdatetime() 和 datetime2将值移出到纳秒。显然只有 2008+ 的选项。