和開發討論的一個資料變更需求
最近在評估一個開發同事的需求時,發現隨著需求的變化,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,目前還沒有想好怎麼自動化分析這個問題,最近有時間了可以搞搞,目前還是手工來做的。
首先開發提出的一個資料需求,刪除資料庫中的幾張表資料,然後把剩下的資料都備份,把備份集複製到一個異機環境。其實這個需求在之前也很他們溝透過,這是他們業務遷移的一個步驟,同時做一些業務梳理,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,目前還沒有想好怎麼自動化分析這個問題,最近有時間了可以搞搞,目前還是手工來做的。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/8494287/viewspace-2107477/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 【經驗分享,歡迎討論】專案管理中需求變更太頻繁,怎麼辦?專案管理
- 敏捷開發中如何從容應對需求變更?敏捷
- 外掛需求討論群 241266707
- 老闆要我開發一個簡單的工作流,15 次需求變更,我幹到禿了。。
- 需求變更,程式碼改的像辣雞 - 論程式碼質量
- Hibernate 一個更新問題的 討論
- 關於 Angular 裡 module 和 Component 包含粒度的一個討論Angular
- 資料分析主題討論
- 專案需求討論 – 定位功能小結
- 專案需求討論-自定義滾輪
- 專案需求討論 - 定位功能小結
- 資料庫系列:高併發下的資料欄位變更資料庫
- 專案需求討論— ButterKnife初級小結
- 專案需求討論:截圖—塗鴉—分享
- 專案需求討論 — ConstraintLayout 詳細使用教程AI
- 變更資料捕獲CDC的八個實際案例 - Dunith
- 資料庫系統架構討論資料庫架構
- 一個比 Redis 效能更強的資料庫Redis資料庫
- 對容器映象的思考和討論
- 當我們在聊「開源大資料排程系統Taier」的資料開發功能時,到底在討論什麼?大資料AI
- 一個關於月球車的筆試題--求討論筆試
- 持續可用與CAP理論 - 一個資料庫系統開發者的觀點資料庫
- 專案管理中的需求變更分析和解決之道專案管理
- python和Java哪個更適合web開發?PythonJavaWeb
- Python和Java,哪個更適合web開發?PythonJavaWeb
- 關於BSS資料化轉型的幾點討論
- 需求變更,敏捷專案應如何做?敏捷
- Netflix計劃於2020年開源的資料庫資料複製重器:DBLog,一個類似Oracle OGG的通用的變更資料捕獲CDC框架 - Netflix資料庫Oracle框架
- [iOS Monkey 討論帖] 整套新的 fastmonkey 討論iOSAST
- 論如何監聽一個物件的變化物件
- 力軟(.NET)敏捷開發框架,讓開發變的更簡單敏捷框架
- (想法 2)此貼討論一下 UI 自動化個人的一個想法UI
- 討論
- LiquiBase 管理資料庫變更實踐UI資料庫
- SQL Server 變更資料捕獲(CDC)SQLServer
- 專案需求討論 - WebView下拍照及圖片選擇功能WebView
- 有沒有一些大廠的高階架構技術討論討論架構
- 基於MySQL資料庫討論虛擬機器資料恢復MySql資料庫虛擬機資料恢復
- Airbnb的變更資料捕獲系統,實現資料突變實時響應AI