운영 환경에서 DB Link를 조심해야 하는 이유 – 장애·보안·성능 리스크 완벽 정리

[로컬 DB 서버 - A사 시스템]          [원격 DB 서버 - B사 시스템]
┌──────────────────────┐             ┌──────────────────────┐
│  SELECT *            │   DB Link   │                      │
│  FROM orders@remote  │ ─────────── │  orders 테이블       │
│  WHERE status='완료' │  네트워크   │  (원격 접근)         │
└──────────────────────┘             └──────────────────────┘
      로컬 세션                          원격 세션 생성

-- DB Link 생성
CREATE DATABASE LINK remote_db_link
  CONNECT TO remote_user IDENTIFIED BY "password123"
  USING '(DESCRIPTION=
    (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.1.100)(PORT=1521))
    (CONNECT_DATA=(SERVICE_NAME=REMOTEDB)))';

-- DB Link를 통한 원격 테이블 조회
SELECT o.order_id, o.customer_id, c.customer_name
FROM   orders@remote_db_link o         -- 원격 DB의 주문 테이블
JOIN   customers c ON o.customer_id = c.id  -- 로컬 DB의 고객 테이블
WHERE  o.status = '완료'
  AND  o.created_at >= SYSDATE - 7;

-- 원격 테이블에 데이터 삽입
INSERT INTO sync_log@remote_db_link (event_time, event_type, detail)
VALUES (SYSDATE, 'SYNC', '일일 정산 완료');
COMMIT;

-- 외부 서버 등록
CREATE EXTENSION postgres_fdw;

CREATE SERVER remote_pg_server
  FOREIGN DATA WRAPPER postgres_fdw
  OPTIONS (host '192.168.1.200', port '5432', dbname 'analytics_db');

-- 사용자 매핑
CREATE USER MAPPING FOR local_user
  SERVER remote_pg_server
  OPTIONS (user 'remote_user', password 'remote_pass');

-- 외부 테이블 선언
CREATE FOREIGN TABLE remote_sales (
    sale_id     BIGINT,
    amount      NUMERIC(15, 2),
    sale_date   DATE
)
SERVER remote_pg_server
OPTIONS (schema_name 'public', table_name 'sales');

-- 마치 로컬 테이블처럼 조회
SELECT * FROM remote_sales WHERE sale_date >= '2024-01-01';

[장애 전파 시나리오]

원격 DB 서버 (B시스템)
    │
    ├─ 네트워크 단절 발생
    ├─ DB 과부하로 응답 지연 (30초 타임아웃)
    └─ DB 서버 다운

         ↓ DB Link 연결

로컬 DB 세션들이 원격 응답을 기다리며 대기(WAITING) 상태
    │
    ├─ 세션 수 급증 → 커넥션 풀 고갈
    ├─ 대기 중인 쿼리가 락(Lock) 보유
    └─ 다른 정상 쿼리들도 락 대기 → 연쇄 장애

         ↓

로컬 DB 서버 (A시스템) 전체 서비스 중단

-- 이 쿼리 하나가 원격 DB 응답을 30초간 기다리면서
-- 해당 세션의 트랜잭션 전체가 블로킹됩니다
SELECT COUNT(*)
FROM   statistics@remote_db_link  -- 원격 DB가 느려지는 순간
WHERE  report_date = TRUNC(SYSDATE);
-- 이 쿼리를 실행한 배치 프로그램이 커넥션을 점유하고,
-- 커넥션 풀이 가득 차서 다른 서비스 요청이 모두 실패하기 시작합니다.

-- 위험한 분산 트랜잭션 예시
BEGIN
    -- 로컬 DB 업데이트
    UPDATE local_orders
    SET    status = '처리완료'
    WHERE  order_id = 12345;

    -- 원격 DB 업데이트 (DB Link)
    UPDATE order_history@remote_db_link
    SET    sync_status = 'DONE',
           synced_at   = SYSDATE
    WHERE  order_id = 12345;

    COMMIT; -- 2PC 시작: 양쪽 DB에 PREPARE → COMMIT 순서로 진행
EXCEPTION
    WHEN OTHERS THEN
        ROLLBACK;  -- 원격 DB 롤백이 실패하면? → 데이터 불일치!
END;

-- Oracle에서 인-다우트 트랜잭션 확인
SELECT local_tran_id, global_tran_id, state, mixed, advice, tran_comment
FROM   dba_2pc_pending;

-- 수동으로 강제 커밋 또는 롤백 (DBA 직접 개입 필요)
COMMIT   FORCE 'local_tran_id';
ROLLBACK FORCE 'local_tran_id';

-- DB Link 생성 시 자격증명이 평문으로 저장됨
CREATE DATABASE LINK remote_db_link
  CONNECT TO admin_user IDENTIFIED BY "SuperSecret123!"
  USING 'REMOTEDB';

