sp_plan_dbccdb "andkylee"
go

显示结果如下：

Recommended size for dbccdb database is 94MB (data = 92MB, log = 2MB).
No suitable devices for dbccdb in master..sysdevices.
Recommended values for workspace size, cache size and process count are:
dbname                         scan ws  text ws  cache  comp mem  process count
andkylee                       40576K   10176K   10151K 0K        3
(return status = 0)
由上，建议dbccdb的空间大小至少94M（其中数据段至少92M，日志段至少2M），scan工作空间至少40576K，text工作空间至少10176K，命名高速缓存至少10151K，工作进程数至少3个。

2.如果必要，调整ASE的工作进程数
在ASE中配置4个工作进程，配置dbccdb最大可用工作进程数为：3

sp_configure "number of worker processes",4
go

3.为dbccdb创建命令高速缓存dbccdb_cache
配置一个dbcc checkstorage专用的命名高速缓存，不仅可以提高性能并且还可以使数据库的一致性检查对其他用户的影响降到最小。dbcc checkstorage要求在命名高速缓存中创建8页的I/O缓存池。

配置大小为30M的命令高速缓存dbccdb_cache，其中8页的I/O缓存池为10M

sp_cacheconfig dbccdb_cache,"30M"
go

命令高速缓存dbccdb_cache需要重启ASE后才能生效。

配置10M的8页I/O缓冲池：

sp_poolconfig dbccdb_cache,"10M","32k"
go

使用命令sp_cacheconfig dbccdb_cache查看命令高速缓存，结果如下：
 Cache Name   Status   Type     Config Value   Run Value
 ------------ -------- -------- -------------- ------------
 dbccdb_cache Active   Mixed        30.00 Mb       30.00 Mb
                           ------------ ------------
                      Total      30.00 Mb     30.00 Mb
==========================================================================
Cache: dbccdb_cache,   Status: Active,   Type: Mixed
      Config Size: 30.00 Mb,   Run Size: 30.00 Mb
      Config Replacement: strict LRU,   Run Replacement: strict LRU
      Config Partition:            1,   Run Partition:            4
 IO Size  Wash Size     Config Size  Run Size     APF Percent
 -------- ------------- ------------ ------------ -----------
     4 Kb       4096 Kb      0.00 Mb     20.00 Mb     20
    32 Kb       2048 Kb     10.00 Mb     10.00 Mb     20
(return status = 0)

4.如果dbccdb存在，则在创建新的dbccdb数据库之前，删除它及其相关的所有设备

use master
go
if exists (select * from master.dbo.sysdatabases where name = "dbccdb" )
begin
print "Dropping the dbccdb database................"
drop database dbccdb
end
go

5.初始化用于dbccdb数据和日志的磁盘设备dbccdb_dat和dbccdb_log
为用户数据库andkylee建议的dbccdb的数据段至少92M，日志段至少2M。在此创建大小为200M的设备dbccdb_dat，20M的设备dbccdb_log。

use master
go
disk init  name  = 'dbccdb_dat',
physname  = 'd:\syb_data\dbccdb_dat.dat',
size  = '200M'
go
disk init  name  = 'dbccdb_log',
physname  = 'd:\syb_data\dbccdb_log.dat',
size  = '20M'
go

6.在数据库设备上创建dbccdb数据库

use master
go
create database dbccdb
on dbccdb_dat= '200M'
log on dbccdb_log='20M'
go

7.将用于 scan 和 text 工作空间的段添加到 dbccdb 的数据设备上

use dbccdb
go
sp_addsegment scanseg,dbccdb,dbccdb_dat
go
sp_addsegment textseg,dbccdb,dbccdb_dat
go

8.填充dbcc数据库并安装dbcc存储过程
installdbccdb 脚本在试图创建表之前检查数据库是否存在。它只创建dbccdb 中尚未存在的那些表。如果任何一个 dbccdb 表被损坏，请使用 drop table 将其删除，然后使用 installdbccdb 重新创建。
isql -Usa  -P<password>  -S<servername> -i%SYBASE%\%SYBASE_ASE%\scripts\installdbccdb -odbccdb.log

9.创建并初始化 scan 和 text 工作空间
scan工作空间至少40576K，text工作空间至少10176K。在此创建120M的scan工作空间：scan_andkylee，50M的text工作空间：text_andkylee

use dbccdb
go
sp_dbcc_createws dbccdb, scanseg, scan_andkylee, scan, "120M"
go
sp_dbcc_createws dbccdb, textseg, text_andkylee, text, "50M"
go

删除工作空间使用 drop table scan_andkylee

10、 更新dbcc_config配置值
max worker processes 为每个目标数据库指定 dbcc checkstorage 使用的工作进程最大数，而 number of worker processes 指定 Adaptive Server 支持的工作进程总数。工作进程不是专用来运行 dbcc checkstorage 操作的。
将 number of worker processes 的值设置得足够高，使之支持 max worker processes 指定的进程数。工作进程数低会降低 dbcc checkstorage 的性能，减少其资源消耗。 dbcc checkstorage 使用的进程数不会多于数据库使用的数据库设备数。
maximum parallel degree 和 maximum scan parallel degree 对于 dbcc checkstorage 的并行功能没有影响。将 maximum parallel degree 设置为 1时，不会禁用 dbcc checkstorage 中的并行度。
dbcc checkstorage 需要多个工作进程，所以 number of worker processes 必须至少设置为 1 以支持父进程和工作进程。

use dbccdb
go
--为数据库andkylee配置最大工作进程数：3
exec sp_dbcc_updateconfig andkylee,"max worker processes","3"
--为数据库andkylee绑定30M的dbccdb_cache
exec sp_dbcc_updateconfig andkylee,"dbcc named cache",dbccdb_cache,"30M"
--为数据库andkylee指定scan和text工作空间
exec sp_dbcc_updateconfig andkylee,"scan workspace",scan_andkylee
exec sp_dbcc_updateconfig andkylee,"text workspace",text_andkylee
exec sp_dbcc_updateconfig andkylee,"OAM count threshold","5"
exec sp_dbcc_updateconfig andkylee,"IO error abort","3"
exec sp_dbcc_updateconfig andkylee,"linkage error abort","8"
go

11.显示目标数据库的配置信息

