问题标签 [dbcc]

我收到警报“检测到可能的索引损坏。运行 DBCC CHECKDB”我检查了错误日志，它们是：“检测到可能的索引损坏。运行 DBCC CHECKDB 错误：9100，严重性：23，状态：2”

我的问题是如何确定在哪个数据库上运行 DBCC？我找不到指向哪个数据库引发此警报的消息。

谢谢，

我正在尝试使用 DBCC 查看表上的页面信息。当我跑

我明白了

DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

在 SSMS 的消息窗口中。

我没有看到 DBCC 的输出。我必须通过一些标志吗？

我有一台 Windows 7 64 位机器，上面运行 16GB 内存、24GB 页面文件、500GB HD 和 SQL Server 2012 标准版 64 位。我通过 SSMS 将最大服务器内存设置为 1024MB。

启动 5 分钟后，它通常会使用我所有的虚拟内存并在我的机器上触发警告，即 ProcessExplorer 说 sqlservr.exe 正在使用 38GB 的​​私有字节，61GB 的虚拟大小。

我相信这个问题是由于我在运行 DBCC MemoryStatus 命令时看到的错误信息造成的，这表明可用虚拟内存是8,763,135,270,912。这个数字至少是 8TB。该命令返回的其他统计数据似乎是准确的。

有谁知道 DBCC MemoryStatus 命令如何获取这个数字以及我如何更正它？我认为这会影响它将尝试分配多少虚拟内存。

需要一些帮助来了解当您遇到硬盘故障和服务器关闭时恢复过程是如何工作的。

我们运行 MSSQL2005 服务器。我们每晚进行一次完整备份，每小时记录一次。

在备份前 (2) 小时，我们在 Raid 5 存储驱动器上出现了磁盘故障。数据库在服务器关闭后重新上线，但故障后 8 小时内没有事务日志。

当我运行 DBCC CHECKDB 时，长报告列出：

这是 CHECKDB 文件中的最后三个条目。有一个长长的范围条目列表。

上一次已知的良好备份是 2 天前。我尝试运行还原而不是repair_allow_data_loss，但是每次我尝试还原并在数据库上运行完整性检查时，它都会因相同的原因而失败，并且DBCC CHECKDB 文件列出了相同的问题。

我怎样才能摆脱这个问题？如果我要运行 repair_allow_data_loss，我会丢失多少数据？损失会包括过去数年的数据还是仅包括故障以来的数据？

For my unit tests I have an automated process which builds a copy of a DB, table by table. I first of all run a SELECT INTO and add the primary key and any indices.

Some of the tables I copy with data, and for those without data I wish to reset the identity seed.

To achieve this I have the following T-SQL statement:

The query runs without any reported problems but when I inspect the table in design view the Identity Seed value is never reset.

Can anyone please tell me why the Identity Seed is not being reset, or what else I need to do?

UPDATE: As per some comments I have modified the sys.identity_columns to the following:

When run, this returns the following message:

Checking identity information: current identity value '1'. DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Which looks promising. However, if I then refresh the table (in the Object Explorer) and look at it in the design view, the Identity Seed is unchanged, i.e. not 1 (or 0) but 135.

我一直在生产服务器中遇到性能问题；在互联网上阅读它时，我遇到了@Brent Ozar 关于等待统计的文章。

我想尝试一下，但我不确定它运行起来有多安全。我的生产环境经常被 SSIS 作业占用，我不想杀死任何作业或服务器。所以，我有几个问题

• 在服务器上运行查询或 SQL 作业时运行是否安全

DBCC SQLPERF("sys.dm_os_wait_stats",CLEAR);

DBCC SQLPREF("sys.dm_os_latch_stats",CLEAR);

• 更新统计信息和清除等待统计信息有什么区别？

我试图弄清楚 SQL Server 如何存储Tinyint（应该是 1 字节长）列。

结果如下：

---

DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

页：（1:182）…………

插槽 0 偏移量 0x60长度 9

