Oracle Database（甲骨文）

Each feature = what it is + why it's genuinely good + what happens at the edge.

1. RAC + Cache Fusion: a shared-disk active-active cluster Why it's real: multiple nodes share the same storage; blocks move directly between node memory (coordinated by GCS) without touching disk — this is the technology Oracle defined a category with. When a node fails, surviving nodes take over with applications barely noticing; it's also the only mature commercial shared-disk multi-writer solution. Edge truth: see Deep Dive 1 — interconnect jitter directly triggers node eviction; when hot-write blocks ping-pong between nodes, Cache Fusion turns from accelerator into amplifier; RAC protects against "node death", not "storage death" or "human error". Also: RAC is a paid option of EE; it was completely removed from SE2 starting with 19c.
2. PL/SQL and the Oracle dialect: a four-decade installed-base moat Why it's real: packages, triggers, DBMS_* system packages, analytic functions, hierarchical queries — the core business logic of global finance/telecom/government enterprises is written in these packages. Oracle's lock-in isn't a contract; it's code. Edge truth: see Deep Dive 6 — "de-O" (removing Oracle) is hard not because of data but because of hundreds of thousands of lines of PL/SQL; package-level session state, autonomous transactions, and DBMS_ package calls have no equivalents on target databases; rewriting is a line-by-line labor bill. The day you buy Oracle, the exit cost starts accruing interest.
3. Data Guard / MAA: the reference implementation of zero-data-loss DR Why it's real: physical standby + real-time redo apply, three protection modes; RPO=0 under maximum availability / maximum protection; FSFO (Fast-Start Failover) + Observer enables automatic failover. This is what defined the word "disaster recovery" in the database industry. Edge truth: see Deep Dive 2 — synchronous mode trades primary write latency for zero loss; async mode loses a few seconds of redo on failure; Active Data Guard (readable standby) is a separately charged option; the Observer itself is a single point that must be deployed independently. RPO=0 is the result of "correct configuration + network that holds up", not an out-of-the-box guarantee.
4. CBO optimizer: the most mature cost-based optimizer Why it's real: decades of optimizer engineering; plan quality for complex SQL (multi-table joins, subqueries, analytic functions) remains the industry benchmark; parallel execution, partition pruning, and materialized-view rewrite form a complete system. Edge truth: plan flips are an Oracle DBA's daily routine — stale statistics, bind-variable peeking, and histogram changes can all make the same SQL suddenly switch plans; SPM (SQL Plan Management) can pin plans, but that's "driving stick". The smarter the optimizer, the more plan troubleshooting depends on DBA skill.
5. Multitenant (PDB): multi-tenant consolidation in a single instance Why it's real: multiple PDBs under one CDB; patching/upgrading/backup done once per CDB; PDB hot-plug migration; ideal for "one database, many uses" consolidation with high resource utilization. Edge truth: since 19c the non-CDB architecture is no longer supported — you enter CDB whether you want it or not; the relationship between PDB count and Multitenant option licensing is per the current License Definitions (待验证, Oracle has changed its wording historically); PDB-level fault isolation is weaker than separate instances — a bad block / mistake in one CDB affects all PDBs.

Each = mechanism + behavior at the edge + selection implication + source.

Deep Dive 1 (performance/availability): RAC's Cache Fusion — the interconnect is the lifeline; on split-brain Oracle chooses to kill nodes to protect data

• Mechanism: blocks in each node's buffer cache are cataloged by GCS (Global Cache Service); when a node needs a block held by another node, the LMS process transfers it directly over the private interconnect (CR consistent-read transfer / Current block transfer), with 0.5–2ms latency, roughly 1/10 of disk (community-tested, 19c). CSS heartbeat + Voting Disk perform cluster membership arbitration.
• At the edge:
  • Interconnect jitter/packet loss/latency spikes → CSS heartbeat timeout → minority nodes get evicted, instances killed outright. What DBAs often see is ORA-29702, CRS-1609/1611, and then "the node is gone". This isn't a bug; it's design philosophy: data correctness over availability.
  • Hot-write blocks (sequences, hot index root blocks) bouncing between nodes drive gc buffer busy waits through the roof — Cache Fusion turns from "accelerator" into "amplifier". RAC scales "throughput", not "single-hotspot writes".
  • On split-brain, Voting Disk arbitrates; the loser gets isolated by I/O fencing — "killing the node" is Oracle's standard practice for split-brain, not negotiation.
  • Sharing the interconnect with the business network, mismatched MTU on the private network, and misconfigured NIC bonding are the three most common human causes of production split-brain/false eviction.