sp_dbcc_configreport
go

12.检查数据库andkylee

dbcc checkstorage(andkylee)
go

检查结果如下：
Checking andkylee: Logical pagesize is 4096 bytes
(return status = 0)
DBCC CHECKSTORAGE for database 'andkylee' sequence 1 completed at Sep 26 2012  4
:42PM. 3 faults and 75248 suspect conditions were located. 0 checks were aborted
. You should investigate the recorded faults, and plan a course of action that w
ill correct them.
Suspect conditions are to be treated as faults if the same suspect condition per
sists in subsequent CHECKSTORAGE operations, or if they are also detected by oth
er DBCC functions.

13.生成dbcc报告
sp_dbcc_summaryreport在指定的日期或该日期之前为指定的数据库完成的所有dbcc checkstorage操作。

sp_dbcc_summaryreport
go

BCC Operation : checkstorage
================================================================================
 Database Name                  Start time           End Time   Operation ID Hard Faults Soft Faults Text Columns Abort Count User Name                                                                                                                                                                                                                                                      
 ------------------------------ -------------------- ---------- ------------ ----------- ----------- ------------ ----------- ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 andkylee                       09/26/2012 16:40:27  16:42:32              1           3       75248         6355           0 sa                                                                                                                                                                                                                                                             

(1 row affected)
 
================================================================================
(return status = 0)

14.报告数据库对象中发现的故障
sp_dbcc_faultreport 报告指定数据库对象中在指定日期或该日期之前发生的故障。可生成短报告，也可生成长报告。下面显示短报告：

sp_dbcc_faultreport  'short'
go

Database Name : andkylee
 
 Table Name     Index   PartitionId       Fault Type                               Page Number      
 -------------- ------- ----------------- ---------------------------------------- -----------------
 ALLOCATION           0                99 100007 (extent id error)                              1008
 sysencryptkeys       0                98 100033 (non-contiguous free space error)               633
 sysencryptkeys       0                98 100036 (deleted row count error)                       633

(1 row affected)
(return status = 0)

由上面得检查结果，可以看到用户数据库andkylee的页面633和1008存在分配错误。
执行： dbcc page('andkylee',1008,1)报下面的错误：
DATA:Error: Non-first OAM page 1008 has non-zero OAMSTRUCT entries: total_used: 2 total_unused: 6 rowsperpage: 0
Error: Non-first OAM page 1008 has attribute entries: Attribute status:1, Attribute count: 10
OAM pg #  0:       1008 has the following 1 entry (allocpg:used/unused):

[   0]        768:  2/  6

执行： dbcc page('andkylee',633,1)的结果如下：
PAGE HEADER:
Page header for page 0x2C413000
pageno=633 nextpg=0 prevpg=0 ptnid=98 sysencryptkeys timestamp=0000 0010b6ff
nextrno=2 level=0 indid=0 freeoff=471 minlen=22
page status bits: 0x811 (0x0800 (PG_XHEADER), 0x0010 (PG_RNOFREE), 0x0001 (PG_DATA))
second set of page status bits (dol_stat2): 0x02 (0x02 (PG2_DOL_DATAPG))
dol_pprivstat status bits: 0x00 (0x00)
pagesize=4096, page version=1, ncfs=169, ndeleted=65535, insert free space=3672
pagetailts=0xb6ff
ndeleted的值明显大于DOL页面允许的最大行数：337。
            Item dependent on page size                             : 2048    4096    8192    16384
-----------------------------------------------------------------------------------------------------------
  Max number of rows per APL data page                              : 256     256     256     256
  Max number of rows per DOL data page                              : 166     337     678     1361
 

15.生成指定对象的分配统计报告

sp_dbcc_statisticsreport andkylee,"sysobjects"
go

相关文章

• 2010-12-27 -- 使用重启数据库的未认证DBCC命令来移交表的所有权 (2)
• 2010-08-23 -- 利用dbcc writepage命令修改SQL SQLSERVER中的物理页面上的内容 (3)
• 2010-02-23 -- 成功恢复drop table的表内数据 (3)
• 2009-11-18 -- SQL SERVER DBCC命令解释 (0)

ASE 15.7 新增了命令可以将数据库对象的所有权从一个所有者移交给另一个所有者。

比如将表customer的所有权从dbo移交给bill，使用命令： alter table dbo.customer modify owner bill

不仅仅限于表，还有其它数据库对象包括：视图、存储过程、用户定义函数、默认值、规则、自定义数据类型、加密密钥等；

一次性可以授予多个数据库对象：

1、将 bill 拥有的所有表的所有权都移交给 eric：
    alter table bill.* modify owner eric preserve permissions

2、将 bill 拥有的所有对象的所有权都移交给 eric：
    alter all bill.* modify owner eric preserve permissions

preserve permissions：针对这些对象的所有显式授予或撤消的权限都将被保留，并且权限的 grantor 将更改为新的所有者。-------------------------------------------------------------------------------------------------------------------------------------------------------

以下提供的方法适用于低于ASE 15.7的版本！

和SQL Server很相似，Sybase ASE数据库有一些未认证的DBCC命令。日常的维护过程中，需要一些Sybase认证的、公开的DBCC命令来完成，比如：检查数据库或者表的一致性、物理存储分配一致性、重建索引等等。对于这些公开的DBCC命令，Sybase公司是提供技术支持保障的。那些未公开的也就是未认证的DBCC命令，仅限Sybase内部工程师使用；Sybase公司不提供技术支持也不会对于此产生的问题负责。

所以，不要在生产环境上使用未认证的DBCC命令。在测试环境上研究学习使用倒是可以的。

需要记住的是：没人对这些未认证的DBCC产后的后果负责。

本篇介绍一个用来关闭或者重启某个用户数据库的未认证DBCC命令：dbcc dbreboot。顺便介绍一个修改对象所有者的方法。因为在ASE中对象的所有权是不能移交的，其它用户只有使用权。这点和中国土地权方面很类似吗？美国人信奉私有制，怎么设计出来这个数据库实现思路？呵呵，有点扯远了~~~

这边的测试环境是ASE15.0.3，我不确定从哪个ASE版本开始支持这个dbcc dbreboot命令的。

首先用isql连接到ASE15.0.3数据库，先打开在屏幕显示输出信息的选项，

