About DATABASE

http://u.gzit.org/blog-27-3455.html

아래 로그가 설치 중에 root.sh  실행 중에 에러 나오면 아래 단계대로 조치하면 된다.

##########################################################################

출처 :https://hoing.io/archives/268

1. TEST Information

2. Scenario

1) 현재 testdb1 , testdb2 의 SID로 RAC(10.2.0.5) 에서 HOT Backup을 이용하여 clonedb를 생성

2) 복제 되는 instance의 SID는 copydb 로 할 것이며, single 로 복구를 시도 할 것이다.

3) RAC는 /oradata/testdb ,  single 은 /oradata3/copydb 로 복구 할 것이다.

3. HOT BACKUP

■ 테스트를 간편하게 하기 위해 alter database begin backup; 으로 백업 진행한다.

SQL> alter database begin backup;

■ Redo와 Temp Tablespace 파일을 제외한 모든 datafile 을 복사 한다.

$ cp system01.dbf /oradata3/copydb/

$ cp sysaux01.dbf /oradata3/copydb/

$ cp undotbs01.dbf /oradata3/copydb/

$ cp undotbs02.dbf /oradata3/copydb/

$ cp users01.dbf /oradata3/copydb/

■ 복사 후 end backup  을 실행한다.

SQL> alter database end backup;

END Backup 을 실행한 시간을 확인한다.

SQL> select to_char(sysdate,'YYYY-MM-DD:HH24:MI:SS') "Time" from dual;

Time

-------------------

2011-12-04:12:10:09

4. TEST Table Creation

■ 복사 후 복구 테스트를 위해서 테이블과 데이터를 입력한다.

■ 테이블 생성

SQL> create table test01 (no number) tablespace users;

■ 데이터 입력

BEGIN

for i in 1..1000 loop

insert into test01 values(i);

end loop;

commit;

END;

/

■ log switch  및 checkpoint 발생

SQL> alter system switch logfile;   -- 수회 실행

■ test table삭제

SQL> drop table test01 purge;

■ 삭제 시간 확인

SQL> select to_char(sysdate,'YYYY-MM-DD:HH24:MI:SS') "Time" from dual;

Time

-------------------

2011-12-04:12:26:00

5. Ready to clonedb

■ spfile 로 pfile을 생성

SQL> create pfile='$ORACLE_HOME/dbs/initCOPYDB.ora' from spfile;

■ controlfile 재생성을 위해 trace 파일 생성

SQL> alter database backup controlfile to trace as '/oradata3/copydb/recon.sql';

■ pfile 수정

아래 파라미터를 clonedb 환경에 맞게 수정 한다, 물론 디렉토리도 생성을 해야 한다.

*.audit_file_dest=

*.background_dump_dest=

*.control_files='

*.user_dump_dest='

*.db_name='testdb'

RAC 파라미터 변경, 아래와 같이 변경

*.instance_number=1

*.cluster_database=false

*.thread=1

*.undo_tablespace='UNDOTBS1'

■ pfile 수정

create controlfile 절을 수정한다.

CREATE CONTROLFILE SET DATABASE "COPYDB" RESETLOGS  NOARCHIVELOG

   REUSE => SET

  NORESETLOGS => RESETLOGS

그 외 경로를 clonedb에 맞게 수정한다.

복구 하고 open 후 temp tablespace를 생성 함으로 temp tablespace 생성 절을 별도로 백업 해둔다

ALTER TABLESPACE TEMP ADD TEMPFILE '/oradata3/copydb/temp01.dbf'

SIZE 524288000  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;

아래와 같이 CHARACTER SET KO16MSWIN949;   까지 유지해서 파일을 작성한다.

STARTUP NOMOUNT

CREATE CONTROLFILE SET DATABASE "COPYDB" RESETLOGS  NOARCHIVELOG

    MAXLOGFILES 192

    MAXLOGMEMBERS 3

    MAXDATAFILES 1024

    MAXINSTANCES 32

    MAXLOGHISTORY 292

LOGFILE

  GROUP 1 (

    '/oradata3/copydb/redo01a.log',

    '/oradata3/copydb/redo01b.log'

  ) SIZE 300M,

  GROUP 2 (

    '/oradata3/copydb/redo02a.log',

    '/oradata3/copydb/redo02b.log'

  ) SIZE 300M,

  GROUP 3 (

    '/oradata3/copydb/redo03a.log',

    '/oradata3/copydb/redo03b.log'

  ) SIZE 300M,

  GROUP 4 (

    '/oradata3/copydb/redo04a.log',

    '/oradata3/copydb/redo04b.log'

  ) SIZE 300M

-- STANDBY LOGFILE

DATAFILE

  '/oradata3/copydb/system01.dbf',

  '/oradata3/copydb/undotbs01.dbf',

  '/oradata3/copydb/sysaux01.dbf',

  '/oradata3/copydb/undotbs02.dbf',

  '/oradata3/copydb/users01.dbf'

CHARACTER SET KO16MSWIN949;

6. Creation clonedb

■ sid를 변경하고 컨트롤 파일을 재생성 한다.

$ export ORACLE_SID=COPYDB

SQL*Plus: Release 10.2.0.5.0 - Production on Sun Dec 4 12:48:19 2011

Copyright (c) 1982, 2010, Oracle.  All Rights Reserved.

Connected to an idle instance

SQL> @recon.sql

■ 시간 기반으로 복구 한다.

복구를 진행할 세션에서 복구하기 편한 방식으로 시간 설정을 한다.

SQL> alter session set nls_date_format='YYYY-MM-DD:HH24:MI:SS';

삭제한 시간이 2011-12-04:12:26:00 이기 때문에 24 분으로 복구 하겠다.

SQL> recover database until time '2011-12-04:12:24:00' using backup controlfile;

복구를 실시하면 아래와 같이 아카이브 파일을 필요로 한다.

ORA-00279: change 565796 generated at 12/04/2011 12:01:54 needed for thread 2

ORA-00289: suggestion : /oracle/product/102/db/dbs/arch2_14_768267462.dbf

ORA-00280: change 565796 for thread 2 is in sequence #14

위에서 알 수 있는 것은 thread 2(RAC에서 2번째 노드) 의 시퀀스 14번 을 가진 아카이브를 원하는

것이다 .

테스트 환경에서는 파일명이 arc_2_14_768267462.arc  이며, 경로 및 파일을 입력한다.

파일명 입력

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/oradata/arch_testdb/arc_2_14_768267462.arc

이번에는 thread 1의 change 565796 을 포함 한 아카이브 파일을 입력 해야 한다.

ORA-00279: change 565796 generated at  needed for thread 1

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

RAC 로 접속해서 쿼리를 수행하여 THREAD1의 565796 변경본이 포함된 아카이브 파일을 찾는다.

SQL> set lines 500

SQL> col name for a50

SQL> SELECT THREAD# ,SEQUENCE# , FIRST_CHANGE#, NEXT_CHANGE#, NAME,

TO_CHAR(FIRST_TIME,'YYYY-MM-DD:HH24:MI:SS') FIRST_TIME  FROM V$ARCHIVED_LOG;

