[ORACLE] SPLIT 수행 시 ORA-600 발생 원인과 점검 절차

SPLIT 수행 시 ORA-600 발생 원인과 점검 절차

ORA-600(Internal error)은 “원인 코드/인자(argument)”에 따라 성격이 크게 달라집니다. 특히 파티션 SPLIT 같은 DDL 작업 중 ORA-600이 뜨면, (1) 오브젝트/인덱스/UNDO/시스템 상태 문제인지, (2) 특정 버전 결함(버그)인지부터 빠르게 갈라서 보는 게 핵심입니다.

먼저 결론부터
- ORA-600은 “코드(첫 번째 argument) + trace/alert”가 없으면 정답을 못 좁힙니다.
- 운영 환경에서는 “재현/우회”보다 원인 코드 확보 → 영향 범위 확정 → 안전한 복구 루트가 우선입니다.
- 실무 기준으로 보면, SPLIT 대상 테이블/인덱스의 상태(통계/무결성/세그먼트)와 DDL 방식(ONLINE/병렬/로깅)이 흔한 분기점입니다.

개요

이 문서는 “SPLIT 수행 시 ORA-600”을 일반오류형(확장형 매뉴얼) 흐름으로 정리합니다. SPLIT의 의미는 환경마다 다를 수 있지만, 보통 다음 중 하나입니다.

• 파티션/서브파티션 SPLIT PARTITION / SPLIT SUBPARTITION
• 인덱스 파티션/서브파티션 관련 DDL
• 특정 기능/제품에서 “split”이라는 작업 명칭을 DDL로 래핑한 경우

따라서 아래 절차는 “ORA-600 argument + 대상 오브젝트 + 수행한 정확한 DDL”을 기준으로 공통 분기하도록 구성했습니다.

환경

필수 수집(이 정보가 없으면 분석이 멈춥니다)
- DB 버전/패치 레벨: v$version, RU/RUR 적용 여부
- 발생 시각(분 단위)과 세션 정보: SID/SERIAL#, username, module/action
- 수행한 DDL 원문: ALTER TABLE ... SPLIT ... 전체
- alert.log 및 해당 ORA-600 trace 파일 경로/내용

자주 영향 받는 옵션(있으면 같이 수집)
- ONLINE DDL 사용 여부, 병렬/로깅/압축/암호화 옵션
- UNDO/TEMP 여유, REDO 발생량, 아카이브 지연 여부
- Data Guard/Standby 적용 여부(redo apply 지연 포함)

기본 확인 SQL

-- 버전/플랫폼
select * from v$version;

-- 인스턴스/DB 정보
select instance_name, host_name, version, startup_time from v$instance;
select name, open_mode, database_role from v$database;

-- 파라미터(온라인 DDL, 병렬 등 분석에 자주 씀)
show parameter parallel;
show parameter undo;
show parameter db_securefile;

증상

SPLIT 실행 도중 ORA-600이 발생하면 DDL이 실패하고, 상황에 따라 “부분적으로 생성된 세그먼트/인덱스”가 남거나, 메타데이터는 진행되었지만 데이터 이동이 중단된 상태가 될 수 있습니다(환경/옵션에 따라 다름).

대표적인 관찰 포인트

• DDL이 즉시 실패하는지, 일정 시간 진행 후 실패하는지(대개 데이터 이동/인덱스 처리 시점에서 갈립니다)
• 같은 DDL을 반복하면 재현되는지(재현되면 버그/오브젝트 손상 가능성이 커짐)
• 특정 파티션/서브파티션 범위에서만 발생하는지(“특정 키 범위 데이터” 또는 “특정 세그먼트” 의심)

로그 예시(형식 참고)

ORA-00600: internal error code, arguments: [arg0], [arg1], [arg2], ...
ORA-06512: at line ...

-- alert.log에 trace 파일 경로가 같이 찍히는 경우가 많음
Errors in file /u01/app/oracle/diag/rdbms/DB/trace/DB_ora_12345.trc:
ORA-00600: internal error code, arguments: [...]

중요
ORA-600의 첫 번째 argument(예: [k...], [q...], [d...], [kc...], [kts...] 등)를 확보해야 분기할 수 있습니다.
이 문서의 점검 흐름은 “argument 기반으로 범위를 줄여가는” 방식입니다.

1차 점검

1) ORA-600 argument와 trace 파일 위치 확보