dbcc traceon(3604)

go

先来查看一下dbcc dbreboot的用法：

执行dbcc help(dbreboot)可以查看使用方法

1> dbcc help(dbreboot)

2> go

dbreboot (report | reboot | reboot_norecovery | shutdown | shutdown_load |

restart | restart_norecovery, <dbname1> [, <dbname2> ...])

 通过上面的使用方法，可以看到dbreboot命令只有两个参数：

1：可操作的类型：reboot，shutdown，restart等

2：被操作的用户数据库的名称，不支持数据库ID，也不支持系统数据库

先来查看一下用户数据库ddb下面都有哪些用户和对象

1>use ddb

2>go

1>select uid,name from sysusers where uid < 1000 order by uid

2>go

 uid         name

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

           0 public

           1 dbo

           3 patrol

           5 rep

(4 rows affected)

数据库ddb内有两个非系统用户：patrol和rep

1>select uid,count(*) from sysobjects

2>group by uid

3>order by uid

4>go

 uid

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

           1          43

           5          56

(2 rows affected)

用户dbo拥有43个对象，另外56个对象归用户rep所属。

下面开始将用户rep拥有的56个对象“移交”给其它的用户：patrol，这里移交的意思就是将对象的所有权转移给其它用户patrol。Sybase ASE中是不支持这么做的。官方的推荐的做法就是重建用户表及其它对象。我这里提供的方法是“非官方”的，或许会存在问题，不过我在多次测试后没发现问题。建议大家在测试开发环境上可以这么做。

但是，我感觉这个方法是可行的。在文章后面我将给出验证方法。

启用服务器选项“allow updates to system tables”来允许修改系统表，在用户事务内修改表数据来回退错误的操作步骤。

1>begin tran

2>go

1>update sysobjects

2>set uid = 3

3>where uid = 5

4>go

(56 rows affected)

1>commit

2>go

以上就将系统表sysobjects中记录对象拥有者uid的信息由rep改成了patrol。内存中的元数据信息是没有办法改的，如果马上进行查询数据库的操作会报错的，也就是说ASE服务器还是“固执”认为被修改所属者的那些表还是属于原来所有者的。如果让ASE认为被修改的这些表属于patrol而不是原来的rep了，方法是重新装载元数据信息。以前的ASE版本中可以通过重启ASE服务器，现在我们可以用dbcc dbreboot命令来重启某个用户数据库，而不是所有的库了。

执行dbcc dbreboot(“reboot”,ddb)，shutdown是个系统关键字，需要加双引号。

1>dbcc dbreboot("reboot",ddb)

2>go

---------- Shutting Down Database 'ddb' ----------

Msg 2202, Level 16, State 1:

Server 'TEST', Line 1:

You cannot start database shutdown from the database to be shut down.

---------- Operation on Database 'ddb' Failed ----------

必须在master数据库内部执行这个命令：dbcc dbreboot("reboot",ddb)

1>use master

2>go

1>dbcc dbreboot("reboot",ddb)

2>go

---------- Shutting Down Database 'ddb' ----------

---------- Re-starting Database 'ddb' With Recovery ----------

Recovering database 'ddb'.

Started estimating recovery log boundaries for database 'ddb'.

Database 'ddb', checkpoint=(26118, 15), first=(26118, 15), last=(26125, 13).

Completed estimating recovery log boundaries for database 'ddb'.

Started ANALYSIS pass for database 'ddb'.

Completed ANALYSIS pass for database 'ddb'.

Started REDO pass for database 'ddb'. The total number of log records to process

is 237.

Redo pass of recovery has processed 1 committed and 2 aborted transactions.

Completed REDO pass for database 'ddb'.

Recovery of database 'ddb' will undo incomplete nested top actions.

Started filling free space info for database 'ddb'.

Completed filling free space info for database 'ddb'.

Started cleaning up the default data cache for database 'ddb'.

Completed cleaning up the default data cache for database 'ddb'.

Recovery complete.

Database 'ddb' is now online.

---------- Operation on Database 'ddb' Completed Successfully ----------

现在，rep拥有的56个对象现在属于patrol用户了。开始验证一下吧。

1>use ddb

2>go

1>select uid,count(*) from sysobjects

2>group by uid

3>go

 uid

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

           1          43

           3          56

 

(2 rows affected)

sysobjects表中uid由5变成3了。

随便找两个表测试一下，

1>select top 2 id,user_name(uid) as username,name  from sysobjects

2>where type='U' and uid = 3

3>go

 id          username

         name

 

 

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

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

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

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

  1392004959 patrol

         config

 

 

   912003249 patrol

         conn_properties

 

(2 rows affected)

 

1>select count(*) from patrol.config

2>go

 

 -----------

          25

 

(1 row affected)

1>select count(*) from patrol.conn_properties

2>go

 

 -----------

           0

 

(1 row affected)

查询这两个表的数据是正常的。

切换到用patrol用户登录，

C:\Documents and Settings\Administrator>isql -Upatrol -Psybase -Stest

1> use ddb

2> go

1> select count(*) from config

2> go

 

 -----------

          25

 

(1 row affected)

同样没有问题。再来验证一下，依赖用户表的

在用户表config上点右键，属性

点 依赖性 按钮，

可以看到一些存储过程依赖用户表config，没有什么问题。

查看依赖表config的其它对象用如下的SQL语句：

select U.name as username ,O.name as object_name, O.type as object_type

 

from dbo.sysdepends D, dbo.sysobjects O, dbo.sysusers U

 

where O.uid = U.uid and O.id = D.id and D.depid = object_id('patrol.config')

 

--and O.type = 'P'

查看自定义数据类型被引用的情况：

select user_name(T.uid) as datatype_owner,T.name as datatype_name, U.name as user_name,O.name as object_name,C.name as column_name ,O.type as object_type

 

from dbo.systypes T, dbo.sysusers U, dbo.syscolumns C, dbo.systypes P,dbo.sysobjects O

 

where T.uid = U.uid and T.usertype = C.usertype and C.id = O.id

 

and T.usertype >= 100 and T.type = P.type

 

and P.usertype = (select min(usertype) from ddb.dbo.systypes where type = T.type )

