ASH에서 롤백(Rollback) 이벤트 분석: 롤백이 발생하는 원인을 분석하고 해결하는 방법.

서버 이관 프로젝트를 진행하는 과정에서 데이터 무결성을 유지하고 성능을 안정적으로 유지하는 것은 매우 중요한 과제다. 특히 트랜잭션 처리 중에 롤백(Rollback)이 자주 발생하면, 애플리케이션 성능 저하와 데이터 일관성 문제를 유발할 수 있다.

 

롤백이란 트랜잭션이 완료되지 못하고 취소될 때, 이전 상태로 데이터를 되돌리는 과정을 의미한다. 일반적으로 데이터 무결성을 보호하기 위해 수행되지만, 빈번한 롤백은 불필요한 리소스 낭비와 성능 저하를 초래할 수 있다.

 

이러한 문제를 해결하기 위해 Oracle의 ASH(Active Session History) 데이터를 활용하여 롤백이 발생하는 원인을 분석하는 것이 중요하다. ASH 데이터는 Oracle이 초 단위로 활성 세션 정보를 수집하는 기능을 제공하며, 롤백이 발생한 트랜잭션을 추적하고 원인을 파악하는 데 유용하게 활용할 수 있다.

 

본 글에서는 ASH 데이터를 활용하여 롤백 이벤트를 분석하는 방법과, 이를 해결하기 위한 최적화 전략을 상세히 설명한다. 이를 통해 서버 이관 후 예상치 못한 롤백 발생을 방지하고 데이터베이스의 안정성을 유지할 수 있도록 한다.

---

롤백(Rollback)이 발생하는 주요 원인

트랜잭션 충돌 및 경쟁(Deadlock, Lock Contention)

• 여러 세션이 동일한 데이터에 대해 동시에 업데이트를 수행할 경우, 트랜잭션 충돌이 발생할 수 있으며, 이로 인해 일부 트랜잭션이 롤백될 수 있다.
• 특히 Deadlock(교착 상태)이 발생하면, Oracle은 자동으로 한쪽 트랜잭션을 강제 롤백하여 교착 상태를 해소한다.

트랜잭션 시간이 너무 길어 발생하는 롤백

• 하나의 트랜잭션이 너무 오래 지속되면, 리소스가 과도하게 사용되면서 롤백이 발생할 가능성이 높아진다.
• 예를 들어, 대량의 데이터 업데이트 작업이 실행 중일 때, 트랜잭션이 일정 시간 이상 지속되면 UNDO 테이블스페이스가 가득 차면서 강제 롤백될 수 있다.

제약 조건 위반(Constraint Violation)

• Primary Key, Unique Key, Foreign Key 등의 제약 조건을 위반하는 트랜잭션이 발생하면, Oracle은 해당 트랜잭션을 자동으로 롤백한다.
• 특히 대량 삽입(INSERT) 작업 중 중복 데이터가 발생하는 경우 롤백이 빈번하게 발생할 수 있다.

Undo 테이블스페이스 부족

• 트랜잭션이 롤백을 수행할 때, UNDO 테이블스페이스를 사용하여 이전 데이터를 복구하는데, UNDO 공간이 부족하면 롤백이 실패할 수 있다.
• 대량 트랜잭션이 실행 중인 경우 UNDO 공간을 적절히 관리하지 않으면 예기치 않은 롤백이 발생할 가능성이 높다.

애플리케이션에서 명시적으로 롤백 수행

• 비즈니스 로직에서 특정 조건이 충족되지 않으면 명시적으로 ROLLBACK을 수행하는 경우가 있다.
• 예를 들어, 업무 프로세스에서 특정 데이터 조건이 만족되지 않을 때 자동으로 트랜잭션을 취소하는 방식이 적용될 수 있다.

---

ASH 데이터를 활용한 롤백 이벤트 분석 방법

1. 롤백이 발생한 트랜잭션 조회

특정 시간 동안 롤백이 발생한 트랜잭션을 조회하려면, ASH 데이터를 활용하여 'rollback' 이벤트를 분석할 수 있다.

SELECT    sql_id,    session_id,    event,    COUNT(*) AS rollback_count  FROM    v$active_session_history  WHERE    event IN (     'rollback', 'transaction rollback'   )    AND sample_time >= SYSDATE - (30 / 1440) -- 최근 30분간 데이터 조회  GROUP BY sql_id, session_id, event  ORDER BY rollback_count DESC;

