第七十九期 兒童節(jié)驚魂
6月第一天，又是兒童節(jié)，加上客戶現(xiàn)場來了不少娃，也有一些客戶家里有娃去參加活動了，所以整體的氛圍是十分輕松愜意的。然鵝，一通電話打破了這一份來之不易的平靜。
1 主板掛了？
這是我們公司另一個地方的項(xiàng)目，之前我跑的前期溝通和部分?jǐn)?shù)據(jù)庫環(huán)境的搭建工作，雖然2年多沒去過難了，但是整體來說那邊的客戶對我的感官還蠻好的（當(dāng)然中間還是遠(yuǎn)程處理過故障滴）。今天這通電話就是那邊項(xiàng)目經(jīng)理打來，原來是那邊X8M的一個計(jì)算節(jié)點(diǎn)莫名其妙的掛了，操作系統(tǒng)沒起起來，隨即遠(yuǎn)程過去看。
首先，掛掉的節(jié)點(diǎn)ilom還能登上去，過去就發(fā)現(xiàn)一些問題：
通過show /System/Open_problems命令可以看到MB（主板）和P0、P1（CPU）都有報(bào)錯，兩個CPU同時壞的的可能性很低，因此這里大概率是主板有問題。緊接著通過show faulty命令查看詳細(xì)信息（內(nèi)容有點(diǎn)多這里就不展示了），發(fā)現(xiàn)是異常重啟后主板無法加電。
根據(jù)一般的標(biāo)準(zhǔn)解決方案，是先清理告警再嘗試重啟，不行再說換硬件的事情，下面是在ilom中如何清理告警：
start /SP/faultmgmt/shell/ #進(jìn)入故障管理工具后臺
faultmgmtsp>
fmadm faulty #查詢所有告警
fmadm repaire fault_UUID #這里需要通過執(zhí)行清理上面所有告警的UUID
exit
reset /SP/ #重啟節(jié)點(diǎn)
這里斷電重啟節(jié)點(diǎn)之后操作系統(tǒng)仍然沒起起來，faulty倒是沒有再次生成，機(jī)房管理也終于到了機(jī)房，發(fā)現(xiàn)這個計(jì)算節(jié)點(diǎn)只有ilom燈亮了，其余的系統(tǒng)燈、硬盤燈一個沒亮，主板還是沒有加電。硬件維保廠商也上線了，說可能需要拔電源線并等待放電一段時間后重啟，由于機(jī)房管理不敢操作，只能等待硬件維保廠商人員到場。到了中午，硬件維保廠商工程師進(jìn)入了機(jī)房，拔電放電重啟后，操作系統(tǒng)果然起來了，接著就是他們檢查下硬件收收日志回頭看看到底發(fā)生了啥。
你以為這就完了？還早呢，現(xiàn)場數(shù)據(jù)庫維護(hù)發(fā)現(xiàn)節(jié)點(diǎn)數(shù)據(jù)庫沒起起來，因此在我午覺的時候又把我吵醒了遠(yuǎn)程去查看。
2 時間同步
通過crsctl check crs檢查，發(fā)現(xiàn)Cluster Ready Services沒起起來，用下面命令嘗試重啟crs并監(jiān)控日志：
su - root
/u01/app/19.0.0.0/grid/bin/crsctl stop crs -f
/u01/app/19.0.0.0/grid/bin/crsctl start crs
tail -f /u01/app/grid/diag/crs/HOSTNAME/crs/alert/log.xml
在查看日志的過程中發(fā)現(xiàn)是兩個計(jì)算節(jié)點(diǎn)的時間差距很大造成CRS啟動失敗。檢查時間同步服務(wù)，發(fā)現(xiàn)出其余節(jié)點(diǎn)（計(jì)算和存儲節(jié)點(diǎn)）都是通過出故障這個節(jié)點(diǎn)進(jìn)行時間同步，而這個節(jié)點(diǎn)又是通過外部時間同步服務(wù)器進(jìn)行時間同步，然而以前配置的時間同步服務(wù)器（自建的）已經(jīng)回收，現(xiàn)在改用硬件時間同步設(shè)備，因此將兩個計(jì)算節(jié)點(diǎn)全部調(diào)整至外部硬件時鐘設(shè)備，存儲節(jié)點(diǎn)由于網(wǎng)絡(luò)問題設(shè)置到兩個計(jì)算節(jié)點(diǎn)同步時間。
處理完成后再次：
su - root
/u01/app/19.0.0.0/grid/bin/crsctl stop crs -f
/u01/app/19.0.0.0/grid/bin/crsctl start crs
這里CRS就起起來了，然鵝還是有問題。
3 數(shù)據(jù)庫參數(shù)
CRS起起來了，但是ACFS和DB沒有起來，ACFS放在后面，畢竟只用于做部分重要表的離線備份，DB才是最重要的。
startup nomount
alter database mount;
-- 結(jié)果出現(xiàn)了以下報(bào)錯
ORA-01105: mount is incompatible with mounts by other instances
ORA-01677: standby file name convert parameters differ from other instance
檢查節(jié)點(diǎn)參數(shù)發(fā)現(xiàn)：
--節(jié)點(diǎn)2（正常節(jié)點(diǎn)）：
SQL> show parameter file_name_convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string
log_file_name_convert string
pdb_file_name_convert string
--節(jié)點(diǎn)1（故障節(jié)點(diǎn)）：
SQL> show parameter file_name_convert
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_file_name_convert string 'dbdg','db'
log_file_name_convert string 'dbdg','db'
pdb_file_name_convert string
create pfile='/home/oracle/initdb0601.ora' from spfile;
檢查spfile內(nèi)容發(fā)現(xiàn)db_file_name_convert和log_file_name_convert參數(shù)都是配置過的，這就很奇怪了，運(yùn)行實(shí)例為啥值為空，只能判斷為前任DBA做了配置，但是沒有重啟數(shù)據(jù)庫，也因此造成了這次實(shí)例無法啟動。（其實(shí)數(shù)據(jù)庫配置了OMF，在ADG環(huán)境是不需要配置convert參數(shù)的，這套ADG我以前搭的時候是沒有配置這兩個參數(shù)，但是有些DBA總覺得這個參數(shù)是必須的）。
alter system reset db_file_name_convert scope=spfile sid='*';
alter system reset log_file_name_convert scope=spfile sid='*';
shut immediate
startup --這里就能正常啟動了
--不要嘗試直接將db_file_name_convert和log_file_name_convert直接設(shè)為空：
alter system set db_file_name_convert='' scope=spfile sid='*';
ORA-01678: parameter string must be pairs of pattern and replacement strings
--convert參數(shù)必須是每兩個為一組一一對應(yīng)的
4 ACFS
本來ACFS起不起來都不是啥大事，但是奈何業(yè)務(wù)需要對重要表進(jìn)行離線備份，再說了日常巡檢掛著看著也不舒服。經(jīng)過基本檢查發(fā)現(xiàn)ACFS模塊沒有啟動起來，因此需要啟動，但是出現(xiàn)了以下的問題：
su -
/u01/app/19.0.0.0/grid/bin/acfsload start
sh: -c: line 0: unexpected EOF while Looking for maching ``'
sh: -c: line 1: syntax error: unexpected end of file
這個報(bào)錯就有點(diǎn)莫名其妙了，結(jié)合之前通過主機(jī)名ping節(jié)點(diǎn)的一些異常（這里通過我的虛擬機(jī)做了個模擬展示）：
讓我隱約感覺到這個/etc/host.conf中有些異常，進(jìn)去一看果然發(fā)現(xiàn)里面有一行reorder hosts,bind，也是報(bào)錯的內(nèi)容，注釋掉之后再次啟動acfs模塊：
su -
/u01/app/19.0.0.0/grid/bin/acfsload start
#這次是正常啟動了
當(dāng)然到這里還沒完：
su - grid
srvctl start asm -proxy #啟動ora.proxy_advm
asmcmd volenable -G DATAC1 ACFSVOL01 #啟動ACFS卷
su -
mount.acfs -o all #掛載所有ACFS卷
沒有報(bào)錯，ACFS也正常掛載。至此，故障處理完成，當(dāng)然還是要等硬件側(cè)的日志分析。
5 兩個錯誤
這件事情中有兩個很奇怪的問題，第一個就是修改了需要重啟生效的參數(shù)但沒有重啟數(shù)據(jù)庫，這個我可以判定為前任DBA的疏忽，但是總歸是不專業(yè)的表現(xiàn)。
第二個則是/etc/host.conf中配置的問題，可能有人覺得是不是配錯了，這里我給大家一個配置文件的原始截圖：
（這里的multi on是因?yàn)橐煌ㄟ^DNS配置IPv4和IPv6雙棧運(yùn)行，是專門開SR咨詢過是可以修改的）
而reorder這行也是專門寫了不要進(jìn)行修改。翻看Linux的相關(guān)文檔：
這個參數(shù)的值只允許為on和off，加上配置文件詳細(xì)寫明了不要更改內(nèi)容。前任DBA也是有OCM的人，這兩件事情加在一起不得不讓我懷疑這是不是故意的。文章來源：http://www.zghlxwxcb.cn/news/detail-468082.html
總結(jié)
也許是我小人之心度君子之腹了，但是有些事情以前就看破過，說破過，真的不好說了。
本次處理呢有很多東西沒來得及截圖也不方便截圖，處理過程一些波折也經(jīng)過了簡化。
老規(guī)矩，知道寫了些啥。文章來源地址http://www.zghlxwxcb.cn/news/detail-468082.html
到了這里，關(guān)于數(shù)據(jù)庫管理-第七十九期 兒童節(jié)驚魂（20230601）的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
