http://moss.tistory.com/150

들어가며

Redis 서버 설정을 위해서 작성하는 redis.conf 파일에 대해서 정리한다.
오역 및 잘못된 내용이 있을 수 있습니다. 참고 용로도만 사용해 주세요.
대상 파일: https://raw.github.com/antirez/redis/2.4.15/redis.conf

요약

기본설정

1. daemonize (daemon으로 실행 여부 설정)
2. pidfile (daemon 실행시 pid가 저장될 파일 경로)
3. port (접근을 허용할 port 설정)
4. bind (요청을 대기할 interface[랜카드] 설정)
5. unixsocket, unixsocketperm (요청을 대기할 unix 소켓 설정)
6. timeout (client와 connection을 끓을 idle 시간 설정)
7. loglevel (loglevel 설정)
8. logfile (log 파일 경로 설정)
9. syslog-enabled (system logger 사용 여부 설정)
10. syslog-ident (syslog에서의 identity 설정)
11. syslog-facility (syslog facility 설정)
12. databases (database 수 설정)

REPLICATION

1. slaveof (master server 설정)
2. masterauth (master server 접근 비밀번호 설정)
3. slave-server-stale-data (master와 connection이 끊긴 경우 행동 설정)
4. repl-ping-slave-perid (미리 정의된 서버로 PING을 날릴 주기 설정)
5. repl-timeout (reply timeout 설정)

SECURITY

1. requirepass (server 접근 비밀번호 설정)
2. rename-command (command 이름 변경)

LIMITS

1. maxclients (최대 client 허용 수 설정)
2. maxmemory (최대 사용가능 메모리 크기 설정)
3. maxmemory-policy (maxmemory 도달 시 행동 설정)
4. maxmemory-samples (LRU 또는 mnimal TTL 알고리즘 샘플 수 설정)

APPEND ONLY MODE

1. appendonly (AOF 사용여부 설정)
2. appendfilename (AOF 파일명 설정)
3. appendsync (fsync() 호출 모드 설정)
4. no-appendfsync-on-rewrite (background saving 작업시 fsync() 호출 여부 설정)
5. auto-aof-rewrite-percentage, auto-aof-rewrite-min-size (AOF file rewrite 기준 설정)

SLOW LOG

1. slowlog-log-slower-than (slow execution 기준 설정)
2. slowlog-max-len (최대 저장 slow log 수 설정)

VIRTUAL MEMORY

1. vm-enabled (vm 모드 사용여부 설정)

ADVANCED CONFIG

1. hash-max-zipmap-entries, hash-max-zipmap-value (hash encode 사용 기준 설정)
2. list-max-ziplist-entries, list-max-ziplist-value (list encode 사용 기준 설정)
3. set-max-intset-entries (set encode 사용 기준 설정)
4. zset-max-ziplist-entries, zset-max-ziplist-value (sorted set encode 사용 기준 설정)
5. activerehashing (자동 rehashing 사용 여부 설정)

기본설정

daemonize [boolean] (기본값: no)

Redis는 기본적으로 daemon으로 실행하지 않는다. 만약 Daemon으로 실행하고 싶다면 'yes'를 사용해라.
Redis는 daemon으로 실행될 때 '/var/run/redis.pid' 파일에 pid를 기록할 것이다.

예) daemonize no

pidfile [file path] (기본값: /var/run/redis.pid)

daemon으로 실행 시 pid가 기록될 파일 위치를 설정한다. 값이 설정되지 않으면 '/var/run/redis.pid'에 pid를 기록한다.

예) pidfile /ver/run/redis.pid

port [number] (기본값: 6379)

Connection을 허용할 Port를 지정한다. 기본값은 6379이다.
만약 port 값을 0으로 지정하면, Redis는 어떤 TCP socket에 대해서도 listen하지 않을 것이다.

예) port 6379

bind [ip] (기본값: 모든 인터페이스)

Redis를 bind 할 특정 interface(랜카드)를 지정할 수 있다. 만약 명시하지 않으면, 모든 interface로부터 들어오는 요청들을 listen할 것이다.

예) bind 127.0.0.1

unixsocket [path], unixsocketperm [number] (기본값: 없음)

들어오는 요청을 listen할 unix socket의 결로를 지정한다. 이 설정에는 기본 값이 없다. 따라서 값이 지정되지 않으면 unix socket에 대해서는 listen하지 않을 것이다.

예) unixscoket /tmp/redis.sock
예) unixsocketperm 755

timeout [second]

client의 idle이 N 초 동안 지속되면 connection이 닫힌다. (0으로 지정하면 connection이 계속 유지된다.)

예) timeout 0

loglevel [level]

logl evel 을 지정한다. Log level 에는 아래 4가지 중 하나를 지정할 수 있다.

예) loglevel verbose

logfile [file path]

로그 파일을 명시한다.'stdout'로 Redis가 the standard output에 로그를 기록하도록 할 수 있다. 만약 'stdout'를 명시했으나 Redis가 daemon으로 동작한다면 로그는 /dev/null logfile stdout 로 보내질 것이다. 따라서 로그가 남지 않을 것이다.

예) logfile stdout

syslog-enabled [boolean]

system logger를 사용해서 logging 할 수 있게 한다. 단지 'yes'로 설정하고 추가적 설정을 위해서 다른 syslog parameter들을 설정할 수 있다.

예) syslog-enabled no

syslog-ident [identity]

syslog identity를 지정한다.

예) syslog-ident redis

syslog-facility [facility]

syslog facility(시설)을 지정한다. 반드시 USER 또는 LOCAL0 - LOCAL7 사이 값이 사용되어야 한다.

예) syslog-facility local0

databases [size]

dababase들의 숫자를 설정한다. 기본 dababase는 DB 0이다. 물론 connecton당 'SELECT <dbid>' 사용해서 다른 database를 선택할 수 있다. dbid는 0 과 'database 수 - 1'사이의 수이다.

예) databases 16

SNAPSHOTTING (RDB 지속성 설정)

save [seconds] [changes]

disk에 DB를 저장한다. DB에서 주어진 값인 seconds와 changes를 모두 만족시키면 DB를 저장 할 것이다.
이 설정은 여러번 설정할 수 있다.

아래는 예제를 설명한 것이다.
900초(15)분 동안에 1개 이상의 key 변경이 발생했다면 DB를 저장한다.
300초(5)분 동안에 10개 이상의 key 변경이 발생했다면 DB를 저장한다.
60초(1)분 동안에 10000개 이상의 key 변경이 발생했다면 DB를 저장한다.
실제 서비스에서는 너무 자주 동기화가 일어나게 설정하면 안된다.

주목: DB를 저장하고 싶지 않으면 모든 save 라인들을 주석 처리한다.

예) save 900 1
예) save 300 10
예) save 60 10000

rdbcompression [boolean] (기본값: yes)

.rbd database를 덤플 할 때 LZF를 사용해서 문자열 부분을 압축할지 설정한다.
압축하는 것은 대부분의 경우 좋기 때문에 기본값은 'yes'이다.
만약 child set을 저장할 때 CPU 사용을 절약하고 싶다면 'no'로 설정한다. 하지만 values 또는 keys가 압축이 가능했다면, dataset은 보다 커질 것이다.

예) rdbcompression yes

dbfilename [file path]

DB가 dump될 파일을 설정한다.

예) dbfilename dump.rdb

dir [directory path]

DB가 기록될 디렉토리를 설정한다. DB dump파일은 위의 dbfilename과 함께 최종적으로 파일이 기록될 곳이 지정된다.
Append Only File 또한 이 디렉토리에 파일을 생성할 것이다.
반드시 여기에 디렉토리를 설정해야 한다. file name에 설정하면 안 된다.

예) dir ./

REPLICATION (복제 셋 구성 설정)

slaveof [masterip] [masterport]

Master-Slave replication을 구성하기 위해서 slaveof를 사용한다. 이것은 Redis instance가 다른 Redis server의 복사본이 되게 한다.
slave에 대한 설정은 local에 위치한다. 따라서 slave에서는 내부적으로 따로 DB를 저장 하거나, 다른 port를 listen하는 등 slave만의 설정이 가능하다.

예) slaveof 127.0.0.1 6379

masterauth [master-password]

만약 master에 password가 설정되어 있다면 replication synchronization(복제 동기화) 과정이 시작되기 전에 slave의 인증이 가능하다. (이것은 "requirepass" 설정으로 가능하다). 만약 password가 틀리다면 slave의 요청은 거절될 것이다.

예) masterauth password1234 

slave-server-stale-data [boolean] (기본값: yes)

만약 slave가 master와의 connection이 끊어 졌거나, replication이 진행 중일 때는 아래의 2가지 행동을 취할 수 있다.

1. 'yes(기본값)'로 설정한 경우, 유효하지 않은 data로 client의 요청에 계속 응답할 것이다. 만약 첫번째 동기화 중이였다면 data는 단순히 empty로 설정될 것이다.
2. 'no'로 설정한 경우, INFO와 SLAVEOF commad(명령)을 제외한 모든 command들에 대해서 "SYNC with master in progress" error로 응답할 것이다.

예) slave-server-stale-data yes

repl-ping-slave-perid [seconds] (기본값: 10)

Salve가 내부적으로 미리 정의된 server로 지정된 시간마다 PING을 보내도록 설정한다.

예) repl-ping-slave-perid 10

repl-timeout [seconds] (기본값: 60)

'bulk transfer I/O(대량 전송 I/O) timeout'과 'master에 대한 data또는 ping response timeout'을 설정한다.

이 값은 'repl-ping-slave-period' 값 보다 항상 크도록 설정되어야 한다. 그렇지 않으면 master와 slave간 작은 traffic이 발생할 때 마다 timeout이 인지될 것이다.

예) repl-timeout 60

SECURITY (보안 설정)

requirepass [password]

client에게 다른 command들을 수행하기 전에 password를 요구하도록 설정한다. 이것은 redis-server에 접근하는 client들을 믿을 수 없는 환경일 때 유용한다.

반대로 개방적으로 사용하기 위해서는 주석 처리 되어야 한다. 왜냐하면 대부분의 사람들은 auth가 필요하지 않기 때문이다.

주의: Redis는 매우 빠르기 때문엔 좋은 환경에서는 외부 사용자가 1초 당 15만개의 password를 시도할 수 있다. 따라서 매우 강력한 password를 설정해야 한다.

예) requirepass foobared

rename-command [target-command] [new-command]

Commnad renaming