后面还有一些工作要做，使用下面的SQL语句查看数据库ddb内部有哪些表有uid这一列。下面的思路可能有点片面，但是，我感觉Sybase ASE内与用户编号相关的应该用uid这个列名吧？

select object_name(c.id) as object_name, o.type

from dbo.syscolumns c,dbo.sysobjects o

where  c.id = o.id and c.name='uid'

 go

与uid相关的对象有8个，排除最后一个视图：sysquerymetrics，需要处理其余7个系统表。

在我们的这个例子中，“移交”对象的所有权不涉及到修改用户表sysusers数据的情况，对象信息表sysobjects在上面已经修改过了，在ASE15.0.3文档中sysencryptkeys被解释为留作将来使用，sysusermessages用来存储用户自定义消息，sysqueryplans用来存储抽象查询计划，sysquerymetrics用来存储性能监控指标，这三张表（sysusermessages、sysqueryplans、sysquerymetrics）都都没有数据。

最后只剩下两张系统表：systype、sysprotects需要进一步处理。

select uid,usertype,name from dbo.systypes

where uid = 5

go

发现系统表systypes存储了用户rep自定义的数据类型，

仿照前面修改sysobjects中uid相似的方法，改成systypes存储的rep创建的数据类型归patrol拥有。

use ddb

go

begin tran

go

update systypes

set uid = 3

where uid = 5

go

commit

go

这样，rep自定义的数据类型就归patrol用户所有了。

下面查看关于sysproctects系统表的信息，这个表主要存储为用户、组和角色授予或撤消的权限的信息。

select * from sysprotects

where uid = 5 or grantor = 5

go

grantor列表示授予者的意思。其实只要将授予者由原来的rep改成现在的patrol即可，既然以前rep没有授予给其他用户权限，那么此处不需要进行修改了。

最后总结一下，在ASE15.0.3版本中，估计其它的ASE15.x也是大同小异，移交用户的所有权需要修改7个系统表的数据。在我的测试环境中仅修改了2个系统表（sysobjects和systypes）。这7个系统表是：sysobjects,systypes,sysusers,sysqueryplans,sysquerymetrics,sysprotects, sysencryptkeys。

批量修改一遍就行了，

update sysobjects set uid = 3  where uid = 5

update systypes set uid = 3  where uid = 5

update sysusers set uid = 3  where uid = 5

update sysqueryplans set uid = 3  where uid = 5

update sysquerymetrics set uid = 3  where uid = 5

update sysprotects set uid = 3  where uid = 5

update sysencryptkeys set uid = 3  where uid = 5这个暂时不需要!

最后重启ASE数据库服务器或者只重启修改的那个用户数据库就可以了。

有什么不妥当的地方，欢迎指正！

相关文章

• 2013-09-05 -- 查找没有授予给其它用户权限的表以及权限 (0)
• 2012-09-26 -- dbcc配置过程 (0)
• 2010-08-23 -- 利用dbcc writepage命令修改SQL SQLSERVER中的物理页面上的内容 (3)
• 2010-02-23 -- 成功恢复drop table的表内数据 (3)
• 2009-11-18 -- SQL SERVER DBCC命令解释 (0)

同样，本文仅仅演示dbcc writepage的使用，您在操作时出现的任何后果与本人无关。

dbcc writepage的语法为：

　　　dbcc writepage ({ dbid, ‘dbname’ }, fileid, pageid, offset, length, data)

下面演示dbcc writepage的使用方法：

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

第一步：创建一个测试表

1> create table test (id int not null,name varchar(30) null)
2> go
1> insert into test
2> select 1,'china'
3> go

(1 行受影响)
1> insert into test
2> select 2,'beijing'
3> go

(1 行受影响)

1> select object_id('test')
2> go

-----------
 1877581727

(1 行受影响)

表的ID为： 1877581727。

第二步：查看表内数据所在的页面号

1> select * from sysindexes
2> where id = 1877581727
3> go
id          status      first    indid  root     minlen keycnt groupid dpages
   reserved    used        rowcnt               rowmodctr   reserved3 reserved4
xmaxlen maxirow OrigFillFactor StatVersion reserved2   FirstIAM impid  lockflags
 pgmodctr    keys
                                                                name

                                 statblob

                                                    maxlen      rows
----------- ----------- -------- ------ -------- ------ ------ ------- ---------
-- ----------- ----------- -------------------- ----------- --------- ---------
------- ------- -------------- ----------- ----------- -------- ------ ---------
 ----------- -------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------- ----------------
--------------------------------------------------------------------------------
-------------------------------- -----------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
--------------------------------------------------- ----------- -----------
 1877581727           0 0x3B4F00       0 0x000000      8      0       1
 1           2           2                    2           2         0         0
     57       0              0           0           0 0x3C4F00      0         0
           0 NULL
                                                               NULL

                                 NULL

                                                           8000           2

(1 行受影响)

查询属于test表的第一个数据页的页号，在sysindexes表中first列表示对象的第一个物理存储页的页号：0x384F00，也就是页号（1：20283）。

第三步：查询修改前的数据内容

下面查询修改前页面（1，20283）上的数据内容。可以看出（1，20283）页上有2行记录，这和插入的2行记录数保持一致。然后，观察到页面的头部有china和beijing的字样，

这和插入的2行记录内容“似乎”一致。

下面我用红色标记了test表中两行测试数据的内容。1,'china'    2,'beijing'

1> dbcc page(9,1,20283,2)
2> go

DATA:
Memory Dump @0x518FC000

518FC000:   01010400 00800001 00000000 00000800 ?................

518FC010:   00000000 00000200 aa000000 721f8a00 ?............r...

518FC020:   3b4f0000 01000000 92010000 75000000 ?;O..........u...

518FC030:   02000000 00000000 00000000 00000000 ?................

518FC040:   01000000 00000000 00000000 00000000 ?................

518FC050:   00000000 00000000 00000000 00000000 ?................

518FC060:   30000800 01000000 0200fc01 00140063 ?0..............c

518FC070:   68696e61 30000800 02000000 0200fc01 ?hina 0...........

518FC080:   00160062 65696a69 6e670000 21212121 ?...beijing ..!!!!

518FC090:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

518FC0A0:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

........... 这些是未分配使用的空间

518FDFC0:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

518FDFD0:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

