1. © 2009 CUBRID Co, Ltd. All rights reserved.
Chapter 1. 개발환경구성 3주차
기술본부
2013.03.29
1

2. © 2009 CUBRID Co, Ltd. All rights reserved.
목차
1.현실적 시스템 성능저하 주요 원인
2.시스템 성능관리
3.오라클 성능 분석 체크리스트
별첨. 금주 세미나자료

3. © 2009 CUBRID Co, Ltd. All rights reserved.
0. W 차장은 이렇게 일한다.(큐브리드는 어떻게 일하는가?)
요새 고민은 어떻게 피드백을 빨리 할까 입니다. 빠른 피드백의 장단점이 있겠지만 단점은 어떻게 보완 할 것인지 고민입니다.
그래도 피드백이 늦어져서 하지 말아야 할 일을 반복 하는 것 보다는 낳으니까요.
1 2
피드백(feedback, 되먹임, 되알
림, 환류, 송환)은 어떤 일로 인
해 일어난 결과가 다시 원인에
영향을 미치는 자동 제어 원리이
다.
증가된 출력을 더 증가시키는 양
성 피드백(positive feedback)과
증가된 출력을 감소시켜 다시 안
정한 상태로 되돌리는 음성 피드
백(negative feedback)으로 나눌
수 있다.
[출처] 위키페디아 -
http://ko.wikipedia.org/wiki/%ED%94%BC%EB%93%9C%EB%B0%B1

4. © 2009 CUBRID Co, Ltd. All rights reserved.
1. 현실적 시스템 성능저하 주요 원인
일반적인 소프트웨어 프로젝트 중 전체 시스템의 성능저하의 주요 원인은 다음과 같으며 대부분의 경우 DB와 관련된 이슈가 대다수임.
DB근간 시스템에서의 성능저하 주요 원인
• 대부분의 성능저하 주요인은 DB관련 비효율
• 성능저하의 핵심은 CPU/Memory 부하가 아닌 비 효율적인 I/O
• 당사의 수많은 성능개선 컨설팅 경험에 비추어 90% 이상이 DB처리 효율화가 핵심
– RDB에 적합한 최적화 DB Design과 Optimizer가 최고의 효율을 낼 수 있는 옵티마이징 전략과 집합개념의 고성능 SQL이 성공의
열쇠
20%
DB Config. Design
15%
5%
Applications &
DB Design
70%
CPU 부하 15%
Memory 부하
10%
기타
5%
I/O 비효율
70%
시스템 성능저하의 요인
DB설계의 문제와 응용프로그램 문제로
인한 성능저하 요인
System Design
H/W Resources
※ 별첨4. 튜닝워크샵교재v1_20040712.ppt 참고

5. © 2009 CUBRID Co, Ltd. All rights reserved.
2. 시스템 성능관리
구축 및 운영 System이 최적의 자원으로 최적의 성능(시간/응답속도)을 발휘할 수 있도록 설계와 구현 응용시스템을 조화롭게 유지 개
선하는 기술
• Key factor base on Performance
• H/W Related Issues
– CPU , Memory , N/W , Disk … System config resources 부족
• S/W Related Issues
– DBMS
• DB Design , Index Design , Optimizing Strategy , SQL 효율 …
– Application Architecture
• 2-Tire , 3-Tier , EJB …
• OLTP , OLAP(adhoc) , Batch …
• C , COBOL , PL/SQL , JSQL , SP …
• Business Process Requirement
– 업무 처리 방식의 문제 등
– Load Balancing 정책 등
※ 별첨4. 튜닝워크샵교재v1_20040712.ppt 참고
별첨2. 퍼포먼스 강의 자료
_(Unix Performane
Management)

6. © 2009 CUBRID Co, Ltd. All rights reserved.
• 오라클 성능 분석 체크리스트
3. 오라클 성능 분석 체크리스트
순서 구분 체크리스트 검토 사항 및 권고 사항
1
설계
DB 설정이 최적화 되어 있는지 검토 OLTP,DSS에 맞게 셋팅 되어 있는지
2 테이블스페이스 설계가 I/O분산이 적절히 되도록 검토 TABLE과 INDEX는 테이블스페이스 분리 할것
3 오라클 메모리 설정이 최적화 되어 있는지 검토 가용메모리의 70~80% 셋팅 현재 1.2G -> 4G로 올릴것
4 물리 설계가 최적화 되어있는지 ( 파티셔닝, IOT) 검토 응용과 Data Access Path 에 의해 결정
5 인덱스 설계가 최적화 되어 있는지 검토 응용과 Data Access Path 에 의해 결정
6
서버튜닝
메모리 구조 튜팅( Buffer Cache, Large-Pool, Log Buffer , PGA ) Buffer Cache 4G , Large 20M, PGA 1G
7 CBO Opitmizer일 경우 통계 데이터 Analyze는 충분히 샘플링 되는지 검토 잘됨
8 Disk I/O를 분산하도록 설정이 되어 있는지 SAME으로 구성할 것을 권장함
9
SQL
Access Path가 최적화 되어 있는지 검토 대부분은 잘되어 있음
10
Join Method는 옵티마이저가 업무 성격에
맞게 생성 되는지 검토( Nested Loop, Sort Merge , Hash Join)
11 NL 조인시 선행 테이블을 잘 선정하여 Access Path가 최적화 되는지 검토
12
응용
소프트 파싱을 하기 위한 데이터 바인딩을 하고 있는지 검토 prepareStatement 를 사용하여 바인딩 할것
13 부하를 줄이기 위한 응용 설정이 최적화 되어 있는지 검토
타 DBMS의 경우 다음과 같은 분석 체크리스트가 존재하며 CUBRID 분석 체크리스트도 만들 필요가 있음.

7. © 2009 CUBRID Co, Ltd. All rights reserved.
4. CUBRID 지식 분류체계 案
CUBRID 지식 분류체계 案

8. © 2009 CUBRID Co, Ltd. All rights reserved.
5. 역할별 튜닝 접근 Approach
시스템 성능 문제 발생시 역할별 튜닝 접근 방법은 다음과 같을 수 있습니다. 물론 쉬운 방법도 어려운 방법도 있습니다. 개발 단계별 접
근 방법도 분류해 볼 수 있는 방법이라고 생각합니다.
1.OS자원의
튜닝
2.인스턴스 튜닝
3.어플리케이션의 튜닝
4.오브젝트의 튜닝
5.SQL 튜닝
6.DB 설계 변경(튜닝)
7.Architecture 변경
SE
DBA
개발자, SE
DBA, 개발자
DBA
DBA, 개발자
개발자, DBA, SE

9. © 2009 CUBRID Co, Ltd. All rights reserved.
6. 지식공유(Top down Approach) 1/2
퇴근시간
TV드라마 시청시간
개인시간
취침시간 출근시간
출근시간

10. © 2009 CUBRID Co, Ltd. All rights reserved.
6. 지식공유(Top down Approach) 2/2
쉬는날 평일평일