单客户形式运行SQL,第十意气风发章DBCC

 

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

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

 

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

在SQL Server的数据库维护过程中,有时候在一些特殊情况下需要在单用户模式下启动SQL Server实例。 下面总结一下单用户模式启动SQL Server的几种方式:

 

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

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

 

如下所示,数据库从SQL Server 2000还原到SQL Server 2008以后,在做一致性检查时,发现有元数据损坏(metadata corruption),下面是实验是构造的一个测试环境

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

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

1:命令模式(sqlservr.exe)启动

 

 

前面几篇主要介绍了per-table一致性检查,本文我们关注交叉表的一致性检查,主要包括:Service Broker一致性检查,交叉目录(cross-catalog)一致性检查,索引视图一致性检查,XML索引一致性检查,空间索引(spatial-index)一致性检查。

 

DBCC CHECKCATALOG (TEST) WITH NO_INFOMSGS;

GO

 

DBCC CHECKDB(TEST) WITH NO_INFOMSGS;

GO

 ■ DBCC CHECKED输出

■交叉表一致性检查

首先在命令窗口中切换到Binn目录(这个要视SQL Server实际安装路径情况而定,另外,多实例情况下,必须切换到对应路径),如果你对sqlservr.exe命令不熟悉,可以查看相关帮助信息。如下所示:

 

DBCC CHECKED用四种方式输出信息:

交叉表一致性检查包括验证数据库中的表之间的各种非物理的关系。一些例子如下:

 

 

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

◆表的元数据必须匹配描述列的元数据(这两套数据在不同的系统目录中)

C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLBinn>sqlservr.exe /?

usage: sqlservr

        [-a<L2 buffer pool directory>,<size in GB>]       (adding an L2 buffer pool file)

        [-c] (not as a service)

        [-d file] (alternative master data file)

        [-l file] (alternative master log file)

        [-e file] (alternate errorlog file)

        [-f] (minimal configuration mode)

        [-m] (single user admin mode)

        [-g number] (stack MB to reserve)

        [-k <decimal number>] (checkpoint speed in MB/sec)

        [-n] (do not use event logging)

        [-s name] (alternate registry key name)

        [-T <number>] (trace flag turned on at startup)

        [-x] (no statistics tracking)

        [-y number] (stack dump on this error)

        [-B] (breakpoint on error (used with -y))

        [-K] (force regeneration of service master key (if exists))

        [-v] (list version information)

 

See documentation for details.

2018-04-06 11:28:00.52             SQL Server shutdown has been initiated

Msg 8992, Level 16, State 1, Line 1

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

◆primary XML索引必须精确代表它索引的XML列(primary XML索引作为内部表存储,与包含它所索引的XML列隔离)

 

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.

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

◆索引视图必须精确代表视图定义。

 

Msg 8992, Level 16, State 1, Line 1

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

交叉表一致性检查只有在涉及的表的一致性检查完成并没有一致性问题(或问题已修复时)才会运行。

sqlservr.ex启动时,当前环境有多实例,而你有没有指定参数-s,那么就会提示类似如下信息, 需要你指定-s参数的SQL Server服务名称。

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

■常规输出

例如,设想一个XML索引建在一个基于表T1的XML列。表T1有一个页损坏,它似乎是空的(即一些记录是不可访问)。如果XML索引检查在表T1检查之前,它可能从XML索引中额外的信息得知索引是损坏的。但实际上,是T1表已损坏,XML索引需要在表T1的任何修复后重建。

 

CHECKDB found 0 allocation errors and 2 consistency errors not associated with any single object.

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

看起来,这是一个微妙的差别,但DBCC CHECKDB需要报告一阶(first-order)一致性错误。持有同样的逻辑来执行的其他交叉表一致性检查,因此,根据什么一致性错误在早期阶段发现,交叉表一致性检查中的某些可能被跳过。

 

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

◆分配错误的列表,加这些错误的计数

1、Service Broker一致性检查

C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLBinn>sqlservr.ex

 

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

服务代理内容使用数据库的两种类型的表:

e -c -m

 

◆对于每一个数据库中的(包括系统目录表):

◆在数据库中使用的服务代理(例如,对话,端点,队列)相关的存储元数据的系统目录

2018-04-06 11:40:54.15 Server      Multiple instances of SQL server are installe

 

行数和页数

◆用于存储服务代理序列的内部表

d on this computer. Renter the command, specifying the -s parameter with the nam

图片 1

错误列表及错误的计数。

这两种类型表都拥有用户表的物理结构,但因为行为和可访问性不同而有不同的属性。它们的物理结构被如前所提到的逻辑一致性检查所检查。该检查验证如下:

e of the instance that you want to start.

 

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

◆一个对话(conversation)必须有两个端点(endpoint)。

2018-04-06 11:40:54.16 Server      SQL Server shutdown has been initiated

 

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

◆一个服务必须相关到一个有效的契约

 

 

DBCC CHECKED输出的一个例子如下:(数据库包含一些破损):

   ◆一个服务必须相关到一个有效的序列   

sqlservr.exe -c -m  -s{instancename}

 

DBCC results for 'CorruptDB'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
Service Broker Msg 9605, State 1: Conversation Priorities analyzed: 0.
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.
DBCC results for 'sys.sysrscols'.
There are 637 rows in 8 pages for object "sys.sysrscols".
DBCC results for 'sys.sysrowsets'.
There are 92 rows in 1 pages for object "sys.sysrowsets".
DBCC results for 'sys.sysallocunits'.
There are 104 rows in 2 pages for object "sys.sysallocunits".
DBCC results for 'sys.sysfiles1'.
There are 2 rows in 1 pages for object "sys.sysfiles1".
DBCC results for 'sys.syspriorities'.
There are 0 rows in 0 pages for object "sys.syspriorities".
DBCC results for 'sys.sysfgfrag'.

◆一个消息必须有一个有效的消息类型

 

那么我们先找到系统视图sys.parameters的数据来源于那个系统基础表(System Base-Table Metadata),如下脚本所示,我们可以找到sys.parameters 最终来源于sys.syscolpars和 sys.sysobjvalues(关于如何获取系统视图定义,此处不做展开分析)

There are 2 rows in 1 pages for object "sys.sysfgfrag".
<some results removed for brevity>
DBCC results for 'sys.syssqlguides'.
There are 0 rows in 0 pages for object "sys.syssqlguides".
DBCC results for 'sys.sysbinsubobjs'.
There are 3 rows in 1 pages for object "sys.sysbinsubobjs".
DBCC results for 'sys.syssoftobjrefs'.
There are 0 rows in 0 pages for object "sys.syssoftobjrefs".
DBCC results for 'sys.queue_messages_1977058079'.
There are 0 rows in 0 pages for object "sys.queue_messages_1977058079".
DBCC results for 'sys.queue_messages_2009058193'.
There are 0 rows in 0 pages for object "sys.queue_messages_2009058193".
DBCC results for 'sys.queue_messages_2041058307'.
There are 0 rows in 0 pages for object "sys.queue_messages_2041058307".
DBCC results for 'sales'.
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.
There are 4755 rows in 20 pages for object "sales".
CHECKDB found 0 allocation errors and 1 consistency errors in table 'sales' (object ID
2073058421).
DBCC results for 'sys.filestream_tombstone_2121058592'.
There are 0 rows in 0 pages for object "sys.filestream_tombstone_2121058592".
DBCC results for 'sys.syscommittab'.
There are 0 rows in 0 pages for object "sys.syscommittab".
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 execution completed. If DBCC printed error messages, contact your system administrator.

   这些检查并非DBCC CHECKDB执行,相反,他们被服务代理子系统(代表DBCC CHECKDB)本身执行。如果发现任何错误的一致性,他们报告DBCC CHECKDB一个8997的错误,加上8992交叉目录的一致性检查错误。    

 

 

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

2、交叉目录(cross-catalog)一致性检查

 

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

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).

在SQL Server2005以前的版本中,CHECKCATALOG什么时候应该被运行以验证各种系统目录之间的关系是一个极易混淆的问题,为此,SQL Server 2005将CHECKCATALOG集成在DBCC CHECKED中。

sqlservr.ex启动时,如果SQL Server服务本身还在运行,就会报“Operating system error = 32(The process cannot access the file because it is being used by another process.).

 

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

SQL Server 2005中,关系引擎中的整个元数据子系统被重写,SQL Server 2008进一步补充为一个系统目录一致性检查SQL Server 2000中相应的检查DBCC CHECKDB(代表元数据子系统进行,也可以使用DBCC CHECKCATALOG执行命令)。

 

 

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

这些检查操作仅仅在系统目录上处理关系引擎元数据。

 

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

如果DBCC CHECKDB因为某种原因提前终止,不能被DBCC CHECKDB控制,错误5235输出,包含一个错误状态。错误状态具有以下含义:

存储引擎元数据系统目录在每表一致性检查期间被检查。在检查的一些例子包括以下内容:

C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLBinn>sqlservr.ex

 

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

◆对所有元数据,匹配表元数据必须存在

e -c -m -sMSSQLSERVER

 

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

◆计算列中引用的列定义必须存在

