보통 DB2에서 테이블 생성 시 자동증가 컬럼 생성을 할 수 있다.
생성문은 대략 아래와 같다.
=======================================================================================
CREATE TABLE DONGBUCNI.TABSAMPLE (
COLUMN1 INTEGER NOT NULL GENERATED ALWAYS
AS IDENTITY (START WITH 1, INCREMENT BY 1, CACHE 20,
MINVALUE 0, MAXVALUE 2000000000, NO CYCLE, NO ORDER)
);

위와 같은 상황에서 데이터가 차곡차곡 쌓이며 운영을 하다가 별도의 테스트
테이블로 데이터 Loading 을 할 필요가 있을때 다음과 같은 주의 사항이 필요하다.
보통 일반적인 Load 문은 아래와 같다.

load from TABSAMPLE .ixf of ixf replace into DONGBUCNI.TABSAMPLE nonrecoverable

GENERATED 구성된 테이블에 위와 같이 일반적인 Load 방식으로 실행하게 되면 그컬럼값에
에러가 팍팍 떨어진다.

그럴경우 다음과 같은 modified 옵션을 통하여 Loading 을 하기 바란다.

load from TABSAMPLE .ixf of ixf modified by GENERATEDOVERRIDE replace into DONGBUCNI.TABSAMPLE nonrecoverable

modified by GENERATEDOVERRIDE 옵션은 아래와 같이 설명된다.
컬럼값의 시퀀스가 흐트러지지 않고 원본 그대로의 값으로 override 되는 옵션이다.


DB2 V9.5부터 Tivoli System Automation Multiplaform 제품이 포함되어 DB2 설치 시 TSAMP가 같이 설치된다. (설치 옵션에서 –f NOTSAMP 옵션을 주면 TSAMP가 설치되지 않는다)

TSAMP 는 DB2 HADR이 구성된 이중화 환경에서 같이 많이 사용되는데 최근 DB2 HADR 관련 기술지원을 하면서 TSAMP 버전에 대해 확인이 필요해 어떻게 확인해야되는지 찾아본 적이 있다.

pureScale이 탑재된 V9.8에서는 설치이미지에 db2cktsa라는 쉘이 있어서 설치이미지에 포함된 TSAMP버전과 OS에 설치된 TSAMP 버전을 확인할 수 있었다. 그런데 V9.7에서는 이 쉘이 빠져있어서 TSAMP 버전 확인이 어렵다.

이미 설치된 TSAMP버전은 OS명령어 (리눅스 경우는 rpm –qa, AIX는 lslpp  -l, 등)을 통해 확인을 한다.

 

리눅스 명령어 (예)

#> rpm -qa | grep -i sam.sappolicy

 

DB2 설치 이미지에 포함된 TSAMP 버전은 다음과 같이 확인한다.

#> cd DB2설치_파일/db2/운영체제명/tsamp/운영체제명/CPU타입/

#> ls –al sam*

      sam-3.1.0.6-10046.i386.rpm

현재 상황을 정리하여 IBM LAB에 내부적으로 db2dump파일을 참조로 PMR Open했다
부디 좋은 결과 및 원인이 나와서 빨리 적용하였으면 한다.

수십번의 PureScale 의 설치 및 구성 작업이다.(한20번은 한것 같다)
이제는 눈감고도 설치가 가능할듯하다. 또한 덕분에 OS 커맨드도 다시 익히게 되었다.
여하튼 어제 DB엔진이 주저앉는 내용을 diag.log를 분석해본 결과 아래의 메세지를 확인할 수 있었다.
====================================================================================
2011-08-10-10.49.04.071637+540 I209380A547          LEVEL: Error
PID     : 1069300              TID  : 19791         PROC : db2sysc 0
INSTANCE: db2sdin1             NODE : 000
APPHDL  : 0-54                 APPID: *N0.db2sdin1.110810014834
AUTHID  : DB2SDIN1
EDUID   : 19791                EDUNAME: db2agntp 0
FUNCTION: DB2 UDB, base sys utilities, sqleagnt_sigsegvh, probe:9
MESSAGE : Error in agent servicing application with PRODUCT SIGNATURE:
DATA #1 : Hexdump, 8 bytes
0x07800000062F66D4 : 5351 4C30 3930 3834                        SQL09084
=====================================================================================
SQL09084의 내용을 찾아본 결과
IC74943: DB2_MEMORY_PROTECT ON PURESCALE, SIGNAL #11 ON CREATE DB 을 확인하였다(실제 우리의 상황과는 직접적인 관계가 없는 듯하나 참고로 넣는다.)
다음의 APAR를 참고하기 바란다.