공유되는 환경에서는 위험한 command들의 이름을 변경할 수 있다. 예를 들어서 CONFIG command를 추측하기 어려운 다른 값으로 변경할 수 있다. 물론 internal-use tool로는 해당 명령어가 사용하지만, 일반적인 외부 client들에 대해서는 불가능하다.

예) rename-command CONFIG b840fc02d524045429941cc15f59e41cb7be6c52

또한 command를 공백으로 rename해서 완전히 사용 불가능하게 할 수도 있다.

예) rename-command CONFIG ""

LIMITS (접속 및 메모리 설정)

maxclients [size] (기본값: 제한 없음)

한번에 연결될 수 있는 최대 client 수를 설정한다. 기본값은 제한이 없으나, Redis process의 file descriptor의 숫자만큼 연결가능하다. 특별히 '0' 값은 제한 없음을 의미한다.
limit에 도달했을 때 새로운 connection들에 대해서는 'max number of clients reached' error를 전송한고 connection을 close 한다.

예) maxclients 128

maxmemory [bytes]

명시한 bytes의 양보다 많은 메모리를 사용하지 말아라.
memory가 limit에 도달했을 때 Redis는 선택된 eviction policy(제거 정책)(maxmemory-policy)에 따라서 key들을 제거할 것이다.

만약 Redis가 eviction policy에 의해서 key를 제거하지 못하거나 polict가 'noeviction'으로 설정되어 있다면, SET, LPUSH와 같이 메모리를 사용하는 command들에 대ㅐ서는 error를 반환하고, 오직 GET 같은 read-only command들에 대해서만 응답할 것이다.

주의: maxmoery 설정 된 instance에 slave가 존재 할 때, slave에게 data를 제공하기위해서 사용되는 output buffer의 size는  used memory count에서 제외된다. 왜냐하면 network 문제나 재동기화가 keys들이 제거된 loop에 대한 trigger를 발생시키지 않게 하기 위해서이다. loop가 발생하면 slave의 output buffer가 제거된 key들의 DEL 명령으로 가득 찰 것이다. 그리고 이것은 database가 완전히 빌 때 까지 지속된다. (좀 더 정확히 알아볼 필요가 있다. 확실히 이해가 안 됨)

간단히 말하면, 만약 slave를 가진다면, slave output buffer를 위해서 system에 약간의 free RAM이 존재시키기 위해서, maxmoery에 약간 낮은 limit를 설정하는 것이 추천된다. (하지만 policy가 'noeviction'이면 필요하지 않다.)

큰 메모리를 표시하기 위해서 아래와 같이 표기가 가능하다.

예) maxmoery 1000

maxmemory-policy [policy] (기본값: volatile-lru)

MAXMEMORY POLICY: maxmemory에 도달했을 때 무엇을 삭제 할 것인지 설정한다. 아래 5개 옵션 중 하나를 선택할 수 있다.

예) maxmemory-policy volatile-lru

maxmemory-samples [size] (기본값: 3)

LRU와 minimal TTL algorithms(알고리즘)은 정확한(최적) 알고리즘들은 아니다. 하지만 거의 최적에 가깝다. 따라서 (메모리를 절약하기 위해서) 검사를 위한 샘플의 크기를 선택할 수 있다. 예를 들어, Redis는 기본적으로 3개의 key들은 검사하고 최근에 가장 적게 사용된 key를 선택할 것이다. 하지만 아래 예와 같이 샘플의 크기를 변경할 수 있다.

예) maxmoery-samples 3

APPEND ONLY MODE (AOF 지속성 설정)

appendonly [boolean] (기본값: no)

Redis는 기본적으로 비동기로 disk에 dataset의 dump를 남긴다. 이 방법은 crash가 발생했을 때 최근의 record를 손실되어도 문제가 없을 때 좋은 방법이다. 하지만 하나의 record도 유실되지 않기를 원한다면 append only mode를 활성화 시키는 것이 좋을 것이다.: 이 mode가 활성화 되면, Redis는 요청받는 모든 write operation들을 appendonly.aof 파일에 기록할 것이다. Redis가 재 시작될 때 memory에 dataset를 rebuild하기 위해서 이 파일을 읽을 것이다.

주목: 원한다면 async dumps와 asppend only file을 동시에 사용할 수 있다. 만약 append only mode가 활성화 되어 있다면, startup 때 dataset의 rebuild를 위해서 append only mode의 log file을 사용하고, dump.rdb 파일은 무시할 것이다.

중요: 순간적으로 write operation이 많을 때 background에서 어떻게 append log file을 rewirte 하는 방법을 확인하기 위해서 BGREWRITEAOF를 확인해라.

예) appendonly no

appendfilename [file name] (기본값: appenonly.aof)

append only file의 이름을 설정한다.
파일이 저장되는 디렉토리는 SNAPSHOTTING의 dir 속성을 사용한다.

예) appendfilename appendonly.aof

appendsync [option]

fsync() call 은 Operating System(운영체제)에게 output buffer 내에 보다 많은 데이터들을 기다리지 않고, disk에 실제로 data를 작성하라고 말한다. 어떤 OS 는 실제로 disk에 data를 기록할 것이고, 어떤 OS들은 가능한 빨리 data를 기록하려고 시도할 것이다.

Redis는 3가지의 다른 mode들을 지원한다.

기본값인 'everysec'은 일반적으로 속도와 데이터 안정성 사이에서 적절한 절충안이다. 이것은 당신의 관대함(?)에 달려있다. 만약 'no'로 설정한다면 OS는 적절한 타이밍에 output buffer를 flush하고 보다 좋은 성능을 낼 것이다. (그러나 만약 data loss가 발생해도 문제가 없다면 기본 persistence(영속성) mode는 snapshotting일 것이다.) 반면에 "always"를 사용하면 매우 느릴 것이다. 하지만 'everysec'보다 조금 더 안전할 것이다.

만약 확실하지않다면 'everysec'를 사용해라.

예) appendfasync everysec

no-appendfsync-on-rewrite [boolean]

AOF fsync policy를 always 또는 everysec로 설정했다면, background saving process(background 저장 또는 AOF log backgournd rewriting)은 disk에 대해서 매우 많은 I/O를 발생시킬 것이다. 따라서 어떤 Linux에서 fsync() call은 매우 긴 block를 발생시킬수도 있다.

주목: 현재 이것에 대한 fix(수정)은 없다. 다른 thread에서 fsync를 수행하더라도 동시에 발생하는 wirte call(2)이 block 될 것이다.

이 문제를 완화 시키기 위해서 BGSAVE 또는 BGREWRITEAOF가 수행중인 동안에 메인 process에서 fsync()가 호출되는 것을 막을 수 있는 no-appendfsync-on-rewirte option을 사용하는 것이 가능하다.

이것은 Redis의 영속성을 저장하는 동안에 다른 자식은 "appendfsync none"으로 설정한 것과 동일하다. 쉽게 말하면, (Linux의 기본 설정에 의해서) 최악의 경우 30초 가량의 log가 손실될 수 있다는 것이다. (이해가 잘 안됨)

이로 인해서 잠재적 문제가 있다면 이 옵션을 'yes'로 설정해라. 하지만 다른 경우에는 'no'로 남겨두는 것이 영속성의 view(?)부터 가장 안전한 선택이다.

예) no-appendfsync-on-rewrite no

auto-aof-rewrite-percentage [percente], auto-aof-rewrite-min-size [bytes]

Append only file의 Automatic rewrite(자동 재 작성)
Redis는 AOF log의크기가 명시된 퍼센트를 넘어갔을 때, 자동적으로 BGREWRITEAOF를 호출함으로서 log file를 재작성 하는 것이 가능하다. (비교 대상이 무엇인지 모르겠다.해당 Drive의 전체 크기인가?)

작동법: Redis는 최근 rewirte후에 AOF file의 크기( 또는 restart이후  rewirte가 발생하지 않았다면, startup 때 사용된 AOF의 크기)를 기억하고 있다.

이 기본 크기는 현재 크기와 비교되어진다. 만약 현재 크기가 설정된 퍼센트보다 크다면, rewrite가 동작하게된다. 또한 rewritten(재작성되는) AOF 파일의 최소 크기를 지정해 주어야 한다. 이것은 비록 퍼센트 증가가 설정 값에 도달하더라도 여전히 작은 크기일 때 AOF file이 rewriting되는 것은 피하는데 유용하다.

Automatic AOF rewirte을 비활성화 시키기 위해서는 percentage값을 0으로 설정해라.

예) auto-aof-rewrite-percentage 100
예) auto-aof-rewrite-min-size 64mb

SLOW LOG

Redis Slow Log는 설정된 실행 시간을 초과한 쿼리들의 로그를 남기는 시스템이다. 실행 시간은 talking with the client, sending the reply와 같은 I/O operation들은 포함되지 않는다. 단지 command를 수행하는데 필요한 시간(command 실행을 위해서 threaad가 block되어서 다른 request를 처리할 수 없는 시간)만이 측정된다.

2개의 parameter들를 통해서 slow log를 설정할 수 있다. : 첫번째 parameter는 Redis가 slow log를 기록하기 위해서  어떤 execution time이 느린 것인지 알려주기 위해서 microsencond로 설정한다. 두번째 parameter는 기록될 수 있는 slow log의 길이이다. 새로운 command가 log 되었을 때, 가장 오래전에 기록된 log가 제거된다. FIFO 형태인 것이다.

slowlog-log-slower-than [microseconds]

microsencod값으로 slow execution time를 설정한다. 1000000은 1초와 같다.

주의: 음수를 설정한 경우 slow log를 비활성화 시킨다. 0으로 설정한 경우 모든 command에 대해서 logging 수행된다.

예) slowlog-log-slower-than 10000

slowlog-max-len

길이에는 제한이 없다. 단지 이것은 memory를 소모하는 것은 인지하고 있어야 한다.
SLOWLOG RESET 명령으로 slow log에 의해서 사용된 memory를 반환 시킬 수 있다.

예) slowlog-max-len 128

VIRTUAL MEMORY

vm-enabled

Virtual Memory는 Redis 2.4에서 제거되었다. vm-enabled no로 설정해서 사용하지 않는다.

예) vm-enabled no

ADVANCED CONFIG

hash-max-zipmap-entries, hash-max-zipmap-value

hash들은 elements의 숫자가 설정된 entries(개수)에 도달하고 가장 큰 element가 설정된 threshold(기준치)를 초과하지 않으면 특별한 방법으로(보다 효과적인 메모리 사용법으로) encoded(인코딩)되어진다.

특별한 방법: hashtable 또는 zipmap

