pajama

# env|grep LANG

LANG=ko_KR

# locale -a

C

POSIX

ko_KR

ko_KR.IBM-eucKR

en_US

en_US.8859-15

en_US.ISO8859-1

# export LANG=ko_KR.IBM-eucKR

# env|grep LANG

LANG=ko_KR.IBM-eucKR

참고

WindowsXP : MS949 -> OK
RHEL : EUC-KR
AIX: IBM-eucKR
KSC5601

SQL*LOADER는 일반 text file의 data를 ORACLE table로 load하는 유틸리티로서 IBM의 DB2 load utility와 흡사하다. SQL*LOADER의 처리 mode에는 크게 direct load와 conventional load가 있다. 여기에서는 각 mode 의 차이점과, SQL*LOADER 를 실행중 index 가 direct load state로 빠지는 현상에 대해 살펴본다.　 
1.CONVENTIONAL PATH LOAD　 

default로 사용되는 option으로 일정한 크기의 버퍼을 memory에 할당하고 이곳에 text data를 저장 하여 버퍼가 모두 차면 SQL command인 insert를 이용하여일반 적인 insert 작업을 수행하게 된다. 이러한 방법은 ORACLE에서 제공하는 일반적인 다른 tool 들에서도 사용하는 insert 방법이다. commit은 버퍼에 저장된 row들이 전부 insert되었을때 수행되며 버퍼의 size는 bindsize라는 option으로 지정되며 만일 한 row의 길이가 너무 길어 지정된 bindsize내에 하나의 row가 수용되지 못할 정도로 크다면 SQL*LOADER는 error를 발생시킨다.　 

예)bindsize=10k,rows=1,record length=15K일 경우 error발생.　 

conventional mode는 direct mode에 비해 처리 과정에서 훨씬 여러 단계를 거치므로 performance는 떨어진다. 그러나 이 방법은direct mode가 안고 있는 몇 가지 제한 사항을 해결하는 장점이 있다.　 

1)load하려는 table에 다른 process에서 access가 가능하다.　 

즉 한쪽에서는 SQL*LOADER로 A table에 load하고 다른 쪽에서는 같은 A table에 SQL*PLUS로 update,insert가 가능하다.　 

2)load시 SQL function을 사용 하려면 conventional을 사용해야 한다.　 

예)load data　 
infile 'test.dat'　 
append　 
into table dept　 
(deptno position(01:02) integer external,　 
dname position(03:10) char upper(:dname),　 
loac position(11:15) char　 
)　 

3)load하려고 하는 table이 단일 table이 아닌 cluster인 경우로 cluster table은 direct path load를 사용 못함.　 

4)SQL*NET을 통해 data를 load시 SQL*NET을 이용해 direct path load mode로 data를 load할 수는 없다.　 

2.DIRECT PATH LOAD　 

direct mode는 일반적으로 다량의 data를 table에 load시 performance를 위해 이용하는 방법이다. 이 경우에는 일반적으로 table에 index가 있으면 제거한 후 load를 하는 것이 더 좋은 performance를 얻을 수 있는데 그 이유는 direct mode에서insert시 index가 구성되는 mechanism을 살펴보면 쉽게 알 수 있다.　 

1)direct path load에서의 index의 형성과정은　 

memory buffer의 data를 datafile에 direct하게 저장 
load된 new data에 대해 temporary index를 생성 
old index와 temporary index를 merge하여 new index를 형성 
d)old index의 drop및 new index로 대치한다.　 
2)이의 처리를 위해 direct path를 이용해 data load시 다음의 제한이 따른다.　 

a)cluster에는 사용 할 수 없다.　 

만일 해당 table에 active transaction이 있는 경우 error발생(commit 안된transaction 이 있는 상태에서 direct load시 ORA-54 error가 발생하는데 해당 table에 table lock을 걸다 실패하기 때문이다) 
c)SQL function을 control file에서 사용 할 수 없다.　 
d)만일 index가 table에 있을 경우 direct load중에는 select를 할 수 없다.　 

제약사항과 특별한 index 생성 process로 인해 direct mode에서는 실제로 data는 table에 load 되었으나 index에서 문제가 발생하여 해당index를 사용하지 못하는 상태가 발생할 수 있다. 즉 direct load중 index에 대한 space를 allocate할 수 없는 경우, sorted indexes option이 사용되었는데 data가 ordered되지 않은 경우, load도중 shutdown이 발생한 경우, index가 unique index인데 load되는 data중에 동일한 key값이 있는 경우에 해당index는 direct load state 상태가 된다. 이 상태에서는 이 테이블을 select시 index를 사용하지 못하거나, SQL*LOADER direct=y option으로 load시 ORA-1502 error 를 만나게 된다. 이 때는 해당 index를 drop후 recreate하면 쉽게 해결이 가능하다 

매우 많은 양의 데이타를 빠른 시간 내에 load하고자하는 경우 direct path load를
사용할 수 있다. 여기에서 이러한 direct path load의 자세한 개념 및 사용방법,
사용 시 고려해야 할 점 등을 설명한다.

1. conventional path load

일반적인 sql*loader를 이용한 방법은 존재하는 table에 datafile 내의 data를 
SQL의 INSERT command를 이용하여 insert시킨다. 이렇게 SQL command를 
이용하기 때문에 각각의 데이타를 위한 insert command가 생성되어 parsing되는 
과정이 필요하며, 먼저 bind array buffer (data block buffer) 내에 insert되는 
데이타를 입력시킨 후 이것을 disk에 write하게 된다.

conventional path load를 사용하여야 하는 경우는 다음과 같다.
--- load 중에 table을 index를 이용하여 access하여야 하는 경우
direct load중에는 index가 'direct load state'가 되어 사용이 불가능하다.
--- load 중에 index를 사용하지 않고 table을 update나 insert등을 수행해야 
하는 경우
direct load 중에는 table에 exclusive write(X) lock을 건다.
--- SQL*NET을 통해 load를 수행해야 하는 경우
--- clustered table에 load하여야 하는 경우
--- index가 걸려 있는 큰 table에 적은 수의 데이타를 load하고자 할 때
--- referential이나 check integrity가 정의되어 있는 큰 table에 
load하고자 할 때
--- data field에 SQL function을 사용하여 load하고자 할 때

2. direct path load의 수행 원리

Direct Path Loads는 다음과 같은 특징들로 인하여 매우 많은 양의 데이타를 
빠른 시간에 load하고자 할 때 이용하는 것이 바람직하다.

(1) SQL INSERT 문장을 generate하여 수행하지 않는다.
(2) memory 내의 bind array buffer를 이용하지 않고 database block의 
format과 같은 data 
block을 memory에 만들어 데이타를 넣은 후 그대로 disk에 write한다.
memory 내의 block buffer와 disk의 block은 그 format이 다르다.
(3) load 시작 시에 table에 lock을 걸고 load가 끝나면 release시킨다.
(4) table의 HWM (High Water Mark) 윗 부분의 block에 data를 load한다. 
HWM는 table에 data가 insert됨에 따라 계속 늘어나고 truncate 외에는 
줄어들게 하지 못한다. 
그러므로, 항상 완전히 빈 새로운 block을 할당받아 data를 입력시키게 된다.
(5) instance failure가 발생하여도 redo log file을 필요로 하지 않는다.
(6) UNDO information을 발생시키지 않는다. 
즉 rollback segment를 사용하지 않는다.
(7) OS에서 asynchronous I/O가 가능하다면, 복수개의 buffer에 의해서 동시에
data를 읽어서 buffer에 write하면서 buffer에서 disk로 write할 수 있다.
(8) parallel option을 이용하면 더욱 성능을 향상시킬 수 있다.

3. direct path load의 사용방법 및 options