APAR status
OPEN
Error description
DB21085I  Instance "regres3" uses "64" bits and DB2 code release
"SQL09084"
with level identifier "09050107".
Informational tokens are "DB2 v9.8.0.4", "s110227", "IP23283",
and Fix Pack
"4".
Product is installed at "/home/regres3/sqllib".
$ db2set DB2_MEMORY_PROTECT=YES

$ db2start
03/09/2011 12:00:20     1   0   SQL1063N  DB2START processing
was successful.
03/09/2011 12:00:22     2   0   SQL1063N  DB2START processing
was successful.
03/09/2011 12:00:22     0   0   SQL1063N  DB2START processing
was successful.
SQL1063N  DB2START processing was successful.

$ db2 create db aabbcc
SQL1032N  No start database manager command was issued.
SQLSTATE=57019

Signal #11
<SignalDetails>
Signal #11 (SIGSEGV): si_addr is 0x0700000065032020, si_code is
0x00000034
</SignalDetails>
<SignalHandlers>
</SignalHandlers>
$
Stack traceback unavailable.

Real stack is

<StackTrace>
-------Frame------ ------Function + Offset------
0x090000001F4B6F0C sqlpcLSN
0x090000001F4E6B84 sqlbgbLatchPageForWARM0xB04
0x090000001F4E7AF0 sqlbgbProcessTPL
0x090000001ECE9974 sqlpWriteToLog
0x090000001ECF5900 sqlpWriteLR
0x0900000024575A48 sqlpWriteLR
0x0900000024576170 sqlptwpl
0x090000001F7B78E0 sqlpxcm1
0x090000001F7A58B0 sqlptfrg
0x090000001F6C4DD0 sqlrr_appl_term
0x090000001E25C8EC AppStopUsing
0x0900000023D1DFAC sqleStartDb
0x0900000023D1FB38 sqleCreateDb
0x09000000245BFA00 sqleCreateEntries_sd
0x09000000245C0978 sqlecrea_agent_sd
0x09000000245B6D04 sqleSubCreateDb
0x0900000021B0C310 sqleSubRequestRouter
0x0900000021B14300 sqleProcessSubRequest
0x090000001DE16CB4 RunEDU
0x090000001DE04828 EDUDriver
0x090000001DE04B5C sqlzRunEDU
0x090000001DA1AA58 sqloEDUEntry
</StackTrace>

다시 설치 및 구성이 잘되었던 픽스팩3 , hdisk 의 Shared영역을 다른 부분으로 설치 후 DB를 만들어 보아도 같은 증상 이었다.아~~ 무엇이 문제일까? DISK , OS
25~6번의 설치와 DB구성 후 약간의 허무함을 느꼈다. 이것이 진정 오라클의 RAC를 견주는 제품이란 말인가?
다음에는 OS엔지니어와 함께 OS , DISK 구성을 다시 해야 하겠다.

OS 엔지니어의 도움으로 HDISK 를 다시 재구성했다.
오~ 깔끔하게 설치 및 클러스터 파일 시스템을 구성했다.
다음은 클러스터 파일 시스템 구성 명령어 이다

1) db2cluster -cfs -create -filesystem db_home -disk /dev/hdisk4 -mount /dbcni/dbhome
2) db2cluster -cfs -create -filesystem db_storage -disk /dev/hdisk2 -mount /dbcni/storage
3) db2cluster -cfs -create -filesystem db_tnxlog -disk /dev/hdisk5 -mount /dbcni/tnxlog

여기서 cluster 의 구성은 root 유저로 해야 한다.
물론 아래와 같이 db2 instance에게 권한은 주어야 겠죵~~

 1) chown -R db2sdin1:db2iadm1 /dbcni/dbhome
 2) chown -R db2sdin1:db2iadm1 /dbcni/storage
 3) chown -R db2sdin1:db2iadm1 /dbcni/tnxlog