• Selection implication: RAC requires a dedicated private interconnect (10GbE minimum), shared storage, and an odd number of voting disks; POC must stress two scenarios — "cross-node hot writes" and "private-network jitter"; only choose RAC if you accept the philosophy that "nodes may be killed to protect correctness".
• Sources: Oracle official RAC concepts docs (github.com/oracle/skills) — official docs; DBA community tests (Cache Fusion latency data, eviction cases) — community-tested; split-brain protection mechanism — community consensus.

Deep Dive 2 (replication & DR): what Data Guard's RPO is traded for — sync slows the primary, async drops trailing redo

• Mechanism: primary redo streams in real time to the standby for apply; three protection modes: maximum performance (async), maximum availability (sync, degrades to async to keep the primary writable when the standby is unavailable), maximum protection (sync, primary stops writing when the standby is unavailable). FSFO requires Data Guard Broker + an independent Observer process, with configurable thresholds (e.g., 10–15 seconds on low-latency single-instance networks).
• At the edge:
  • Under maximum protection, one standby network blip = primary writes blocked — the cost of DR is primary availability. Most production deployments choose maximum availability, which is essentially "sync normally, protect the primary at critical moments".
  • Under the default maximum performance (async) mode, a primary crash means the standby never received trailing redo — it's lost for good; RPO>0 is the norm.
  • After failover, the old primary's timeline diverges: with Flashback enabled, REINSTATE rolls it back to a standby in seconds; without it, you must rebuild — the unassuming "is Flashback on" setting decides whether post-disaster recovery is minutes or hours.
  • If FSFO's Observer sits in the same datacenter as primary and standby, a site-level failure takes out the observer along with the primary, and automatic failover never happens. Observer placement is an architecture question.
  • Active Data Guard (readable standby) is a separately charged option — the lovely idea of "no idle standby" costs extra.
• Selection implication: choosing a protection mode is a three-way RPO/RTO/primary-performance trade-off with no free lunch; DR drills must cover the full failover + reinstate chain, not just switchover; list Active Data Guard separately when getting quotes.
• Sources: Oracle official MAA docs (High Availability Overview, FSFO best practices) — official docs; DBA community practice (reinstate/re-create decisions) — community-tested.

Deep Dive 3 (cost/licensing): license metering and LMS audits — billed by "cores × factor", virtualization billed across the whole cluster, audit scripts scanning feature usage turn into invoices

• Mechanism: Processor metering = physical cores × Oracle Processor Core Factor Table coefficient (official table, coefficients by chip architecture); NUP metering requires EE minimum 25 NUP per processor (official License Definitions and Rules — official docs); with application-server multiplexing, billing is by actual end-user count, not connection-pool users; internet-facing apps that can't count users must use Processor metering (official Database Licensing docs — official docs).
• At the edge:
  • Each option billed separately: RAC, Partitioning, Advanced Security (TDE), Diagnostics Pack (AWR/ASH), Tuning Pack, Database Vault, etc., each an independent SKU. Using without buying = non-compliant. The classic trap: a DBA casually runs an AWR report and the Diagnostics Pack feature usage gets recorded.
  • LMS audits: Oracle collects feature usage with proprietary scripts; script output becomes the first draft of the audit report; historically audits were widely perceived as a "sales tool" (CCL survey: nearly 90% of respondents viewed the audit process negatively, 2014 survey, historical third-party data). Third-party observation in 2025: Oracle's strategy shifted to cloud, formal audits decreased, but "technical validation" continues and the scripts still run (third-party judgment, pending ongoing verification).
  • Virtualization partitioning policy: Oracle doesn't recognize soft partitioning like VMware — running Oracle on a vSphere cluster means licensing all physical hosts in the cluster/vCenter, not one VM's vCPU count. This is the main reason virtualized/cloud Oracle deployments explode in cost (third-party licensing analysis — community consensus).
  • Support fees: ~22%/year of the license net price, charged annually (third-party/community consensus figure); 19c supported through 2032 means paying support through 2032 — in a TCO model, support fees are the main course, not a side dish.
  • Metering-boundary checklist (confirm in writing when quoting): whether standby/DR nodes are billed (Data Guard physical standby licensing rules), test/dev environments, containers by request vs limit, VMware cluster scope, RAC node count, option list, ULA measurement method.