direct path load를 사용하기 위한 view들은 다음 script에 포함어 있으며, 
미리 sys user로 수행되어야 한다. 단 이 script는 catalog.sql에 포함되어 있어,
db 구성 시에 이미 수행되어진다.

@$ORACLE_HOME/rdbms/admin/catldr.sql 

direct path load를 사용하기 위해서는 일반적인 sqlload 명령문에 DIRECT=TRUE를
포함시키기만 하면 된다. 다음과 같이 기술하면 된다.

sqlload username/password control=loadtest.ctl direct=true 

이 direct path load를 사용 시에 고려할 만한 추가적인 option 및 control file
내에 기술 가능한 clause들을 살펴본다.

(1) ROWS = n 
conventional path load에서 rows는 default가 64이며, rows에 지정된 갯수
만큼의 row가 load되면 commit이 발생한다. 이와 비슷하게 direct load 
path에서는 rows option을 이용하여 data save를 이루며, data save가 발생하면
data는 기존 table에 포함되어 입력된 data를 잃지 않게 된다. 
단 이 때 direct path load는 모든 data가 load된 다음에야 index가
구성되므로 data save가 발생하여도 index는 여전히 direct load state로 
사용하지 못하게 된다.
direct path load에서 이 rows의 default값은 unlimited이며, 지정된 값이
database block을 채우지 못하면 block을 완전히 채우는 값으로 올림하여, 
partial block이 생성되지 않도록 한다.

(2) PIECED clause
control file내에 column_spec datatype_spec PIECED 순으로 기술하는 
것으로서 direct path load에만 유효하다. LONG type과 같이 하나의 data가
maximum buffer size보다 큰 경우 하나의 data를 여러번에 나누어 load하는 
것이다. 이 option은 table의 맨 마지막 field 
하나에만 적용가능하며, index column인 경우에는 사용할 수 없다.
그리고 load도중 data에 문제가 있는 경우 현재 load되는 data의 잘린 부분만
bad file에 기록되게 된다. 왜냐하면 이전 조각은 이미 datafile에 기록되어 
buffer에는 남아있지 않기 때문이다.

(3) READBUFFERS = n (default is 4)
만약 매우 큰 data가 마지막 field가 아니거나 index의 한 부분인 경우 
PIECED option을 사용할 수 없다. 이러한 경우 buffer size를 증가시켜야 
하는데 이것은 readbuffers option을 이용하면 된다. default buffer갯수는 
4개이며, 만약 data load중 ORA-2374(No more slots for read buffer 
queue) message가 나타나면, buffer갯수가 부족한 것이므로 늘려주도록 한다. 
단 일반적으로는 이 option을 이용하여 값을 늘린다하더라도 system 
overhead만 증가하고 performance의 향상은 기대하기 어렵다.

4. direct path load에서의 index 처리

direct path load에서 인덱스를 생성하는 절차는 다음과 같다.

(1) data가 table에 load된다.
(2) load된 data의 key 부분이 temporary segment에 copy되어 sort된다.
(3) 기존에 존재하던 index와 (2)에 의해서 정렬된 key가 merge된다.
(4) (3)에 의해서 새로운 index가 만들어진다.
기존에 존재하던 index와 temporary segment, 그리고 새로 만들어지는 index가
merge가 완전히 끝날 때까지 모두 존재한다.
(5) old index와 temporary segment는 지워진다.

이와 같은 절차에 반해 conventional path load는 data가 insert될 때마다 한
row 씩 index에 첨가된다. 그러므로 temporary storage space는 필요하지 않지만
direct path load에 비해 index 생성 시간도 느리고, index tree의 balancing도
떨어지게 된다.

index생성 시 필요한 temporary space는 다음과 같은 공식에 의해 예측되어질 수
있다.

1.3 * key_storage
key_storage = (number_of_rows) * (10 + sum_of_column_sizes + 
number_of_columns)

여기에서 1.3은 평균적으로 sort 시에 추가적으로 필요한 space를 위한 값이며,
전체 data가 완전히 순서가 거꾸로 된 경우에는 2, 전체가 미리 정렬된 경우라면
1을 적용하면 된다.

--- SINGLEROW clause
이와 같이 direct path load에서 index 생성 시 space를 많이 차지하는 문제점
때문에 resource가 부족한 경우에는 SINGLEROW option을 사용할 수 있다.
이 option은 controlfile 내에 다음과 같은 형태로 기술하며, direct path
load에만 사용 가능하다.

into tables table_name [sorted indexes...] singlerow

이 option을 사용하면 전체 data가 load된 뒤에 index가 구성되는 것이 아니라
data가 load됨에 따라 data 각각이 바로 index에 추가된다.
이 option은 기존에 미리 index가 존재하는 경우 index를 생성하는 동안 
merge를 위해 space를 추가적으로 필요로 하는 것을 막고자 하는 것이므로 
INSERT 시에는 사용하지 않고, APPEND시에만 사용하도록 하고 있다. 
실제 새로 load할 data 보다 기존 table이 20배 이상 클 때 사용하도록 권하고
있다.

direct path load는 rollback information을 기록하지 않지만, 이 singlerow
option을 사용하면 insert되는 index에 대해 undo 정보를 rollback segment에
기록하게 된다. 
그러나, 중간에 instance failure가 발생하면 data는 data save까지는 보존
되지만 index는 여전히 direct load state로 사용할 수 없게 된다.

--- Direct Load State

만약 direct path load가 성공적으로 끝나지 않으면 index는 direct load 
state로 된다. 
이 index를 통해 조회하고자 하면 다음과 같은 오류가 발생한다.
ORA-01502 : index 'SCOTT.DEPT_PK' is in direct load state.

index가 direct load state로 되는 원인을 구체적으로 살펴보면 다음과 같다.
(1) index가 생성되는 과정에서 space가 부족한 경우
(2) SORTED INDEXES clause가 사용되었으나, 실제 data는 정렬되어 있지 않은
경우
이러한 경우 data는 모두 load가 되고, index만이 direct load state로 된다.
(3) index 생성 도중 instance failure가 발생한 경우
(4) unique index가 지정되어 있는 컬럼에 중복된 data가 load되는 경우

특정 index가 direct load state인지를 확인하는 방법은 다음과 같다.

select index_name, status
from user_indexes
where table_name = TABLE_NAME';

만약 index가 direct load state로 나타나면 그 index는 drop하고 재생성
하여야만 사용할 수 있다. 단, direct load 중에는 모든 index가 direct
load state로 되었다가 load가 성공적으로 끝나면 자동으로 valid로 변경된다.

--- Pre-sorting (SORTED INDEX)

direct load 시 index구성을 위해서 정렬하는 시간을 줄이기 위해 미리 index
column에 대해서 data를 정렬하여 load시킬 수 있다. 이 때 control file 내에
SORTED INDEXES option을 다음과 같이 정의한다. 
이 option은 direct path load 시에만 유효하며, 복수 개의 index에 대해서
지정가능하다.

into table table_name SORTED INDEXES (index_names_with_blank)

만약, 기존의 index가 이미 존재한다면, 새로운 key를 일시적으로 저장할 만큼
의 temporary storage가 필요하며, 기존 index가 없는 경우였다면, 이러한
temporary space도 필요하지 않다.

이와 같이 direct path load 시에 index 구성 시에는 기존 데이타가 있는 table에
load하는 경우 space도 추가적으로 들고, load가 완전히 성공적으로 끝나지 않으면
index를 재생성하여야 하므로, 일반적으로 direct path load 전에 미리 table의
index를 제거한 후 load가 모두 끝난 후 재생성하도록 한다.

5. Recovery

