> 借用一句歌詞：" 要是能重來 我要選李白 幾百年前做的好壞 沒那麼多人猜 "

# 1. 故障回放

> 故障修復之後，回想事情發生的整個過程，感覺十分魔幻，以後還是要把命運掌握在自己手裡，不要圍觀。

**2021.09.29 17:30**

```
找主機同事在一套核心資料庫安裝xx備份軟體的agent客戶端，安裝資料庫為Oracle RAC 11.2.0.4.181016雙節點，作業系統為 Solaris 11.3。
```

**2021.09.29 17:35**

```
同事從備份軟體控制檯下載了Solaris平臺備份客戶端代理安裝壓縮檔案，檔名Solaris_5.11_sparc64-latest.tar.gz。

1) 同時連線雙節點。

2) 同時上傳至/root/Downloads目錄 通過tar -xvf 命令解壓

3) 解壓後/root/Downloads目錄裡生成AnyBackupClient目錄，AnyBackupClient目錄有如下檔案
   (1) ClientService 目錄
   (2) etc目錄
   (3) VersionDetails檔案

4) 進入ClientService 使用sh命令 執行 sh install.sh指令碼檔案，執行報錯如下：
errot installation path /root/ below, there will be a permissions issue, please install the client to buid a directory in the /.!

5) 將ClientService 目錄 拷貝至/ 目錄下 進入ClientService 後使用sh命令 執行 sh install.sh。

6) 系統大量提示 find 命令未找到檔案，之後開始停止無輸出，等待3分鐘後使用ctrl+c 將命令中斷。
```

**注：上面**6**個步驟在雙節點均進行了操作，下面步驟只在一節點進行了操作。**

```
7) 隨後將/ClientService 檔案目錄 和 /root/Downloads目錄下的AnyBackupClient刪除

重新使用tar -xvf命令解壓。

8) 拷貝AnyBackupClient 目錄拷貝至 / 目錄下 進入/AnyBackupClient/ClientService 下執行 sh install.sh

9) 系統提示正常安裝步驟，到配置資料庫型別時 選擇oracle資料庫 使用者oracle ，提示oracle資料庫未找到，通過ctrl+c將命令中斷 。

10) 執行 export=ORACLE_HOME=/u01/app/pracle/produce/11.2.0.4/dbhome_1

11) 重新執行 sh install.sh 命令 
```

**2021.09.29 17:45**

```
收到通知，個稅應用以及呼叫個稅相關應用無法正常使用，需要排查。
```

**2021.09.29 17:45**

```
檢視資料庫監控系統，資料庫已經顯示hang，立即使用xshell使用oracle使用者連線主機，發現無法連線。
```

**2021.09.29 17:46**

```
使用執行指令碼xshell視窗root連線執行切換使用者命令
# su – oracle，已經無法切換。
```

**2021.09.29 17:48**

```
聯絡客戶請求重啟主機。
```

**2021.09.29 17:50**

```
小機分割槽進行重啟。
```

**2021.09.29 17:50**

```
reboot命令 將個稅兩個分割槽均進行了重啟，重啟之後，系統外部無法訪問。
```

**2021.09.29 17:55**

```
在ldm 管理分割槽上使用 console終端進入分割槽，發現分割槽已經處於單使用者模式 無法識別網路卡，故障形成，且無法通過重啟恢復。
```

# 2. 第一階段恢復嘗試修復Solaris主機

1. 經過分析執行步驟與指令碼內容，發現引起故障原因如下

```
install.sh指令碼本應該有兩層目錄，但是由於同事拷貝了一層目錄，導致install.sh指令碼只有了一層目錄，也就是/ClientService，但是install.sh指令碼會對AnyClientService自身目錄下etc目錄以及上層目錄進行更改許可權，但是由於只有一層目錄，導致賦權變成了：
# chown / root:root -R 
# chown //etc root:root
...
還有等等幾個類似賦權，導致OS部分/var、/etc下檔案許可權發生變化，導致作業系統無法識別網路卡，在solaris管理節點檢視分割槽分配均正常，一些網路卡檔案確認存在且許可權正確。
```

2. 第一時間聯絡備份軟體廠商以及其他廠商，請求協助。