자~ 이제 DB를 생성해 보자
과거에는 2node 구성으로 2member , 2cf 에 DB생성까지 완료 했지만
이제는 3node 2member , 1cf로 구성된 Purescale에 DB를 생성 하겠다.

 1)  db2 create database cnidb on /dbcni/storage dbpath on /dbcni/dbhome

두둥~~~
에러가 아니라 DB엔진이 내려갔다. 뭐야~~ 이건.
픽스팩4의 버그가 아직 있단 말인가? 하지만 예전 DB구성 성공까지 진행 되었던
픽스팩3도 마찬가지였다
구성된 클러스터에 DB만 생성하면 DB엔진이 주저 앉는다.
아~~ 이런








김우용 기자 yong2@zdnet.co.kr 2011.07.19 / AM 08:34

오라클의 차세대 아이태니엄 프로세서 SW개발 중단 발표 후 HP와 오라클의 진흙탕 싸움이 한창이다. 갖은 비난과 설전을 주고받는 두 회사 사이에서 'HP 유닉스 서버 + 오라클DB'를 사용하는 고객도 바빠졌다. 유사 시에 대비한 선택지와 대안마련에 골몰하고 있는 것이다.

 

미국 조사업체 451그룹의 다니엘 쿠스네츠키 애널리스트는 최근 미국 지디넷을 통해 HP 유닉스 서버와 오라클 DB를 사용중인 고객들이 취할 수 있는 방법과 그에 따른 고려사항을 소개했다.

 

오라클과 HP 틈바구니에 낀 고객들이 택할 수 있는 길은 4가지다. ▲어떤 것도 하지 않고 기다린다 ▲HP 아이태니엄 플랫폼을 유지하고 오라클 SW를 교체 ▲오라클 SW를 유지하고, 하드웨어를 교체 ▲하드웨어와 SW 전체 교체 등이다.

 

모든 회사들의 IT환경이 복잡해진 이래, 미리 준비된 단일 솔루션은 없다. 각 옵션 별로 명심해야 할 고려사항들을 알아보자.

 

▲ 아이태니엄

■오라클과 HP의 합의를 기다린다

 

일부 기업들은 현재 운영중인 시스템을 유지하길 원한다. 그들은 더는 기능을 유지할 수 없는 경우에만 대안 마련에 들어갈 것이다. 움직이는 시점은 현 솔루션의 유지비용이 시스템 이전비용보다 높아질 경우다. 이는 단기적인 처방일 수 있다. 직접적인 움직임에 돌입하지 않더라도 장기적인 솔루션을 찾아보는 것이 의사결정자에게 현명한 일이다.

 

■HP서버를 유지하고 오라클SW를 교체

 

이는 HP 유닉스 시스템을 유지하길 원하는 고객들에 해당되는 선택지다. 이같은 고객들은 오라클 DB가 현재 시스템에서 지원하지 않으므로 SW를 교체하게 된다. 이는 전혀 다른 DB 플랫폼으로 이동하는 것을 의미한다.

 

고객이 직면한 문제은 DB 솔루션이 가장 개발하기 복잡한 SW란 점이다. 고객이 원하는 성능과 확장성을 달성하기 위해 DB업체는 메모리 관리, 파일시스템, 클러스터링, 운영체제(OS) 등을 지원하기 위한 몇가지 특징을 반드시 갖춰야 한다.

 

적합성을 달성하는 것은 쉽지 않은 일이다. 고객들은 다른 DB로 교체할 때 쉽게 이전하는 방법을 찾는다. 이전 비용을 최소화하는 것에 대부분의 초점이 맞춰진다.

 

우선 고려해할 것은 호환성 높은 DB 제품을 찾는 것이다. 이는 고객에게 맞춤화된 애플리케이션이 이전 완료 이후에도 작동해야 하기 때문이다.

 

반면, 우수한 이전 도구와 상대적으로 힘이 덜드는 프로세스를 만들어내는 서비스를 제공하는 공급업체를 택할 수도 있다. 고객이 패키징된 SW를 사용하고, 맞춤형 애플리케이션을 거의 사용하지 않을 경우 유효하다. HP와 IBM 모두 이같은 시나리오에서 적합한 후보자임을 자청한다.

 

다행히 오라클에 필적하는 DB업체가 다수 존재한다. 오픈소스인 포스트그레SQL(PostgreSQL) 기반 DB를 제공하는 엔터프라이즈DB가 대표적이다. 오라클 경쟁사인 IBM DB2 역시 오라클과 호환성을 제공한다. 당연히 두 회사의 DB 모두 HP 아이태니엄 유닉스 서버를 지원한다.

 

