自管 Oracle on EC2：從部署到維運，每一步都比想像中重

很多團隊把系統搬上 AWS 時，第一個直覺是：既然以前在 IDC 裡可以自己裝 Oracle，那在 EC2 上應該也差不多。

開一台機器、掛上磁碟、安裝 Oracle、設定備份，服務就可以開始連線。這個想法看起來很合理，尤其是公司本來就有 DBA，也有一套多年累積下來的維運習慣。

但真正開始做之後，才會發現「把 Oracle 放到 EC2」不是單純把地端主機換成雲端主機而已。

如果沒有用雲端思維重新設計維運方式，而是把地端 IDC 的做法原封不動搬上來，從部署到維運，每一步都會比想像中重。你不是只接手一台資料庫，而是接手一整套資料庫平台的生命週期。

故事背景

許多公司內都有專職 DBA。對一位有經驗的 DBA 來說，開資料庫規格通常不是問題，因為他很清楚資料庫需要多少空間、哪些目錄要分開、哪些資料檔需要獨立掛載。

於是常見的需求可能長得像這樣：

/        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：

sudo mkswap /dev/<swap-device>
sudo swapon /dev/<swap-device>

查詢 mount 在主機上的 disk id：

lsblk

將查到的 disk id 寫入 /etc/fstab：

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 時間：

sudo timedatectl set-time "2026-07-17 10:33:00"

這個動作在單機環境看起來很直覺，但在 AWS 上很容易造成連鎖反應。

OS 時間被手動改掉之後，CloudWatch 會判定指標時間不正確，導致監控資料無法正常寫入。從表面上看，是 CloudWatch 沒有資料；實際追下去，才發現根本原因是主機時間被人手動調整過。

這類問題最麻煩的地方，是一開始很難判斷到底是 Agent 壞了、IAM 權限錯了、網路不通，還是時間本身出了問題。等到 DBA、維運與雲端團隊來回確認幾次後，才會發現問題其實是操作習慣不一致。

比較完整的做法，不是直接改系統時間，而是：

• 讓主機透過 NTP 或 chrony 同步標準時間。
• 確認 OS timezone 是否設定為系統需要的時區，例如 Asia/Taipei。
• 資料庫、應用程式與報表系統要先約定時間欄位使用 UTC 還是本地時間。
• 監控系統要避免因為主機時間漂移而產生資料斷層。

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、還原與事故處理負責。