2012년 11월 27일 화요일

20121127 점심시간 운동

오랫만에 점심시간에 운동을 했다.

저녁시간에 운동하는 계획을 세웠었는데 지키기가 참 어렵다.

점심시간, 저녁시간 따지지 말고 시간이 나면 운동하자.


스트레칭
  • 팔 스트레칭
  • 다리
  • 반달 자세
  • 다리 자세
  • 물고기 자세
  • 코브라 자세
  • 고양이 자세
  • 낙타 자세
맨손운동
  • 복근운동 상체들기 10회 2 set
  • 복근운동 다리들기 10회 2 set
  • 팔굽혀펴기 5회
한동안 운동을 안했고, 오늘도 갑작스럽게 운동을 결정한거라 귀찮음을 극복하지 못하고 복근운동과 맨손 근력 운동을 부실하게 했다. 

차근차근 횟수를 늘려가자.

트레드밀
  • 6 - 5분
  • 8 - 10분
  • 5 - 3분
달리기는 그럭저럭 예전 만큼 할만했다.

지금 상태를 몇일 더 유지하자.

트레드밀 후 다리 스트레칭

  • 벽 밀기
근력운동이나 다른 운동은 시간 부족으로 못했다.

점심시간에 운동을 하면 앞으로도 이런 패턴일 것 같다.

짧은 시간이라도 열심히 운동하자.


2012년 11월 26일 월요일

실행계획 데이터베이스 튜닝 - 실행계획분석 18

193P

소트 머지 조인

소트 머지 조인의 모든 장점을 제공하면서 소트 머지 조인의 단점까지 어느 정도 보완한 해쉬 조인 사용

소트 머지 조인은 중첩 루프 조인이나 해쉬 조인과 달리 어느 테이블이 먼저 엑세스되고 어느 테이블이 나중에 엑세스되는가는 큰 영향이 없다.

소트 머지 조인은 각 테이블에서 조건에 만족하는 데이터를 추출한 후 조인 조건으로 각 집합을 정렬한다.

정렬된 두 개의 집합에 대해 머지 조인을 수행하고 조인에 실패한 데이터는 버려진다.

정렬에 많은 비용이 발생.

머지 조인 알고리즘이 해쉬 함수에 비해 성능이 보장되지 않음.

대용량일 경우 해쉬 조인, 적은 데이터일 경우 중첩 루프 조인

소트 머지 조인은 조인 SQL의 조인 조건에 인덱스를 이용하지 못할 경우 자주 발생한다.

조인 조건에 인덱스가 없으면 오라클 옵티마이져는 중첩 루프 조인을 선택하지 않는 경우가 많다.


196P

카테시안 조인이 소트 머지 조인과 동일하지는 않으나 실행 계획이 소트 머지 조인 실행 계획의 형식으로 생성된다.

FROM 절의 테이블을 연결할 때 WHERE 절에서 테이블을 연결하는 조인 조건이 없을 경우 카테시안 조인이 발생한다.


199P


CentOS 설치

CentOS-6.3-x86_64-LiveDVD.iso 로 설치

기본과정은 생략

1. 파티션 분할

기본으로 하고 /root의 크기를 줄이고 /home 크기를 늘렸다.


# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_livedvd-lv_root
                       20G  4.5G   15G  24% /
tmpfs                1004M  260K 1004M   1% /dev/shm
/dev/sda1             485M   38M  422M   9% /boot
/dev/mapper/vg_livedvd-lv_home
                       56G  180M   53G   1% /home


2. 네트워크 설정


DEVICE=eth0
BOOTPROTO="none"
IPADDR="xxx.xxx.xxx.xxx"
NETMASK="xxx.xxx.xxx.xxx"
GATEWAY="xxx.xxx.xxx.xxx"
DNS1="168.126.63.1"
DNS2="xxx.xxx.xxx.xxx"
TYPE="Ethernet"
IPV6INIT="no"

IPV6INIT="no" 이 라인을 빼면 에러 메시지가 한 줄 출력된다.


3. 계정생성

useradd -d 홈디렉토리 -s shell 계정명

4. telnet 확인

