ORACLE 대용량 데이터 백업 처리시

130만건 데이터를 백업하는 경우가 있다. 총 3천만건 정도 되는 테이블이라 슬로우쿼리가 팍팍하게 걸린다.

일단 생각나는대로 조회쿼리를 뚝딱뚝딱 조립해서, 백업을 시도했다.

반응형

CREATE TABLE Z_BAK_M_DATA AS
SELECT *
FROM K_V2.M_DATA m
WHERE SRC_SEQ = 3
  AND m.M_POINT_ID IN (
        SELECT m2.M_POINT_ID
        FROM K_V2.M_DATA m2
        LEFT JOIN K_V2.OUTDOOR_M_POINT o
               ON m2.M_POINT_ID = o.OUTDOOR_M_POINT_ID
              AND o.DEL_YN = 'N'
        WHERE m2.SRC_SEQ = 3
          AND o.OUTDOOR_M_POINT_ID IS NULL
  );

 

단순하게 접근하니, 느리고, 안되고, 슬프네.

느리고, 뻗고, 재기동하면서 내가 잘못했다 인정을 한다.

 

그래서 GPT 형님께 문의를 하면서 튜닝을 시작한다.

형님의 조언을 듣고보니, 고개가 절로 끄덕여진다. 그래 이게 맞지.

 

CREATE TABLE Z_BAK_M_DATA
NOLOGGING
PARALLEL 8
AS
SELECT /*+ PARALLEL(m 8) */
       m.*
FROM K_V2.M_DATA m
WHERE m.SRC_SEQ = 3
  AND NOT EXISTS (
        SELECT 1
        FROM K_V2.OUTDOOR_M_POINT o
        WHERE o.OUTDOOR_M_POINT_ID = m.M_POINT_ID
          AND o.DEL_YN = 'N'
  );

현재 쿼리가 느린 이유 (핵심)

1. IN (서브쿼리)
   → 대량 데이터에서 가장 느린 패턴 중 하나
2. MEASURE_DATA를 두 번 스캔
3. LEFT JOIN + IS NULL
   → 옵티마이저가 잘못 타면 풀스캔
4. CTAS 단일 트랜잭션
5. 이후 DELETE도 같은 조건으로 또 풀스캔 예정

문제는 늘 정답을 놓고 보면 명확하고, 간단한 해법들이 있다.

공부를 해야 한다. 열심히 해보자.