흔히 우리가 말하는 SP(Stored Procedure),SQC,Function 등의 응용 어플리케이션을 생성하게 되면 DB상에는 Package 라는 것이 생성이 되게 된다.

DB2 Package에는 생성 당시 통계정보를 근거로 최적화된 Access Plan을 가지고 있는 Static라고 보면 된다.
이는 DB상의 Object의 변경시 통계정보를 재구성하고 이를 바탕으로 최적의 Plan을 작성하기 위해 DB2상에서는 Bind 라는 것을 실행 하게 된다.

쉽게말해 짜놓은 application 프로그램상에서 쿼리하는 부분에 최적의 Plan을 짜기 위해 필요하다는 것이다.

아래는 일반적으로 Rebind가 필요한 시점이다.

1. 통계정보 재구성 작업을 실행 하였을 때

2. 인덱스의 생성 및 재구성 작업이 있었을 때

3. Database Configuration중 아래와 같은 내용이 변경되었을 때
    1) BuffPage
    2) SortHeap
    3) Locklist
    4) MaxLocks
    5) Avg_appls

4. 프로그램 내 SQL문이 변경 되었을 때

5. Bind Option이 변경 되었을 때

6. DB2 엔진이 업그레이드 되었을때(패치적용)

7. 기타

DB2의 멀티 파티션 기능을 수행하기 위해서는 서버간 Share 할 수 있는 파일 시스템이 필요하다
파일시스템의 공유를 통하여 서버간에 DB2의 필요한 부분들을 공유 할 수 있다.

물론 이는 NFS라는 기법을 사용하여 일반적으로 구성한다.
AIX에서는 smitty 이라는 인터페이스 툴로 간단히 구성을 할 수 있다.
또한 Linux상에서도 간략한 Command Line을 통하여 NFS를 구성 할 수 있다.

Linux의 CentOS에서 NFS 설정을 해보도록 하겠습니다.
설정은 아래와 같습니다.
=======================================================================
1. 환경
  1) NFS 서버 IP : 192.168.217.128(hostname : Server1)
  2) NFS 공유 파일 시스템(디렉토리) : /Server1
  3) 클라이언트 서버 IP : 192.168.217.129(hostname : Server2)
  4) 클라이언트 마운트할 파일 시스템(디렉토리) : /Server2

2. NFS 서버쪽 설정
  1) /etc/exports 파일의 편집
    : /Server1<NFS 서버 파일시스템> 192.168.217.129<클라이언트 서버 IP>(rw)<읽기,쓰기 권한>
  2) exportfs -v 명령어로 세팅된 /etc/exports 확인 하기
    : exportfs -v

3. NFS 서비스 데몬 기동
   1) PortMap 기동
       /etc/init.d/portmap start
   2) NFS 기동
       /etc/init.d/nfs start
   3) NetFs 기동
       /etc/init.d/netfs start

4. iptables 방화벽 Port 중지
      /etc/init.d/iptables stop

5. 클라이언트 서버쪽 설정
     mount -t nfs 192.168.217.128:/Server1 /Server2
    : NFS 서버쪽의 IP, NFS 서버 쪽 파일 시스템, 클라이언트 서버 Mount 파일 시스템

6. Mount 된 NFS 확인

# 참조(서버의 hostname 변경하기)
 1) echo "Server1" > /proc/sys/kernel/hostname
 
2) vi /etc/hosts 에서 아래와 같이 편집
    
192.168.217.129  Server2
 3) vi /etc/sysconfig/network
     NETWORKING=yes
     NETWORKING_IPV6=yes
     HOSTNAME=Server2
     GATEWAY=192.168.192.2

정보 센터를 통해서 db2iprune으로 불필요한 설치 파일을 없앨 수 있다는 것을 읽은 적이 있다. 그러나 db2iprune가 어디 있는지 몰라 확인을 못하고 넘어 갔었다.

설치 이미지 내부를 뒤지다 db2iprune이 존재하는 위치를 알게 되었다.

많이 활용할 기회가 있을지 없을지 모르겠지만, db2 설치하면서 불필요하게 설치되는 것들은 사전에 제거할 수 있으니 의미가 있을 것도 같다.

개인적으로는 itma 기능은 없애서 깔면 좋겠다 하는 생각을 했다.

설치 이미지 압축을 풀면 server 디렉토리가 생긴다. 그 기준에서

위치: server/db2/운영체제/utilities/db2iprune

db2iprune라는 쉘과 db2server.prn 이라는 설정 파일이 존재한다.

