第七十期 自己？自己
來到70了，最近有點(diǎn)卷，寫的稍微多了些。
吐槽一下五一調(diào)休，周末砍一天，連6天，放5天，上3天，周末又砍一天。
今天刷抖音看到現(xiàn)在是如何看伍佰演唱會(huì)的：“花500買票，去伍佰的演唱會(huì)，唱伍佰的歌給伍佰聽，伍佰只要起個(gè)頭，插不上嘴”。突然回憶起伍佰的《突然的自我》。最近還是除了很多跟“自己”相關(guān)的事情，記錄一下。
1 自己嚇自己
這里是前段時(shí)間做ADG搭建準(zhǔn)備的時(shí)候發(fā)現(xiàn)的，dbca建庫的時(shí)候開啟了FRA和日志歸檔。到準(zhǔn)備修改log_archive_dest_1參數(shù)時(shí)，發(fā)現(xiàn)這個(gè)值為空，理論上默認(rèn)配置這個(gè)參數(shù)應(yīng)該為：
log_archive_dest_1='LOCATION=use_db_recovery_file_dest'
同時(shí)去FRA目錄下通過下面命令查看目錄：
ASMCMD> ls +RECOC1/db_unique_name/
發(fā)現(xiàn)里面沒有ARCHIVELOG文件夾，歸檔虛空了？通過EM看備份日志，發(fā)現(xiàn)日常的備份日志是跑著的啊，有點(diǎn)小就是了（我一個(gè)日志組10G，每3小時(shí)的歸檔備份一般也就10-50G之間）。難道是只有備份期間的日志歸檔被備份了？平時(shí)沒有產(chǎn)生。到這里我下出了一身冷汗，沒有歸檔還沒有搭A(yù)DG意味著備份幾乎沒啥用。
冷靜一下，還是發(fā)現(xiàn)一個(gè)問題，歸檔剛剛備份完，有20多個(gè)G，我就嘗試做了：
alter system switch logfile;
這時(shí)候“驚訝”的發(fā)現(xiàn)FRA目錄下出現(xiàn)了ARCHIVELOG文件夾，剛剛切換生產(chǎn)的歸檔日志也有。當(dāng)然參數(shù)還是正常配了：
alter system set log_archive_dest_1='LOCATION=use_db_recovery_file_dest VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=primary_db_unique_name';
這里可以看到在開啟FRA功能的默認(rèn)情況下，歸檔在配置的FRA路徑下生產(chǎn)歸檔文件，我屬于是在“正確”的時(shí)間看到了“正確”的輸出做出了“正確”的驚嚇。翻遍官方文檔也就發(fā)現(xiàn)下面描述比較貼切：
歸檔模式，開了FRA默認(rèn)就是在FRA，沒開就會(huì)去dbs目錄。這盤屬實(shí)是自己嚇自己。
2 自己坑自己
接下來到上面那個(gè)環(huán)境的ADG備庫，因?yàn)榉?wù)器給我的時(shí)候，有臺(tái)服務(wù)器HBA卡是壞的，更換需要時(shí)間，但是災(zāi)備環(huán)境上線又比較急（報(bào)了考核的），就只能把另外兩臺(tái)裝好，先把ADG弄好，服務(wù)器修好了再加入集群。
在這中間出過一丟丟小插曲，其實(shí)以前遇到過，就是一個(gè)沒有經(jīng)過dbca的集群，db中因?yàn)?ORACLE_HOME/bin/oracle權(quán)限的問題是無法使用ASM磁盤組的，需要執(zhí)行以下操作：
$GRID_HOME/bin/setasmgidwrap -o $ORACLE_HOME/bin/oracle
徹底弄完了觀察了兩天發(fā)現(xiàn)一個(gè)問題：
DGMGRL> show configuration
Configuration - dg
Protection Mode: MaxPerformance
Members:
dbaas - Primary database
dbdg - Physical standby database
Warning: ORA-16632: instance being added to member profile
Fast-Start Failover: Disabled
Configuration Status:
WARNING (status updated 17 seconds ago)
DGMGRL> show database dbdg
Database - dbdg
Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 1 second ago)
Average Apply Rate: 1.08 MByte/s
Real Time Query: ON
Instance(s):
dbdg1
dbdg2 (apply instance)
-- dbdg3呢？？？？?。。?！
首先發(fā)現(xiàn)第一個(gè)問題，我新加節(jié)點(diǎn)的忘記配置靜態(tài)監(jiān)聽和tnsname了，搞完之后，configuration output能短暫恢復(fù)下，但是一會(huì)兒繼續(xù)恢復(fù)報(bào)錯(cuò)，第三個(gè)實(shí)例仍然沒有粗線。本來這個(gè)報(bào)錯(cuò)是會(huì)自動(dòng)處理的：
但是通過DG Diagnostic檢查后發(fā)現(xiàn)最后個(gè)節(jié)點(diǎn)無法正確的通過正確的tnsname連接到主庫去（絕對(duì)正確，可以用sqlplus連過去的?。。?，SR給了個(gè)操作建議：
DGMGRL> disable database dbdg;
DGMGRL> enable database dbdg;
DGMGRL> enable configuration
仍然不能在配置中正確添加新加的節(jié)點(diǎn)，只能用大招了：
DGMGRL> remove database dbdg;
DGMGRL> add database dbdg as connect identifier is dbdg;
DGMGRL> edit database dbdg set property logxptmode='sync';
然后一切正常，我懷疑這里和沒有在添加節(jié)點(diǎn)前配置好靜態(tài)監(jiān)聽和tnsname這步有關(guān)，屬實(shí)自己坑了自己一把。
3 自己挺自己
今天下午我這X8M那臺(tái)一體機(jī)告警，CPU占用率超過95%，也算是小刀剌屁股——開眼了（雖然祖上也因?yàn)镃BC遇到過），但是很久沒出現(xiàn)了，這機(jī)器CPU常年15%以下。
到EM一看，第二次小刀剌屁股，一體機(jī)內(nèi)兩個(gè)PDB，一個(gè)PDB用dblink去另一個(gè)dblink查數(shù)據(jù)，然后并發(fā)達(dá)到了150次/s（后面AWR查出來一小時(shí)跑了660W次，而對(duì)應(yīng)的接口調(diào)用記錄一小時(shí)只有幾萬次），這里明顯是業(yè)務(wù)側(cè)出現(xiàn)了異常，150次/s的并發(fā)，dblink兩端都在一體機(jī)上，即便語句單條執(zhí)行只有不到4微妙，但是雙倍壓力引給了CPU多倍的“快樂”。（其實(shí)前一天還處理了也是涉及這兩個(gè)PDB的一條SQL，是一個(gè)查詢4張表，3張表涉及dblink不在本地，而且這3張表一張?jiān)谝惑w機(jī)另外兩張?jiān)诹硪惶讛?shù)據(jù)庫，因?yàn)椴樵儣l件一點(diǎn)點(diǎn)的改動(dòng)就會(huì)造成查詢時(shí)長(zhǎng)非常大的變化，最后把另一套庫的兩張表都弄到一體機(jī)搞定的），后面重啟了對(duì)應(yīng)應(yīng)用正常了。
其實(shí)CPU高不高都沒啥，主要是CPU那么高（超過了66%，具體見第二十四期），但是對(duì)所有業(yè)務(wù)（十多個(gè)PDB）都沒造成啥影響，響應(yīng)速度依舊飛快，毫無感知，甚至是除了CPU比較高，這兩個(gè)PDB對(duì)應(yīng)的業(yè)務(wù)都沒啥感知。這當(dāng)然是resource manager的功勞?。ㄔ斠姷谒钠?，算上古文章了），雖然這兩個(gè)PDB都是share 2，CPU max 40%。資源管理在這個(gè)時(shí)候就是根據(jù)份額確保了各個(gè)PDB運(yùn)行所需要的CPU資源。
這里算一下，平時(shí)整體CPU不超過15%，到95%之間有80個(gè)點(diǎn)，那么CPU整體突破95%時(shí)這兩個(gè)PDB以外用的其實(shí)很少（可以算不超過15%），那么算下來這兩個(gè)PDB各占用了40%（雖然，資源隔離其實(shí)沒那么簡(jiǎn)單）。所以沒有影響到其他業(yè)務(wù)，resource manager還是起到了CPU隔離的作用，當(dāng)然整體常規(guī)負(fù)載低也是重要原因，要不這兩個(gè)PDB的性能分配肯定會(huì)被擠壓。
所以預(yù)先做好了配置，還是一定程度上避免了出現(xiàn)更大范圍的問題，給自己點(diǎn)個(gè)贊！
4 自己懵自己
首先說明一點(diǎn)，本節(jié)內(nèi)容僅限運(yùn)營商環(huán)境，僅是本人觀點(diǎn)。
上周不是國產(chǎn)數(shù)據(jù)溝通么，其實(shí)很多廠商都說過一句話或者表達(dá)一種態(tài)度，以前都在B域發(fā)力，O域不是太上心。之前一直覺得B域有錢，O域沒錢，還有就是B域整體技術(shù)實(shí)力是普遍強(qiáng)于O域的。但是今天和客戶討論這事，被自己一句話點(diǎn)了一下：B域的業(yè)務(wù)其實(shí)很簡(jiǎn)單，比如BOSS計(jì)費(fèi)，主要是高并發(fā)相對(duì)單一業(yè)務(wù)邏輯應(yīng)用場(chǎng)景（插改為主），而且很多情況會(huì)通過其他方式匯聚結(jié)果或者結(jié)果只是根據(jù)請(qǐng)求反饋，很多時(shí)候的結(jié)果及時(shí)性有些場(chǎng)景反而沒有O域那么明顯（記錄的實(shí)時(shí)性還是比較極端的哈）。而O域的很多業(yè)務(wù)都是流程類的，業(yè)務(wù)邏輯比較復(fù)雜，涉及的語句會(huì)更復(fù)雜，還可能會(huì)有大量的存儲(chǔ)過程和觸發(fā)器，實(shí)時(shí)性要求反而更高。
而現(xiàn)在很多國產(chǎn)數(shù)據(jù)庫都在標(biāo)榜自己的tpmC能力，其實(shí)更多也也是應(yīng)對(duì)B域的應(yīng)用場(chǎng)景，也就是業(yè)務(wù)邏輯相對(duì)單一的高并發(fā)OLTP。那么之前不重視O域也似乎找到了一點(diǎn)原因了。為啥現(xiàn)在又來了呢，一方面是占坑，另一方面是近一年大家的HTAP能力還是有了長(zhǎng)足的進(jìn)步，可以應(yīng)對(duì)更加復(fù)雜的應(yīng)用場(chǎng)景了。所以后面O域這邊的數(shù)據(jù)庫選型可能會(huì)有不一樣的要求和側(cè)重點(diǎn)。文章來源：http://www.zghlxwxcb.cn/news/detail-426060.html
總結(jié)
最后說一句，這周某大佬攢了個(gè)項(xiàng)目“時(shí)序流式地理空間圖譜文檔關(guān)系向量流批一體自主可控智能自治AI向量全文檢索云原生可編程超融合分布式單機(jī)一體化serverless數(shù)據(jù)庫”，大家有沒有興趣投一下啊。
老規(guī)矩，知道寫了些啥。文章來源地址http://www.zghlxwxcb.cn/news/detail-426060.html
到了這里，關(guān)于數(shù)據(jù)庫管理-第七十期 自己？自己（20230425）的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