예) hash-max-zipmap-entries 512
예) hash-max-zipmap-value 64

list-max-ziplist-entries, list-max-ziplist-value

hash와 비슷하게 작은 list도 공간을 절약하기 위해서 특별한 방법으로 encode되어진다. 오직 설정된 값 보다 아래에 있을 때 특별한 방법이 사용되어진다.

특별한 방법: linkedlist 또는 ziplist

예) list-max-ziplist-entries 512
예) list-max-ziplist-value 64

set-max-intset-entries

Set은 오직 한 가지 경우에만 특별한 방법으로 encoded 되어진다. Set이 오직 string(문자열)로만 구성되었을 때, 64bit signed integer 범위의 radix 10의 integer로 변환된다.
아래 설정은 특별한 메모리 저장 인코딩을 사용하기 위해서 set 의 크기 제한을 설정한다. (정확한 확인 필요, 아마도 아래보다 크지 않을 때 사용하지 않을까 싶다.)

예) set-max-intset-entries 512

zset-max-ziplist-entries, zset-max-ziplist-value

hash 및 list와 비슷하게, sorted set도 많은 공간을 절약하기 위해서 특별하게 encoded되어진다. 이 Encoding은 sorted set의 element와 length가 설정치를 초과하지 않을 때 사용되어 진다.

예) zset-max-ziplist-entries 128
예) zset-max-ziplist-value 64

activerehashing

rehashing을 활성화 하면 main Redis has table(최상위 key-value hash table)을 rehashing하는 것을 돕기 위해서 CPU time의 매 100 millisecond 마다 1 millisencond를 사용한다. redis가 사용하는 hash table 구현은 lazy rehashing으로 동작한다. rehashing이 수행되는 hash table에서 많은 operation을 수행 할 수록, 보다 많은 rehashing 'steps'이 수행된다. 따라서 server가 idle 상태이면 rehashing은 결코 완료되지 않고, 약간의 메모리가 hash table에 의해서 사용되어진다.

기본값은 가능할 메모라는 free하게 만들기 위해서, main dictionary들의 rehashing을 active하는데 매 초마다 10 millisecond를 사용하는 것이다.

만약 힘든 잠재적 요구사항이나 당신의 환경에 적합하지 않아서 확신이 들지 않는다면 'activerehashing no'를 사용해라. 이 설정으로 인해서 Redis가 request들에 대해서 reply하는데 2 milliseoncds의 delay(지연)가 발생할 것이다.

만약 어려운 환경이 아니고 가장한 빠르게 메모리는 free하게 하고 싶다면 'activerehashing yes'를 사용해라.

예) activerehashing yes

# 레디스 통계 정보

redis-cli
redis client 문서 : http://redis.io/clients

> info 명령
* Server : 실행 중인 레디스 서버의 실행 정보
* Clients : 서버와 연결된 클라이언트들의 통계 정보
* Memory : 메모리 사용 정보 및 메모리 통계 정보
* Persistence : 영구 저장소와 관련된 저장 정보
* Stats : 명령 수행과 저장된 키에 대한 통계 정보
* Replication : 현재 동작 중인 복제 정보
* CPU : CPU 사용률 통계 정보
* Keyspace : 데이터베이스별로 저장된 키 정보

1) redis_version : 실행 중인 레디스 서버의 버전 정보
2) arch_bits :  실행 중인 레디스 서버의 아키텍처 비트
3) process_id :  실행 중인 레디스 서버의 시스템 프로세스 ID
4) connected_clients :  현재 연결되어 있는 클라이언트의 커넥션 수
5) connected_slaves :  복제를 위해서 연결되는 슬레이브 노드 수
6) used_memory : 레디스 서버가 사용하는 메모리의 양(바이트 단위)
7) used_memory_human : used_memory를 사람이 읽기 쉽도록 메가바이트 또는 기가바이트 단위로 표현
8) used_memory_peak :  레디스 서버가 최대로 사용했던 메모리 크기(바이트 단위)
9) used_memory_peak_human : used_memory_peak을 사람이 읽기 쉽도록 메가바이트 또는 기가바디트 단위로 표현
10) mem_fragmentation_ratio : 레디스 서버에 저장된 데이터 중에 연속되지 않은 메모리 공간에 저장되어 있는 비율
11) role:master : 마스터-슬레이브 복제 모드에서 동작하는 모드, 단일모드로 동작할 때도 마스터로 표시된다.

# 레디스 성능 측정

benchmark 문서 : http://redis.io/topics/benchmarks

> 레디스 성능 측정 도구 옵션

Usage: redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]

 -h <hostname>      Server hostname (default 127.0.0.1)
 -p <port>          Server port (default 6379)
 -s <socket>        Server socket (overrides host and port)
 -c <clients>       Number of parallel connections (default 50)
 -n <requests>      Total number of requests (default 10000)
 -d <size>          Data size of SET/GET value in bytes (default 2)
 -k <boolean>       1=keep alive 0=reconnect (default 1)
 -r <keyspacelen>   Use random keys for SET/GET/INCR, random values for SADD
  Using this option the benchmark will get/set keys
  in the form mykey_rand:000000012456 instead of constant
  keys, the <keyspacelen> argument determines the max
  number of values for the random number. For instance
  if set to 10 only rand:000000000000 - rand:000000000009
  range will be allowed.
 -P <numreq>        Pipeline <numreq> requests. Default 1 (no pipeline).
 -q                 Quiet. Just show query/sec values
 --csv              Output in CSV format
 -l                 Loop. Run the tests forever
 -t <tests>         Only run the comma separated list of tests. The test
                    names are the same as the ones produced as output.
 -I                 Idle mode. Just open N idle connections and wait.

> redis-benchmark 명령 실행

> 50바이트의 데이터를 문자열, 리스트, 셋 데이터형으로 저장하고 읽는 시간 측정

> 1024바이트의 데이터를 문자열, 리스트, 셋 데이터형으로 저장하고 읽는 시간 측정

> 백만 개의 키를 문자열 데이터로 추가

# 응답시간 측정

운영 중인 레디스가 정상적으로 작동하는지, 얼마나 빨리 응답하는지 확인하는 방법이다.
latency 옵션은 명령이 서버로 전달되고 나서부터 응답이 돌아오기까지의 시간을 측정하는 데 사용한다.
이 옵션은 사용자의 종료 명령(ctrl-c)을 전달받기 전까지 계속 실행된다.

# 주기적인 통계 정보 조회

메모리 상태, 저장된 키의 개수와 같은 서버의 통계 정보를 주기적으로 확인해야 한다면 별도의 프로그램을 개발하기보다는 간단한 리눅스 셸명령과 크론탭을 사용하는 편이 낫다.

> info 명령의 인자 목록
server : 레디스 서버의 기초적인 정보, 프로세스 ID, 포트 등을 출력
clients : 접속된 클라이언트 정보 및 통계를 출력한다.
memory :  메모리 사용량 통계 정보를 출력한다.
persistence :  영구 저장소 상태 및 통계 정보를 출력한다.
stats : 키 사용률, 명령 개수에 대한 통계 정보를 출력한다.
replication :  복제에 대한 통계 정보를 출력한다.
cpu :  CPU의 사용 정보에 대한 통계 정보를 출력한다.
keyspace :  저장된 키의 개수 정보를 출력한다.

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
SHA256:lE9TM7sHONclMNYVtHrwfefdIV3lsn88ZJLuWYc6Rz8.
Please contact your system administrator.
Add correct host key in /Users/md/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/md/.ssh/known_hosts:1
RSA host key for XXX.XXX.XXX.XXX has changed and you have requested strict checking.
Host key verification failed.

원인은 재설치한 Centos에 ssh을 접속하였기 때문이라고 한다.
이전에 접속한 RSA 키 값으로 자꾸 접속하려니까 맞지 않았던 것이라고..
결론은 지우면 된다는거.

ssh-keygen -R [ IP or DomainName]

상단의 내용을 치니, 다음과 같이 나온다.
# Host XXX.XXX.XXX.XXX found: line 1
/Users/md/.ssh/known_hosts updated.
Original contents retained as /Users/md/.ssh/known_hosts.old

이렇게 뜬다면 성공한 것이다.

♬ 하드 디스크 병목 현상

-LogicalDisk\% Free Space 

-PhysicalDisk\% Idle Time

-PhysicalDisk\Avg. Disk Sec/Read

-PhysicalDisk\Avg. Disk Sec/Write

-PhysicalDisk\Avg. Disk Queue Length

-Memory\Cache Bytes

♬ 메모리 병목 현상

-Memory\% Committed Bytes in Use

-Memory\% Available Mbytes

-Memory\Free System Page Table Entries

-Memory\Pool Non-Paged Bytes

-Memory\Pool Paged Bytes

-Memory\Pages per Second

♬ 프로세서 병목 현상

-Processor\% Processor Time

-Processor\% User Time

-Processor\% Interrupt Time

-System\Processor Queue Length

♬ 네트워크 병목 현상

-Network Interface\Bytes Total/Sec

-Network Interface\Output Queue Length

♬ 프로세스 병목 현상

-Process\Handle Count 

-Process\Thread Count

-Process\Private Bytes 

https://technet.microsoft.com/ko-kr/magazine/2008.08.pulse.aspx

mysql-connector-odbc-5.2.6-winx64.msi

mysql 사이트에가서 다운받는다.

odbc 설치.







cursor/resuts 에서
return matched rows instated of affected rows 는 꼭 체크 한다.. 
openquery update 

linked Server

공급자 : Microsoft OLE DB Provider for ODBC Drivers
제품이름 : MySQL
데이터원본 : GA (시스템DNS)
공급자 문자열 : DRIVER[MYSQL ODBC 5.2 Unicode Driver];SERVER=xxx.xxx.xxx.xxx;PORT=3306
카탈로그 : db선택

보안 : 
다음보안 컨텍스트트를 이용하여 연결 
--시스템 DNS 에 설정한 아이디 비번

서버옵션
데이터엑스스 , RPC, RPC내보내기 , 언격 데이터 정렬 사용 ==> TRUE



openquery 사용

select * from openquery(GA, 'select * from mysql_table')

insert into openquery(GA, 'select seq from tb_xxxx') values (1)
insert into openquery(GA, 'select seq from tb_xxxx') select seq from dbo.mssql_table

delete openquery(GA, 'select seq from tb_xxxx') where seq > 0

update xx
set xx.col = zz.col
from openquery(GA, 'select seq, col from tb_xxxx') xx
inner join mssql_table zz on xx.seq=zz.seq;

Ubuntu 12.04 Zabbix 설치