518FDFE0:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

518FDFF0:   21212121 21212121 21212121 74006000 ?!!!!!!!!!!!!t.`.

OFFSET TABLE:

Row - Offset

1 (0x1) - 116 (0x74)

0 (0x0) - 96 (0x60)

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

第四步：修改物理数据页面的内容

通过上面的dbcc page输出结果，仔细数了一下，china这列内容的偏移为111，将china这五个字符改成aaaa。这是最简单的。a的asicc为：97（0x61）。

1> db cc writepage(9,1,20283,111,5,0x6161616161)
2> go
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

第五步：查看修改后的物理页面的内容

1> dbcc page(9,1,20283,2)
2> go

DATA:
Memory Dump @0x5002C000

5002C000:   01010400 00820001 00000000 00000800 ?................

5002C010:   00000000 00000200 aa000000 721f8a00 ?............r...

5002C020:   3b4f0000 01000000 92010000 75000000 ?;O..........u...

5002C030:   02000000 00000000 00000000 8234666e ?.............4fn

5002C040:   00000000 00000000 00000000 00000000 ?................

5002C050:   00000000 00000000 00000000 00000000 ?................

5002C060:   30000800 01000000 0200fc01 00140061 ?0..............a

5002C070:   61616161 30000800 02000000 0200fc01 ?aaaa 0...........

5002C080:   00160062 65696a69 6e670000 21212121 ?...beijing ..!!!!

5002C090:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

5002C0A0:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

5002C140:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

5002C150:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

..................省略未占用空间

5002DFE0:   21212121 21212121 21212121 21212121 ?!!!!!!!!!!!!!!!!

5002DFF0:   21212121 21212121 21212121 74006000 ?!!!!!!!!!!!!t.`.

OFFSET TABLE:

Row - Offset

1 (0x1) - 116 (0x74)

0 (0x0) - 96 (0x60)

DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。

第六步：通过客户端工具验证修改后的数据内容

1> select * from test
2> go
id          name
----------- ------------------------------
          1 aaaaa
          2 beijing

(2 行受影响)
可以看到第一行记录的name列由china改为了aaaaa

备注： 以上演示的是仅仅修改某一行某一列的数据，并且修改后的内容和修改前的内容保持长度一致。

如果修改多列或者修改前后的字段长度不一致；进一步修改整行数据，或者修改整页的数据的话，可能会复杂许多。

————————————————————————————————-
—- 本文为andkylee个人原创，请在尊重作者劳动成果的前提下进行转载；
—- 转载务必注明原始出处 : http://www.dbainfo.net
—- 关键字：dbcc writepage undocumented command 修改 物理页面 page
————————————————————————————————-

相关文章

• 2009-11-18 -- SQL SERVER DBCC命令解释 (0)
• 2019-04-11 -- SQL Server 数据库修复专家SQLRescue (0)
• 2012-09-26 -- dbcc配置过程 (0)
• 2010-12-27 -- 使用重启数据库的未认证DBCC命令来移交表的所有权 (2)
• 2010-11-03 -- SQL2005 如何更新系统表 (2)
• 2010-09-28 -- SQL SERVER中查看表占用空间的另外一种方法 (0)
• 2010-09-16 -- Java连接SQL Server数据库的一个简单例子 (0)
• 2010-09-15 -- 统计SQL SERVER数据库内所有表占用空间并排序 (0)
• 2010-09-06 -- SQL Server的链接服务器技术小结[转] (0)
• 2010-08-29 -- 从oracle内访问sqlserver2005的数据时一个错误 (0)

这是一篇受密码保护的文章。您需要提供访问密码：

密码：

相关文章

• 2013-06-02 -- Sybase数据库恢复工具 (0)
• 2013-06-02 -- (0)
• 2010-02-25 -- MSSQLSERVER利用日志恢复drop table的表数据[转] (0)
• 2012-06-22 -- Sybase SQL Anywhere(ASA)数据库非常规恢复工具 (0)
• 2012-06-11 -- 研发成功了从Sybase SQL Anywhere的DB文件上恢复数据的工具 (3)
• 2009-11-18 -- Sybase Adaptive Server Enterprise(ASE)数据库恢复工具 (2)
• 2019-04-12 -- Sybase ASE及SQL Anywhere数据库修复专家 (0)
• 2019-04-11 -- SQL Server 数据库修复专家SQLRescue (0)
• 2015-01-16 -- master数据库配置区域(configuration area)损坏的一种修复方法 (1)
• 2012-09-26 -- dbcc配置过程 (0)