• event = 'rollback' 또는 'transaction rollback' → 롤백이 발생한 세션 조회.
• rollback_count → 해당 SQL이 롤백된 횟수.

이 데이터를 활용하면 어떤 SQL이 자주 롤백을 발생시키는지 파악하고, 원인을 분석할 수 있다.

---

2. Deadlock 및 Lock Contention으로 인해 롤백된 트랜잭션 조회

Deadlock이나 Lock Contention으로 인해 롤백이 발생하는 경우를 분석하려면 세션 간의 락 대기 이벤트를 조회할 수 있다.

SELECT    session_id,    blocking_session,    event,    COUNT(*) AS lock_waits  FROM    v$active_session_history  WHERE    event IN (     'enq: TX - row lock contention',      'enq: TM - contention'   )    AND sample_time >= SYSDATE - (30 / 1440) -- 최근 30분간 데이터 조회  GROUP BY session_id, blocking_session, event ORDER BY lock_waits DESC;

• blocking_session → 해당 트랜잭션을 차단하고 있는 세션 ID.
• event → 트랜잭션 롤백을 유발한 주요 대기 이벤트.
• lock_waits → 특정 트랜잭션이 락을 기다린 횟수.

이 데이터를 분석하면 Deadlock이 발생한 세션과 롤백이 발생한 트랜잭션을 식별하여 해결할 수 있다.

---

3. 트랜잭션 실행 시간이 너무 긴 세션 조회

오래 실행되는 트랜잭션이 롤백되는 경우를 분석하려면 트랜잭션이 장시간 실행된 세션을 조회할 수 있다.

SELECT    session_id,    sql_id,    COUNT(*) AS execution_time  FROM    v$active_session_history  WHERE    session_state = 'ON CPU'    AND sample_time >= SYSDATE - (30 / 1440)  GROUP BY    session_id,    sql_id  ORDER BY    execution_time DESC;

• execution_time → 특정 SQL이 실행된 횟수.

이 데이터를 활용하면 오래 실행된 트랜잭션을 조기에 감지하고, 필요하면 트랜잭션 크기를 줄이거나 COMMIT 빈도를 조정할 수 있다.

---

롤백 문제 해결을 위한 최적화 전략

1. Deadlock 및 Lock Contention 해결

• 트랜잭션이 동일한 데이터를 동시에 변경하지 않도록 애플리케이션 로직을 조정한다.
• 락이 자주 발생하는 테이블에 적절한 인덱스를 추가하여 충돌을 최소화한다.
• 트랜잭션의 실행 시간을 단축하고, 필요하면 트랜잭션 크기를 줄여 롤백 가능성을 낮춘다.

2. 트랜잭션 크기 조정

• 대량 업데이트 또는 삽입(INSERT) 작업을 수행할 때, 여러 개의 작은 트랜잭션으로 나누어 실행하는 것이 좋다.
• 정기적으로 COMMIT을 수행하여 UNDO 테이블스페이스 사용량을 줄이고, 롤백 부담을 완화할 수 있다.

3. UNDO 테이블스페이스 관리 최적화

• UNDO 테이블스페이스 크기를 적절히 설정하여 롤백 시 충분한 공간이 확보되도록 조정한다.
• 현재 UNDO 설정 확인:
   

  SHOW PARAMETER undo_tablespace;
• UNDO 크기 조정:
   

  ALTER DATABASE DATAFILE '/oradata/undotbs01.dbf' RESIZE 2G;

4. 애플리케이션에서 불필요한 롤백 방지

• 명시적인 ROLLBACK이 자주 발생하는 경우, 애플리케이션 로직을 분석하여 불필요한 롤백을 줄인다.
• 트랜잭션이 실패할 가능성이 있는지 사전에 검증하고, 롤백을 최소화하는 방식으로 개발하는 것이 중요하다.

---

ASH 데이터를 활용하면 롤백이 발생하는 주요 원인을 실시간으로 분석하고, Deadlock, 트랜잭션 충돌, UNDO 부족 등의 문제를 해결할 수 있다.

 

특히, 트랜잭션 크기를 조정하고, 적절한 인덱스를 추가하며, UNDO 테이블스페이스를 최적화하면 롤백으로 인한 성능 저하를 방지할 수 있다.