馬曉亮中國PG分會認(rèn)證專家金風(fēng)科技DBA，恩墨學(xué)院PostgreSQL金牌講師，從事10余年的數(shù)據(jù)庫相關(guān)工作，對通訊信息化、電網(wǎng)安全改造有豐富經(jīng)驗，為公司主要產(chǎn)品的國產(chǎn)化技術(shù)轉(zhuǎn)型做了很多工作，未來主要基于開源構(gòu)建公司相關(guān)業(yè)務(wù)支撐。【摘要】

Global 默認(rèn)是PG的系統(tǒng)表空間，存儲的是共享系統(tǒng)字典表還有控制文件相關(guān)信息，此表空間下的文件是整個數(shù)據(jù)庫系統(tǒng)訪問控制的核心，一旦損壞數(shù)據(jù)庫訪問將會受限，尤其是控制文件受損將會導(dǎo)致系統(tǒng)的不可用，本文通過實際的現(xiàn)場global下文件受損導(dǎo)致數(shù)據(jù)庫不可用案例，來講述如何重構(gòu)系統(tǒng)表空間以及控制文件來恢復(fù)數(shù)據(jù)庫，從而通過邏輯備份快速導(dǎo)出數(shù)據(jù)，對以后postgresql 的global下的文件損壞而導(dǎo)致的數(shù)據(jù)庫問題可以嘗試使用此方法。

1.?問題的提出

接到客戶現(xiàn)場反饋說業(yè)務(wù)應(yīng)用連接數(shù)據(jù)庫異常，提示global目錄下對象存在無效的頁，通過遠(yuǎn)程過去查看日志發(fā)現(xiàn)確實pg數(shù)據(jù)庫的核心表空間下的對象出問題，詳細(xì)的跟現(xiàn)場了解下情況，現(xiàn)場反饋說服務(wù)器硬盤壞了(服務(wù)器有raid 磁盤冗余保護(hù))，很難理解怎么會影響上層的業(yè)務(wù)應(yīng)用，原來是客戶要定期的從服務(wù)器上要拷貝生產(chǎn)業(yè)務(wù)報告(電網(wǎng)內(nèi)有隔離)，當(dāng)時U盤不可用服務(wù)器廠商讓客戶重啟服務(wù)器試試，誰知道起不來了，據(jù)說服務(wù)器廠商讓客戶又做了拔掉電源等系列匪夷所思的操作后系統(tǒng)能夠正常登陸了，但是此時數(shù)據(jù)庫就掛了，從整體的描述來看初步判斷是服務(wù)器的raid卡出問題了導(dǎo)致系統(tǒng)登錄問題以及識別不到U盤。

報錯信息：

2.?解決思路

根據(jù)以上的信息聯(lián)想到是否可以通過跳過無效的頁來解決問題，仔細(xì)分析后發(fā)現(xiàn)此問題跟我們實際當(dāng)中碰到的數(shù)據(jù)頁損壞還是有區(qū)別的，因為數(shù)據(jù)頁損壞我們跳過數(shù)據(jù)不訪問便是，但是系統(tǒng)表空間下對象信息是一點也不能被忽視，也想過是否可以向oracle那樣重建系統(tǒng)表空間呢，可是并找到pg相關(guān)重建系統(tǒng)表空間的方法，那怎么辦呢？比較慘的事情遠(yuǎn)遠(yuǎn)沒有結(jié)束，檢查備份發(fā)現(xiàn)近一年的備份都是無效備份，看來通過備份的方式是沒戲了，當(dāng)時感覺天是黑黑的！

無效備份文件：

好消息是數(shù)據(jù)庫可以正常登陸：

2.1.?如何解決問題

1、是否可以嘗試別的方式恢復(fù)global:有個想法既然global下存儲的是共享系統(tǒng)字典表，那么我們是不是就可以通過初始化一個庫來重新生成新的global呢？感覺可行，但是這里面有個問題就是需要重建控制文件，ok有思路總比一頭霧水強(qiáng)，說干就干.

1)：通過物理拷貝的方式備份數(shù)據(jù)庫副本來進(jìn)行驗證操作

2)：我通過initdb 初始化一個實例

3)：拷貝原備份副本里面的global文件到global_bak

4)：拷貝新生成的global表空間目錄到原備份副本中

5)：嘗試重建控制文件

6)：嘗試?yán)饠?shù)據(jù)庫

[highgo@localhost highgo]$ ll