--说明：
--260：打印关于扩展存储过程动态链接库的版本信息
--444：停止auto-parameterization
--1200：输出锁信息
--1204：传回参与死锁的SQL SERVER相关程序之运行数据
--1211：停止lock escalation（锁升级）
--1252：显示动态选择锁的相关信息
--2528：通过 DBCC CHECKDB、DBCC CHECKFILEGROUP 和 DBCC CHECKTABLE 禁用对象的并行检查。
--默认情况下，并行度由查询处理器自动确定。最大并行度的配置方式与并行查询相同。
--有关更多信息，请参见 max degree of parallelism 选项。
-- 通常情况下，应将并行 DBCC 保留为启用状态。执行 DBCC CHECKDB 时，
-- 查询处理器重新评估和自动调整并行度，并检查每个表或一批表。
--有时，检查可能在服务器处于实际空闲状态时进行。如果管理员知道在检查结束前负荷将加大，
--可能希望手工减小或禁用并行度。
-- 但是，禁用并行检查会导致数据库的总体性能降低。降低并行度将增加必须扫描的事务日志量。
--这反过来增加了对 tempdb 空间的需求，并导致 dbcc 完成检查所需的时间非线性增加。
--如果运行 DBCC 时启用了 TABLOCK 功能并关闭了并行度，则表可能被锁定更长时间。
--3205：默认情况下，如果磁带驱动器支持硬件压缩，则 DUMP 或 BACKUP 语句会使用该功能。
-- 利用此跟踪标记，可以禁用磁带驱动程序的硬件压缩。
-- 本项在要与不支持压缩的其它站点或磁带驱动器交换磁带时有用。
--3604：将trace结果输出到前端
--3605：要求DBCC的输出放到SQL server ERROR LOG
--8602：停止索引提示功能
--8722：停止join group等最优化提示功能
--8755：停止锁提示功能
--8780：停止最优化超时配置，强制做完整的最优化动作
------------------------------------------------------
--2 DBCC page
dbcc traceon(3604)
dbcc page(northwind,1,100,1)
/*查询northwind 的数据的第101个页面的信息*/
/*DBCC Page ({dbid|dbname},filenum,pagenum[,printopt])
?
具体参数描述如下：
dbid: 包含页面的数据库ID
dbname:包含页面的数据库的名称
filenum:包含页面的文件编号
pagenum:文件内的页面
printopt:可选的输出选项；选用其中一个值：
0:默认值，输出缓冲区的标题和页面标题
1:输出缓冲区的标题、页面标题(分别输出每一行)，以及行偏移量表
2:输出缓冲区的标题、页面标题(整体输出页面)，以及行偏移量表
3:输出缓冲区的标题、页面标题(分别输出每一行)，以及行偏移量表；每一行后跟分别列出的它的列值
*/
------------------------------------------------------
--3 DBCC checkalloc
DBCC checkalloc（northwind)
/*检查指定数据库的系统表内和表间的一致性
checkalloc是检查指定数据库，看其所有正确分配的页和尚未分配的页的情况。
若未指定数据库名，则checkalloc检查当前数据库。checkalloc会返回已分配的和使用的空间数量。
checkalloc的缺省模式为nofix，要使用fix选项，必须把数据库置于单用户模式。
*/
-----------------------------------------------------
--4 DBCC checkcatalog
DBCC checkcatalog(northwind)
/*
检查批定数据库的系统表内和系统表间的一致性
*/
-----------------------------------------------------
--5 DBCC checkconstraints
DBCC checkconstraints(products)
/*
检查指定表上的指定约束或所有约束的完整性
DBCC CHECKCONSTRAINTS
[('table_name'|'constraint_name'
)]
[WITH {ALL_ERRORMSGS|ALL_CONSTRAINTS}]
DBCC CHECKCONSTRAINTS在某个数据库中，检测某些特定的约束或者全部约束的一致性。
DBCC CHECKCONSTRAINTS总是在当前数据库的上下文环境中执行。
　　注意，DBCC CHECKCONSTRAINTS并不进行磁盘或者文件级别的一致性检测;
它只是确保外键定义的一致性，同时检测约束——仅仅是确认数据有效。
如果你希望检测磁盘上表和索引的一致性，
你应该执行DBCC CHECKDB或者在所有的表上执行DBCC CHECKALLOC和 DBCC CHECKTABLE的组合。
*/
------------------------------------------------------
--6 DBCC checkdb
DBCC checkdb
/*
检查数据库中的所有对象的分配和结构完整性
checkdb [('database_name'[, NOINDEX | REPAIR])]
[WITH NO_INFOMSGS[, ALL_ERRORMSGS][, PHYSICAL_ONLY]
[, ESTIMATEONLY][, TABLOCK]]
*/
-----------------------------------------------------
--7 DBCC cleantable
DBCC cleantable
/*
回收alter table drop column语句 删除可变长度列或text列后的存储空间
cleantable ('database_name'|database_id, 'table_name'|table_id, [batch_size])
*/
-----------------------------------------------------
--8 DBCC dbreindex
DBCC dbreindex
/*
重建指定数据库的一个或多个索引
dbreindex ('table_name' [, index_name [, fillfactor ]]) [WITH NO_INFOMSGS]
*/
-----------------------------------------------------
--9 DBCC indexdefrag
DBCC indexdefrag
/*
对表或视图上的索引和非聚集索引进行碎片整理
indexdefrag ({dbid | dbname | 0}, {tableid | tablename}, {indid | indname})
*/

在小规模环境下，DBCC INDEXDEFRAG的结果比DBCC DBREINDEX要好一些。不过，在大多数情况下，完全重建索引应该具有更好的性能。
当DBCC INDEXDEFRAG运行在一个动态的系统上，即数据保持在线更新，DBCC INDEXDEFRAG会跳过那些被锁住的页。因此DBCC INDEXDEFRAG也许就无法完全消除碎片。要衡量DBCC INDEXDEFRAG发挥了多大作用，可以在DBCC INDEXDEFRAG后立刻运行DBCC SHOWCONTIG。
DBCC DBREINDEX完全重建索引

