다른 데이터베이스에 있는 테이블을
내가 접속 중인 데이터베이스에서 직접 조회하거나 사용할 수 있게 해주는 연결 통로
=> A DB에서 B DB의 테이블을 바로 SELECT/DML 작업 가능
DB 링크를 사용했던 이유
- 운영 DB와 분석 DB가 분리되어 있을 때
- 다른 시스템(DB)에 있는 데이터를 바로 써야 할 때
- 데이터 복사 없이 실시간 참조가 필요할 때
DB 링크를 지양하는 이유

1. 장애 전파 및 복구 어려움
- 단일 장애가 연쇄 장애로 확산될 수 있음
예) 로컬 DB에서 원격 DB의 테이블을 조인하고 있었는데, 원격 DB에 장애 발생 → 로컬 서비스까지 먹통
- 복구가 어려움
단순한 재시도나 로컬 트랜잭션 롤백으로 끝나지 않음DB간 연결이 끊긴 상태에서 rollback조차 실패할 수 있음
2. 보안 취약점
- DB 링크는 일반적으로 고정된 계정/비밀번호로 연결되며 그 정보가 내부적으로 평문 저장되거나 공개될 수 있음 → 특히 PUBLIC DB LINK의 경우, 누구나 접근 가능한 보안 구멍이 될 수 있음
- 원격 DB 권한 통제 어려움
링크를 통해 간접적으로 원격 DB에 쓰기/삭제 등을 해버릴 수 있어서 위험
3. 성능 저하 및 튜닝 어려움
- 원격 쿼리를 조인하거나 트랜잭션으로 처리하면 네트워크 레이턴시 + 원격 옵티마이저 문제로 성능이 예측불가
- 옵티마이저가 원격 테이블의 통계를 알 수 없어서 비효율적인 실행계획을 세우는 경우가 많음
- 원격 DB의 성능 저하가 로컬 DB에도 영향을 미치므로 문제 원인 추적이 까다로움
4. 트랜잭션 일관성 보장 어려움
- DB 링크를 통한 분산 트랜잭션은 복잡한 구조를 가짐 (2PC - Two Phase Commit) → 트랜잭션 커밋/롤백 중 일부만 성공하면 데이터 불일치 발생 위험
- 특히 장애 중복 발생 시 원격 DB는 커밋됐는데 로컬은 롤백된 상황 등… 복구가 매우 어려움
5. 운영 및 배포 관리 복잡성
- 운영 중 링크 관리 어려움
- 링크 대상 DB가 변경되면 모든 관련 DB 링크를 수정해야 함
- DB 복제, 마이그레이션, 환경 분리(운영/스테이징/개발) 시 DB 링크 설정 때문에 작업량 증가
- TNS 설정, SID/서비스명 의존성 때문에 클라우드 전환/분산 아키텍처에 부적합
6. 현대적인 아키텍처와 어긋남
-요즘은 마이크로서비스, API 중심, 메시지 기반 아키텍처가 대세라서 DB끼리 직접 연결(link)하는 방식보다 API 호출, RESTful 서비스, 메시징 큐(Kafka 등)로 데이터 전달하는 추세임
- DB 링크는 서비스 독립성/경계를 깨뜨리고 강한 결합을 초래함
✅ 대안
1. REST API
- DB끼리 직접 연결하는 대신, 중간 API를 두고 호출로 연결
2. 메시징 큐
- Kafka, RabbitMQ 등을 활용한 비동기 데이터 전달 방식
3. DB 복제
- GoldenGate, Streams, Kafka CDC 등으로 DB 간 실시간 복제
4. ETL / ELT
- 주기적 배치/스트리밍으로 데이터를 이동시키고 각 DB에서 독립 운영
'RDBMS > Oracle' 카테고리의 다른 글
| [Oracle] 분기 관련 날짜 데이터 출력 - TO_CHAR(), TRUNC() (0) | 2023.08.31 |
|---|---|
| [Oracle] FETCH절(출력 행 개수 지정) (0) | 2023.07.12 |
| [PL/SQL] 복합형(레코드/컬렉션) (0) | 2023.04.21 |
| [PL/SQL] 변수의 자료형(스칼라형/참조형) (0) | 2023.04.21 |
| [PL/SQL] 제어문(조건문, 반복문) (0) | 2023.04.21 |

