0
我們擁有一個帶有2個表的數據庫,其中一個擁有數億行(行大小< 1KB),另外還有1400萬行。兩者都啓用了壓縮。 數據庫大小爲〜66GB。一切正常。SQL - 對壓縮表上的索引進行碎片整理
索引分成75%。同事在兩張桌子上開始了重建。現在已經運行了4.5個小時。 MDF差不多150GB,LDF大約13GB,並且不斷增長。我們即將耗盡空間。
我們該怎麼辦?等待它完成?取消查詢?重新啓動SQL?重新啓動服務器?
我們擁有一個帶有2個表的數據庫,其中一個擁有數億行(行大小< 1KB),另外還有1400萬行。兩者都啓用了壓縮。 數據庫大小爲〜66GB。一切正常。SQL - 對壓縮表上的索引進行碎片整理
索引分成75%。同事在兩張桌子上開始了重建。現在已經運行了4.5個小時。 MDF差不多150GB,LDF大約13GB,並且不斷增長。我們即將耗盡空間。
我們該怎麼辦?等待它完成?取消查詢?重新啓動SQL?重新啓動服務器?
該過程完成7小時後,消耗約170GB的MDF文件。
所以答案是:
希望這可以幫助別人。
我沒想到'未壓縮'的文件大小在這裏,我必須記住它是新索引文件需要的未壓縮大小。 TY共享解決方案 – Twelfth 2014-09-05 21:13:51
索引REBUILD已完全記錄,所以LDF會變得非常大,但不知道它與索引大小相比有多大。 – 2014-09-04 22:18:41
你有沒有打開最小化日誌記錄(批量記錄)?重建索引時,SQL Server將在刪除舊索引之前,在第一個索引旁創建第二個索引(並且需要兩者的文件空間)。在重建之前,指數的大小是多少? – Twelfth 2014-09-04 22:24:13
@GoatCO有趣的是,LDF只有13GB,我們擔心中密度纖維板,如果完成的話,它會變成170GB。謝謝。 – 2014-09-05 02:18:35