THREAD#  SEQUENCE  # FIRST_CHANGE   # NEXT_CHANGE#      NAME                                   FIRST_TIME

----------  ---------- ------------- ------------ -------------------------------------------------------------------------------

  2          14       553454              567190      /oradata/arch_testdb/arc_2_14_768267462.arc    2011-12-04:05:52:04

  2          15       567190              567247      /oradata/arch_testdb/arc_2_15_768267462.arc    2011-12-04:12:20:05

  2          16        567247             567249      /oradata/arch_testdb/arc_2_16_768267462.arc    2011-12-04:12:20:09

  1          11       553456              567252    /oradata/arch_testdb/arc_1_11_768267462.arc   2011-12-04:05:52:05

  2          17       567249              567254      /oradata/arch_testdb/arc_2_17_768267462.arc    2011-12-04:12:20:12

  2          18       567254              567274      /oradata/arch_testdb/arc_2_18_768267462.arc    2011-12-04:12:20:15

  2          19       567274              567279      /oradata/arch_testdb/arc_2_19_768267462.arc    2011-12-04:12:21:12

  1          12       567252              567293      /oradata/arch_testdb/arc_1_12_768267462.arc    2011-12-04:12:20:14

확인 해 보면 arc_1_11_768267462.arc 파일인 것을 알 수 있다. 아래와 같이 경로와 파일명을 입력한다.

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/oradata/arch_testdb/arc_1_11_768267462.arc

ORA-00279: change 567190 generated at 12/04/2011 12:20:05 needed for thread 2

ORA-00289: suggestion : /oracle/product/102/db/dbs/arch2_15_768267462.dbf

ORA-00280: change 567190 for thread 2 is in sequence #15

ORA-00278: log file '/oradata/arch_testdb/arc_2_14_768267462.arc' no longer

needed for this recovery

change 567190 for thread 2 is in sequence #15 메세지를 보면 THREAD2의 15 시퀀스 아카이브 파일을

필요로 한다는 것을 알 수 있다. 경로 및 파일명을 입력한다.

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}

/oradata/arch_testdb/arc_2_15_768267462.arc

위와 같은 패턴으로 요청하는 아카이브 파일을 계속 적용해준다.

운영중인 RAC에 생성 된 아카이브 보다 더 높은 시퀀스를 요구 한다면 로그 스위치를 발생하여

생성한 아카이브를 적용 시켜준다.

계속 적용 시키면 아래와 같이 recovery가 되었다는 메세지를 볼 수 있다.

Log applied.

Media recovery complete.

resetlogs로 instance를 open한다

SQL> alter database open resetlogs;

Temp Tablespace 를 추가한다.

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE '/oradata3/copydb/temp01.dbf'

SIZE 524288000  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;

■ 예외 처리

아래와 같이 ORA-38856 가 나오게 되면 Unpulbished Bug-4355382 로써

오라클 문서ID: 334899.1 를 참조한다.

ERROR at line 1:

ORA-38856: cannot mark instance UNNAMED_INSTANCE_2 (redo thread 2) as enabled

pfile에 _no_recovery_through_resetlogs=TRUE  를 추가한 후 다시 resetlogs로 open한다.

open 후 test01 테이블이 복구 되었는지 조회해 본다.

select count(*) from test01;

  COUNT(*)

----------

      1000

적용 대상:

Oracle Database - Enterprise Edition - 버전 10.2.0.1 to 11.2.0.3 [릴리즈 10.2 to 11.2]
이 문서의 내용은 모든 플랫폼에 적용됩니다.

목적

Many RAC instability issues are attributed to a rather short list of commonly missed Best Practices and/or Configuration issues.  The goal of this document it to provide a easy to find listing of these commonly missed Best Practices and/or Configuration issues with the hope to prevent instability caused by these issues.

범위

이 문서의 내용은 RAC이 구현된 모든 환경에 적용된다.

상세 내역

1. 최신 Patchset Update (PSU) 를 적용하라

적용 가능한 플랫폼:  모든 플랫폼

이유?: PSU는 CPU 패치 계획을 좀더 향상시키기 위해 10.2.0.4 이상 버전에서 도입되었다. PSU는 분기마다 출시되며 최근의 CPU를 포함하고 있고 거기에 추가적으로, 운영 환경의 안정화에 중요하다고 여겨지는 개별패치(fix)들을 포함하고 있다. 만약 신규 설치건이라면, 반드시 해당 버전의 가장 최신 PSU를 적용해야 한다. 기존 시스템의 경우, 지속적이고 정기적으로 최신의 PSU를 적용하는 방식으로 운영 환경을 유지보수 하도록 계획해야 한다. 오라클 Support에 문의되고 버그로 판명되는 이슈들중에는 최신의 PSU에서 이미 해결된 알려진 버그인 경우가 많다. 그리고, 윈도우즈 환경에서는 누적 번들 패치가 PSU보다는 좀더 자주 출시가 되는데, 이 경우의 최신의 PSU는, PSU 출시 분기 동안에 나왔던 윈도우즈 번들 패치에 포함된다. .

추가 정보: PSU에 관한 더 많은 정보는 아래 문서들을 참조하라:
Document 854428.1 Intro to Patch Set Updates (PSU)
Document 1082394.1 11.2.0.X Grid Infrastructure PSU Known Issues
Document 756671.1 Oracle Recommended Patches -- Oracle Database
Document 161549.1 Oracle Database, Networking and Grid Agent Patches for Microsoft Platforms

2.  UDP 버퍼 크기가 적당한 지 확인하라

적용 가능한 플랫폼: Windows를 제외한 모든 플랫폼

이유?: 인터커넥트(interconnect)는 RAC 데이터베이스에서 생명선과 같다. 그러나 UDP send/receive 버퍼에 할당된 버퍼 공간이 적당치 않다면 인터커넥트 성능에 상당히 영향을 끼치며, 이것은 곧 클러스터 안정성에 문제가 될 수 있다. 

추가 정보: 적절한 UDP 버퍼 크기 산정을 위한 더 많은 정보는 아래 문서들을 참조하라:
Document 181489.1 Tuning Inter-Instance Performance in RAC and OPS
Document 563566.1 gc lost blocks diagnostics

3.  모든 10.2 와 11.1 클러스터에는 DIAGWAIT 값을 13으로 설정하라

적용 가능한 플랫폼:  Windows를 제외한 모든 플랫폼

이유?:  10gR2 (10.2.x)와 11gR1 (11.1.x)에서 OPROCD 데몬을 위한 기본 마진값은 겨우 500 밀리세컨드 (0.5초)이다. 이 마진은 매우 바쁜 시스템의 경우 너무 작은 값이며 그로 인해 과부하시 가짜 리부팅 (false reboot)이 발생할 수 있다. diagwait 설정을 13으로 변경하는 것은 OPROCD의 마진을 10,000 밀리세컨드 (10초)로 변경해주며 이는 곧 바쁜 시스템에 대해 가짜 리부팅 상황을 피하게끔 충분한 마진을 부여하는 것이다. 게다가, diagwait 설정은, 만약 reboot이 발생하는 경우에 추가 디버깅해볼 수 있는 정보를 trace 화일에 쓰는 시간을 좀더 부여하게끔 해준다. 이 변경은 patchset에는 포함될 수 없다. 그 이유는 클러스터 전체의 중단이 필요하기 때문입니다. 모든 10gR2 와 11gR1 클러스터에서는 이 값을 13으로 설정할 것을 강력히 권고하는 바이다. 새로 설치하는 경우라면 인스톨 직후에 이 diagwait 값을 변경해야 한다. 기존에 설치된 시스템의 경우는 다운타임을 계획해서 필히 적용해야 한다. 현재 설정은 아래 명령어로 확인할 수 있다:

추가 정보: DIAGWAIT에 관한 더 많은 정보는 아래 문서들을 참조하라:
Document 559365.1  Using Diagwait as a diagnostic to get more information for diagnosing Oracle Clusterware Node evictions
Document 567730.1  Changes in Oracle Clusterware on Linux with the 10.2.0.4 Patchset

4.  리눅스 환경에서는 HugePages를 구현하라

적용 가능한 플랫폼:  모든 LINUX 64-Bit 플래폼

이유?:  HugePages를 구현하면 리눅스 환경에서 커널의 성능이 크게 향상된다. 이는, 더 많은 메모리를 가지고 있는 시스템의 경우 특히 그렇다. 일반적으로 12GB RAM 이상을 가진 시스템의 경우, HugePages를 적용하기에 적합한 대상이다. 더 많은 RAM을 가진 시스템일수록 HugePages 활성화를 통해서 얻는 이득이 많다. 왜냐하면 시스템이 가진 메모리가 많을 수록 커널이 그만한 양의 메모리에 대해 page table을 맵핑하고 유지해야 하는 작업량이 증가하기 때문이다. HugePages를 활성화하는 것은 커널이 관리해야 할 page수를 줄여주기 때문에 시스템이 훨씬 효율적으로 동작할 수 있게 해준다. 만약 HugePages가 활성화돼 있지 않다면, 경험적으로 봤을 때 커널이 오라클 클러스터웨어나 Real Application Clusters 데몬보다 선점하면서 인스턴스 또는 노드 eviction을 일으키는 사례가 종종 나타난다.

추가 정보: 
Document 361323.1  HugePages on Linux: What It Is... and What It Is Not...
Document 401749.1  Shell Script to Calculate Values Recommended Linux HugePages / HugeTLB Configuration

5.  OS Watcher 및 Cluster Health Monitor를 구현하라

적용 가능한 플랫폼s:  모든 플랫폼

이유?: 안정성 측면과 직접 관련은 없지만, OS Watcher와 Cluster Health Monitor는 OS 상태 및 노드 및 인스턴스 eviction을 유발하는 잠재적 근본 원인을 규명하는 데 있어 매우 유용한 툴이다. 어떤 문제가 처음 발생한 이후 그 문제를 진단할 수 있는 적절한 데이터가 있다면 그 자료를 확보하는 것은 문제 원인을 규명하는 시간을 단축하게끔 해주며, 그렇게 함으로써 향후 장애를 예방할 수 있을 것이다. 이런 종류의 대부분의 3rd party 데이터 수집툴은 수집 주기가 너무 길며 (예를 들어, 5분 또는 그 이상), 그 툴들의 자료를 해석하기가 어렵거나 적절한 데이터를 수집하지 않는 경우도 있다. OS Watcher는 30초 (기본값) 간격으로 기본적인 OS 정보를 수집하는 매우 간단하고 가벼운 툴이다. Cluster Health Monitor는, 모든 플랫폼에 쓸 수 있는 것은 아니지만, 좀더 세부 수준까지 실시간으로 데이터를 수집함으로써 OS Watcher를 보완한다. 어떤 이슈에 대해 보다 빠른 진단과 디버깅을 수월하게 하는데 있어, 이 유틸리티들을 하나 또는 둘다 항상 모든 클러스터 노드에서 수행해 두는 것은 매우 중요한다.

추가 정보:
Document 301137.1 OS Watcher User Guide
Document 1328466.1 Cluster Health Monitor (CHM) FAQ
Document 580513.1 How To Start OSWatcher Black Box Every System Boot (Linux specific)

6.  OS설정에 대해서는 Best Practice를 따르라

(시스템 안정화를 위한 메모리 튜닝에 관한 백서로서, 오라클과 IBM이 공동 작업함)

적용 가능한 플랫폼:  모든 AIX 버전

이유?: 백서 Oracle Real Application Clusters on IBM AIX Best practices in memory tuning and configuring for system stability는 양 벤더의 상호 경험치에 기반한 최적 사례를 함께 테스트하고 엮은 매우 좋은 문서이다. 경험적으로 RAC/AIX 클러스터에서 안정성 문제의 대부분은 이 문서에서 권고한대로 설정하여 해결할 수 있었다. AIX 버전 6.1은 이런 많은 권고안들을 기본값으로 포함하고 있으나, 이 설정들은 OS버전 또는 오라클 버전에 상관없이 모든 RAC 클러스터 상에서 확인돼야 한다.

추가 정보:
백서 다운로드: http://www.oracle.com/technetwork/database/clusterware/overview/rac-aix-system-stability-131022.pdf
Document 811293.1  RAC Assurance Support Team: RAC Starter Kit and Best Practices (AIX)

7.  AIX 플랫폼에서 과도한 페이징/스와핑 이슈를 방지하기 위해, 적절한 APAR가 제대로 설정돼 있는 지 확인하라

적용 가능한 플랫폼: 모든 AIX 버전

이유?: 경험적으로 이 사안은 AIX환경에 영향을 미치는 매우 흔한 이슈이다. 이 이슈의 본질상, 이 문제에 민감한 사람이라면 완전히 시스템 hang이 되는 상황을 경험했을 것이다. RAC이 아닌 환경에서는 이것은 인위적 개입 없이는 계속 시스템 hang 상황에 빠져 있게 된다. 그러나 RAC 환경에서는 해당 노드의 응답 없음으로 인해 노드 eviction 상황으로 전개된다. 

추가 정보: 이 문제에 대한 추가 정보는, 오라클 문서 Document 1088076.1 Paging Space Growth May Occur Unexpectedly on AIX Systems With 64K (medium) Pages Enabled 를 확인하라

8.  NUMA 패치를 적용하라

적용 가능한 플랫폼:  모든 플랫폼

이유?:  10.2.0.4 과11.1.0.7 RDBMS 패치셋에는, NUMA (OS와 하드웨어 종속적)를 지원하는 플랫폼 상에서는 NUMA 최적화가 활성화돼 있었다. (NUMA를 지원하는 시스템 상의) RDBMS 코드내에 이 NUMA가 활성화 돼 있어서 데이터베이스의 성능 저하와 불안정을 야기하는 버그가 되어 왔었다. 10.2.0.4 과11.1.0.7에 NUMA 최적화와 관련있는 증상/이슈에 대한 전체 목록이 Document 759565.1에 나와 있다. 만약 10.2.0.4 또는 11.1.0.7 을 운영하고 있다면, NUMA관련 이슈를 적극적으로 해결하기 위해 Patch 8199533 를 적용할 것을 강력히 권고하는 바이다.