```
進行了如下修復：
嘗試與正常OS對比，手工修改檔案許可權，嘗試是否可以修復OS。
```

>經過兩三個小時各路工程師診斷修復，OS依然無法修復，此時我們開始準備下面另一套恢復方案。

# 3. 第二階段恢復儲存對映磁碟給另一套RAC掛載磁碟組

> 操作過程由恩墨專家遠端協助，共同恢復，在此感謝各位在故障發生時給予支援。

## 3.1 修復一節點

> 不幸中萬幸，我們有一套一模一樣Solaris RAC叢集，以前的遷移中間庫，並且在同一個SAN網路中，我們在原廠工程師修復原來那套RAC作業系統的同時，準備開始著手對映磁碟方案，最終我們也採用了這個方案，因為到晚上十二點的時候，原來RAC兩臺OS還是無法恢復，故障依舊，為了保證第二天白天業務正常，我們開始對映儲存，異機掛載ASM磁碟方案。

1. 檢查新環境OS環境是否正常

```shell
# 恢復步驟
新環境中間庫停庫，新環境主機重啟叢集伺服器，確認新環境是否有問題。
```

2. 移除新環境與原來環境同名磁碟組磁碟

```shell
# 由於兩套環境ASM磁碟組均相同，所以需要先將新環境中FRA與DATA磁碟組磁碟隱藏
# Solaris預設發現ASM磁碟路徑在/dev/rdsk目錄下，/dev/rdsk目錄下檔案未/devices/scsi_vhci/*下面檔案軟連結。
# 確認新環境ASM磁碟，準備隱藏
$ sqlplsu / as sysasm
SQL> select path,name,header_status from v$asm_disk;
# 通過kfed再次確認磁碟
$ kfed read <disk_name>|egrep "kfdhdb.grpname|kfdhdb.dskname"
$ sqlplsu / as sysasm
SQL> alter diskgroup fra dismount;
SQL> alter diskgroup data dismount;
# cd /dev
# mkdir old_disk
# 先暫時隱藏磁碟，隱藏之後，cfgadm -al掃盤或重啟，會再次生成，需要注意
# mv <disk_name> old_disk/
```

3. 在儲存控制檯將原環境ASN磁碟LUN對映到新主機

```shell
# 掃描磁碟
# cfgadm -al
# 需要將第二步再執行一遍，因為之前dismount的磁碟也再次被掃描了出來。
```

4. 修改FRA磁碟組磁碟磁碟屬主與許可權

```shell
通過kfed讀取磁碟頭找出FRA磁碟組磁碟，修改FRA對映磁碟組許可權。改為grid:asmadmin，0660
# Solaris下修改/devices/scsi_vhci/*下檔案屬性。
```

5. 新環境修改asm例項asm_diskstring

```shell
# 其實也可以不修改asm_diskstring，Solaris預設即會發現/dev/rdsk下磁碟。
# 修改asm_diskstring發生小插曲，無法修改，ps -ef|grep LOCAL=YES發現有幾個會話，懷疑有未關閉視窗阻塞修改，最後通過shutdown abort，重啟asm例項修改。
$ sqlplus / as sysasm
SQL> shutdown abort;
SQL> startup;
SQL> alter system set asm_diskstring='/dev/rdsk/*';
```

6. 新環境先嚐試掛載FRA磁碟組

```shell
$ sqlplus / as sysasm
SQL> alter diskgroup fra mount;
# 可以正常掛載，下面開始同樣步驟掛載DATA磁碟組。
# 如果新環境中crsctl status res -t中沒有磁碟組資源，則使用下面命令新增即可
# root使用者
# crsctl add  res ora.<diskgroup_name>.dg -type ora.diskgroup.type -attr "ACL='owner:grid:rwx,pgrp:oinstall:rwx,other::rw-',AUTO_START=always,VERSION=11.2.0.4.0" -i
# crsctl start resource ora.<diskgroup_name>.dg
```

7. 掛載DATA磁碟組

```shell
# 省略上面確認磁碟與掛載，最後成功掛載data磁碟組
$ sqlplus / as sysasm
SQL> alter diskgroup data mount;
# root使用者
# crsctl add  res ora.<diskgroup_name>.dg -type ora.diskgroup.type -attr "ACL='owner:grid:rwx,pgrp:oinstall:rwx,other::rw-',AUTO_START=always,VERSION=11.2.0.4.0" -i
# crsctl start resource ora.<diskgroup_name>.dg
```