direct load는 기존 segment중간에 data를 insert하는 것이 아니라 완전히 
새로운 block을 할당받아 정확히 write가 끝난 다음 해당 segment에 포함되기 
때문에 instance failure시에는 redo log정보를 필요로 하지 않는다. 그러나 
default로 direct load는 redo log에 입력되는 data를 기록하는데 이것은 media
recovery를 위한 것이다. 그러므로 archive log mode가 아니면 direct load에 
생성된 redo log 정보는 불필요하게 되므로 NOARCHIVELOG mode시에는 항상 
control file내에 UNRECOVERABLE이라는 option을 사용하여 redo log에 redo entry를 기록하지 않도록 한다. 
data가 redo log 정보 없이 instance failure시에 data save까지는 보호되는데 
반해 index는 무조건 direct load state가 되어 재생성하여야 한다. 그리고 data save이후의 load하고자 하는 table에 할당되었던 extent는 load된 data가 
user에게 보여지지는 않지만 extent가 free space로 release되지는 않는다.

6. Integrity Constraints & Triggers

direct path load중 not null, unique, primary key constraint는 enable
상태로 존재한다. not null은 insert시에 check되고 unique는 load후 index를 
구성하는 시점에 check된다.
그러나 check constraint와 referential constraint는 load가 시작되면서 
disable상태로 된다. 전체 데이타가 load되고 난 후 이렇게 disable된 
constraints를 enable시키려면 control file내에 REENABLE이라는 option을 
지정하여야 한다. 이 reenable option은 각 constraint마다 지정할 수는 없으며 
control file에 한번 지정하면 전체 integrity/check constraint에 영향을 
미치게 된다. 만약 reenable되는 과정에서 constraint를 위배하는 data가 
발견되면 해당 constraint는 enable되지 못하고 disabled status로 남게 되며, 
이렇게 위배된 data를 확인하기 위해서는 reenable clause에 exceptions option을 다음과 같이 추가하면 된다.

reenable exceptions table_name 

이 때 table_name은 $ORACLE_HOME/rdbms/admin/utlexcpt.sql을 다른 
directory로copy하여 table이름을 exceptions가 아닌 다른 이름으로 만들어 수행시키면 된다.
insert trigger도 integrity/check constraint와 같이 direct load가 시작하는
시점에 disable되며, load가 끝나면 자동으로 enable된다. 단 enable되고 나서도
load에 의해 입력된 data에 대해 trigger가 fire되지는 않는다.

http://kr.forums.oracle.com/forums/thread.jspa?threadID=470778&tstart=315

최근 Windows 7 나오면서 다들 관심이 많아 지셨는데 뜸금없이 2008 R2 내용입니다. ^^;

아주 간단한 Tip이라 도움이 되실지 모르겠지만, 제가 도움을 많이 받은 TPHOLIC이라 작성해 봅니다.

1. Windows Server 2008 R2 평가판 소프트웨어 다운로드

http://msdn.microsoft.com/ko-kr/evalcenter/ee175713.aspx

 .180일 평가판 입니다. Live ID를 필요로 하고 ISO 형태로 받을 수 있습니다. DVD로 구워서 설치하면 됩니다.
 .링크 잘 따라가시면 Live ID 로그인 하고 받을 수 있습니다.
 .기본적으로 영문판이고 R2 버전부터 x64 로만 나온다고 합니다. x86은 없습니다.

2. Windows Server 2008 R2 환경에서 다국어 사용자 인터페이스 사용하기

http://www.microsoft.com/downloads/details.aspx?displaylang=ko&FamilyID=03831393-eef7-48a5-a69f-0ce72b883df2

 .영문판이기 때문에 혹시 한글이 필요하시다면 MUI 받으시면 한글로 사용할 수 있습니다.
 .제가 보기에는 한글버전과 차이가 없다고 생각 될 정도입니다.
 .실행파일을 클릭하자 마자 설치됩니다. 그냥 기달리시면 설치되고요..
 .설치 완료후 한글 활성화 방법은 제가 영어가 짧아서 한글 메뉴로 말씀드립니다.
   제어판 -> 시계, 언어 및 국가별 옵션 -> 표시언어 변경 에서 한국어로 바꾸시면 됩니다.
   (로그오프 되고 다시 로그인 하시면 한글이 보입니다.)

3. 서버관리자 셋팅

 .제가 Windows Server 2000 까지 써보고 서버를 사용해 본적이 없습니다.
  처음에는 어색했는데 써보니 많이 편하네요..
 .서버관리자가 많이 바뀌었습니다. 셋팅시 제가 진행하는 부분을 적어봅니다.

 가. IE ESC (보안강화구성) 변경
   - 기본 IE 셋팅이 보안이 엄청 높아서 할 수 있는 부분이 거의 없습니다. ESC를 해제 하면됩니다.
   - 서버관리자 구동하시고 좌단의 "서버관리자(서버이름)"을 클릭하시면 초기 페이지가 나오는데 "보안정보" 항목에서
     IE ESC 구성을 선택하시고 사용 안함으로 하시면 일반 OS의 IE 사용처럼 바뀝니다. 
 나. 기능 - 무선 LAN 서비스 활성화
   - 2008 R2는 필요한 서비스를 사용자가 활성화 시켜야합니다. 무선랜을 사용하신다면 
     기능 -> 기능추가 -> 무선 LAN 서비스를 설치하셔야합니다.
     드라이버 설정과는 별개로 이부분을 추가하셔야 무선랜을 사용할 수 있습니다.
 다. .NET Framework 3.5.1 활성화
   - 초기에는 .NET Framework이 활성화 되어 있지 않습니다. .NET Framework을 필요로 하는 드라이버가 있습니다.
     예를 들어서 ATI 비디오 카드를 쓰시는 분은 .NET Framework가 실행되어 있지 않으면 드라이버가 제대로 올라오지
     않습니다.
   - 기능 -> 기능추가 -> .NET Framework 3.5.1 기능 설치
   - 필요한 소프트웨어가 .NET 기반이라면 설치후 가장 먼저 추가해야 합니다.
 

3. Aero Glass 사용방법

 .2008 R2는 기본으로 Aero Glass를 구동하지 않습니다. 설치하면 보기는 많이 좋아지네요.. ^^;
 .당연한 말이지만, 비디오 드라이버가 제대로 설치된 후에 아래 작업 하셔야 합니다. 
 
 가. 기능추가 (데스크톱 경험, Quality Audio Video Experience 설치)
   - 서버관리자의 기능으로 가셔서 데스크톱 경험, Quality Audio Video Experience 을 설치합니다.
   - 위에서 기능 부분 설치해보시면 아시겠지만, 필요한 다른 기능이나 역할이 있으면 알아서 추가합니다.
 나. 서비스 중 Themes 구동 
   - 서비스는 여러 방법으로 갈 수 있는데 서버관리자 -> 구성 -> 서비스에서 하셔도 됩니다.
   - Themes 서비스는 사용안함으로 되어 있는데 자동으로 실행하도록 바꿔주시면 됩니다.
 다. Aero Glass Skin 추가/변경
   - 바탕화면에서 오른쪽 마우스를 클릭하시면 하단에 "개인설정" 메뉴가 추가됩니다.
   - 여기서 온라인 테마추가 하시거나 기본 제공 Aero 테마를 선택하시면 됩니다.

4. TP 관련 드라이버
 
 .제가 설치해본 TP 기종은 X61s, T400 입니다. 
 .제가 모두 다 해본건 아니지만, 대부분 VISTA 드라이버로 설치가 됩니다.
 .TPHOLIC 사이트의 유저강좌에서 windows 7 드라이버를 찾아보시면 설치가 됩니다. 
  유저강좌의 파미님 올려주신글이 참고가 많이 되었습니다. 여기서 감사드립니다.

 .최근 나온 os라 그런지 대부분 장치는 기본적으로 설치가 됩니다.

 .제가 알고 있는 문제는 블루투스가 2008 R2에서 기본적으로 막았다고 합니다. 이부분 설치하는건 결국 못했습니다.

