Installing and Administering SAP HANA
SAP HANA 소개
가. SAP HANA(High-Performance Analytic Appliance)
○ SAP가 개발한 인메모리(In-Memory) 데이터베이스
※ SAP S/4 HANA(SAP Business Suite 4 SAP HANA) : SAP HANA 데이터베이스 기반 차세대 비즈니스 플랫폼
나. SAP HANA와 기존 DBMS의 차별점
SAP HANA
기존 DBMS
저장 방식
메모리에 데이터 저장
데이터를 디스크에 저장
데이터 구조
열(Column) 기반 저장
행(Row) 기반 저장
성능
데이터 압축과 실시간 분석 최적화
대량의 데이터 처리 지연
저장방식 : 인메모리 DB (SAP HANA) vs. 디스크 기반 DB (기존 DBMS)기존 DBMS는 데이터를 디스크에 저장한다. 반면 SAP HANA는 데이터를 메모리에 저장하여 디스크 I/O 병목 현상을 없애고 빠른 데이터 액세스를 제공한다.
컬럼 기반 저장 vs. 행 기반 저장기존 DBMS는 데이터를 행 단위로 저장한다. 반면 SAP HANA는 컬럼 기반 저장 방식을 사용하여 데이터 압축을 극대화하고, 집계 연산의 성능을 향상시킨다.
라. HANA DB 구조
[데이터 베이스]
○ 시스템 DB(System DB) : HANA System의 전반적인 관리 목적으로 사용되는 DB
○ 테넌트 DB(Tenant DB) : 실제 테이블, 데이터 정보가 저장되는 DB
System DB
Tenant DB
수행 작업
HANA System 모니터링
HANA System 레벨/ DB 레벨 파라미터 설정
DB 생성/삭제,
DB 기능 활성화/비활성화
DB Scaling-out
DB 백업/복원
DB 모니터링
DB 계정 권한 설정
DB스키마/테이블/인덱스 생성 및 삭제
DB 레벨 파라미터 설정
DB 백업
※ 각 데이터베이스에서 수행 가능한 작업
[서 버]
Index Server : Teneant DB에만 존재하는 서버로, Data Store(Row and Column Table)를 보유하며 데이터를 로드하고 쿼리하고 결과를 반환한다.
Name Server : System DB에만 존재하는 서버로, 전체 DB의 Landscape 및 Data Distribution 정보를 알고 있다.
Compile Server : 프로그램과 Procedure를 컴파일하는 서버
Preprocessor : Index Server가 Text data를 분석하기 위해 사용하며 Text Search 기반 정보를 추출한다.
Webdispatcher : HANA DB에 HTTP로 접근하는 것을 처리한다
XSengine : Web(HTTP)으로 접속을 처리하는 Engine 이다.
[디스크 스토리지]
○데이터 볼륨 (Data Volume): 데이터베이스의 특정 시점의 모든 데이터를 저장
○로그 볼륨 (Log Volume): 데이터베이스에서 발생한 변경 사항(SQL문)을 저장
다. 델타 병합(Delta Merge)
☐ HANA DB는 데이터가 압축되어 저장된다. 하지만 DB에서 일어나는 모든 변경사항에 대해서 압축후 디스크에 저장하기에는 많은 비용이 들기 떄문에 변경사항을 Delta Storage로 기록하고 Main Storage와 Delta Storage를 합치는 Delta Merge 작업을 수행하게 된다.
다-1. SAP HANA 데이터 저장소
○ Delta Storage: 쓰기 작업(Write)에 최적화된 저장소로,
메모리 내에서만 존재하며 디스크에는 미저장
○ Main Storage: 읽기 작업(Read)에 최적화된 저장소로,
압축 및 최적화되어 디스크에 저장
다-2. 델타 병합 프로세스
Before Merge
Main Storage와 Delta Storage가 각각 존재.
쓰기 작업은 Delta Storage에서만 수행.
읽기 작업은 Main 및 Delta Storage에서 모두 수행 가능.
During Merge
새로운 Main 및 Delta Storage(Main(2), Delta(2)) 생성.
**Delta(1)**에서 아직 커밋되지 않은 변경사항을 **Delta(2)**로 복사.
기존 **Main(1)**과 **Delta(1)**가 새로운 Main(2)로 병합.
After Merge
Main(1) 및 Delta(1) 삭제.
**Main(2)**가 새로운 Main Storage로 대체.
Main Storage 내용은 디스크에 저장되며, 필요 시 추가 압축 및 최적화 수행
HANA DB 관리
☐ DB 백업
○ 데이터 백업 (Data Backup): 데이터베이스의 특정 시점의 모든 데이터를 저장
○ 로그 백업 (Log Backup): 데이터베이스에서 발생한 변경 사항(SQL문)을 저장
☐ 데이터 백업 방법
○ 풀 백업 (Full Backup): 데이터 전체를 백업하며, 독립적인 복원이 가능하지만 가장 느림.
○ 증분 백업 (Incremental Backup): 풀 백업 이후 변경된 데이터만 백업.
○ 차등 백업 (Differential Backup): 풀 백업 이후 추가된 데이터를 합산하여 백업.
☐ 로그 백업
가. 로그 관리 기본 구성요소
Log Buffer (Redo Log)
역할 : 모든 트랜잭션에 의한 변경사항을 메모리 상에 기록.
작동 방식: Log Buffer가 가득 차거나(Full), Commit 명령이 수행되면, 해당 데이터가 디스크의 Log Segment에 기록된다.
Log Segment (= Log Volume, Log Disk)
정의 : 디스크에 기록된 Log Buffer의 데이터를 저장한 공간.
특징 : 디스크에 존재하기 때문에 비휘발성 데이터를 제공.
Log Backup
사용 조건 : Log Mode Normal을 사용하는 경우에 설정 가능.
필요성 : Log Segment의 재사용을 가능하게 하기 위해 주기적으로 백업. 만약 Log Backup을 사용하지 않으면, Log Volume이 가득 찼을 때 DB가 정지할 위험이 있음.
백업 트리거 :
1). Log Segment가 Full 상태가 될 때.
2). 특정 임계 시간이 초과되었을 때.
3). DB가 시작될 때.
나. Log Mode
SAP HANA 신규 설치 후, 초기 overwrite 모드로 수행된다.이 후, 첫 Full Data Backup 을 수행하면 자동으로 기본 모드인 Normal 로 전환되고 로그 백업이 수행된다.
○ Normal Mode: 로그 백업이 정기적으로 수행되며, Time-Based Recovery 지원.
○ Overwrite Mode: 로그 백업이 수행되지 않고 기존 로그를 덮어씀. 임시 시스템에 적합.
다. Log Volume Full 이슈
대규모 변경작업이 있거나, 마이그레이션시 등등 Log Segment 가 쌓이는 속도가 빨라지면 Log Volume이 Full 될 수도 있다. 이때, DB는 더 이상 처리와 응답을 할 수 없게 된다.
다-1. Log Volume Full 이슈 해결방법
○로그 공간의 디스크를 증설하여 여유 공간 확보
○(권고) 사전 생성한 더미 파일 삭제로 공간 확보.
☐ DB 복구
(A) 가장 최근 상태로 복구
(B) 특정 시점으로 복구
(C) 특정 데이터 백업으로 복구
사용
데이터
가장 최근의 데이터 백업
데이터 백업 이후 생성된 로그 백업
로그 영역
지정된 시점 이전의 마지막 데이터 백업
데이터 백업 이후 생성된 로그 백업
로그 영역
지정된 데이터 백업
Cockpit을 통한 DB 모니터링
☐ HANA 모니터링 툴
SAP HANA Cockpit
SAP HANA Studio
커맨드 라인 인터페이스
주요기능
SAP HANA 시스템의 중앙 집중식 관리
사용자 및 권한 관리
백업 및 복구
고가용성 관리
다양한 관리 앱 제공
데이터베이스 모니터링 및 문제 해결
SQL 콘솔 제공
Eclipse 기반 Java IDE 플러그인
시스템 시작/중지
상태 및 버전 확인
유지 관리 및 설정
모든 구성 작업(SQL 문 기반)
특징
GUI 기반으로 직관적이며 다양한 설치 옵션 제공
기능 감소 중이나 SQL 콘솔 활용 가능
GUI 미제공으로 복잡하지만 강력한 관리 도구
지원상태
최신 관리 도구
2025년까지 최소 지원 예정
병행 사용 권장
☐ 성능 모니터링
시간 경과에 따른 SAP HANA 데이터베이스의 성능을 분석하면 메모리, 디스크 및 CPU 사용량과 관련된 다양한 주요 성능 지표에서 과거 성능 데이터를 시각적으로 분석할 수 있다.
○CPU 부하 시 인덱스 서버 연관성 간접 확인 가능
CPU 부하 시 인덱스 서버로 인한 원인인지 확인이 어렵다. 그때 성능 모니터링을 통해 CPU와 INDEX 서버가 같이 상승한다면 INDEX 서버가 CPU 부하에 영향을 주었다고 간접적으로 확인 할 수 있다.
※ 직접적으로 확인 원한다면 NMON (Linux Server 운영 시 5분마다 서버 성능치를 모니터링하고 분석 할 수 있는 모니터링 툴) 사용 권고
○DBCP(DataBase Connection Pool) 모니터링
클라이언트와 웹 어플리케이션에서, 많은 사용자가 요청에 따라 Connection이 생성된다면 서버에 과부하가 걸리게 된다. 이를 예방하기 위해 미리 일정 갯수의 Connection을 만들어 Pool에 저장을 하고, 사용자의 요청이 발생하면 Connection을 제공하고 사용자와의 연결이 종료된다면 Pool에 다시 반환하여 보관하는 것을 의미한다.
미리 설정된 Pool을 초과하는 요청이 들어오면 DB에 남는 Pool이 생길 때까지 대기하게 되고 이에 따라 지연이 발생하게 된다. 이를 사전에 모니터링하며 Connection Pool 크기 조절과 Connection 재활용 및 최적화하는 것이 필요하다.
모니터링 지표
○ Active Connection 수
○ Idle Connection 수
○ Connection 대기 시간
○ Connection 생성 및 반환 속도
(1) Connection Pool 크기 조절
Pool의 **최대 Connection 개수(maximum pool size)**를 적절히 설정해야 한다.
과소 설정: 요청 대기 시간이 증가하여 성능 저하
과다 설정: 메모리 및 CPU 과부하로 서버 성능 저하
설정 기준
○ 데이터베이스의 최대 연결 허용치 확인
○ 애플리케이션의 평균/최대 동시 사용자 수 파악
○ 메모리와 CPU 성능 분석
○ 모니터링 도구를 통해 Active Connection 개수와 대기 시간 분석
○ 점진적으로 Pool 크기를 늘리며, Active Connection 개수가
최대치 내에서 유지되도록 조정
(2) Connection 재활용 및 최적화
애플리케이션이 사용한 Connection을 반환하지 않아 Connection Leak가 발생한 경우라면 아무리 Connection Pool의 개수를 늘린다고 해도 해당 현상을 해결할 수 없다. 이 경우 DB Active 개수는 우상향 그래프를 그리게 된다. Connection Leak을 막기 위해서는 사용한 Connection 사용 후 명시적으로 반환하도록 설정하거나 재사용하는 방식을 적용해 볼 수 있다.
Connection Leak 방지
○ 사용 후 Connection을 명시적으로 반환하도록 코드를 작성
○ 미사용 Connection 강제 반환 설정
Idle Connection 최적화
○ 일정 시간 동안 사용되지 않는 Connection을 Pool에서 제거
○ idleTimeout, maxIdle 같은 설정 사용
쿼리 성능 최적화
○ 필요 이상의 Connection 할당 방지
○ 자주 사용하는 쿼리는 Prepared Statement로 캐싱
☐ 테이블 사용량 모니터링
☐ DB 장애분석
○ DB 장애시 SAP 지원팀이 시스템의 문제점을 분석하고 진단하는데 도움이 되도록 시스템에서 진단 정보를 ZIP 파일로 수집가능
※ OS 접속은 되지만 DB 접속이 안되는 경우 사용
암호화
☐ 암호화
○ API방식 : 암/복호화 과정이 프로그램 단에서 수행되는 방식 →암호화 적용에 공수 필요
○ Plug-In방식 : DB서버에서 플러그인으로 연결된 암복호화 모듈을 호출하는 방식 →모든 암/복호화 과정이 데이터베이스에서 테이블의 일부 또는 ‘특정 조건에 따라 필터링된 데이터만’을 포함하는 ‘가상 테이블’
뷰(View)를 통해 이루어져 성능 저하
○ Kernel방식 : DB 내부에서 데이터파일 저장 시 암호화하고 메모리영역으로 가져올때 복호화하는 방식
→ DB내에서 암복호화 진행하여 구축에 용이
출처 : KISA 개인정보 암호화 조치 안내서(2020.12)