rpm -qa | grep telnet

아무것도 없는 것을 확인.

5. ssh 설정

기본적으로 설치된다.

vi /etc/ssh/sshd_config

LoginGraceTime 1m
PermitRootLogin no

두 라인 주석 제거 후 service sshd restart

6. 전체 계정 잠금 설정

vi /etc/pam.d/system-auth

auth        required      pam_tally2.so onerr=fail      deny=3  no_magic_root reset
account     required      pam_tally2.so onerr=fail      no_magic_root

두 라인 추가. 서비스를 재시작하지 않아도 바로 적용된다.

7. 잠금 설정을 테스트 하기위해 계정 추가

                                                                                                                                 





2012년 11월 24일 토요일

RedHat vs. CentOS

이번에 가상화를 진행하면서 Solaris를 사용하던 서버들을 Linux로 옮길 계획을 가지고 있었다.

그동안 RedHat이 Windows와 마찬가지로 라이선스 키가 없으면 설치도 안되는 줄 알고 있었는데 확인해보니 설치는 가능하나 라이선스 키가 없으면 패키지를 업데이트 하거나 보안 패치 등을 받을 수 없었다. 물론 기술지원도 받을 수 없다.

곰곰히 생각해보니 yum을 이용한 패키지 설치나 업데이트가 되지 않는다면 너무 번거로울 것 같아 대안으로 CentOS를 고민하게 되었다.

CentOS는 RHEL의 클론으로 무료로 yum을 이용한 패키지 설치나 업데이트가 가능하다.

테스트 서버가 아닌 실제 서버에 오픈소스를 올리는 것이 부담스럽기도 하지만 생각해보면 이미 많은 부분을 오픈소스로 사용하고 있으니 그 부분을 일단 덮어두기로 했다.

2012년 11월 5일 월요일

실행계획 데이터베이스 튜닝 - 실행계획분석 17

174P

해쉬 조인

대용량 데이터의 연결을 해결하기 위한 조인 방법

BUILD 테이블 - PROBE 테이블

180P

해쉬 조인의 성능은

BUILD 테이블의 빠른 해쉬 영역 생성
PROBE 테이블에 대한 최적의 엑세스
BUILD 테이블에 대한 최적의 엑세스

해쉬영역의 크기는 BUILD 테이블에 의해 추출되는 데이터의 건수에 의해 좌우된다.

해쉬 영역의 크기가 크다면 모든 데이터가 메모리에 구성되지 못하고 임시 테이블스페이스를 사용한다.

임시 테이블스페이스는 디스크에 존재한다.

해쉬 영역의 크기가 크다면 디스크에 있는 임시 테이블스페이스에 많이 엑세스해야하고 이는 디스크 I/O의 증가를 의미한다.

결국 BUILD 테이블에서 데이터를 적게 추출하여 해쉬 영역의 크기를 감소시키는 것이 해쉬 조인의 성능을 향상시키는 가장 중요한 항목이다.

PROBE 테이블은 중첩 루프 조인과 달리 조인 조건을 상수로 제공받지 못한다.

이 점이 중첩 루프 조인과 해쉬 조인의 가장 큰 차이점이다.

PROBE 테이블에서 추출되는 데이터가 적으면 인덱스, 많으면 전체 스캔.

전체 스캔인 경우 병렬 프로세싱.

/*+ ORDERED USE_HASH(A, B) PARALLEL(B, 4) */

184P

192P

실행계획 데이터베이스 튜닝 - 실행계획분석 16

150P

DRIVING 테이블 선정 조건

조인 조건을 제외한 WHERE 조건이 없을 경우
1:M 관계의 모델링에서 1에 해당하는 테이블을 DRIVING 테이블로 선정
1:1 관계에서는 어느 테이블이든 DRIVING 테이블이 될 수 있다.
M:N 관계에서는 COUNT 함수를 수행하여 가장 작은 값을 추출하는 테이블을 DRIVING 테이블로 선정해야 한다.

조인 조건을 제외한 WHERE 조건이 있을 경우
각 테이블의 WHERE 조건으로 COUNT 함수를 수행하여 가장 작은 값을 추출하는 테이블을 DRIVING 테이블로 선전해야 한다.