https://www.digitalocean.com/community/tutorials/how-to-install-zabbix-on-ubuntu-configure-it-to-monitor-multiple-vps-servers

위에 홈페이지 설명대로 설치

추가 사항

vi /etc/apache2/apache2.conf

AddType application/x-httpd-php .php .html .htm .inc

vi /etc/php5/apache2/php.ini
post_max_size = 16M
max_execution_time = 300
max_input_time = 300
date.timezone = Asia/Seoul

php 관련 추가 설치

apt-get install php5 libapache2-mod-php5 php5-mcrypt php5-mysql

​

어떤 걸 설치하다보니 갑자기 mysql 이 시작되지 않고 

/usr/bin/mysqld_safe 이런 메시지가 뜨거나 

/var/log 어쩌구 샬라샬라 할 때가 있다.

그럼 100% 이전 my.cnf 를 찾고 있는거다.

find / -name my.cnf 

해서 찾아서 필요없는 건 지워라..-_-;

리눅스 시간 동기화

아마존 서비스가 글로벌 서비스이다보니 date 명령어를 사용했을 때 UTC 시간을 사용한다.

하지만 국내용 서비스를 하기 위해서는 아무래도 KST 시간으로 설정하는 것이 좋을 것이다.

구글링을 해보면 몇 가지 방법을 찾을 수 있는데,  그중 한가지가 다음과 같은 명령어를 사용하는 방법이다.

# tzselect 

위 명령어를 입력하면 간단하게 몇 가지 물음으로 KST 설정 방법에 대해서 나온다.

하지만 tzselect에서 마지막 알려주는 설정 방식으로 .profile 설정을 알려주는데, 그렇게 하면 현재 유저(ec2-user)에만 이가 적용된다.

(sudo date 명령어를 입력해보면 그대로 UTC이다.)

전체 서버에서, 다시 말해 모든 사용자가 KST를 사용하기 위해서는 아래 명령어가 필요하다

# sudo mv /etc/localtime /etc/localtime.old

# sudo ln -s /usr/share/zoneinfo/Asia/Seoul /etc/localtime 

1. 기존 /etc/localtime 백업

2. Asia/Seoul 파일을 /etc/localtime으로 연결

아마존에서 특별한 설정변경없이 EC2 인스턴스를 생성하면 기본적으로 8G의 디스크용량을 가지게 된다. 이렇게 사용하다가 용량이 부족하다 싶으면 사용하던 데이터를 손대지 않고 스토리지의 공간을 확장할 수 있다.

기본적인 개념은 아래와 같다.

1. EC2를 정지시킨다.
2. 연결되어 있는 EBS를 detach 시킨다.
3. detach 된 EBS volume의 snapshot을 생성한다.
4. 생성된 snapshot으로 새로운 EBS volume을 생성한다. 이때 생성되는 EBS volume의 크기를 원하는 사이즈로 지정한다.
5. EC2에 새로 생성된 EBS volume을 attach 한다.
6. EC2 인스턴스에 접속해서 디스크크기를 재설정한다.

대략 위와 같은 과정이라고 보면 된다.

쉽게 설명하면 서버에서 기존의 저장장치를 때어내고 새로만든 큰 저장장치를 붙이는 과정이다. 이과정에서 새로만든 저장장치에 기존 데이터가 그대로 들어있도록 만드는 것이 포인트라고 할 수 있다.

아마존 웹 서비스 콘솔에서 위와 같은 과정으로 EC2 인스턴스의 스토리지를 확장할 수 있다. 

위 그림만 이해하면 콘솔의 메뉴를 열어 보고 어렵지 않게 진행할 수 있다. 이럴 경우 6번 과정만 주의 해서 봐도 된다. 처음에 5번까지만 하고 인스턴스 공간이이 확장이 안되어 있어서 해맸었다.

상세과정을 살펴보자.

1. EC2를 정지시킨다.

아마존 EC2콘솔 INSTANCES -> instances 메뉴에서 실행하려는 인스턴스 선택후 마우스오른쪽 버튼을 누르면 아래와 같이 팝업 메뉴가 뜬다.

여기서 Stop을 실행한다.

4. 생성된 snapshot으로 새로운 EBS volume을 생성한다. 이때 생성되는 EBS volume의 크기를 원하는 사이즈로 지정한다.

아마존 EC2콘솔 ELASTIC BLOCK STORE -> Snapshots 메뉴에서 방금 생성한 스냅샵을 찾아서 마우스 오른쪽 버튼을 누르면 아래와 같이 팝업 메뉴가 나온다.

여기서 Create Volume을 선택한다.

다음으로 볼륨 생성팝업차이 뜨는데 이때 아래와 같이 Size를 확장하려는 사이즈로 지정해준다. 기본값이 현재 사이즈 이므로 방심하면 그냥 넘어가서 크기가 같은 볼륨을 생성해버리게 되니 주의

5. EC2에 새로 생성된 EBS volume을 attach 한다.

새로 생성된 볼륨은 상태가 available 상태로 되어 있다. 여기서 마우스 오른쪽 버튼을 누르면 아래와 같이 팝업 메뉴가 나온다.

여기서 Attach Volume을 선택한다.

다음으로 나오는 어태치 팝업에서 아래와 같이 instance를 지정해준다. 최초에 stop 시킨 인스턴스의 아이디나 이름 등을 입력하면 된다.

그리고 Device에서 원래의 볼륨이 마운트되어 있던 경로를 똑같이 적는다. 2번과정에서 /dev/sda1 경로 였다.

6. EC2 인스턴스에 접속해서 디스크크기를 재설정한다.

기본적으로 EC2와 연결된 EBS Volume의 용량을 늘려주면 스토리지 확장이 된다고 하는데 여기까지 진행하고 인스턴스를 재시작한후

막상 디스크 용량을 확인해보면 전혀 늘어나지 않았다.

아래와 같이 command 처리로 늘어난 EBS 스토리지 공간을 OS에서 인식 할 수 있게 되었다.

위와 같이 처음에 df -h 로 디스크 공간을 확인해보면 7.9G만 잡혀있는 상태이다.

그러나 fdisk -l로 확인해보면 /dev/xvde 디스크용량이 107.4G 인것이 확인된다.

이상태에서 resize2fs /dev/xvde 명령을 실행해서 파일시스템을 재구축해야 한다. (오래 걸림)

다시 df -h 로 용량을 확인해보면 전체 디스크 용량이 모두 사용가능한 공간이 되었음을 확인 할 수 있다.

저 명령실행전에 몽고 디비가 실행중이었는데 용량 제산정 과정이나 진행후에 프로세스에 전혀 지장이 없었다.

파일 시스템 재구축 작업은 서비스 운영중에도 사용할 수 있을 것으로 판단된다.

아마존의 위 문서에서 스토리지 확장하는 방법이 자세하게 나와 있다. (영어)

출처 : http://adrenal.tistory.com/11

성능 관련 기초 이론
※ 모델링 - 시스템에 영향을 미칠 수 있는 요소들을 추출하여 이들의 연관관계를 도식화하는 것
- Queuing Network Model(QNM)
  : 1976년 Jeffrey P. Buzen이 제안, 1978년 Peter J.Denning&Jeffrey P. Buzen에 의해 확장
  : 컴퓨터 시스템의 대기 행렬을 의미하는 큐들의 네트워크
  : 다중 서버에 대한 모델링이 가능
  : 'Operational Law'에 의해 분석

- 단일 서버 QNM
  : 서버가 하나인 경우 사용(2Tier)
  : 사용자가 서버에 Request하는 경우, Queue를 거쳐 서비스 요청
  : Parameters - 부하 강도(사용자의 호출 빈도), 서비스 요구량(사용자 요청을 처리하는 데 소요되는 시간)
  : Operation Law
    → 이용률(Utilization): 전체 측정 시간 대비 서비스 시간의 비율
    → 응답시간(Response Time): 사용자가 서버에서 머물렀던 평균 시간(서비스 시간+대기 시간)
    → 큐 길이(Queue Length): 서버에 머무르고 있는 총 사용자 수(서비스 + 대기)
    → 처리량(Throughtput): 서버가 서비스 처리 종료 후 서버를 출발하는 비율
  : Operation Law의 의미
    → 이용률(Utilization): 대상 서버에 대한 가용 자원 대비에 현재 이용되고 있는 정도
                            0≤이용률≤1, 1이 되면 서버에 병목현상 발생, 부하강도가 증가하면 이용률도 증가
    → 응답시간(Response Time): 사용자가 서비스를 요청하고 받을 때까지 걸리는 시간
                                이용률(부하강도)의 증가에 따라 기하급수적으로 증가
    → 큐 길이(Queue Length): 큐를 점유하고 있는 사용자 수
                              이용률(부하강도)의 증가에 따라 기하급수적으로 증가
    → 처리량(Throughtput): 대상 서버에서 요청 건수의 대비 처리량
                            이용률의 증가에 따라 같이 증가, 이용률이 1이 되면 일정 수준 유지

- 다중 서버 QNM
  : 서버가 여러 개일 경우 사용(3Tier over)
  : 사용자가 서버에 Request하는 경우, Web Server → WAS → DB 서버 등을 거쳐 서비스 요청 및 처리
  : Parameters - 부하 강도(사용자의 호출 빈도), 실행 시간(각 개별 서버 별 요청 처리에 소요되는 시간)
                 ※ 부하 강도는 시스템의 종류에 따라 각각 다르게 정의될 수 있음
                    (ex. TP-Monitor: 요청건수, Batch: 동시 사용자, 웹 기반, C/S 시스템: 동시 사용자 수&평균 Think time 등)
  : Operation Law는 단일 서버 QNM과 유사

- Operation Law
  : QNM에서 서버의 여러 특성들을 파라미터화하여 주요 평가 항목들을 추출할 때 사용하는 주요 공식의 기반
  : 파라미터화 된 기본 항목들은 측정 도구에 의해 측정 가능

  ※ 기본 항목
    → T: 대상 시스템을 모니터링한 총 소요 시간(초)
       A: T시간 동안 시스템에 요청된 총 요청 건수(건)
       C: T시간 동안 시스템에서 처리된 총 처리 건수(건)
       B: 시스템이 요청을 처리하기 위해 사용된 총 서비스 시간(Bysu Time, 초)
       W: 시스템이 요청을 처리하기 위해 사용된 총 응답 시간(서비스 시간 + 대기 시간)
       Z: 사용자가 다음 요청을 준비하기 위해 소요된 Think time(초)
       N: T시간 동안 시스템을 사용하고 있는 사용자 수(명)

  ※ 도출되는 성능 수치 항목
    → 호출비율(Arrival Rate): 단위 시간당 시스템으로 들어오고 있는 건수(λ=A/T)
    → 처리량(Throughtput): 단위 시간당 시스템에서 처리 되고 있는 건수(X=C/T)
    → 이용률(Utilization): 총 소요 시간 대비의 총 서비스 시간 비율(U=B/T)
    → 평균 서비스 시간(Service Time): 요청을 처리하기 위해 소요된 평균 서비스 시간(S=B/C)
    → 응답 시간(Response Time): 요청을 처리하기 위해 소요된 평균 응답 시간(R=W/C)