9.  윈도우즈의 비상호적 데스크탑 힙 메모리 (noninteractive Desktop Heap)를 늘려라

적용 가능한 플랫폼:  Windows 플랫폼 

이유?: 윈도우즈 클러스터에서 비상호적 데스크탑 힙 메모리의 기본 크기가 충분치 않음이 확인되었다. 이는 애플리케이션 연결성 이슈 및 클러스터의 일반적인 불안정(hang 및 crash)을 초래한다. 이 이슈에 대해 적극적으로 대처하기 위해, 비상호적 데스크탑 힙 메모리를 1MB까지 늘려줄 것을 권고한다. 권고치 1MB 보다 크게 늘려주는 것은, 마이크로소프트 측의 관여 없이는 수행하지 말아야 한다. 

추가 정보: 비상호적 데스크탑 힙 메모리를 어떻게 조정할 수 있는 지에 대한 설명은 Document 744125.1에서 볼 수 있다.

10.  RACcheck 유틸리티를 수행해라

적용 가능한 플랫폼:  Linux (x86 and x86_64), Solaris SPARC 그리고 AIX (bash shell 환경)

이유?: RACcheck은 Real Application Clusters (RAC), 오라클 클러스터웨어 (CRS), Automatic Storage Management (ASM), 그리고 Grid Infrastructure (GI) 에서 다양하고 중요한 설정 정보들을 살펴볼 수 있도록 개발된 RAC 설정 감사툴이다. 이 유틸리티는, RAC Assurance 개발/지원팀에서 유지 관리되고 있는 일련의 RAC/오라클 클러스터웨어 Best Practice와 Starter Kit 문서 (Document 810394.1 참조)에서 정의된 Best Practice 와 성공 요소들을 점검하는데 이용할 수 있다. RACcheck가 지원되는 플랫폼에서 RAC을 운영하고 있는 고객이라면 클러스터 안정성에 영향을 줄 수 있는 잠재적인 설정 이슈를 식별하기 위해서 이 툴을 활용할 것을 독려하는 바이다.

추가 정보: RACcheck에 대한 더 많은 정보 및 이 유틸리티를 내려받기 위한 링크는 Document 1268927.1에서 확인할 수 있다.

11. NTP를 slewing 옵션으로 설정하라.

적용 가능한 플랫폼:  모든 Linux 및 Unix 플랫폼.

이유?: slew 옵션이 없는 경우는 시간 불일치가 특정 임계치(플랫폼마다 다름)를 넘어설 때 NTP가 시스템 글럭을 앞으로 또는 뒤로 건너뛸 수 있다. 뒤로 시간을 많이 건너 뛰게 되면 클러스터웨어는 checkin이 없다고 보고 노드 eviction을 하게 될 수도 있다. 이러한 이유로, eviction 상황을 방지하기 위해 클럭이 시간을 동기시킬 수 있도록 NTP를 slew time (speed up 또는 speed down)으로 설정할 것을 강력히 권고하는 바이다. 각 플랫폼에서 NTP time slewing을 어떻게 구현하는 지, 아래 각 플랫폼별 RAC and Oracle Clusterware Best Practices and Starter Kit 문서를 참조하라 (아래).

Steps to Remove Node from Cluster When the Node Crashes Due to OS/Hardware Failure and cannot boot up (Doc ID 466975.1) To BottomTo Bottom

Modified:16-Nov-2012Type:HOWTO

Rate this document Email link to this document Open document in new window Printable Page

In this Document

Goal

Fix

  Summary

  Example Configuration

  Initial Stage

  Step 1 Remove oifcfg information for the failed node

  Step 2 Remove ONS information

  Step 3 Remove resources

  Step 4 Execute rootdeletenode.sh

  Step 5 Update the Inventory

References

APPLIES TO:

Oracle Server - Enterprise Edition - Version 10.2.0.1 to 11.1.0.6 [Release 10.2 to 11.1]

Oracle Server - Standard Edition - Version 10.2.0.1 to 11.1.0.6 [Release 10.2 to 11.1]

Information in this document applies to any platform.

Oracle Server Enterprise Edition - Version: 10.2.0.1 to 11.1.0.6

Oracle Clusterware

GOAL

This document is intented to provide the steps to be taken to remove a node from the Oracle cluster. The node itself is unavailable due to some OS issue or hardware issue which prevents the node from starting up. This document will provide the steps to remove such a node so that it can be added back after the node is fixed.

The steps to remove a node from a Cluster is already documented in the Oracle documentation at

Version Documentation Link

10gR2 http://download.oracle.com/docs/cd/B19306_01/rac.102/b14197/adddelunix.htm#BEIFDCAF

11gR1 http://download.oracle.com/docs/cd/B28359_01/rac.111/b28255/adddelclusterware.htm#BEIFDCAF

This note is different because the documentation covers the scenario where the node is accessible and the removal is a planned procedure. This note covers the scenario where the Node is unable to boot up and therefore it is not possible to run the clusterware commands from this node.

For 11gR2, refer to note 1262925.1

FIX

Summary

Basically all the steps documented in the Oracle Clusterware Administration and Deployment Guide must be followed. The difference here is that we skip the steps that are to be executed on the node which is not available and we run some extra commands on the other node which is going to remain in the cluster to remove the resources from the node that is to be removed.

Example Configuration

 All steps outlined in this document were executed on a cluster with the following configuration:

Item Value

Node Names lc2n1, lc2n2, lc2n3

Operating System Oracle Enterprise Linux 5 Update 4

Oracle Clusterware Release 10.2.0.5.0

ASM & Database Release 10.2.0.5.0

Clusterware Home /u01/app/oracle/product/10.2.0/crs ($CRS_HOME)

ASM Home /u01/app/oracle/product/10.2.0/asm

Database Home /u01/app/oracle/product/10.2.0/db_1

 Cluster Name lc2

 Assume that node lc2n3 is down due to a hardware failure and cannot even boot up. The plan is to remove it from the clusterware, fix the issue and then add it again to the Clusterware. In this document, we will cover the steps to remove the node from the clusterware

Please note that for better readability instead of 'crs_stat -t' the sample script 'crsstat' from 

  Doc ID 259301.1 CRS and 10g/11.1 Real Application Clusters 

was used to query the state of the CRS resources. This script is not part of a standard CRS installation.

Initial Stage

At this stage, the Oracle Clusterware is up and running on nodes lc2n1 & lc2n2 (good nodes) . Node lc2n3 is down and cannot be accessed. Note that the Virtual IP of lc2n3 is running on Node 1. The rest of the lc2n3 resources are OFFLINE:

[oracle@lc2n1 ~]$ crsstat

Name                                     Target     State      Host      

-------------------------------------------------------------------------------

ora.LC2DB1.LC2DB11.inst                  ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB12.inst                  ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB13.inst                  ONLINE     OFFLINE              

ora.LC2DB1.LC2DB1_SRV1.LC2DB11.srv       ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB1_SRV1.LC2DB12.srv       ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB1_SRV1.LC2DB13.srv       ONLINE     OFFLINE              

ora.LC2DB1.LC2DB1_SRV1.cs                ONLINE     ONLINE     lc2n1     

