재시도

서비스 타임아웃은 위 구조에서 서비스요청이 큐에서 나와 실제 서비스가 수행되는 시작부터 서비스가 끝나는 구간 설정된 타임아웃시간을 넘어 설 때 발생합니다.

-      Service timeout 발생 후 BBL의 AP서버 재기동 구조

: 다량의 AP 서버가 서비스타임아웃발생으로 동시에 shutdown 되면 발생과 동시에 타임아웃이 발생한 AP서버에게 시그널을 보내서 shutdown 시키며 ULOG에 타임아웃 서비스를 write 합니다.

그 후에 BBL이 AP서버들의 상태를 확인 하는 주기

SANITYSCAN * SCANUNIT (현재 ???)  에 따라 shutdown된 AP서버를 재기동 하게 되는데 이때 shutdown 된 시점보다 위 주기에 따라 부팅되는 시간은 차이가 날수 있으며  또 하나 순간적으로 다량의 AP서버가 shutdown 되면 BBL의 재기동 하는 작업도 순차적으로 AP 서버들을 기동하게 되어 재 기동 되는 전체 시간의 지연이 발생하게 됩니다.

테스트 환경

클라이언트  Oracle Linux 6.6 

서버            IBM AIX 7.2   

테스트 내용 

client --------> AP Server1 -------->  AP Server2  순서로 서비스 호출

AP Server1 서비스 함수 TOUPPER (소문자 -> 대문자 호출 서비스)

AP Server2 서비스 함수 TOLOWER (대문자 -> 소문자 호출 서비스)

로직 

Client --------> AP Server1 (client) --------> AP Server2 (server)

          (tpcall)                                (tpcall)

즉, AP Server1은 AP Server2의 클라이언트가 된다.

이 로직을 완성시키기 위해서는 AP Server1의 simpserv.c 파일을 클라이언트로 컴파일 해주어야한다.

(클라이언트의 simpcl.c  파일을 참고하여 코딩한다) 

컴파일된 simpcl(Client) 실행모듈이 TOUPPER 서비스를 호출을 요청하게되면 서버로 보내지게 되고, TOUPPER 서비스를 가지고 있는 AP server인 simpserv 실행모듈은 TOUPPER 서비스를 리턴하지않고 다시 TOLOWER 서비스를 가지고 있는 AP server인 simpserv2 실행모듈이 simpserv(클라이언트)의 호출을 받아 TOLOWER 서비스를 Client에게 return하게 된다.

따라서

1. simpcl(클라이언트)이 TOUPPER 서비스를 호출하여도 return 받는 것은  TOLOWER 서비스이다.

2. simpcl(클라이언트)이 TOLOWER 서비스를 호출하여도 return 받는 것은 TOLOWER  서비스이다.

테스트 결과 

# TOLOWER 호출 -> TOUPPER 리턴 -> TOLOWER 호출 ->  TOLOWER 리턴 
$ ./simpcl thisislowercasetotouppercase
Returned string is: thisislowercasetotouppercase

# TOUPPER 호출 -> TOUPPER 리턴 -> TOLOWER 호출 -> TOLOWER 리턴
$ ./simpcl THISISLOWERCASETOTOUPPERCASE
Returned string is: thisislowercasetotouppercase

<simpcl.c>

#include <stdio.h>
#include "atmi.h"             


#if defined(__STDC__) || defined(__cplusplus)
main(int argc, char *argv[])
#else
main(argc, argv)
int argc;
char *argv[];
#endif

{

        char *sendbuf, *rcvbuf;
        long sendlen, rcvlen;
        int ret;

        if(argc != 2) {
                (void) fprintf(stderr, "Usage: simpcl string\n");
                exit(1);
        }

        if (tpinit((TPINIT *) NULL) == -1) {
                (void) fprintf(stderr, "Tpinit failed\n");
                exit(1);
        }

        sendlen = strlen(argv[1]);


        if((sendbuf = (char *) tpalloc("STRING", NULL, sendlen+1)) == NULL) {
                (void) fprintf(stderr,"Error allocating send buffer\n");
                tpterm();
                exit(1);
        }

        if((rcvbuf = (char *) tpalloc("STRING", NULL, sendlen+1)) == NULL) {
                (void) fprintf(stderr,"Error allocating receive buffer\n");
                tpfree(sendbuf);
                tpterm();
                exit(1);
        }

        (void) strcpy(sendbuf, argv[1]);

        ret = tpcall("TOUPPER", (char *)sendbuf, 0, (char **)&rcvbuf, &rcvlen, (long)0);

        if(ret == -1) {
                (void) fprintf(stderr, "Can't send request to service TOUPPER\n");
                (void) fprintf(stderr, "Tperrno = %d\n", tperrno);
                tpfree(sendbuf);
                tpfree(rcvbuf);
                tpterm();
                exit(1);
        }

        (void) fprintf(stdout, "Returned string is: %s\n", rcvbuf);

        /* Free Buffers & Detach from System/T */
        tpfree(sendbuf);
        tpfree(rcvbuf);
        tpterm();
        return(0);
}

<simpserv.c>

#include <stdio.h>
#include <ctype.h>
#include <atmi.h>       /* TUXEDO Header File */
#include <userlog.h>    /* TUXEDO Header File */

#if defined(__STDC__) || defined(__cplusplus)
tpsvrinit(int argc, char *argv[])
#else
tpsvrinit(argc, argv)
int argc;
char **argv;

#endif
{
        argc = argc;
        argv = argv;

        userlog("Welcome to the simple server");
        return(0);
}


#ifdef __cplusplus
extern "C"
#endif
void
#if defined(__STDC__) || defined(__cplusplus)
TOUPPER(TPSVCINFO *rqst)
#else
TOUPPER(rqst)
TPSVCINFO *rqst;
#endif
{
	#변수선언
        int ret;
        char *sendbuf, *rcvbuf;
        long sendlen, rcvlen;
        #구조체연산자
        sendlen = strlen(rqst->len); 


        if((sendbuf = (char *) tpalloc("STRING", NULL, sendlen+1)) == NULL) {
                (void) fprintf(stderr,"Error allocating send buffer\n");
                tpterm();
                exit(1);
                tpterm();
                exit(1);
        }

        if((rcvbuf = (char *) tpalloc("STRING", NULL, sendlen+1)) == NULL) {
                (void) fprintf(stderr,"Error allocating receive buffer\n");
                tpfree(sendbuf);
                tpterm();
                exit(1);
        }
		
        (void) strcpy(sendbuf, rqst->data);


      
        
        ret = tpcall("TOLOWER", (char *)sendbuf, 0, (char **)&rcvbuf, &rcvlen, (long)0);


         if(ret == -1) {
                (void) fprintf(stderr, "Can't send request to service TOUPPER\n");
                (void) fprintf(stderr, "Tperrno = %d\n", tperrno);
                tpfree(sendbuf);
                tpfree(rcvbuf);
                tpterm();
                exit(1);

}

        tpreturn(TPSUCCESS, 0, rcvbuf, 0L, 0);


}

<simpserv2.c>

# vi simpserv2.c

#include <stdio.h>
#include <ctype.h>
#include <atmi.h>       /* TUXEDO Header File */
#include <userlog.h>    /* TUXEDO Header File */


#if defined(__STDC__) || defined(__cplusplus)
tpsvrinit(int argc, char *argv[])
#else
tpsvrinit(argc, argv)
int argc;
char **argv;
#endif
"simpserv2.c" 85 lines, 2155 characters
char **argv;
#endif
{
        argc = argc;
        argv = argv;

        userlog("Welcome to the simple server");
        return(0);
}

#ifdef __cplusplus
extern "C"
#endif
void
#if defined(__STDC__) || defined(__cplusplus)
TOLOWER(TPSVCINFO *rqst)
#else
TOLOWER(rqst)
TPSVCINFO *rqst;
#endif
{

        int i;

        for(i = 0; i < rqst->len-1; i++)
                rqst->data[i] = tolower(rqst->data[i]);

        tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);

