ORACLE/INSTALL2008. 4. 8. 01:06
반응형

Oracle 10.1.0.4 Update

 
지난번 포스팅시 마지막에 예고했었던 오라클 패치업데이트(10.1.0.2 에서 10.1.0.4) 에 관한 내용. 전제로 OS는 리눅스 환경이다.

예비서버의 오라클 패치를 끝내고 본서버와 교체후 이번에는 본서버의 패치를 실행했다. 2번째라 그런지 별 문제없이 끝났다. 다만 Enterprise Manager에서 트러블이 있었는데 이건 다음에 포스팅하겠음.


>> 10.1.0.2(혹은 10.1.0.3)에서 10.1.0.4로의 패치수순

0. HP유닉스, AIX의 경우는 방법이 일부 다르므로 오라클 홈페이지의 메뉴얼이나 KROWN문서를 참조해서 알아서 수정할것.

1. OiSC에서 패치파일(용량 571MB)를 다운로드해서 서버에 복사.

2. 패치를 실행하기전에 먼저 구패키지에 포함되어 있는 Oracle Database 10g Companion CD에서 Oracle Database 10g Products 인스톨 타입을 선택해서 인스톨을 해야한다. 이안에는 Java퍼포먼스를 향상시키는 Natively Compiled Java Libraries (NCOMP)가 들어있는데 이걸 인스톨하지 않으면 나중에 패치를 실행할때 "ORA-29558: JAccelerator(NCOMP) not installed" 라는 에러가 발생하며 더이상 패치 진행이 불가능하다.


3. RAC환경에서 운영시에는 CRS를 먼저 패치를 실행한 후 본 패치를 실행해야한다. CRS의 패치순서는 다음과 같다.
(1) 기존의 Oracle Database 10g 서비스를 전부 다음의 순서로 정지시킨다.
- srvctl을 사용해서 전노드의 모든 RAC인스턴스, 데이터베이스를 정지시킨다.
srvctl stop instance -d <db_unique_name> -i <inst_name_list> [-o <stop_options>]
srvctl stop database -d <db_unique_name> [-o <stop_options>] [-c <connect_str>]
srvctl stop instance -d SERAC -i SERAC1 -o immedate
srvctl stop instance -d SERAC -i SERAC2 -o immedate
srvctl stop database -d SERAC -o immediate

- srvctl을 사용해서 전노드의 모든 ASM인스턴스를 정지시킨다.
srvctl stop asm -n <node_name> [-i <inst_name>] [-o <stop_options>]
srvctl stop asm -n togos-db1 -i +ASM1 -o immedate
srvctl stop asm -n togos-db2 -i +ASM1 -o immedate

- srvctl을 사용해서 전노드의 노드어플리케이션을 정지시킨다.
srvctl stop nodeapps -n <node_name>
srvctl stop nodeapps -n togos-db1
srvctl stop nodeapps -n togos-db2

- 다음 커맨드를 실행해서 모든 노드의 CRS프로세스를 정지시킨다.
# /etc/init.d/init.crs stop (솔라리스, 리눅스)
# /sbin/init.d/init.crs stop (HP유닉스)
# /etc/init.crs stop (AIX)

(3) 그밖에 혹시 ORA_CRS_HOME를 사용하는 어플리케이션, 프로세스가 존재한다면 모두 정지시킨다.

(4) 패치파일을 압축해제한 디렉토리에서 runInstaller를 실행한다.

(5) 파일의 장소를 지정하는 화면까지 이동한다. 소스지정은 products.xml, 인스톨 장소는 기존 인스톨장소인 ORA_CRS_HOME를 선택한후 계속 진행한다. (데폴트는 이름은 OraCr10ghome1, 패스는 /u01/app/oracle/product/10.1.0/crs)

(6) 이후는 쭉 진행하다가 마지막에 커맨드모드에서 다음의 쉘파일을 모든 노드에서 루트권한으로 실행한다. (메세지에 나온다)
$ORA_CRS_HOME/install/root10104.sh

(7) 여기까지로 CRS패치는 모두 종료되었다. 이후 계속해서 데이터베이스의 패치를 진행하기 위해서 다음의 명령들을 실행해서 (1) 에서 소개한 커맨드들을 다시 실행해서 패치중 재기동된 오라클 서비스들을 정지시킨다. 작업이 끝나면 crs_stat -t 커맨드를 실행해서 전 노드의 리소스가 OFFLINE상태가 되었는지를 재확인한다.