-- DBA 권한이 있는 계정이라면 다음으로 조회 가능
SELECT db_link, username, host
FROM   dba_db_links;
-- username: ADMIN_USER (비밀번호는 암호화되어 있지만 해독 가능)

-- 위험한 패턴: 로컬 데이터 건수만큼 원격 쿼리 발생 (N+1 문제)
FOR rec IN (SELECT order_id FROM local_orders WHERE status = 'PENDING')
LOOP
    -- 루프 1회당 네트워크 왕복 1회 발생
    -- 100건이면 100번의 네트워크 왕복
    SELECT customer_name
    INTO   v_name
    FROM   customers@remote_db_link
    WHERE  customer_id = rec.customer_id;

    -- ... 처리 로직
END LOOP;

-- 옵티마이저가 잘못된 실행 계획을 선택하는 예시
-- 원격 테이블이 1억 건인데 통계가 없으면 작은 테이블로 오인
SELECT l.order_id, r.customer_name
FROM   local_orders l
JOIN   customers@remote_db_link r ON l.customer_id = r.customer_id
WHERE  l.status = 'COMPLETE';
-- 실제: remote customers = 1억 건 → Nested Loop 선택 → 매우 느림
-- 기대: Hash Join이 적합하나 원격 통계 부재로 잘못된 선택

-- 야간 배치 프로그램 (매일 새벽 2시 실행)
INSERT INTO daily_report
SELECT a.dept_code,
       SUM(b.sales_amount) AS total_sales,
       COUNT(b.order_id)   AS order_count
FROM   departments a
JOIN   sales@legacy_db_link b ON a.dept_code = b.dept_code  -- DB Link 사용
WHERE  b.sale_date = TRUNC(SYSDATE) - 1
GROUP BY a.dept_code;

COMMIT;

-- DB Link의 기본 타임아웃이 없으면 Oracle은 영구 대기
ALTER SESSION SET distributed_lock_timeout = 60; -- 60초로 제한
-- 이 설정이 없으면 기본값(60초)이지만, DB Link 자체 타임아웃은 별도
-- sqlnet.ora에 SQLNET.OUTBOUND_CONNECT_TIMEOUT 미설정 시 영구 대기 가능

-- sqlnet.ora에 반드시 설정해야 할 항목
-- SQLNET.OUTBOUND_CONNECT_TIMEOUT = 10  (연결 타임아웃: 10초)
-- SQLNET.RECV_TIMEOUT = 30              (수신 타임아웃: 30초)
-- SQLNET.SEND_TIMEOUT = 30              (송신 타임아웃: 30초)

-- 일반 뷰처럼 보이지만 내부에 DB Link가 숨어있음
CREATE OR REPLACE VIEW v_customer_summary AS
SELECT c.customer_id,
       c.customer_name,
       o.total_orders,
       o.total_amount
FROM   customers c
JOIN   (
    SELECT customer_id,
           COUNT(*)    AS total_orders,
           SUM(amount) AS total_amount
    FROM   orders@crm_db_link  -- 여기에 숨어있는 DB Link!
    GROUP BY customer_id
) o ON c.customer_id = o.customer_id;

// DB Link 방식: 원격 DB 직접 조회 (나쁜 예)
// SELECT * FROM customers@remote_db_link WHERE customer_id = ?

// API 방식: HTTP 호출로 대체 (좋은 예)
@Service
public class CustomerIntegrationService {

    private final RestTemplate restTemplate;
    private final CircuitBreaker circuitBreaker;  // 장애 격리 핵심

    public CustomerIntegrationService(RestTemplate restTemplate,
                                       CircuitBreakerRegistry registry) {
        this.restTemplate = restTemplate;
        this.circuitBreaker = registry.circuitBreaker("customerService");
    }

    public CustomerDto getCustomer(Long customerId) {
        // 서킷 브레이커로 감싸서 원격 서비스 장애가 전파되지 않도록 격리
        return circuitBreaker.executeSupplier(() -> {
            String url = "http://customer-service/api/customers/" + customerId;
            return restTemplate.getForObject(url, CustomerDto.class);
        });
    }

    // 서킷 브레이커가 열렸을 때 반환할 폴백
    public CustomerDto getCustomerFallback(Long customerId, Exception ex) {
        log.warn("Customer service unavailable, returning fallback for id: {}", customerId);
        return CustomerDto.unknown(customerId);  // 기본값 반환
    }
}

[배치 ETL 파이프라인 구조]

원격 DB (소스)
    │
    ├─ Debezium (CDC - Change Data Capture)
    │   └─ 변경된 데이터만 실시간 캡처
    │
    ├─ Apache Kafka (메시지 버스)
    │   └─ 데이터 변경 이벤트 전달
    │
    └─ Kafka Consumer
        └─ 로컬 DB (타겟) 동기화 테이블에 반영

