1. Savepoint
SAP HANA DB 는 인메모리 DB 로써, 온라인 상태 중에서 대부분의 데이터는 메모리에 올라와있게 된다.
HANA 에서 Savepoint 는 지속성(Persistence) 을 위해, 메모리 상에서의 변경점(Delta Storage) 을 디스크 레벨에서 유지하도록 해준다.
Savepoint 에서는 Row, Columns 테이블의 모든 변경사항이 디스크로 기록되며, 각각의 HANA Host 와 서비스마다 고유의 Savepoint 가 있다.
Savepoint 에 속한 데이터는 작업 중, 메모리에서 디스크(Data Volum)로 Flush 하여 데이터의 일관성을 유지하며, 다음 Savepoint 작업이 완료될때까지 유지된다.
또한, 지속적인 디스크 기록으로 복구 및 DB 서비스 재시작시에 더 적은 Redo Log 를 사용하므로 속도 개선효과도 있다.
2. Savepoint 수행
여러 Savepoint 트리거가 있지만, 기본적으로는 일정 주기마다 자동으로 Savepoint 가 찍힌다.
2-1. Savepoint interval (automatic)
정상 운영 중에는 마지막 Savepoint 작업 완료 이후, 파라미터에 설정된 간격에 따라 다음 Savepoint 작업이 수행된다.
다음 파라미터를 통해 Savepoint 의 수행 간격을 조절할 수 있다.
global.ini -> [persistence] -> savepoint_interval_s
해당 파라미터의 기본 설정 값은 300 (5m) 이다.
즉, 기본적으로 5분마다 Savepoint 가 찍힌다.
2-2. System command (manual)
관리자가 필요할 때, 다음 명령어를 통해서 수동으로 Savepoint 작업을 시작할 수 있다.
ALTER SYSTEM SAVEPOINT
2-3. Soft shutdown
명령어를 통한 HANA DB Soft Shutdown 시(ex. HDB Stop), 서비스가 종료되기 전에 Savepoint 가 수행된다.
Hard Shutdown (ex. Kill) 시에는 Savepoint 가 수행되지 않는다.
2-4. Backup
DB 백업 시작 전에는 Global Savepoint 가 수행된다.
2-5. Startup
DB 서비스 시작 후, 일관성이 유지된 상태에 도달했을때에도 Savepoint 가 수행된다.
2-6. Snapshots
Snapshot 은 일반 Savepoint 와는 다르게 장기적으로 사용하기 위해 보존하는 저장점으로 이 경우, 다음 Savepoint 에 의해 덮어쓰이지 않고 따로 보관된다.
이러한 Snapshot 은 나중에 DB 를 특정 시점으로 복원하는데 사용될 수 있다.
2-7. Reclaim Datavolume
사용되지 않는 공간을 회수하는 RECLAIM DATAVOLUME 을 수행하면, 지속성이 해제되므로 정기적으로 Savepoint 가 트리거된다.
3. Savepoint 이력 및 정보 확인
-
M_SAVEPOINTS : 개별 Savepoint 에 대한 자세한 정보
-
M_SAVEPOINT_STATISTICS : HANA Host 및 서비스별 Global Savepoint 정보
-
M_SERVICE_THREADS : Threads 테이블에서도 THREAD_TYPE = 'PeriodicSavepoint' 필드값으로 Savepoint 세부정보를 확인할 수 있다.
4. Savepoint 추가 정보
4-1. Savepoint - Blocking Phase (Lock)
Savepoint 작업은 온라인 중에 수행되며 작업 수행 중에는 Lock 이 필요하지 않지만, 작업 종료 단계에서 ConsistentChangeLock(이하 CCL) 이 필요하다.
일관성을 유지하기 위해 Savepoint - Blocking Phase 에서는 Savepoint 에서만 ConsistentChangeLock(CCL) 을 가져야 한다.
Savepoint 가 CCL 을 획득하면 다른 모든 신규 수정 요청은 Savepoint 가 잡은 CCL 에 의해 차단된다.
이때의 단계를 Blocking Phase 라 하는데, 이 단계는 세가지 주요 하위단계로 구성된다. (Blocking Phase 는 일반적으로 1~2초 이내에 완료된다.)
◾ Blocking - waitForLock
CCL 을 가져오기 위한 대기, CCL 을 획득하면 다음 waitForFlush 단계로 진행
◾ Blocking - waitForFlush
CCL 획득 후, CCL 획득 이전의 Non-blocking 단계에서 트리거된 모든 I/O 가 Disk 에 성공적으로 Flush 될 때까지 대기
CCL 이전의 모든 I/O 가 Disk 에 성공적으로 Flush 되면 다음 critical 단계로 진행
◾ Blocking - critical
Savepoint 에서 모든 CCL 을 잡으면, Savepoint 는 수정된 메모리를 디스크에 일관되게 Flush 한다.
이 단계 동안 다른 트랜잭션은 테이블에서 변경을 수행할 수 없다. (CCL 에 의해서 차단됨)
4-2. 장기 실행 Savepoint 영향도
Delta Merge 가 300초(savepoint_interval_s 기본값) 이상 수행되면, waitForLock 단계에서 CCL 을 잡지 못해 다음 Savepoint 가 차단될 수 있다.
Savepoint 의 Blocking Phase 에서는 다른 모든 수정 작업을 차단해야하기 때문이다.
또한, 디스크가 가득 찼거나, I/O 성능에 문제가 있는 경우에는 시스템이 중단되거나 행 상태에 빠질 수 있다.
따라서, DB 시스템에서 테이블이 얼마나 큰지, Delta Merge 는 일반적으로 얼마나 오래 수행되는지, Savepoint 작업 수행에 얼만큼의 시간이 소요되지는지 등등을 알아둬야 한다.
이에 대한 정보는 시스템 모니터링 뷰를 통해서 쉽게 확인할 수 있다.
또는, SAP SQL 구문 모음집의 Minicheck 를 통해서도 잠재적이거나 심각한 이슈에 대해서 파악이 가능하다.
- Check ID : M0346~ M0359, M0380 ~ M0387, M1830
4-3. 높은 부하에서의 Savepoint 개선
앞선 설명들로 Savepoint - Blocking Phase 를 최대한 줄이는 것은 중요하다.
그러나 마이그레이션, 대량 데이터 임포트, 대량의 테스트 데이터 셋트 생성 등등의 높은 부하(I/O Overhead) 예상되는 특수한 상황에서는 일반적인 Savepoint 동작보다는 더 짧은 기간의 Savepoint 를 가지도록 설정하는 것이 유리할 수 있다.
SAP HANA 의 기본동작으로 Savepoint 의 Blocking Phase 기간을 최대한 줄이기 위해 Savepoint 기간이 위험 한도를 초과하지 않을 것으로 예상되는 경우에만 Blocking Phase 단계로 들어가게 된다.
다음 파라미터를 통해서, Blocking Phase 단계에 대한 최적화가 가능하다.
-
global.ini -> [persistence] -> savepoint_max_pre_critical_flush_duration
Blocking Phase 단계의 기간을 최적화하기 위해 사용되는 최대 시간(s)
Default : 900 (s) -
global.ini -> [persistence] -> savepoint_pre_critical_flush_retry_threshold
예상 Blocking Phase 단계의 수행 상한 설정(ms)
Default : 3000 (ms)
5. Snapshot
SAP HANA 에서는 여러 유형의 Snapshot 을 제공하는데, 여기서는 유용한 두가지 유형만 기록한다.
5-1. Fallback Snapshots
운영 중인 DB 의 상태를 빠르게 복원하기 위해, 수동으로 생성하는 대체 Snapshot
다음 명령어로 Fallback Snapshot 을 생성할 수 있다.
ALTER DATABASE <DB_SID> CREATE FALLBACK SNAPSHOT
나중에, 해당 스냅샷을 사용하여 DB 를 복원할 수 있다.
ALTER SYSTEM START DATABASE <DB_SID> FROM FALLBACK SNAPSHOT
5-2. Secondary (System) Time Travel Snapshots
이번 기능은 메인 DB(Active) 에서 실수 또는 오동작으로 삭제된 데이터에 대해서 Replication 으로 묶여있는 보조 시스템을 활용하여 삭제된 데이터를 확인할 수 있는 방법이다.
Tiem Travel 을 사용하여 실제로 보조 시스템을 복구하는 방법은 아래 별도의 포스트에서 다루며, 여기에서는 Time Travel Snapshot 간격과 보존기간 설정에 대해서만 기록한다.
Time Travel 을 위한 설정과 수행은 아래 포스트를 참조하기 바란다.
다음 파라미터를 통해서, Secondary Time Travel Snapshot 의 간격을 설정할 수 있다. (단위 m)
global.ini -> [system_replication] -> timetravel_snapshot_creation_interval
또한, 다음 파라미터를 통해서, 해당 Snapshot 의 보관기간을 설정할 수 있다. (단위 m)
global.ini -> [system_replication] -> timetravel_max_retention_time