4. EM가 기동중이라면 먼저 정지시킨다. (emctl stop dbconsole)

5. 패치파일의 runInstaller를 기동해서 파일의 장소를 지정하는 화면까지 이동한다. 소스지정은 products.xml, 인스톨 장소는 기존 인스톨장소인 ORACLE_HOME를 선택한후 계속 진행한다. (데폴트는 이름은 OraDb10ghome1, 패스는 /u01/app/oracle/product/10.1.0/db)

6. 쭉 순서에 따라 진행한 후 인스톨화면을 종료한다.


여기까지로 기본 패치 프로그램의 인스톨작업은 끝났다. 하지만 아직 전체작업이 끝난것은 아니다. 다음 작업들을 실행하지 않으면 데이타베이스가 에러("ORA-13516: SWRF Operation failed: CATPROC not valid")를 내며 기동되지 않으므로 계속 패치 수순을 진행한다.


>> 패치 인스톨 후의 작업

1. RAC환경의 경우 클러스터의 모든 노드에 대해서 노드어플리케이션을 기동시킨다.
srvctl start nodeapps -n <nodename>
srvctl start nodeapps -n togos-db1
srvctl start nodeapps -n togos-db2

2. ASM사용시에는 ASM인스턴스를 기동시킨다.
srvctl start asm -n <nodename>

srvctl start asm -n togos-db1
srvctl start asm -n togos-db2

3. sysdba권한으로 sqlplus에 로그인한다.
sqlplus / as sysdba

4. 데이터베이스를 기동한다.
SQL> STARTUP NOMOUNT

5. SHARED_POOL_SIZE, JAVA_POOL_SIZE 파라메터의 값을 다음과 같이 수정한다. 패치작업을 종료한후 원래대로 다시 수정해도 상관없다.
SQL> ALTER SYSTEM SET SHARED_POOL_SIZE='180M' SCOPE=both; (에러발생시 both대신 spfile)
SQL> ALTER SYSTEM SET JAVA_POOL_SIZE='180M' SCOPE=both; (에러발생시 both대신 spfile)

6. RAC환경의 경우 CLUSTER_DATABASE 파라메터의 값을 FALSE로 수정한다. 패치작업이 모두 종료되면 다시 TRUE 로 값을 되돌려야 한다. 그렇지 않으면 RAC환경이 정상적으로 기동되지 않는다.
SQL> ALTER SYSTEM SET CLUSTER_DATABASE=FALSE SCOPE=spfile;

7. 수정한 파라메터를 반영시키고 새로운 업데이트를 실시하기위해 데이터베이스를 재기동한다.
SQL> SHUTDOWN
SQL> STARTUP UPGRADE

8. 다음의 커맨드를 실행한다.
SQL> SPOOL patch.log
SQL> @?/rdbms/admin/catpatch.sql
(머신파워에 따라 다르지만 내 경우 위커맨드는 실행후 종료까지 30분정도 걸렸다)
SQL> SPOOL OFF

9. 출력된 patch.log파을을 확인해서 에러가 발생하지 않았는지 확인한다. 에러가 발생했을 경우 문제점을 수정하고 다시 catpatch.sql 을 재실행해야한다.

10. 지금까지 문제가 없을경우 데이터베이스를 다시 재기동한다.
SQL> SHUTDOWN
SQL> STARTUP

11. 다음의 커맨드를 실행해서 INVALID스테이터스 상태가 된 PL/SQL패키지를 재컴파일한다.
SQL> @?/rdbms/admin/utlrp.sql
위커맨드 실행시 스탠다드 에디션의 경우는 OLAP관련의 INVALID오브젝트가 여전히 남게되나 이부분은 엔터프라이즈버전에서만 활성화되는 기능이므로 무시한다.

12. RAC환경의 경우 모든 노드에서 configPatch.pl 스크립트를 실행한다.
# perl $ORACLE_HOME/sysman/install/configPatch.pl
log4j: ERROR 가 발생하지만 무시한다.


이로써 10.1.0.4 의 패치작업은 모두 끝났다. 혹시나 발생할 문제점을 미연에 발견하기 위해 전노드의 재기동을 추천한다. 그리고 Enterprise Manager 기능에 관련해서 문제가 발생할 경우는 이를 수정하는것보다 EM을 삭제후 재설치하는 편이 훨씬 빠르다. EM의 재설치에 관련해서는 이전 포스팅 을 참조한다.


이상.

 

반응형
Posted by [PineTree]