여기서 또한번 고려해야 할 사항이 있다. 고성능 혹은 우수한 이전도구 및 서비스를 제공하는 교체는 ▲스크립팅 언어 ▲펑션 ▲트리거 ▲축적된 절차 ▲표준 패키지 라이브러리 ▲사용자 개발패키지나 컨버트 방법을 지원할 능력 등을 체크해야 한다.

 

이 카테고리에 고객들은 SQL 문서를 처리하기 위한 DB 서버 교체가 필수적이다. 기존 DB가 수행하던 버그 색출, 데이터 수집과 같은 기능을 동일하게 제공해야 한다. 그만큼 DB 호환성은 이루기 어려운 부분이다.

 

경쟁사들이 90%의 호환성을 제공한다고 해도 장애물은 남는다. 고객의 애플리케이션 포트폴리오가 교체하는 DB와 기존 DB 사이에서 90% 호환된다면 이전작업은 어렵지 않다. 반대로, 고객의 애플리케이션이 DB 기능의 10%만 사용할 경우, 새로운 DB에서 이를 지원하지 않으면 이전작업은 어려워진다.

 

이같은 여러 장애물을 넘어 성공적인 DB이전을 제공하려면 공급업체들은 복제나 제3의 기능으로 지원하는 방법을 제공해야 한다.

 

또다른 고려사항은 각 DB업체들이 제공하는 이전 프로그램과 능력이다. 어떤 회사들은 새로운 DB플랫폼과 기존 DB 플랫폼 간 호환성보다 새로운 능력에 주목할 수 있다.

 

엔프라이즈DB의 강점은 오픈소스인 포스트그레SQL 기반의 DB다. 이 회사는 저렴한 가격과 고성능, 충분한 호환성을 제공한다고 강조한다.

 

IBM의 강점은 회사에 대한 브랜드 인지도다. DB2 이전으로 IBM만의 특징, 기능, 성능, 신뢰성을 장점으로 내세운다. IBM은 또한 세계에 광범위하게 퍼진 파트너사들이 가진 지원 프로그램과 도구를 제공한다고 강조한다.

 

IBM의 광범위한 지원범위는 엔터프라이즈DB에서 제공하지 못하는 부분이다. 엔터프라이즈DB는 아직 세계 곳곳에 퍼지지 못하고 있다.

 

■하드웨어 교체, 함께 가는 SW

 

DB 플랫폼을 유지하고 하드웨어를 교체하는 것은 시스템뿐 아니라, 매니지먼트 SW, 개발도구, 애플리케이션 SW를 교체하는 것을 의미한다. 서버에 연결된 스토리지 디바이스 역시 교체대상이다.

 

오라클 하드웨어는 비용적인 측면에서 접근가능하다. 오라클이 HP 아이태니엄 서버를 자사의 썬서버로 교체하길 원한다는 것은 공공연한 사실. HP 역시 이점을 비도덕적이라며 비난한다. 그러나 오라클 서버로 교체하는 것이 유일한 옵션은 아니다.

 

HP는 당연히 고객들이 자사의 유닉스 고객으로 남길 원한다. 하지만, 고객이 하드웨어 교체를 원할 경우 차선책으로 유닉스 대신 X86서버로 플랫폼을 교체할 것을 제안할 것이다. HP의 하이엔드 x86서버는 오라클 DB를 지원하기 때문이며, 오라클도 인텔 x86 프로세서 ‘제온’을 사용하는 기업이기 때문에 SW지원 중단이란 시나리오는 통하지 않는다.

 

IBM은 광범위한 이전 방법을 제안한다. IBM은 유닉스 서버인 P시리즈뿐 아니라, x86서버인 x시리즈, 메인프레임 z시리즈 등도 보유했다. 여기에 DB2 이전을 함께 제안한다.

 

이 회사는 엔터프라이즈 메인프레임에서 제공하는 경험이 더 좋은 확장성, 신뢰성, 사용 용이성을 제공한다고 강조한다. 또한 서버 메이크오버 프로그램을 통해 적합한 하드웨어 플랫폼을 찾아주고, 구축 및 이전작업을 돕는다.

 