• Selection implication: Oracle's true cost = license + options + 22%/year × N years of support + compliance risk; "cheaper than xx" can only be relative to Oracle's own history, never cross-vendor; before production, build an Effective License Position (entitlements vs actual deployment reconciliation).
• Sources: Oracle official License Definitions and Rules, Processor Core Factor Table, Database Licensing docs — official docs; LMS audit practice — third-party analysis + community consensus; virtualization policy — third-party licensing analysis (Licenseware etc.), community consensus.

Deep Dive 4 (ops/upgrades): version fragmentation and patching — 20/22 never shipped, 23ai renamed to 26ai, 19c extended to 2032

• Mechanism: Oracle support has three stages: Premier (patches + new features) → Extended (paid patches) → Sustaining (no new patches). Official Lifetime Support Policy (effective 2026-05-01): 19c Premier through 2029-12-31, Extended through 2032-12-31; 26ai (LTS) Premier through 2031-12-31; 21c (innovation release) Premier through 2027-07-31, no Extended 官方文档.
• At the edge:
  • Oracle once announced versions 20/22 (2019 wording) that never shipped — version-number promises can't be taken at face value (third-party reports).
  • 23ai shipped cloud-first with repeated delays (H1 2024 → H2 → 2025), on-prem GA dragging past mid-2025; in 2025-10 it was directly renamed Oracle AI Database 26ai (internally still 23.26.x; applying RU 23.26 counts as "upgrading"). Version confusion is a real operational cost: docs, drivers, and third-party tools' support matrices for "26ai" must be checked item by item (client interoperability matrix: 18c and older clients can't connect to 26ai).
  • 19c's repeated extensions (Premier pushed from 2024 to 2029) say one thing: production mainstream is 19c, and huge numbers of customers never moved. The cost of staying on 19c is paid Extended Support + the feature gap with newer versions.
  • Since 19c, SE2 no longer supports RAC (the installer blocks it outright); SE2 RAC users upgrading to 19c are forced to move to EE or change architecture; since 19c non-CDB is no longer supported.
  • Patch (RU/RUR) regression risk is a perennial DBA-community topic: patches must go through full regression in test environments first — "latest patch" ≠ "most stable patch" 社区共识.