INDEX FAST FULL SCAN /*+ INDEX_FFS(테이블 이름, 인덱스 이름) */ 힌트와 인덱스를 활용

WHERE 조건에 조인 조건만 있고 대용량의 데이터에 엑세스해야 한다면 중첩 루프 조인보다 해쉬 조인을 이용하는 것이 유리

155P

160P

166p

중첩 루프 조인에서는 조인이 수행될 때마다 데이터가 감소하는 경우보다는 데이터가 증가하는 경우에 성능을 보장받을 수 있다.

168P

171P


2012년 11월 2일 금요일

실행계획 데이터베이스 튜닝 - 실행계획분석 15

130P

134P

중첩 루프 조인(NESTED LOOP)

DRIVING 테이블 - 먼저 엑세스 하는 테이블

INNER 테이블 - 뒤에 엑세스 하는 테이블

중첩 루프 조인에서 조인에 참여하는 테이블이 어떤 역할 을 수행하는가에 따라 SQL 최적화를 위한 인덱스가 변한다.

DRIVING 테이블
조건을 만족하는 데이터에 대해 한 번만 엑세스하며 조인 조건을 상수로 제공받지 못한다.

INNER 테이블
DRIVING 테이블에서 추출되는 데이터 건수만큼 반복 수행하며 조인 조건을 상수로 받는다.

----

DRIVING 테이블
실행 계획에서 위에 생성되는 테이블이 DRIVING 테이블의 역할을 수행하며 커리 밤위를 감소시키는 역할로 조인 조건을 사용할 수 없게 된다.
DRIVING 테이블은 조건을 만족하는 데이터에 한 번만 엑세스한다.

INNER 테이블
실행 계획에서 밑에 생성되는 테이블
조인 조건을 처리 범위 감소 조건으로 사용할 수 있다.
DRIVING 테이블에서 추출되는 데이터의 건수만큼 반복 수행하며 조인 조건을 상수로 제공받는다.

----

140P

향상된 중첩 루프 조인

DRIVING 테이블과 INNER 테이블이 1:M의 관계일 때 하나 하나에 대해 랜덤 엑세스를 수행하는 것이 아니라 DRIVING 테이블에서 추출한 값에 대해 INNER 테이블의 인덱스에서 추출되는 여러 건에 대한 한 번에 값을 모아 INNER 테이블에 엑세스한다.

INNER 테이블의 데이터가 정렬되어 저장되어 있다면 몇 개의 블록만 엑세스하여 모든 결과를 추출할 수 있다.

향상된 중첩 루프 조인을 사용하면 INNER 테이블에 엑세스하는 I/O의 횟수를 감소시킬 수 있다.

향상된 중첩 루프 조인이 효과적으로 사용되기 위해서는 클러스터링 팩터가 양호해야 한다.

특정 컬럼으로 데이터가 모여서 저장되어 있는지 아닌지를 클러스터링 팩터라고 한다.

향상된 중첩 루프 조인을 효과적으로 이용하려면 다음의 조건을 만족해야 한다.

1:M 관계의 테이블들에 대한 중첩 루프 조인
1에 해당하는 테이블이 DRIVING 테이블로 수행되며 M에 해당하는 테이블이 INNER 테이블로 수행
M에 해당하는 테이블은 조인 조건에 의해 정렬되어 데이터 저장(조인 컬럼에 의해 M에 해당하는 테이블은 클러스터링 팩터 양호)

----

144P

중첩 루프 조인에서 성능을 좌우하는 항목

INNER 테이블의 효과적인 엑세스
DRIVING 테이블에서 추출되는 데이터 건수
DRIVING 테이블의 엑세스 최적화

----

INNER 테이블의 반복 엑세스를 어떻게 최적화할 것인가? - 최적화된 인덱스

EX) KR-CODE + 거래일자

중첩 루프 조인의 성능 최적화에서 가장 중요한 요소는 INNER 테이블의 반복 엑세스를 최적화 하는 것이다.