여기까지가 간단하게 Widnows Server 2008 R2 기본적인 셋팅입니다.
제가 Windows 7을 써보지 못했는데 이유가.. ^^; 마이크로소프트 Windows 7 평가판중에 한국어 버전은 64버전을 제공한다고 하는데
다운로드가 되지 않았습니다. 그래서 비교는 못해봤습니다.

R2 설치 하면서 64 버전이라서 안되는것이 많을 줄 알았는데 제가 쓰는 프로그램에서는 문제되는 부분이 없습니다. 물론..
몇개 쓰지 않습니다.

도움이 되었으면 좋겠습니다.

출처 : http://tpholic.com/xe/?mid=ibmreport&page=5&document_srl=2731433

Oracle Client / Server Interoperability Support

Introduction

This note gives a summary of the support for interoperability between Oracle client and server versions. This includes support for connections over database links between Oracle versions. Note that this relates to support for investigation of defects / ability to obtain bug fixes.

Note that this is a general guide for interoperability only - certain products or utilities may impose additional restrictions on supported combinations specific to the product / utility. eg: Precompilers, Export / Import utilities etc..

For a summary of the support status of each Oracle release see Note 161818.1

General Policy

Oracles general policy is to test and support each new Oracle release for compatibility with older releases thus:

• Test the NEW client to each OLDER server release where the OLDER release is still covered by Premier Support (formerly Primary Error Correction support) at the time that the NEW version is released.
• Test OLDER clients to the NEW server release where the OLDER release is still covered by Premier Support (formerly Primary Error Correction support) OR is in the first two years of Extended Support (formerly Extended Maintenance support).
• Tests between the NEW version and other OLDER releases may be added where Oracle deems it sensible to support interoperability between those releases.

Current Interoperability Support Situation

The matrix below summarizes client and server combinations that are supported.

New interoperability problems will only be investigated if BOTH releases involved are covered by a valid support contract at the time that the issue is reported .
eg:

A 9.2.0 client to a 10.2.0 server issue requires the customer to have a valid Extended Support contract for the 9.2.0 client in order for Oracle to investigate it.

	Server Version
Client Version	11.1.0	10.2.0	10.1.0	9.2.0	9.0.1	8.1.7	8.1.6	8.1.5	8.0.6	8.0.5	7.3.4
11.1.0	Yes	Yes #6	Yes #6	ES #5	No	No	No #3	No #3	No #3	No #3	No #3
10.2.0	Yes #6	Yes	Yes	ES #5	No	Was	No #3	No #3	No #3	No #3	No #3
10.1.0(#4)	Yes #6	Yes	Yes	ES	Was	Was #2	No #3	No #3	No #3	No #3	No #3
9.2.0	ES #5	ES #5	ES	ES	Was	Was	No	No	Was	No	No #1
9.0.1	No	No	Was	Was	Was	Was	Was	No	Was	No	Was
8.1.7	No	Was	Was	Was	Was	Was	Was	Was	Was	Was	Was
8.1.6	No	No	No	No	Was	Was	Was	Was	Was	Was	Was
8.1.5	No	No	No	No	No	Was	Was	Was	Was	Was	Was
8.0.6	No	No	No	Was	Was	Was	Was	Was	Was	Was	Was
8.0.5	No	No	No	No	No	Was	Was	Was	Was	Was	Was
7.3.4	No	No	No	Was	Was	Was	Was	Was	Was	Was	Was

Key:

Yes	Supported
ES	Supported but fixes only possible for customers with Extended Support .
Was	Was a supported combination but one of the releases is no longer covered by any of Premier Support , Primary Error Correct support , Extended Support nor Extended Maintenance Support so fixes are no longer possible.
No	Has never been Supported

Specific Notes:

• #1 - See Note 207319.1
• #2 - An ORA-3134 error is incorrectly reported if a 10g client tries to connect to an 8.1.7.3 or lower server. See Note 3437884.8 .
• #3 - An ORA-3134 error is correctly reported when attempting to connect to this version.
• #4 - There are problems connecting from a 10g client to 8i/9i where one is EBCDIC based. See Note 3564573.8
• #5 - For connections between 10.2 (or higher) and 9.2 the 9.2 end MUST be at 9.2.0.4 or higher. Connections between 10.2 (or higher) and 9.2.0.1, 9.2.0.2 or 9.2.0.3 are not supported.
• #6 - For connections between 11.1 (or higher) and 10.1 / 10.2 the 10g end MUST be at 10.1.0.5 / 10.2.0.2 (or higher) respectively in order to use PLSQL between those versions. See Note 4511371.8 for more details.

General Notes:

1. For database links between different Oracle versions connections must be supported in BOTH directions in the matrix above.
   eg: As 9.2 -> 7.3.4 is not supported then database links between these version are notsupported in either direction.
   
2. Unsupported combinations may appear to work but can encounter errors for particular operations. The fact that they appear to work should not be relied upon - issues on unsupported combinations will not be investigated.
3. Since new database servers are compatible with a limited set of older OCI clients, it may not be necessary to upgrade the client software when upgrading the database. However, some new features may not work without upgrading the client software. So, for example, an Oracle 7.3.4 client is able to connect to an Oracle8i database, but is not able to take advantage of newer features such as Transparent Application Failover (introduced in v8).
4. Oracle Applications , or other Oracle products, may have supported configurations not listed in the matrix above.
5. The matrix above also applies between different platforms and between 32/64 bit releases of Oracle client / server except where any Oracle platform desupport notice indicates otherwise .
6. Unix BEQUEATH (BEQ) connections are NOT supported between different releases. eg: Client 9.2.0 is not supported to make an Oracle Net connection to a 10.1.0 server using the BEQ protocol adapter regardless of the interoperability support listed above. SeeNote 364252.1 for more details.

Changing the Listener Port Number for Database Connection Requests

If you change the listener port number for database connection requests, you must ensure that all future database connection requests use the new port number. This means that connection requests such as those discussed in"Connecting Remotely with SQL Command Line" must explicitly include the port number.

For example, if you change the port number for database connection requests to 1522, subsequent SQL Command Line (SQL*Plus) connect statements must be similar to the following (assuming a connection from Oracle Database Express Edition Client):

connect system/mypassword@myhost.mydomain.com:1522

Example: Changing Listener Port Number for Database Connection Requests

Assume that your Oracle Database XE host computer is named myhost.mydomain.com and that you want to install a new software package on this computer that requires TCP port number 1521. Assume also that the port number for that software package cannot be configured, and that you must therefore resolve the port number conflict by reconfiguring Oracle Database XE. You decide to change the listener port number for database connection requests to 1522.

To change the listener port number for database connection requests to 1522:

1. Stop the listener.

   See "Stopping and Starting the Listener" for instructions.

2. Open the file listener.ora with a text editor.

   Table 4-3 shows the location of this file on each platform.

   Table 4-3 Location of the listener.ora File

   Platform	Location
   Linux	/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/network/admin/
   Windows	c:\oraclexe\app\oracle\product\10.2.0\server\NETWORK\ADMIN\

   
   

3. Locate the following section of the file:

   LISTENER =
     (DESCRIPTION_LIST =
       (DESCRIPTION =
         (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))
         (ADDRESS = (PROTOCOL = TCP)(HOST = myhost)(PORT = 1521))
       )
     )
   

   Note that the line indicated in bold may or may not be present in the file.

4. Change the text (PORT = 1521) to (PORT = 1522).

5. Save the modified listener.ora file.

