--- layout: post title: "自管 Oracle on EC2：從部署到維運，每一步都比想像中重" image: https://fastly.picsum.photos/id/366/1200/630.jpg?hmac=XylRtAp3wu3AH4jqKv5S8MnRvYjhcf3wqIflnoV7uOg description: "把 Oracle 架在 EC2 上看似只是延續地端維運方式，但實際上從磁碟切分、掛載、監控、備份、Patch 到事故處理，每一步都會把資料庫平台的責任重新交回團隊手上。" author: Mark_Mew categories: [AWS, EC2] tags: [Oracle, Database, AWS, EC2] keywords: [Oracle, Database, EC2, Self-hosted Database, CloudWatch, Systems Manager, EBS, DBA] lang: zh-TW date: 2026-07-17 --- 很多團隊把系統搬上 AWS 時，第一個直覺是：既然以前在 IDC 裡可以自己裝 Oracle，那在 EC2 上應該也差不多。 開一台機器、掛上磁碟、安裝 Oracle、設定備份，服務就可以開始連線。這個想法看起來很合理，尤其是公司本來就有 DBA，也有一套多年累積下來的維運習慣。 但真正開始做之後，才會發現「把 Oracle 放到 EC2」不是單純把地端主機換成雲端主機而已。 如果沒有用雲端思維重新設計維運方式，而是把地端 IDC 的做法原封不動搬上來，從部署到維運，每一步都會比想像中重。你不是只接手一台資料庫，而是接手一整套資料庫平台的生命週期。 ## 故事背景 許多公司內都有專職 DBA。對一位有經驗的 DBA 來說，開資料庫規格通常不是問題，因為他很清楚資料庫需要多少空間、哪些目錄要分開、哪些資料檔需要獨立掛載。 於是常見的需求可能長得像這樣： ```plaintext / 250 GB /boot 1 GB /tmp 25 GB /data01 250 GB /data02 250 GB /data03 250 GB /data04 250 GB /data05 250 GB /data06 250 GB swap 16 GB ``` 這種規劃在地端環境很常見。把 root、tmp、data、swap 拆開，目的是讓不同用途的 I/O、容量與管理邊界更清楚。站在 DBA 的角度，這不是亂開規格，而是為了降低資料庫未來維運時互相影響的風險。 但問題是，到了 EC2 上，每個切分都會變成你要自己處理的基礎建設細節。 以這個例子來看，EC2 採用 `r5.large`，每個月大約需要花費 109.44 美元；EBS 硬碟空間配置到 1792 GB，每個月大約花費 215.04 美元。 也就是說，從資料庫機器初始化開始，還沒真正上線營運，就已經要面對每個月接近一萬台幣的基礎成本。 這還只是帳單上的成本。真正更重的，是後面那些沒出現在 AWS Bill 裡的人力成本、維護成本與事故風險。 ## 前置步驟 ### 步驟 1：部署不是開機而已 有地端 IDC 經驗的人，一定對 Linux 指令不陌生。要初始化 swap、查磁碟、寫入 `/etc/fstab`，這些操作都不算困難。 初始化 swap： ```bash sudo mkswap /dev/ sudo swapon /dev/ ``` 查詢 mount 在主機上的 disk id： ```bash lsblk ``` 將查到的 disk id 寫入 `/etc/fstab`： ```bash sudo vi /etc/fstab ``` 如果只做一次，這些指令看起來還好。但資料庫不是一般應用伺服器，資料磁碟通常不能隨便掛錯，也不能靠「大概是這顆」來判斷。 當 `/data01` 到 `/data06` 都是獨立磁碟時，你必須確認每一顆 EBS Volume 對應到正確的掛載點，還要確認重開機後能正常掛載，權限也要符合 Oracle 的需求。 只要其中一個環節失誤，就可能發生： - 重開機後資料目錄沒有掛起來。 - 掛載點順序錯誤，資料被寫到不該寫的位置。 - 檔案系統、權限或 owner 設錯，導致 Oracle 啟動失敗。 - 磁碟空間看似足夠，但實際可用目錄不是預期中的那個。 這些問題在正式環境很麻煩，因為每一次修正都牽涉停機窗口、資料一致性與回復計畫。 ### 步驟 2：成本不是只有 EC2 和 EBS 很多人在比較 EC2 自架 Oracle 和 Managed Database 時，會先看每個月的主機費用。 這樣比較沒有錯，但不完整。 EC2 上的 Oracle 至少還要把這些事情算進去： - EBS 容量、IOPS 與 Throughput 規劃。 - Snapshot、備份保存與跨區備援。 - OS Patch 與 Oracle Patch。 - 監控 Agent 安裝與維護。 - Log 收集、告警與通知。 - 還原演練與事故文件。 - 權限控管、金鑰、連線安全與稽核。 這些都是工作，而且通常不是一次性工作。 資料庫會成長，系統流量會變，安全修補會持續發生，備份策略也會因為合規或業務要求而調整。只要你選擇自管，這些責任就會一直留在團隊身上。 ### 步驟 3：監控要自己接起來 在 RDS 上，很多資料庫指標可以直接透過 CloudWatch 看到。但如果 Oracle 是裝在 EC2 裡，你要自己把主機層、磁碟層、資料庫層的監控接起來。 最基本的做法，是安裝 CloudWatch Agent 和 Systems Manager Agent，並且確認 EC2 Instance Profile Role 有對應權限，可以把蒐集到的監控資訊送到 CloudWatch。 這裡又會出現幾個實務問題： - CloudWatch Agent 的設定檔誰維護？ - 要收集哪些 mount point 的磁碟使用率？ - Memory、swap、disk I/O、process 是否都要納入？ - Oracle listener、tablespace、archive log 是否有額外監控？ - Agent 壞掉時，有沒有告警？ - 新增磁碟或調整掛載點時，監控設定會不會同步更新？ 如果監控只做到 EC2 CPU，那其實離資料庫可觀測性還有很大一段距離。 Oracle 真正會讓人半夜醒來的問題，往往不是 CPU 高而已，而是 archive log 滿了、tablespace 不夠、I/O latency 飆高、連線數異常、備份沒有成功，或某個批次作業把資源吃光。 這些都需要額外設計。 ### 步驟 4：安裝資料庫也不是下一步下一步 如果使用的是 Red Hat Enterprise Linux，對有經驗的 DBA 或系統管理者來說，安裝套件前先確認可信任的 source、驗證 GPG key、改用官方 repo，都是很自然的事情。 但到了 EC2 上，事情又多了一層。 專業的 DBA 不一定會信任 AMI 預設帶進來的 source，也可能要求改指向官方 repo，或依照公司資安標準使用內部核准過的套件來源。這些要求本身都合理，但也代表安裝 Oracle 前，還要先處理作業系統層級的套件來源、相依套件、安裝權限與安全驗證。 如果過去習慣仰賴圖形化介面安裝，到了需要全指令操作的環境，就可能卡在很前面的步驟。更麻煩的是，這些問題通常不是 Oracle 本身壞掉，而是 OS、套件、權限與安裝流程沒有先對齊。 ## 災難開始 做到這裡會發現，資料庫的資料甚至還沒有倒入，前置作業就已經開始消耗大量時間。 但這些都只是剛開始。 真正麻煩的是，當資料庫開始被系統使用後，地端習慣和雲端環境之間的落差會一個一個浮出來。 ### 災難 1：時間不一致 有一次使用者反應資料庫時間不一致，DBA 的直覺做法是直接修改 OS 時間： ```bash sudo timedatectl set-time "2026-07-17 10:33:00" ``` 這個動作在單機環境看起來很直覺，但在 AWS 上很容易造成連鎖反應。 OS 時間被手動改掉之後，CloudWatch 會判定指標時間不正確，導致監控資料無法正常寫入。從表面上看，是 CloudWatch 沒有資料；實際追下去，才發現根本原因是主機時間被人手動調整過。 這類問題最麻煩的地方，是一開始很難判斷到底是 Agent 壞了、IAM 權限錯了、網路不通，還是時間本身出了問題。等到 DBA、維運與雲端團隊來回確認幾次後，才會發現問題其實是操作習慣不一致。 比較完整的做法，不是直接改系統時間，而是： - 讓主機透過 NTP 或 chrony 同步標準時間。 - 確認 OS timezone 是否設定為系統需要的時區，例如 `Asia/Taipei`。 - 資料庫、應用程式與報表系統要先約定時間欄位使用 UTC 還是本地時間。 - 監控系統要避免因為主機時間漂移而產生資料斷層。 ```bash sudo timedatectl set-timezone "Asia/Taipei" ``` 時間問題看起來小，但一旦牽涉資料庫、監控、稽核與報表，就會變成跨團隊問題。 ### 災難 2：備份不是有 Snapshot 就好 EC2 自架 Oracle 時，很多人會直覺想到 EBS Snapshot。 Snapshot 很有用，但它不是完整的資料庫備份策略。尤其是 Oracle 這類資料庫，必須考慮資料一致性、archive log、還原時間與復原點。 更麻煩的是，這台機器的 root disk 也不是乾淨的原始狀態。因為 `/etc/fstab` 裡已經針對多顆資料碟做了很多客製設定，如果直接把 root 還原起來，可能會因為裡面寫死了舊磁碟的 UUID，導致新還原的 EC2 開機失敗或掛載異常。 這時候還原流程就不再是「從 Snapshot 建一台機器」這麼簡單，而是可能變成： 1. 先從 Snapshot 還原 root volume。 2. 把還原出來的 root volume 掛到另一台可用的 EC2 上。 3. 修改或暫時註解 `/etc/fstab` 裡和舊磁碟 UUID 相關的設定。 4. 再把 root volume 掛回原本要啟動的 EC2。 5. 逐一還原 `/data01` 到 `/data06` 的資料碟。 6. 確認每一顆資料碟都掛回正確的 mount point。 別忘了，`/data01` 到 `/data06` 容量都一樣大。當每顆磁碟看起來都很像時，還原時就必須更小心辨識 Volume ID、UUID、檔案系統標籤與實際掛載點。 一旦掛錯，不只是服務起不來，還可能讓資料被寫到錯誤目錄，後續清理會更痛苦。 一個能上正式環境的備份策略，至少要回答幾個問題： - 備份多久做一次？ - 能不能還原到指定時間點？ - 備份失敗時誰會收到通知？ - 備份保存多久？ - 備份是否要跨帳號或跨區保存？ - 還原流程有沒有實際演練過？ - 還原後應用程式要怎麼切換？ 最可怕的不是沒有備份，而是大家以為有備份，直到事故發生才發現備份不能用、還原步驟沒有人熟、或是復原時間遠超過系統能接受的範圍。 自架 Oracle 當然可以做得很好，但它需要成熟的 DBA 流程，也需要團隊願意長期維護這套流程。 ### 災難 3：Patch 和維護窗口會一直存在 資料庫不是裝好之後就結束。 EC2 要 Patch，Linux 套件要更新，安全漏洞要追，Oracle 本身也有版本與安全更新要處理。每一次 Patch 都會牽涉風險評估： - 要不要停機？ - 停多久？ - Patch 前要不要做備份？ - 更新失敗要怎麼 rollback？ - 應用程式和 Driver 是否相容？ - 非正式環境有沒有先測過？ 如果團隊裡有成熟 DBA 與 SRE，這些問題都能被流程化。但如果這台 Oracle 只是某個系統附帶的一台資料庫，事情往往會變成「能不動就不動」。 結果就是系統跑了很久，卻沒有人敢升級，也沒有人清楚一旦需要維護時會影響什麼。 ## 真正的問題：你是在自建一個資料庫平台 把 Oracle 架在 EC2 上，不是錯。 有些情境確實需要這樣做，例如： - 需要特定 Oracle 版本或功能。 - 授權模式不適合 Managed Service。 - 有特殊 OS、Agent 或檔案系統需求。 - 公司內部已有成熟 DBA 團隊與既有標準流程。 - 需要高度客製化的備份、複寫或維運架構。 但如果只是因為「以前在 IDC 都這樣做」，那就要小心了。 EC2 只是提供運算資源，並不會替你承擔資料庫平台的責任。磁碟怎麼規劃、備份怎麼驗證、監控怎麼補齊、Patch 怎麼安排、事故怎麼還原，這些問題最後都會回到團隊身上。 這也是為什麼自管 Oracle on EC2 會比想像中重。 你以為自己只是架了一台資料庫，但實際上，你是在建立一套需要 24 小時負責的資料庫維運平台。 ## 結論 為什麼連有 20 年經驗的專業 DBA，都可能在 Oracle on EC2 上維護得很吃力？ 問題不一定是雲端比較難，也不一定是地端和雲端有多大的技術鴻溝。 真正的問題是，有些人把「20 年經驗」理解成「同一套做法用了 20 年」。只要環境變了、責任邊界變了、工具鏈變了，過去很熟的操作就不一定還是正確答案。 雲端不會因為一個人資歷夠深，就自動配合他的習慣運作。你手動改 OS 時間，CloudWatch 一樣會收不到資料；你在 `/etc/fstab` 寫死 UUID，Snapshot 還原時一樣可能開不了機；你只相信自己熟悉的安裝流程，遇到全指令、權限、repo、key 驗證時，一樣會卡在資料都還沒倒入之前。 這不是經驗沒有價值，而是經驗如果沒有更新，就很容易變成另一種技術債。 就像不能拿 20 年 MySQL 維運經驗，直接說自己一定能管理好 SQL Server 或 Oracle；也不能拿 20 年 IDC 維運經驗，直接說自己一定能管理好雲端上的資料庫平台。專業不只是知道以前怎麼做，還要知道現在為什麼不能再那樣做。 如果團隊有足夠的 DBA 能力、明確的維運流程，以及非自架不可的技術或商業理由，那麼 Oracle on EC2 當然可以是一個選項。 但如果團隊期待的是「上雲之後維運變簡單」，卻只是把地端做法搬到 EC2，最後只會得到一台看起來在雲端、實際上還停留在舊維運思維裡的資料庫。 雲端真正的價值，不是讓我們用比較新的方式開 VM，而是重新思考哪些責任應該自己扛，哪些責任可以交給 Managed Service。 自管 Oracle on EC2 最大的代價，不一定是每個月帳單上的 EC2 與 EBS。 更大的代價，是你必須長期為部署、監控、備份、Patch、還原與事故處理負責。