IBM은 썬이나 HP의 제안보다 훨씬 강력하다고 주장한다. IBM은 자사의 시스템이 HP 아이태니엄 시스템, 썬 스팍 시스템보다 더 높은 성능을 낸다는 점을 지적하고 있다. 또한 HP와 오라클 썬 스팍 서버에서 수천건의 이전 사례를 만들었다는 점도 강조된다.

 

■이상적인 이전 솔루션은 무엇인가?

 

이상적인 이전작업을 위해 다음과 같은 고려사항을 따져야 한다.

 

① 서버의 범위를 폭넓게 고려하라. 서버의 선택은 작은 것부터 매우 큰 것까지 범위를 아우른다.
② 소프트웨어 스택은 그들의 고유한 상황에 필요한 제품을 찾아 선택하라.
③ 무료 혹은 저가 서비스는 최선의 코스를 결정하는데 도움을 줄 수 있다. 소유권의 지속적인 비용을 감소하는 결정을 포함한다. 모든 SW라이선스부터 IT관리자와 개발자 교육, 이전 콘셉트의 입증 등이 비용에 포함된다.
④ 하드웨어와 소프트웨어의 묶음 제공은 플랫폼 이전작업을 단순화시킨다. 만약 공급업체가 보상판매 프로그앰을 운영할 경우도 도움을 준다.
⑤ 업체가 제공하는 전문서비스와 도구는 이전을 쉽고, 재빠르고, 비용효율적으로 달성하도록 한다.

 

고객들은 자신의 고유한 요구사항을 해결 할 수 있는 선택지를 최우선으로 고려해야 한다. 하드웨어와 소프트웨어의 안정성을 유지하고, 강력한 기능을 제공하면서, 호환성도 높아야 한다.

'News' 카테고리의 다른 글

[정보] IBM pure System  (0) 2012.11.20
[뉴스] 오라클-HP 갈등 틈에 IBM '윈백 공세'  (0) 2011.07.11
dd 명령어 및 pv를 clear 후 설치는 완료 되었다.
다시 기쁜 마음으로 DB구성을 하려는 순간~~~ cluster 에러가 발생 하였다
이건 뭐~ 할때 마다 상황이 틀려지나~~~ 아~~
에러는 다음과 같은 메세지를 내면서 cluster가 구성되지 않았다.
No Available PR Key 확인을 해보니 각 hdisk 마다 PR Key 가 있는데 lsattr 로 조회시
구성 부분이 none으로 표시 되었다(PR Key 는 각자 검색해 보시길~~)
그림을 첨부한다.


OS 엔지니어의 도움으로 몇번을 시도 해보았지만 같은 결과를 보여주었다.
할 수 없이 기존 디스크의 구성을 다 뭉개 버리고 재구성을 하기로 하였다.
아~~ PureScale의 이런 노고가 언젠가는 빛을 바라길 기원한다.

‘IBM DB2 UDB for LUW’라는 용어에서 ‘LUW’의 의미는 ‘Linux, Unix, Windows’의 약어이며, 이는 DB2가 리눅스, 유닉스, 윈도우 3가지 플랫폼을 모두 다 지원한다는 의미이다.

그러나, 현재까지 DB2는 주로 Enterprise 용도로 많이 쓰여왔기 때문에 윈도우나 리눅스보다는 유닉스 환경 (주로 AIX) 에서 많이 사용되어 온 것이 사실이다.

따라서, 현업에서 DB2 고객지원을 원활하게 하기 위해서는 평소에 유닉스 환경에서 여러 가지 DB2 테스트를 해보는 것이 가장 좋으나, 대개의 경우 유닉스 서버는 (더군다나 IBM 서버의 경우) 다음과 같은 이유로 개인이 마음대로 사용할 수 없는 것이 현실이다.

1. 유닉스용 서버, 특히 AIX용 서버인 pSeries 서버는 비싸다.

2. 비싸다 보니 많은 서버를 보유하기가 현실적으로 어렵다.

3. 그러다 보니, 서버 한대를 여러 사람/어플리케이션이 사용하여 리소스가 딸린다.

4. 공동 사용이므로, 사용상 여러 제약도 따른다. (구성변경, 포맷, 재 부팅 등등)

5. 결정적으로, 회사 외부에서는 사용할 수 없다. (회사 보안 규정상, 사내 접근만 허용)

