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
  );

 

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

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

 

728x90

그래서 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도 같은 조건으로 또 풀스캔 예정

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

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