6. Start the listener.

   See "Stopping and Starting the Listener" for instructions.

7. Start SQL Command Line and connect to the database as user SYSTEM.

   See "Connecting Locally with SQL Command Line" for instructions. You must supply the SYSTEM password. You set this password upon installation (Windows) or configuration (Linux) of Oracle Database XE.

8. Enter the following two commands:

   ALTER SYSTEM SET LOCAL_LISTENER = "(ADDRESS=(PROTOCOL=TCP)(HOST=myhost.mydomain.com)(PORT=1522))";
   ALTER SYSTEM REGISTER;
   

9. Exit SQL Command Line and run the lsnrctl status command to verify the port number change.

   The new port number should be displayed in the Listening Endpoints Summary section of the status report, and the report should include the following lines:

   Service "XE" has 1 instance(s).  Instance "XE", status READY, has 1 handler(s) for this service...

   reference : http://download.oracle.com/docs/cd/B25329_01/doc/admin.102/b25107/network.htm#BHCCDEIH

db가 생성된 후에는,  startup upgrade후에 다음과 같은 작업을 해야합니다.

디비의 버전을 업그레이드 했지만, 이미 만들어진 객체들, 테이블, 패키지등은 아직 구버전 그대로 이기때문에,

테이블, 패키지등을 새로운 버전으로 업그레이드 하는 작업이 필요한데,  이것이  아래의 작업입니다.

사실은, 디비가 생성된 후에 패치 하지 마시고,  가능하면 디비 엔진만 설치 된 후에 패치하고,

그리고 디비 생성하는것이좋습니다.    그러면 아래같은 작업을 하지 않아도 됩니다.

아래와 같이 작업해도,  시간이 많이 걸리고, 진행이 안되고 멈추는 경우도 있었습니다. 

디비가 운영중일때는, 이런 패치작업은가능하면 안하는 것이 좋고, 

하더라도 디비 모든 내용(디비엔진, 데이터파일등 몽땅)을 다른곳에 백업을 받아놓고 하는것이 안전합니다. 

( 아래 내용은 패치안에 포함된 readme.html에 있는 내용을 편집한것입니다. 

  자세한 것은 readme.html을 참조하시기 바래요.)

1. Enter the following SQL*Plus commands:

   SQL> STARTUP UPGRADE
   SQL> SPOOL patch.log
   SQL> @?/rdbms/admin/catupgrd.sql  <- 이부분 실행
   SQL> SPOOL OFF
   

2. Review the patch.log file for errors and inspect the list of components that is displayed at the end of catupgrd.sqlscript.

   This list provides the version and status of each SERVER component in the database.

3. If necessary, rerun the catupgrd.sql script after correcting any problems.

4. Restart the database:

   SQL> SHUTDOWN IMMEDIATE
   SQL> STARTUP
   

1. Run the following command to check the status of all the components after the upgrade:

   SQL> select comp_name, version, status from sys.dba_registry;
   

   In the output of the preceding command, the status of all the components should be VALID for a successful upgrade.

클래스패스와 환경 변수, 그것이 알고 싶다. 
김세곤 
2001년 4월 17일 

서론 
초보 자바 프로그래머를 괴롭히는 큰 문제 중에 그놈의 클래스패스는 빠지지 않는다. 클래스패스는 사실 이렇게 하나의 글로 설명하기조차 매우 부끄러운 사소한 것인데, 초보 자바 프로그래머에게는 절대 사소하지 않은 것이 현실이다. 더군다나, 가슴 아프게도 대부분의 자바 관련 서적은 클래스패스에 지면을 할애할 만한 형편도 안되고, 대부분의 저자들이 별것도 아닌 것에 공들여 설명하려 하지 않기 때문에, 당연히 클래스패스에 대해서는 많은 독자들이 제대로 이해하지 못한 채 끙끙댄다. 한편으로는, 이것은 기초를 제대로 다지지 않은 독자들의 책임이 크다. 클래스패스를 잘 설정해서 자바 프로그램을 컴파일하고 실행하는 기술은 자바 언어의 첫번째 단추이고, 이 내용은 대부분의 자바 책(자바 관련 서적이 아닌 자바 그 자체를 설명하는 책)에서는 설명이 되어 있기 때문이다.

필자는 JSP Bible이라는 책을 집필하고 독자로부터 많은 질문을 받았는데, 거짓말 보태지 않고 50% 이상의 독자가 클래스패스로 골머리를 썩고 있었다. JSP로 웹 개발을 시도하려 한다면 자바 언어의 첫번째 단추인 클래스패스와 컴파일 정도에는 문제가 없어야 하는데, 아쉽게도 이 첫번째 단추를 못 껴서 진도를 못 나가다니 가슴 아픈 현실이 아닐 수 없다. 

가장 좋은 방법은 역시 자바 언어를 제대로 공부하고 나서 JSP, Servlet, EJB 등 그 다음 단계의 공부를 진행하는 것이다. 그런데, 이유야 어찌 됐건, 대부분의 독자들은 자바에 대한 기초없이 응용 단계인 JSP, Servlet, EJB 등으로 마구 앞질러 나간다. 그리고, 막히면 다시 자바 언어를 체계적으로 공부하지 않고, 끙끙거리며 당장 진도를 나가려고 발버둥친다. 이 대목에서 찔리는 독자 여러분들이 분명히 많을 것이다. 

솔직히 말해서, 필자는 JSP Bible 집필 당시에 자바의 생기초라 할 수 있는 클래스패스 설정하기 및 컴파일하기 등에 대해서 이렇게 많은 독자들이 모르리라고 예상하지 못했다. 그리고, 끊임없이 클래스패스에 대한 질문을 받으면서, 같은 답변을 계속 하다보니 이제는 클래스패스에 대한 질문만 만나면 경기가 난다. 

필자는 이 글로 더 이상 클래스패스나 환경 변수 혹은 컴파일하기 등에 관련된 질문이 없기를 간절히 기대한다. 더 나아가서 많은 자바를 공부하고자 하는 개발자들이 제발 자바 언어에 대해서는 탄탄하게 기초를 다졌으면 한다. 

클래스 이름과 패키지 
갑돌이가 A.java 라는 자바 프로그램을 만들었다고 하자. 그리고, 자신의 컴퓨터 C 드라이브의 myClass라는 폴더에 A.java를 컴파일한 A.class를 넣어 두었다고 치자. 그리고는 A.class를 잘 사용하다가 어느날 똑순이가 만든 클래스를 사용할 일이 있어서 똑순이의 클래스들을 건네 받았는데, 그 중에 A.class라는 같은 이름의 클래스가 있다는 사실을 알았다. 갑돌이는 갑자기 답답해졌다. 자, 어찌 하면 갑돌이가 만든 클래스 A와 똑순이가 만든 클래스 A를 구별할 수 있을까? 

해답은 바로 패키지이다. 

갑돌이의 회사는 gabdol이고, 똑순이의 회사는 ddogsun이므로, 이 이름을 클래스 이름 A에 붙여쓰면 구별이 될 수가 있는 것이다. 갑돌이의 클래스 A의 이름을 gabdol.A로 똑순이의 클래스 A의 이름을 ddogsun.A로 사용하면 고민이 해결된다는 말이다. 그런데, 덕팔이의 회사 이름이 갑돌이의 회사 이름과 같다면 또 이름이 충돌하게 된다. 그렇다면 전세계에서 유일한 이름을 클래스 이름 앞에 붙여주면 아주 간단해진다. 전세계에서 유일한 이름으로는 머리속에 팍 떠오르는 것이 회사의 도메인 명이다. 갑돌이네 회사가 www.gabdol.com이라는 도메인 이름을 소유하고 있다면, 갑돌이네 회사에서 만드는 모든 클래스의 이름을 com.gabdol.A와 같은 식으로 만들면 문제가 해결된다. 바로, 이 com.gabdol이 클래스 A의 패키지 이름이 되는 것이다. 만일, 갑돌이네 회사가 두 개의 자바 소프트웨어를 개발했는데, 둘 다 A.java라는 클래스가 있다면 이를 또 구별해야 한다. 이런 경우라면 com.gabdol 뒤에 임의로 갑돌이네 회사가 알아서 패키지 이름을 만들면 된다. 두 개의 소프트웨어 이름이 sw1, sw2라고 하면 com.gabdol.sw1.A, com.gabdol.sw2.A 식으로 클래스 이름을 사용하는 것이다. 

