我們知道在windows平台下，一旦文件在程序中打開，則不能被删除，所以不存在誤删數據文件的情況，如下圖所示。

但是在linux操作系統中，被進程打開的文件仍可以被删除，因此存在DM7數據文件可能被誤删的風險。并且，在默認情況下，若數據文件被删除，數據庫是不會返回任何報錯信息的，這樣無形中就增大了 數據丢失的風險。因此，本篇文章主要講兩個方面：

1.在表空間文件被誤删後，如何使數據庫及時反饋出來。

2.在表空間文件被誤删後，如何進行數據的恢複。

注：本文實驗環境的DM7數據庫版本為：

DM Database Server x64 V7.1.6.16-Build(2017.10.10-85437)ENT

一、在表空間文件被誤删後，如何使數據庫反饋出來。

1.首先建一個測試表。

2.删除數據文件MAIN.DBF，此時去查詢test表，發現一切正常，數據庫沒有任何報錯。

3.進行相關設置，使數據庫可以檢測出文件被删除，有以下兩種方式： 調用系統過程SP_FILE_SYS_CHECK()來手動檢查，數據庫重啟後失效； 設置參數FIL_CHECK_INTERVAL大于0即可（單位是s），若使其永久生效，則需要将參數添加進dm.ini文件中。2.删除數據文件MAIN.DBF，此時去查詢test表，發現一切正常，數據庫沒有任何報錯。

4.設置成功後，再次查詢test表，即報錯： 表空間[MAIN]中文件[/opt/dmdbms/data/DAMENG/MAIN.DBF]已被删除

進行以上設置後，若數據文件被删除，我們可以及時得知，下面來講如何進行數據恢複。

數據恢複分兩種方法：聯機恢複和脫機恢複。

2.1 聯機恢複，此方法隻适用于被删除的是用戶數據文件（以MAIN.DBF為例）：

1.首先調用以下系統過程進行恢複的準備工作：

2.在服務器終端執行 ps ­ef |grep dms，獲取數據庫服務的pid為12130

3.接下來，就用ls命令查看被删除文件對應的副本：ls /proc/12130/fd ­l，如下圖，在MAIN.DBF文件 後，有個delete，表示已被删除掉。

4.将上述MAIN.DBF文件複制到原數據文件路徑下即可：

5.複制成功後，執行以下語句完成表空間失效文件的恢複。

6.再次查詢test表，可正常執行，并得到正确數據。

為什麼聯機恢複隻适用于恢複被删除的用戶數據文件呢， 因為當被删除的是ROLL.DBF、TEMP.DBF 或SYSTEM.DBF文件時，數據庫一旦檢測到它們其中任何一個文件不在了，就會直接挂掉，所以根本沒有 機會進行聯機恢複的操作。此時，隻能利用備份文件和歸檔文件進行還原，并因為數據庫屬于異常退出， 有部分redo日志還沒來得及寫進歸檔中，導緻歸檔不全，無法恢複到數據庫異常退出前的狀态。因此，在 進行還原前，需進行歸檔修複（歸檔修複會掃描聯機日志文件，将那些已經寫入聯機日志文件、但還沒有 寫入到歸檔日志文件的REDO日志，重新寫入到歸檔日志文件，詳見手冊 DM7_Backup_And_Recovery.pdf）。

2.2 脫機恢複，即備份還原機制

在利用備份進行還原時，根據被删除文件類型，也分為以下兩種情況：

2.2.1 若被删除的是ROLL.DBF或TEMP.DBF，通過以下過程，即可完整恢複數據庫。

1.歸檔修複：

2.利用備份加歸檔，進行還原：

2.2.2 若被删除的是SYSTEM.DBF文件，則無法完整恢複數據庫。

1.SYSTEM.DBF被删除後，無法修複歸檔，所以會導緻部分數據丢失。

2.SYSTEM.DBF被删除後，無法在原庫上直接進行還原，必須新初始化一個庫才可以。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!