INNER 테이블의 반복 엑세스를 최적화하기 위해서는 처리 범위를 최대한 감소시킬 수 있는 인덱스가 선정되어야 한다.

중첩 루프 조인에서 INNER 테이블은 조인 조건을 상수로 제공받고, 일반적으로 조인 조건에서 점 조건을 사용하기 때문에 INNER 테이블의 인덱스 선정은 성능의 핵심이 될 것디다.

INNER 테이블에서 조인 조건과 그외 점 조건으로 인덱스를 구성하고 선분 조건을 인덱스 뒤에 추가하는 것이 가장 효과적이다.

----

DRIVING 테이블의 처리 범위

----


149P

실행계획 데이터베이스 튜닝 - 실행계획분석 14

123p

대용량 테이블에서 3~5% 이상의 데이터를 추출하는 경우 인덱스를 이용하면 처리 범위 및 랜덤 엑세스의 증가로 인해서 엄청난 성능 저하가 발생한다.

이런 경우엔는 테이블 전체 스캔을 고려한다.

테이블 전체 스캔

첫번째 방법은 힌트 /*+ FULL(테이블 이름) +/

두번째 방법은 인덱스 컬럼에 데이터를 변경시키지 않는 함수를 사용

인덱스 컬럼이 함수에 의해 가공되면 해당 인덱스를 이용할 수 없다.

대용량 테이블에서 많은 양의 데이터를 추출할 경우에 테이블을 전체 스캔하는 이유는 랜덤 엑세스 때문이다.

테이블 전체 스캔은 랜덤 엑세스를 제거할 수 있으므로 많은 데이터에 엑세스하는 SQL의 경우에 인덱스를 이용하는 것보다 더 좋은 성능을 보장받을 수 있다.

또한, 테이블 전체 스캔은 다중 블록 I/O를 수행하기 때문에 대용량의 데이터를 추출하는 SQL에 대해서는 인덱스 스캔보다 성능적으로 유리할 수 있다.

126P

기본적으로 오라클에서는 하나의 SQL에는 하나의 프로세스가 기동되어 필요한 데이터에 엑세스한다.

병렬 프로세싱을 이용하면 설정한 개수만큼의 프로세스가 기동하여 작업을 나누어 수행한다.

운영 체제에서 여러 개의 프로세스를 기동하기 위해서는 운영 체제의 자원을 사용해야 한다. 그렇기 때문에 여러 개의 프로세스를 기동시키기 위한 시간이 소요된다. 프로세스를 많이 기동시킬수록 운영 체제의 병렬 프로세스 기동 시간은 증가한다. 따라서, 크기가 작은 테이블에 병렬 프로세싱을 적용하면 테이블에 엑세스하는 시간보다 프로세스를 기동시키는 시간이 더 많이 소요될 수 있기 때문에 성능이 저하될 수 있다.

1GB 이상의 테이블에서 병렬 프로세싱을 이용하는 것이 효과적.

병렬 프로세싱을 사용하기 위한 데이터베이스 파라메터 설정 확인이 필요.

PARALLEL_MIN_SERVER - 시스템에서 사용할 수 있는 최소 병렬 프로세싱 개수

PARALLEL_MAX_SERVER - 최대 병렬 프로세싱 개수

PARALLEL_AUTOMATIC_TUNING - 병렬 프로세싱의 메시지 저장 공간과 병렬 프로세스 사이의 통신을 위한 I/O 단위를 설정

PARALLEL_AUTOMATIC_MESSAGE_SIZE - 병렬 프로세스 사이의 통신을 위한 I/O 크기

----

PARALLEL_AUTOMATIC_TUNING = TRUE/FALSE

TRUE - 병렬 프로세스 사이에 통신을 수행하기 위해 사용하는 메시지는 오라클 메모리 공간 중에서 LARGE POOL 공간을 사용한다.

FALSE - SHARED POOL 공간을 사용

SQL에 대한 파싱 정보를 저장하는 SHARED POOL 영역을 사용한다면 메모리 사용에 비효울이 발생한다.

TRUE로 설정하면 병렬 프로세스 사이에서 통신을 하기 위한 I/O의 크기가 1KB에서 2KB로 변경된다.

128P