維護計劃重建 idex 後，事務日誌變得巨大
幾天前，我正在使用 SQL Server 2008 中的維護計劃測試一些東西。
我創建了一個來重建索引並每週進行一次完整備份。（我知道，我今天發現的壞事）。
問題是，由於事務日誌增長了很多（大約 80gb，db 為 60gb），備份沒有執行。現在我整天都在Google搜尋，看看是否有辦法將事務日誌縮小到以前的大小，大約是 200mb。
更新
這是在我們的生產伺服器上，維護計劃如下：
重建索引
成功備份完整數據庫
成功 刪除超過兩週的備份。
這並沒有完成，它在某個時候壞了，所以我想重建索引花了太長時間。所以備份沒有發生。
我們還每小時備份一次事務日誌。
這可能嗎？為什麼會這樣？我知道在重建時它會在事務日誌或類似的東西中創建索引的副本，但是有可能擺脫這個副本嗎？
這就是我在作業歷史記錄中的內容，所以它看起來由於某種原因在創建索引時失敗了，並且由於計劃成功，所以備份它就停在那裡了。
資訊 ：
以使用者身份執行：SHOCKLOGIC\DB1$。…ress：2013-08-05 03:01:03.43 來源：重建索引任務執行查詢“ALTER INDEX
$$ PK_ActivitiesPerGroup $$在$$ dbo $$.$$ Acti…".: 12% complete End Progress Progress: 2013-08-05 03:01:03.43 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 12% 完成 End Progress Progress: 2013-08-05 03:01:03.52 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivitiesPerHotelCat $$在$$ dbo $$.$$ A…”.: 12% complete End Progress Progress: 2013-08-05 03:01:03.52 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 12% 完成 End Progress Progress: 2013-08-05 03:01:03.69 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivitiesPerHotelCat_OLD $$在$$ dbo…”.: 12% complete End Progress Progress: 2013-08-05 03:01:03.69 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 12% 完成 End Progress Progress: 2013-08-05 03:01:08.61 Source: Rebuild Index Task Executing query “ALTER INDEX$$ _dta_index_ActivitiesPerPerson_10_292…”.: 13% complete End Progress Progress: 2013-08-05 03:01:08.61 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 13% 完成 End Progress Progress: 2013-08-05 03:01:12.85 Source: Rebuild Index Task Executing query “ALTER INDEX$$ _dta_index_ActivitiesPerPerson_10_292…”.: 13% complete End Progress Progress: 2013-08-05 03:01:12.85 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 13% 完成 End Progress Progress: 2013-08-05 03:01:20.44 Source: Rebuild Index Task Executing query “ALTER INDEX$$ IX_ActivitiesPerPerson $$在$$ dbo $$.$$ Act…”.: 13% complete End Progress Progress: 2013-08-05 03:01:20.44 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 13% 完成 End Progress Progress: 2013-08-05 03:01:57.55 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivitiesPerPerson $$在$$ dbo $$.$$ Act…”.: 13% complete End Progress Progress: 2013-08-05 03:01:57.55 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 14% 完成 End Progress Progress: 2013-08-05 03:01:57.58 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivityGroupInputTypes $$在$$ dbo $$….”.: 14% 完成 End Progress Progress: 2013-08-05 03:01:57.58 Source: Rebuild Index Task Executing query “USE$$ Eventlogic $$ “.: 14% 完成 End Progress Progress: 2013-08-05 03:01:57.65 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivityGroupTypes $$在$$ dbo $$.$$ Acti…”.: 14% complete End Progress Progress: 2013-08-05 03:01:57.66 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 14% 完成 End Progress Progress: 2013-08-05 03:01:57.66 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivityGroupTypeForGroups $$在$$ db…”.: 14% complete End Progress Progress: 2013-08-05 03:01:57.66 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 14% 完成 End Progress Progress: 2013-08-05 03:01:57.74 Source: Rebuild Index Task Executing query “ALTER INDEX$$ PK_ActivityInputTypes $$在$$ dbo $$.$$ Acti…”.: 15% complete End Progress Progress: 2013-08-05 03:01:57.74 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “.: 15% 完成 End Progress Progress: 2013-08-05 03:01:57.77 Source: Rebuild Index Task Executing query “ALTER INDEX [ PK_Activity_B7BCF0184055F19F ] ON$$ d…”.: 15% complete End Progress Progress: 2013-08-05 03:01:57.77 Source: Rebuild Index Task Executing query “USE [Eventlogic $$ “。：完成 15% 完成進度進度：2013-08-05 03:01:57.88 來源：重建索引任務執行查詢“ALTER INDEX [PK_AddressConfirmationScreenFieldsLan …”。：完成 15% 完成進度進度：2013-08-05 03:01:57.88 來源：重建索引…包執行失敗…步驟失敗。
重建索引需要足夠的空間來創建新索引。一個簡化的經驗法則似乎是您需要原始索引使用的大約 120% 的空間。這可能在數據庫或 tempdb 中，具體取決於 SORT_IN_TEMPDB 是 ON 還是 OFF。
如果可能，讓 SORT_IN_TEMPDB = ON 減少一些已完成的日誌記錄。
如果在 LOG 備份之間重建所有索引，則用於重新索引所有索引的所有日誌都將在日誌文件中。因此，大的重組需要有合適的磁碟空間、日誌空間等資源。（例如，您可以嘗試一次重新組織一個表並在每個表之後進行日誌備份。）
對於索引空間需求： http: //msdn.microsoft.com/en-us/library/ms191183 (v=sql.110).aspx 對於事務日誌：http: //msdn.microsoft.com/en-us/library /ms184246.aspx
您可以嘗試更改為最小日誌記錄恢復模型，例如 SIMPLE 或 BULK_LOGGED。但是，對於生產數據庫，您必須權衡負面影響並確定什麼是最好的。（為了重新組織數據庫而更改為 SIMPLE 後，可能應該更改為 FULL 並執行 FULL 備份。）
可以縮小日誌文件，但只能在日誌備份釋放高階頁面之後。（這通常是一個循環備份日誌，DBCC SHRINKFILE，然後檢查空間再試一次。）
對於收縮日誌文件，不要使用 DBCC SHRINKDATABASE。使用 DBCC SHRINKFILE（日誌文件名，目標大小）。
我創建了一個來重建索引並每週進行一次完整備份。（我知道，我今天發現的壞事）。
正確的。
這些程序應該分開，以便它們可以獨立執行。當然，無論索引重建是成功還是失敗，備份過程都應該繼續進行。但不要費心試圖解決這個問題，因為：
很少需要一直完全重建索引，而且通常非常昂貴。我建議使用更智能的過程，首先確定索引是否碎片化以及碎片數量，然後採取適當的措施。我個人使用並推薦Ola Hallengren 的腳本來執行此操作。
問題是，由於事務日誌增長了很多（大約 80gb，db 為 60gb），備份沒有執行。現在我整天都在Google搜尋，看看是否有辦法將事務日誌縮小到以前的大小，大約是 200mb。
根據您在評論中告訴我的內容，“失敗”（未執行）的備份是完整備份。假設事務日誌備份一直成功，您應該能夠使用
DBCC SHRINKFILE（或更簡單的 SSMS GUI）將日誌文件縮小到合理的大小。我知道在重建時它會在事務日誌或類似的東西中創建索引的副本，但是有可能擺脫這個副本嗎？
您不能一開始就阻止它被創建，這就是為什麼一直進行重建如此昂貴的原因，以及為什麼我建議使用上述腳本。
備份事務日誌後，可以重新使用已使用的空間，或將其作為
SHRINKFILE.