#ifdef __cplusplus
extern "C"
#endif
void
#if defined(__STDC__) || defined(__cplusplus)
TOLOWER(TPSVCINFO *rqst)
#else
TOLOWER(rqst)
TPSVCINFO *rqst;
#endif
{

        int i;

        for(i = 0; i < rqst->len-1; i++)
                rqst->data[i] = tolower(rqst->data[i]);

        tpreturn(TPSUCCESS, 0, rqst->data, 0L, 0);
}

참고자료 

https://mc529.tistory.com/1098?category=979773 

테스트환경 : IBM AIX 7.2

한 장비에서 tuxedo 서버를 2개 이상 띄우지 못한다.

Tuxedo 10g

Tuxedo 12c 

두개를 기동하려고 했으나 

하나가 띄워져있는 상태에서 다른 하나를 띄우려고 하면, 멈추는 에러가 발생.

BLOCKTIME : RESOURCES Section
 
- BLOCKTIME = BLOCKTIME * SCANUNIT
- tpinit 을 한 tuxedo client 가 tpcall, tpacall, tpconnect, tpsend, tprecv 등을 처리할 때
- asynchronous service requests 일 경우에는 각각의 send, receive 동작 각각의 시간에 적용
- 아래와 같은 시간을 합한 값으로 결정
  * 요청 server의 request queue 로 보내는데 걸리는 시간.
  * 해당 server 에서 로직 처리하는데 걸리는 시간
  * 요청된 server 가 로직을 다 처리한후 reply queue 로 부터 메세지를 받는 시간
  * 위의 처리중에 네트웍에서 걸린 시간.

SVCTIMEOUT  : SERVICES Section

 - 이것은 특정 서버내에 잘못된 long job 을 갖고 있는 service 가 존재할경우 해당 service 가 실행하는 동안 다른 서비스가 실행될수 없기때문에 특정 시간이 지나면 해당 서버를  kill 시키는 옵션
 - 물론 이런경우에는 server 가 재부팅되게 해야 함.
 - 이 시간은 단순히 service 가 실행되는 시간을 count.
 - 만일 이옵션을 사용하지 않으면, 기본적으로 해당 서비스가 끝날 때까지 지속됨.
 - 턱시도는 기본적으로 특정 process 를 강제로 죽이지 않음.
 - 일 설정 값(초단위)을 넣게 되면 해당 초 동안에 서비스가 실행되어야 함.

TRANTIME : SERVICES Section

 - 이경우는 AUTOTRAN 설정시에 해당 서비스의 Transaction timeout 을 설정
 - AUTOTRAN 은 자동을 tuxedo 에서 트랜잭션을 처리해줌. ( begin, join 여부를 알아서 판단해줌 )
 - tpbegin : client or server 내에서 transaction 을 처리할 때 사용하는 API.  매개변수 값으로 해당 값을 넣으면 그 값에 의해서 트랜잭션 타임아웃 값이 결정됨.

1. Opatch 소개

Oracle Server 9.2.0.2.0 부터는 interim patch(one-off patch, 즉 single patch)를 적용할 때 'opatch'

라는 tool을 사용한다.

One-off Patch 는 특정 버그에 대한 조치이며, 이것들의 모음을 PacthSet 이다

지원 PLATFORM : UNIX, WINDOWS PLATFORM

Metalink에서는 항상 최신 Opatch tool 을 download받을 수 있도록 갱신된다.

2. Opatch 기능

-      INTERIM PATCH를 적용(APPLY)

-      설치된 INTERIM PATCH를 제거 (ROLLBACK)

-      기 설치된 INTERIM PATCH와 CONFLICT여부 점검

-      설치된 PRODUCT 및 INTERIM PATCH를 REPORT

3. Opatch 사용 환경

1) Opatch를 사용하기 위한 준비사항

Perl version은 최소한 5.005_03 이상을 요구하며 가급적 5.6 이상을 권장한다.

JRE는 $ORACLE_HOME에 설치된 JRE를 사용한다.

2) inventory

Inventory는 Oracle RDBMS 설치 시 두 개의 inventory가 생성된다.

하나는 oraInst.loc에서 지정된 inventory directory이고, 이것을 central inventory라고 한다.

다른 하나는 $ORACLE_HOME 아래에 생성되는 inventory directory이며 이것을 Local inventory라고

한다. Opatch 적용 시 반드시 이 두 개의 inventory가 정상적으로 유지되어야 한다.

oracleInst.loc 는 보통 다음 위치에 있다

-      AIX와 Linux /etc directory에 위치

-      다른 Unix에서는 /var/opt/oracle

-      Windows는 registry에서 HKEY_LOCAL_MACHINE\Software\Oracle\inst_loc

3) RAC 환경인 경우 Oracle과 Cluster와의 인터페이스를 위하여 oracle library를 사용하는데 다음 경

로가 library path에 포함되어 있어야 한다.

Sun solaris의 경우 LD_LIBRARY_PATH 이고, HP-UX의 경우 SHLIB_PATH이다.

4. Opatch Download

 http://metalink.oracle.com 에 접속 -> patches button 클릭 -> simple search 선택 ->

Patch number 입력 -> platform 선택 -> 최신 날짜의 항목 Download

5. Opatch 설치

1) Metalink에서 최신 버젼 Opatch를 download받으면 p2617419_10102_GENERIC.zip 이런 형태로

 파일이 존재한다.

2) 이 파일을 원하는 위치에 COPY 후, 압축을 푼다.

3) 사용자가 임의로 원하는 디렉토리를 만들어서 그 디렉토리에 화일을 푼다.

$ unzip p2617419_10102_GENERIC.zip

2) OS의 어느 디렉토리에서 사용하든지 상관없도록 하기 위해 환경변수 PATH에 Opatch가 설치되어

있는 디렉토리를 기술한다.

예) export PATH=$PATH:/oracle/opatch/Opatch

setenv PATH $PATH:/oracle/opatch/Opatch

6. 주의 사항

Opatch 적용 시에는 반드시 기존의 inventory 즉, $ORACLE_HOME/inventory와

oraInst.loc에서 지시하는 central inventory를 backup받아 두어야 한다.

Windows의 경우 winzip, unix에서는 tar를 사용하면 된다.

Opatch Directory 구조

/docs                  관련문서

/jlib                     Opatch에서 사용되는 CLASS FILE

/perl_modules      PERL MODULES

INTERIM PATCH DIRECTORY 구조

/actions               PATCH시 적용할 대상 아카이브파일, 디렉토리, make 파일 등이 기록

/inventory                          PATCH 적용 후 oracle inventory에 업데이트 헤야 하는 내용과 대상 플랫폼, 오라클 버전이 기록

/GenericActions.xml                        각 운영체제별로 사용할 명령어가 정리

/ShipHomeDirectoryStructure.xml      Patch 디렉토리의 구조가 정의

옵션 정리

1. opatch apply  : PATCH 적용

apply <ShipHome> -force -oh <OracleHome>

opatch apply -invPrtLoc $ORACLE_HOME/oraInst.loc

이 명령어는 oraInst.loc 파일의 위치가 default directory가 아닌 경우 해당 위치를 지정하여 patch를

적용하는 명령이다.

2. opatch rollback  : 적용된 PATCH를 ROLLBACK

rollback -id <patch id> -oh <OracleHome> -ph <patch dir>

opatch rollback -id 3113008 -ph /opt/oracle/3113008

이 명령어는 patch id 3113008을 depatch하며, 이 때 기존 patch file이 있는 directory를 -ph

argument를 이용하여 지시한다. 기본적으로 사용하는 옵션은 -id 이다

-local 옵션은 RAC 환경에서 depatch를 다른 노드에 전파하지 않고 Local 노드에만 적용할 때 사용

한다. 이 경우 모든 노드에서 개별적으로 depatch가 진행되어야 한다.

3. opatch lsinventory  : 적용된 PATCH 조회

lsinventory -all -oh <OracleHome>

opatch lsinventory -all -oh /opt/oracle

이 명령어는 현재 db 서버에 적용되어 있는 patch list를 보여준다.

예) $ opatch lsinventory -all

PRODUCT NAME VERSION

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

Advanced Queueing (AQ) API 9.2.0.1.0

Advanced Replication 9.2.0.1.0

Agent Required Support Files 9.2.0.1.0

.

..