ora.LC2DB1.db                            ONLINE     ONLINE     lc2n2     

ora.lc2n1.ASM1.asm                       ONLINE     ONLINE     lc2n1     

ora.lc2n1.LISTENER_LC2N1.lsnr            ONLINE     ONLINE     lc2n1     

ora.lc2n1.gsd                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.ons                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.vip                            ONLINE     ONLINE     lc2n1     

ora.lc2n2.ASM2.asm                       ONLINE     ONLINE     lc2n2     

ora.lc2n2.LISTENER_LC2N2.lsnr            ONLINE     ONLINE     lc2n2     

ora.lc2n2.gsd                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.ons                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.vip                            ONLINE     ONLINE     lc2n2     

ora.lc2n3.ASM3.asm                       ONLINE     OFFLINE              

ora.lc2n3.LISTENER_LC2N3.lsnr            ONLINE     OFFLINE              

ora.lc2n3.gsd                            ONLINE     OFFLINE              

ora.lc2n3.ons                            ONLINE     OFFLINE              

ora.lc2n3.vip                            ONLINE     ONLINE     lc2n1     

[oracle@lc2n1 ~]$

Step 1 Remove oifcfg information for the failed node

Generally most installations use the global flag of the oifcfg command and therefore they can skip this step. They can confirm this using:

[oracle@lc2n1 bin]$ $CRS_HOME/bin/oifcfg getif

eth0  192.168.56.0  global  public

eth1  192.168.57.0  global  cluster_interconnect