이렇게 패키지를 사용하게 되면 이름 충돌의 문제도 해결할 수 있을 뿐만 아니라, 클래스를 분류하기도 쉽다. 예를 들어, 갑돌이네 회사에서 고객에 관련된 클래스들의 패키지 이름을 com.gabdol.client로 하고, 상품에 관련된 클래스들의 패키지 이름을 com.gabdol.product로 정하면 클래스들의 성격을 패키지 이름만 보고도 쉽게 파악할 수 있는 것이다. 

클래스의 위치 
이제, 갑돌이가 만드는 클래스의 이름이 com.gabdol.sw1.A로 정해졌다고 하자. 그렇다면 이 클래스는 어디에 위치해야 할까? com.gabdol.sw2.A와 같은 폴더에 존재하면 안 되므로, 패키지 이름에 따라 클래스의 위치가 유일하게 구별될 수 있어야 한다. 갑돌이는 자신의 클래스르 모두 C:\\myClass라는 폴더에 두고 있으므로, com.gabdol.sw1.A 클래스는 C:\\myClass\\com\\gabdol\\sw1 폴더에 두고, com.gabdol.sw2.A 클래스는 C:\\myClass\\com\\gabdol\\sw2 폴더에 두면 두 클래스가 충돌하지 않을 것이다. 이렇게 하면, 소스 파일과 컴파일된 클래스 파일이 다음처럼 위치하게 된다. 

C:\\myClass\\com\\gabdol\\sw1\\A.java 
C:\\myClass\\com\\gabdol\\sw1\\A.class 
C:\\myClass\\com\\gabdol\\sw2\\A.java 
C:\\myClass\\com\\gabdol\\sw2\\A.class 


이제, 패키지의 이름에 따른 클래스의 위치에 대해서 감이 오는가? 

패키지 선언과 임포트 
com.gabdol.sw1.A 클래스의 패키지는 com.gabdol.sw1이고 com.gabdol.sw2.A 클래스의 패키지는 com.gabdol.sw2이다. 이 정보는 당연히 두 소스 코드 내에 들어가야 한다. 방법은 간단하다. C:\\myClass\\com\\gabdol\\sw1\\A.java 코드의 첫머리에 다음의 한 줄만 쓰면 된다. 


package com.gabdol.sw1; 


여기서, com.gabdol.sw1.A 클래스가 com.gabdol.sw2 패키지에 들어있는 클래스들을 사용하고 싶다고 하자. 어떻게 해야 할까? 방법은 두 가지이다. 

첫번째는 클래스의 이름을 완전히 써 주는 것이다. 다음처럼 말이다. 


package com.gabdol.sw1; 
... 
com.gabdol.sw2.B b = new com.gabdol.sw2.B(); 
... 


이렇게 하면 클래스 B가 com.gabdol.sw2 패키지 내에 있는 것이 드러나므로 컴파일 시에 문제가 없다. 

두번째는 패키지를 임포트(import)하는 것이다. 다음처럼 하면 된다. 


package com.gabdol.sw1; 
import com.gabdol.sw2.*; 
... 
B b = new B(); 
... 


위의 코드의 import com.gabdol.sw2.*; 부분은 com.gabdol.sw1.A 클래스가 com.gabdol.sw2 패키지 내의 클래스들을 사용하겠다는 뜻이다. 이렇게 하면 자바 컴파일러가 B b = new B(); 부분을 컴파일하면서 B라는 클래스를 com.gabdol.sw1.A가 속해있는 com.gabdol.sw1 패키지와 임포트한 com.gabdol.sw2 패키지 내에서 찾게 된다. 만일, com.gabdol.sw1과 com.gabdol.sw2 패키지에 모두 B라는 이름의 클래스가 있다면 당연히 컴파일러는 어떤 것을 써야할지 모르므로 에러를 낸다. 이 경우에는 다음처럼 하는 수밖에 없다. 


package com.gabdol.sw1; 
import com.gabdol.sw2.*; 
... 
com.gabdol.sw1.B b1 = new com.gabdol.sw1.B(); 
com.gabdol.sw2.B b2 = new com.gabdol.sw2.B(); 
... 


import com.gabdol.sw1.*과 같이 *를 사용하면 com.gabdol.sw1 패키지 내의 모든 클래스를 사용하겠다는 뜻이고, com.gabdol.sw1.B 클래스만 사용한다면 import com.gabdol.sw1.B라고 명시하면 된다. 

클래스패스 
이제, 갑돌이는 C:\\myClass\\com\\gabdol\\sw1\\A.java 파일을 컴파일하려 한다. 갑돌이는 C:\\myClass\\com\\gabdol\\sw1\\ 폴더로 이동해서 다음처럼 할 것이다. 

javac A.java 


결과는 당연히 클래스 B를 찾을 수 없다는 에러 메시지이다. com.gabdol.sw1.B 클래스가 컴파일된 바이트코드인 B.class가 도대체 어디에 있는지 자바 컴파일러로서는 알 길이 없기 때문이다. 이 때 필요한 것이 클래스패스이다. 갑돌이가 다음처럼 하면 컴파일이 성공적으로 이루어진다. 

javac -classpath C:\\myClass A.java 


여기에 "-classpath C:\\myClass" 부분은 자바 컴파일러에게 C:\\myClass폴더를 기준으로 패키지를 찾으라는 뜻이다. 즉, com.gabdol.sw1.B 클래스는 C:\\myClass 폴더를 시작으로 C:\\myClass\\com\\gabdol\\sw1 폴더에서 찾고, com.gabdol.sw2.B 클래스는 C:\\myClass\\com\\gabdol\\sw2 폴더에서 찾는 것이다. 

그런데, 갑돌이는 돌쇠에게 건네 받은 클래스들을 C:\\otherClass 라는 폴더에 저장하고 있었는데, 이 중에 일부 클래스를 A.java에서 사용할 일이 생겼다. 돌쇠가 건네 준 클래스는 com.dolsse.ddol 이라는 패키지에 포함되어 있고, 이 클래스들은 C:\\otherClass\\pr\\com\\dolsse\\ddol 폴더에 있다면, 돌쇠가 준 클래스들은 C:\\otherClass\\pr 폴더를 시작으로 찾아야 한다. 따라서, 돌쇠의 클래스를 사용하는 A.java 파일을 컴파일하기 위해서는 다음처럼 해야 한다. 

javac -classpath "C:\\myClass;C:\\otherClass\\pr" A.java 


이렇게 하면 C:\\myClass 폴더에 저장되어 있는 com.gabdol.sw1.A, com.gabdol.sw2.B 클래스와 C:\\otherClass\\pr 폴더에 저장되어 있는 com.dolsse.ddol.* 클래스들을 자바 컴파일러가 제대로 찾을 수 있게 되는 것이다. 

A.java를 컴파일해서 얻어진 클래스를 직접 실행하려면 자바 가상 머신을 구동해야 하는데, 이 때에서 당연히 A.class가 사용하는 다른 클래스를 자바 가상 머신이 찾을 수 있어야 한다. 따라서, 역시 컴파일할 때와 마찬가지로 클래스패스가 필요하다. A.class를 실행하려면 다음처럼 해야 한다. 

