和開發討論的一個資料變更需求

    最近在評估一個開發同事的需求時，發現隨著需求的變化，DBA相關的評估工作也會隨之變化，同時反射到開發同事那邊，透過這個案例也可以看到很多的需求變化，可以從中看出很多的不足和改進之處。
    首先開發提出的一個資料需求，刪除資料庫中的幾張表資料，然後把剩下的資料都備份，把備份集複製到一個異機環境。其實這個需求在之前也很他們溝透過，這是他們業務遷移的一個步驟，同時做一些業務梳理，DB這邊需要配合做一些資料的清理的工作。
    這種工作其實對我來說是一件好事，如果有一天我發現我在維護一個T級的資料庫，但是資料庫裡的資料從來用不到，垃圾成山，我會有一種很深的負罪感，至於為什麼這麼說，我後面再解釋。
    我們在很早之前溝通的結論，開發同事提供一個列表清單，刪除這些清單中的表資料，這樣能夠完成一些業務的梳理和資料清理，然後提供一個初始的備份交給他們，後期如果需要做一些特殊的資料恢復有據可依，然後在這個基礎上他們會把另外幾個業務線的資料遷移過來，提供資源的利用率。
    所以看到這個需求之後就好像我們之前的暗號一樣，我開始按照計劃來做一個詳細的評估，但是評估發現原來的方案有一些硬傷。
當前所在的環境是一主一備，資料量在1.7T左右。磁碟空間的利用率達到了95%以上，意味著系統中已經沒有多少的剩餘空間。根據我檢視dba_segements的分析，發現需要刪除的資料大概在300G左右，這對於1.7T的資料量來說不是多大的提升，所以我的初步評估就是做資料備份還是有難度的，一來備份集太大，恢復起來難度很大，二來本地磁碟空間不足，想匯出資料絕非易事。
當然我提出難處，還得有解，我的一個建議就是直接把備庫的資料檔案都複製過去，順帶控制檔案，引數檔案，這樣兩個難點看起來都能夠解決，一來恢復起來非常容易，只需要啟用資料庫即可，二來磁碟空間不足的問題可以緩解，可以直接透過rsync或者ftp，scp的方式傳輸過去。這種方案對於開發同事來說，雖然聽起來要複雜一些，但是他們實際想來發現也是受益的，所以也能夠理解我的想法。他們評估了一下，認為還是可行的。
    但是這個時候我突然想到了一個問題，那就是主備庫的磁碟空間問題，如果我要匯出備份，1.7T的資料，如果直接複製資料檔案，得花費半天左右，而在這半天的時間裡，如果產生大量的歸檔，在備庫無法應用就會一直擠壓下來，到時候還是會撐爆磁碟空間，主備庫都有一定的風險，我在使用指令碼檢視了主庫的歸檔頻率情況之後，更加堅定了我的擔心，主庫每天的歸檔在早上大概會有60g左右，也就意味著在半天的時間範圍內，主庫的空間很可能被撐爆。而備庫是計劃是停庫直接複製資料檔案，這個時間持續太長，潛在風險還不少。所以雖然我建議了傳輸資料檔案，突然發現有些事情結合具體環境來看還是有一定的風險，需要綜合評估來看。
    當然我不能一會一個主意，這也會給開發的同事造成很多不專業的影響，所以我簡單的描述了現在的情況，決定還是在資料清理之後再來看看實際的資料使用率再來決定。刪除的工作也是反覆確認，最後直接動用了truncate,刪除資料冗餘，建立資料艱難，刪除的工作總共持續了不到一分鐘，檢視磁碟空間使用情況，讓我大吃一驚，空間剩餘1.5T左右，也就意味著刪除了近1T多的資料。
    這些資料都是和開發同學反覆確認之後操作的，所以在這一點上我也就心安理得了。空間清理的幅度如此之大，讓我有些招架不住，如此一來，還複製資料檔案幹什麼，直接匯出資料，大概會在100G左右，直接推送到目標端，也真心不是什麼難事。所以這樣一來留給開發的任務看起來就更加明朗了，我可以主動推送檔案給他們或者他們來抓取。
    而我在這個基礎上還有一些工作要做，其中重要的一環就是收縮資料庫空間，這個操作可以使用resize datafile的方式來實現，可以使用如下的SQL語句來實現。
select a.file#,a.name,a.bytes/1024/1024 CurrentMB,
          ceil(HWM * a.block_size)/1024/1024 ResizeTo,
          (a.bytes - HWM * a.block_size)/1024/1024 ReleaseMB,
          'alter database datafile '''||a.name||''' resize '||
          ceil(HWM * a.block_size/1024/1024) || 'M;' ResizeCMD
   from v$datafile a,
        (select file_id,max(block_id+blocks-1) HWM
          from dba_extents
          group by file_id) b
  where a.file# = b.file_id(+)
   and (a.bytes - HWM *block_size)>0
我可以根據刪除的收益（能夠釋放的空間情況）來決定是否需要執行相應的SQL語句，一番折騰之後，物理磁碟空間馬上又釋放了幾百G。
在這個基礎上，其實我們還是可以進一步分析資料檔案的高水位線，1T多的資料檔案，實際的資料使用率才200G左右，肯定有些資料庫物件佔用了高水線的位置，導致很多資料檔案無法收縮。當然這個工作也是個細活，需要分析dba_extents，結合dba_segements，目前還沒有想好怎麼自動化分析這個問題，最近有時間了可以搞搞，目前還是手工來做的。