簡介這份《Oracle云基礎(chǔ)架構(gòu)平臺解決方案》PDF面向售前技術(shù)人員、培訓(xùn)人員、合作伙伴及對Oracle云計算感興趣的讀者系統(tǒng)梳理了Oracle云基礎(chǔ)架構(gòu)的整體架構(gòu)與落地思路可幫助讀者理解企業(yè)構(gòu)建私有云、公有云或混合云環(huán)境時的關(guān)鍵設(shè)計要點。資源包內(nèi)僅含1個PDF文件大小約3.72MB內(nèi)容涵蓋計算、存儲、網(wǎng)絡(luò)、云安全、運營子系統(tǒng)、應(yīng)用云子系統(tǒng)、軟硬件配置清單、API與集成、合作伙伴關(guān)系及售后服務(wù)支持等模塊并附有版本修訂記錄與閱讀對象說明便于按章節(jié)查閱。目前已有99人學(xué)習(xí)下載。讀者可從中獲取云平臺分層架構(gòu)的完整描述、各子系統(tǒng)職責劃分、軟硬件選型參考以及跨云集成與運維自動化的基本思路適合作為方案規(guī)劃與架構(gòu)學(xué)習(xí)的參考資料。1. Oracle 云基礎(chǔ)架構(gòu)平臺解決方案從一臺數(shù)據(jù)庫到一套可交付的云底座很多團隊第一次接觸「Oracle 云基礎(chǔ)架構(gòu)平臺解決方案」這個詞是在一份幾十頁的 PDF 里——里面畫滿了區(qū)域、可用域、虛擬云網(wǎng)絡(luò)、塊存儲、負載均衡的架構(gòu)圖看完覺得都對合上文檔卻不知道明天該敲哪條命令。我當年也是這樣把方案文檔當科普讀物翻了三遍直到真正要在一周內(nèi)把一套 Oracle 數(shù)據(jù)庫遷到云上才發(fā)現(xiàn)文檔里沒寫的東西才是要命的網(wǎng)絡(luò)怎么切、存儲怎么選、監(jiān)聽怎么配、備份怎么驗證。這篇筆記不講空泛的架構(gòu)愿景只講一件事如果你手上有一份 Oracle 云基礎(chǔ)架構(gòu)平臺解決方案或者你正準備自己搭一套從零到能跑業(yè)務(wù)中間那些必須落地的步驟、參數(shù)和坑我按自己踩過的順序講一遍。適合兩類人一類是要把本地 Oracle 數(shù)據(jù)庫往云上搬的 DBA 和運維另一類是需要在云上從零規(guī)劃一套 Oracle 基礎(chǔ)架構(gòu)的架構(gòu)師。新手能照著命令走熟手能直接跳到參數(shù)和邊界那幾節(jié)。2. 先想清楚Oracle 云基礎(chǔ)架構(gòu)到底由哪幾層拼起來2.1 計算、存儲、網(wǎng)絡(luò)三件套的對應(yīng)關(guān)系Oracle 云基礎(chǔ)架構(gòu)OCI的底座說穿了就是三樣?xùn)|西計算實例、塊存儲、虛擬云網(wǎng)絡(luò)。方案文檔里那些花哨的名字落到操作層面就是這三樣在組合。計算實例對應(yīng)你原來機房里的物理機或虛擬機塊存儲對應(yīng)你掛在服務(wù)器上的盤虛擬云網(wǎng)絡(luò)對應(yīng)你機房里的交換機和防火墻策略。理解這個對應(yīng)關(guān)系很重要因為遷移時你腦子里要做的映射是原來數(shù)據(jù)庫跑在哪臺機器上、數(shù)據(jù)放在哪個盤、應(yīng)用怎么連過來。這三件事想清楚了云上的架構(gòu)自然就出來了。我一般會先畫一張表把本地的機器、磁盤、網(wǎng)段列出來再逐個映射到云上的資源類型映射不上的地方就是后面要重點驗證的風險點。本地資源云上對應(yīng)關(guān)鍵差異物理服務(wù)器計算實例靈活配置規(guī)格可在線調(diào)整但調(diào)整需重啟本地磁盤 / SAN塊存儲卷性能按 VPU 計費需預(yù)估 IOPS交換機 / 防火墻虛擬云網(wǎng)絡(luò) 安全列表規(guī)則默認拒絕需顯式放行負載均衡設(shè)備負載均衡器后端集健康檢查要單獨配這張表不是讓你照抄而是讓你在動手前把「哪些是等價替換、哪些是行為差異」分清楚。等價替換的部分可以放心搬行為差異的部分必須實測。2.2 區(qū)域與可用域容災(zāi)不是勾選項是網(wǎng)絡(luò)設(shè)計題方案里一定會提區(qū)域和可用域很多人把它當成容災(zāi)開關(guān)勾上就以為高可用做完了。實際上可用域的選擇直接決定你的網(wǎng)絡(luò)怎么劃、存儲怎么放、延遲是多少。同一個區(qū)域內(nèi)的不同可用域之間延遲通常在個位數(shù)毫秒跨區(qū)域就是幾十毫秒起步這個差距對數(shù)據(jù)庫主備同步是致命的。我的做法是主庫和備庫放在同一區(qū)域的不同可用域應(yīng)用服務(wù)器跟主庫放同一可用域跨區(qū)域只做備份歸檔不做實時同步。這樣既拿到了可用域級別的容災(zāi)又不會讓同步延遲拖垮業(yè)務(wù)。方案文檔里如果只寫了「建議跨可用域部署」而沒寫延遲數(shù)據(jù)那這段就是給你留的作業(yè)得自己測。2.3 從方案文檔到可執(zhí)行清單的拆解方法拿到一份解決方案 PDF不要從頭讀到尾。我的習(xí)慣是先翻到架構(gòu)圖那一頁把圖上的每個方框抄下來變成一個資源清單然后翻到參數(shù)配置章節(jié)把每個方框?qū)?yīng)的規(guī)格、數(shù)量、網(wǎng)段填進去最后翻到實施步驟對照清單看有沒有遺漏。拆完之后你會得到一張類似這樣的清單幾個計算實例、每個實例什么規(guī)格、掛幾塊盤、每塊盤多大、在哪個子網(wǎng)、開放哪些端口、備份策略是什么。這張清單才是你真正要執(zhí)行的東西PDF 本身只是參考。清單里任何一項寫不出具體數(shù)字就說明方案在這一塊是模糊的需要你自己補決策。3. 把 Oracle 數(shù)據(jù)庫搬上云實例、存儲與網(wǎng)絡(luò)的最小落地路徑3.1 計算實例規(guī)格怎么選才不浪費也不翻車選規(guī)格這件事新手最容易犯的錯是照著本地服務(wù)器的配置往上套。本地是 16 核 64G云上也買個差不多的結(jié)果發(fā)現(xiàn)云上的核和本地的核不是一回事性能對不上。Oracle 數(shù)據(jù)庫對 CPU 和內(nèi)存的比例很敏感OLTP 場景一般內(nèi)存是 CPU 核數(shù)的 4 到 8 倍比較穩(wěn)OLAP 場景內(nèi)存可以再高一些。我一般會先按現(xiàn)有數(shù)據(jù)庫的 AWR 報告估算看 DB CPU 和 DB Time 的比例看每秒邏輯讀再折算到云上的規(guī)格。如果拿不到 AWR就按經(jīng)驗值起步然后壓測調(diào)整。起步配置寧可小一點云上擴容比縮容容易而且擴容只需要重啟不會丟數(shù)據(jù)。# 查看當前數(shù)據(jù)庫的 CPU 和內(nèi)存使用基線在源庫執(zhí)行 sqlplus / as sysdba EOF -- 查看實例啟動以來的 CPU 時間 SELECT name, value FROM v\$sysstat WHERE name IN (CPU used by this session, parse time cpu); -- 查看 SGA 和 PGA 配置 SHOW PARAMETER sga_target; SHOW PARAMETER pga_aggregate_target; -- 查看邏輯讀用于估算 IOPS 需求 SELECT name, value FROM v\$sysstat WHERE name session logical reads; EOF這段腳本的作用是拿到源庫的資源基線。CPU used by this session是累計 CPU 消耗配合實例啟動時間能算出平均 CPU 使用率session logical reads是邏輯讀總量除以運行秒數(shù)就是每秒邏輯讀再乘以塊大小通常 8K就是每秒 IO 量級用來反推塊存儲的 VPU 需求。參數(shù)上sga_target和pga_aggregate_target決定了內(nèi)存規(guī)格的下限云上實例內(nèi)存不能低于這兩個值之和再加操作系統(tǒng)開銷。3.2 塊存儲的 VPU 與 IOPS別等業(yè)務(wù)卡了才回頭加盤塊存儲是云上最容易低估的一塊。本地磁盤你買回來性能是固定的云上塊存儲的性能跟容量和 VPU 掛鉤選小了業(yè)務(wù)一壓就卡。Oracle 數(shù)據(jù)庫的 redo 日志對寫延遲極其敏感數(shù)據(jù)文件對吞吐敏感這兩類盤要分開考慮。我的做法是redo 日志單獨掛一塊盤選高 VPU 低容量數(shù)據(jù)文件掛一塊大容量盤VPU 按每秒邏輯讀折算歸檔和備份再掛一塊普通盤。三塊盤分開既方便調(diào)優(yōu)也方便出問題時定位是哪一類 IO 拖后腿。# 在云主機上確認塊存儲掛載和 IO 調(diào)度器 lsblk -o NAME,SIZE,TYPE,MOUNTPOINT # 查看每塊盤的調(diào)度器數(shù)據(jù)庫盤建議用 none 或 mq-deadline cat /sys/block/sdb/queue/scheduler # 臨時調(diào)整調(diào)度器重啟失效需寫進 udev 規(guī)則 echo mq-deadline /sys/block/sdb/queue/scheduler # 用 fio 做一次寫延遲基線測試注意不要在生產(chǎn)盤上跑 fio --namerandwrite --ioenginelibaio --iodepth32 --rwrandwrite \ --bs8k --direct1 --size1G --runtime60 --filename/data/testfilelsblk確認盤掛上了沒有scheduler決定 IO 請求怎么排隊數(shù)據(jù)庫盤用mq-deadline或none比默認的cfq更穩(wěn)。fio那段是寫延遲基線重點看lat (usec)那一行的 p99 值如果 p99 超過 1msredo 日志放這塊盤上就要謹慎。注意--filename指向測試文件別指向真實數(shù)據(jù)文件跑之前確認路徑。3.3 虛擬云網(wǎng)絡(luò)與安全列表監(jiān)聽器起不來的頭號原因網(wǎng)絡(luò)這塊方案文檔通常畫得很清楚但落地時最?？ㄔ诎踩斜砩?。Oracle 監(jiān)聽默認走 1521 端口云上的安全列表默認拒絕所有入站你不顯式放行監(jiān)聽起得來但連不上。這個坑我踩過不止一次現(xiàn)象是lsnrctl status顯示正?？蛻舳司褪荗RA-12518: 監(jiān)聽程序無法分發(fā)。排查順序是先在云主機上tnsping自己通了說明監(jiān)聽沒問題再從客戶端tnsping不通就是網(wǎng)絡(luò)或安全列表最后看安全列表的入站規(guī)則有沒有放行 1521 和客戶端所在網(wǎng)段。# 在數(shù)據(jù)庫主機上確認監(jiān)聽狀態(tài)和端口 lsnrctl status netstat -tlnp | grep 1521 # 從客戶端測試連通性 tnsping 數(shù)據(jù)庫主機IP:1521/服務(wù)名 # 如果超時檢查安全列表入站規(guī)則是否放行源網(wǎng)段到 1521lsnrctl status看監(jiān)聽是否 READYnetstat確認 1521 在監(jiān)聽。tnsping是最直接的連通性測試超時基本就是網(wǎng)絡(luò)層被攔了。安全列表規(guī)則要寫清楚源 CIDR不要圖省事寫0.0.0.0/0數(shù)據(jù)庫端口暴露到公網(wǎng)是等保檢查的重點項方案里如果沒提這條實施時一定要補上。4. 上線前必須過的驗證關(guān)備份、恢復(fù)與性能基線4.1 備份策略能恢復(fù)才算備份不能恢復(fù)只是占地方云上的備份比本地方便但方便不等于可靠。我見過太多團隊開了自動備份就以為萬事大吉真出事的時候發(fā)現(xiàn)備份文件在恢復(fù)腳本跑不通。備份策略要回答三個問題備份頻率、保留周期、恢復(fù)演練頻率。前兩個方案文檔里一般有第三個通常沒人寫。我的習(xí)慣是上線前做一次完整恢復(fù)演練從備份里恢復(fù)一個實例跑一遍應(yīng)用連接測試確認數(shù)據(jù)一致。演練不通過備份策略就不算完成。這一步花半天時間能省掉出事時幾天的救火。# 用 RMAN 做一次全庫備份到云塊存儲 rman target / EOF CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; -- 校驗備份集完整性 VALIDATE BACKUPSET ALL; EOFRETENTION POLICY決定保留窗口7 天是常見起步值按業(yè)務(wù)合規(guī)要求調(diào)整。BACKUP AS COMPRESSED BACKUPSET壓縮備份集省存儲但增加 CPU 開銷CPU 緊張的庫可以去掉壓縮。VALIDATE BACKUPSET是關(guān)鍵一步它校驗備份文件是否可讀、塊是否完整不做這步你永遠不知道備份是不是壞的。4.2 恢復(fù)演練把「應(yīng)該能恢復(fù)」變成「確實恢復(fù)過」恢復(fù)演練不是把備份還原回去就完事要驗證的是恢復(fù)出來的庫能不能被應(yīng)用正常使用。步驟是起一個臨時實例恢復(fù)數(shù)據(jù)文件和控制文件做一次不完全恢復(fù)或完全恢復(fù)然后讓應(yīng)用連上去跑核心查詢。# 在臨時實例上做恢復(fù)演練 rman target / EOF STARTUP NOMOUNT; RESTORE CONTROLFILE FROM 備份控制文件路徑; ALTER DATABASE MOUNT; RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS; EOF # 恢復(fù)后驗證數(shù)據(jù)一致性 sqlplus / as sysdba EOF SELECT COUNT(*) FROM 核心業(yè)務(wù)表; SELECT MAX(created_date) FROM 核心業(yè)務(wù)表; EOFRESTORE CONTROLFILE先恢復(fù)控制文件因為控制文件里記錄了數(shù)據(jù)文件的位置和備份信息。RECOVER DATABASE應(yīng)用歸檔日志到一致點。OPEN RESETLOGS打開數(shù)據(jù)庫這一步之后原備份鏈就斷了所以演練要在隔離環(huán)境做。最后兩條查詢是驗證數(shù)據(jù)到?jīng)]到預(yù)期時間點MAX(created_date)能看出恢復(fù)到了哪個時刻。4.3 性能基線上線前不測上線后就是玄學(xué)性能基線是很多人跳過的一步覺得業(yè)務(wù)還沒上測了也沒意義。實際上基線的作用是給你一個參照系業(yè)務(wù)上線后變慢了你能判斷是業(yè)務(wù)量漲了還是系統(tǒng)退化了。基線要測三類CPU 密集查詢、IO 密集查詢、并發(fā)連接。# 用 swingbench 或類似工具做并發(fā)基線測試 # 這里用簡單的并發(fā)查詢模擬 for i in $(seq 1 50); do sqlplus -s user/pass//主機:1521/服務(wù)名 EOF SELECT /* FULL(t) */ COUNT(*) FROM 大表 t; EXIT; EOF done wait # 測試期間在數(shù)據(jù)庫端觀察等待事件 sqlplus / as sysdba EOF SELECT event, total_waits, time_waited FROM v\$system_event WHERE wait_class ! Idle ORDER BY time_waited DESC FETCH FIRST 10 ROWS ONLY; EOF并發(fā)查詢模擬的是多用戶同時訪問的場景讓查詢后臺并行wait等全部結(jié)束。數(shù)據(jù)庫端的v$system_event看等待事件如果db file sequential read排前面說明 IO 是瓶頸latch: shared pool排前面說明共享池有爭用。基線數(shù)據(jù)記下來上線后對比差異超過 20% 就要查原因。5. 避坑與排查那些方案文檔不會寫的翻車現(xiàn)場5.1 監(jiān)聽服務(wù)無法啟動先看日志再看權(quán)限現(xiàn)象lsnrctl start卡住或報錯lsnrctl status顯示監(jiān)聽未啟動。原因通常是監(jiān)聽日志文件滿了或者權(quán)限不對。Oracle 監(jiān)聽日志默認在$ORACLE_HOME/network/log/下長期不清理會漲到幾個 G寫不進去就起不來。解決清理監(jiān)聽日志確認listener.ora和日志目錄的屬主是 oracle 用戶。# 查看監(jiān)聽日志大小 ls -lh $ORACLE_HOME/network/log/listener.log # 清理日志先備份再清空 cp $ORACLE_HOME/network/log/listener.log /tmp/listener.log.bak $ORACLE_HOME/network/log/listener.log # 確認權(quán)限 ls -l $ORACLE_HOME/network/log/5.2 ORA-12518 監(jiān)聽程序無法分發(fā)連接數(shù)打滿了現(xiàn)象客戶端報ORA-12518: 監(jiān)聽程序無法分發(fā)但監(jiān)聽狀態(tài)正常。原因是數(shù)據(jù)庫的processes或sessions參數(shù)達到上限新連接分不出去。解決查當前連接數(shù)調(diào)大processes和sessions重啟生效。-- 查看當前連接數(shù)和參數(shù)上限 SELECT COUNT(*) FROM v$session; SHOW PARAMETER processes; SHOW PARAMETER sessions; -- 調(diào)大參數(shù)需重啟 ALTER SYSTEM SET processes500 SCOPESPFILE; ALTER SYSTEM SET sessions555 SCOPESPFILE;5.3 12c 刪除不干凈導(dǎo)致重裝失敗注冊表和殘留文件現(xiàn)象卸載 Oracle 12c 后重裝報各種奇怪的錯誤比如端口被占、實例名沖突。原因是卸載沒清干凈注冊表項、環(huán)境變量、/etc/oratab、/etc/oraInst.loc都有殘留。解決手動清理這些位置重啟后再裝。# 清理殘留文件 rm -f /etc/oratab /etc/oraInst.loc rm -rf /u01/app/oracle /u01/app/oraInventory # 清理環(huán)境變量檢查 ~/.bash_profile 里的 ORACLE_HOME 等 grep -i oracle ~/.bash_profile # 確認沒有殘留進程 ps -ef | grep -i oracle | grep -v grep5.4 等保檢查項默認配置過不了現(xiàn)象等保測評時被指出數(shù)據(jù)庫存在弱口令、端口暴露、審計未開啟等問題。原因是默認安裝的配置不符合等保要求。解決改口令策略、限制監(jiān)聽端口訪問來源、開啟審計、關(guān)閉不必要的服務(wù)。-- 開啟數(shù)據(jù)庫審計 ALTER SYSTEM SET audit_trailDB,EXTENDED SCOPESPFILE; -- 查看當前口令策略 SELECT * FROM dba_profiles WHERE resource_name LIKE PASSWORD%; -- 修改口令有效期和復(fù)雜度 ALTER PROFILE DEFAULT LIMIT PASSWORD_LIFE_TIME 90; ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 5;5.5 跨可用域延遲導(dǎo)致主備同步慢先測再定架構(gòu)現(xiàn)象主備庫跨可用域部署后備庫延遲持續(xù)增長。原因是跨可用域的網(wǎng)絡(luò)延遲比預(yù)期高redo 傳輸跟不上。解決先測實際延遲如果超過 5ms考慮把備庫放到同可用域或者改用異步同步。# 測試兩臺主機之間的網(wǎng)絡(luò)延遲 ping -c 100 備庫IP | tail -1 # 用 iperf3 測帶寬 iperf3 -c 備庫IP -t 306. 進階技巧用腳本把重復(fù)的巡檢和驗證自動化做到這里一套 Oracle 云基礎(chǔ)架構(gòu)基本能跑了。但真正讓這套東西可持續(xù)的是把日常巡檢和上線前驗證自動化。我自己的習(xí)慣是寫一個巡檢腳本每天定時跑把關(guān)鍵指標落庫出問題的時候有歷史數(shù)據(jù)可查。#!/bin/bash # oracle_daily_check.sh - 每日巡檢腳本 LOG/var/log/oracle_check_$(date %Y%m%d).log { echo 巡檢時間: $(date) # 實例狀態(tài) sqlplus -s / as sysdba EOF SELECT instance_name, status FROM v\$instance; SELECT name, open_mode FROM v\$database; -- 表空間使用率 SELECT tablespace_name, ROUND(used_percent,2) FROM dba_tablespace_usage_metrics; -- 等待事件 TOP5 SELECT event, time_waited FROM v\$system_event WHERE wait_class ! Idle ORDER BY time_waited DESC FETCH FIRST 5 ROWS ONLY; -- 無效對象 SELECT COUNT(*) FROM dba_objects WHERE statusINVALID; EXIT; EOF # 監(jiān)聽狀態(tài) lsnrctl status | grep -E READY|BLOCKED # 磁盤使用率 df -h | grep -E /u01|/data } $LOG 21 # 保留最近 30 天日志 find /var/log -name oracle_check_*.log -mtime 30 -delete這個腳本把實例狀態(tài)、表空間、等待事件、無效對象、監(jiān)聽、磁盤六項串起來輸出到按日期命名的日志文件。dba_tablespace_usage_metrics直接給出使用率百分比比手算方便。FETCH FIRST 5 ROWS ONLY是 12c 以上語法11g 要換成ROWNUM 5。最后一行清理 30 天前的日志避免日志把盤占滿——這個坑我踩過巡檢腳本自己把盤寫滿了。腳本跑起來之后配合云上的監(jiān)控告警基本能做到問題早發(fā)現(xiàn)。但腳本不是萬能的它只能告訴你「哪里不對」不能告訴你「為什么不對」。真正出問題時還是要回到前面幾節(jié)的排查思路從現(xiàn)象倒推原因。我自己的教訓(xùn)是別等出事了才寫巡檢腳本也別指望一個腳本覆蓋所有場景。先跑起來再根據(jù)實際報警慢慢加檢查項比一開始就追求大而全要靠譜得多。希望幫到你。本文還有配套的精品資源點擊獲取