If the output of the command returns global as shown above then you can skip the following step (executing the command below on a global defination will return an error as shown below.

If the output of the oifcfg getif command does not return global then use the following command

[oracle@lc2n1 bin]$ $CRS_HOME/bin/oifcfg delif -node lc2n3 

PROC-4: The cluster registry key to be operated on does not exist.

PRIF-11: cluster registry error

Step 2 Remove ONS information

Execute the following command to find out the remote port number to be used

[oracle@lc2n1 bin]$ cat $CRS_HOME/opmn/conf/ons.config

localport=6113 

remoteport=6200 

loglevel=3

useocr=on

and remove the information pertaining to the node to be deleted using:

[oracle@lc2n1 bin]$ $CRS_HOME/bin/racgons remove_config lc2n3:6200

Step 3 Remove resources

In this step, the resources that were defined on this node have to be removed. These resources include Database Instances, ASm, Listener and Nodeapps resources. A list of these can be acquired by running crsstat (crs_stat -t) command from any node

[oracle@lc2n1 ~]$ crsstat |grep OFFLINE

ora.LC2DB1.LC2DB13.inst                  ONLINE     OFFLINE              

ora.LC2DB1.LC2DB1_SRV1.LC2DB13.srv       ONLINE     OFFLINE              

ora.lc2n3.ASM3.asm                       ONLINE     OFFLINE              

ora.lc2n3.LISTENER_LC2N3.lsnr            ONLINE     OFFLINE              

ora.lc2n3.gsd                            ONLINE     OFFLINE              

ora.lc2n3.ons                            ONLINE     OFFLINE             

 Before removing any resource it is recommended to take a backup of the OCR:

[root@lc2n1 ~]# cd $CRS_HOME/cdata/lc2

[root@lc2n1 lc2]# $CRS_HOME/bin/ocrconfig -export ocr_before_node_removal.exp

[root@lc2n1 lc2]# ls -l ocr_before_node_removal.exp

-rw-r--r-- 1 root root 151946 Nov 15 15:24 ocr_before_node_removal.exp

 Use 'srvctl' from the database home to delete the database instance on node 3:

[oracle@lc2n1 ~]$ . oraenv

ORACLE_SID = [oracle] ? LC2DB1

[oracle@lc2n1 ~]$ $ORACLE_HOME/bin/srvctl remove instance -d LC2DB1 -i LC2DB13

Remove instance LC2DB13 from the database LC2DB1? (y/[n]) y

 Use 'srvctl' from the ASM home to delete the ASM instance on node 3:

[oracle@lc2n1 ~]$ . oraenv

ORACLE_SID = [oracle] ? +ASM1

[oracle@lc2n1 ~]$ $ORACLE_HOME/bin/srvctl remove asm -n lc2n3

Next remove the listener resource.

Please note that there is no 'srvctl remove listener' subcommand prior to 11.1 so this command will not work in 10.2. Using 'netca' to delete the listener from a down node also is not an option as netca needs to remove the listener configuration from the listener.ora.

10.2 only:

The only way to remove the listener resources is to use the command 'crs_unregister', please use this command only in this particular scenario:

[oracle@lc2n1 lc2]$ $CRS_HOME/bin/crs_unregister ora.lc2n3.LISTENER_LC2N3.lsnr

 11.1 only:

 Set the environment to the home from which the listener runs (ASM or database):

[oracle@lc2n1 ~]$ . oraenv

ORACLE_SID = [oracle] ? +ASM1

[oracle@lc2n1 lc2]$ $ORACLE_HOME/bin/srvctl remove listener -n lc2n3 

  As user root stop the nodeapps resources:

[root@lc2n1 oracle]# $CRS_HOME/bin/srvctl stop nodeapps -n lc2n3

[root@lc2n1 oracle]# crsstat |grep OFFLINE

ora.lc2n3.LISTENER_LC2N3.lsnr            OFFLINE    OFFLINE              

ora.lc2n3.gsd                            OFFLINE    OFFLINE              

ora.lc2n3.ons                            OFFLINE    OFFLINE              

ora.lc2n3.vip                            OFFLINE    OFFLINE        

 Now remove them:

[root@lc2n1 oracle]#  $CRS_HOME/bin/srvctl remove nodeapps -n lc2n3

Please confirm that you intend to remove the node-level applications on node lc2n3 (y/[n]) y

 At this point all resources from the bad node should be gone:

[oracle@lc2n1 ~]$ crsstat 

Name                                     Target     State      Host      

-------------------------------------------------------------------------------

ora.LC2DB1.LC2DB11.inst                  ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB12.inst                  ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB1_SRV1.LC2DB11.srv       ONLINE     ONLINE     lc2n1     

ora.LC2DB1.LC2DB1_SRV1.LC2DB12.srv       ONLINE     ONLINE     lc2n2     

ora.LC2DB1.LC2DB1_SRV1.cs                ONLINE     ONLINE     lc2n1     

ora.LC2DB1.db                            ONLINE     ONLINE     lc2n2     

ora.lc2n1.ASM1.asm                       ONLINE     ONLINE     lc2n1     

ora.lc2n1.LISTENER_LC2N1.lsnr            ONLINE     ONLINE     lc2n1     

ora.lc2n1.gsd                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.ons                            ONLINE     ONLINE     lc2n1     

ora.lc2n1.vip                            ONLINE     ONLINE     lc2n1     

ora.lc2n2.ASM2.asm                       ONLINE     ONLINE     lc2n2     

ora.lc2n2.LISTENER_LC2N2.lsnr            ONLINE     ONLINE     lc2n2     

ora.lc2n2.gsd                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.ons                            ONLINE     ONLINE     lc2n2     

ora.lc2n2.vip                            ONLINE     ONLINE     lc2n2  

Step 4 Execute rootdeletenode.sh

From the node that you are not deleting execute as root the following command which will help find out the node number of the node that you want to delete

[oracle@lc2n1 ~]$ $CRS_HOME//bin/olsnodes -n

lc2n1   1

lc2n2   2

lc2n3   3

this number can be passed to the rootdeletenode.sh command which is to be executed as root from any node which is going to remain in the cluster.

[root@lc2n1 ~]# cd $CRS_HOME/install

[root@lc2n1 install]# ./rootdeletenode.sh lc2n3,3

CRS-0210: Could not find resource 'ora.lc2n3.ons'.

CRS-0210: Could not find resource 'ora.lc2n3.vip'.

CRS-0210: Could not find resource 'ora.lc2n3.gsd'.

CRS-0210: Could not find resource ora.lc2n3.vip.

CRS nodeapps are deleted successfully

clscfg: EXISTING configuration version 3 detected.

clscfg: version 3 is 10G Release 2.

Successfully deleted 14 values from OCR.

Key SYSTEM.css.interfaces.nodelc2n3 marked for deletion is not there. Ignoring.

Successfully deleted 5 keys from OCR.

Node deletion operation successful.

'lc2n3,3' deleted successfully

[root@lc2n1 install]# $CRS_HOME/bin/olsnodes -n

lc2n1   1

lc2n2   2

Step 5 Update the Inventory

From the node which is going to remain in the cluster run the following command as owner of the CRS_HOME. The argument to be passed to the CLUSTER_NODES is a comma seperated list of node names of the cluster which are going to remain in the cluster. This step needs to be performed from once per home (Clusterware, ASM and RDBMS homes).

[oracle@lc2n1 install]$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/10.2.0/crs "CLUSTER_NODES={lc2n1,lc2n2}" CRS=TRUE  

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oracle/oraInventory

'UpdateNodeList' was successful.

[oracle@lc2n1 install]$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/10.2.0/asm "CLUSTER_NODES={lc2n1,lc2n2}"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oracle/oraInventory

'UpdateNodeList' was successful.

[oracle@lc2n1 install]$ $CRS_HOME/oui/bin/runInstaller -updateNodeList ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1 "CLUSTER_NODES={lc2n1,lc2n2}"

Starting Oracle Universal Installer...

No pre-requisite checks found in oraparam.ini, no system pre-requisite checks will be executed.

The inventory pointer is located at /etc/oraInst.loc

The inventory is located at /u01/app/oracle/oraInventory

'UpdateNodeList' was successful.

TAF (Transparent Application Failover)란 무엇인가?

RAC에서 사용하는 application failover의 개념으로 클라리언트 측의 feature이다.
두 노드가 있다고 가정하고, 한쪽 노드에 장애가 발생했을 경우,
나머지 살아있는 노드로 failover되는 기능이다.


TAF가 왜 필요한가?

TAF의 개념을 이해한다면 의심의 여지가 없다.
고가용성 시스템을 구축하기 위해 RAC를 사용한다면
장애 발생시에 failover를 안쓴다면 왜 RAC를 구축하겠는가?


TAF를 적용하기 위해서는 어떤 작업들이 필요한가?

1. 일단 클라이언트 측에 오라클 클라이언트 프로그램이 설치되어 있어야 한다.

2. 서버 쪽에 RAC가 구축되어 있어야 한다.

3. 오라클 클라이언트가 설치되어있는 곳의 $ORACLE_HOME/network/admin의 tnsnames.ora파일에
   아래와 같은 설정이 필요하다.

TAF가 지원하는 매개변수들에 대한 설명

TYPE: 
이것은 NONE, SESSION, 또는 SELECT 중 하나가 사용됩니다. 사용 해제을 위해서는 TYPE=SESSION 로 설정하고, 세션과 오픈 커서의 페일오버를 위해서는 TYPE=SELECT 로 설정하십시오. 그리고 TAF 를 해제하기 위해서는 TYPE=NONE 으로 설정하시면 됩니다.

METHOD: 
이것은 BASIC 또는 PRECONNECT 중 하나가 사용됩니다. BASIC 방식을 사용하면, 기존 접속이 실패할 때까지, TAF 는 접속의 재설정을 시도하지 않을 것입니다. PRECONNECT 방식을 사용하면, TAF 는 백업 접속을 위해 필요한 메모리 구조를 사전-설정하지만, 기존 접속이 실패할 때까지 백업 접속은 활성화되지 않을 것입니다.

BACKUP: 
이 하위-매개변수는 백업 접속의 설정을 위해 사용되는 네트 서비스 이름을 지정합니다. BACKUP 지정은 PRECONNECT 방식을 사용할 때 필요한데, BASIC 방식에서 강력하게 추천되고 있습니다; 그렇지 않다면, 클라이언트가 재접속을 할 때까지 추가적으로 지연을 시키면서 방금 실패한 인스턴스에 최초로 재접속을 시도할 것입니다. 그러나, 사용자는 LOAD_BALANCING=ON 인 상태에서는 BACKUP 을 지정할 수가 없습니다.

DELAY: 
TAF 가 장애 후에 BACKUP 에 연결하려는 시도 사이에서 기다리는 몇 초간의 지연 시간입니다.

RETRIES: 
포기하기 전, TAF 가 장애 후에 BACKUP 에 연결하기 위해 시도하는 횟수입니다. RETRIES 와 DELAY 는 TAF 가 백업 접속을 포기하기 전에 콜드 페일오버가 완료될 수 있는 시간을 갖게 해줍니다


4. 그리고 /etc/hosts 파일에 3.에서 정의한 hostname이 정의되어 있어야 한다.

os] cat /etc/hosts

실제로 TAF 테스트를 해보자

Window 머신 (또는 다른 플랫폼의 “non-RAC” 클라이언트 머신)에서 orcltest 서비스를 사용하여 SYSTEM 사용자로 클러스터 데이터베이스에 로그인합니다:

C:\> sqlplus system/manager@orcltest

COLUMN instance_name    FORMAT a13
COLUMN host_name        FORMAT a9
COLUMN failover_method  FORMAT a15
COLUMN failed_over      FORMAT a11

SELECT
    instance_name
  , host_name
  , NULL AS failover_type
  , NULL AS failover_method
  , NULL AS failed_over
FROM v$instance
UNION
SELECT
    NULL
  , NULL
  , failover_type
  , failover_method
  , failed_over
FROM v$session
WHERE username = 'SYSTEM';

INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- --------- ------------- --------------- -----------
orcl1         linux1
                        SELECT        BASIC           NO

위에서 설정한 SQL*Plus 세션에서 로그아웃 하지 않습니다!

위 쿼리를 수행한 다음, abort 옵션을 사용하여 linux1 노드의 orcl1 인스턴스를 셧다운 합니다. 이 작업을 수행하기 위해 아래와 같이 srvctl 커맨드라인 유틸리티를 사용합니다:

# su - oracle
$ srvctl status database -d orcl
Instance orcl1 is running on node linux1
Instance orcl2 is running on node linux2

