因一個表中的資料從26號之後，因儲存過程的問題，資料一直抽取抽取，導致資料重複量超過有的超過了900多條。

所以，計劃刪除表中26號之後的資料，再重新抽取。

       表中有一個聚集索引，一個非聚集索引。刪除之前收縮了下日誌，且停止了全部作業。刪除時間三個半小時之後，查詢資料時，已經將表中的資料產出掉了。但是日誌確一直在寫。此時日誌檔案已經增大到500G。因怕日誌一直寫，導致硬碟寫滿。故強制關閉了MSSM。重新開啟MSSM，表中的資料不加 no(lock) 不可查詢。

        解決方式：重啟SQLSERVER服務，讓資料自動回滾事務。

        PLAN B：截斷日誌，執行dbcc check 語句（最後的手段，不建議使用，會有資料一致性問題）。

        PLAN B 語句：

        alter database CNC_MIOT_BI set emergency;
        alter database CNC_MIOT_BI rebuild log on(name=CNC_MIOT_BI_log1,filename='D:\CNC\CNC_MIOT_BI_log1.LDF');
        alter database CNC_MIOT_BI set multi_user;

        dbcc checkdb ("CNC_MIOT_BI")                      

        如果確定只有一個表的話，也可以 DBCC CHECKTABLE ('fact_pool_do_out');

事後反思：

1、刪除資料，可以轉化為drop 表。先將剩餘的資料取出來，放在表A中，drop 表 B，然後將 表A 重新命名為 表 B。

2、刪除資料前，可以先刪除掉非聚集索引，然後再重建非聚集索引。（懷疑一直寫日誌和這有關）

3、一定要等待日誌寫完。