XML Transx 9.2.0.1.0

XSQL Servlet 9.2.0.1.0

Installed Patch List:

1) Patch 3574853 applied on Sun Apr 25 03:27:43 JST 2004

Base Bug(s): 3111457

2) Patch 3400911 applied on Sun Apr 25 03:24:40 JST 2004

Base Bug(s): 3304290

3) Patch 3508417 applied on Sun Apr 04 22:53:59 JST 2004

Base Bug(s): 3046394

4) Patch 3213774 applied on Sun Apr 04 09:12:08 JST 2004

Base Bug(s): 3186503 3210293

5) Patch 3226815 applied on Sun Apr 04 09:09:22 JST 2004

Base Bug(s): 3157063

6) Patch 3118677 applied on Sun Apr 04 09:06:28 JST 2004

Base Bug(s): 3118677

7) Patch 3113003 applied on Sun Apr 04 09:04:45 JST 2004

Base Bug(s): 2968709

4. opatch query  : interim patch에 대한 정보를 조회한다.

5. opatch version

이 명령어는 사용하는 opatch 유틸리티의 version을 보여준다.

6. 모든 opatch 명령어는 각 명령어에 대한 상세한 usage를 보여주는 -help 옵션을 가진다.

opatch.pl [ -help { [ apply | lsinventory | rollback | version ] }

RAC에서의 Opatch 사용

기본적으로 임시 패치 적용시는 인스턴스를 다운한 후 적용해야 하므로, 패 치 적용시는

서비스를 할 수 없게 된다. RAC에서는 몇 가지 아규먼트를 사용 하여 다운타임을 최소화

할 수 있다.

대략적으로RAC에서 패치가 적용되는 방법을 적어보면 다음과 같다. 

If (사용자가 패치 적용방법을minimize_downtime으로 설정) 
patching mechanism = Minimize Downtime 
else if (패치가 롤링 패치를 지원) 
patching mechanism = Rolling 
else 
patching mechanism = All-Node 

여기서, 주의할 점은 CFS 등의 공유 파일 시스템에 오라클 제품을 설치 하여 여러 노드에

서 공유하는 경우에는 minimize_downtime과 롤링 패치 가 적용되지 않는다는 것이다. 

All-Node

이것은 일반적인 데이타베이스에 패치를 적용하는 것처럼, 모든 인스턴스를 다운한 후, 한

노드씩 순차적으로 진행한다. ORACLE_HOME을 여러 노드 에서 공유하는 경우는 이 방식

으로 패치를 적용해야 한다. 

Minimize_downtime

Minimize_downtime은 RAC 운영시 다운타임을 최소화하기 위해 사용된 다. 2노드RAC의 경

우를 예로 패치 절차를 알아보자. 

1.먼저 로컬 노드의 인스턴스를 셧다운한다. 
‘opatch apply -minimize_downtime’명령으로 패치를 시작한다. 

2. ‘Is this node ready for updating?’질문에‘Yes’로 답하면, 로컬 노드에 패치가 적용된다. 

3.패치 적용 후 다음에 적용할 노드명을 물어본다. 

4.해당 노드명을 입력하면, 이 노드의 인스턴스를 셧다운하도록 요청한다. 

5.요청받은 노드의 인스턴스는‘Shutdown immediate’로 셧다운한 후, 셧 다운이 완료되면

이미 패치가 적용된 노드의 인스턴스가 셧다운한다. 

6.두 번째 노드에 패치를 적용한다. 

7.인벤토리 정보가 업데이트된다. 

8.패치가 완료되면 두 번째 인스턴스도 셧다운한다. 

Minimize_downtime 아규먼트를 사용해도 모든 인스턴스가 다운되는 단계는 있지만, 5번 단

계에서만 해당되므로, 다운타임을 최소화할 수 있다. 

Rolling Patch

롤링 패치가 Minimize_downtime과 틀린 점은 다운타임이 전혀 없다는 것이다. 적용 절차는

다음과 같다. 

1.먼저 인스턴스1을 셧다운한다. 이 단계에서 인스턴스2는 서비스 중이다. 
2.노드1에서‘opatch apply’명령으로 패치를 적용한다. 
3.노드1에 패치가 적용되었으면, 인스턴스1을 시동하라는 메시지를 받는다. 
그리고 다음에 적용할 노드를 입력하도록 메시지를 받는다. 
4.인스턴스2를 셧다운한다. 
5.3번 세션에서 계속 이어서 노드2에 패치를 적용한다. 
6.패치 적용후 인스턴스2를 시동한다. 

롤링 패치는 모든 패치가 다 가능한 것은 아니고, 롤링 패치를 지원하도 록 설계된 패치만

가능하다. 롤링 패치가 가능한지 여부는‘opatch query - is_rolling’명령으로 확인할 수 있다.

OS별 진행 사항

DB Engine Backup 후 10.2.0.4 PatchSet 적용(HP-UNIX/Oracle 10g)

패치 적용 절차

Step1) source 압축 풀고, xmanager Display 설정

Step2) Application Service 중지

Step3) Listener Process 중지

oracle$> lsnrctl stop

Step4) Oracle Instance 종료

SQL> shutdown immediate

Step5) Oracle Engine Backup

root#> cd $ORACLE_HOME

root#> tar –cvf  $ORACLE_HOME.tar $ORACLE_HOME

* engine backup location 확인

Step6) patchSet 적용

./runInstaller

Root.sh

cd $ORACLE_HOME/rdbms/admin

SQL> sqlplus “ /as sysdba”

SQL> startup upgrade

SQL> @catupgrd.sql

SQL> shutdown immediate

SQL> startup

SQL> @utlrp.sql

SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS = 'INVALID'; 확인

Step7) Listener process 시작

oracle$> lsnrctl start

원복 절차

1.     엔진 디렉토리 rm –rf 명령어로 지움

2.     Tar  -xvf  $ORACLE_HOME.tar  $ORACLE_HOME

DB Engine Backup 후 9.2.0.8 PatchSet 적용(Windows/Oracle 9i)

패치 적용 절차

Step1) Application Service 중지

Step2) Listener Process 중지

oracle$> lsnrctl stop

Step3) Oracle Instance 종료

SQL> shutdown immediate

Step4) 컴퓨터 관리 -> 서비스 및 응용 프로그램 -> 서비스 에서

프로세서 확인

Step5) Oracle Engine Backup, 데이터파일 backup

C:\> set ORACLE_HOME=C:\ORACLE\9.2.0.8           $ORACLE_HOME 폴더 확인

C:\>  압축(윈도우 자체 압축 프로그램 사용)

* engine backup location 확인

C:\> copy명령어 사용 복사

Ex) Copy /oradata /backup

Step6) patchSet 적용

Setup.exe

Step7) shared_pool_size, java_pool_size 설정

SQL> sqlplus “ /as sysdba”

SQL> startup

SQL> show parameter pfile;

SQL> show parameter shared_pool_size

SQL> show parameter java_pool_size

l  만약 shared_pool_size 와 java_pool_size가 적어도 150m가 안된다면

Spile을  사용하여 설정한다.

create spfile from pfile;

alter system set shared_pool_size=’150m’ scope=spfile;

alter system set java_pool_size=’150m’ scope=spfile;

SQL> shutdown

Step8) 업그레이드

C:\> lsnrctl start

C:\> $ORACLE_HOME/rdbms/admin

C:\> sqlplus “/as sysdba”

SQL> startup migrate

SQL> spool patch.log

SQL> @catpatch.sql

SQL> spool off

Patch.log 확인 후 필요하다면 catpatch.sql을 재실행 한다

SQL> shutdown

SQL> startup

SQL> @utlrp.sql

SQL> SELECT OBJECT_NAME FROM DBA_OBJECTS WHERE STATUS = 'INVALID'; 확인

원복 절차

1.     엔진 디렉토리 삭제

2.     엔진 압축 파일해제

기타 팁

OPatch silent 자동화 방법

ㄱ. 먼저 ocm.rsp 생성

1. 해당 경로로 이동

cd $ORACLE_HOME

2. Opatch 경로 bak로 변경’

mv OPatch OPatch_bak

3. media를 $ORACLE_HOME으로 이동(최신 OPatch 파일로)