db2server.prn에 주석처리(*) 되어 있는 기능 중 제거하고자 하는 기능의 주석을 풀어 db2iprune를 실행하면 (설치 전) 설치 이미지에서 해당 기능이 제거되어 설치에서 제외 시킬 수 있다.

(경우에 따라서는 설치 이미지 크기를 줄여서 가볍게 설치 파일을 이동시킬 수도 있겠다.)

참고로 설치 이미지 내의 samples(위치:server/db2/운영체제/samples)에 각각 설치 버전에 따른 response file이 있다.

이 파일을 설정해서 db2 설치부터 db생성까지, 변수 값 설정까지 자동화할 수도 있다. (설정 작업이 만만치는 않겠지만.. 동일한 설정으로 많은 시스템에 설치를 해서 사용하는 경우는 편할 수 있겠다.)

명령어
#>./db2iprune –r db2server.prn –o 제거된_새설치이미지_위치

실행 후 /tmp/db2iprune.log 파일의 내용엔 다음과 같이 기록되었다.

DB2 설치 프로그램 로그 파일 시작 시간:  Fri Sep 23 10:16:21 2011 KST
============================================================
운영 체제 정보: Linux 2.6.18-238.el5.#1 SMP Thu Jan 13 15:51:15 EST 2011 x86_64
프룬하려는 선택된 제품:
    IBM DB2 Express Edition
    DB2 Workgroup Server Edition
    DB2 Advanced Enterprise Server Edition
    DB2 Personal Edition
    DB2 Connect Server


프룬하려는 선택된 구성요소:
    DB2 LDAP 지원
    통합 플래시 복사 지원
    Spatial Extender 클라이언트
    DB2 텍스트 검색
    Informix 데이터 소스 지원


프룬하려는 선택된 언어:


대상 디렉토리:                             /work/db2v97prune
SA MP 프룬:                                아니오
IBM Tivoli Monitoring for Databases 프룬:    예


"INFORMIX_DATA_SOURCE_SUPPORT : Informix 데이터 소스 지원 "용 파일 제거 중.


"TEXT_SEARCH : DB2 텍스트 검색 "용 파일 제거 중.


"WSE_PRODUCT_SIGNATURE : DB2 Workgroup Server Edition용 제품 서명 "용 파일 제거중.


"PE_PRODUCT_SIGNATURE : DB2 Personal Edition용 제품 서명 "용 파일 제거 중.

"SPATIAL_EXTENDER_CLIENT_SUPPORT : Spatial Extender 클라이언트 "용 파일 제거 중.

"EXPRESS_PRODUCT_SIGNATURE : DB2 Express Server Edition용 제품 서명 "용 파일제거 중.


"AESE_PRODUCT_SIGNATURE"용 파일 제거 중.


"ACS : 통합 플래시 복사 지원 "용 파일 제거 중.


"LDAP_EXPLOITATION : DB2 LDAP 지원 "용 파일 제거 중.


"CONSV_PRODUCT_SIGNATURE : DB2 Connect Server용 제품 서명 "용 파일 제거 중.

"RELATIONAL_WRAPPERS_COMMON : 일반 관계 랩퍼 "용 파일 제거 중.


DB2 파일 세트 프룬 :.......성공
IBM Tivoli Monitoring for Databases 프룬 :.......성공


DB2 프룬 로그 파일 완료 시간:  2011년 09월 23일 (금) 오전 10시 17분 03초
============================================================

DB2 관련 테스트 작업을 하다 DB2 설치 이미지 내부를 살펴보면서 V9.7에서도 쉘을 이용하여 tsa 버전을 확인하는 법을 알게 되었다.

설치 이미지의 압축을 풀면 server/db2/운영체제/install 이라는 디렉토리가 존재한다.

하위에 db2chktsa 라는 쉘이 존재한다. 이 shell을 통해 시스템 내에 설치된 버전 및 db2 설치 이미지에 있는 버전을 확인할 수 있다.

설치된 tsa 버전 확인

명령어
#>./db2chktsa -m

결과
TSAMP_VERSION=3.2.1.1 

설치 이미지에 있는 tsa 버전 확인

명령어
#>./db2chktsa -c

결과
TSAMP_VERSION=3.2.1.1 

설치를 하지 않았는데도 설치 버전이 나온다.

M옵션은 “라이센스를 갖고 있는 시스템 내에 설치된 SA MP” 그리고 “미디어 내에 try & buy 라이센스를 갖는 SAMP” 를 확인하는 옵션으로 기술되어 있다. (설치된 것 이외에도 미디어에 있는 버전도 보여 준다는 의미인 듯.)

