Tibero DBMS 관련 용어 및 분석
1. DB Memory Size
- Shared Memory Size
- 의미 : 전체 TSM(Tibero Shared Memory) 사이즈
- 분석 : 사이즈가 클수록 성능이 좋다.
- Shared Pool Size
- 의미 : Shared Pool Memory 크기를 의미한다. Physical Plan, Data Dictionary 정보를 Working Thread 간 공유하기 위해 쓰이는 메모리 영역의 크기
- 분석 : 사이즈가 클수록 성능이 좋지만, 전체 TSM 크기 내에서 Shared Pool, Buffer Cache, Redo Log Cache의 크기를 조율해야 하기 때문에 적절하게 크기를 조절해주어야 한다.
[사이즈가 작을 경우; 적재 가능한 DD/PP가 적다. → 디스크 I/O 증가 → 성능 감소]
[사이즈가 클 경우; 적재 가능한 DD/PP가 많다. → 디스크 I/O 감소 → 성능 향상]
- DB Cache Size (= Buffer Cache Size)
- 의미 : DB Buffuer Cache의 크기, 디스크로부터 읽어들인 데이터 블록을 담고 있는 버퍼
- 분석 : 크기가 클수록 성능이 좋다.
[사이즈가 작을 경우; 적재 가능한 데이터 블록의 수가 적다 → Hit율 감소 & 디스크 I/O 증가 → 성능 감소]
[사이즈가 클 경우; 적재 가능한 데이터 블록의 수가 많다. → Hit율 증가 & 디스크 I/O 감소 → 성능 향상]
- Log Buffer Size (= Redo Log Buffer Size)
- 의미 : Redo Log Buffer Cache의 크기로, DML에 의한 변경 사항을 저장하고 있는 Redo Log Buffer
- 분석 : 크기가 클수록 성능이 좋다.
[사이즈가 작을 경우; LGWR에 의해 디스크에 많이 쓰인다. → 디스크 I/O 증가 → 성능 감소]
[사이즈가 클 경우; LGWR에 의해 디스크에 적게 쓰인다. → 디스크 I/O 감소 → 성능 향상]
- DB Block Size
- 의미 : 데이터베이스 블록 크기
- 분석 : 적절한 크기 설정이 필요하다.
[사이즈가 작을 경우; 여러 블록에 데이터가 쪼개서 저장 → 데이터 단편화 증가 → 디스크 I/O 증가 → 성능 감소]
[사이즈가 클 경우; 하나의 블록에 데이터 저장 가능 → 데이터 단편화 감소 → 디스크 I/O 감소 → 성능 향상 (but, 공간 낭비가 발생할 수 있다. 조각화 문제]
2. SGA Stat
- Buffer Cache Hit Ratio
- 의미 : DB Buffer Cache 에서 원하는 데이터를 찾은 비율
- 분석 : 높을수록 성능이 좋은 것
[Hit율이 높은 경우; 메모리에서 원하는 데이터를 많이 찾음 → 디스크 I/O 감소 → 성능 향상]
[Hit율이 낮은 경우; 메모리에서 원하는 데이터를 적게 찾음 → 디스크 I/O 증가 → 성능 감소]
- SQL Cache Hit Ratio
- 의미 : Shared Pool Memory 내의 SQL Cache(PP Cache)에서 SQL Plan을 찾은 비율
- 분석 : 높을수록 성능이 좋은 것
[Hit율이 높은 경우; 메모리에서 원하는 SQL Plan을 많이 찾음 →디스크 I/O 감소 → 성능 향상]
[Hit율이 낮은 경우; 메모리에서 원하는 SQL Plan을 적게 찾음 →디스크 I/O 증가 → 성능 감소]
- Dictionary Cache Hit Ratio
- 의미 : Shared Pool Memory 내의 Data Dictionary에서 원하는 DD 정보를 찾은 비율
- 분석 : 높은수록 성능이 좋은 것
[Hit율이 높은 경우; 메모리에서 원하는 DD 정보를 많이 찾음 →디스크 I/O 감소 → 성능 향상]
[Hit율이 낮은 경우; 메모리에서 원하는 DD 정보를 적게 찾음 →디스크 I/O 증가 → 성능 감소]
- In-Memory Sort
- 의미 : 메모리에서 정렬이 일어난 횟수의 비율(메모리 정렬 수 / 총 정렬 수)
- 분석 : 높은수록 성능이 좋은 것
[높은 경우; 정렬이 메모리에서 많이 일어남 → Temp Tablespace에서 정렬이 적게 일어남 → 디스크 I/O가 적게 일어났다는 것 → 성능 향상]
[낮은 경우; 정렬이 메모리에서 적게 일어남 → Temp Tablespace에서 정렬이 많이 일어남 → 디스크 I/O가 많이 일어났다는 것 → 성능 감소]
- Shared Cache Free Space
- 의미 : Shared Memroy에서 남은 여유 공간의 크기를 의미
- 분석 : 높을수록 성능 측면에서 좋음
[여유 공간이 많다; 낭비되고 있는 메모리 영역이 많다. → 그러나 추후 DD, PP가 적재되어 디스크 I/O가 줄어든다. → 메모리 용량 효율 측면에서는 나쁘지만, 디스크 I/O 측면에서는 좋다.]
[여유 공간이 적다; 낭비되고 있는 메모리 영역이 적다. → 그러나 추후 DD, PP가 적재되어 디스크 I/O가 증가한다. → 메모리 용량 효율 측면에서는 좋지만, 디스크 I/O 측면에서는 나쁘다.]
3. Tablespace Usage
- Tablespace Usage
- 의미 : 전체 테이블스페이스 사용량을 의미
- 분석 : 테이블스페이스 사용량이 90%가 넘으면 디스크 공간이 매우 부족한 상태이기 때문에 디스크 증설, 테이블스페이스 분할, 불필요한 데이터 제거 등의 조치를 취해야 한다. 사용량이 100%가 되면 DBMS가 멈추며 장애가 발생한다.
- Undo Usage Free
- 의미 : Undo 테이블스페이스에서 사용가능한 공간 비율
- 분석 : 클수록 좋다. Undo Segmet가 덮어씌어질 가능성이 낮아지며, 복구 가능성/롤백 가능성이 증가하게 된다. 또한 트랜잭션이 많아 Undo Segment를 모두 사용하게 되어 트랜잭션이 중지될 가능성이 낮다.
- Temp Usage
- 의미 : Temp 테이블스페이스에서 사용중인 공간 비율
- 분석 : 사용량이 낮을수록 좋다. Temp Tablespace 사용량이 낮다는 것은 그만큼 부하가 큰 작업을 수행중인 트랜잭션이 많다는 것이다.
4. Object 점검
- Invalid Object 개수
- 의미 : Invalid Object(정상적으로 컴파일 되지 않은 객체)의 수 점검 ( STATUS='INVALID' )
- 분석 : 적을수록 좋다.
Invalid Object가 있다는 것은 정상적이지 않은 객체가 있다는 것으로, 원인을 파악하고 해결해야 한다. (rebuild, recompile)
- 통계정보수집 점검
- 의미 : 통계정보(Optimizer가 실행계획을 세울 때 참조하는 정보) 수집 확인
- 분석 : 통계정보는 optimizer가 실행계획을 작성할 때 참조하는 정보로 성능 최적화에 영향을 주기 때문에 최신상태를 유지할 수록 좋다.
- NOCYCLE 시퀀스 점검
- 의미 : NOCYCLE 옵션인 시퀀스 중 LAST_NUMBER 값이 MAX_VALUE 90% 이상 도달한 시퀀스의 수를 점검
- 분석 : Nocycle 시퀀스 90% 도달한게 많다는 것은 에러날 확률이 높은 시퀀스가 많다는 것이다. MAX_VALUE를 더 높여주는 등의 조치 필요
- Recyclebin 점검(건수, 사이즈)
- 의미 : Recyclebin 에 저장된 삭제된 Segment의 수와 사이즈 점검
- 분석 : Recyclebin에 DROP된 데이터가 저장된다. Recyclebin을 purge해줘야 디스크에서 완전삭제 되며 purge 전에는 계속 쌓인다. (테이블스페이스 부족한 경우도 내부적으로 삭제됨) 주기적으로 recyclebin을 purge 해줘야 한다.
5. Instance 점검
- Session Usage
- 의미 : 현재 접속한 세션 수 / 인스턴스에 최대로 접속할 수 있는 세션 수
- 분석 : 작을수록 좋다. 현재 접속한 세션의 수가 MAX_SESSION에 가까워 지면 새로운 세션이 불가능하게 되며 에러가 발생할 수 있다.
6. Redo Swtich Stat
- Max Count / Day
- 의미 : 하루 최대 로그 스위치 발생 횟수
- 분석 : Max count가 Avg Count보다 많이 크다면 일별 log swtich 횟수를 확인하고 특정 날짜에 많이 발생한 원인을 파악해야 한다.
- Avg Count / Day
- 의미 : 하루 평균 로그 스위치 발생 횟수
- 분석 : 평균적으로 log switch 수가 크다면 log switch가 적게 일어나도록 redo member의 크기를 증가시키는 등의 조치를 취한다. 수가 작다면 redo member의 크기가 너무 큰건 아닌지 확인하고 사이즈를 줄이는 등 조절할 필요가 있다.
- Avg Size(MB) / Day
- 의미 : 하루 평균 로그 스위치 사이즈
- 분석 : 하루 평균 로그 스위치 수와 함께 봐야 한다.
(1) 로그 스위치 횟수 작으면서 사이즈는 크다면 리두 로그 파일이 매우 커서 로그 스위치가 적은 빈도로 일어나고 있을 가능성이 있다. 한번에 대량의 로그가 디스크에 기록되게 된다. → 리두 로그 멤버의 크기를 감소시키는 등 균형을 맞춰줘야 한다.
(2) 로그 스위치 횟수가 크면서 사이즈가 작다면 리두 로그 파일이 매우 작아서 자주 일어나고 있을 가능성이 있다. 적은 파일의 데이터를 자주 쓰게 되면서 리두 로그 파일을 자주 교체하게 되며 오버헤드 발생 및 성능 저하 가능성이 높다. → 리두 로그 멤버의 크기를 증가시키는 등 균형을 맞춰줘야 한다.
728x90