--------------------------------------------------------
--10 DBCC pintable/DBCC unpintable
--将表数据驻留在内存中或撤销驻留 在内存中的数据
--pintable (database_id, table_id)
----------------------------------------------------------
--11 DBCC shrinkdatabase
--收缩指定数据库的数据文件和日志文件大小
--shrinkdatabase ({dbid | 'dbname'}, [freespace_percentage [, {NOTRUNCATE | TRUNCATEONLY}]])
----------------------------------------------------------
--12 DBCC shrinkfile
--收缩相关数据库的指定数据文件和日志文件大小
--shrinkfile ({fileid | 'filename'}, [compress_size [, {NOTRUNCATE | TRUNCATEONLY | EMPTYFILE}]])
------------------------------------------------------------
--13 DBCC dllname(free)
--在内存中制裁指定的扩展想念过程动态链接库（DLL）
sp_helpextended proc
--查询当前内存中的扩展存储过程动态链接库
-------------------------------------------------------------
--14 DBCC dropcleanbuffers
--从缓冲池中删除所有缓冲区
/*
使用 DBCC DROPCLEANBUFFERS 测试带有冷高速缓存的查询，而不用关闭和重新启动服务器
*/
---------------------------------------------------------------
--15 DBCC freeproccache
--从过程缓冲区删除所有元素
--清理所有数据库的过程高速缓存
-----------------------------------------------------------------
--16 DBCC inputButter
--显示从客户机发送到服务器的最后一个语句
-------------------------------------------------------------
--17 DBCC opentran
--查询某个数据库执行时间最久的事务，由哪个程序拥有
----------------------------------------------------------------
--18 DBCC show_statistics
--显示指定表上的指定目前的当前分布统计信息
------------------------------------------------------------------
--19 DBCC showcontig
--显示指定表的数据和索引的碎片信息
-----------------------------------------------------------------
--20 DBCC sqlperf
--可用参数logspace,iostats,threads
--返回多种有用的统计信息
---dbcc sqlperf(logspace)
Database Name Log Size (MB) Log Space Used (%) Status
-------------------------------------------------------------------------------------------------------------------------------- ------------------------ ------------------------ -----------
master 5.0546875 27.93663 0
tempdb 0.7421875 58.88158 0
model 0.4921875 74.206352 0
msdb 2.2421875 38.414635 0
pubs 0.7421875 43.947369 0
Northwind 0.9921875 41.732285 0
db40cdr 32.304688 6.3618503 0
fcdb 218.30469 79.981796 0
fcdb_20070826 19.992188 3.0138726 0
test 176.92969 6.4423542 0
kldb 0.9921875 33.267715 0
--dbcc sqlperf(iostats)
Statistic Value
-------------------------------- ------------------------
Reads Outstanding 0.0
Writes Outstanding 0.0
--dbcc sqlperf(threads)
Spid Thread ID Status LoginName IO CPU MemUsage
------ ----------- ---------- ---------- ---------------------- ----------- -----------
1 NULL background NULL 0 0 0
2 NULL background NULL 0 0 5
3 NULL sleeping NULL 0 0 0
4 NULL background NULL 0 0 -6
5 0 background sa 41 0 3
6 NULL sleeping NULL 1 0 0
7 0 background sa 0 0 3
8 0 background sa 0 0 3
9 0 background sa 0 0 3
10 0 background sa 0 0 3
11 0 background sa 0 0 3
12 0 background sa 0 0 3
51 0 sleeping RD-001\Adm 19 32 29
52 0 sleeping RD-001\Adm 6 515 15
53 3828 runnable RD-001\Adm 1 15 5
------------------------------------------------------------------
--21 DBCC cachestats
--显示SQL SERVER内存的统计信息
-----------------------------------------------------------------
--22 DBCC cursorstats
--显示SQL SERVER游标的统计信息
------------------------------------------------------------------
--23 DBCC sqlmgrstats
--显示缓冲中先读和预先准备的SQL语句
------------------------------------------------------------
--24 DBCC errlog
--初始化SQL SERVER错误日志文件
----------------------------------------------------------
--25 DBCC flushprocindb
--清除SQL SERVER服务器内存中某个数据库的存储过程缓存内容
----------------------------------------------------------
--26 DBCC Buffer
--显示缓冲区的善信息和页面信息
--------------------------------------------------------
--27 DBCC DBinfo
--显示数据库结构信息
------------------------------------------------------------
--28 DBCC DBtable
--显示管理数据的表信息
-----------------------------------------------------------
--29 DBCC IND
--查看某个索引使用的页面信息
-------------------------------------------------------------
--30 DBCC REbuild_log
--重建SQL SERVER事务日志文件
------------------------------------------------------------
--31 DBCC log
--查看某个数据库使用的事务日志信息
-----------------------------------------------------------
--32 DBCC procbuf
--显示过程缓冲池中的缓冲区头和存储过程头
------------------------------------------------------------
--33 DBCC prtipage
--查看某个索引页面的每行指向的页面号
------------------------------------------------------------
--34 DBCC pss
--显示当前连接到SQL SERVER的进程信息
-----------------------------------------------------------
--35 DBCC resource
--显示服务器当前使用的资源情况
------------------------------------------------------------
--36 DBCC tab
--查看数据页面的结构
----------------------------------------------------------

1. DBCC CHECKDB
　　重启服务器后，在没有进行任何操作的情况下，在SQL查询分析器中执行以下SQL进行数据库的修复，修复数据库存在的一致性错误与分配错误。

 
use master
declare @databasename varchar(255)
set @databasename='需要修复的数据库实体的名称'
exec sp_dboption @databasename, N'single', N'true' --将目标数据库置为单用户状态
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
exec sp_dboption @databasename, N'single', N'false'--将目标数据库置为多用户状态

然后执行 DBCC CHECKDB('需要修复的数据库实体的名称') 检查数据库是否仍旧存在错误。注意：修复后可能会造成部分数据的丢失。

2. DBCC CHECKTABLE
如果DBCC CHECKDB 检查仍旧存在错误，可以使用DBCC CHECKTABLE来修复。
use 需要修复的数据库实体的名称
declare @dbname varchar(255)
set @dbname='需要修复的数据库实体的名称'
exec sp_dboption @dbname,'single user','true'
dbcc checktable('需要修复的数据表的名称',REPAIR_ALLOW_DATA_LOSS)
dbcc checktable('需要修复的数据表的名称',REPAIR_REBUILD)
------把’ 需要修复的数据表的名称’更改为执行DBCC CHECKDB时报错的数据表的名称
exec sp_dboption @dbname,'single user','false'

3. 其他的一些常用的修复命令
DBCC DBREINDEX 重建指定数据库中表的一个或多个索引
用法：DBCC DBREINDEX (表名,’’) 修复此表所有的索引。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

SQL SERVER数据库的检测及修复方法
随着K/3产品的推广，要求客户服务人员对SQL SERVER数据库的了解也进一步提高。在K/3的使用过程中，数据库文件被频繁地使用，由于某些原因，数据库有可能被损坏，本文将针对这种情况的数据库检测及修复方法做一简单讲解。希望各位在实际工作过程中有新的发现时，及时给我们提供信息，以便做进一步的更新。
1.1 SQL SERVER数据库的检测
SQL SERVER提供了数据库检测的命令，可用DBCC CHECKDB对数据库中各个对象的分配及结构的正确性进行检测，并可通过一参数控制，将所有的错误信息显示出来。其语法如下：
DBCC CHECKDB
('database_name' [,NOINDEX | { REPAIR_ALLOW_DATA_LOSS
| REPAIR_FAST
| REPAIR_REBUILD
}]
) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
参数说明：
'database_name'代表被检测的数据库实体名；
NOINDEX指非系统表的非聚族索引不检测；
REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST| REPAIR_REBUILD 指直接修复发现的错误，其中REPAIR_ALLOW_DATA_LOSS代表，若此错误不能修复时，系统将直接删除相关数据。带此三个参数的任一个时，数据库必须处于单用户模式，可在Enterprise Manager中的数据库属性中设置；
ALL_ERRORMSGS代表将检测到的错误信息全部显示出来，否则，对于每张表最多只显示200条错误信息；
NO_INFOMSGS代表隐藏所有的信息及占用空间的报告。
经过检测，对于错误的对象，将以OBJECT ID的形式报告具体出错的信息，可根据OBJECT ID到系统表sysobjects中查找到相关的表，即NAME。