java -classpath "C:\\myClass;C:\\otherClass\\pr" com.gabdol.sw1.A 


실행할 때에는 실행하고자 하는 클래스의 패키지 이름까지 명시해야 한다. 왜냐하면, 자바 가상 머신이 클래스를 실행할 때에는 지정된 이름이 패키지 이름을 포함한 것으로 생각하기 때문이다. 만일, 다음처럼 한다면, 

java -classpath "C:\\myClass;C:\\otherClass\\pr" A 


자바 가상 머신은 C:\\myClass\\A.class 혹은 C:\\otherClass\\pr\\A.class를 찾으려고 할 것이다. 

클래스패스란 여러 폴더에 산재한 클래스들의 위치를 지정해서 패키지에 따라 클래스를 제대로 찾을 수 있게 해 주는 값이다. 

환경 변수 
매번, 컴파일할 때와 실행할 때에 classpath 옵션에 클래스패스를 명시하는 것을 불편하다. 한 번의 설정으로 이런 문제를 해결하기 위해서 환경 변수라는 것을 사용한다. 많은 독자들이 역시 환경 변수가 무엇인지, 어떻게 설정하는지 모르는 경우가 많으므로 여기서 잘 정리해 보겠다. 

환경 변수는 말 그래로 변수에 어떤 값을 저장시키되 이를 환경에 저장하는 것이다. 환경에 저장한다는 말은 그 환경 내의 모든 프로그램이 그 변수의 값을 알 수 있게 된다는 뜻이다. 여러분이 윈도우 95/98/Me의 도스창 혹은 윈도우 NT/2000의 명령창을 실행시키면, 그 명령창 내에서 각종 프로그램을 구동할 수가 있는데, 이 때, 그 명령창의 환경에 변수 값을 설정하면 그 명령창 내에서 구동되는 프로그램들은 환경 변수 값을 얻을 수가 있게 된다. 

명령창 내에서 환경 변수를 설정하는 방법은 간단하다. 

C:\\> SET 변수이름=값 


혹은 

C:\\> SET 변수이름="값" 


처럼 하면 된다. 여러분의 명령창 또는 도스창을 띄워서 다음처럼 해 보자. 

C:\\> SET myname="Hong Gil Dong" 


이렇게 하면 환경 변수 myname에는 "Hong Gil Dong"이 설정된다. 제대로 설정이 되었는지 확인해 보기 위해서는 다음처럼 하면 된다. 

C:\\> echo %myname% 
"Hong Gil Dong" 


첫 번째 줄은 환경 변수 myname의 값을 출력하라는 명령이고, 두 번째 줄은 그 결과가 나온 것이다. 

환경 변수는 메모리가 허락하는 양만큼 설정할 수 있다. 즉, 다음처럼 복수 개의 환경 변수를 설정할 수 있다는 말이다. 

C:\\> SET myname="Hong Gil Dong" 

C:\\> SET yourname="Kim Gap Soon" 


자, 이번에는 이 명령창을 종료하고 다른 명령창을 띄워 보자. 그리고, 다음처럼 myname 환경 변수의 값을 출력해 보자. 

C:\\> echo %myname% 
%myname% 


두 번째 줄과 같은 결과가 나온다. 조금 전에 설정했던 값을 온데간데 없다. 왜 그럴까? 이유는 간단하다. 환경 변수는 그 명령창 내에서만 존재하기 때문이다. myname 변수를 설정한 명령창을 종료했기 때문에, 이와 동시에 myname 환경 변수가 사라진 것이다. 또, myname 변수를 설정한 명령창을 종료하지 않았다고 해도, 다른 명령창에서는 myname 변수 값을 공유하지 않는다. 오로지, 변수를 설정한 그 명령창 내에서만 그 변수는 의미가 있게 되는 것이다. 

이렇게 환경 변수가 명령창 내에서만 의미가 있기 때문에, 온갖 프로그램에서 공유하기 위해서는 명령창에서 환경 변수를 설정하는 방법 외에 다른 방법을 사용해야 한다. 윈도우 95/98/Me라면 autoexec.bat 파일을 사용하고, 윈도우 NT/2000이라면 글로벌 환경 변수를 설정하는 별도의 방법이 존재한다. 

우선, 윈도우 NT/2000이라면 다음처럼 한다. 

1. 바탕화면의 "내 컴퓨터"를 오른쪽 클릭한다. 

2. "고급" 메뉴를 택한다. 

3. 가운데 "환경 변수" 메뉴를 택한다. 

4. 두 창이 나오는데 위 쪽은 특정 로그인 사용자에 대한 환경 변수를 설정하는 것이고, 아래 쪽은 모든 사용자에게 적용되는 환경 변수를 설정하는 것이다. 관리자(Administrator) 권한을 갖고 있다면 아래 시스템 변수의 값을 설정할 수 있다. 상황에 맞게 선택하면 된다. 

5. 버튼이 "새로 만들기", "편집", "삭제"가 있는데, 새로운 환경 변수를 만드는 경우에는 "새로 만들기"를 클릭하고, 기존 변수 값을 수정하고자 한다면 "편집"을 누른다. "삭제"는 물론 변수를 아예 없애는 경우에 클릭한다. 

6. "새로 만들기"나 "편집"을 클릭하면 변수 이름과 값을 설정하게 되어 있는데 여기에 원하는 이름과 값을 입력하면 된다. 


윈도우 95/98/Me라면, autoexec.bat 파일을 편집기로 열어서 "set 변수이름=값"을 아무데나 추가하면 된다. 

자, 이제는 글로벌 환경 변수에 클래스패스 변수를 설정해 보자. 

윈도우 NT/2000이라면 위의 단계를 차례로 실행한 후에, 이미 CLASSPATH 혹은 classpath 변수가 있다면 이를 편집하고, 없다면 새로 만들기를 하면 된다. 지금까지 예로 든 대로라면 다음의 값을 입력하면 된다. 

C:\\myClass;C:\\otherClass\\pr 

<김상욱 주: 이렇게만 하면 한 디렉토리에서 방금 만들어진 클래스파일 즉 현재 디렉토리의 클래스파일을 찾지 못하기 때문에 현재 디렉토리를 나타내는 . 을 추가한다.> 

<즉, .\\C:\\myClass;C:\\otherClass\\pr 이렇게 입력하여야 합니다.> 


윈도우 95/98/Me라면 autoexec.bat 파일을 열어서, 다음의 한 줄을 추가한다. 

set CLASSPATH="C:\\myClass;C:\\otherClass\\pr" 

<김상욱 주: 마찬가지 이유로 set CLASSPATH=".;C:\\myClass;C:\\otherClass\\pr" 로 입력되어야 합니다.> 


그렇다면, 자바 컴파일러와 자바 가상 머신은 이렇게 설정한 환경 변수와는 어떤 관계가 있을까? 자바 컴파일러와 자바 가상 머신은 -classpath 옵션을 지정하지 않으면 환경 변수 CLASSPATH 혹은 classpath의 값을 시스템으로부터 얻어서 이를 클래스패스로 사용한다. 클래스패스의 값을 환경 변수로부터 얻을 수 있도록 애초부터 만들어진 것이다. 

jar 파일과 클래스패스 
jar 파일은 클래스들을 묶어 놓은 것이다. 즉, 갑돌이는 자신이 만든 com.gabdol 이하의 모든 클래스를 하나의 파일인 gabdol.jar 파일로 묶을 수가 있다. 이렇게, gabdol.jar 파일을 C:\\gg\\cc 폴더 아래에 두었다면 이 압축 파일 내의 클래스를 역시 자바 컴파일러와 자바 가상 머신이 찾을 수 있도록 해야 한다. 이 때에는 파일 이름까지 포함해서 클래스패스에 추가해야 한다. 다음처럼 말이다. 