• Selection implication: plan new deployments directly on 26ai (Oracle's official position: fresh 23ai installs should target 26ai); existing 19c estates need an upgrade roadmap before 2029; SE2 users should confirm RAC/feature requirements before talking versions.
• Sources: Oracle Lifetime Support Policy (Technology Products, effective 2026-05-01) — official docs; 26ai release and rename — Oracle official announcements + DBA community (zeddba, dohdatabase); SE2 RAC removal — Oracle official notice (quoted via Miro Consulting); patch regression — community consensus.

Deep Dive 5 (ecosystem/strategy): cloud strategy — "moving OCI into competitors' datacenters", while the database remains Oracle's

• Mechanism: OCI has ~50 global regions; Database@Azure / @AWS / @Google Cloud physically deploy OCI's Exadata hardware inside hyperscaler datacenters, running Exadata Database Service / Autonomous Database with sub-millisecond app-side latency and no egress fees (Oracle official + third-party analysis — official/third-party docs); Autonomous Database focuses on self-management (automatic patching/tuning/scaling).
• At the edge:
  • The essence of multicloud: compute/AI can live on AWS/Azure/GCP, but the Exadata box holding the database is still Oracle hardware under Oracle control. The latency problem is solved; the lock-in problem isn't — it changed from "OCI lock-in" to "Oracle Database lock-in", in a different place.
  • Oracle's new releases are consistently cloud-first: 23ai GA'd on OCI first, on-prem more than a year later. Customers on the on-prem cadence always get new features a year later than cloud customers.
  • The boundary of Autonomous' "autonomy": automatic patching means patch timing isn't yours to choose; for core systems sensitive to change windows, that's a feature and a risk.
  • Running Oracle managed by cloud vendors on AWS/Azure/GCP: restricted features (no RAC on RDS, etc.), and mostly BYOL — "moving to cloud" ≠ "peace of mind"; it equals "paying the Oracle tax in a different way".
• Selection implication: multicloud solves "apps and data in the same datacenter", not "de-Oracle-ization"; cloud Oracle TCO must account for both "Oracle licensing" and "cloud resources"; sovereignty scenarios should look at Dedicated Region / sovereign cloud.
• Sources: Oracle official multicloud docs and IDC MarketScape report — official/third-party docs; Database@AWS partnership details — third-party reports; cloud-first release cadence — community consensus.

Deep Dive 6 (compatibility/migration): "de-O" is hard not because of data but because of code — PL/SQL is a line-by-line labor bill

• Mechanism: heterogeneous migration has two steps: schema/code conversion + data movement (full load + CDC). Per AWS's official migration assessment: the hard part is code, not data.
• At the edge (Oracle→PostgreSQL no-equivalent list; migration tools are best-effort only):
  • Packages: PG has no direct equivalent; package-level session state (e.g., pkg.g_price_cache) has nowhere to live; requires refactoring into schemas+functions or application-layer state.
  • CONNECT BY: rewrite as recursive CTEs; LEVEL, SYS_CONNECT_BY_PATH, NOCYCLE handled manually item by item.
  • ROWNUM: takes effect before ORDER BY; naively swapping in LIMIT returns different rows, not just a different order.
  • (+) outer joins: a LEFT JOIN with the wrong direction runs but returns wrong results — "it runs" is the most dangerous state in a migration.
  • Bitmap indexes: unsupported in PG; index strategy must be redone.
  • Optimizer hints: they're comments in PG, silently ignored; execution plans change outright without errors.
  • Empty string = NULL, SYSDATE semantics (doesn't advance within a statement), TIMESTAMP WITH LOCAL TIME ZONE: semantic-level differences that slip through if test cases don't cover them.
  • PRAGMA AUTONOMOUS_TRANSACTION, DBMS_* package calls: no automatic translation; manual, one by one.
  • Real AWS assessment case: a claims system with 78,000 lines of PL/SQL + 23 AQ queues achieved only 31% automatic conversion, with the conclusion "high investment, architecture redo"; while systems with little PL/SQL reached 78% (AWS official blog — official docs).
• Selection implication: the first step of a de-O assessment is code scanning (how many lines of PL/SQL, how many packages, how many CONNECT BY/ROWNUM/(+)), not data volume; systems with <50% auto-conversion should be budgeted as "rewrites"; parallel-run validation + rollback plans are mandatory; "de-O saves license fees" and "de-O costs labor fees" are two sides of the same coin.
• Sources: AWS official migration blog (SCT assessment cases) — official docs; open-source migration tool docs (credativ-pg-migrator, oracle-to-postgres migration lab's H-series checklist) — community-tested; HN user multi-year migration experience posts — community-tested.

The good deserves depth too. Each = why it's true + edges and limits.

1. "Never loses data" correctness reputation
   • Why it's true: four decades of redo + undo + Data Guard + RAC engineering; the default choice for financial core systems; RPO=0 genuinely achievable (when implemented per MAA).
   • Edges & limits: the reputation rests on "complete MAA implementation" — a bare single instance loses data and fears human error just the same; RPO=0 costs the latency tax of synchronous replication plus the Active Data Guard option fee. You're buying "capability ceiling", not "out-of-the-box".
   • Sources: community consensus; Oracle MAA docs 官方文档. Observed versions: 19c/26ai.
2. PL/SQL installed base: the home of business logic
   • Why it's true: decades of accumulated packages, stored procedures, and triggers; switching databases = rewriting business; Oracle is "the home of code", and that's the moat in migration assessments.
   • Edges & limits: the moat's flip side is lock-in — package-level state, DBMS_*, and autonomous transactions make exit costs billable by the line; the new generation of developers doesn't write PL/SQL; the talent pool is aging 社区共识.
   • Sources: community consensus; de-O migration cases (AWS official blog). Observed versions: all.
3. Complete toolchain: RMAN / Data Pump / EM
   • Why it's true: RMAN built in (incremental/block-level recovery), Data Pump high-speed import/export, EM centralized management — the DBA toolbox is complete out of the box.
   • Edges & limits: EM's AWR/ASH foundation is the Diagnostics Pack paid pack — "seeing" requires "being able to afford" first; RMAN advanced features (e.g., Block Change Tracking for fast incrementals) are restricted in SE2.
   • Sources: Oracle official docs 官方文档; AWS EE/SE2 comparison (third-party). Observed versions: 19c.
4. RAC / Data Guard HA reputation
   • Why it's true: second-level takeover on node failure, zero-loss switchover on site failure — the definer of "high availability" in the database industry.
   • Edges & limits: RAC and Active Data Guard are both EE paid options; RAC needs the trio of private network + shared storage + senior DBAs; Data Guard's zero loss trades primary latency. The reputation is the "fully-loaded" reputation.
   • Sources: Oracle MAA docs 官方文档; community consensus. Observed versions: 19c.
5. DBA talent supply and knowledge accumulation
   • Why it's true: the world's largest Oracle DBA population; four decades of docs, books, and community Q&A — any problem "has been hit by someone before".
   • Edges & limits: the talent pool is aging; the cloud-native generation of DBAs knows PG/MySQL better; and half of Oracle "knowledge" is "licensing compliance knowledge", not technical knowledge.
   • Sources: community consensus (editor's judgment). Observed versions: all.

• One-line positioning: The de facto standard of enterprise relational databases — you pay for correctness engineering, the PL/SQL installed base, and the MAA stack; the price is the industry's most complex licensing metering and the deepest lock-in. Oracle is a "tax", not a "tool".
• Who it's for:
  • Financial/telecom/government core systems where correctness comes first and RPO=0 is a hard requirement;
  • Teams carrying hundreds of thousands of lines of PL/SQL legacy where management has done the math that "rewrite cost > license cost";
  • Those needing the RAC/Data Guard MAA stack with senior DBA teams to run it;
  • Regulated industries requiring a commercial support owner and complete auditing;
  • Those already deeply tied to the Oracle stack (Exadata/ODA/applications) where migration costs exceed renewal costs.
• Who it's not for:
  • Startups/internet companies (extremely poor cost-performance; licensing complexity mismatched to scale);
  • Greenfield projects with no Oracle baggage (PG/MySQL are free and sufficient);
  • Budget-sensitive teams allergic to the word "audit";
  • Scenarios with explicit 信创 (xìnchuàng, IT innovation/localization) / de-O mandates;
  • Teams hoping "moving to cloud means peace of mind" (cloud Oracle is just paying the tax differently).
• Migration cost:
  • from_oracle (de-O): High. Data movement is the small part; PL/SQL code rewriting is the big part; automatic conversion rates depend on PL/SQL line counts (AWS case: 78% vs 31%); code scanning must come first, plus parallel-run validation and rollback plans.
  • from_mysql: Medium. Mainly application-layer rework; heavy reliance on MySQL-specific features raises conversion cost; plus one-time acceptance of the Oracle licensing system.
  • from_postgres: Medium-high. PG→Oracle is "going from free to paid" — beyond application rework, there's the financial hurdle of licensing and options; few go this route unless the business strongly depends on Oracle-exclusive capabilities.

• Versions & support: Oracle Lifetime Support Policy for Technology Products (effective 2026-05-01: 19c Premier through 2029-12-31 / Extended through 2032-12-31; 26ai Premier through 2031-12-31; 21c through 2027-07-31) — official docs; Oracle AI Database 26ai release announcement (2025-10-14, oracle.com) — official docs; on-prem GA 2026-01-27, internal version 23.26.x — DBA community (zeddba, dohdatabase)
• RAC/split-brain: Oracle official RAC concepts docs (github.com/oracle/skills) — official docs; Cache Fusion latency and eviction cases — DBA community tests; Voting Disk/I/O fencing — community consensus
• Data Guard: Oracle MAA docs (High Availability Overview, FSFO best-practices whitepaper) — official docs; switchover/failover/reinstate practice — DBA community tests (2026-09)
• Licensing: License Definitions and Rules, Processor Core Factor Table, Database Licensing docs — official docs; LMS audits — CCL historical survey + Medium 2025-10 third-party analysis; virtualization partitioning policy — third-party licensing analysis, community consensus; 22% support fee — third-party/community consensus figures
• TDE/option attribution: AWS official blog (RDS Custom for Oracle TDE series) — official docs; Oracle security docs — official docs
• Cloud strategy: Oracle multicloud research brief (Moor Insights & Strategy 2025-03), IDC MarketScape 2025 — third-party docs; Database@AWS partnership — third-party reports (2026-09)
• De-O: AWS official migration blog (SCT assessment: 78% vs 31% auto-conversion cases) — official docs; credativ-pg-migrator, oracle-to-postgres migration lab — community-tested; HN multi-year migration experience posts — community-tested
• Next review: track 26ai follow-up RUs (23.26.3+) and third-party toolchain adaptation; track LMS audit policy changes; re-verify Multitenant PDB licensing wording; re-verify 19c Extended Support paid period (2029–2032) details