1.2 SQL SERVER问题数据库的修复
经过数据库检测后，可针对出现的问题采取相应的措施进行处理。如通过检测后，发现对象的物理存放存在问题，可用DBCC CHECKALLOC来进行修复：
DBCC CHECKALLOC ('database_name' | REPAIR_REBUILD }] ) [WITH {ALL_ERRORMSGS | NO_INFOMSGS}]
若是非系统对象的索引出错，则可用DBCC DBREINDEX进行修复：
DBCC DBREINDEX ( [ 'database.owner.table_name' [, index_name [, fillfactor ] ] ] ) [WITH NO_INFOMSGS]
以上两种情况，也可直接使用DBCC CHECKDB(‘db_name’,repair_rebuild)来修复。
另外一种情况是在进行检测时，提示无法建立数据连接，此时表明，数据库已损坏。对于这种情况，我们可采取如下措施来尝试修复。
首先，在SQL Enterprise中新建一数据库（如数据库名为test）,建好数据库后，停止SQL Server Service Manager，并将客户数据库的MDF文件更名为test _data.mdf(即新建数据库的主文件名)，然后用更名后的文件覆盖新建数据库同名文件，接着，启动SQL Server Service Manager。对Master数据库将系统表设置为可更改状态
Use Master
Go
sp_configure 'allow updates', 1
reconfigure with override
Go
将数据库设为紧急状态：
update sysdatabases set status = 32768 where database '
停止并重新启动SQL Server Service Manager，并重建Log文件：
DBCC TRACEON (3604)
DBCC REBUILD_LOG(' test ','test _log_ldf')
将数据库设置为单用户模式，然后进行检测：
sp_dboption ' test ', 'single user', 'true'
DBCC CHECKDB(' test ')
Go
此数据库执行CHECKDB的过程中发现一些表的索引被破坏，于是针对具体的表进行重建索引的操作：
DBCC DBREINDEX（表名）
如执行以上操作仍然不能解决，若索引破坏的表是临时表或不是关键表，则可从新建账套中引入，若是主表，则可能通过近期的备份来（部份）恢复。若没有一个备份，则无法修复。

1.3 SQL Server数据库为什么易损坏呢？
以下是微软提供的一些可能引起数据库损坏的原因及一些预防措施：
操作问题，包括冷起动机器、热拔硬盘、删除一些数据库文件；
硬件问题，包括磁盘控制器的问题；
操作系统问题，包括与系统相关的一些致命错误。

1.4 预防措施：
1、定期/不定期执行CHKDSK(不带参数)，以检测硬盘物理结构并修复一些CHKDSK报告的问题；
2、常备份数据。

1.5 应用数据库修复举例
declare @databasename varchar(255)
set @databasename='AIS20021224170730'------一定要手工输入
---------执行一般性修复还存在问题时,进行允许数据丢失的修复
---------许数据丢失的修复要求在单用户下进行,此时请退出中间层,客户端,sql的其他模块
---所有功能退出,在查询分析器master里设置数据库为单用户

exec sp_dboption @databasename, N'single', N'true'

-----在查询分析器master里,进行修复数据库
dbcc checkdb(@databasename,REPAIR_ALLOW_DATA_LOSS)
dbcc checkdb(@databasename,REPAIR_REBUILD)
------还原数据库状态
exec sp_dboption @databasename, N'single', N'false'

第2章数据库日志损坏的修复
请遵照如下步骤来试图重建数据库事务日志.

注意: 由于事务日志丢失, 数据库可能有没有提交的数据.

注:都要替换成真实的数据库名字

2.1 步骤1:

创建一个新的数据库,命名为原来数据库的名字.

2.2步骤2:

停止SQL Server

2.3步骤3:

把老数据库的MDF文件替换新数据库的相应的MDF文件, 并把LDF文件删除

2.4步骤4:

重新启动SQL Server 服务,然后运行如下命令:

Use Master

Go

sp_configure 'allow updates', 1

reconfigure with override

Go

begin tran

update sysdatabases set status = 32768 where db_name'

-- Verify one row is updated before committing

commit tran

2.5步骤5:

停止SQL然后重新启动SQL Server 服务,然后运行如下命令:

DBCC TRACEON (3604)

DBCC REBUILD_LOG('db_name','c:\mssql7\data\dbxxx_3.LDF')

Go

2.6步骤6:

停止SQL然后重新启动SQL Server 服务,然后运行:

use master

update sysdatabases set status = 8 where
Go

sp_configure 'allow updates', 0

reconfigure with override

Go

2.7步骤7:
运行dbcc checkdb(db_name)检查数据库的完整性.

第3章 数据库质疑的一般处理
1、执行如下SQL（打开修改系统表的开关）：
EXEC sp_configure 'allow updates', 1
RECONFIGURE WITH OVERRIDE
2、修改数据库Master中的表：sysdatabases
将 status字段数值更改为4
3、再执行如下SQL：
EXEC sp_configure 'allow updates', 0
RECONFIGURE WITH OVERRIDE。

相关文章

• 2010-08-23 -- 利用dbcc writepage命令修改SQL SQLSERVER中的物理页面上的内容 (3)
• 2019-04-11 -- SQL Server 数据库修复专家SQLRescue (0)
• 2012-09-26 -- dbcc配置过程 (0)
• 2010-12-27 -- 使用重启数据库的未认证DBCC命令来移交表的所有权 (2)
• 2010-11-03 -- SQL2005 如何更新系统表 (2)
• 2010-09-28 -- SQL SERVER中查看表占用空间的另外一种方法 (0)
• 2010-09-16 -- Java连接SQL Server数据库的一个简单例子 (0)
• 2010-09-15 -- 统计SQL SERVER数据库内所有表占用空间并排序 (0)
• 2010-09-06 -- SQL Server的链接服务器技术小结[转] (0)
• 2010-08-29 -- 从oracle内访问sqlserver2005的数据时一个错误 (0)