읽는 기준

Oracle은 관계형 모델을 바꾸기보다, 대형 조직의 운영 요구를 같은 RDBMS 안에서 더 강하게 받쳐 주는 쪽에 집중합니다.

핵심은 기능 이름 자체보다, 복잡한 질의·큰 데이터·무중단 운영을 각각 어떤 장치로 버티게 만드는지입니다.

엔터프라이즈 요구
Oracle이 쓰는 수단
운영에서 달라지는 점
복잡한 SQL도 예측 가능해야 함

대형 업무 시스템은 조인, 집계, 배치 쿼리가 길고 다양합니다.

강력한 옵티마이저

인덱스 선택, 조인 순서, 접근 경로를 비용 기반으로 세밀하게 고릅니다.

복잡한 워크로드에서 실행 계획 품질을 유지

같은 SQL이라도 데이터 규모가 커질수록 성능 흔들림을 줄이는 데 유리합니다.

테이블이 커져도 관리 가능해야 함

한 테이블에 데이터가 계속 쌓이면 조회와 유지보수 비용이 같이 증가합니다.

파티셔닝

범위나 해시 기준으로 데이터를 나눠 저장해, 필요한 조각만 읽고 따로 관리합니다.

대용량 데이터도 부분 단위로 다룸

조회 범위를 줄이고, 백업·보관·정리 같은 운영 작업을 더 세밀하게 나눌 수 있습니다.

장애가 나도 서비스가 멈추면 안 됨

금융·공공 같은 환경에서는 한 노드 장애가 전체 중단으로 이어지면 안 됩니다.

RAC

여러 노드가 같은 데이터베이스를 공유하며, 장애 상황에서도 서비스를 이어 가도록 설계합니다.

고가용성 운영에 초점

단일 서버 의존을 줄여, 유지보수나 장애 대응에서도 서비스 연속성을 확보하기 쉽습니다.

I/O 병목까지 포함해 전체 성능을 끌어올려야 함

DB 엔진만 빨라도 저장 장치가 받쳐 주지 못하면 대형 시스템은 쉽게 막힙니다.

Exadata 같은 하드웨어 통합

DB 소프트웨어와 스토리지를 함께 최적화해, 병목이 생기는 구간을 줄입니다.

소프트웨어와 장비를 묶어 처리량 확보

대형 운영 환경에서 벤더가 전체 스택을 책임지는 구조를 선호할 때 강점이 큽니다.

정리: Oracle은 "기능이 많다"는 제품 소개보다, 복잡한 질의 최적화 + 대용량 운영 + 고가용성을 한 관계형 플랫폼으로 묶어 주는 엔터프라이즈형 RDBMS로 이해하는 편이 빠릅니다.