澳门在线威尼斯官方 > 电脑数据库 > 读书笔记,Server元数据损坏

原标题:读书笔记,Server元数据损坏

浏览次数:81 时间:2019-09-25

 

■SQL Server错误日志输出

 

虽然这个输出是全面的,但消息是冗余的。在正常操作中,涉及破损的重要信息可能会在数据库中。总是建议使用NO_INFOMSGS选项,以减少输出,仅仅必要的信息。例如,这里是来自相同的破损数据库的DBCC CHECKDB输出,但NO_INFOMSGS选项被定义:

那么难道就没有办法解决这种问题了吗? 答案是当然有,不过,这种方式是没有官方文档而且也不被官方Support的,如果你要按下面方法操作,是有一定风险的。所以如果你决定按照下面方式修复元数据损坏的话,先做好备份。以防万一。

◆Windows 应用程序事件日志的一个项。

 

◆3  合并模式因为数据库不能在重建事务日志后不能重启而修复失败。7909错误,伴随着5235错误。

 

默认,DBCC CHECKED输出如下:
 ◆服务代理一致性检查的概要

 

◆SQL Server 错误日志的一条信息

 

Msg 8909, Level 16, State 1, Line 1
Table error: Object ID 0, index ID -1, partition ID 0, alloc unit ID 0 (type Unknown), page
ID (1:158) contains an incorrect page ID in its page header. The PageId in the page header =
(0:0).
CHECKDB found 0 allocation errors and 1 consistency errors not associated with any single
object.
Msg 8928, Level 16, State 1, Line 1
Object ID 2073058421, index ID 1, partition ID 72057594038386688, alloc unit ID
72057594042384384 (type In-row data): Page (1:158) could not be processed.  See other errors
for details.
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sales' (object ID
2073058421).
CHECKDB found 0 allocation errors and 2 consistency errors in database 'CorruptDB'.
repair_allow_data_loss is the minimum repair level for the errors found by DBCC CHECKDB
(CorruptDB).

 

每次DBCC CHECKED成功完成时,一个关于被一致性检查的数据库的项被加到SQL Server错误日志。一个错误例子如下:
2008-11-03 00:51:11.08 spid56      DBCC CHECKDB (CorruptDB) executed by CHICAGO
Administrator found 2 errors and repaired 0 errors. Elapsed time: 0 hours 0 minutes 0
seconds.  Internal database snapshot has split point LSN = 00000044:00000188:0001 and first
LSN = 00000044:00000187:0001.  This is an informational message only. No user action is
required. 

DBCC CHECKCATALOG (TEST) WITH NO_INFOMSGS;

GO

 

DBCC CHECKDB(TEST) WITH NO_INFOMSGS;

GO

如果错误被DBCC CHECKED发现,在包含错误报告的故障文件的元数据的事件日志中可能有三个附加的项。
 在DBCC CHECKED决定提前终止的事件中,一个简单的项输入到事件日志。如果SQL Server错误日志项没被生成,那是因为DBCC CHECKED不受控制地终止,应用程序事件日志项也不生成。

 

◆4  一个访问冲突或断言发生(即使DBCC CHECKED已经在SQL Server2005中被重新设计以避免这些错误发生)

 

《Microsoft Sql server 2008 Internal》读书笔记--目录索引

但是系统基础表sys.syscolpars和sys.sysobjvalues在正常情况下是不可见的。只有在数据库专用管理员连接方式(DAC Dedicated Administrator Connection)连接下才能可见。如下所示,可以判断数据来源于sys.syscolpars系统基础表。

注意:并没有针对原始的系统表检查的阶段被报告。这个阶段运行得很快以至于在SQL Server 2005中的进度报告被加到DBCC CHECKED时,开发小组不认为有必要包括一个隔离的进度报告阶段。
对于DBCC CHECKTABLE,下列阶段被报告:

 

◆DBCC SYS CHECK

Msg 8992, Level 16, State 1, Line 1

当DBCC CHECKED被在master数据库中执行是一个特例。此时,DBCC CHECKED也被运行在隐藏的资源数据库mssqlsystemresource,因此输出结果中包含这两个数据库的结果。

 

 图片 1

USE TEST;

错误列表及错误的计数。

 

◆DBCC TABLE CHECK

图片 2

◆0  一个致命的元数据破损被检测到。一个或更多的8930错误,伴随着5235错误。

r Management Studio - Query"

如果DBCC CHECKDB过早终止,一个简单型的项(entry)在错误日志中被输入。如果在存储引擎的高危险性的错误导致DBCC CHECKDB无法控制地终止,项不会出现在错误日志中。该错误日志项的生成是DBCC CHECKDB完成时所做的最后的事情之一。这意味着,如果发生错误,例如,终止运行命令的连接,DBCC CHECKDB无法生成错误日志项。

 

 

 