- Utilization Law
  : U=B/T=(B/C)*(C/T)=S*X
  : 총 소요 시간 대비의 총 서비스 시간 비율 = 단위 시간당 시스템의 처리 건수 * 처리 건당 소요되는 평균 서비스 시간

- Little's Law
  : 서버상의 큐 길이를 설정할 때 참조할 수 있는 공식
  : Q(큐의 길이) = W/T = (W/C)*(C/T) = R*X

- Response Time's Law
  : X(처리량) = 총 호출 건수/총 소요 시간 = N*(T*(R+Z))/T = N*(R+Z)

- Forced-Flow Law
  : 개별 리소스와 전체 시스템 사이의 상관 관계를 보여주는 공식
  : C - 전체 시스템에 대한 처리 건수
    Ck- 개별 리소스에 대한 처리 건수(k번째 리소스)
    Vk- 개별 리소스에 대한 Visit Ratio(k번째 리소스)
    Dk- 개별 리소스에 대한 서비스 요구량(k번째 리소스)

    Vk = Ck/C(k번째 리소스)
    Xk = Vk*X (k번째 리소스에 대한 처리량)
    Uk = Xk*Sk (k번째 리소스에 대한 사용율)
       = X*Vk*Sk
       = X*Dk

- 처리량 상관관계
  : Forced-Flow Law에 의해 도출된 각 리소스에 대한 처리량을 통해 전체 시스템의 처리량을 정의할 수 있음
  : 전체 시스템을 구성하는 n개의 독립 서버의 각 처리량을 Tn이라할 때, 다음과 같이 처리량을 도출할 수 있음
  ※ 전체 Throughput(단, 각각의 서버가 동일한 리소스에 의해 병목을 직면하고 있는 경우)
    T = 1/(1/T1+1/T2+1/T3+1/T4+1/T5+....+1/Tn) = 1/(∑(1/Tn))
  ※ Throughput of Block A&B = 1/(1/a+1/b)

- 병목 지점 분석
  : 임계 지점 부근의 처리량(X)과 응답 시간(R)의 상관 관계
    → X(N)≤min{1/Dmax, N/(D+Z)}
       R(N)≥max{D, NDmax-Z}
       where Dmax: 병목 지점의 서비스 시간
             D=∑Dn
       전제조건: 어떠한 리소스라도 이용률은 1이하이다.
                 N명의 사용자를 처리하고 있는 시스템의 응답 시간은 1명의 사용자를 처리하는 시스템보다 더 빠를 수 없다

  : 처리량의 경우 입계 사용자 수 근방까지 시스템의 용청을 원할하게 처리, 포화 지점 이후 병목 발생 수평을 유지
  : 임계 사용자 수 지점의 처리량은 해당 시스템의 최대 처리량 or 임계 처리량
  : 응답 시간은 임계점 이전은 일정하게 유지, 포화 지점 이후 병목 발생으로 응답시간 증가

===================================================================================================================

각종 공식들에 눈돌아가네요...@_@;

DB와는 직접적인 관련이 없습니다만... 알아두시면 좋으실 듯 해서 두번째 정리본 올립니당~^^ㅋ

출처 : http://cafe.naver.com/prodba/3664

ERROR: child process failed, exited with error number 100 가 나타난다면

설치 시 잘못해서 그런거다.. 중복 실행을 했거나...

이럴 때 설치하는 data 폴더를 찾아가서

rm mongod.lock 

으로 mongod.lock 파일을 살포시 날려준다.

또는 

[root@server ]# mongod --smallfiles

한 후

conf 디렉토리에서

nojournal = true 를 해주고

service mongo restart 해주면 정상적으로 데몬이 뜬다.

-- 출처 : SQLTAG BOOK2 

CREATE TABLE dbo.TEST_RESOURCE

( COL1 int NOT NULL

, COL2 varchar(100) NULL

, COL3 smallint NOT NULL

, COL4 varchar(10) SPARSE NULL

, COL5 char(10) NOT NULL

, COL6 char(30) NULL

, COL7 varchar(max) NOT NULL

)

GO

INSERT dbo.TEST_RESOURCE

( COL1

, COL2

, COL3

, COL4

, COL5

, COL6

, COL7

)

VALUES

(1,'A',1,'AA','A','A',REPLICATE(CONVERT(varchar(max),'A'),10000)),

(2,'BB',2,'BBB','BB','BB',REPLICATE(CONVERT(varchar(max),'A'),300)),

(3,'CCC',30,'CCCC','CCC','CCC',REPLICATE(CONVERT(varchar(max),'A'),10))

GO

ALTER TABLE dbo.TEST_RESOURCE

ADD CONSTRAINT PK_TEST_RESOURCE

PRIMARY KEY CLUSTERED

( COL3

)

GO

CREATE UNIQUE NONCLUSTERED INDEX UNCIDX_TEST_RESOURCE

ON dbo.TEST_RESOURCE

( COL1

)

GO

-- 1. Partition Id 확인(PK_TEST_RESOURCE)

SELECT %%ROWDUMP%% AS [ROWDUMP]

, sys.fn_GetRowsetIdFromRowDump(%%ROWDUMP%%) AS PARITION_ID

FROM dbo.TEST_RESOURCE

GO

-- 2. Partition Id 확인(UNCIDX_TEST_RESOURCE)

SELECT %%ROWDUMP%% AS [ROWDUMP]

, sys.fn_GetRowsetIdFromRowDump(%%ROWDUMP%%) AS PARITION_ID

FROM dbo.TEST_RESOURCE WITH(INDEX(UNCIDX_TEST_RESOURCE))

GO

-- 3. 가변 길이 칼럼의 행 정보 확인

SELECT %%ROWDUMP%% AS [ROWDUMP]

, RDC.*

FROM dbo.TEST_RESOURCE AS TR

CROSS APPLY

sys.fn_RowDumpCracker(%%ROWDUMP%%) AS RDC

GO

-- 3. File Id, Page Id, Slot Id, KeyHashValue 확인(PK_TEST_RESOURCE)

SELECT %%PHYSLOC%% AS PHYSLOC

, sys.fn_PhysLocFormatter(%%PHYSLOC%%) AS [FILEID:PAGEID:SLOTID]

, PLC.*

, %%LOCKRES%% AS [LOCKRES]

FROM dbo.TEST_RESOURCE AS TR

CROSS APPLY

sys.fn_PhysLocCracker(%%PHYSLOC%%) AS PLC

GO

-- 4. File Id, Page Id, Slot Id, KeyHashValue 확인(UNCIDX_TEST_RESOURCE)

SELECT %%PHYSLOC%% AS PHYSLOC

, sys.fn_PhysLocFormatter(%%PHYSLOC%%) AS [FILEID:PAGEID:SLOTID]

, PLC.*

, %%LOCKRES%% LOCKRES

FROM dbo.TEST_RESOURCE AS TR WITH(INDEX(UNCIDX_TEST_RESOURCE))

CROSS APPLY

sys.fn_PhysLocCracker(%%PHYSLOC%%) AS PLC

GO

MYSQL에서 쿼리 작성 중 프로그램과의 형변환에러가 난다면

필드에 대한 연산 및 기타함수 사용 시 형변환에러가 난다.

이것은 필드의 형이 달라지는 것이 아닌 상수를 입력하거나

예를 들면 IFNULL(필드, 0)으로 입력 시 0이 기존적으로 BIGINT형식으로 처리되므로

프로그램상에서 필드= TINYINT 로 인식해야하는데 0의 값을 출력하게 되면 BIGINT로 출력하게 되므로

형변환 에러가 나는 것이다.

--1단계 : 가장 많은 리컴파일 데이터베이스 찾기

CREATE EVENT SESSION [XE_Database_Recompile_Histogram] ON SERVER

ADD EVENT sqlserver.sql_statement_recompile(

ACTION(sqlserver.database_id)

WHERE ([package0].[counter]<(2000)))

ADD TARGET package0.histogram(

SET filtering_event_name = N'sqlserver.sql_statement_recompile'

, slots = (100)

, source = N'sqlserver.database_id')

WITH (

MAX_MEMORY = 4096 KB

, EVENT_RETENTION_MODE = ALLOW_MULTIPLE_EVENT_LOSS

, MAX_DISPATCH_LATENCY = 5 SECONDS

)

GO

-- 2단계 : 어떤 이유로 리컴파일이 가장 많이 발생하는지 찾기

CREATE EVENT SESSION [XE_Database_Recompile_Histogram_Cause] ON SERVER 

ADD EVENT sqlserver.sql_statement_recompile(

    WHERE (

[package0].[less_than_uint64]([package0].[counter],(2000)) 

AND [package0].[equal_uint64]([sqlserver].[database_id],(54)))) 

ADD TARGET package0.histogram(

SET filtering_event_name=N'sqlserver.sql_statement_recompile'

, source=N'recompile_cause'

, source_type=(0))

WITH (

MAX_MEMORY=4096 KB

, EVENT_RETENTION_MODE=ALLOW_MULTIPLE_EVENT_LOSS

, MAX_DISPATCH_LATENCY=5 SECONDS

, MAX_EVENT_SIZE=0 KB

, MEMORY_PARTITION_MODE=NONE

, TRACK_CAUSALITY=OFF

, STARTUP_STATE=OFF

)

GO

-- 3단계 : 2단계에서 찾은 원인에 해당하는 쿼리 찾기

CREATE EVENT SESSION [XE_Database_Recompile_Histogram_Cause_Statement] ON SERVER 

ADD EVENT sqlserver.sql_statement_recompile(

    ACTION(sqlserver.sql_text,sqlserver.tsql_stack)

    WHERE (

[package0].[counter]<(2000) AND [sqlserver].[database_id]=(10)

AND [recompile_cause]=(11))) 

ADD TARGET package0.event_file(

SET filename=N'XE_Database_Recompile_Histogram_Cause_Statement'

, max_file_size=(100))