-- trace 파일이 어디에 생성되는지 빠르게 확인
select value as diag_trace
from v$diag_info
where name = 'Diag Trace';

-- 최근 발생한 에러를 세션/시간 기준으로 찾는 보조(권한/옵션에 따라 다름)
-- 가능하면 alert.log에서 발생 시각 주변을 우선 확인

2) SPLIT 대상 오브젝트 식별(테이블/파티션/인덱스)

-- SPLIT 대상 테이블/파티션 확인 (예시: 소유자/테이블명은 교체)
select owner, table_name, partitioned
from dba_tables
where owner = upper(:owner) and table_name = upper(:table_name);

select owner, table_name, partition_name, tablespace_name, status
from dba_tab_partitions
where owner = upper(:owner) and table_name = upper(:table_name)
order by partition_position;

-- 관련 인덱스 상태
select owner, index_name, status, partitioned
from dba_indexes
where table_owner = upper(:owner) and table_name = upper(:table_name)
order by index_name;

3) 즉시 위험 신호 점검(공간/UNDO/아카이브)

-- 테이블스페이스 여유 (간단 확인)
select tablespace_name, round(sum(bytes)/1024/1024) as mb
from dba_free_space
group by tablespace_name
order by mb desc;

-- UNDO 사용량/설정 확인(환경에 따라 뷰/권한 차이 있음)
show parameter undo_tablespace;
show parameter undo_retention;

-- 아카이브 모드/적용 지연(해당 시)
archive log list;

1차 점검에서 자주 나오는 결론
- 공간/UNDO/TEMP 부족이 보이면: ORA-600이 “2차 증상”일 가능성도 있어 먼저 해소 후 재시도
- 인덱스/파티션 상태가 INVALID/UNUSABLE이면: SPLIT 도중 내부 경로에서 ORA-600 유발 가능성 상승
- 같은 argument로 100% 재현되면: 특정 오브젝트 손상 또는 버전 결함(패치 필요) 방향으로 무게중심 이동

심화 분석

분기 1) 오브젝트/세그먼트 손상 의심

SPLIT은 데이터 이동/인덱스 갱신을 동반하는 경우가 많아서, 특정 파티션/인덱스 세그먼트의 미세한 손상이 트리거가 될 수 있습니다.

-- 권한이 있으면 가장 먼저 검토(테이블/인덱스)
analyze table <OWNER>.<TABLE> validate structure cascade;

-- 파티션 단위로 가능한 경우(환경에 따라 지원/제약 있음)
analyze table <OWNER>.<TABLE> partition (<PARTITION_NAME>) validate structure cascade;

-- 인덱스 단독 점검
analyze index <OWNER>.<INDEX_NAME> validate structure;

해석 팁
- validate 결과에서 체인(row chaining) 자체는 “손상”이 아닙니다.
- 오류/부정합 메시지, 또는 특정 파티션에서만 실패하는 패턴이 나오면 “해당 파티션/세그먼트” 중심으로 복구를 설계합니다.

분기 2) ONLINE/병렬/특정 옵션 조합 이슈(버그 포함) 의심

운영 환경에서는 ONLINE DDL, 병렬 DDL, 압축/암호화, LOB(SecureFile), 파티션 인덱스 구성이 겹치면 내부 경로가 복잡해집니다. ORA-600이 특정 옵션에서만 재현되면 “옵션 제거로 우회 가능 여부”를 먼저 확인하는 게 빠릅니다.

-- 예시: ONLINE/병렬을 제거한 형태로 재현성 비교(DDL 문장은 환경에 맞게 조정)
-- (1) 병렬 제거
alter session disable parallel dml;
alter session disable parallel ddl;

-- (2) ONLINE 옵션 제거(가능한 경우)
-- alter table ... split partition ...;  -- ONLINE 키워드/옵션을 제외한 변형으로 테스트

분기 3) 동시성/락/장시간 트랜잭션 영향

-- SPLIT 대상 테이블에 장시간 트랜잭션/락이 걸려있는지 확인(대표 쿼리 예시)
select
  s.sid, s.serial#, s.username, s.status, s.module,
  l.type, l.lmode, l.request
from v$session s
join v$lock l on s.sid = l.sid
where s.username is not null
order by s.sid;

운영 환경에서는
SPLIT 같은 변경 작업은 “동시성”이 원인인 경우가 많습니다.
락/장트랜잭션을 정리하고, 배치/피크 시간대를 피해서 재현성(발생/미발생)을 비교하면 원인 좁히기가 빨라집니다.