C옵션은 “미디어에 있는 SA MP 및 설치 사전 조건"”을 확인하는 옵션으로 기술되어 있다.

차후 HADR등등의 이중화 구성된 DB2 환경에서는 위와 같은 방법으로 버전 확인할 수 있다.

종종 이기종간의 데이터 마이그레이션을 할 때 우리는 다양한 툴들을 사용하고 있다.
물론 툴들의 기본 내부적인 구조를 보면 DB2의 Command Line을 통하여 움직이고 있으며
데이터 마이그레이션 시 기본적으로 export , load 의 방법을 많이 사용하고 있다.

일반적으로 DB2의 Federation 기법을 사용하여 데이터의 마이그레이션을 손쉽게 할 수는 있으나
때로는 까다로운 혹은 보안이 심하게 걸려있는 고객의 사이트의 경우 직접 떨궈준 SAM파일을 이용해 데이터를 loading 하는 경우도 종종 있다.

DB2에서 제공되는 export 툴의 기능은 심플하며 다양한 기능들을 가지고 있다.
여러가지 modification 옵션을 가지고 있으며 상당히 직관적이고 심플하다.

아래는 일반적으로 데이터의 컬럼 구분자를 명시하는 방법이다.
기본적으로 구분자는 (,) 쉼표로 구분되어 지며 사용자의 특이한 데이터 상황을 고려하여
아래와 같이 변형을 가할 수 있다.

db2 "export to staff.del of del modified by coldel! select * from staff"

이는 구분자를 (!) 로 하겠다는 이야기 이다.

물론 특수 문자(예를 들면 | , '',Tab) 같은 것들은 아스키 코드의 변형으로 가능하다.
아래는 Tab 구분자를 아스키코드로 변환하여 구분자를 주는 것이다.

db2 "export to staff.del of del modified by coldel0x09 select * from staff"

위와 같이 아스키 코드를 이용하여 export 는 물론 Load옵션에도 줄 수 있다.

쓰고자 하는 내용이 DB2 아키텍처에 해당될 수 도 있을 것 같은데, 고객사의 자바로 실행되는 프로시저관련 기술지원하면서 찾아본 내용들을 정리해 본다.

프로시저를 작성하게 되면 FENCED, NOT FENCED 옵션을 선언하게 된다. DB2 내에서 자체적으로 제공되는 내장(built-in) 루틴(함수, 프로시저, 패키지, 모듈)은 not fenced 옵션으로 실행이 되지만, 일반 사용자(개발자)등이 생성하는 루틴은  fenced로 선언을 한다.

함수나 프로시저에서 선언되는 fenced라는 것은 DB2 인스턴스를 생성할 때 지정하게 되는 분리사용자(fence user)와 관계가 깊다.

하나의 프로그램이 실행되는 것은 process (혹은 daemon)가 실행되어 짐을 의미하고, 이것은 다시 계정하고도 매핑이 된다. 즉 OS 상의 자원은 소유자에 의해서 할당되어 실행이 되어진다고 할 수 있겠다.

V9.5부터 DB2는 multi-thread 방식의 아키텍처로 변경되었고, 인스턴스를 기동하면 OS상에서 db2sysc(system controller)라는 프로세스가  db2 인스턴스 계정으로 실행이 된다.

이 db2sysc라는 프로세스 하위에는 (v9.1 이하에서는 프로세스로 존재했던) db2agent라는 thread가 존재한다. (이외 instance 및 db 레벨에서 실행되는 여러 프로세스들이 다 db2sysc 하위의 thread로 포함되었다)

db2agent가 하는 역할은 원격에서 접속이 되면 db2agent가 생성이 되고, 작업 요청을 db2agent가 받아서 db 내부로 던져주는 역할을 한다. db 내에서 응답을 주면 원격에 다시 그 결과를 통보해 주는 통로 역할을 한다. (어찌 보면  client 접속에 대해 전체적인 트랜잭션을 관리해 주는 관리자 프로세스라고 할 수 있겠다.)

db2agent로 인스턴스 계정의 소유로 자원을 받아 실행이 되며, db2sysc와도 관련을 갖고 행동하기 때문에, 작업에 대해 예외가 발생하여 db2agent 한 개가 crash가 되는 경우 db2sysc 까지 영향을 미쳐, 인스턴스가 비정상적으로 종료가 되는 상황이 발생한다.

인스턴스 계정으로 소유된 자원들이기에 하위의 프로세스, 쓰레드는 어느 하나가 문제가 발생해도 전체가 다 죽는 상황이 발생을 하게 된다.