◆影响到表的地方不能被确定的错误列表,加这些错误的计数

CHECKDB found 0 allocation errors and 2 consistency errors in database 'TEST'.

■应用程序事件日志输出

SET QUOTED_IDENTIFIER ON

SET ANSI_NULLS ON

GO

CREATE VIEW sys.parameters AS

    SELECT object_id, name,

        parameter_id, system_type_id,

        user_type_id, max_length,

        precision, scale,

        is_output, is_cursor_ref,

        has_default_value, is_xml_document,

        default_value, xml_collection_id,

        is_readonly

    FROM sys.parameters$

    WHERE number = 1

 

GO

 

 

 

CREATE VIEW sys.parameters$ AS

    SELECT c.id AS object_id,

        c.number, c.name,

        c.colid AS parameter_id,

        c.xtype AS system_type_id,

        c.utype AS user_type_id,

        c.length AS max_length,

        c.prec AS precision,

        c.scale AS scale,

        sysconv(bit, c.status & 512) AS is_output,        -- CPM_OUTPUT

        sysconv(bit, c.status & 1024) AS is_cursor_ref,    -- CPM_CURSORREF

        sysconv(bit, isnull(v.objid, 0)) AS has_default_value,

        sysconv(bit, c.status & 2048) AS is_xml_document, -- CPM_XML_DOC        

        v.value AS default_value,

        xmlns AS xml_collection_id,

        sysconv(bit, c.status & 4194304) AS is_readonly -- CPM_IS_READONLY = 0x00400000

    FROM sys.syscolpars c

    LEFT JOIN sys.sysobjvalues v ON v.valclass = 9 AND v.objid = c.id AND v.subobjid = c.colid AND v.valnum = 0    -- SVC_PARAMDEFAULT

    WHERE number > 0 AND has_access('CO', c.id) = 1

◆DBCC ALLOC CHECK

 

◆在sys.dm_exec_requests目录视图的进度报告信息

 

下篇将关注DBCC CHECKDB选项

 

对于DBCC CHECKFILEGROUP,下列阶段被报告:

 

■进度报告输出

 

◆常规输出,由一个错误的信息和邮件组成的列表指向发布DBCC CHECKDB命令的连接。

你必须将数据库实例在单用户模式下面启动,然后以专用管理员(DAC)连接到数据库,然后就可以删除基础表下面的数据了,如下截图所示:

■常规输出

其实如果是从SQL Server 2000还原的话,在SQL Server 2000当中是可以修改相关系统表的,如果执行了DBCC CHECKDB命令发现了元数据问题,那么可以直接修改系统表解决问题(当然只是部分情况),如果已经还原到了SQL Server 2008 以上数据库时,就必须按这种方式折腾,由于这种方式,官方是不支持的。所以还是有一定风险的。因为你不清楚潜在的风险,也不能确保任何场景都能解决问题而不出现意外情况。所以操作之前,尽量多测试、做好备份以防万一。

每次DBCC CHECKED成功完成时,一个项被加到应用程序事件日志标明错误被发现我修复的序号,一个例子如下:
图片 3

在升级一个SQL Server 2000的数据库时,遇到了一致性错误,其中有几个错误是元数据损坏(metadata corruption),特意研究了一下这个案例,因为以前也零零散散的遇到过一些一致性相关错误,但是难得遇到元数据损坏的案例。

◆DBCC TABLE REPAIR(如果发现一个错误,并且一个修复选项被定义)

Check Catalog Msg 3853, State 1: Attribute (object_id=1362819917) of row (object_id=1362819917,parameter_id=1) in sys.parameters does not have a matching row (object_id=1362819917) in sys.objects.

◆1  一个无效的内部状态在DBCC CHECKED内部被检测到。一个或更多的8967错误,伴随着5235错误。

 

◆分配和一致性错误的概要计数

C:Documents and Settings>net start mssqlserver /m"Microsoft SQL Serve

 

《Microsoft Sql server 2008 Internals》读书笔记订阅地址:

Msg 8992, Level 16, State 1, Line 1

◆必须被定义以修复已报告错误的最小修复级别

 

正如你所看到,这个输出信息易读性不错。

GO

◆DBCC IVIEW CHECK(如果上一步未发现错误)

 

《Microsoft Sql server 2008 Internals》索引目录:

 

 

The SQL Server (MSSQLSERVER) service is starting.

◆DBCC TABLE CHECK
 注意:DBCC CHECKFILEGROUP不支持修复操作。

本文由澳门在线威尼斯官方发布于电脑数据库,转载请注明出处:读书笔记,Server元数据损坏

关键词:

上一篇:二进制日志

下一篇:没有了