WITH (

MAX_MEMORY=4096 KB

, EVENT_RETENTION_MODE=ALLOW_MULTIPLE_EVENT_LOSS

, MAX_DISPATCH_LATENCY=5 SECONDS

, MAX_EVENT_SIZE=0 KB

, MEMORY_PARTITION_MODE=NONE

, TRACK_CAUSALITY=OFF

, STARTUP_STATE=OFF

)

GO

-- 시작

ALTER EVENT SESSION [XE_Database_Recompile_Histogram] ON SERVER

STATE = START

GO

ALTER EVENT SESSION [XE_Database_Recompile_Histogram_Cause] ON SERVER

STATE = START

GO

ALTER EVENT SESSION [XE_Database_Recompile_Histogram_Cause_Statement] ON SERVER

STATE = START

GO

-- 종료

ALTER EVENT SESSION [XE_Database_Recompile_Histogram] ON SERVER

STATE = STOP

GO

ALTER EVENT SESSION [XE_Database_Recompile_Histogram_Cause] ON SERVER

STATE = STOP

GO

ALTER EVENT SESSION [XE_Database_Recompile_Histogram_Cause_Statement] ON SERVER

STATE = STOP

GO

-- 삭제

DROP EVENT SESSION [XE_Database_Recompile_Histogram] ON SERVER

GO

DROP EVENT SESSION [XE_Database_Recompile_Histogram_Cause] ON SERVER

GO

DROP EVENT SESSION [XE_Database_Recompile_Histogram_Cause_Statement] ON SERVER

GO

-- 1단계 XQuery를 이용한 분석

SELECT db_name(xnode.xdata.query('.').value('(Slot/value)[1]','varchar(max)')) AS database_name

, xnode.xdata.query('.').value('(Slot/@count)[1]','varchar(max)') as recompile_count

FROM (

SELECT CAST(target_data as xml) as target_data

FROM sys.dm_xe_sessions as s

INNER JOIN sys.dm_xe_session_targets as t

ON s.address = t.event_session_address

WHERE s.name = 'XE_Database_Recompile_Histogram') as a

CROSS APPLY a.target_data.nodes('HistogramTarget/Slot') as xnode (xdata)

GO

-- 2단계 XQuery를 이용한 분석

;WITH cte_xdata_results as (

SELECT xnode.xdata.query('.').value('(Slot/value)[1]','varchar(max)') as recompile_cause

, xnode.xdata.query('.').value('(Slot/@count)[1]','varchar(max)') as recompile_count

FROM (

SELECT CAST(target_data as xml) as target_data

FROM sys.dm_xe_sessions as s

INNER JOIN sys.dm_xe_session_targets as t

ON s.address = t.event_session_address

WHERE s.name = 'XE_Database_Recompile_Histogram_Cause'

) as a

CROSS APPLY a.target_data.nodes('HistogramTarget/Slot') as xnode (xdata)

)

SELECT map_value as statement_recompile_cause

, recompile_count

FROM cte_xdata_results as x

INNER JOIN sys.dm_xe_map_values as mv

ON x.recompile_cause = mv.map_key

WHERE mv.name = 'statement_recompile_cause';

GO

-- 3단계 분석

/* 

tsql_stack 의 handle를 이용해 프로덕션 데이터베이스에서 조회 할 수 있음.(결과가 모두 출력되지 않으면

도구 > 옵션 > 쿼리 결과 > SQL Server > 텍스트로 결과 표시 > 각 열에 표시할 최대 문자 수를 적당하게 변경 후 SSMS 재시작)

*/

SELECT *

FROM sys.dm_exec_sql_text(0x03002E005D05B6215B3BFB00A2A2000001000000000000000000000000000000000000000000000000000000);

;WITH cte_dm_xe_sessions AS (

SELECT xnode.xdata.query('./data').value('(data[@name="recompile_cause"]/text)[1]','varchar(max)') AS recompile_cause

, db_name(xnode.xdata.query('./data').value('(data[@name="source_database_id"]/value)[1]','varchar(max)')) AS [db_name]

, xnode.xdata.query('./data').value('(data[@name="object_type"]/text)[1]','varchar(max)') AS object_type

, xnode.xdata.query('./action').value('(action[@name="sql_text"]/value)[1]','varchar(max)') AS sql_text

, xnode.xdata.query('./action/value/frames') AS tsql_stack_frames

FROM ( SELECT CONVERT(xml,target_data) AS target_data

FROM sys.dm_xe_sessions AS s

INNER JOIN

sys.dm_xe_session_targets AS t

ON s.[address] = t.event_session_address

WHERE s.name = 'XE_Database_Recompile_Histogram_Cause_Statement'

AND target_name = 'ring_buffer'

) AS a

CROSS APPLY

a.target_data.nodes('RingBufferTarget/event') xnode (xdata)

)

SELECT a.db_name

, a.recompile_cause

, a.object_type

, a.sql_text

, [level] AS frame_level

, b.[text]

, SUBSTRING

( b.[text]

, (offsetStart/2)+1

, (( CASE offsetEnd

WHEN -1 THEN DATALENGTH(b.[text])

ELSE offsetEnd

END - offsetStart

)/2)+1

) AS stmt

FROM ( SELECT a.*

, ynode.ydata.query('.').value('(frame/@level)[1]','varchar(max)') AS [level]

, ynode.ydata.query('.').value('(frame/@handle)[1]','varchar(max)') AS handle

, ynode.ydata.query('.').value('(frame/@offsetStart)[1]','varchar(max)') AS offsetStart

, ynode.ydata.query('.').value('(frame/@offsetEnd)[1]','varchar(max)') AS offsetEnd

FROM cte_dm_xe_sessions AS a

CROSS APPLY

a.tsql_stack_frames.nodes('frames/frame') ynode (ydata)

) AS a

OUTER APPLY

sys.dm_exec_sql_text (CONVERT(varbinary(max),handle,1)) b

GO

-- tempdb 의 I/O 관련 장애처리

CREATE DATABASE DBA

GO

USE DBA

GO

-- DROP TABLE dbo.TBL_ANALYSIS_MONITOR_TEMPDB

-- GO

CREATE TABLE dbo.TBL_ANALYSIS_MONITOR_TEMPDB

(

Event_Date datetime -- 로깅 시작

, Event_Idx int identity -- 중복방지 자동증가값

, Task_UserObj_Alloc_Cnt int -- 유저오브젝트 페이지 할당수

, Task_UserObj_Dealloc_Cnt int -- 유저오브젝트 페이지 해제수

, Task_Internal_Alloc_Cnt int -- 내부오브젝트 페이지 할당수

, Task_Internal_Dealloc_Cnt int -- 내부오브젝트 페이지 해제수

, Degree_of_Parallelism smallint -- 병렬처리수준

, Database_ID int -- DB_ID

, User_ID int -- 실행 유저 ID

, SQL_Handle varbinary(64) -- 후에 추적 가능하도록 로깅

, Plan_Handle varbinary(64) -- 후에 추적 가능하도록 로깅

, SQL_Text100 nvarchar(100) -- 핸들 조인 안될경우 대비

, CONSTRAINT CPK__TBL_ANALYSIS_MONITOR_TEMPDB__01 PRIMARY KEY CLUSTERED (Event_Date, Event_Idx)

);

GO

IF object_id('dbo.USP_TEMP_IO_GETTER') IS NULL

EXEC ('CREATE PROC dbo.USP_TEMP_IO_GETTER AS SELECT 1')

GO

ALTER PROCEDURE dbo.USP_TEMP_IO_GETTER

(

@pRoop_Cnt int = 60

)

AS

BEGIN

SET NOCOUNT ON;

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

DECLARE @vDate_Time datetime, @vCnt int = 0

WHILE @vCnt < @pRoop_Cnt

BEGIN

SELECT @vDate_Time = GETDATE(), @vCnt += 1;

WITH cteSU AS (

SELECT TOP 10

session_id

, request_id

, SUM(user_objects_alloc_page_count) as [userobj_alloc_cnt]

, SUM(user_objects_dealloc_page_count) as [userobj_dealloc_cnt]

, SUM(internal_objects_alloc_page_count) as [internal_alloc_cnt]

, SUM(internal_objects_dealloc_page_count) as [internal_dealloc_cnt]

, COUNT(session_id) as [degree_of_parallelism]

FROM tempdb.sys.dm_db_task_space_usage

WHERE database_id = 2

AND (user_objects_alloc_page_count > 0 OR internal_objects_alloc_page_count > 0)

AND session_id <> @@spid

AND session_id > 50

GROUP BY session_id, request_id

ORDER BY SUM(user_objects_alloc_page_count)

+ SUM(internal_objects_alloc_page_count) DESC

)

INSERT INTO DBA.dbo.TBL_ANALYSIS_MONITOR_TEMPDB

(Event_Date

, Task_UserObj_Alloc_Cnt

, Task_UserObj_Dealloc_Cnt

, Task_Internal_Alloc_Cnt

, Task_Internal_Dealloc_Cnt

, Degree_of_Parallelism

, Database_ID

, User_ID

, SQL_Handle

, Plan_Handle

, SQL_Text100

)

SELECT GETDATE() AS event_date

, A.userobj_alloc_cnt

, A.userobj_dealloc_cnt

, A.internal_alloc_cnt

, A.internal_dealloc_cnt

, A.degree_of_parallelism

, ER.database_id

, ER.user_id

, ER.sql_handle

, ER.plan_handle

, LEFT(ST.text, 100)

FROM cteSU AS A 

INNER JOIN sys.dm_exec_requests AS ER

ON ER.session_id = A.session_id AND ER.request_id = A.request_id

OUTER APPLY sys.dm_exec_sql_text(ER.sql_handle) AS ST

WAITFOR DELAY '00:00:01'

END

END;

GO

SELECT ST.text as [SQL_Text]

, QP.query_plan as [Plan_XML]

, AMT.Max_Task_UserObj_Alloc_Cnt

, AMT.Max_Task_Internal_Alloc_Cnt

, AMT.Database_ID

, AMT.SQL_Text100

FROM (

SELECT TOP 10

SQL_Handle, Plan_Handle, Database_ID

, MAX(Task_UserObj_Alloc_Cnt) as [Max_Task_UserObj_Alloc_Cnt]

, MAX(Task_Internal_Alloc_Cnt) as [Max_Task_Internal_Alloc_Cnt]

, SQL_Text100

FROM DBA.dbo.TBL_ANALYSIS_MONITOR_TEMPDB

GROUP BY SQL_Handle, Plan_Handle, Database_ID, SQL_Text100

ORDER BY MAX(Task_UserObj_Alloc_Cnt) + MAX(Task_Internal_Alloc_Cnt) DESC

) AS AMT 

