GRECP/LPL RECOVERY
GRECP和LPL是DM標記的兩個DBET狀態。
之前有篇博文講述了LPL
在介紹GRECP/LPL 之前,先介紹下GRECP(GROUP BUFFER POOL RECOVERY PENDING)。
在DATASHARING環境中,每個MEMER都有自己的local buffer pool,當多個MEMBER都該某個page的時候,會先把page讀到自己的local buffer里修改,當達到check point的時候,就會把local buffer里的page送到GBP(GROUP BUFFER POOL)或者把GBP里的page CAST OUT到DASD上,這個過程中每個member都會檢測自己的local buffer里是不是有這些page,如果有的話就要test/refresh最新版本的page,這樣就保證每個member都能看到最新的共享page。
可是在這個過程中,GBP可能壞掉,可能local buffer到GBP的連接失敗,這樣DB2z就會啟動一個DA(damaged assessment)任務去把GBP里那些需要被修改的page標注成GRECP狀態。
通常對于定義成AUTO RECOVERY YES的GBP來說,DB2會AUTO RECOVER GRECP。
當然也可以用下面的辦法手工RECOVER GRECP狀態
對于LPL的page來說,DB2也會AUTO RECOVERY LPL, 也可以用下面的辦法手工RECOVER LPL:
總結
以上是生活随笔為你收集整理的GRECP/LPL RECOVERY的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Flutter 全能型选手GetX ——
- 下一篇: 淘宝十年资深架构师吐血总结淘宝的数据库架