cp p6880880_102000_HPUX-IA64.zip $ORACLE_HOME

4. $ORACLE_HOME 에서 unzip 실행

unzip p6880880_102000_HPUX-IA64.zip

5. 신규 OPatch/ocm/bin 경로로 이동

cd OPatch/ocm/bin

6. emocmrsp 실행 및 내용 넣기 (엔터 등)

./emocmrsp

ㄴ. OPatch silent 자동화

1. ocm.rsp 파일 media 있는 경로로 이동’

cp ocm.rsp /oracle/media

2. 경로 여기로 이동

cd /oracle/media

3. 나머지 패치파일 unzip

unzip p6367097_10204_HPUX-IA64.zip

unzip p7318276_10204_HPUX-IA64.zip

unzip p8576156_10204_HPUX-IA64.zip

4. OPatch silent 모드로 실행

opatch apply 6367097 -local -silent -ocmrf /oracle/media/ocm.rsp;

sleep 5;

opatch apply 7318276 -local -silent -ocmrf /oracle/media/ocm.rsp;

sleep 5;

opatch apply 8576156 -local -silent -ocmrf /oracle/media/ocm.rsp;

OPatch lsinventory로 패치 잘 됐는지 확인

자료출처 

https://blog.naver.com/jsmguy/90074707124

