我會選擇多一事不如少一事

主要是因為沒有人能「確定」是否還有人需要
如果這個「xxx_TEST」
原先只是當測試用
但後來偏室扶正
為了省事而名稱沒改
又或者每年只用兩天
所以覺得沒人在用
那掛了它應該會滿慘的吧

系統備份

建議 可以使用 SQL Server Profiler 進行追蹤
觀察

但我知道有幾個資料庫是根本沒在用的，例如：xxx_TEST、xxx_restore，之類的~

又有一些資料表，例如名稱是：xxxx_YYYYMMDDbak 之類的~

確認...是否這些資料庫是否已經沒在使用!?

這是 德瑞克老師的教學文 使用 SQL Profiler 建立「SQL 追蹤(SQL Trace)」

將這些table更名，例如改成del_xxx_TEST這種容易辨視的。
出現異常時將名稱改回去即可，一段時間沒出事在回頭刪除!

建議多一事不如少一事

如果沒有消耗什麼效能,頂多只是看了礙眼,很多公司的DB也都存在著大量不知用途的Table;
就算有些公司管控了DB物件的建立;也有很多的程式,裡面寫了不知所謂的程式碼..所以通常
都是程式產生了效能問題,才會去檢視

而且有些程式或是資料庫,它並不一定會有所謂的使用周期的,甚至可能一年才用一次,例如年底
盤點,需要一個測試資料庫,將盤點資料轉入再執行測試...假設你一月做了變更,可是12月問題
才發生....你能想起來是因為這件事情嘛..

其實我也曾經有過板大的雄心壯志,但是工作講求的是 績效/效益/可數據化 的報告,其實這類型的工作...對於上面的人來說,真的是最沒價值的(且出事情你會死得很慘,所有矛頭都是你)

1. 發信通知大家，定下日期，哪天會進行刪除？

2. 備份一次，並且持續觀察幾天
   看看是否還有人使用？

3. 當天，先備份，然後再來刪除

資訊界有句話說...沒有壞的就別去動他....
如果硬碟空間夠,而且不會影響效能,那動他幹嘛呢....

當你努力維護、簡化、最佳化公司網路架構、伺服器、資料庫時，因為公司的服務都不會當機，到後來就會連資訊主管都說~~~你一天到晚在機房忙，我都不知道你在忙什麼??

等到沒有人維護這些時，當伺服器常常當機時，老闆、資訊主管就會想起你的好。

基本上 比照LINUX跟window得檔案設定
上一次使用時期跟使用者而定
就可以認定那些是主要跟次要及不要的了.

全部備份很麻煩
甚至沒做定期整理更慘

都有道理耶；
只是立場不同、環境不同而已。