8. 嘗試開啟資料庫

```shell
新建adump目錄，在ORACLE_HOME/dbs下新建init<sid>.ora指向DATA磁碟組spfile，直接open資料庫。
# 很幸運，在這個步驟未遇到任何問題，資料庫在新環境1節點成功open。
```

9. 將原環境2個public、2個vip、1個scan全部使用scan_listener方式掛載到新環境1節點

```shell
# 應用使用了所有public跟vip，所以將原環境所有ip均使用scan方式浮動到新環境1節點
## 更改SCAN IP
# 檢視叢集狀態
# grid使用者
$ crsctl stat res -t
$ srvctl config scan
$ srvctl status scan_listener

# grid使用者執行
$ srvctl stop scan
$ srvctl stop scan_listener

# 首先修改RAC雙節點 /etc/hosts，將scan IP對映
xx.xx.xx.xx <scan hostname="">
...五個IP均協商，後面scan hostname均為新環境$ srvctl config scan檢視到的scan名稱即可

# root 在節點1上執行
/u01/app/grid/bin/srvctl modify scan -n <scan>
/u01/app/grid/bin/srvctl modify scan_listener -u

# grid使用者 ，檢視scan修改情況
$ srvctl config scan

# grid使用者執行
$ srvctl start scan
$ srvctl start scan_listener
# grid使用者檢視狀態
$ srvctl status scan_listener
# 此時可以看到五個IP均已scan方式浮動到1節點。
```

## 3.2 修復2節點

> 我們修復1節點之後，已經接近凌晨五點，所以在應用驗證可以正常連線資料庫，資料無問題之後，再未進行任何操作。
>
> 當天白天申請了停機視窗，停機維護二節點，主要進行二節點加入叢集、修改叢集public/private/scan IP，保持與原叢集一直。
>
> 白天的時候，我們從儲存控制檯將原來環境中的FRA磁碟與DATA磁碟徹底從儲存對映中移除，徹底解決掃盤以及重啟會導致原ASM磁碟再次被掃出問題。

1. 二節點嘗試掃描磁碟

```shell
# root使用者
# cfgadm -al
```

2. 二節點與一節點磁碟核對，確認磁碟是否均一致

```shell
主要核對二節點是否掃描到所有一節點FRA、DATA磁碟組磁碟。
```

3. 二節點修改磁碟屬主，許可權

4. 叢集移除原有資料庫資源

```shell
# oracle使用者，移除原來用於遷移的中間庫
$ srvctl remove database -d <db_unique_name> [-f] [-y]
```

5. 二節點啟動叢集，檢視磁碟組是否自動mount

```shell
由於提前修改了磁碟屬性，且叢集中有現成FRA、DATA資源，所以直接可以由叢集將磁碟組掛載。
```

6. 修改adump、修改pfile指向

```
FRA、DATA磁碟組mount，修改$ORACLE_HOME/dbs/init<sid>2.ora指向ASM spfile
在二節點建立adump目錄
```

7. open二節點資料庫

8. 資料庫加入叢集資源

```shell
# oracle使用者
$ srvctl add database -d <db_unique_name> -o <oracle_home> [-p <spfile>]
```

9. 兩節點例項加入叢集資源

```shell
# oracle使用者
$ srvctl add instance -d <db_unique_name> -i <inst_name> -n <node_name> [-f]
```

10. 一節點移除之前加入叢集五個scan listener，並同時修改scan為原故障機器scan vip

```shell
How to Update the IP Address of the SCAN VIP Resources (ora.scan.vip) (Doc ID 952903.1)
## 更改SCAN IP
# 檢視叢集狀態
# grid使用者
$ crsctl stat res -t
$ srvctl config scan
$ srvctl status scan_listener

# grid使用者執行
$ srvctl stop scan
$ srvctl stop scan_listener

# 首先修改RAC雙節點 /etc/hosts，將scan IP對映
xx.xx.xx.xx <scan hostname="">

# root 在節點1上執行
/u01/app/grid/bin/srvctl modify scan -n <scan>
# 更新scan_listener配置
/u01/app/grid/bin/srvctl modify scan_listener -u

# grid使用者 ，檢視scan修改情況
$ srvctl config scan

# grid使用者執行
$ srvctl start scan
$ srvctl start scan_listener
# grid使用者檢視狀態
$ srvctl status scan_listener
```