2018-04-06 11:41:59.01 Server      Error: 17058, Severity: 16, State: 1.

图片 2

◆2  对关键系统表中的原始检查失败。一个或更多的7984到7988错误,伴随着5235错误。

◆包括在一个索引定义的所有列必须存在

2018-04-06 11:41:59.01 Server      initerrlog: Could not open error log file 'C:

 

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

如果任何一致性检查出错,报给DBCC CHECKED,然后转化为8992错误:

Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLLogERRORLOG'. Ope

 

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

Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row
(object_id=1977058079,column_id=1) in sys.columns does not have a matching row
(object_id=1977058079) in sys.objects.
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3853, State 1: Attribute (object_id=1977058079) of row
(object_id=1977058079,column_id=2) in sys.columns does not have a matching row
(object_id=1977058079) in sys.objects.

rating system error = 32(The process cannot access the file because it is being

此时即使在专用管理员连接下面也是无法删除这些数据的,会报“Ad hoc update to system catalogs is not supported”,对应中文提示为“不支持对系统目录进行即席更新”。如下所示:

◆5  一个未知原因引起DBCC CHECKED终止,尽管也可能是graceful.

注意:这些检查不运行在tempdb数据库
 

used by another process.).

 

在SQL Server2008中,任何时候被DBCC CHECKED发现的错误,一个故障文件在实例日志目录被创建,还有一些XML格式的错误的文本概要和一个当前SQL Server错误日志文件的副本。如果实例被配置为提供反馈给microsoft,这些文件会被自动上传。

3、索引视图一致性检查

2018-04-06 11:41:59.32 Server      Error: 17058, Severity: 16, State: 1.

 

 

尽管索引视图是数据库中的一个First-class对象,它被存储作为一个带一个聚集索引的内部表,因而它的物理结构在per-table一致性检查时被检查。这些一致性检查并不检查索引视图的内容是否匹配视图定义。
 

2018-04-06 11:41:59.32 Server      initerrlog: Could not open error log file 'C:

EXEC sp_configure 'allow_updates', 1;

■SQL Server错误日志输出

描述索引视图一致性检查最简单的方法是,它使用了索引视图的定义(在系统目录中)来生成一个索引视图的临时副本。然后,它使用查询处理器执行两个实际索引视图和临时索引视图之间的左反半联接。此查询报告实际索引视图任何丢失或额外的行。

Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLLogERRORLOG'. Ope

RECONFIGURE WITH OVERRIDE;

每次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 CHECKDB采用的查询类似于非聚集索引使用深潜交叉检查(deep-dive cross-checking),查询格式:

rating system error = 32(The process cannot access the file because it is being

GO

请注意该项(entry)列出DBCC CHECKDB完成的elapsed时间。这可以使数据库管理员可以获得一些必要的判断信息,而不必为特定的数据库诉诸人工计时DBCC CHECKDB的平均运行时间。该项还列出了哪个选项被定义。这对于决定数据库以前是否被修复可能是有用的。
该项还列出了DBCC CHECKDB创建的一些有关数据库快照的元数据信息。这对产品支持调试时的破损问题可能是有用的。

SELECT <identifying columns of missing rows>
FROM <materialize the view temporarily> tOuter WITH (NOEXPAND)
WHERE NOT EXISTS
(
       SELECT 1
       FROM <actual view> tInner WITH (INDEX = 1)
       WHERE
       (
              ([tInner].<view columns> = [tOuter].<view columns>) OR
              ([tInner].<view columns> IS NULL AND [tOuter].<view columns> IS NULL)
       )
)
UNION ALL
SELECT <identifying columns of extra rows>
FROM <actual view> tOuter WITH (INDEX = 2)
WHERE NOT EXISTS
(
       SELECT 1
       FROM <materialize the view temporarily> tInner WITH (NOEXPAND)
       WHERE
       (
              ([tInner].<view columns> = [tOuter].<view columns>) OR
              ([tInner].<view columns> IS NULL AND [tOuter].<view columns> IS NULL)
       )
)

used by another process.).

USE TEST;

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

 

2018-04-06 11:42:02.04 Server      SQL Server shutdown has been initiated

GO

■应用程序事件日志输出

 

 

DELETE FROM  sys.syscolpars WHERE id=1362819917;

DBCC CHECKED在每次写输出到SQL Server错误日志时生成一个匹配的应用程序事件日志。

在查询中使用的NOEXPAND提示指示查询处理器执行索引视图扫描,而不是扩展到它的各个组成部分。索引视图中的任何额外的行被报为8907错误,丢失行则报8908错误。

 

GO

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

