그림 1. 리눅스와 유닉스 상의 이전 DB2 프로세스 모델
그림 2는 리눅스와 유닉스 상의 새로운 프로세스 모델을 나타낸다.
그림 2. 리눅스와 유닉스 상의 새로운 DB2 프로세스 모델
데이터베이스 서버, 클라이언트, 애플리케이션 간의 통신은 프레임워크에 의해 처리된다. 이러한 유형의 프레임워크는 단지 모든 DB2 서버가 사용하는 프로세스 모델일 뿐이다. 이 프레임워크는 내부적으로 사용되는 데이터베이스 파일이 사용자 또는 데이터베이스 애플리케이션을 방해하지 않게 한다.
EDU(Engine Dispatchable Unit)는 데이터베이스 애플리케이션의 요청 처리, 데이터베이스 로그 파일 읽기, 로그 버퍼의 로그 레코드를 디스크의 로그 파일로 플러시하는 것과 같은 여러 작업 수행을 담당한다. 일반적으로 DB2 서버는 이것을 작업당 개별 EDU로 처리한다. DB2 9.5 이전에는 이러한 EDU는 대부분 유닉스와 리눅스 환경 기반에서는 프로세스로 수행되었고 윈도 환경 기반에서는 스레드였다. 9.5에서는 현재 EDU가 리눅스, 유닉스, 윈도 환경 기반 모두에서 스레드이므로 DB2의 프로세스 모델에서 단일화되었다.
다음은 새 메모리 모델의 이점이다.
- 새 메모리 모델은 더 단순하고 쉽게 구성된다. DB2 Information Center에서 다음 항목을 참조할 수 있다.
- 새 모델은 리소스를 저장한다.
시스템 파일 설명자(file descriptor) 사용이 현저하게 줄어들었다. 프로세스와 스레드에 있어 가장 분명한 차이는 프로세스의 모든 스레드가 동일한 메모리 공간과 시스템 정의 기능(system-defined facility)을 공유한다는 것이다. 기능에는 오픈 파일 핸들(파일 설명자), 공유 메모리, 프로세스 동기화 원본(primitive), 현재 디렉터리가 포함된다. 프로세스 내 모든 스레드는 같은 파일 설명자를 공유할 수 있다. 각 에이전트가 자신의 파일 설명자 테이블을 가질 필요가 없다. - 성능이 향상되었다.
일반적으로 운영체제는 다른 프로세스 간에서보다 같은 프로세스의 스레드 간에 더 빨리 전환(컨텍스트 전환)할 수 있다. 주소 공간을 전환할 필요는 없다. 전역 메모리가 공유되고 새 메모리를 할당할 필요가 없으므로 스레드를 만드는 것이 프로세스를 만드는 것보다 더 간단하고 빠르다. 프로세스 생성은 프로세서 사이클과 메모리 사용량 면에서 볼 때 비용이 많이 든다. - 자동화되고 역동적인 구성 가능 매개변수가 더 많기 때문에 DBA가 수행해야 할 작업이 줄어들었다.
이 내용은 이 글의 프로세스 모델 구성 단순화에서 다룬다. - 프로세스 모델이 이제 세 개 플랫폼(리눅스, 유닉스, 윈도) 모두에서 똑같다.
db2pd로 스레드 모니터링 및 ps 결과와 매핑
DB2 9.5 이전에서는 유닉스와 리눅스 환경에서 ps 시스템 명령 또는 db2_local_ps 명령을 사용하여 전체 활성 DB2 EDU를 나열할 수 있었다. 하지만 DB2 9.5에서는 이러한 명령을 사용하여 db2sysc 프로세스 내의 EDU 스레드를 더 이상 나열할 수 없다. 따라서 DB2 사용자와 DBA가 OS 명령을 사용하여 시스템에서 실행 중인 프로세스를 살펴볼 때 알 수 있는 변경 내용 중 하나가 바로 여러 프로세스와 나란히 있는 하나의 프로세스만 표시된다는 것이다. 이것은 DBA 관점에서 볼 때 예측할 수 있는 관리 변경이다.
$ ps -fu db2ins10
UID PID PPID C STIME TTY TIME CMD
db2ins10 1237176 2109662 0 Feb 28 - 0:12 db2acd 0
db2ins10 1921136 2109662 0 Feb 28 - 0:14 db2sysc 0
db2ins10 2101494 1941686 0 14:22:34 pts/1 0:00 -ksh
db2ins10 2420958 2101494 0 15:25:33 pts/1 0:00 ps -fu db2ins10
|
AIX:
db2sysc 프로세스의 스레드를 모두 보려면(PID = 1921136) 다음과 같다.
Listing 1. AIX 시스템에서 db2sysc 프로세스의 모든 스레드 보기
$ ps -mo THREAD -p 1921136
USER PID PPID TID ST CP PRI SC WCHAN F TT BND COMMAND
db2ins10 1921136 2109662 - A 0 60 26 * 40401 - - db2sysc 0
- - - 1273899 S 0 60 1 f1000100403674b0 410400 - - -
- - - 1327331 Z 0 60 1 - c00001 - - -
- - - 1392805 Z 0 60 1 - c00001 - - -
- - - 1601705 Z 0 60 1 - c00001 - - -
- - - 1814627 Z 0 60 1 - c00001 - - -
- - - 1851457 S 0 60 1 f1000004f010de00 410400 - - -
- - - 1961987 Z 0 60 1 - c00001 - - -
- - - 1974311 Z 0 60 1 - c00001 - - -
- - - 2023571 S 0 60 1 f100010041b401b0 410400 - - -
- - - 2068591 Z 0 60 1 - c00001 - - -
- - - 2179161 Z 0 60 1 - c00001 - - -
- - - 2187515 Z 0 60 1 - c00001 - - -
- - - 2216003 S 0 60 1 - 400400 - - -
- - - 2412647 Z 0 60 1 - c00001 - - -
- - - 2551911 Z 0 60 1 - c00001 - - -
- - - 2592969 Z 0 60 1 - c00001 - - -
- - - 2621455 S 0 60 1 f1000100407f7e30 410400 - - -
- - - 2658531 S 0 60 1 - 418400 - - -
- - - 3031171 Z 0 60 1 - c00001 - - -
- - - 3457047 Z 0 60 1 - c00001 - - -
- - - 3899477 Z 0 60 1 - c00001 - - -
- - - 4157609 Z 0 60 1 - c00001 - - -
- - - 4390991 S 0 60 1 - 400400 - - -
- - - 4636819 Z 0 60 1 - c00001 - - -
- - - 5628153 S 0 60 1 - 400400 - - -
- - - 6783009 Z 0 60 1 - c00001 - - -
|
리눅스:
db2sysc 프로세스의 스레드를 모두 보려면(PID = 1921136) 다음과 같이 한다: ps -lLfp 1921136
이제 DBA의 역할이 더 쉬워졌다. db2pd에서 프로세스와 스레드를 나열하는 기능이 향상되었다. 이제 db2pd 명령을 -edu 옵션과 함께 사용하여 현재 활성인 모든 EDU 스레드를 나열할 수 있다. 이 기능은 유닉스, 리눅스, 윈도 시스템에서 사용할 수 있다.
Listing 2. 리눅스 시스템에서 db2sysc 프로세스의 모든 스레드 보기
$ db2pd -edu
Database Partition 0 -- Active -- Up 1 days 01:05:54
List of all EDUs for database partition 0
db2sysc PID: 1921136
db2wdog PID: 2109662
db2acd PID: 1237176
EDU ID TID Kernel TID EDU Name USR SYS
===================================================================================
1801 1801 2216003 db2agent (idle) 0 0.706935 1.071737
1543 1543 5628153 db2resync 0 0.002641 0.004271
1286 1286 1851457 db2ipccm 0 0.082388 0.044037
1029 1029 2023571 db2licc 0 0.000211 0.001055
772 772 4390991 db2thcln 0 0.000244 0.000105
515 515 2621455 db2aiothr 0 2.740874 6.287562
2 2 1273899 db2alarm 0 0.274076 0.408226
258 258 2658531 db2sysc 0 2.085981 1.379128
|
위로
DB2에서 사용하는 메모리의 양
메모리 사용량을 확인하는 몇 가지 방법은 다음과 같다.
- db2pd -dbptnmem
- db2 get snapshot for applications on sample
- select * from table(admin_get_dbp_mem_usage())
- db2mtrk -a 그리고 db2mtrk -p
다음 정보에 주의한다.
- db2pd는 공유 메모리 계층을 정확하게 표시한다.
- db2pd는 여전히 개인 메모리 할당을 표시하지 못한다.
- db2mtrk는 개인 메모리 할당은 표시하지만 다른 영역 표시에는 약하다.
- 개인 메모리 사용은 이제 관심 대상이 아니다.
- db2pd -dbpntmem의 고수준 보고 기능으로 충분할 수 있다.
db2pd 사용
Listing 2. db2pd 예제
$ db2pd -dbptnmem
Database Partition 0 -- Active -- Up 1 days 01:11:27
Database Partition Memory Controller Statistics
Controller Automatic: Y
Memory Limit: 13994636 KB
Current usage: 76608 KB
HWM usage: 332736 KB
Cached memory: 16064 KB
Individual Memory Consumers:
Name Mem Used (KB) HWM Used (KB) Cached (KB)
========================================================
DBMS-db2ins10 46784 46784 10048
FMP_RESOURCES 22528 22528 0
PRIVATE 7296 7296 6016
|
필드 정보:
INSTANCE_MEMORY 구성 매개변수를 AUTOMATIC으로 설정하는 경우 Controller Automatic이 Y로 설정된다. 이것은 데이터베이스 매니저가 메모리 소비의 상위 한계를 자동으로 결정함을 의미한다.
Memory Limit는 DB2 서버가 사용할 수 있는 메모리의 상한값이다. 이 값은 INSTANCE_MEMORY 구성 매개변수의 값이다.
Current usage는 현재 서버가 소비하는 메모리의 양이다.
HWM usage는 HWM(High Water Mark 고수위 표시) 또는 db2start 명령이 실행되어 데이터베이스 파티션이 활성화된 이후 소비된 최고 메모리 사용량이다.
Cached memory는 현재 사용량으로서 현재 사용되지는 않지만 성능을 위해 향후 메모리 요청에 대비하여 캐시된 메모리의 양이다.
개별 메모리 소비자(Memory Consumer) 섹션:
- DB2 서버 내에 등록된 모든 메모리 "소비자"가 사용하고 있는 총 메모리의 양과 함께 나열된다.
- Name: 메모리 "소비자"의 간략하고 특징적인 이름. 예제에 다음 사항이 포함되어 있다.
- APPL-<dbname>: 데이터베이스 <dbname>이 사용한 애플리케이션
- DBMS-xxx: 전역 데이터베이스 매니저 메모리 요구 사항
- FMP_RESOURCES: db2fmps와 통신하는 데 필요한 메모리
- PRIVATE: 기타 개인 메모리 요구 사항
- FCM_RESOURCES: Fast Communication Manager 리소스
- LCL-<pid>: 로컬 애플리케이션과 통신하는 데 사용되는 메모리 세그먼트
- DB-<dbname>: 데이터베이스 <dbname>이 사용하는 데이터베이스 메모리
- Mem Used(KB): 현재 해당 소비자에 할당된 메모리의 양
- HWM Used(KB): 소비자가 사용한 고수위 표시 또는 최고 메모리
- Cached(KB): Of the Mem Used(KB), 현재 사용되고 있지 않지만 향후 메모리 할당에 즉시 사용할 수 있는 메모리의 양.
db2 get snapshot 사용
Listing 4. db2 get snapshot 예제
$ db2 get snapshot for applications on sample
Memory usage for application:
Memory Pool Type = Application Heap
Current size (bytes) = 65536
High water mark (bytes) = 65536
Configured size (bytes) = 1048576
Agent process/thread ID = 6463
Agent Lock timeout (seconds) = -1
Memory usage for agent:
Memory Pool Type = Other Memory
Current size (bytes) = 196608
High water mark (bytes) = 196608
Configured size (bytes) = 16710107136
|
SQL 사용
Listing 5. SQL 사용 예제
$ db2 "select * from table(admin_get_dbp_mem_usage())"
DBPARTITIONNUM MAX_PARTITION_MEM CURRENT_PARTITION_MEM PEAK_PARTITION_MEM
-------------- -------------------- --------------------- --------------------
0 14330507264 340590592 340852736
1 record(s) selected.
|
db2mtrk 사용
Listing 6. db2mtrk -a 예제
$ db2mtrk -a
Tracking Memory on: 2008/02/29 at 15:51:00
Application Memory for database: SAMPLE
appshrh
128.0K
Memory for application 546
apph other
64.0K 192.0K
Memory for application 545
apph other
64.0K 192.0K
Memory for application 544
apph other
64.0K 320.0K
Memory for application 543
apph other
64.0K 576.0K
Memory for application 547
apph other
64.0K 192.0K
|
Listing 7. db2mtrk -p 예제
$ db2mtrk -p
Tracking Memory on: 2008/02/29 at 15:51:37
Memory for agent 6463
other
192.0K
Memory for agent 6206
other
192.0K
Memory for agent 5949
other
320.0K
Memory for agent 2094
other
576.0K
Memory for agent 6720
other
192.0K
|
참고: 기본적으로 INSTANCE_MEMORY를 AUTOMATIC으로 설정하면 인스턴스에게 RAM의 비율에 있어 최대가 허용된다. 범위는 작은 시스템인 경우 75%이고 더 큰 규모의 시스템인 경우 95%다. 여기에는 단일 인스턴스에 대한 모든 로컬 파티션이 포함된다.
db2 get dbm cfg show detail|grep INSTANCE_MEMORY
Size of instance shared memory(4KB)(INSTANCE_MEMORY)=AUTOMATIC(3498659)AUTOMATIC(3498659)
|
다른 데이터베이스 파티션에 대해 다른 INSTANCE_MEMORY 값을 영구적으로 설정할 수 없다. DB2 Express 라이선스의 경우 INSTANCE_MEMORY의 상한값은 4GB 메모리(1,048,576 * 4KB 페이지)로 제한된다. 이 한도보다 더 큰 값으로 INSTANCE_MEMORY 구성 매개변수를 업데이트하려고 하면 라이선스에 허용되는 제한 범위가 표시되면서 SQL5130N 리턴 코드와 함께 실패한다. 다른 라이선스 유형에는 추가 제한 사항이 없다. INSTANCE_MEMORY를 RAM보다 큰 값으로 설정할 수 없다.
위로
DPF 백업과 복구 문제 제거
각 파티션은 다른 타임스탬프를 가져온다.
이전 DB2 버전의 경우:
$ db2_all " db2 backup db test"
Backup successful. The timestamp for this backup image is : 20080304124529
eva88: db2 backup db test completed ok
Backup successful. The timestamp for this backup image is : 20080304124544
eva88: db2 backup db test completed ok
Backup successful. The timestamp for this backup image is : 20080304124554
eva88: db2 backup db test completed ok
|
반면 DB2 9.5에서는 BACKUP 명령이 향상되어 데이터베이스 파티션의 목록을 표시할 때 단일 시스템 뷰를 제공한다.
$ db2 backup db test on all dbpartitionnums
Part Result
---- -------------------------------
0000 DB20000I The BACKUP DATABASE command completed successfully.
0010 DB20000I The BACKUP DATABASE command completed successfully.
Backup successful. The timestamp for this backup image is : 20080304135942
|
롤 포워드하는 동안 필요한 로그 파일을 확인하는 방법
$ db2 rollforward db test to 2008-03-01 and stop
SQL1275N The stoptime passed to roll-forward must be greater than or equal to
"2008-03-04-12.45.54.000000 UTC", because database "TEST" on node(s) "0,1"
contains information later than the specified time.
$ db2 rollforward db test to 2008-03-04-12.45.54.000000 and stop
DB20000I The ROLLFORWARD command completed successfully.
|
위 예제는 롤 포워드하는 동안 명령에서 지정한 PIT(지정 시간)가 이전 시간이거나 빠른 경우 오류 메시지가 표시되는 것을 보여준다(SQL1275N). 오류 메시지에 올바른 PIT가 표시된다. INCLUDE 로그와 함께 BACKUP 사용을 고려해 볼 수도 있다. 하지만 DPF 데이터베이스에서 BACKUP을 INCLUDE 로그와 함께 사용하면 오류 메시지가 생성된다(SQL2032N). 따라서 이 옵션은 사용할 수 없다.
반면 DB2 9.5에서는 ROLLFORWARD 명령과 함께 "TO END OF BACKUP" 절을 사용하여 파티션된 데이터베이스에 있는 모든 파티션을 최소 복구 시간으로 롤 포워드할 수 있다. 최소 복구 시간은 롤 포워드하는 동안 데이터베이스에 일관성이 있는 경우(데이터베이스 카탈로그에 나열된 오브젝트가 디스크에 있는 오브젝트와 실제로 일치하는 경우) 가장 빠른 지정 시간이다. 데이터베이스를 롤 포워드할 올바른 지정 시간을 수동으로 결정하기는 어려우며 특히 파티션된 데이터베이스의 경우 더욱 어렵다. 이 경우 "END OF BACKUP" 옵션을 사용하면 작업이 쉬워진다.
$ db2 rollforward db test to end of backup and stop
DB20000I The ROLLFORWARD command completed successfully
|
위로
사용자 한도(user limits)의 주요 사항
사용자 한도는 셸의 리소스 사용에 대한 다양한 제한 사항을 설정하거나 표시한다. 이러한 제한을 설정하여 결함 있는 셸 스크립트가 자체적으로 무제한 복사를 시작하는 것을 방지하거나 시스템의 사용자가 무한 실행하는 프로세스를 시작하는 것을 막을 수 있다. 하지만 어떤 제한을 설정할 것인가? 다음은 리소스에 대한 다양한 제한 사항에서 고려해야 할 몇 가지 사항이다.
- db2 start 시 데이터와 nofile에는 제한이 없다.
- 스택 제한은 관계가 없다. DB2가 자신만의 스택 공간을 만들기 때문이다(AGENT_STACK_SZ dbm cfg)
64비트 유닉스
기본값 : 4 MB
최소값 : 1 MB
최대값 : 128 MB
32비트 리눅스
기본값 : 1MB
최소값 : 64 KB
최대값 : 4MB
- MAXFILOP는 파티션당 데이터베이스의 최대값이다. 32비트에 대한 ~32K 및 64비트에 대한 ~64K의 새 상위 기본값이 있다.
- 현재 ulimit 설정값(또는 AIX의 경우 ulimit를 unlimited로 설정하면 8GB임). DB2는 무제한의 코어 제한(core limit)을 무시한다. 코어를 8GB보다 크게 하려면 코어 제한을 명시적으로 8GB보다 큰 어떤 값으로 설정해야 한다. 하지만 무제한(unlimited)으로 지정할 수 없다.
위로
프로세스 모델 구성 단순화
이 절에서는 구성 매개변수가 DB2 9.5에서 다르게 동작하는 것을 보여준다. 기본값과 범위가 이전과 달라졌으므로 유의한다.
그림 3. 구성 매개변수
성능이 중요하며 보호되지 않은(unfenced) 외부 저장 프로시저(SP) 또는 사용자 정의 함수(UDF)가 있는 경우 스레드가 안전한지(thread-safe) 확인해야 한다. 마이그레이션할 때는 외부의 보호되지 않은 SP와 UDF가 모두 보호된다.데이터 통합의 경우 규칙에 따라 보호되지 않은 SP 및 UDF의 스레드가 이미 보호되지만 강제 적용할 수 없다. 스레드가 보호되지 않는 SP 또는 UDF를 다중 스레드 프로세스에서 실행하면 예기치 않은 문제가 발생할 수도 있다. 따라서 마이그레이션 프로시저와 같이 보호되지 않는 상태로의 변환을 사용하기 위한 스크립트를 만들어야 한다.
끝내기 전에 새로 도입된 스레드와 프로세스에 대해 간단히 살펴보자.
- db2thcln(스레드 스택 정리): EDU가 종료되면 리소스를 재활용한다(유닉스에만 해당).
- db2aiothr(aio 컬렉터 스레드): 데이터베이스 파티션에 대한 비동기 I/O 요청을 관리한다(유닉스에만 해당).
- db2alarm(알람 스레드): 요청한 타이머가 만료되면 EDU에 알린다(유닉스에만 해당).
- db2vend(보호되는 공급업체 프로세스): EDU를 대신하여 공급업체 코드를 실행한다. 예를 들어 로그 보관을 위한 사용자 종료 프로그램을 실행한다(유닉스에만 해당).
- db2extev(외부 이벤트 핸들러 스레드): SIGUSR2와 동일
- db2acd: Health Monitor 프로세스
마지막으로 DB2 9.5로 이동하는 경우 현재 사용 중인 애플리케이션에 영향을 미치는가?
절대로 그렇지 않다. 내부 변경 내용은 애플리케이션에 전혀 영향을 주지 않는다. 실제로 관리 및 애플리케이션 프로그래밍 측면에서 볼 때 대부분 투명하다.