$ srvctl stop instance -d orcl -i orcl1 -o abort

$ srvctl status database -d orcl
Instance orcl1 is not running on node linux1
Instance orcl2 is running on node linux2

다시 앞의 SQL 세션으로 돌아가, 버퍼에 저장된 SQL 구문을 재실행합니다: 
COLUMN instance_name    FORMAT a13
COLUMN host_name        FORMAT a9
COLUMN failover_method  FORMAT a15
COLUMN failed_over      FORMAT a11

SELECT
    instance_name
  , host_name
  , NULL AS failover_type
  , NULL AS failover_method
  , NULL AS failed_over
FROM v$instance
UNION
SELECT
    NULL
  , NULL
  , failover_type
  , failover_method
  , failed_over
FROM v$session
WHERE username = 'SYSTEM';

INSTANCE_NAME HOST_NAME FAILOVER_TYPE FAILOVER_METHOD FAILED_OVER
------------- --------- ------------- --------------- -----------
orcl2         linux2
                        SELECT        BASIC           YES

SQL> exit

위 실행 결과에서, 세션이 linux2 노드의 orcl2 인스턴스로 페일오버 되었음을 확인할 수 있습니다. 


참조 : http://www.oracle.com/technology/global/kr/pub/articles/hunter_rac10gr2_3.html
         http://www.oracle.com/technology/global/kr/deploy/availability/htdocs/taf.html
         http://publib.boulder.ibm.com/infocenter/pim/v6r0m0/index.jsp?topic=/com.ibm.wpc.ins.doc/wpc_tsk_setting_up_oracle_to_use_taf_support.html

root 유저로 실행

crs_stat -p ora.LISTENER_SCAN1.lsnr |grep -i start
crs_stat -p ora.scan1.vip  |grep -i start

[root@rac1 ~]# crsctl modify resource "ora.rac1.vip" -attr "AUTO_START=always"
[root@rac1 ~]#
[root@rac1 ~]# crsctl modify resource "ora.rac2.vip" -attr "AUTO_START=always"
[root@rac1 ~]# crsctl modify resource "ora.LISTENER_SCAN1.lsnr" -attr "AUTO_START=always"
[root@rac1 ~]# crsctl modify resource "ora.racdb.db" -attr "AUTO_START=always"
[root@rac1 ~]# crsctl modify resource "ora.scan1.vip" -attr "AUTO_START=always"
[root@rac1 ~]#
[root@rac1 ~]# crsctl modify resource "ora.net1.network" -attr "AUTO_START=always"
[root@rac1 ~]#
[root@rac1 ~]# crsctl modify resource "ora.LISTENER.lsnr" -attr "AUTO_START=always"
[root@rac1 ~]# crsctl modify resource "ora.oc4j" -attr "AUTO_START=always"
[root@rac1 ~]# crs_stat -p|grep restore

출처 : http://leejehong.tistory.com/170

[root@RAC1 ~]# srvctl config database -d devdb -v
Database unique name: devdb
Database name: devdb
Oracle home: /u01/app/11.2.0/db
Oracle user: oracle

10g CRS AUTO_START 값 변경.txt

11G Oracle RAC Startup Policy 변경.txt

11gR2 Disable Enable Automatic startup Oracle HAS.txt

Changing Resource Attributes in 11gR2 Grid Infrastructure.txt

crs_stat_resource상태확인(AUTO_START).txt

Spfile: /dev/raw/raw6
Domain: 
Start options: open
Stop options: immediate
Database role: PRIMARY
Management policy: AUTOMATIC
Server pools: devdb
Database instances: devdb1,devdb2
Disk Groups: 
Mount point paths: 
Services: 
Type: RAC
Database is administrator managed
[root@RAC1 ~]#

oracle@RAC1:/>crs_stat -t
Name           Type           Target    State     Host        
------------------------------------------------------------
ora....ER.lsnr ora....er.type ONLINE    ONLINE    rac1        
ora....N1.lsnr ora....er.type ONLINE    ONLINE    rac2        
ora.cvu        ora.cvu.type   ONLINE    ONLINE    rac1        
ora.devdb.db   ora....se.type OFFLINE   OFFLINE               
ora.gsd        ora.gsd.type   ONLINE    ONLINE    rac1        
ora....network ora....rk.type ONLINE    ONLINE    rac1        
ora.oc4j       ora.oc4j.type  ONLINE    ONLINE    rac1        
ora.ons        ora.ons.type   ONLINE    ONLINE    rac1        
ora....C1.lsnr application    ONLINE    ONLINE    rac1        
ora.rac1.gsd   application    ONLINE    ONLINE    rac1        
ora.rac1.ons   application    ONLINE    ONLINE    rac1        
ora.rac1.vip   ora....t1.type ONLINE    ONLINE    rac1        
ora....C2.lsnr application    ONLINE    ONLINE    rac2        
ora.rac2.gsd   application    ONLINE    ONLINE    rac2        
ora.rac2.ons   application    ONLINE    ONLINE    rac2        
ora.rac2.vip   ora....t1.type ONLINE    ONLINE    rac2        
ora....ry.acfs ora....fs.type OFFLINE   OFFLINE               
ora.scan1.vip  ora....ip.type ONLINE    ONLINE    rac2        
oracle@RAC1:/>
oracle@RAC1:/>

reboot시 Database가 자동으로 시작되지 않음.

oracle@RAC1:/>crs_stat -p ora.devdb.db |grep -i start
AUTO_START=restore
GEN_START_OPTIONS@SERVERNAME(rac1)=open
GEN_START_OPTIONS@SERVERNAME(rac2)=open
RESTART_ATTEMPTS=2
START_TIMEOUT=600
oracle@RAC1:/>

AUTO_START=restore 로 되어있어서 startup 되지 않음.

# 참고
* AUTO_START=1(always) -> 그 전의 상태와 상관없이 하드웨어 설정상태만 정상이면 crs 재구동시 리소스가 online 되어짐. * * AUTO_START=2(never) -> 모든 리소스를 수동으로 시작 
* AUTO_START=0(restore) -> 모든 리소스는 내리기 전 상태로 복귀.

[root@RAC1 profile]# crs_stat -p ora.devdb.db |grep -i start
AUTO_START=restore
GEN_START_OPTIONS@SERVERNAME(rac1)=open
GEN_START_OPTIONS@SERVERNAME(rac2)=open
RESTART_ATTEMPTS=2
START_TIMEOUT=600

[root@RAC1 profile]# 
[root@RAC1 profile]# crsctl modify resource "ora.devdb.db" -attr "AUTO_START=always"
[root@RAC1 profile]# crs_stat -p ora.devdb.db |grep -i start
AUTO_START=always
GEN_START_OPTIONS@SERVERNAME(rac1)=open
GEN_START_OPTIONS@SERVERNAME(rac2)=open
RESTART_ATTEMPTS=2
START_TIMEOUT=600
[root@RAC1 profile]#

Changing Resource Attributes in 11gR2 Grid Infrastructure 
In 11gR2 grid infrastructure installations certain resources may have auto start set to never and restore. 
This was observed both on environments where clusterware was upgraded to 11.2 as well as newly installed environments. 
Depending on the situation these may not be desirable. Auto start attribute setting could be changed as follows.