这个检查非常耗时和耗空间。索引视图定义越复杂,它被定义的表就越大,具体化一个索引视图的临时副本花费时间更长,越可能在tempdb占用更多的空间。该检查SQL Server2008默认不执行,必须使用extended_logical_checks选项才能启用。

 

 

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

 

如果在sqlservr.exe当中退出单用户模式,直接使用CTRL C 或 CTRL Break,如下所示:

 

■进度报告输出

4、XML索引一致性检查

 

图片 4

DBCC CHECKED,DBCC CHECKTABLE,DBCC CHECKFILEGROUP都在sys.dm_exec_requests目录视图中报告它们的进度。相关的两个列是percent_complete(自我解释)和command(当前DBCC命令被执行的执行阶段),下表展示了执行的顺序:

一个primary的XML索引被存储为一个带聚集索引的内表。一个secondary的XML索引被作为primary XML索引内表的一个非聚集索引存储。一致性检查必须验证XML索引包含用户表的XML值的一个精确的碎片代表。

图片 5

 

 图片 6

这种机制类似于索引视图一致性检查,并且可以类似查询样式的可视化,即使T-SQL查询并没有使用。在此情况下,两个左反半联接可以被看作是实际的XML索引和一个XML索引子系统产生的XML索引的临时副本。

 

 

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

XML索引的任何额外的行被报8907错误,丢失行则会报8908错误。

 

 

◆DBCC TABLE CHECK

这个检查运行成本非常高。XML架构越复杂,XML列值越大,生成XML索引的临时副本花费的时间更长,越有可能在tempdb中占用更多的空间。该检查SQL Server2008默认不执行,必须使用extended_logical_checks选项才能启用。
 

 

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

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

5、空间索引(spatial-index)一致性检查

 

 

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

一个空间索引被存储为一个带聚集索引的内表。一致性检查必须验证空间索引包含用户表的空间值的一个精确的碎片代表。

2:命令模式(net star)启动

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

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

这种机制类似于索引视图一致性检查,并且可以类似查询样式的可视化,即使T-SQL查询并没有使用。在此情况下,两个左反半联接可以被看作是实际的空间索引和一个空间索引子系统产生的空间索引的临时副本。

 

 

◆DBCC ALLOC CHECK

空间索引的任何额外的行被报8907错误,丢失行则会报8908错误。
这个检查可能是耗时和耗空间的,这取决于空间索引如何被定义。在每个索引边界盒内部的每个Grid级别的分解的单元格的数量越高,每空间值存储的匹配grid单元格的数量越高,生成空间索引的临时副本花费的时间更长,越有可能在tempdb中占用更多的空间。该检查SQL Server2008默认不执行,必须使用extended_logical_checks选项才能启用。

 

 

◆DBCC SYS CHECK

本文主要介绍了交叉表的一致性检查。下文将介绍DBCC CHECKED Output
 

C:Users>net stop mssqlserver

C:Documents and Settings>net stop mssqlserver

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

The following services are dependent on the SQL Server (MSSQLSERVER) service.

The SQL Server (MSSQLSERVER) service is stopping.

下篇将关注DBCC CHECKDB选项

Stopping the SQL Server (MSSQLSERVER) service will also stop these services.

The SQL Server (MSSQLSERVER) service was stopped successfully.

 

 

 

   SQL Server Agent (MSSQLSERVER)

 

 

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

Do you want to continue this operation? (Y/N) [N]: y

r Management Studio - Query"

The SQL Server Agent (MSSQLSERVER) service is stopping.

The SQL Server (MSSQLSERVER) service is starting.

The SQL Server Agent (MSSQLSERVER) service was stopped successfully.

The SQL Server (MSSQLSERVER) service was started successfully.

 

 

The SQL Server (MSSQLSERVER) service is stopping.

 

The SQL Server (MSSQLSERVER) service was stopped successfully.

USE TEST;

GO

DELETE FROM  sys.syscolpars WHERE id=1362819917;

GO

 

----------------------------------------------------------------------------------

Warning: System table ID 41 has been updated directly in database ID 5 and cache coherence may not have been maintained. SQL Server should be restarted.

 

(2 row(s) affected)

 

 

 

图片 7

C:Program FilesMicrosoft SQL ServerMSSQL12.MSSQLSERVERMSSQLBinn>net start mssqlserver /m

 

The SQL Server (MSSQLSERVER) service is starting.

 

The SQL Server (MSSQLSERVER) service was started successfully.

 

 

此时再去检查数据库一致性,你就会看到上面遇到的元数据损坏错误不见了。如下截图所示:

图片 8

 

 

 

 

 

3:SQL Server配置管理器启动

图片 9

 

 

 

 