DB2는 사용자 정의 함수(UDF)나 프로시저등의 사용자가 작성해서 사용하는 object들에 대해서는 인스턴스 소유로 실행되지 않도록 db2fmp라는 별도의 프로세스를 통해 처리되도록 설계를 하였고, 이 db2fmp 프로세스는 (db2 인스턴스를 생성할 때 필요한 분리사용자 계정) fence 계정 소유로 실행된다.

따라서, UDF나 Procedure가 들어있는 트랜잭션을 db2agent가 받게 되면 이것을 db2fmp에서 처리되도록 전달한다. db2fmp는 들어온 트랜잭션을 db쪽에 요청하여 작업 처리를 하고 결과를 db2agent에 전달하는 식으로 하여 작업 처리를 하게 된다.

DB2 V9.7 fixpack 2~3에 포함된 IBM JDK에 버그가 발생해서 자바기반의 UDF나 Procedure가 실행되면 db2fmp 프로세스가 CPU 90% 이상을 잡아 먹는 상황이 발생을 하였었다. (해결책은 IBM JDK 최신 버전을 받아 설치해서 DB2가 사용하도록 하면 된다.)

db2fmp에서 어떤 작업들이 실행되었는지는 db2pd –fmp 를 실행함으로 확인해 볼 수 있다.

명령어: db2pd –fmp

결과:

FmpPid     Bit   Flags      ActiveThrd PooledThrd ForcedThrd Active
966858     64    0x00000000 0          0          0          Yes   
 
   Active Threads:
     EduPid : 15455     ThreadId : 0     

FMP Process:
FmpPid     Bit   Flags      ActiveThrd PooledThrd ForcedThrd Active
 950308     64    0x00000003 1          0          0          Yes   
 
   Active Threads:
     EduPid : 14427     ThreadId : 2314     
        Routine ID     Timestamp
        65974          2010-11-11-17.26.19.274874

 

명령어: db2pd -fmpe pid=950308 genquery

결과:

FMP Process:
Address            FmpPid     Bit   Flags      ActiveThrd PooledThrd ForcedThrd Active IPCList
0x0780000000DDBD40 766078     64    0x00000003 5          1          0          Yes    0x0780000000E6EFC0
 
   Active Threads:
   Address            FmpPid     EduPid     ThreadId 
   0x0780000000E6D880 766078     25189      3342     
   0x0780000000DDFE00 766078     17736      3085     
   0x0780000000DDF240 766078     17479      2828     
   0x0780000000DDD500 766078     16708      2571     
   0x0780000000DDC7C0 766078     16451      2314     
 

WITH RTNHIST ( PID, TID, RTNID, RTNTIME) AS
( VALUES   ( 766078    , 3599      , 65960     , TIMESTAMP('2010-11-12-01.03.33.056630')),
           ( 766078    , 3342      , 65960     , TIMESTAMP('2010-11-12-01.02.33.762402')),
           ( 766078    , 3085      , 65974     , TIMESTAMP('2010-11-12-01.01.59.036435')),
           ( 766078    , 2828      , 67495     , TIMESTAMP('2010-11-12-01.01.58.972998')),
           ( 766078    , 2571      , 65974     , TIMESTAMP('2010-11-12-01.01.54.017851')),
           ( 766078    , 2314      , 67495     , TIMESTAMP('2010-11-12-01.01.51.854489')),
           ( 766078    , 3856      , 65960     , TIMESTAMP('2010-11-12-01.03.33.057850'))
)
SELECT R.PID, R.TID, R.RTNTIME, ROUTINESCHEMA, ROUTINENAME, SPECIFICNAME, ROUTINEID
FROM syscat.routines, RTNHIST as R
where ROUTINEID = R.RTNID
ORDER BY R.PID, R.TID, R.RTNTIME

특정 PID에 대해 어떤 SQL이 실행되었는지를 위와 같은 명령어를 통해서 확인할 수 있다.

만일 특정 루틴이 이런 문제를 발생했다면, 위와 같은 방식으로 찾아 낼 수 있지 않을까 하는 생각을 한다.

정보센터에도 자세한 내용은 나오지 않지만 flags에 대해서는 자세히 기술해 놓았다.

참고 문서: http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp

 

이외 자바 프로시저 관련해서 발생하는 오류에 대해 잘 정리가 된 문서가 있어 소개해 본다.

(자바 프로시저를 생성하고, 실행해볼 수 있도록 설명이 되었기에 자바 프로시저에 대한 기능 테스트 하기 편할 것 같다.)

참고 문서: http://www.ibm.com/developerworks/data/library/techarticle/dm-0510law/