1. Check the current auto start values

# crsctl stat res -p
NAME=ora.FLASH.dg
TYPE=ora.diskgroup.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
ALIAS_NAME=
AUTO_START=never     

NAME=ora.DATA.dg
TYPE=ora.diskgroup.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
ALIAS_NAME=
AUTO_START=never    

NAME=ora.clusdb.db
TYPE=ora.database.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
ACTIVE_PLACEMENT=1
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
AUTO_START=restore

2. Since ASM diskgroup that database depend on will never auto start database will also be unavailable.

3. Change the resource start attribute with

# crsctl modify resource "ora.FLASH.dg" -attr "AUTO_START=always"
# crsctl modify resource "ora.DATA.dg" -attr "AUTO_START=always"
# crsctl modify resource ora.clusdb.db -attr "AUTO_START=always"
Auto start must be upper case if not command will fail 
crsctl modify resource ora.clusdb.db -attr "auto_start=always"
CRS-0160: The attribute 'auto_start' is not supported in this resource type.
CRS-4000: Command Modify failed, or completed with errors.

4. Verify the status change with 
# crsctl stat res -p
NAME=ora.clusdb.db
TYPE=ora.database.type
ACL=owner:oracle:rwx,pgrp:oinstall:rwx,other::r--
ACTION_FAILURE_TEMPLATE=
ACTION_SCRIPT=
ACTIVE_PLACEMENT=1
AGENT_FILENAME=%CRS_HOME%/bin/oraagent%CRS_EXE_SUFFIX%
AUTO_START=always

VIP Failover Take Long Time After Network Cable Pulled [ID 403743.1]
--------------------------------------------------------------------------------
 
  수정 날짜 05-JAN-2011     유형 PROBLEM     상태 PUBLISHED  

In this Document
  Symptoms
  Changes
  Cause
  Solution
  References

--------------------------------------------------------------------------------

Applies to:
Oracle Server - Enterprise Edition - Version: 10.2.0.1 to 11.1.0.7 - Release: 10.2 to 11.1
Information in this document applies to any platform.
***Checked for relevance on 05-Jan-2011***
Symptoms
This example is based on SUN Solaris platform, with IPMP configured for the public network. In this case, VIP failover takes almost 4 minutes to complete when both network cables of the public network are pulled from one node.

crsd.log shows:

2006-12-07 13:14:05.401: [ CRSAPP][4588] CheckResource error for ora.node1.vip error code = 1
2006-12-07 13:14:05.408: [ CRSRES][4588] In stateChanged, ora.node1.vip target is ONLINE
2006-12-07 13:14:05.409: [ CRSRES][4588] ora.node1.vip on node1 went OFFLINE unexpectedly
<<< detect network cable failure and VIP OFFLINE immediately

2006-12-07 13:14:05.410: [ CRSRES][4588] StopResource: setting CLI values
2006-12-07 13:14:05.420: [ CRSRES][4588] Attempting to stop `ora.node1.vip` on member `node1`
2006-12-07 13:14:06.651: [ CRSRES][4588] Stop of `ora.node1.vip` on member `node1` succeeded.
2006-12-07 13:14:06.652: [ CRSRES][4588] ora.node1.vip RESTART_COUNT=0 RESTART_ATTEMPTS=0
2006-12-07 13:14:06.667: [ CRSRES][4588] ora.node1.vip failed on node1 relocating.
2006-12-07 13:14:06.758: [ CRSRES][4588] StopResource: setting CLI values
2006-12-07 13:14:06.766: [ CRSRES][4588] Attempting to stop `ora.node1.LISTENER_NODE1.lsnr` on member `node1`
2006-12-07 13:17:41.399: [ CRSRES][4588] Stop of `ora.node1.LISTENER_NODE1.lsnr` on member `node1` succeeded.
<<< takes 3.5 minutes to stop listener

2006-12-07 13:17:41.402: Attempting to stop `ora.node1.ASM1.asm` on member `node1`
<<< stop dependant inst and ASM
2006-12-07 13:17:55.610: [ CRSRES][4588] Stop of `ora.node1.ASM1.asm` on member `node1` succeeded.

2006-12-07 13:17:55.661: [ CRSRES][4588] Attempting to start `ora.node1.vip` on member `node2`
2006-12-07 13:18:00.260: [ CRSRES][4588] Start of `ora.node1.vip` on member `node2` succeeded.
<<< now VIP failover complete after almost 4 mins

ora.node1.LISTENER_NODE1.lsnr.log shows:

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=node1vip)(PORT=1521)(IP=FIRST)))
TNS-12535: TNS:operation timed
2006-12-07 13:17:41.329: [ RACG][1] [23916][1][ora.node1.LISTENER_NODE1.lsnr]: out
   TNS-12560: TNS:protocol adapter error
     TNS-00505: Operation timed out
     Solaris Error: 145: Connection timed out
     Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=10.1.10.100)(PORT=1521)(IP=FIRST)))
The command completed successfully

Client connection hang during this failover time.

Changes
This may be a new setup, or a setup that was migrated from an earlier release.
Cause
This problem is caused by the first address in the listener.ora configuration being an address that uses the TCP protocol.

In this circumstance, when a network cable is pulled, "lsnrctl stop" listener has to wait for TCP timeout before it can check next address. On the Solaris platform, TCP timeout is defined by tcp_ip_abort_cinterval with a default value of 180000 (3 minutes).   That is why shutting down listener almost took 3.5 minutes. (TCP timeout on other platforms may vary).  The error message "Solaris Error: 145: Connection timed out" in ora.node1.LISTENER_NODE1.lsnr.log also indicates it is waiting for tcp timeout.

The listener.ora in this scenario is defined as:

[LISTENER_NODE1 =
 (DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = node1vip)(PORT = 1521)(IP = FIRST))
     )
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.100)(PORT = 1521)(IP = FIRST))
     )
     (ADDRESS_LIST =
       (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
     )
   )
 )Solution
To prevent this, move the IPC address to be the first address for the listener in the listener.ora, eg:

LISTENER_NODE1 =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
       (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC))
       )
       (ADDRESS_LIST =
          (ADDRESS = (PROTOCOL = TCP)(HOST = node1vip)(PORT = 1521)(IP = FIRST))
        )
       (ADDRESS_LIST =
           (ADDRESS = (PROTOCOL = TCP)(HOST = 10.1.10.100)(PORT = 1521)(IP = FIRST))
        )
     )
  )

When lsnrctl tries to stop the listener, it will now connect to the IPC address first, which is available during that time. It will not have to wait for tcp timeout.

After the above change, the VIP failover only takes 48 to 50 seconds to complete regardless of the tcp_ip_abort_cinterval setting.

Please note, listener.ora files newly created from 10.2.0.3 to 11.1.0.7 should have the IPC protocol as the first address in listener.ora in most cases.  However, if you have upgraded from a previous release, or manually modified/copied over a listener.ora from a previous install, you may not have the IPC protocol as the first address, regardless of your version. Manual modification is required to move IPC protocol to be the first address to avoid the problem described in this note.

References