set CLASSPATH=C:\\gg\\cc\\gabdol.jar;C:\\myClass;C:\\otherClass\\pr 


마치며 


지금까지 자바 프로그램의 가장 기초라고 할 수 있는 클래스패스에 대해서 알아 보았다. 필자는 이 글로 더 이상의 클래스패스에 대한 질문이 사라졌으면 하는 바램이다. 독자 여러분이 클래스패스를 고민하는 것도 시간 낭비이고, 저자가 이에 대해서 일일이 답변해 주는 것도 시간 낭비라고 생각된다. 만일, 독자 여러분이 클래스를 찾지 못한다는 에러를 만난다면 100% 클래스패스 설정 잘못이므로, 이 글을 잘 읽어서 근본적으로 클래스패스에 대해서 이해한 후에 문제를 해결하는 노력을 기울이도록 하자. 

DBMS의 종류

대표적 상용 DBMS의 간략히 소개하고자 한다.

① Oracle

 Oracle사의 대표적인 제품으로써 전 세계적으로 가장 많은 수요자 층을 확보하고 있는 제품이다. 현재 Oracle10g버전이 출시되어 있다. 유닉스, 리눅스, 윈도우 버전이 따로 있으며 리눅스 버전의 경우에는 홈페이지에서 다운로드 받아 개발용으로 사용할 수 있다.

Oracle Korea 홈페이지 (http://www.oracle.co.kr)

② Microsoft SQL Server

 마이크로소프트의 대표적인 데이터베이스 시스템이다. 윈도우 환경에서 가장 많이 사용되고 있으며 비주얼 베이직과의 직접적인 프로그래밍도 가능하다. Windows 2000 서버나 Windows 2003 서버를 사용하는 시스템에서 활용되고 있으며 SQL Server2005까지 출시되었다.

Microsoft의 SQL Server 홈페이지 (http://www.microsoft.com/sql/) 

③ DB2

 IBM의 DB2(Data Base 2)는 1983년에 발표된 상업용 관계 데이터 베이스 관리 시스템으로서 MVS/XA와 MVS/370 운영체제에서 사용되며, SQL을 데이터 언어로 사용하여 다수의 사용자들이 여러 개의 관계 데이터 베이스를 동시에 접근할 수 있는 대형 데이터 베이스를 위한 시스템이다. 현재 DB2 9까지 출시 되었다.

IBM DB2 소개 홈페이지 (http://www-306.ibm.com/software/data/db2/v9/)

④ Sybase

 Sybase는 엔터프라이즈 정보시스템 구축을 위한 Client/Server 환경에서 가장 강력한 데이터베이스 관리시스템 소프트웨어로, 데스크탑 환경에서뿐만 아니라 엔터프라이즈 컴퓨팅에 이르기까지 토탈 솔루션 제공한다. 기존에 RDBMS 들의 단점을 보완한 Client/Server 아키텍처를 기본 사상으로 개발되어, 하드웨어 플랫폼과 무관한 개방형 시스템 구조로 확장성과 상호 운용성, 신뢰성 및 가용성을 최대의 장점으로 부각된 제품이다.

Sybase 홈페이지 (http://www.sybase.com)

⑤ Informix

 Informix사의 Informix DBMS는 객체지향기술을 접목하여 Image, Audio, Video, TimeSeries 등 비정형 Data의 탁월한 통합처리를 보장하며 OLTP에서부터 DataWare Housing, Data Marts, Internet / Intranet / Extranet, GIS, Entertainment산업에 이르는 모든 Application을 지원하는 시스템이다.

Informix 홈페이지 (http://www.informix.com/) 

⑥ Microsoft Access

 마이크로소프트의 대표적인 개인용 데이터베이스 관리 시스템이다. Office 프로그램에 제공되며, 비주얼 베이직에서 기본적으로 활용하는 데이터베이스이다. MDB라는 확장자를 가지고 저장되며, 윈도우에만 사용이 가능하다.

오라클의 adump, bdump, udump, 리스너 로그, 아카이브 로그 등을 백업할 수 있으면 백업하는 것을 권장한다. 하지만 대부분의 경우 백업의 필요성이 절실하지 않기 때문에 삭제한다.

각종 로그의 자동관리를 위하여 첨부한 파일과 같이 CRONTAB에 등록하여 관리하면 편리하다.
각각의 로그관리에 대한 정책이 필요하다.

정책 예시)
1. alert 로그       : 월별로 로그를 관리. 영구 보관하는 것이 좋다.
                      compress 명령으로 압축하여 보관.
2. adump audit 파일 : 180일 정도 유지, 매일 180일이 지난 trc파일을 삭제
3. bdump trace 파일 : 90일 정도 유지, 매일 90일이 지난 trc파일을 삭제
4. udump trace 파일 : 90일 정도 유지, 매일 90일이 지난 trc파일을 삭제
5. 리스너 로그      : 리스너를 로깅하도록 설정했을 경우 월별로 로그를 관리.

                      180일이 지난 파일은 삭제.
                      compress 명령으로 압축하여 보관.
6. 아카이브로그 파일 : 기본적으로 1주일에 1번 이상 FULL BACKUP을 받을 경우
   백업 툴에서 아카이브로그를 관리해 주지 않을 경우 등록하여 사용
   7일전 아카이브로그 파일 삭제.

쉘 예시) 쉘 스크립트 작성 시 오타에 주의할 것
#######################################################
#### alert.log                                     ####
#######################################################
nDate=`date +%Y%m%d`
cp $ORACLE_BASE/admin/TESTDB/bdump/alert_TESTDB.log $ORACLE_BASE/TESTDB/bdump/alert_TESTDB.log.$nDate
cat /dev/null > $ORACLE_BASE/admin/TESTDB/bdump/alert_TESTDB.log
compress -vf $ORACLE_BASE/TESTDB/bdump/alert_TESTDB.log.$nDate

#######################################################
#### listener.log                                  ####
#######################################################
nDate=`date +%Y%m%d`
cp $ORACLE_HOME/network/admin/listener.log $ORACLE_HOME/network/admin/listener.log.$nDate
cat /dev/null > $ORACLE_HOME/network/admin/listener.log
compress -vf $ORACLE_HOME/network/admin/listener.log.$nDate

#######################################################
#### audit                                         ####
#######################################################
# 1주일이 지난 *.aud를 찾아 삭제
find $ORACLE_BASE/admin/TESTDB/adump \( -ctime +7 -name '*.aud' \) -exec rm -f {} \;

#######################################################
#### .trc                                          ####
# 30일이 지난 *.trc를 찾아 삭제                    ####
#######################################################
find $ORACLE_BASE/admin/TESTDB/bdump \( -ctime +30 -name '*.trc' \) -exec rm -f {} \;
find $ORACLE_BASE/admin/TESTDB/udump \( -ctime +30 -name '*.trc' \) -exec rm -f {} \;

#######################################################
#### archive log                                   ####
#######################################################
# 3일이 지난 *.arc를 찾아 삭제
find /archive_log \( -ctime +3 -name '*.arc' \) -exec rm -f {} \;

#########################################################
# 특정 디렉토리가 70%이상이면 3일지난 *.arc를 찾아 삭제 #
#########################################################
#!/usr/bin/ksh
A=`df -k /archive_log | grep -v "용량" | awk '{print $5}' | sed 's/%//'`
if [ $A > 70 ] ;
then
    find /archive_log \( -ctime +3 -name '*.arc' \) -exec rm -f {} \;
fi