-- 로컬 DB에 복제된 테이블을 조인 (DB Link 없음)
SELECT l.order_id, r.customer_name
FROM   local_orders l
JOIN   synced_customers r ON l.customer_id = r.customer_id;
-- synced_customers: 원격 DB를 로컬에 주기적으로 복제한 테이블

# 단순 배치 ETL 예시 (Python + SQLAlchemy)
import schedule
from sqlalchemy import create_engine, text

SOURCE_DB = create_engine("oracle+cx_oracle://user:pass@source-db/orcl")
TARGET_DB = create_engine("postgresql://user:pass@local-db/mydb")

def sync_customers():
    """원격 고객 데이터를 로컬 동기화 테이블에 복제"""
    with SOURCE_DB.connect() as src, TARGET_DB.connect() as tgt:
        # 변경된 데이터만 가져오기 (증분 동기화)
        rows = src.execute(text("""
            SELECT customer_id, customer_name, email, updated_at
            FROM   customers
            WHERE  updated_at >= :last_sync
        """), {"last_sync": get_last_sync_time()}).fetchall()

        if rows:
            tgt.execute(text("""
                INSERT INTO synced_customers
                    (customer_id, customer_name, email, synced_at)
                VALUES (:id, :name, :email, NOW())
                ON CONFLICT (customer_id)
                DO UPDATE SET customer_name = EXCLUDED.customer_name,
                              email         = EXCLUDED.email,
                              synced_at     = NOW()
            """), [{"id": r.customer_id, "name": r.customer_name,
                    "email": r.email} for r in rows])
            tgt.commit()
            update_last_sync_time()

schedule.every(10).minutes.do(sync_customers)

[이벤트 기반 구조]

A 시스템 (주문)         B 시스템 (통계)
┌─────────────┐         ┌─────────────┐
│ 주문 생성   │─Kafka──→│ 주문 이벤트 │
│             │  이벤트  │ 구독 → 통계 │
│ orders 테이블│         │ DB에 저장   │
└─────────────┘         └─────────────┘
  DB Link 없음             DB Link 없음
  각자의 DB만 조회          각자의 DB만 조회

# $ORACLE_HOME/network/admin/sqlnet.ora
SQLNET.OUTBOUND_CONNECT_TIMEOUT = 10   # 연결 시도 타임아웃: 10초
SQLNET.RECV_TIMEOUT             = 30   # 데이터 수신 타임아웃: 30초
SQLNET.SEND_TIMEOUT             = 30   # 데이터 송신 타임아웃: 30초

-- 세션 레벨 분산 트랜잭션 타임아웃
ALTER SYSTEM SET DISTRIBUTED_LOCK_TIMEOUT = 60 SCOPE = BOTH;

-- DB Link 전용 계정에는 필요한 객체에만 SELECT 권한 부여
CREATE USER db_link_readonly IDENTIFIED BY 'ComplexPass123!';

-- 절대 금지: GRANT DBA TO db_link_readonly;
-- 절대 금지: GRANT SELECT ANY TABLE TO db_link_readonly;

-- 필요한 테이블에만 최소 권한
GRANT SELECT ON customers TO db_link_readonly;
GRANT SELECT ON product_catalog TO db_link_readonly;
-- INSERT, UPDATE, DELETE는 가능한 한 부여하지 않음

-- 현재 DB Link 목록 전수 조회
SELECT owner, db_link, username, host, created
FROM   dba_db_links
ORDER BY owner, db_link;

-- 현재 활성화된 DB Link 세션 모니터링
SELECT s.sid, s.serial#, s.username, s.status,
       s.sql_id, s.event, s.wait_time_micro / 1000 AS wait_ms
FROM   v$session s
WHERE  s.server = 'SHARED'
   OR  EXISTS (
       SELECT 1 FROM v$dblink d WHERE d.sid = s.sid
   );

-- DB Link를 통한 쿼리 실행 횟수 추적
SELECT db_link_name, executions, elapsed_time/1000 AS elapsed_ms
FROM   v$sql
WHERE  sql_text LIKE '%@%'  -- DB Link 사용 쿼리 식별
ORDER BY elapsed_time DESC;

-- DB Link를 직접 노출하지 않고 뷰로 캡슐화
-- 뷰 명칭에 외부 데이터임을 명시
CREATE OR REPLACE VIEW ext_v_customers AS
SELECT customer_id, customer_name, email  -- 필요한 컬럼만 노출
FROM   customers@remote_db_link;

-- 이 뷰를 통해서만 접근하도록 DB Link 직접 사용 금지 정책 적용
-- 개발자들이 @remote_db_link를 직접 쓰는 코드를 작성하지 않도록 가이드