儘量停止SQLserver所在的伺服器的寫操作，確切的說，是資料庫檔案所在碟符的寫操作。

首先找運維看一下有沒有備份，如果有，看一下備份日期，這個時間跨度就是回檔跨度，看能不能接受，能接受直接恢復，不能接受往下看；

mssqlserver可以透過日誌找回資料，但是這個方法弊端太多，有的軟體會將資料“快取”的日誌裡，有的不會，有的軟體還會最佳化日誌檔案大小，所以極有可能出現日誌內無資料，或者只能提取部分資料，所以這個方法看人品；

終極辦法，資料恢復。根據你的描述，不存在硬碟損壞，壞道等問題，所以找回資料還是比較簡單的，但還是一定的機率無法找回的，固態硬碟的刪除邏輯與傳統機械硬碟不同，有可能無法恢復資料，機械硬碟中，資料所在的物理位置正好被其他檔案寫入，極有可能無法恢復資料。

總之，祝好運。

拷獯穡涸贇QLServer中，所有對資料庫執行的更新操作都會記錄在資料庫的事務日誌檔案中，除非將資料庫設為可自動收縮的或手動的對資料庫進行了收縮，否則事務日誌檔案將一直增長，直到達到事先設定的日誌檔案增長上限或用盡所有可用的磁碟空間。如果當前的資料庫檔案或日誌檔案過大，可以使用以下兩個命令對其進行收縮：DBCCSHRINKDATABASE：收縮指定資料庫的所有資料和日誌檔案的大小DBCCSHRINKFILE：收縮資料庫的某個指定資料或日誌檔案的大小這兩個命令可以釋放資料庫中的空閒空間，並將資料庫或指定的資料庫檔案收縮到指定的大小，但收縮後的資料檔案或日誌檔案的大小不會小於檔中現存的有效資料所佔空間的大小。關於這兩個命令的具體使用方法，可以參考SQLServer2000聯機叢書中的相應主題。另外，也可在SQLServer企業管理器中執行資料庫收縮，同樣是呼叫的以上兩個命令，效果類似。在使用以上命令收縮日誌檔案的時候需要注意，已寫入資料庫但未被截斷的事務日誌記錄是不會被收縮的，因為雖然這部分日誌記錄的資訊已經寫入資料庫檔案，但在使用事務日誌備份進行資料庫還原的時候，還將用到其中的資訊。對於使用簡單恢復模型的資料庫，事務日誌會在每次處理檢查點（CheckPoint）時自動被截斷。對於使用完全恢復模型或大容量日誌記錄恢復模型的資料庫，事務日誌只有在執行日誌備份（BACKUPLOG）時才會被截斷，這時事務日誌中記錄的資訊被寫入事務日誌備份檔案，而它們所佔用的這部分空間被標記為可用（即被截斷）。截斷事務日誌並不會使日誌檔案變小，但可以將其中的部分空間釋放供以後寫入新的日誌記錄使用。若要減少日誌檔案的物理大小，則要使用上面提到的DBCCSHRINKDATABASE和DBCCSHRINKFILE命令。在執行BACKUPLOG語句的時候，還可以使用WITHNO_LOG（或WITHTRUNCATE_ONLY，含義相同）引數，這時並不真正備份事務日誌，而只是截斷事務日誌中的非活動部分（這和普通的BACKUPLOG語句作用相同）。這適合於剩餘磁碟空間不夠進行事務日誌備份或不打算保留事務日誌中的非活動部分用於資料庫恢復的情況。為避免事務日誌檔案增長過快以致用盡所有磁碟空間的現象發生，一種辦法是將資料庫設為使用簡單恢復模型，這樣可以使SQLServer週期性的自動截斷事務日誌的非活動部分，並回收其佔用的空間供以後寫入事務日誌記錄使用。但這將使資料庫無法利用事務日誌備份還原到實時點，降低了資料庫的可靠性，因此一般不應用於生產型資料庫。對於生產型資料庫，推薦的做法是使用完全恢復模型，並定期進行資料庫的完全備份和事務日誌備份。例如每週執行一次完全備份，每天執行一次事務日誌備份，這可以透過SQLServer企業管理器中的資料庫維護計劃嚮導很方便的實現（一般可以設為在每天夜裡業務不繁忙的某個時刻自動執行備份）。透過定期執行資料庫的事務日誌備份，可以避免日誌檔案的迅速增大，而使其保持一個比較穩定的大小。雖然資料庫備份檔案也會佔用很多磁碟空間，但隨時可以將這些檔案移到其他磁碟上或在不需要它們的時候將其刪除，而且可以在出現故障或誤操作的時候方便的進行資料庫的還原。由於資料檔案的大小是隨資料庫中資料量的增長而增長的，資料庫中已刪除的資料所佔的空間可以供新插入的資料使用；而在定期執行了事務日誌的備份後，我們可以將日誌檔案的大小控制在一個比較合理的範圍。因此，一般不需要對資料庫進行收縮，也不推薦將資料庫設為自動收縮模式。建議僅在以下情況下執行資料庫的收縮：1、磁碟空間不足2、資料檔案很大，但其中只包含較少量的資料（可能是以前有大量資料，但後來刪除了很多），並且預期今後資料庫中的資料量也不會很大。3、由於長期未進行事務日誌備份，導致事務日誌檔案過大。減小事務日誌檔案大小的另一種方法是：首先在該資料庫中執行CHECKPOINT命令，然後將該資料庫分離（Detach），再將與其對應的資料庫日誌檔案（.ldf檔案）改名或刪除或移動到其他目錄下，然後執行sp_attach_single_file_db儲存過程或在企業管理器中重新將其附加（Attach）。由於找不到原來的日誌檔案，SQLServer將自動為該資料庫建立一個大小隻有504K的日誌檔案。但這種方法必須暫時將資料庫離線，因此一般不適宜在生產環境中使用。如果當前資料庫的事務日誌檔案過大，必須對其進行收縮的話，建議參照以下步驟：1、建議首先備份資料庫（但不是必需的）：BACKUPDATABASEdatabase_nameTObackup_device

2、備份事務日誌：BACKUPLOGdatabase_nameTObackup_device如果不需要當前事務日誌中的記錄進行資料庫還原或沒有足夠的空間進行事務日誌備份的的話，也可僅執行以下命令截斷事務日誌：BACKUPLOGdatabase_nameWITHNO_LOG

3、收縮日誌檔案：DBCCSHRINKFILE(log_file_name)其中log_file_name是事務日誌檔案的邏輯名稱，可以在企業管理器中資料庫屬性的“事務日誌”頁中看到（如Northwind資料庫的預設事務日誌檔案邏輯名稱為Northwind_log）。4、如果日誌檔案仍然較大的話，可以嘗試重複執行一次BACKUPLOGWITHNO_LOG和DBCCSHRINKFILE命令。5、如果這時仍沒有明顯的效果，請執行DBCCOPENTRAN(database_name)檢查當前資料庫中是否存在長時間未提交的活動事務。有必要的話，可以斷開這些連線並重新嘗試截斷事務日誌和收縮日誌檔案。6、日誌檔案收縮完成後，建議立即執行一次資料庫的完全備份並根據實際需要制定適當的資料庫備份計劃。