在SQL Server配置管理器中,找到对应实例,右键单击属性,在启动参数里面增加参数-m,然后重启即可。

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

 

 

图片 10

 

 

 

在单用户模式下启动SQL Server实例时,请注意下列事项:

 

 

·         只有一个用户可以连接到服务器。

 

·         不执行CHECKPOINT 进程。 默认情况下,启动时自动执行此进程。

 

 

                                                                                                                                                                                                                 在单用户模式下启动 SQL Server 可使计算机本地 Administrators 组的任何成员作为 sysadmin 固定服务器角色的成员连接到 SQL Server 实例。 有关详细信息,请参阅在系统管理员被锁定时连接到 SQL Server。

 

 

在单用户模式下, 只有一个用户可以连接到服务器,那么这样问题就来了,很有可能当你需要登录的时候,这个唯一的的用户已经被其它用户捷足先登了。此时你却被拒之门外,是否相当抓狂。此时你可能遇到下面错误

 

 

 

C:Users>sqlcmd

Sqlcmd: Error: Microsoft ODBC Driver 11 for SQL Server : Login failed for user '

xxxx'. Reason: Server is in single user mode. Only one administrator c

an connect at this time..

 

SSMS客户端一般遇到下面这样的错误信息:

 

 

Login failed for user 'xxxx'. Reason: Server is in single user mode. Only one administrator can connect at this time. (Microsoft SQL Server, Error: 18461)

 

 

错误日志或命令里面输出的日志,你会看到类似如下信息:

 

 

2018-04-06 12:21:14.85 Logon       Error: 18461, Severity: 14, State: 1.

2018-04-06 12:21:14.85 Logon       Login failed for user 'xxx'. Reason: Server is in single user mode. Only one administrator can connect at this time. [CLIENT: 192.168.xxx.xxx]

 

 

在这种情况下,怎么办呢? 难道要拼速度? 当然不是,你需要从下面这些方面注意:

 

 

在单用户模式下连接到SQL Server实例之前,停止SQL Server Agent 服务;否则 SQL Server Agent 服务将使用该连接,从而使其阻塞。

 

 

在单用户模式下启动SQL Server实例时,SQL Server Management Studio 可以连接到 SQL Server。 但是Management Studio中的对象资源管理器可能会失败,因为在某些操作中它需要使用多个连接。 若要在单用户模式下管理 SQL Server,可以执行 Transact-SQL 语句(仅通过 Management Studio 中的查询编辑器连接)或者使用 sqlcmd 实用工具。

 

当您将 -m 选项与 sqlcmd 或 Management Studio 结合使用时,可以将连接限制为指定的客户端应用程序。 例如,-m"sqlcmd" 将连接限制为单个连接并且该连接必须将自身标识为 sqlcmd 客户端程序。 当您正在单用户模式下启动 SQL Server 并且未知的客户端应用程序正在占用这个唯一的可用连接时,使用此选项。 若要通过 Management Studio 中的查询编辑器进行连接,请使用 -m"Microsoft SQL Server Management Studio - Query"。

 

 

如下所示,如果你指定了单用户只能以SQLCMD连接,那么此时,其它通过SSMS等其它方式连接数据库都会报上面错误,其它通过程序连接过来的连接就不会抢占这个连接了。

 

C:Windowssystem32>net stop mssqlserver

The SQL Server (MSSQLSERVER) service is stopping.

The SQL Server (MSSQLSERVER) service was stopped successfully.

 

 

C:Windowssystem32>net start mssqlserver /m"SQLCMD"

The SQL Server (MSSQLSERVER) service is starting.

The SQL Server (MSSQLSERVER) service was started successfully.

 

 

C:Windowssystem32>

 

图片 11

 

 

如果你指定参数/m"Microsoft SQL Server Management Studio - Query" 那么就会阻止像应用程序或SQLCMD登录,如下所:

 

 

C:Windowssystem32>net stop mssqlserver

The SQL Server (MSSQLSERVER) service is stopping.

The SQL Server (MSSQLSERVER) service was stopped successfully.

 

 

C:Windowssystem32>net start mssqlserver /m"Microsoft SQL Server Management Studio - Query"

The SQL Server (MSSQLSERVER) service is starting.

The SQL Server (MSSQLSERVER) service was started successfully.

 

 

 

C:Users>sqlcmd

Sqlcmd: Error: Microsoft ODBC Driver 11 for SQL Server : Login failed for user '

xxx'. Reason: Server is in single user mode. Only one administrator c

an connect at this time..

 

图片 12

本文由星彩网app下载发布于星彩彩票app下载,转载请注明出处:单客户形式运行SQL,第十意气风发章DBCC

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。