DB2 버전이 올라갈수록 그 기능이 복잡해지면서 같이 설치되어지는 프로그램들이 있다. V9.5 부터는 Tivoli System Automation for Multiplatform(TSAMP) 라는 클러스터가 번들로 설치가 된다. 또 DB2 모니터링을 위한 Tivoli Monitoring for Database라는 제품도 설치가 된다.

여기서 살펴보고자 하는 것은 Tivoli Monitoring 제품으로 DB2 엔진 설치 시 자동적으로 설치가 된다. 삭제 또한 DB2 엔진 삭제되면서 같이 삭제가 되고 별도로 삭제하는 도구는 제공되지 않는다.

tivoli monitoring 은 db2_install_path/itma 에 설치가 된다.

다음과 같이 ps –ef 명령어를 통해서 해당 프로세스가 실행중임을 확인할 수 있다.

#> ps –ef | grep db2
inst97    5692     1  0 23:37 ?        00:00:00 /opt/ibm/db2/v9.7fp3a/itma/lx8266/ud/bin/kuddb2 localhost_inst97
dpf97     6876     1  0 23:38 ?        00:00:00 /opt/ibm/db2/v9.7fp3a/itma/lx8266/ud/bin/kuddb2 localhost_dpf97
inst95    7807     1  0 23:38 ?        00:00:00 /opt/ibm/db2/v9.5fp6a/itma/lx8266/ud/bin/kuddb2 localhost_inst95

위 실행 결과를 보면 인스턴스 별로 kuddb2 프로세스가 실행됨을 알 수 있다.

또한 이 프로세스가 하는 역할은 DataStudio Health Monitor (구, DataStudio Admin Console –DSAC 라 칭함) 를 통하여 DB2내의 자원들의 상태를 GUI로 볼 수 있도록 해주는 기능을 한다. 이 기능은 (차기 버전에서 없어질) 제어센터의 Health Monitor 기능과 동일하다 보면 되겠다.

개인적인 짐작이지만, 제어센터가 사라지면서 health monitor 기능을 대체하기 위해 DataStudio 추가적으로 확장된 기능이 아닌가 싶다. (DB2 기술지원하면서 Health Monitor 기능이 필요하다고 느껴본 적이 없기에 그 기능의 존재 여부는 회의적이다.)

그렇다면 이렇게 자동 실행되는 프로세스를 어떻게 중지시킬 수 있을까? 구글을 검색해서 살펴본 내용을 정리해본다.

프로세스 실행 중지 시키기

#> find -L /etc/init.d -name ITMAgents* -exec \{\} stop \;

혹은 프로세스를 영구적으로 자동 실행되지 않도록 아래 명령어를 실행하여 검색되는 파일을 삭제할 수도 있다. (2011.09.26 내용 수정함)

#> find /etc/rc.d -name S*ITMAgents*

위 작업 이후 kuddb2 프로세스가 없어짐을 확인할 수 있을 것이다.

우리는 새로운 서버의 도입으로 신규 서버에 DB를 설치 하는 경우가 있다.
물론 설치전 요구사항들을 꼼꼼히 체크하고 설치 시에 문제를 예방하지만 가끔 다음과 같은
부분을 miss 할 수 있다.

바로 비동기식 IO스위치의 Avalilable 상태이다.
이는 OS상의 커널파라미터가 DB2 설치 후 엔진의 Start 시 발생될 수 있는 에러이며
db2start 시 다음과 같은 에러 메세지를 보여준다.

db2start를 실행할 때 다음 오류가 발생할 수 있습니다.

0509-130 Symbol resolution failed for /usr/lib/threads/libc.a(aio.o)
because: 0509-136 Symbol kaio_rdwr (number 0) is not exported from dependent module /unix.
0509-136 Symbol listio (number 1) is not exported from dependent module /unix.
0509-136 Symbol acancel (number 2) is not exported from dependent module /unix.
0509-136 Symbol iosuspend (number 3) is not exported from dependent module /unix.
0509-136 Symbol aio_nwait (number 4) is not exported from
dependent module /unix.
0509-192 Examine .loader section symbols with the
'dump -Tv' command.


아래와 같은 방법으로 다음과 같은 에러를 해결 할 수 있다.

비동기 I/O를 켜려면 다음을 수행하십시오.

1. smitty chgaio를 실행하고 시스템 다시 시작 시 구성할 상태정의됨(Defined)에서 사용 가능(Avalilable) 으로 설정하십시오.


2. Enter를 누르십시오.


3. 다음 중
하나를 수행하십시오.

      시스템을 다시 시작하십시오.

db2start 명령이 작동하게 됩니다.


보통 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

+ Recent posts