## 3.3 修改public/vip

> 由於現有環境與原有環境叢集所有IP均處於同一網段，所以修改各個IP均比較簡單
>
> How to Modify Public Network Information including VIP in Oracle Clusterware (Doc ID 276434.1).pdf

### 3.3.1 修改public IP

```shell
# RAC滾動修改

# grid使用者 1節點
$ crsctl status res -t

# 1節點停止叢集
# root使用者
# crsctl stop crs

# rac所有節點同時修改/etc/hosts
！ 只修改1節點public ip與hostname對應
！ 只修改1節點public

# 修改網路卡IP

# 啟動1節點叢集
# crsctl start crs

# 檢查叢集狀態,grid使用者
$ crsctl status res -t

################ grid使用者 2節點
$ crsctl status res -t

# 2節點停止叢集
# root使用者
# crsctl stop crs

# rac所有節點同時修改/etc/hosts
！ 只修改2節點public ip與hostname對應
！ 只修改2節點public

# 修改網路卡IP

# 啟動2節點叢集
# crsctl start crs

# 檢查叢集狀態,grid使用者
$ crsctl status res -t
```

### 3.3.2 不修改網段修改VIP地址

```shell
# 11gR2
$ srvctl config nodeapps -a

# 11.2,檢視VIP狀態
$ crsctl stat res -t

# 11gR2，grid使用者
$ srvctl stop vip -n <node_name> -f

# 驗證IP地址是否已經不在
$ ifconfig -a

# 修改VIP資源，root使用者
# srvctl modify nodeapps -n <node> -A <new_vip_address or="" new_vip_hostname="">/<netmask>/

eg.
srvctl modify nodeapps -n db-oracle-node1 -A db-oracle-node1-vip/255.255.255.0/bond0

# 驗證
# grid使用者
$ srvctl config nodeapps -a

# 啟動nodeapps
$ srvctl start vip -n <node_name>

# 檢視資源
$ crsctl status res -t
```

# 4. 總結

>在整個恢復過程中，公司、客戶聯絡了所有能聯絡到的資源，彙集了許多高階工程師協助解決，最終在故障持續了10個多小時後恢復了資料庫服務。教訓異常的慘痛，也十分感謝大家的幫助。

1. 對於Oracle RAC這種高可用架構，高可用的設計就是為了避免單點故障，所以操作時務必一個節點配置完畢，檢查校驗沒有問題，再在另一個節點進行操作，這樣做，單節點故障，不至於造成整個資料庫服務中斷。
2. 對核心資料庫安裝部署任何軟體，一定要保持謹慎，此次資料庫備份軟體agent其實我們在部署之前在其他平臺Aix、Linux資料庫主機上一直沒有遇到過任何問題，不過均未像此次操作一樣單獨移出子目錄，都是一次性解壓、安裝，這說明在資料庫伺服器上安裝軟體要謹慎，嚴格按照步驟流程操作。
3. 對於新軟體，一定要解壓直接使用，不要輕易挪動軟體中任何東西再執行，因為無法預知指令碼中到底有沒有判斷指令碼所在目錄。
4. 遇到故障，第一時間想辦法先恢復業務。
5. 故障不是自己操作，但是責任是要一起承擔的，謹慎、謹慎、謹慎。
6. 最後，此次備份軟體agent指令碼中的賦權確實也存在一定問題，它並未判斷自己上層目錄是否是自己正常解壓目錄，希望以後軟體都打包成類似rpm包之類的安裝包，免去解壓、安裝可能造成的錯誤。

> 希望老家的暴雨災害能更快更好的恢復，祝福大家以後事情都順順利利。</node_name></netmask></new_vip_address></node></node_name></scan></scan></node_name></inst_name></db_unique_name></spfile></oracle_home></db_unique_name></sid></db_unique_name></scan></scan></sid></diskgroup_name></diskgroup_name></diskgroup_name></diskgroup_name></disk_name></disk_name>

生產庫當機加老家暴雨的十一，我想倒帶

相關文章