資料一
1、停止資料庫伺服器,將資料庫MDF檔案和LDF檔案複製備份一份
2、啟動資料庫伺服器,刪除置疑的資料庫
3、僅用備份的資料庫MDF檔案附加資料庫,sp_attach_db或者sp_attach_single_file_db可以附加資料庫,出現類似下面的提示資訊:
裝置啟用錯誤。物理檔案名稱 'C:/Program Files/Microsoft SQL Server/MSSQL/data/myDb_Log.LDF' 可能有誤。
已建立名為 'C:/Program Files/Microsoft SQL Server/MSSQL/Data/myDb_log.LDF' 的新記錄檔。
這個表明資料庫附加成功,問題解決了,如果成功則要恭喜你了,反正我是符加不成功,提示類似下面的錯誤資訊
未能開啟新資料庫 'myDb'。CREATE DATABASE 將終止。
裝置啟用錯誤。物理檔案名稱 'e:/www/myDb_log.LDF' 可能有誤。
此時我用了以下方法解決(參考了網上的方法)。
A.我們SQL SERVER企業管理器建立立一個供恢複使用的同名資料庫(注意:要跟問題資料庫同名,本例中為myDb)。
B.停掉資料庫伺服器。
C.將剛才產生的資料庫的記錄檔myDb_log.ldf刪除(本例中的示列資料庫名,實際使用您自己的資料庫名稱),用剛才備份的資料庫mdf檔案覆蓋新產生的資料庫資料檔案myDb_data.mdf。
D.啟動資料庫伺服器。此時會看到資料庫myDb的狀態為“置疑”。這時候不能對此資料庫進行任何操作。
E.設定資料庫允許直接作業系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器,按右--鍵,選擇“屬性”,在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go F.設定myDb為緊急修複模式
在查詢管理器裡設定如下命令:
update sysdatabases set status=-32768 where dbid=DB_ID('myDb')此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於“唯讀/置疑/離線/緊急模式”可以看到資料庫裡面的表,但是僅僅有系統資料表
G.下面執行真正的恢複操作,重建資料庫記錄檔
dbcc rebuild_log('myDb','C:/Program Files/Microsoft SQL Server/MSSQL/Data/myDb_log.ldf')警告: 資料庫 'myDb' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重設資料庫選項,並且可能需要刪除多餘的記錄檔。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
此時開啟在SQL Server Enterprise Manager裡面會看到資料庫的狀態為“只供DBO使用”。此時可以訪問資料庫裡面的使用者表了。
H.驗證資料庫一致性(可省略)
dbcc checkdb('myDb')一般執行結果如下:
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤(在資料庫 'myDb' 中)。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
I.設定資料庫為正常狀態
sp_dboption 'myDb','dbo use only','false' J.最後一步,我們要將步驟E中設定的“允許對系統目錄直接修改”一項恢複。因為平時直接作業系統表是一件比較危險的事情。當然,我們可以在SQL Server Enterprise Manager裡面恢複,也可以使用如下陳述式完成
sp_configure 'allow updates',0
go
reconfigure with override
go
到此資料庫置疑問題解決。
資料二
MS SQL SERVER資料庫置疑後恢複步驟
--SQL SERVER資料庫置疑後恢複步驟
--1. 恢複步驟:
--a.將smlog_log.ldf檔案備份到其它目錄下;
--b.將來源目錄下的smlog_log.ldf檔案改名為smlog_log_bak.ldf;
--c.執行以下語句修改資料庫的狀態:
use Master
go
update sysdatabases set status=32768 where name='資料庫名稱' --修改狀態,設為緊急狀態
go
shutdown with nowait --停止資料庫伺服器
go
--d.退出SQL並在(COMMAND)命令列模式中通過下面的代碼重新啟動SQL:
sqlservr -c -T3608 -T4022 --安全模式啟動SQL SERVER
--e.在查詢分析器中執行以下語句來查看剛剛修改過狀態的資料庫狀態:
select Name,Status from sysdatabases where Name='資料庫名稱'
--f.執行以下代碼建立記錄檔:
dbcc traceon(3604)--跟蹤
dbcc rebuild_log('資料庫名稱','記錄檔全路徑') --檔案名稱要有全路徑和副檔名
--dbcc rebuild_log('prs_msc','d:/mscsql/mssql/data/prs_msc_log.ldf
--g.將資料庫置回正常狀態:
update sysdatabases set status=0 where name='資料庫名稱'
--h.重新啟動資料庫後執行以下語句檢查資料庫:
DBCC CHECKDB --如果執行完有錯誤用以下語句修複
--i.要修複資料庫必需將資料庫改為單一使用者模式:
Exce sp_dboption '資料庫名稱','single user','true'---('false'恢複多使用者)
--j.執行以下語句修複資料庫:
DBCC CHECKDB('資料庫名稱',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS:是比較進階的修複方式
REPAIR_FAST:是簡單快速的修複方式
/*
處理狀態就為"置疑"的數據庫
備份資料檔案,然後按下面的步驟處理:
1.建立一個同名的資料庫(資料檔案與原來的要一致)
2.再停掉sql server(注意不要分離資料庫)
3.用原資料庫的資料檔案覆蓋掉這個建立的資料庫
4.再重啟sql server
5.此時開啟企業管理器時會出現置疑,先不管,執行下面的語句(注意修改其中的資料庫名)
6.完成後一般就可以訪問資料庫中的資料了,這時,資料庫本身一般還要問題,解決辦法是,利用資料庫的指令碼建立一個新的資料庫,並將資料導進去就行了.
*/
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的資料庫名'
Go
sp_dboption '置疑的資料庫名','single user','true'
Go
DBCC CHECKDB('置疑的資料庫名')
Go
update sysdatabases set status=28 where name='置疑的資料庫名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的資料庫名', 'single user','false'
Go
/*
只有mdf檔案的恢複技術
由於種種原因,我們如果當時僅僅備份了mdf檔案,那麼恢複起來就是一件很麻煩的事情了。
如果您的mdf檔案是當前資料庫產生的,那麼很僥倖,也許你使用sp_attach_db或者sp_attach_single_file_db可以恢複資料庫,但是會出現類似下面的提示資訊
裝置啟用錯誤。物理檔案名稱 'C:/Program Files/Microsoft SQL Server/MSSQL/data/test_Log.LDF' 可能有誤。
已建立名為 'C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.LDF' 的新記錄檔。
但是,如果您的資料庫檔案是從其他電腦上複製過來的,那麼很不幸,也許上述辦法就行不通了。你也許會得到類似下面的錯誤資訊
伺服器: 訊息 1813,層級 16,狀態 2,行 1
未能開啟新資料庫 'test'。CREATE DATABASE 將終止。
裝置啟用錯誤。物理檔案名稱 'd:/test_log.LDF' 可能有誤。
怎麼辦呢?別著急,下面我們舉例說明恢複辦法。
*/
--A.我們使用預設建立一個供恢複使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
--B.停掉資料庫伺服器。
--C.將剛才產生的資料庫的記錄檔test_log.ldf刪除,用要恢複的資料庫mdf檔案覆蓋剛才產生的資料庫資料檔案test_data.mdf。
--D.啟動資料庫伺服器。此時會看到資料庫test的狀態為“置疑”。這時候不能對此資料庫進行任何操作。
--E.設定資料庫允許直接作業系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器,按右--鍵,選擇“屬性”,在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--F.設定test為緊急修複模式
--在查詢管理器裡設定如下命令:
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於“唯讀/置疑/離線/緊急模式”可以看到資料庫裡面的表,但是僅僅有系統資料表
--G.下面執行真正的恢複操作,重建資料庫記錄檔
dbcc rebuild_log('test','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.ldf')
/*
執行過程中,如果遇到下列提示資訊:
伺服器: 訊息 5030,層級 16,狀態 1,行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
說明您的其他程式正在使用該資料庫,如果剛才您在F步驟中使用SQL Server Enterprise Manager開啟了test庫的系統資料表,那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於:
警告: 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重設資料庫選項,並且可能需要刪除多餘的記錄檔。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
此時開啟在SQL Server Enterprise Manager裡面會看到資料庫的狀態為“只供DBO使用”。此時可以訪問資料庫裡面的使用者表了。
*/
--H.驗證資料庫一致性(可省略)
dbcc checkdb('test')
/*一般執行結果如下:
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤(在資料庫 'test' 中)。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。*/
--I.設定資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
--如果沒有出錯,那麼恭喜,現在就可以正常的使用恢複後的資料庫啦。
--J.最後一步,我們要將步驟E中設定的“允許對系統目錄直接修改”一項恢複。因為平時直接作業系統表是一件比較危險的事情。當然,我們可以在SQL Server Enterprise Manager裡面恢複,也可以使用如下陳述式完成
sp_configure 'allow updates',0
go
reconfigure with override
go
--記錄檔出現問題(丟失或檔案格式非法),怎麼使資料庫恢複正常
--如果用sp_attach_single_file 'TEST','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.mdf'失敗則需要用下列步驟完成
--1.將置疑的資料庫分離,將mdf檔案移走或改名!
sp_detach_db 'TEST'
--2.重新在原來目錄下建立同名的資料庫TEST
--3.停掉SQL Service,將先前的mdf檔案拷貝回來覆蓋(或改名),刪除原來的log檔案(或改名)
--4.啟動SQL Service(否則下面的語句沒辦法運行)
--5.將資料庫設成緊急模式(status=32768)
sp_configure 'allow updates',1
reconfigure with override
update sysdatabases set status=32768 where name='TEST'
--重建立立記錄檔
DBCC traceon(3604)
dbcc rebuild_log('test','C:/Program Files/Microsoft SQL Server/MSSQL/Data/test_log.ldf')
Go
--6.重新啟動SQL Service
--7.將資料庫設定成單一使用者模式(下面三個語句均可)
--sp_dboption 'TEST','single user','true'
update sysdatabases set status=4096 where name='TEST'
--alter database TEST set Single_user
--8.檢查資料庫的完整性和一致性,OK了就可以用了
DBCC CheckDB(TEST)
--9.將資料的存取權限設定成多使用者模式
sp_dboption 'TEST','single user','false'
--或alter database TEST set multi_user
--10.關閉進階選項
sp_configure 'allow updates',0
reconfigure with override
--結束
SQL Server安裝掛起
在安裝sql server時出現“以前的某個程式安裝已在安裝電腦上建立掛起的檔案操作。運行安裝程式之前必須重新啟動電腦”錯誤。無法進行下去。 參考有關資料後,以下步驟基本可以解決:
1)添加/刪除程式中徹底刪除sql server。
2)將沒有刪除的sql server目錄也刪除掉。
3)開啟登錄編輯程式,在HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Control/ Session Manager中找到PendingFileRenameOperations項目,並刪除它。這樣就可以清除安裝暫掛項目。
4)刪除註冊表中跟sql server相關的鍵
注意:
要是不想重新啟動就順利安裝,一般來說按照第三步就可以解決……
資料三:
--SQL SERVER資料庫置疑後恢複步驟
--1. 恢複步驟:
--a.將smlog_log.ldf檔案備份到其它目錄下;
--b.將來源目錄下的smlog_log.ldf檔案改名為smlog_log_bak.ldf;
--c.執行以下語句修改資料庫的狀態:
use Master
go
update sysdatabases set status=32768 where name='資料庫名稱' --修改狀態,設為緊急狀態
go
shutdown with nowait --停止資料庫伺服器
go
--d.退出SQL並在(COMMAND)命令列模式中通過下面的代碼重新啟動SQL:
sqlservr -c -T3608 -T4022 --安全模式啟動SQL SERVER
--e.在查詢分析器中執行以下語句來查看剛剛修改過狀態的資料庫狀態:
select Name,Status from sysdatabases where Name='資料庫名稱'
--f.執行以下代碼建立記錄檔:
dbcc traceon(3604)--跟蹤
dbcc rebuild_log('資料庫名稱','記錄檔全路徑') --檔案名稱要有全路徑和副檔名
--dbcc rebuild_log('prs_msc','dmscsqlmssqldataprs_msc_log.ldf
--g.將資料庫置回正常狀態:
update sysdatabases set status=0 where name='資料庫名稱'
--h.重新啟動資料庫後執行以下語句檢查資料庫:
DBCC CHECKDB --如果執行完有錯誤用以下語句修複
--i.要修複資料庫必需將資料庫改為單一使用者模式:
Exce sp_dboption '資料庫名稱','single user','true'---('false'恢複多使用者)
--j.執行以下語句修複資料庫:
DBCC CHECKDB('資料庫名稱',REPAIR_ALLOW_DATA_LOSS)
REPAIR_ALLOW_DATA_LOSS:是比較進階的修複方式
REPAIR_FAST:是簡單快速的修複方式
處理狀態就為置疑的數據庫
備份資料檔案,然後按下面的步驟處理
1.建立一個同名的資料庫(資料檔案與原來的要一致)
2.再停掉sql server(注意不要分離資料庫)
3.用原資料庫的資料檔案覆蓋掉這個建立的資料庫
4.再重啟sql server
5.此時開啟企業管理器時會出現置疑,先不管,執行下面的語句(注意修改其中的資料庫名)
6.完成後一般就可以訪問資料庫中的資料了,這時,資料庫本身一般還要問題,解決辦法是,利用資料庫的指令碼建立一個新的資料庫,並將資料導進去就行了.
USE MASTER
GO
SP_CONFIGURE 'ALLOW UPDATES',1
GO
RECONFIGURE WITH OVERRIDE
GO
UPDATE SYSDATABASES SET STATUS =32768 WHERE NAME='置疑的資料庫名'
Go
sp_dboption '置疑的資料庫名','single user','true'
Go
DBCC CHECKDB('置疑的資料庫名')
Go
update sysdatabases set status=28 where name='置疑的資料庫名'
Go
sp_configure 'allow updates',0
GO
reconfigure with override
Go
sp_dboption '置疑的資料庫名', 'single user','false'
Go
只有mdf檔案的恢複技術
由於種種原因,我們如果當時僅僅備份了mdf檔案,那麼恢複起來就是一件很麻煩的事情了。
如果您的mdf檔案是當前資料庫產生的,那麼很僥倖,也許你使用sp_attach_db或者sp_attach_single_file_db可以恢複資料庫,但是會出現類似下面的提示資訊
裝置啟用錯誤。物理檔案名稱 'CProgram FilesMicrosoft SQL ServerMSSQLdatatest_Log.LDF' 可能有誤。
已建立名為 'CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.LDF' 的新記錄檔。
但是,如果您的資料庫檔案是從其他電腦上複製過來的,那麼很不幸,也許上述辦法就行不通了。你也許會得到類似下面的錯誤資訊
伺服器 訊息 1813,層級 16,狀態 2,行 1
未能開啟新資料庫 'test'。CREATE DATABASE 將終止。
裝置啟用錯誤。物理檔案名稱 'dtest_log.LDF' 可能有誤。
怎麼辦呢?別著急,下面我們舉例說明恢複辦法。
--A.我們使用預設建立一個供恢複使用的資料庫(如test)。可以在SQL Server Enterprise Manager裡面建立。
--B.停掉資料庫伺服器。
--C.將剛才產生的資料庫的記錄檔test_log.ldf刪除,用要恢複的資料庫mdf檔案覆蓋剛才產生的資料庫資料檔案test_data.mdf。
--D.啟動資料庫伺服器。此時會看到資料庫test的狀態為“置疑”。這時候不能對此資料庫進行任何操作。
--E.設定資料庫允許直接作業系統表。此操作可以在SQL Server Enterprise Manager裡面選擇資料庫伺服器,按右--鍵,選擇“屬性”,在“伺服器設定”頁面中將“允許對系統目錄直接修改”一項選中。也可以使用如下語句來實現。
use master
go
sp_configure 'allow updates',1
go
reconfigure with override
go
--F.設定test為緊急修複模式
--在查詢管理器裡設定如下命令:
update sysdatabases set status=-32768 where dbid=DB_ID('test')
--此時可以在SQL Server Enterprise Manager裡面看到該資料庫處於“唯讀置疑離線緊急模式”可以看到資料庫裡面的表,但是僅僅有系統資料表
--G.下面執行真正的恢複操作,重建資料庫記錄檔
dbcc rebuild_log('test','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf')
執行過程中,如果遇到下列提示資訊:
伺服器 訊息 5030,層級 16,狀態 1,行 1
未能排它地鎖定資料庫以執行該操作。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
說明您的其他程式正在使用該資料庫,如果剛才您在F步驟中使用SQL Server Enterprise Manager開啟了test庫的系統資料表,那麼退出SQL Server Enterprise Manager就可以了。
正確執行完成的提示應該類似於:
警告 資料庫 'test' 的日誌已重建。已失去事務的一致性。應運行 DBCC CHECKDB 以驗證物理一致性。將必須重設資料庫選項,並且可能需要刪除多餘的記錄檔。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
此時開啟在SQL Server Enterprise Manager裡面會看到資料庫的狀態為“只供DBO使用”。此時可以訪問資料庫裡面的使用者表了。
--H.驗證資料庫一致性(可省略)
dbcc checkdb('test')
一般執行結果如下:
CHECKDB 發現了 0 個分配錯誤和 0 個一致性錯誤(在資料庫 'test' 中)。
DBCC 執行完畢。如果 DBCC 輸出了錯誤資訊,請與系統管理員聯絡。
--I.設定資料庫為正常狀態
sp_dboption 'test','dbo use only','false'
--如果沒有出錯,那麼恭喜,現在就可以正常的使用恢複後的資料庫啦。
--J.最後一步,我們要將步驟E中設定的“允許對系統目錄直接修改”一項恢複。因為平時直接作業系統表是一件比較危險的事情。當然,我們可以在SQL Server Enterprise Manager裡面恢複,也可以使用如下陳述式完成
sp_configure 'allow updates',0
go
reconfigure with override
go
--記錄檔出現問題(丟失或檔案格式非法),怎麼使資料庫恢複正常
--如果用sp_attach_single_file 'TEST','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.mdf'失敗則需要用下列步驟完成
--1.將置疑的資料庫分離,將mdf檔案移走或改名!
sp_detach_db 'TEST'
--2.重新在原來目錄下建立同名的資料庫TEST
--3.停掉SQL Service,將先前的mdf檔案拷貝回來覆蓋(或改名),刪除原來的log檔案(或改名)
--4.啟動SQL Service(否則下面的語句沒辦法運行)
--5.將資料庫設成緊急模式(status=32768)
sp_configure 'allow updates',1
reconfigure with override
update sysdatabases set status=32768 where name='TEST'
--重建立立記錄檔
DBCC traceon(3604)
dbcc rebuild_log('test','CProgram FilesMicrosoft SQL ServerMSSQLDatatest_log.ldf')
Go
--6.重新啟動SQL Service
--7.將資料庫設定成單一使用者模式(下面三個語句均可)
--sp_dboption 'TEST','single user','true'
update sysdatabases set status=4096 where name='TEST'
--alter database TEST set Single_user
--8.檢查資料庫的完整性和一致性,OK了就可以用了
DBCC CheckDB(TEST)
--9.將資料的存取權限設定成多使用者模式
sp_dboption 'TEST','single user','false'
--或alter database TEST set multi_user
--10.關閉進階選項
sp_configure 'allow updates',0
reconfigure with override
--結束
資料四:
如何修複SQLSERVER 資料庫"置疑"之(二) 收藏
如果 SQL Server 因為磁碟可用空間不足,而不能完成資料庫的恢複,那麼 SQL Server 2000 會返回錯誤 1105 並且將 sysdatabases 中的 status 列設為置疑。
你可以看到在SQLSERVER 的ERROR LOG 和OS的應用程式記錄檔中應該有1105的錯誤資訊:
SQL Server交易記錄可能會被填滿,這會阻止之後的資料庫操作,包括UPDATE, DELETE, INSERT 和CHECKPOINT。
交易記錄填滿會導致1105錯誤:
Can't allocate space for object syslogs in database dbname because
the logsegment is full。 If you ran out of space in syslogs, dump
the transaction log。 Otherwise use ALTER DATABASE or
sp_extendsegment to increase the size of the segment。
這種現象可能出現於任何一個資料庫中,包括Master和TempDB。一些難以預見的因素可能消耗日誌空間。 例如:
一個大型事務, 尤其像批量資料更新、插入或刪除。
一個未提交的事務。
檢查點處理常式截除時所需的頻寬過大。
截除時超過閾值
上述各種條件互相作用的結果。
用於發布的標記事務沒有被日誌讀取程式讀走
下面是修複的步驟和收縮日誌的步驟:
1.在命令提示字元下運行以下命令啟動 SQL Server:
SQLSERVER -f -m
備忘:-m 開關以單一使用者模式啟動 SQL Server。在單一使用者模式下,只能成功建立一個串連。 請注意是否有任何其他客戶機或服務可能會在您通過 SQL Server 查詢分析器 建立串連前使用那個串連。
2. 重設置疑資料庫的狀態。
sp_resetstatus 'database_name'
下面是結果集:
Database'database_name'status reset!
WARNING: You must reboot SQL Server prior to accessing this database!
3. 用 ALTER DATABASE 向資料庫添加一個資料檔案或記錄檔:
USE master
GO
CREATE DATABASE db_name ON
(
NAME = dbname_dat1,
FILENAME = 'D:/MSSQL/Data/dbname_dat1.ndf',
SIZE = 1000MB,
FILEGROWTH = 50MB
)
GO --更改該資料庫以添加一個 2GB 大小的新資料檔案
ALTER DATABASE db_name
ADD FILE
(
NAME = dbname_dat2,
FILENAME = 'F:/MSSQL/DATA/dbname_dat2.ndf',
SIZE = 2000MB,
FILEGROWTH = 50MB
)
GO
--更改該資料庫以添加一個1GB 大小的新記錄檔
ALTER DATABASE db_name
ADD LOG FILE
( NAME = db_name_log2,
FILENAME = 'F:/MSSQL/Data/db_name_log2.ldf',
SIZE = 1000MB,
FILEGROWTH = 20MB),
GO
4. 停止並重新啟動 SQL Server:
用新的資料檔案或記錄檔所提供的額外空間,SQL Server 應該能完成資料庫的恢複。
5. 釋放磁碟空間並且重新運行恢複操作,按照下面的步驟收縮日誌。
sp_resetstatus 關閉資料庫的置疑標誌,但是原封不動地保持資料庫的其它選項。
為從根本上解決這樣的問題,你可以按下面的操作配置SQLSERVER 2000:
a.如果不需要恢複到指定的時間點,你可以將資料庫的復原模式配置為簡單,這樣
UPDATE,DELETE,SELECT就不會記錄日誌,日誌就不會增加的很大:
USE MASTER
GO
ALTER DATABASE DB_NAME SET RECOVERY SIMPLE
b.如果你的復原模式是全部,你一定要配置日誌欄位收縮:
USE MASTER
GO
sp_dboption 'databasename','trunc. log on chkpt.',true
sp_dboption 'databasename','autoshrink',true
c.通過每日備份將日誌收縮:
BACKUP DATABASE DATABASE_NAME TO BACKUP_DEVICES
BACKUP LOG DATABASE_NAME TO LOG_DEVICES
OR
BACKUP LOG DATABASE_NAME with truncate_only
**檢查日誌的容量:DBCC SQLPERF (LOGSPACE) 這時日誌並沒有收縮!
d.每天在備份資料庫完成之後,重新啟動MS SQLSERVER SERVICE.
USE DATABASE_NAME
go
DBCC SHRINKFILE(2,truncateonly)
**檢查日誌的容量:DBCC SQLPERF (LOGSPACE) 這時日誌已經收縮!
e.手動快速收縮日誌:
/ *run below script,you will shrink you database log files
immediately, in my experience,you need to run the script for 3 or
4 minutes before stopping it manually */
use databasename
dbcc shrinkfile(2,notruncate)
dbcc shrinkfile(2,truncateonly)
create table t1(char1 char(4000))
go
declare @i int
select @i=0
while(1=1)
begin
while(@i<100)
begin
INSERT INTO T1 VALUES ('A')
SELECT @I=@I+1
END
TRUNCATE table T1
BACKUP LOG youdatabasename with truncate_only
end
GO
注意 只有在您的主要支援提供者指導下或有疑難解答建議的做法時,才可以使用
sp_resetstatus。否則,可能會損壞資料庫。
由於該過程修改了系統資料表,系統管理員必須在運行 sp_resetstatus這個過程前,啟用系統資料表更新。要
啟 用更新,使用下面的過程:
USE master
GO
sp_configure 'allow updates', 1
GO
RECONFIGURE WITH OVERRIDE
GO
過程建立後,立即禁用系統資料表更新:
sp_configure 'allow updates', 0
GO
RECONFIGURE WITH OVERRIDE
GO
只有系統管理員才能執行 sp_resetstatus。執行該過程後,立即關閉 SQL Server。
請參考:
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;317375
http://support.microsoft.com/default.aspx?scid=kb;zh-cn;307775
本文來自CSDN部落格,轉載請標明出處:http://blog.csdn.net/leimin/archive/2004/02/26/12900.aspx