그래서, 위와 같은 문제점들을 우회하기 위한  대안이 바로 리눅스 환경을 기반으로 한 DB2 테스트 베드를 가상컴퓨터로 구축하는 것이며, 이 방안의 장단점은 다음과 같다고 볼 수 있다.

[장점]

1. 유닉스와 비슷한 환경 하에서 DB2 테스트 해볼 수 있다.

2. 가상컴퓨터 기반이므로 서버의 추가 생성에 대한 비용적 부담이 없다.

3. 가상컴퓨터 기반이기 때문에 하드웨어의 변경 또한 자유롭다. (CPU, RAM, HDD, NC 등)

4. 혼자 사용하므로, 사용에 어떠한 제약도 없다.

5. 개인용 노트북에 설치하게 되면 언제 어디서든지 사용 가능하다.

[단점]

1. 가상컴퓨터 소프트웨어는 상용 프로그램이다. (물론 무료도 있지만...)

2. 가상컴퓨터를 실행시키는 컴퓨터/노트북의 사양이 빵빵해야 된다.

몇 가지 단점에도 불구하고 이 방안이 주는 장점들이 매력적이기 때문에 (솔직히 말하면, 이거 이외에는 다른 대안이 없기에) 그 동안 많은 DB2 테스트들을 이러한 환경하에서 진행해왔었다.

그리고, 앞으로도 요러한 환경이 (큰 이변이 없는 한) 계속해서 사용될 것으로 생각되어서 그간 구축해 보았던 몇 가지 리눅스 서버 구성법들을 (까먹기 전에) 알기 쉽게 체계적으로 총 정리하여 문서화 해보려고 한다.

오늘은 실제 운영 환경에 맞는 구성을 위해 PureScale을 재설치 하게되었다.
1차 설치 구성은 2대의 논리적 서버에 2Member 에 2CF로 구성을 하였으나, 1대의 서버를
추가하여 CF를 추가된 서버에 구성 하기로 했다.
변경된 추가 구성 사항은 아래와같다.
================================================================================
1차 구성 요건
  1) Member -> dbcni1 , dbcni2
  2) CF         -> dbcni1 , dbcni2

2차 구성 요건
   1) Member -> dbcni1 , dbcni2
   2) CF         -> dbcni3(추가)
=================================================================================

기존에 구성된 디스크의 PVID 값으로 Shared Disk 영역과 TieBreake 영역을 만들기로 했다
이론~ 근데 중간에 에러를 내면서 설치가 제대로 진행되지 않았다.
시스템 rebbot과 Disk 를 clear 해보아도 도무지 해결되지 않았다.
여러가지 검색과 수소문끝에 disk 상태가 clear 되지 않을 때 강제로 null값을 넣을 수 있는
방법을 알게 되었다.
Command 는 다음과 같다.
 
dd if=/dev/zero of=/dev/hdisk2 bs=4096 count=1000

결과는 에러 발생~~
또같이 해당 디스크에 대해서 busy 하다는 내용이었다.
DISK 자체를 날려버리고 재구성을 해야 할 듯 싶었다.
아무래도 이부분은 OS엔지니어의 도움이 필요한듯 싶다.
추후 Disk 문제 해결 후 다시 구성을 해야 겠다.~~~

우여곡절 끝에 설치는 끝났다~~
자~ 이제 DB를 만들어 보고 테스트를 해야 겠다.
그전 우리가 앞으로 해야 할 테스트 요건을 회의를 통해 정리 했다.
이대로 무사히 테스트가 진행되기를 기원하며~~~

=======================================================================================
1. 기본기능
   1) Admin
        가. Reorg : reorg 중 강제 종료 , M1 Reorg 중 M2 에서 Select
        나. Backup , Recovery
        다. 병렬 Load 테스트(M1,M2)
        라. 페더레이션
        마. Range Table
        바. 권한(권한 부여, 일반 유저 패스워드 변경)
        사. 멀티 생성 가능
        아. Cur_Commit 가능(검증 완료)
        자. Automatic Storage 이외 테이블 스페이스 생성 안됨

2. 확장성
        가. Member Attach,Detach 테스트

3. 가용성
        가. Member , CF 강제 종료
        나. Proccess Kill
        다. 서버 강제로 끄기등

4. 성능
        가. One Member Vs Double Member 측정
        나. 멤버별 버퍼풀 사이즈 변경 및 생성

+ Recent posts