OUTER APPLY sys.dm_exec_sql_text(AMT.sql_handle) as ST

OUTER APPLY sys.dm_exec_query_plan(AMT.Plan_Handle) as QP

GO

EXEC dbo.USP_TEMP_IO_GETTER;

-- Read I/O

CREATE EVENT SESSION [MONITOR_FILEIO_READ_HISTOGRAM]

ON SERVER

ADD EVENT sqlserver.file_read

( SET collect_path = (1)

WHERE

( -- tempdb 드라이브 path를 지정

[sqlserver].[like_i_sql_unicode_string]([path],N'E:\%')

)

)

ADD TARGET package0.histogram

( SET filtering_event_name = N'sqlserver.file_read'

, source = N'path'

, source_type = (0)

)

WITH

( max_memory = 4096 kb

, event_retention_mode = allow_single_event_loss

, max_dispatch_latency = 30 seconds

, max_event_size = 0 kb

, memory_partition_mode = none

, track_causality = off

, startup_state = off

)

GO

-- Write I/O

CREATE EVENT SESSION [MONITOR_FILEIO_WRITTEN_HISTOGRAM]

ON SERVER

ADD EVENT sqlserver.file_written

( SET collect_path = (1)

WHERE

( -- tempdb 드라이브 path를 지정

[sqlserver].[like_i_sql_unicode_string]([path],N'E:\%')

)

)

ADD TARGET package0.histogram

( SET filtering_event_name = N'sqlserver.file_written'

, source = N'path'

, source_type = (0)

)

WITH

( max_memory = 4096 kb

, event_retention_mode = allow_single_event_loss

, max_dispatch_latency = 30 seconds

, max_event_size = 0 kb

, memory_partition_mode = none

, track_causality = off

, startup_state = off

)

GO

SELECT TOP 10

TSU.session_id

, TSU.request_id

, TSU.task_alloc_cnt

, TSU.task_dealloc_cnt

, EST.text as [query_text]

, EQP.query_plan as [plan_xml]

FROM (

SELECT session_id

, request_id

, SUM(internal_objects_alloc_page_count) as [task_alloc_cnt]

, SUM(internal_objects_dealloc_page_count) as [task_dealloc_cnt]

FROM sys.dm_db_task_space_usage

GROUP BY session_id, request_id --병렬처리 그룹화

) as [TSU]

INNER JOIN sys.dm_exec_requests as [ER]

ON TSU.session_id = ER.session_id

AND TSU.request_id = ER.request_id

OUTER APPLY sys.dm_exec_sql_text (ER.sql_handle) as [EST]

OUTER APPLY sys.dm_exec_query_plan (ER.plan_handle) as [EQP]

WHERE TSU.session_id <> @@spid

ORDER BY TSU.task_alloc_cnt DESC

-- 버전스토오 사용시 TEMPDB 사용량 확인

SELECT TOP 10

SDT.session_id

, SDT.elapsed_time_seconds

, SDT.is_snapshot

, EST.text as query_text

, EQP.query_plan as plan_xml

FROM sys.dm_tran_active_snapshot_database_transactions as [SDT]

LEFT OUTER JOIN sys.dm_exec_requests as [ER]

ON SDT.session_id = ER.session_id

OUTER APPLY sys.dm_exec_sql_text (ER.sql_handle) as [EST]

OUTER APPLY sys.dm_exec_query_plan (ER.plan_handle) as [EQP]

ORDER BY elapsed_time_seconds DESC;

SET @tmp1 = '12,13,14,15';

SET @xxx := CONCAT("SELECT * FROM t_user_master_card where user_seq = 1 and master_card_seq in (", @tmp1, ")");

SELECT @xxx;

PREPARE stmt FROM @xxx  ;

EXECUTE stmt   ;

DEALLOCATE PREPARE stmt ;

SET @tmp2 = 15;

SET @xxx := CONCAT("SELECT * FROM t_user_master_card where user_seq = 1 and master_card_seq in (?)");

SELECT @xxx;

PREPARE stmt FROM @xxx  ;

EXECUTE stmt USING @tmp2   ;

DEALLOCATE PREPARE stmt ;

use test;

delimiter //

create function strSplit(

   pi_str   varchar(100)

,  pi_delim varchar(5)

,  pi_pos   int

)

returns varchar(100)

charset utf8

deterministic

begin

   return replace(substring(substring_index(pi_str, pi_delim, pi_pos), length(substring_index(pi_str, pi_delim, pi_pos-1)) + 1), pi_delim, '');

end //

delimiter ;

select strSplit('A,B,C,D,E', ',', 2) ex1

      ,strSplit('A1,B2,C3,D4,E5',',',5) ex2

      ,strSplit('A1,B2,C3,D4,E5',',',9) ex3;

프로시저 생성 시

OUT을 받을 것라면

프로시저 내에서 DECLARE po_result INT 를 선언하지 않아야 한다.

DROP PROCEDURE getName;

DELIMITER //

CREATE PROCEDURE getName

 (OUT po_result VARCHAR(50))

BEGIN

DECLARE v_sqlstate VARCHAR(5) DEFAULT '00000';

DECLARE v_msg VARCHAR(500);

DECLARE v_err_no INT;

--DECLARE po_result INT signed DEFAULT 0;    -- select로 po_result를 받을 거라면 선언하고 set로 받을거라면 선언하면 안됨.

DECLARE EXIT HANDLER FOR SQLEXCEPTION, SQLWARNING

BEGIN

GET DIAGNOSTICS CONDITION 1 v_sqlstate = RETURNED_SQLSTATE, v_err_no = MYSQL_ERRNO, v_msg = MESSAGE_TEXT;

ROLLBACK;

INSERT INTO ADMIN_DB.log_error (partkey_month, procedure_name, sql_state, msg, reg_date) 

VALUES (month(sysdate()), "usp_ins_skill_index", v_sqlstate, v_msg, sysdate());

SET po_result = v_err_no * -1;

END;

BEGIN

SELECT no INTO @var1 FROM CopyT WHERE no = 1;

INSERT INTO CopyT1 VALUES (10000);

END;

  SET po_result= 0;

END//

DELIMITER ;

MySQL에서는  두   가지  방법으로   사용자가  정의한  변수를   지원한다.  변수이름은 

alphanumeric 문자와 '_', '$', '.'로 구성된다. 변수에 초기값이 지정되지 않으면, NULL이 디

폴트이며, integer, real, string 값을 저장할 수 있다. 변수이름은 버전 5.0부터는 대·소문자 

구분이 없다.



방법1)

SET 문을 사용하여 변수를 설정

 SET @variable={integer expression | real expression | string expression }

        [,@variable=...]

【예제】

mysql> set @t3=5;

mysql> select @t3;

+------+

| @t3  |

+------+

| 5    |

+------+

mysql> 



방법2)

@variable:=expr 문을 사용하여 설정

【예제】

mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;

      +----------------------+------+------+------+

      | @t1:=(@t2:=1)+@t3:=4 | @t1  | @t2  | @t3  |

      +----------------------+------+------+------+

      |                    5 | 5    | 1    | 4    |

      +----------------------+------+------+------+

출처 - http://flashcafe.org/index.php?mid=mysql_study&listStyle=webzine&document_srl=3999

===================================================================================

[출처] Datetime 필드 기준 파티션 자동 관리 프로시저 (MySQL)|작성자 돌고래사육사

http://seuis398.blog.me/70186283219

MySQL에서 파티셔닝은 성능 문제로 권장되는 옵션은 아니다.

하지만, 로그 데이터와 같이 주기적으로 과거 데이터를 삭제해야 되는 경우라면 파티셔닝이 매우 편리하다.

신규 파티션 추가와 오래된 파티션 삭제를 수작업으로 하기는 번거로울테니, 간단하게 이 과정을 자동화 해 줄 프로시저를 만들어 봄~

[파티션 관리 요건]

- 어떠한 이유에서든지 프로시저가 동작하지 않은 경우라도 데이터 INSERT 실패가 발생하지 않도록 할 것

- 프로시저가 일정 기간 동작하지 않고 다시 재가동 되는 경우에, 프로시저가 주기적으로 동작했던 것과 동일한 파티션 구조를 생성할 것

- 파티션 삭제시 Table Lock으로 인한 영향을 최소화 할 것

[파티션 생성 프로시저]

[파티션 삭제 프로시저]

[동작 예시]

- 파티셔닝 키 컬럼이 datetime이 아닌 timestamp라면 HIGH VALUE 비교하는 부분 수정 필요 (date 타입은 사용 가능)

- MySQL이 아닌 MariaDB를 사용하는 경우 PARTITION EXCHANGE 부분에서 DB 버전 체크하는 부분 수정 필요

- 적용 대상 테이블은 사전에 RANGE 방식의 파티셔닝 구성이 되어 있어야 하며, MAXVALUE 파티션이 만들어져 있어야 함 

mysql에서는 FEDERATED라는 엔진이 있다.
FEDERATED 테이블은 사용하기 매우 간단하며, 정상적인 경우, 동일한 호스트, 다른 
호스트 상에서 두대의 서버를 구동할 수 있습니다. 즉 FEDERATED 테이블이 동일한 서버가 관리하는 다른 테이블을 사용할 수 있다는 말이죠. 

우선, 여러분이 FEDERATED 테이블을 사용해서 접속하고자 하는 리모트 서버상에 테이블 가지고 있어야 한다. federated 데이터베이스에 리모트 테이블이 있고  그 테이블이 아래와 같이 정의 되었다고 가정하자: 

 CREATE TABLE test_table ( 
    id    INT(20) NOT NULL AUTO_INCREMENT, 
    name  VARCHAR(32) NOT NULL DEFAULT '', 
    other  INT(20) NOT NULL DEFAULT '0', 
    PRIMARY KEY  (id), 
    INDEX name (name), 
    INDEX other_key (other) 
) 
ENGINE=MyISAM 
DEFAULT CHARSET=latin1; 
  
위의 예문은 MyISAM 테이블을 사용하고는 있지만, 테이블은 모든 스토리지 엔진을 사용할 수 있습니다. 
다음에는, 리모트 테이블의 접속하기 위해 로컬 서버에 FEDERATED 테이블을 생성합니다. 