记录类型 = PRIMARY_RECORD 记录属性 = NULL_BITMAP记录大小 = 9

内存转储@0x000000000545A060

0000000000000000: 10000600 03000100 00 †††††††††††††††††.........

插槽 0 列 1 偏移量 0x4 长度 2 长度（物理）2

Col1 = 3

DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

---

解释： 实际数据行为 10 00 0600 0300 0100 00 为：
10：状态位 A
00：状态位 B
0600：存储列数的位置
0300：Tinyint 数据
0100：列数
00：Null 位图
总字节数： 1 + 1 + 2 + 2 + 2 + 1 = 9 字节

与“Smallint”比较：将
“Col1”类型更改为“ Smallint”（2 字节长）产生完全相同的结果。

问题 为什么 SQL Server 将 2 个字节专用于 ' Tinyint' 列？为什么它在商店规模上不区分“Tinyint”和“Smallint”？

可能是一个菜鸟问题，但它就在这里。所以我正在使用 powershell 制作这个备份测试脚本，我在控制台中显示 DBCC 的结果，当 $db.CheckTables('None') 循环通过数据库集合并遇到损坏的数据库时，它不会继续检查其余的数据库。这是我的代码

我希望从 python 代码中重新设置 userprofile 表。我做了如下

但它没有得到设置。我检查过

任何帮助将不胜感激

我正在尝试缩小测试系统上的数据库，但文件不会变小。mdf 文件的大小为 47 GB，未使用空间为 38 GB。大量数据从数据库中删除，因此大量未使用空间。

出现以下错误：Start dbcc shrinkfile (Olympus_dat, 46912) at 2015-07-23 15:27:19.300 DBCC SHRINKFILE: Page 1:6017543 由于尚未格式化，无法移动。

我该如何解决这个错误？

SQL Server 2012 x64

附加信息。以下查询返回错误：

DBCC 执行完成。如果 DBCC 打印错误消息，请联系您的系统管理员。

页：（14440：908631589）

缓冲：

BUF @0x0000000009682040

bpage = 0x00000002B46B8000 bhash = 0x0000000000000000 bpageno = (1:6017543) bdbid = 6 breferences = 1 bcputicks = 0 bsampleCount = 0 bUse1 = 23548 bstat = 0x809 blog = 0x5adb215a000000000000000

页眉：

页面@0x00000002B46B8000

m_pageId = (14440:908631589) m_headerVersion = 252 m_type = 226 m_typeFlagBits = 0xf9 m_level = 216 m_flagBits = 0xd676 m_objId (AllocUnitId.idObj) = -1238914908 m_indexId (AllocUnitId.idInd) = 23941 Metadata: AllocUnitId = 6738992698879115264 Metadata: PartitionId = 0 Metadata : IndexId = -1 Metadata: ObjectId = 0 m_prevPage = (35510:854211095) m_nextPage = (61606:1041616947) pminlen = 43990 m_slotCnt = 27900 m_freeCnt = 40464 m_freeData = 34288 m_reservedCnt = 12643 m_lsn = (-257029635:1920476993:30788) m_xactReserved = 11969 m_xdesId = (25449:1820050307) m_ghostRecCnt = 61532 m_tornBits = -213551362 DB Frag ID = 1

分配状态

GAM (1:5623552) = 已分配 SGAM (1:5623553) = 已分配
PFS (1:6017472) = 0x40 已分配 0_PCT_FULL DIFF (1:5623558) = 未更改 ML (1:5623559) = 未最小记录

压缩信息@0x00000000309682B0

CompressionInfo 原始字节

CompressionInfo 大小（以字节为单位）= 0 PageModCount = 50289 CI 标头标志 =

数据：

插槽 0，偏移量 0x4ad2，长度 1，DumpStyle BYTE

记录类型 = (COMPRESSED) EMPTY_GHOST_RECORD 记录大小 = 1

光盘阵列

记录内存转储

000000003096EAD2：05。
消息 0，级别 11，状态 0，行 0 当前命令发生严重错误。结果，如果有的话，应该丢弃。