SQl server 收縮事務日志

-- 清空日志  

  --壓縮日志及資料庫檔案大小  

  /*--特别注意  

  請按步驟進行,未進行前面的步驟,請不要做後面的步驟  

  否則可能損壞你的資料庫.  

  --*/  

  select   *from   sysfiles  

  --1.清空日志  

  DUMP     TRANSACTION     username     WITH     NO_LOG          

  --2.截斷事務日志：  

  BACKUP   LOG   username   WITH   NO_LOG  

  --3.收縮資料庫檔案(如果不壓縮,資料庫的檔案不會減小  

  -- 企業管理器--右鍵你要壓縮的資料庫--所有任務--收縮資料庫--收縮檔案  

  --選擇日志檔案--在收縮方式裡選擇收縮至XXM,這裡會給出一個允許收縮到的最小M數,直接輸入這個數,确定就可以了  

  --選擇資料檔案--在收縮方式裡選擇收縮至XXM,這裡會給出一個允許收縮到的最小M數,直接輸入這個數,确定就可以了  

  -- 也可以用SQL語句來完成  

  --收縮資料庫  

  DBCC   SHRINKDATABASE(username)  

  --收縮指定資料檔案,1是檔案号,可以通過這個語句查詢到:select   *   from   sysfiles  

  DBCC   SHRINKFILE(2)  

  --4.為了最大化的縮小日志檔案(如果是sql   7.0,這步隻能在查詢分析器中進行)  

  -- a.分離資料庫:  

  -- 企業管理器--伺服器--資料庫--右鍵--分離資料庫  

  -- b.在我的電腦中删除LOG檔案  

  -- c.附加資料庫:  

  -- 企業管理器--伺服器--資料庫--右鍵--附加資料庫  

  -- 此法将生成新的LOG，大小隻有500多K  

  -- 或用代碼：    

  -- 下面的示例分離   username，然後将   username   中的一個檔案附加到目前伺服器。  

  exec   sp_dboption   username,'single   user',true  

  a.分離  

  EXEC   sp_detach_db   @dbname   =   'username'  

  b.删除日志檔案  

  exec   master..xp_cmdshell   'del   D:\Program   Files\SQL\database\username_LOG.ldf'  

  c.再附加  

  EXEC   sp_attach_single_file_db   @dbname   =   'username',    

        @physname   =   'D:\Program   Files\SQL\database\username_Data.MDF'  

  --5.為了以後能自動收縮,做如下設定:  

  -- 企業管理器--伺服器--右鍵資料庫--屬性--選項--選擇"自動收縮"  

  --SQL語句設定方式:  

  EXEC   sp_dboption   '資料庫名',   'autoshrink',   'TRUE'  

  --6.如果想以後不讓它日志增長得太大  

  -- 企業管理器--伺服器--右鍵資料庫--屬性--事務日志  

  --将檔案增長限制為xM(x是你允許的最大資料檔案大小)  

  --SQL語句的設定方式:  

  alter   database   資料庫名   modify   file(name=邏輯檔案名,maxsize=20)  

  Top

   無資料庫日志檔案恢複資料庫方法兩則    

  方法一  

  1.建立一個同名的資料庫  

  2.再停掉sql   server(注意不要分離資料庫)  

  3.用原資料庫的資料檔案覆寫掉這個建立的資料庫  

  4.再重新開機sql   server  

  5.此時打開企業管理器時會出現置疑，先不管，執行下面的語句（注意修改其中的資料庫名)  

  6.完成後一般就可以通路資料庫中的資料了,這時,資料庫本身一般還要問題,解決辦法是,利用  

  資料庫的腳本建立一個新的資料庫,并将資料導進去就行了.  

  USE   MASTER  

  GO  

  SP_CONFIGURE   'ALLOW   UPDATES',1   RECONFIGURE   WITH   OVERRIDE  

  UPDATE   SYSDATABASES   SET   STATUS   =32768   WHERE   NAME='置疑的資料庫名'  

  Go  

  sp_dboption   '置疑的資料庫名',   'single   user',   'true'  

  DBCC   CHECKDB('置疑的資料庫名')    

  update   sysdatabases   set   status   =28   where   name='置疑的資料庫名'  

  sp_configure   'allow   updates',   0   reconfigure   with   override  

  Go    

  sp_dboption   '置疑的資料庫名',   'single   user',   'false'  

  方法二  

  事情的起因  

  昨天，系統管理者告訴我，我們一個内部應用資料庫所在的磁盤空間不足了。我注意到資料庫事件日志檔案XXX_Data.ldf檔案已經增長到了3GB，于是我決意縮小這個日志檔案。經過收縮資料庫等操作未果後，我犯了一個自進入行業以來的最大最愚蠢的錯誤：竟然誤删除了這個日志檔案！後來我看到所有論及資料庫恢複的文章上都說道：“無論如何都要保證資料庫日志檔案存在，它至關重要”，甚至微軟甚至有一篇KB文章講如何隻靠日志檔案恢複資料庫的。我真是不知道我那時候是怎麼想的？！  

  這下子壞了！這個資料庫連不上了，企業管理器在它的旁邊寫着“(置疑)”。而且最要命的，這個資料庫從來沒有備份了。我唯一找得到的是遷移半年前的另外一個資料庫伺服器，應用倒是能用了，但是少了許多記錄、表和存儲過程。真希望這隻是一場噩夢！  

  沒有效果的恢複步驟  

  附加資料庫  

  _Rambo講過被删除日志檔案中不存在活動日志時，可以這麼做來恢複：  

  1，分離被置疑的資料庫，可以使用sp_detach_db  

  2，附加資料庫，可以使用sp_attach_single_file_db  

  但是，很遺憾，執行之後，SQL   Server質疑資料檔案和日志檔案不符，是以無法附加資料庫資料檔案。  

  DTS資料導出  

  不行，無法讀取XXX資料庫，DTS   Wizard報告說“初始化上下文發生錯誤”。  

  緊急模式  

  怡紅公子講過沒有日志用于恢複時，可以這麼做：  

  1，把資料庫設定為emergency   mode    

  2，重建立立一個log檔案  

  3，把SQL   Server   重新啟動一下  

  4，把應用資料庫設定成單使用者模式  

  5，做DBCC   CHECKDB  

  6，如果沒有什麼大問題就可以把資料庫狀态改回去了，記得别忘了把系統表的修改選項關掉  

  我實踐了一下，把應用資料庫的資料檔案移走，重建立立一個同名的資料庫XXX，然後停掉SQL服務，把原來的資料檔案再覆寫回來。之後，按照怡紅公子的步驟走。  

  但是，也很遺憾，除了第2步之外，其他步驟執行非常成功。可惜，重新開機SQL   Server之後，這個應用資料庫仍然是置疑！  

  不過，讓我欣慰的是，這麼做之後，倒是能夠Select資料了，讓我大出一口氣。隻不過，元件使用資料庫時，報告說：“發生錯誤：-2147467259,未能在資料庫   'XXX'   中運作   BEGIN   TRANSACTION，因為該資料庫處于回避恢複模式。”  

  最終成功恢複的全部步驟  

  設定資料庫為緊急模式  

                     停掉SQL   Server服務；  

                     把應用資料庫的資料檔案XXX_Data.mdf移走；  

                     重建立立一個同名的資料庫XXX；  

                     停掉SQL服務；  

                     把原來的資料檔案再覆寫回來；  

                     運作以下語句，把該資料庫設定為緊急模式；  

          運作“Use   Master  

  sp_configure   'allow   updates',   1  

  reconfigure   with   override  

  Go”  

  執行結果：  

  DBCC   執行完畢。如果   DBCC   輸出了錯誤資訊，請與系統管理者聯系。  

  已将配置選項   'allow   updates'   從   0   改為   1。請運作   RECONFIGURE   語句以安裝。  

  接着運作“update   sysdatabases   set   status   =   32768   where   name   =   'XXX'”  

  （所影響的行數為   1   行）  

                     重新開機SQL   Server服務；  

                     運作以下語句，把應用資料庫設定為Single   User模式；  

              運作“sp_dboption   'XXX',   'single   user',   'true'”  

              指令已成功完成。  

                     做DBCC   CHECKDB；  

              運作“DBCC   CHECKDB('XXX')”  

  'XXX'   的   DBCC   結果。  

  'sysobjects'   的   DBCC   結果。  

  對象   'sysobjects'   有   273   行，這些行位于   5   頁中。  

  'sysindexes'   的   DBCC   結果。  

  對象   'sysindexes'   有   202   行，這些行位于   7   頁中。  

  'syscolumns'   的   DBCC   結果。  

  ………  

                     運作以下語句把系統表的修改選項關掉；  

              運作“sp_resetstatus   "XXX"  

  go  

  sp_configure   'allow   updates',   0  

  在   sysdatabases   中更新資料庫   'XXX'   的條目之前，模式   =   0，狀态   =   28（狀态   suspect_bit   =   0），  

  沒有更新   sysdatabases   中的任何行，因為已正确地重置了模式和狀态。沒有錯誤，未進行任何更改。  

  已将配置選項   'allow   updates'   從   1   改為   0。請運作   RECONFIGURE   語句以安裝。  

                     重建立立另外一個資料庫XXX.Lost；  

  DTS導出向導  

                     運作DTS導出向導；  

                     複制源選擇EmergencyMode的資料庫XXX，導入到XXX.Lost；  

                     選擇“在SQL   Server資料庫之間複制對象和資料”，試了多次，好像不行，隻是複制過來了所有表結構，但是沒有資料，也沒有視圖和存儲過程，而且DTS向導最後報告複制失敗；  

                     是以最後選擇“從源資料庫複制表和視圖”，但是後來發現，這樣總是隻能複制一部分表記錄；  

                     于是選擇“用一條查詢指定要傳輸的資料”，缺哪個表記錄，就導哪個；  

                     視圖和存儲過程是執行SQL語句添加的。  

        這樣，XXX.Lost資料庫就可以替換原來的應用資料庫了。  

http://blog.163.com/gyq_6699/blog/static/35581794200921881120401/    SQL 日志管理

http://hi.baidu.com/xsy86110/blog/item/56e412ce804fd23fb600c8d5.html  收縮日志

http://blog.csdn.net/chyliu/archive/2006/07/08/891363.aspx

http://publish.it168.com/2005/0925/20050925039501.shtml