[SAP] Lock 방식/경합, Enqueue (운영관점)

SAP ERP 시스템은 여러 사용자가 동시에 데이터를 처리한다.

이때 동일한 데이터를 동시에 수정하려고 하면 데이터 불일치(정합성 오류)가 발생할 수 있다.

이를 방지하기 위해 SAP는 Enqueue(잠금, Lock) 메커니즘을 제공한다.

하지만 특정 상황에서는 Lock이 과도하게 걸리거나 해제되지 않아 Lock 경합(Contention) 이 발생하며, 이는 실무에서 트랜잭션 지연이나 오류의 주요 원인이 된다.

 

이번 시간엔 개발 관점은 제외하고 운영관점에서 알아보자

 

1. 일반적인 DB 트랜잭션에서의 Lock
DB만 단독으로 사용하는 시스템에서는, 사용자가 데이터를 수정하려 하면 DB가 그 데이터를 직접 Lock해서 다른 사용자가 동시에 수정하지 못하게 한다.

예:
사용자 A가 고객 마스터 테이블 KNA1의 특정 고객(1000번)을 수정 → DB가 해당 레코드를 Lock
사용자 B가 같은 고객(1000번)을 수정하려고 하면 → DB Lock 때문에 대기

2. SAP에서는?
SAP는 단순 DB Lock을 그대로 쓰지 않는다.
왜냐하면 SAP는 다수의 서버가 DB와 연결되어 있고, SAP 자체적으로 문서 단위(예: 판매오더, 송장) 같은 논리적 개체 단위로 Lock을 관리해야 하기 때문

즉, SAP에서는 DB 레벨이 아닌, 논리적 객체 기준의 Lock 관리가 필요하다.

3. SAP의 Enqueue Server 역할
SAP는 DB Lock 대신 Enqueue Server라는 전용 프로세스를 두고, 모든 Lock 요청을 Enqueue Server에서 먼저 처리하도록 설계

동작 방식은 사용자가 판매오더 12345를 수정하려고 VA02 실행.
SAP Work Process가 Enqueue Server에게 오더 12345 잠구라고 요청.

Enqueue Server가 확인
지금 아무도 이 오더를 안 쓰고 있다면 → Lock을 부여하고 OK 응답.
이미 Lock 잡힌 상태라면 → 대기 or 에러 메시지 발생.
Enqueue Server에서 Lock이 성공해야만 → DB에 Update가 진행됨.

즉, SAP는 DB에 직접 Lock을 거는 게 아니라 → Enqueue Server에서 먼저 논리적 Lock을 관리하고 → 성공한 경우에만 DB 변경을 허용하는 구조인 것이다.

DB Lock 방식: 도서관에서 책을 빌릴 때 → 책장에 직접 대출 중 표시를 붙여두는 것.
SAP Enqueue 방식: 도서관 카운터(Enqueue Server)에서 먼저 누가 어떤 책을 빌리는지 기록해두고,
카운터에서 허가받은 사람만 책을 가져갈 수 있게 하는 것.

정리하자면,
SAP는 DB 충돌을 막기 위해 Enqueue Server라는 논리적 Lock 관리자에게 먼저 Lock을 요청하고, 성공한 경우에만 DB 작업을수행한다

Enqueue(잠금) 원리
Enqueue Server
SAP 시스템에서 데이터베이스 레벨의 Lock 대신 논리적 Lock을 관리하는 전용 서버 프로세스.

Lock 객체 (Lock Object)
개발자가 정의한 데이터 테이블/필드를 기준으로 Lock을 생성. 예: 판매오더(VBAK) 같은 문서 단위.

Lock 종류
Exclusive Lock (E): 하나의 사용자만 접근 가능 (다른 사용자 접근 불가).
Shared Lock (S): 여러 사용자 조회 가능, 수정 불가.
Optimistic Lock (O): 잠금 없이 먼저 실행 후 충돌 시 롤백 처리.

즉, SAP는 DB 트랜잭션 충돌을 막기 위해 Enqueue Server에 먼저 잠금을 요청 → 성공 시 DB에 반영 하는 구조

Lock 경합 발생 원인
실무에서 자주 발생하는 케이스는.

1. 동일 문서를 여러 사용자가 동시에 수정
예: 같은 판매오더를 두 명이 동시에 VA02로 수정 시.

Batch Job과 온라인 트랜잭션 동시 실행
MRP Job이 오더 생성 중일 때 사용자가 같은 오더를 수정하려 하면 경합 발생.

2. Lock 해제 지연
프로그램 비정상 종료, 네트워크 장애 등으로 Lock이 해제되지 않는 경우.

3. 대량 처리 프로그램
Custom Batch Job에서 Lock 범위를 너무 크게 잡아 전체 문서를 오래 Lock하는 경우.

확인 방법
SM12 (Lock Entry List)
현재 시스템에서 걸린 Lock 목록 확인.
Lock 대상(테이블/키), 사용자, 클라이언트, 시간 표시.
오래된 Lock이 있으면 해당 세션이 죽었는지 확인 후 수동 삭제 가능.

SM21 (System Log)
Lock 관련 에러 메시지 확인.

ST22 (Dump Analysis)
Lock Timeout 발생 시 관련 ABAP Dump 확인 가능.

SM37 (Job Monitoring)
Job이 Lock 때문에 대기 중인지 체크.

트러블슈팅 & 해결 방안

오래된 Lock을 SM12에서 운영자가 직접 해제 (주의: 무분별 삭제는 데이터 불일치 위험).
Job이 Lock으로 정지된 경우 → 해당 사용자/프로세스 종료 후 재실행.
동일 문서 동시에 처리하려는 사용자에게 안내.