?
CS模式下，數據是放在客戶本地的服務器上。而大部分客戶并沒有專業能力去維護他們的SQL Server，老版本數據庫系統設置更是較舊。因此，總是遇到客戶反饋的損壞問題。客戶 alter 或 drop 某個存儲過程、或者打開存儲過程列表時，執行中止并提示“架構損壞”。
-- checkdb 中斷報錯DBCC CHECKDB(DBName)
-- 類似的，修復也報錯DBCC CHECKDB (dbname, REPAIR_ALLOW_DATA_LOSS);
CHECKDB 在數據庫 'dbname' 中發現 0 個分配錯誤和 0 個一致性錯誤。
DBCC 執行完畢。如果 DBCC 輸出了錯誤信息，請與系統管理員聯系。
消息 211，級別 23，狀態 16，第 1 行
可能發生了架構損壞。請運行 DBCC CHECKCATALOG。
除了這些錯誤信息，完全不知道哪些表有問題。又對這個庫的所有表都 checktable ，也無報錯。可以確認，當前的表結構及數據是沒問題的，斷定是當前數據庫的系統表出現了問題。
好吧，打開 Profiler 跟著（RPC:Startding、RPC:Completed、SP:Startding、SP:Completed、SP:StmtStartding、SP:StmtCompleted、SQL:…），甚至還跟蹤了鎖的請求及釋放（有點多余了）。然后刪除某報錯的存儲過程，跟蹤到以下SQL：
圖一
把以上跟蹤出現的涉及表查詢一遍：
select * from sys.all_objectsselect * from sys.database_principalsselect * from sys.sql_modulesselect * from sys.system_sql_modules
發現是系統視圖 sys.sql_modules 報錯！該視圖返回函數、視圖、存儲過程的定義。查看該視圖的定義：
sp_helptext 'sys.sql_modules'
--定義CREATE VIEW sys.sql_modules AS SELECT object_id = o.id, definition = object_definition(o.id), uses_ansi_nulls = sysconv(bit, o.status & 0x40000), -- OBJMOD_ANSINULLS uses_quoted_identifier = sysconv(bit, o.status & 0x80000), -- OBJMOD_QUOTEDIDENT is_schema_bound = sysconv(bit, o.status & 0x20000), -- OBJMOD_SCHEMABOUND uses_database_collation = sysconv(bit, o.status & 0x100000), -- OBJMOD_USESDBCOLL is_recompiled = sysconv(bit, o.status & 0x400000), -- OBJMOD_NOCACHE null_on_null_input = sysconv(bit, o.status & 0x200000), -- OBJMOD_NULLONNULL execute_as_principal_id = x.indepid FROM sys.sysschobjs o LEFT JOIN sys.syssingleobjrefs x ON x.depid = o.id AND x.class = 22 AND x.depsubid = 0 -- SRC_OBJEXECASOWNER WHERE o.pclass <> 100 -- x_eunc_Server AND ((o.type = 'TR' AND has_access('TR', o.id, o.pid, o.nsclass) = 1) OR (type IN ('P','V','FN','IF','TF','RF','IS') AND has_access('CO', o.id) = 1) OR (type IN ('R','D') AND o.pid = 0))
可以看到2個系統視圖： sys.sysschobjs、sys.syssingleobjrefs。但是，這2個系統視圖是無法直接查詢的，難道到這里就終止了嗎？不可能的！~
要查看這些系統視圖，我們需要以專用管理員連接(DAC) 訪問。添加 “-m” 到啟動參數，然后重啟服務。
圖二
直接點擊一個查詢窗口，以DAC管理員訪問：admin:<instancename>
圖三
好了，進入損壞的數據庫，查詢系統視圖：
select * from sys.sysschobjsselect * from sys.syssingleobjrefs
其實，這些系統視圖，等價于我們常看到的那些系統視圖。
Sysobjects = sys.sysschobjs
Syscolumns = sys.syscolpars
Sysindexes = sys.sysidxstats
廢話不多說，再執行視圖sys.sql_modules 的定義中的一部分sql：
SELECT object_id = o.id, definition = object_definition(o.id)FROM sys.sysschobjs o LEFT JOIN sys.syssingleobjrefs x ON x.depid = o.id AND x.class = 22 AND x.depsubid = 0
可以確認是 object_definition 獲取定義的函數出錯。回頭看看那個報錯的存儲過程，查看其定義：
select object_definition(id),id from sys.sysschobjs where name='usp_mytest'
果然是報錯的就是它，錯誤就是最開始的信息。但是，不確定是否其他對象也可能出錯，所以執行以下SQL，把所有輸出都執行一遍。
select concat('selelct object_definition(',id,')') from sys.sysschobjs
既然確定了該出錯的信息，那么就只能把該行數據刪掉了！那要刪除哪些表呢？以下這些表，可以都查看一遍，與對象id相關的，都可以查詢出來刪掉。
select id,name,type,concat('select * from sys.',name) from sys.sysschobjs WHERE NAME LIKE 'sys%' order by type,NAME
以下幾張表要刪除的：
select id from sys.sysschobjs where name='usp_mytest'
delete from sys.sysschobjs where id=xxxxxxxxxxxdelete from sys.syscolpars where id=xxxxxxxxxxxdelete from sys.syssoftobjrefs where depid=xxxxxxxxxxx
如果只刪除 sys.sysschobjs ，checkdb 的時候還是報以下錯誤，所以把其他相關表也刪除。
Attribute (parent_object_id=xxxxxxxxxxx) of row (object_id=xxxxxxxxxxx) in sys.objects does not have a matching row (object_id=xxxxxxxxxxx) in sys.objects.
再執行 checkdb，發現已經沒有錯誤了。上面提到的一些查詢也操作正常，SSMS存儲過程列表也可以打開了！
-- 可創建原來的存儲過程-- Create procedure usp_mytest ALTER DATABASE dbname SET EMERGENCY;GOALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK IMMEDIATE;GODBCC CHECKDB (dbname) WITH TABLOCKGOALTER DATABASE dbname SET MULTI_USER;GOALTER DATABASE dbname SET ONLINE;GO
此時，可以把啟動參數“-m”去掉，重啟服務！至此，完美解決。checkdb 無法修復的系統對象，通過手動修改解決了！
閱讀原文：原文鏈接
該文章在 2025/1/10 11:08:56 編輯過
400 186 1886