總用量 16

drwx------. 21 highgo highgo 4096 12月 25 09:25 9.4? ? ? ? --原數(shù)據(jù)庫數(shù)據(jù)文件

drwx------. 20 highgo highgo 4096 12月 24 18:06 9.4_bak? ? --備份數(shù)據(jù)庫副本

drwx------. 18 highgo highgo 4096 12月 24 17:27 9.5? ? ? ? --初始化數(shù)據(jù)庫數(shù)據(jù)文件

[highgo@localhost 9.4_bak]$ ll

總用量 152

drwx------. 7 highgo highgo? 4096 12月 24 17:45 base

drwx------. 2 highgo highgo? 4096 12月 25 09:26 global? ? ? ? --初始化拷貝新global文件? ?

drwx------. 2 highgo highgo? 4096 12月 24 18:33 global_bak? ? --原表空間備份副本

drwxr-x---. 2 highgo highgo? 4096 12月 24 17:59 hgdb_log

drwx------. 2 highgo highgo? 4096 12月 24 18:46 pg_clog

2.2.?計算控制文件信息

1、查看pg_xlog

按照早期9.2的版本pg_resetxlog –l 參數(shù)需要-l timelineid,fileid,seg三個參數(shù)現(xiàn)場是9.4的版本只需要一個參數(shù)指定下一個事務(wù)日志號即可。

2、查看pg_clog? ?

-x 參數(shù)來自pg_clog

查看pg_multixact

-O參數(shù)來自members

-m參數(shù)來自offsets

根據(jù)以上三個文件的內(nèi)容我們計算的控制文件信息如下:

pg_resetxlog -l 00000001000000300000003D -x 0x002000000 -m 0x0003,0x0003 -O 0x0006 /opt/goldwind/pgdata/data/highgo/9.4_bak -f

2.3.?異常情況

1、?準(zhǔn)備好了一切按照我們的設(shè)想需要重啟庫來驗證下是否可行。

數(shù)據(jù)庫啟動正常，心理安心了不少。

Ok 數(shù)據(jù)庫可以正常訪問，心理的一塊石頭落地了！

2、?高興的有點早啊，因為發(fā)現(xiàn)數(shù)據(jù)庫是正常了，但是我們業(yè)務(wù)數(shù)據(jù)庫沒有想象中一樣出現(xiàn)，檢查發(fā)現(xiàn)數(shù)據(jù)肯定是存在的。

2.4.?恢復(fù)

1、?果然問題并沒有想的那么簡單，我們忽略了重要的信息，那就是字典表里面有部分對象存儲著初始化后新增對象的字典信息，既然這樣那么開始嘗試查看無效頁的對象：

由于對象沒有辦法確認(rèn)那么我們只能嘗試著去規(guī)避這個對象了：

1) 清理此對象涉及的物理文件

2) 拷貝清理后的global所有對象到備份副本下

3) 嘗試再次重建控制文件

4) 嘗試啟動數(shù)據(jù)庫

5) 嘗試連接數(shù)據(jù)庫

6) 驗證成功后嘗試備份數(shù)據(jù)

3.?實踐情況

此文檔通過另一種方式恢復(fù)了數(shù)據(jù)庫的global表空間，幸運的是沒有碰到記錄系統(tǒng)對象的表，恢復(fù)之后在想如果碰到是類似pg_database數(shù)據(jù)丟失我們是不是也能通過此方法來處理呢，答案應(yīng)可以，為什么呢，因為只要知道系統(tǒng)內(nèi)的數(shù)據(jù)庫信息一樣可以人為的補(bǔ)全。

4.?效果評價

此現(xiàn)場沒有備份如果恢復(fù)不了面臨的就是20G生產(chǎn)業(yè)務(wù)數(shù)據(jù)的丟失，隨時不可估量，但是我們恢復(fù)了就說明此方法可行。

5.?推廣建議

建議極端情況下可以嘗試此方法，一般恢復(fù)后建議立即備份。

6.?參考資料

無

?――完――

歡迎投稿

????????中國開源軟件推進(jìn)聯(lián)盟PostgreSQL分會，歡迎大家積極投稿，向PGer分享自己的實踐經(jīng)驗、心得體會，共建PG中國生態(tài)。

投稿郵箱：

partner@postgresqlchina.com

總結(jié)

以上是生活随笔為你收集整理的plsql查看表空间_最佳实践—PG数据库系统表空间重建的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。