Opatch : 다재다능한 패치 관리 유틸리티
남궁혁 | 한국오라클
오라클에서는 패치 관리 유틸리티 Opatch를 통해 새로운 패치 관리 기능들을 제공하고 있다. 
여기서는 Opatch의 구성 및 설치 방법과 각 명령어의 사용법을 소개한다. 
아울러, 기존에 발생했던 몇 가지 문제들도 소개함으로써, 독자의 Opatch 사용에 도움을 줄 것이다. 
오라클에서는 특정 문제를 완벽하게 해결한 패치셋(patchset)이나 차기 릴리즈를 발표하기 전에 임시 패치(interim patch, 혹은‘one-off’patch) 를 제공하여 해당 문제에 적용할 수 있도록 하고 있다. 물론, 이 임시 패치 는 특정 버전의 컴포넌트에만 적용할 수 있다. 예를 들어, Oracle Database 8.1.7.3에 대해 생성된 임시 패치는 Oracle Database 8.1.7.4에 는 적용할 수 없다. 그리고, 대부분의 임시 패치는 차기 패치셋에 포함된다. 그런데, 이 임시 패치는 해당 문제가 해결됐는지는 테스트하지만, 패 치가 적용된 후 발생할 수 있는 부작용 등을 테스트하는 리그레션 (Regression) 테스트는 하지 않는다. 이 리그레션 테스트는 패치셋에서 테 스트된다. 따라서 특별한 경우가 아니라면, 임시 패치를 적용하기보다는 패치셋을 적용할 것을 권한다. 
임시 패치를 여러 개 적용하다 보면, 이전 임시 패치와의 충돌이 발생 하기도 한다. 이를 방지하기 위해서, 임시 패치를 요청할 경우에는 Oracle Support에 이전에 설치한 모든 임시 패치 리스트를 제공하여, 충돌여부를 확인하고, 만약 충돌 발생시 병합하는 과정을 거치도록 해야 한다(임시 패 치 적용시 또 하나 주의할 점은 함께 제공되는 해당 패치의 Readme 파일 을 꼭 확인하는 것이다). 
Oracle Database 9.0.1 버전까지는 패치 적용시 셸 스크립트를 이용 하여 패치를 적용하도록 되어 있었다. 그러나 9.2 버전부터는‘Opatch’라 는 패치 관리 유틸리티가 등장하여, 이전에 없었던 새로운 패치 관리 기능 들을 제공하고 있다. 
이 글에서는 Oracle Database 9.2에서 패치 적용시 사용되는 Opatch 의 구성 및 설치 방법, 각 명령어의 사용방법에 대해 알아보도록 하겠다. 그 리고 기존에 발생했던 대표적인 Opatch 적용시의 문제들도 간략하게 소 개한다. 
Opatch 사용 환경 및 설치 방법
Opatch는 Oracle Database 9.2 이상의 오라클 데이타베이스와 Oracle Application Server 10g에 임시 패치를 적용하는 과정을 지원한다. 현재 지원되는 플랫폼은 Unix와 Windows 계열이며, 현재 IBM OS/390에 대 해서는 지원하지 않는다. 따라서, IBM OS/390에 대해서는 이전(Oracle Database 9.0.1 이전 방식)과 동일하게 임시 패치를 적용해야 한다. 
Opatch는 Oracle Database 9.2에 포함되어 있지 않으며, 설치하려면 Oracle Metalink에서 다운로드해야 한다. 다운로드 절차는 다음과 같다. 
1.Oracle Metalink(http://metalink.oracle.com)에 로그인한다. 
2.PATCHES 버튼을 선택한다. 
3.Simple Search 링크를 선택한다. 
4.Patch(s) Numbers 폼에‘2617419’를 입력한다. 
5.Platform or Language 리스트에서 해당 플랫폼을 선택한다. 
6.Go 버튼을 선택한다. 
7.다음 항목을 선택한다. 
2617419 Universal Installer: Patch OPATCH ARU PLACEHOLDER. (10.1.0.2) 
8.다운로드가 진행된다. 
9.다운 받은 파일을 압축 해제한다. 
$ unzip p2617419_10102_GENERIC.zip 
10.User Path에 등록한다. 
For Korn / Bourne shell : % export PATH=$PATH:/oracle/opatch/Opatch For C Shell : % setenv PATH $PATH:/oracle/opatch/Opatch 
Opatch를 실행을 위한 요구사항. 
● Perl : 최소 Perl 5.0.0.5_03 이상이 시스템에 설치되어야 하며, 5.6 버전 이상 이 권장된다. Perl은 오라클 설치시‘Typical’옵션으로 설치하거나, ‘Custom’설치시 Apache Web Server를 선택하면 $ORACLE_HOME/ Apache/perl에 설치된다. 
● Inventory : 오라클 제품은 두 개의 인벤토리를 유지하는데, 하나는 oraInst.loc 파 일 에 서 지 시 하 는 센 트 럴 인 벤 토 리 이 며 , 보 통 $ORACLE_BASE/oraInventory의 이름으로 존재한다. 이 인벤토리는 설치 된 오라클 제품의 정보를 보관한다. 또 하나의 인벤토리는 로컬 인벤토리로, $ORACLE_HOME/inventory에 위 치 한 다 . 이 인 벤 토 리 에 는 특 정 ORACLE_HOME에 설치된 컴포넌트 정보를 저장한다. 이 두 개의 인벤토리 가 정상적으로 유지되어야 한다(참고로, oralnst.loc의 위치는 AIX, Linux는 /etc 디렉토리에 위치하며, 다른 Unix에서는 /var/opt/oracle에 위치한다. Windows는 레 지 스 트 리 에 서 HKEY_LOCAL_MACHINE/Software/ Oracle/Oracle/inst_loc 항목에 지정된 위치에 있다). 
● Opatch : Oracle9i Database에는 Opatch 유틸리티가 번들되어 있지 않으므 로, 앞에서언급한것처럼Oracle Metalink에서다운받아야하며, 해당패치넘 버로 최신Opatch 버전이 업데이트되므로, 항상 최신 버전을 유지하도록 한다. 
● Path : RAC(Real Application Cluster)에서 임시 패치 적용시, $ORACLE_ HOME/lib와$ORACLE_HOME/srvm/lib이 라이브러리 패치에 포함되어야 한다(예를 들어, Solaris의 경우 LD_LIBRARY_PATH, HP-UX의 경우 SHLIB_PATH). 
Opatch를 설치한 후 디렉토리 구조를 보면 다음과 같이 구성되어 있다. 



OPatch 디렉토리에는 Opatch 실행시 최초로 실행되는 셸 스크립트인 Opatch와 이 스크립트에서 호출되는 opatch.pl이 있다. 하위 디렉토리가 세 개 생성되고, perl_module 디렉토리에는 Opatch의 각각의 기능을 담당 하는 Perl 모듈이 위치한다. 이 스크립트들은 opatch.pl에 의해 호출되며, 실 제로 패치를 관리하는 기능은 jlib 디렉토리 및 OUI(Oracle Universal Installer) 내의 Java 클래스를 호출하여 구현된다. Docs 디렉토리는 Opatch를 사용할 때 참조할 문서들이 있으므로 꼭 읽어보아야 한다. 적용할 임시 패치 파일의 압축을 풀면, 다음과 같은 디렉토리 구조를 갖는다. 


패치 파일을 다운 받아 압축을 풀면, 해당 패치 번호의 이름으로 디렉 토리가 생성되며, 이 밑에 etc와 files 두 개의 디렉토리가 생성된다. Files 디렉토리 밑에는 lib 디렉토리가 있고, 이 디렉토리에 실제로 적용할 객체 파일들이 있다. 
etc 디렉토리 밑에는 config와 xml 디렉토리가 생성된다. Config 디렉토리 밑에 있는 Actions 파일은 패치가 적용되어야 하는 대상 아카이브 파일과 디렉토리, 메이크 파일 등이 기록되어 있다. Inventory 파일에는 패치 적용 후 오라클 인벤토리에 업데이트해야 하는 내용과 대상 플랫폼, 오라클 버전이 기록되어 있다. 
Xml 디렉토리에는 GenericAction.xml 파일이 있다. 이 파일에는 각 운영체제별로 사용할 명령어가 정의되어 있다. ShipHomeDirectoryStructure. xml 파일에는 패치 디렉토리의 구조가 정의되어 있다. 
Opatch의 사용 방법
Opatch의 기능을 정리하면 다음과 같다. 
● 임시 패치의 적용 
● 적용한 임시 패치의 제거
● 설치한 컴포넌트와 패치(임시 패치 및 패치셋)에대한정보조회 
● 임시 패치에 대한 정보 조회 
그러면 이런 기능들을 어떻게 사용하는지 하나씩 알아보자. 
Usage : opatch [ -h[elp] ] [ -r[eport] ] [ command ] [ command argument ]
Global argument
-h[elp] : 특정 명령어에 대한 설명
예) opatch -h lsinventory
-r[report] : 실제 패치 적용 없이 처리과정을 화면 출력
패치 적용
패치 적용은 Apply 명령어를 사용한다. 기본적인 명령은 다음과 같다. 
$ opatch apply [ -delay ] [ -force ]
[ -invPtrLoc ]
[ -jdk ] [ -jre ] [ -local ]
[ -minimize_downtime ] [ -no_bug_superset ]
[ -no_inventory ] [ -oh ]
[ -retry ] [ -silent ] [ -verbose ]
각각의명령어아규먼트(command argument)를설명하면, 다음과같다. 
● force : 이전에 설치한 임시 패치와 충돌 발생시 이를 무시하고 설치하도록 한 다. 이 경우 기존의 객체 파일을 새로운 객체 파일로 대체하게 되므로 주의하여 야한다. 
● invPtrLoc : oraInst.loc 파일의 위치를 수동으로 지정할 때 사용한다. 오라클 제품 설치시 별도의 옵션을 주지 않으면 oraInst.loc 파일은 각 플랫폼의 디폴 트 위치에 생성된다. 이 위치를 사용자가 변경하기 위해‘runInstaller - invPtrLoc <경로 및 파일명>’처럼 사용할 수 있다. Opatch에 oraInst.loc 파 일의 위치를 알려주기 위해 이 아규먼트를 사용해야 한다. 
● jdk : 디폴트로 사용되는$ORACLE_HOME/jdk 이외의 jdk를 이용하여 패치 할 때 이 아규먼트를 사용한다. 
● jre : 디폴트로 사용되는 $ORACLE_HOME/jre 이외의 jre를 이용하여 패치 할 때 이 아규먼트를 사용한다. 
● local : RAC에서 사용할 수 있으며, 패치 적용을 다른 노드에 전파하지 않고 로컬 노드에만 적용한 후 인벤토리도 로컬 노드에서만 업데이트한다. 이 경우 다른 노드에서도 개별적으로 로컬 아규먼트를 이용하여 즉시 패치가 적용되어 야한다. 일부 노드만 패치를 적용해 운영하는 것은 허용되지 않는다. 
● minimize_downtime : 임시 패치 적용중 RAC의 다운타임을 최소화하기 위해 사용할 수 있다. 
● no_bug_superset : 설치하려는 패치가 이미 설치한 패치의 슈퍼셋인 경우 에러를 발생시킨다. 
● no_inventory : 패치 적용 과정 중에서 인벤토리를 읽거나 업데이트하는 과 정을 생략한다. 이 명령어 아규먼트는 인벤토리 변조 등으로 인해 정상적으로 인벤토리를 읽거나 업데이트할 수 없을 때만 사용해야 하며, 일단 사용 후에는 미지원 상태가 되므로 사용에 주의해야 한다. 그리고 위에서 설명한 로컬 명령 어 아규먼트는와는 같이 사용할 수 없다 
● oh : 정의된$ORACLE_HOME 대신에사용할ORACLE_HOME을지정한다. 
● silent : 사용자 인터랙션을 모두 디폴트 값으로 적용하여 패치를 진행한다. 
● verbose : 기본적으로 나타나는 정보보다 더 자세한 내용을 화면과 로그 파일 에 출력한다. 
● Patch_location : 설치하려는 임시 패치의 모든 경로를 표시한다. 
그러면, 패치 적용의 사용 예를 간단히 알아보자. 
$ opatch apply 
단순히 이 명령으로 패치를 적용할 수 있다. 
$ opatch apply -invPtrLoc $ORACLE_HOME/oraInst.loc -silent 
이 명령으로 oraInst.loc 파일의 위치를 알려주고, 모든 사용자 인터랙 션은 디폴트 값으로 설정한 후 패치를 적용할 수 있다. 
패치 제거
패치 제거를 위해서는 Rollback 명령어를 사용한다. 
$ opatch rollback -id [ -invPtrLoc ] 
[ -jdk ] -jre -local
[ -oh [ -ph ]
-silent -verbose
Rollback 명령어 아규먼트 중 Apply 명령어 아규먼트와 중복되지 않 는 아규먼트는 다음과 같다. 
● id : 제거하려는 임시 패치 번호이다. 
● ph : 패치 스테이지의 위치, 즉 패치를 제거할 때도 패치 파일이 필요하다. 
간단한 패치 제거 사용 예는 다음과 같다. 
$ opatch -id 380927 -ph /opt/oracle/920/380927 
위의 명령으로 패치 번호 380927을 롤백하게 된다. 
패치 정보 조회
패치 정보 조회를 위한 명령은 다음과 같다. 
$ opatch query [ -all ] [ -get_base_bug ] [ -get_component ]
[ -get_date ] [ -get_os ] [ -get_system_change ] 
[ -is_rolling ] [ -is_shutdown ]
패치의 조회는 Query 명령어를 사용하며, 다운 받은 임시 패치 자체 의 정보를 확인할 때 사용한다. 
Query 명령어의 아규먼트는 다음과 같다. 
● all : 모든 아규먼트로 조회되는 정보를 알려준다. 
● get_base_bug : 해당 패치에 의해 수정된 베이스 버그를 알려준다. 
● get_component : 패치 적용시 요구되는 컴포넌트를 알려준다. 
● get_date : 패치가 생성된 일자를 알려준다. 
● get_os : 패치 파일이 지원하는 운영체제를 알려준다. 
● get_system_change : 해당 패치를 적용한 후 시스템에 변경되는 사항을 알 려주는 아규먼트이지만, 현재는 지원되지 않는다. 
● is_rolling : 해당 패치가 롤링 패치가 가능한지 알려준다. 
● is_shutdown : 해당 패치 적용시 인스턴스를 다운해야 하는지 여부를 알려주 지만, 현재는 지원되지 않는다. 
설치된 패치 리스트 조회
ORACLE_HOME에 설치된 오라클 제품 컴포넌트를 조회하거나, 적용된 임 시 패치를 조회할 때는 lsinventory 명령어를 사용한다. 
$ opatch lsinventory [ -all ] [ -detail ]
[ -invPtrLoc ] 
[ -jre ] [ -oh ]
이 명령어의 아규먼트는 다음과 같다. 
● all : ORACLE_BASE 밑에 설치된 모든ORACLE_HOME 정보를 표시한다. 
● detail : 설치된 패치 내에 포함된 라이브러리 파일까지 표시해 주므로 패치 적 용시 충돌되는 객체 파일을 확인할 수 있다. 
Opatch 버전 조회
Opatch의 버전을 조회하는 실제 예는 다음과 같다. 여기서 현재 사용한 Opatch는 1.0.0.0.50 버전임을 알 수 있다. 
[rmtdcaix4]/apac/rdbms/3748283> ../OPatch/opatch version 
PERL5LIB=/apac/rdbms/64bit/app/oracle/product/9.2.0.4/Apache/perl/lib/5.00503:../ 
OPatch/perl_modules; export PERL5LIB 
/apac/rdbms/64bit/app/oracle/product/9.2.0.4/Apache/perl/bin/perl 
../OPatch/opatch.pl version 
../OPatch/opatch.pl version: 1.0.0.0.50 
RAC에서의 Opatch 사용
기본적으로 임시 패치 적용시는 인스턴스를 다운한 후 적용해야 하므로, 패 치 적용시는 서비스를 할 수 없게 된다. RAC에서는 몇 가지 아규먼트를 사용 하여 다운타임을 최소화할 수 있다. 
대략적으로RAC에서 패치가 적용되는 방법을 적어보면 다음과 같다. 
If (사용자가 패치 적용방법을minimize_downtime으로 설정) 
patching mechanism = Minimize Downtime 
else if (패치가 롤링 패치를 지원) 
patching mechanism = Rolling 
else 
patching mechanism = All-Node 
여기서, 주의할 점은 CFS 등의 공유 파일 시스템에 오라클 제품을 설치 하여 여러 노드에서 공유하는 경우에는 minimize_downtime과 롤링 패치 가 적용되지 않는다는 것이다. 
그러면 각각의 방법에 대해 알아보자. 
All-Node
이것은 일반적인 데이타베이스에 패치를 적용하는 것처럼, 모든 인스턴스를 다운한 후, 한 노드씩 순차적으로 진행한다. ORACLE_HOME을 여러 노드 에서 공유하는 경우는 이 방식으로 패치를 적용해야 한다. 
Minimize_downtime
Minimize_downtime은 RAC 운영시 다운타임을 최소화하기 위해 사용된 다. 2노드RAC의 경우를 예로 패치 절차를 알아보자. 
1.먼저 로컬 노드의 인스턴스를 셧다운한다. 
‘opatch apply -minimize_downtime’명령으로 패치를 시작한다. 
2. ‘Is this node ready for updating?’질문에‘Yes’로 답하면, 로컬 노드에 패치가 적용된다. 
3.패치 적용 후 다음에 적용할 노드명을 물어본다. 
4.해당 노드명을 입력하면, 이 노드의 인스턴스를 셧다운하도록 요청한다. 
5.요청받은 노드의 인스턴스는‘Shutdown immediate’로 셧다운한 후, 셧 다운이 완료되면 이미 패치가 적용된 노드의 인스턴스가 셧다운한다. 
6.두 번째 노드에 패치를 적용한다. 
7.인벤토리 정보가 업데이트된다. 
8.패치가 완료되면 두 번째 인스턴스도 셧다운한다. 
Minimize_downtime 아규먼트를 사용해도 모든 인스턴스가 다운되는 단계는 있지만, 5번 단계에서만 해당되므로, 다운타임을 최소화할 수 있다. 
Rolling Patch
롤링 패치가 Minimize_downtime과 틀린 점은 다운타임이 전혀 없다는 것이다. 적용 절차는 다음과 같다. 
1.먼저 인스턴스1을 셧다운한다. 이 단계에서 인스턴스2는 서비스 중이다. 
2.노드1에서‘opatch apply’명령으로 패치를 적용한다. 
3.노드1에 패치가 적용되었으면, 인스턴스1을 시동하라는 메시지를 받는다. 
그리고 다음에 적용할 노드를 입력하도록 메시지를 받는다. 
4.인스턴스2를 셧다운한다. 
5.3번 세션에서 계속 이어서 노드2에 패치를 적용한다. 
6.패치 적용후 인스턴스2를 시동한다. 
롤링 패치는 모든 패치가 다 가능한 것은 아니고, 롤링 패치를 지원하도 록 설계된 패치만 가능하다. 롤링 패치가 가능한지 여부는‘opatch query - is_rolling’명령으로 확인할 수 있다. 
Windows 플랫폼에서 Opatch 사용
Windows에서 Opatch를 사용할 때도 기본적인 명령어는 동일하다. 
Opatch 명령을 실행하면 Windows 레지스트리에 ORACLE_HOME 이 등록되어 있어도, ORACLE_HOME이 지정되지 않았다는 메시지가 나 온다. Opatch 명령어를 사용할 때 -oh 아규먼트를 사용하여 ORACLE_HOME을 지정하거나, DOS 프롬프트에서 다음 명령으로 ORACLE_HOME을 지정한다. 
C:\> Set ORACLE_HOME = 
트러블슈팅
>임시 패치가 적용되었는지 어떻게 확인할 수 있는가?
일반적으로 패치가 적용되었는지를 보려면‘opatch lsinventory’를 사용하 여 확인한다. 
Oracle Database 9.2 이 상 에 서 임 시 패 치 를 적 용 하 면 , 
$ORACLE_HOME/.patch_storage 디렉토리 밑에 해당 패치 번호를 이름 으로 디렉토리가 생성되고, 이 디렉토리 밑에 패치 적용 로그와 패치 적용 이전의 라이브러리 파일, 롤백시 적용할 스크립트가 있다. 여기서 로그 파 일을 보는 것도 패치가 적용되었는지 확인하는 방법이 될 수 있다. 이 로그 파일은 패치 적용을 실행하는 횟수만큼 생성된다. 
또 한 가지 방법은 아카이브 파일을 Ar 명령으로 조회해 보는 것이다. 
예를 들어, kko.o 파일을 libserver9.a에 적용하는 경우, ‘ar tv libserver 9.a|grep kko.o’명령으로 kko.o의 타임스탬프를 조회할 수 있다. 
Windows에서 Opatch 실패
Windows 플랫폼에서Opatch를실행하면다음메시지가나오는경우가있다. 
C:\oracle\ora92\OPatch>opatch lsinventory 
“You have to invoke the patch tool manually.” 
“The syntax is:” 
“ perl /opatch.pl ” 
“If everything is installed correctly you should be able to run” 
“ perl /opatch.pl” 
“ and see the basic help message.” 
C:\oracle\ora92\OPatch>perl opatch.pl lsinventory 
<< 중략 >> Required Jar File under Oracle Universal Installer = jlib\OraInstaller.jar 
‘“”C:\Program’은(는) 내부 또는 외부 명령, 실행할 수 있는 프로그램, 또는 
배치 파일이 아닙니다. 
Get inventory loc. from C:Program Files... 
<< 생략 >> 
Opatch 사용시 권장되는 Perl 버전은 5.6 이상이지만, 이상하게도 Windows에서 Perl 5.6 이상을 사용하여 Opatch를 실행하면 위와 같은 에러 메시지가 발생한다. 이 경우 $ORACLE_HOME/Apache /perl을 사 용하도록 한다. 
컴포넌트/버전의 불일치
This Oracle Home does not have components/versions required by the patch. 
ERROR: OPatch failed during pre-reqs check. 
위와 같은 메시지는 적용하려는 임시 패치가 요구하는 컴포넌트가 설치되 지 않았거나, 지원하는 버전이 틀린 경우이다. 
패치 파일의 요구사항은‘opatch-query’명령으로 조회해 볼 수 있다. 
혹은 patch stage/etc/config/inventory 파일을 열고, 항목을 확인해도 된다. 
유효한 패치 영역이 아닌 경우
Not a valid patch area 
이 경우는 현재의 작업 디렉토리가 패치 디렉토리가 아니거나 패치 디렉토 리명이 패치 ID와 같지 않아서 발생하는 문제이다. 
패치 디렉토리가 현재 디렉토리가 아닌 경우는 경로를 명시해 주어야 한다. 예를 들어서, 현재 디렉토리는‘/oracle’이고, 패치는‘/oracle/3809254’에 있는 경우, ‘opatch apply /oracle/3809254’라고 명령을 내려야 한다. 
패치 디렉토리가 패치 ID와 이름이 다른 경우는 먼저 패치 ID를 확인 한다. 이 정보는‘opatch query -all’로 확인하거나‘patch stage/etc /config/inventory’파일에서 reference_id 항목에서 확인할 수 있다. 이 후 디렉토리명을 패치 번호와 동일하게 맞춰 준다. 
java.lang.UnsatisfiedLinkError
Exception in thread “main”java.lang.UnsatisfiedLinkError: 
no oraInstaller in java.library.path 
이 경우 원인은 대부분 liboraInstaller.so가 라이브러리 경로에 포함 되지 않았기 때문이다. 
이 파일은 $ORACLE_HOME/oui/bin/ 디렉토리에 있 다. 이 경로를 라이브러리 경로에 추가하고, 다시 패치를 적용한다. 
java.lang.NullPointerException
Exception in thread “main”java.lang.NullPointerException at XXX.main... 
오라클 제품의 최초 설치시 RunInstaller를 -invPtrLoc 옵션을 사용해서 실행한 경우일 수 있다. 이 경우 Opatch를 사용할 때도 동일한 -invPtrLoc 를 사용하여 oraInst.loc의 위치를 명시해 주어야 한다. 
Oracle Support에 문의해야 하는 경우
모든 문제가 그렇지만, Opatch 실행시 발생하는 문제도 거의 유형별로 다 르기 때문에, 위와 같이 일반화 하는 것이 힘들다. 따라서 일단 문제가 발생 하면, 다음과 같이 기본적인 점검을 하고, 다음 사항을 검토한다. 
● Opatch가 최신 버전인지 확인 
● Opatch를 실행하기 위한 환경이 셋업되었는지 확인 
PERL, JDK, 환경변수(PATH, LIBRARY PATH, …) 
● Fresh Install인지 확인 
● HP에서 fuser 문제인 경우 NOTE. 234741.1를확인 
더 이상 확인이 안될 경우는 Oracle Metalink(http://www. metalink. com)에서TAR를연후Oracle Support 엔지니어와 같이 문제를 해결해야 한다. 이 경우 다음 정보들을 미리 준비하여 Oracle Support에 전달하면 문제 해결에 도움이 될 수 있다. 
● 운영체제 디버깅 아웃풋 
예 : truss -aefdD -o test.out opatch apply 
● oraInst.loc 파일 
● $ORACLE_HOME/inventory/ContentsXML/comps.xml 
● $ORACLE_HOME/.patch_storage 디렉토리를 압축 
● oraInst.loc에 기록된 인벤토리 디렉토리 밑의 ContentsXML/inventory 파일 
● 운영체제 환경변수‘OPATCH_DEBUG=TRUE’를 세팅한 후 Opatch 적용시의 아웃풋 
● 문제가 발생하고 있는 임시 패치 번호 
오라클 관리자의 필수 유틸리티
Oracle Database 9.2부터 지원되는 Opatch는 임시 패치 관리에 있어서 많은 편리한 기능을 제공한다. 애플리케이션 서버도 Oracle Application Server 10g부터는 Opatch로 임시 패치를 관리하게 되므로, 오라클 관리 자에게 Opatch는 필수 유틸리티라고 할 수 있다. 
마지막으로 당부하고 싶은 것은 임시 패치 적용 전 반드시 센트럴 인 벤토리와 로컬 인벤토리를 백업하여 예기치 못한 인벤토리 충돌시 복구가 가능하도록 하기 바란다. 
제공 : DB포탈사이트 DBguide.net 
출처명 : 한국오라클

[출처] 오라클 OPatch 사용법|작성자 sulgata

1. root.sh

/usr/local/bin의 경로에 'dbhome', 'oraenv', 'coraenv' 파일을 생성한다.
이 파일에는 오라클 제품에 대한 권한 설정과 root 유저에 관련된 설정 작업을 한다.
product 정보 및 엔진의 HOME 디렉토리를 저장하기 위함이다.





2. orainstRoot.sh

orainstRoot.sh 파일을 실행하게 되면 /etc/orainst.loc 파일이 생성된다.
이 파일은 orainventory의 위치와 이를 다루는 유닉스 계정 그룹명이 기록된다.

inventory_loc=/oracle/oraInventory
inst_group=dba (or oinstall)



# oraInventory 란? #

oraInventory는 Oracle Software 제품에 관한 정보와 Server에 설치되어있는 ORACLE_HOME의 정보를 가지고 있는
일종의 Repository(Directory)이다.
Inventory는 Oracle Software 제품에 관한 정보와 Server에 설치되어있는 ORACLE_HOME에 대한 내용이 XML 형태로 존재하는
파일로써 XML Inventory라고 말한다.
예전에는 XML Inventory가 아닌 Binary 형태로 존재하는 Binary Iventory를 사용 했다.

이러한 Inventory는 Global Inventory(Central Inventory)와 Local Inventory(Oracle Home Inventory) 2가지가 존재 한다.

Global Inventory
Global Inventory는 Server에 설치 되어 있는 모든 Oracle 제품의 관한 정보를 유지 한다.
Server에 설치 되어 있는 모든 Oracle 제품이란
Oracle database, Oracle Application Server, Collaboration Suite, SOA suite, Forms/Reports Server, Discoverer Server 와 같은 Oracle 제품군을 이야기 한다.
Global Inventory의 위치는 /etc (on Linux) 또는 /var/opt/oracle (solaris)에 존재 하는 oraInst.loc파일이 명시 되어 있는 곳에 존재한다.
Server에 설치 되어 있는 Oracle 제품군을 알고 싶으면 oraInst.loc에 명시 되어 있는
oraInventory/ContentsXML/inventory.xml 파일을 열어 보면 확인 할 수 있다.

Local Inventory
Oracle_Home에 존재하는 local Inventory는 Oracle_Home이 포함하는 Oracle 제품군에 관한 정보를 담고 있다.

Multiple Global Inventory
한대의 Server에서서 2개 이상의 Global Inventory를 가지는 것이 Multiple Global Inventory이라고 불린다. Multiple Global Inventory를 사용 하는 이유는 한대의 Server의 동일한 Oracle 제품을 2개 이상 설치 하려 할때 유용하다.그러나 Oracle 제품을 Upgrade를 하거나 Patch 작업을 진행 하기 전에 항상 oralnst.loc파일을 확인 해야 한다.

(출처 : http://cafe.naver.com/ocmkorea.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=4984&)

Oracle 제품을 설치 하면서 가장 많이 듣는 말 중에 하나가 oraInventory이라는 것이다. 이것이 아무 것도 모를때는 아!~ 그냥 설치 하면 되는 구나 하는데 나중에 oraInventory가 꼬이기 시작 하면 대책이 없는 경우가 많이 발 생한다.

그래서 이번에는 oraInventory에 관하여 이야기 하려 한다.

oraInventory 란?

oraInventory은 Oracle Software 제품의 관한 정보와 Server에 설치 되어 있는 Oracle_Home의 정보를 가지고 있는 일종의 Repository(Directory)이다.

Inventory는 Oracle Software 제품의 관한 정보와 Server에 설치 되어 있는 Oracle_Home에 대한 내용을 XML형태로 존재 한는 파일을 이야기 하면 이런 파일을 XML Inventory라고 말한다. 예전에는 XML Inventory가 아닌 binary 형태로 존재 하는 Binary형태로 존재하는 Binary Inventory를 사용 했다.

이러한 Inventory는 Global Inventory(Central Inventory)와 Local Inventory(Oracle Home Inventory) 2가지가 존재 한다.

Global Inventory

Global Inventory는 Server에 설치 되어 있는 모든 Oracle 제품의 관한 정보를 유지 한다. Server에 설치 되어 있는 모든 Oracle 제품이란 Oracle database, Oracle Application Server, Collaboration Suite, SOA suite, Forms/Reports Server, Discoverer Server와 같은 Oracle 제품군을 이야기 한다.

Global Inventory의 위치는 /etc (on Linux) 또는 /var/opt/oracle (solaris)에 존재 하는 oraInst.loc파일이 명시 되어 있는 곳에 존재한다.

만약 당신이 Server에 설치 되어 있는 Oracle 제품군을 알고 싶으면 oraInst.loc에 명시 되어 있는 oraInventory밑에 ContentsXML 밑에 inventory.xml 파일을 열어 보면 확인 할 수 있다.

Local Inventory

Oracle_Home에 존재하는 local Inventory는 Oracle_Home이 포함하는 Oracle 제품군에 관한 정보를 담고 있다.

Multiple Global Inventory

한대의 Server에서서 2개 이상의 Global Inventory를 가지는 것이 Multiple Global Inventory이라고 불린다. Multiple Global Inventory를 사용 하는 이유는 한대의 Server의 동일한 Oracle 제품을 2개 이상 설치 하려 할때 유용하다.

그러나 Oracle 제품을 Upgrade를 하거나 Patch 작업을 진행 하기 전에 항상 oralnst.loc파일을 확인 해야 한다.

자료출처 

http://egloos.zum.com/genes1s/v/3056068#:~:text=orainstRoot.sh%20%ED%8C%8C%EC%9D%BC%EC%9D%84%20%EC%8B%A4%ED%96%89,%EA%B3%84%EC%A0%95%20%EA%B7%B8%EB%A3%B9%EB%AA%85%EC%9D%B4%20%EA%B8%B0%EB%A1%9D%EB%90%9C%EB%8B%A4.&text=%EC%9D%BC%EC%A2%85%EC%9D%98%20Repository(Directory)%EC%9D%B4%EB%8B%A4.&text=%ED%8C%8C%EC%9D%BC%EB%A1%9C%EC%8D%A8%20XML%20Inventory%EB%9D%BC%EA%B3%A0%20%EB%A7%90%ED%95%9C%EB%8B%A4. 

패치 확인 명령어를 포스팅 합니다.

UNIX서버상에서 패치확인 명령어는 lsinventory 입니다. 

apply와 동일합니다.

./opatch lsinventory -invPtrLoc /oraInst.loc의 절대경로/

를 실행시켜주시면 

아래와 같이 패치버전이 나오게 됩니다.

이전 포스팅에 tuxedo 서버를 설치하였고 이번 포스팅으로는 패치를 진행해보도록 하겠습니다.

oracle에서 패치를 위한 실행파일은 OPatch 디렉토리에 있습니다.

실행을 위해서 ./patch 로 실행파일을 실행시켜주면 되지만 

설치를 위한 설치파일이 존재해야합니다.

설치파일은 mos에서 받으면 됩니다.

아래 그림과 같이 진행해주세요.

버전과 서버설정은 별도로 정해주세요.

많은 설치파일이 나오게 됩니다.

어느 설치 파일을 받으셔도 동일한 방법으로 진행되기 때문에 상관없습니다.

옆 패치네임을 클릭하셔서 다운로드를 받아주세요.

저는 가장 최신패치버전으로 RP092 버전을 다운로드 받았습니다.

다운로드 받은 윈도우 zip파일을 드래그를 사용하여 리눅스 서버로 가져옵니다. 

드래그가 되지 않는 경우는 SFTP를 사용하시면 됩니다.

아래는 SFTP 방법 포스팅입니다.

https://nomajorkorean.tistory.com/3

아래와 같이 zip파일을 풀어주게 되면 패치파일이 생깁니다.

아래 보이시는 34290692.zip 이 파일을 opatch를 실행시켜 패치 적용을 시켜주어야합니다.

패치를 적용시키는 명령어는 apply 입니다.

패치파일의 절대경로가 설정되었다면 oraInst.loc 파일의 절대경로도 설정해주어야 합니다.

 -invPtrLoc는 oraInst.loc 파일의 위치를 나타내주는 파라미터 입니다.

oraInst.loc의 절대경로를 설정해줍니다.

덧붙여 설명드리자면 

invPtrLoc 는 oraInst.loc 파일의 위치를 수동으로 지정할 때 사용합니다. 오라클 제품 설치시 별도의 옵션을 주지 않으면 oraInst.loc 파일은 각 플랫폼의 디폴 트 위치에 생성됩니다. 이 위치를 사용자가 변경하기 위해‘runInstaller - invPtrLoc <경로 및 파일명>’처럼 사용할 수 있습니다. Opatch에 oraInst.loc 파 일의 위치를 알려주기 위해 이 argument를 사용해야 합니다.

./opatch apply /패치파일디렉토리절대경로/패치버전.zip -invPtrLoc /oraInventory절대경로/oraInst.loc

패치가 성공적으로 진행되었습니다.

이상으로 oracle tuxedo의 최신버전패치 포스팅을 마치겠습니다.

감사합니다.

조언 및 충고는 많은 도움이 됩니다.

이번 포스팅은 tuxedo 서버를 설치하는 테스트를 올립니다.

사용자를 추가해서 서버 설치 계정을 따로 만들었습니다.

디렉토리를 새로 생성하여 

/sw3/tp3/ 

디렉토리에 설치를 진행하였습니다.

zip파일을 unzip 합니다.

unzip을 하게 되면 설치파일 디렉토리 내에 Disk1 디렉토리가 생성됩니다.

console 모드로 설치를 하기 위해 스크립트파일을 실행합니다.

central inventory를 선택하게되면

기존에 지정된 oraInventory로 경로 지정이 자동으로 됩니다.

중요한 점은 아래와 같은 에러를 만날 수 있습니다.

이미 존재하는 oraInventory로 경로지정이 됐지만 접근 권한이 없기 때문에 설치가 진행이 되지 않습니다.

설치사용자는 oraInventory의 소유자그룹과 동일해야한다는 점이 필수라고 하네요.

이부분은 oraInventory의 소유자를 변경시켜도 되지만, 설치시 마다 변경해줄 수 없으니 private inventory를 선택해서 다시 설치를 진행해보겠습니다.

다시 인벤토리 선택창으로 돌아왔습니다.

포인터 파일을 설정해야하기 때문에, 제가 지정한 경로를 private inventory pointer file에 절대경로로 입력시켜줍니다.

하지만 저는 그러지 않았기 때문에 당연하게도 아래와 같이 에러가 납니다.

invalid inventory pointer file

이 에러가 난다면 oraInventory 경로 지정이 잘못되었거나 아예 경로지정이 안되었을 경우 입니다.

이제  oraInventory를 생성합니다.

저는 /sw3/tp3/oraInventory 경로로 디렉토리를 생성하였습니다.

그리고 oraInventory 디렉토리 아래에 oraInst.loc 파일을 생성해줍니다.

이 파일에는  orainventory의 위치와 이를 다루는 계정(사용자) 그룹명이 기록됩니다.

아래와 같이 oraInventory 의 절대경로와 사용자명을 기록하고 

:wq 명령어로 저장하고 나옵니다.

또한 사용자가 읽고 실행하는 권한이 필요하기 때문에 

chmod 를 사용하여 권한설정을 해줍니다.

chmod 750 oraInst.loc

oraInventory 설정이 끝났다면

다시 콘솔모드로 설치를 진행합니다.

원활하게 진행됩니다.

다음 설치단계는 ORACLE_HOME 설정입니다.

보통 ORACLE_HOME은 설치디렉토리로 설정하게 됩니다.

다음 단계는 install set 단계 입니다.

tuxedo 서버 설치를 진행하도록 하겠습니다.

다음 단계는 옵션입니다.

sample과 MP모드를 대비하기 위해 tlisten을 설치하여줍니다.

tuxedo server 설치가 성공적으로 진행된 모습입니다.

설치가 완료된 후 

tuxedo 엔진 아래 samples/atmi/simpapp 디렉토리로 들어가게 되면 

클라이언트 실행모듈과 서버 실행모듈, ubbconfig 가 잘 설치된 것을 볼 수 있습니다.

다음 포스팅으로는 패치를 진행해보겠습니다.

감사합니다.