CREATE TABLE federated_table ( 
    id    INT(20) NOT NULL AUTO_INCREMENT, 
    name  VARCHAR(32) NOT NULL DEFAULT '', 
    other  INT(20) NOT NULL DEFAULT '0', 
    PRIMARY KEY  (id), 
    INDEX name (name), 
    INDEX other_key (other) 
) 
ENGINE=FEDERATED 
DEFAULT CHARSET=latin1 

CONNECTION='mysql://root@remote_host:9306/federated/test_table'; 
(MySQL 5.0.13 이전에는, COMMENT 를 CONNECTION 대신에 사용하였습니다.) 
  
이 테이블의 구조는 반드시 리모트 테이블의 구조와 정확히 같아야 하지만, except that the ENGINE 테이블 옵션은 FEDERATED이고 CONNECTION 테이블 옵션은 리모트 서버에 접속하는 방법을 FEDERATED 엔진에 알려주는 연결 스트링입니다. 

FEDERATED 엔진은 federated 데이터베이스에 test_table.frm 파일만을 생성합니다. 

리모트 호스트 정보는 리모트 서버에게 여러분의 로컬 서버가 어디에 접속되어 있는지를 알려 주고, 데이터베이스 및 테이블 정보는 데이터 소스로 사용되는 리모트 테이블이 어떤 것인지를 알려줍니다. 이 예문에서 보면, 리모트 서버는 remote_host 형태로 구동되어야 한다고 가리켜져 있기 때문에, 포트 9306에서, MySQL 서버는 리모트 서버에서 구동되어야 하고 포트 9306에 리스팅 되어야만 합니다. 

CONNECTION 옵션에서의 연결 스트링의 일반적인 형태는 다음과 같습니다. 
scheme://user_name[:password]@host_name[:port_num]/db_name/tbl_name 
이 시점에서 보면, 오직 mysql만이 scheme 값 형태로 지원된다; 패스워드와 포트 번호는 선택 사항입니다. 
아래에 몇 가지 연결 스트링에 대한 예가 있습니다. 

CONNECTION='mysql://username:password@hostname:port/database/tablename' 
CONNECTION='mysql://username@hostname/database/tablename' 
CONNECTION='mysql://username:password@hostname/database/tablename' 

연결 스트링을 지정하기 위한 CONNECTION의 사용은 논-옵티말 (non-optimal)이며 나중에 변경될 예정입니다.FEDERATED 테이블을 사용하는 어플리케이션에 대해서는 이점을 기억해 둡시다. 이러한 어플리케이션은, 연결 정보를 지정하기 위해 포맷이 변경되는 경우에는 수정이 필요할 수도 있습니다. 

연결 스트링에서 주어지는 모든 패스워드는 평이한 텍스트 형태로 저장되기 때문에, EDERATED 테이블에 대해서 SHOW CREATE TABLE 또는 SHOW TABLE STATUS를 사용하는 모든 사용자, 또는 INFORMATION_SCHEMA 데이터베이스에 있는TABLES 테이블을 쿼리하는 모든 사용자가 이것을 볼 수 있게 됩니다.

출처 : http://blog.naver.com/zamzacs/80037978241

1. SQL Server 메모리의 이해

데이터는 디스크에 저장되고 디스크에서 검색을 하는데 디스크 I/O 작업에 많은 리소스를

소비하게 되므로 SQL Server는 디스크 I/O 작업을 효율적으로 관리하기 위하여 버퍼풀의

메모리 구조를 이용한다.

1) SQL Server 메모리 동작 방식

데이터를 조회하게 되면 SQL Server는 버퍼풀에 데이터가 있는지 확인하고 없을 경우

디스크에서 버퍼풀로 데이터를 복사한 후 데이터를 사용한다.

버퍼풀에 데이터가 있으면 디스크에 액세스 하지 않고 버퍼풀의 데이터를 바로 사용한다.

데이터를 변경하게 되면 트랜잭션 로그에는 변경 내역이 즉시 반영되지만 실질적인

데이터 페이지에는 CHECKPOINT 시점의 최종적으로 수정된 데이터만 디스크에 쓰여져

디스크 I/O를 줄여준다.

SQL Server가 사용하는 메모리는 동적으로 관리된다.

처음 시작될 때 SQL Server는 가동에 필요한 최소한의 메모리 공간만 할당 받아서 사용하게 된다.

SQL Server가 운영되는 동안 메모리가 필요할 경우 시스템의 여유 메모리를 할당 받아 사용하고,

사용이 끝나 다른 곳에서 메모리를 요구할 경우 메모리를 반환한다.

2) 32비트 시스템 메모리 특징

32bit 응용 프로그램에서는 총 4GB의 프로세스 주소 공간을 할당할 수 있다.

이중 2GB는 OS의 커널 모드 주소 공간. 2GB는 사용자 모드 주소 공간으로 사용한다.

메모리 옵션을 사용하여 커널 모드 주소 공간을 1GB로 제한하고, 응용 프로그램에 더 할당하거나

AWE 옵션을 활용하여 사용자 모드 주소 공간을 확장하여 응용 프로그램이 더 많은 메모리를

용할 수 있도록 한다.

3) 메모리 설정을 해야 하는 이유

부하가 많은 시스템에서 I/O가 지속적으로 발생하면 SQL Server는 시스템의 메모리를 계속

요구하며 할당 받아 사용하게 되는데 이는 OS나 다른 응용 프로그램의 동작에 영향을 줄 수 있다. 

반대로 OS나 다른 응응 프로그램에서 많은 공간의 메모리를 사용하고 있다면

SQL Server가 할당 받아 사용할 메모리가 줄어들게 된다.

SQL Server의 버퍼풀 메모리가 부족할 경우 잦은 디스크 I/O를 발생시키고, 쿼리를

실행하는데 필요한 최소 메모리를 얻지 못하고 리소스를 대기하는 동안 오류가 발생한다.

2. 메모리 설정 옵션들

1) 부팅 옵션

3GB

32bit 환경에서 4GB 메모리를 사용 중이라면 boot.ini에 /3GB 옵션을 설정해서 운영체제에

1GB를 할당 하고, SQL Server에 3GB를 할당해서 사용할 수 있다.

그러나 16GB를 초과하는 메모리를 사용할 경우에는 가상메모리 주소 할당을 위해 커널 모드에

2GB 이상의 메모리가 필요하기 때문에 /3GB 옵션은 해제해야 한다.

PAE

32bit 운영체제에서 4GB이상의 물리메모리를 사용할 수 있도록 확장

AWE 설정 시 필수 사항

2) 시스템 옵션

LOCK PAGE IN MEMORY

시스템이 디스크의 가상 메모리로 데이터를 페이징 하지 않도록 방지.

OS에서 메모리 반환 요청을 하지 않는다. 

AWE +  LOCK PAGE IN MEMORY 설정을 하면 할당된 메모리를 해제하지 않기 때문에 OS에 메모리를

뺏기지 않는다. 그래서 max server memory를 지정해 주지 않으면 OS가 메모리 부족을 감지할 경우 

buffer pool 영역 이외의 영역이 non-buffer pool 영역에서 메모리를 빼앗기게 때문에 더 심각한 문제가 

발생할 수 있다. 그래서 max server memory  설정을 해야한다. 

32bit 환경에서 4GB 이상 메모리를 사용해야 하는 경우나 64bit 시스템을 사용할 경우 이 옵션을 반드시 설정 해야한다. 

LARGE SYSTEM CACHE

변경 된 데이터 페이지를 물리적인 메모리에 남겨두는 제한을 설정한다.

시스템 캐시를 사용하게 되면 서버의 성능은 향상되지만 애플리케이션에서

사용할 수 있는 가용메모리는 줄어들게 된다.

응용 프로그램이 좀 더 메모리를 사용할수 있게 해주는 옵션임.

http://sqlsql.tistory.com/82

3) SP_CONFIGURE 옵션

min/max server memory

max server memory 까지 메모리를 확보 후 min server memory 까지 메모리를 해제.

min/max server memory를 같게 하여 SQL Server간 메모리 할당 해제에 따른 리소스 최소화.

AWE

4GB를 초과하는 물리적인 메모리를 32bit 주소 공간에 동적으로 할당하는 역할

/PAE 옵션과 함께 사용

확장된 메모리는 버퍼풀로만 매핑해서 활용

4) Trace flag 옵션

845

Lock Page in Memory를 사용할 수 있도록 하는 옵션

SQL Server 구성관리자 -> SQL Server 서비스 -> SQL Server 속성 -> 고급 -> 시작 매개 변수 마지막에 ;-T845 추가 (맞나?..)

836

Max server memory로 지정된 공간까지 버퍼풀 메모리를 확보

AWE모드에서 작동

834

버퍼풀에 할당된 메모리가 Windows 큰 페이지 할당을 사용하도록 한다.

5) 시스템 별 메모리 옵션 설정하기

32bit SQL Server & 32bit Windows Server

/3GB 옵션으로 OS 1GB, 응용 프로그램 3GB 할당

만약 4GB를 초과하는 메모리를 사용한다면 /PAE 옵션을 통해 4GB 메모리 주소 공간을

최대 64GB까지 확장하고, AWE 옵션으로 SQL Server가 확장된 주소 공간을 버퍼풀

영역으로 사용할 수 있도록 설정.

Lock Page in Memory 설정으로 메모리가 페이징 되는 것을 방지.

max server memory 옵션 설정

16GB를 초과하는 메모리를 사용할 경우 3GB 옵션을 제거

64bit SQL Server & 64bit Windows Server

Lock Page in Memory / Max server memory 만 설정

3GB , PAE , AWE 옵션 필요 없음.

32bit SQL Server & 64bit Windows Server(WOW 모드)

OS가 64bit 이기 때문에 내부적인 메모리의 동작 방식은 64bit 시스템을 따라간다.

그래서 PAE 옵션은 필요하지 않다. 하지만 SQL Server는 32bit 시스템 이므로 AWE 모드를

활성화 한다. Lock Page in Memory / max server memory 옵션도 함께 설정한다.

3. MIN / MAX 메모리 설정하기

데이터 캐시를 위한 버퍼풀 영역의 크기만을 의미

SQL Server 전용 머신이라 할지라도 버퍼풀 이외 개체의 메모리 사용량을 예측하고 적절한

크기를 설정한다. 왜냐하면 SQL Server가 메모리를 확보한 후 해제하지 않아 OS나 다른

애플리케이션에서 메모리 부족으로 문제가 발생 하거나 반대로 SQL Server가 메모리를

확보하지 못해 느린 응답 속도를 낼 수 있다.

1) 메모리 크기 별 권장 메모리 설정

2) 메모리 크기와 사용량 분석

-- 시스템메모리상태보기