분기 4) incident/trace에서 ORA-600 세부 코드 확보

trace 파일에는 ORA-600 argument 외에 call stack, object id, SQL text 조각이 남는 경우가 있습니다. “어떤 오브젝트(OBJ#)에서 났는지”가 나오면, 손상/구성 이슈를 매우 빠르게 특정할 수 있습니다.

-- OBJ#(object id)가 trace에 있다면 매핑
select owner, object_name, object_type, subobject_name
from dba_objects
where object_id = :obj_id;

복구

1) 즉시 안전 조치(재시도 전)

• 실패한 DDL이 남긴 중간 오브젝트(임시 세그먼트/UNUSABLE 인덱스) 여부 확인
• 업무 영향이 큰 경우: SPLIT 작업을 중단하고 “현 상태 백업/스냅샷” 확보(논리/물리 중 가능한 방식)
• 같은 DDL을 무작정 반복 실행하지 않기(오브젝트 상태를 더 꼬이게 만들 수 있음)

2) 인덱스 상태 정리(UNUSABLE/INVALID 대응)

-- UNUSABLE 인덱스/파티션 인덱스가 있다면 재구성(예시)
alter index <OWNER>.<INDEX_NAME> rebuild;

-- 파티션 인덱스라면(예시)
-- alter index <OWNER>.<INDEX_NAME> rebuild partition <PARTITION_NAME>;

3) 오브젝트 손상이 의심될 때의 복구 루트(현실적인 선택지)

권장 순서(보수적으로)
1) 영향 범위 최소화(문제 파티션/서브파티션만 분리) → 2) 논리 복구(Data Pump/CTAS) → 3) 마지막 수단으로 repair 계열 고려

-- (A) 문제 범위가 파티션 단위로 고립 가능하면:
-- 1) 대상 파티션을 별도 테이블로 추출(CTAS) 후 교체 전략 검토
create table <OWNER>.<NEW_TABLE> as
select /*+ parallel */ * from <OWNER>.<TABLE> partition (<PARTITION_NAME>);

-- (B) 논리 백업/복구(예: Data Pump) 루트는 운영 정책에 맞게 진행
-- expdp/impdp는 옵션과 다운타임 전략이 중요하므로 사내 표준 절차에 따르는 것을 권장

4) 버전 결함(패치) 방향일 때

ORA-600 argument가 특정 버전/RU 조합에서 알려진 케이스와 매칭되면, 가장 안정적인 해결은 “권장 RU/RUR 적용(또는 패치셋 업데이트)”입니다. 운영 환경에서는 패치 전까지 아래 우회가 도움이 되는 경우가 있습니다.

• ONLINE 옵션 제거 후 오프라인 시간 확보하여 수행
• 병렬/특정 압축 옵션 제거 후 수행
• 인덱스를 사전에 rebuild 후 수행
• 피크 시간 회피(동시성/락 이슈 차단)

재발 방지

운영 절차 측면

• 변경 전 점검 체크리스트: 대상 테이블/인덱스 상태, 공간/UNDO/TEMP 여유, 동시성(락/장트랜잭션) 확인을 표준화
• DDL 실행 템플릿: 기본은 병렬 OFF, ONLINE은 필요 시에만, 로깅/압축 옵션은 단계적으로 적용
• 재현성 기록: 동일 DDL/동일 argument 재현 여부, 발생 시각, 세션 정보, trace 파일을 티켓에 남겨 다음 대응 시간을 줄이기

기술 측면

• 정기 패치 정책: Oracle RU/RUR(또는 조직 표준 패치 정책) 주기를 고정하고, 변경 작업은 패치 후 수행을 기본으로 설계
• 무결성 점검 루틴: 대형 파티션 테이블은 정기적으로 인덱스/세그먼트 상태 점검(업무 영향 최소 시간대)
• 백업/복구 리허설: SPLIT 실패 시 “되돌리기/대체(CTAS/impdp)” 루트의 소요시간을 사전에 검증

관리자 입장에서
ORA-600은 “원인 확정”보다 “안전한 복구와 재발 방지”가 먼저입니다.
SPLIT 같은 구조 변경은 작업 전 표준 점검(공간/UNDO/락/인덱스 상태)을 습관화하면, 같은 유형의 장애가 크게 줄어듭니다.