RAC + ASM 환경에서 vip 변경 후 DB 재시작을 했는데

리스너 상태를 확인해보면 아래처럼 +ASM1 이 없어졌음을 확인할 수 있었다.

 

[grid@rac1 ~]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 04-MAR-2014 16:11:28

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                04-MAR-2014 16:04:44
Uptime                    0 days 0 hr. 6 min. 43 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /app/11.2/grid/network/admin/listener.ora
Listener Log File         /app/oracle/diag/tnslsnr/rac1/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=1.1.1.101)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=1.1.1.121)(PORT=1521)))
Services Summary...
Service "orcl" has 1 instance(s).
  Instance "orcl1", status READY, has 1 handler(s) for this service...
The command completed successfully

 

부가적으로 OS따로 리스너 로그에 에러가 지속적으로 나타날 수도 있고,

다른 경우로 아래처럼 ASM service died 메시지를 볼 수 있다.

04-MAR-2014 16:11:22 * service_died * +ASM1 * 12537

 

검색을 해도 이 문제는 찾을 수 없었는데, 가만히 ASM 로그를 보니 local_listener 의 host 값을 vip의 주소로 가져오는걸 확인할 수 있었다.

그런데 오라클 메타링크 가이드에 필요시 local_listener, remote_listener를 수정하란 이야기가 마지막에 써있었다.

 

SQL> alter system set local_listener='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=1.1.1.121)(PORT=1521))))' scope=memory sid='+ASM1';

 

ASM의 local_listener 의 host 값을 현재의 vip로 수정하고 정상화되었다.

 

[grid@rac1 admin]$ lsnrctl status

LSNRCTL for Linux: Version 11.2.0.2.0 - Production on 04-MAR-2014 16:38:07

Copyright (c) 1991, 2010, Oracle.  All rights reserved.

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=LISTENER)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 11.2.0.2.0 - Production
Start Date                04-MAR-2014 16:04:44
Uptime                    0 days 0 hr. 33 min. 22 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /app/11.2/grid/network/admin/listener.ora
Listener Log File         /app/oracle/diag/tnslsnr/rac1/listener/alert/log.xml
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=LISTENER)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=1.1.1.101)(PORT=1521)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=1.1.1.121)(PORT=1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
  Instance "+ASM1", status READY, has 1 handler(s) for this service...
Service "orcl" has 1 instance(s).
  Instance "orcl1", status READY, has 1 handler(s) for this service...
The command completed successfully

 

아니면 ASM을 재시작하기 위해 crs를 재시작하는 것도 한 방법이다.

 

 

Posted by neo-orcl
,

CRS는 10.2.0.5

DB는 10.2.0.5

이 상황에서 10.2.0.3으로 내려달라는 요청이 있었다.

DB 10.2.0.5인 상황에서 DBCA로 DB 생성했기에 compatible 값은 10.2.0.5 이다. 다운그레이드는 불가.

결국 10.2.0.3 DB를 추가로 설치하기로 하고 거기에다가 datapump를 써서 넘기라고 했다.

그런데 리스너는 현재 10.2.0.5의 엔진에서 돌아가고 있는 상황 아닌가?

그래서 10.2.0.5에서 netca로 리스너 제거하고 10.2.0.3에서 netca해봤더니 같은 이름을 가진 리스너가 있다며 진행 불가.

음. 혹시나 해서 CRS를 재시작해보고 진행해보니 잘 된다. 뭔가 OCR에 등록된게 꼬인 것 같다.

정리해보면

 

1. 10.2.0.5에서 리스너를 netca로 제거

2. 10.2.0.3에서 리스너를 netca로 생성. 잘 된다면 끝

3. 만약 같은 이름의 리스너가 있다면 전 노드에서 crsctl stop crs, crsctl start crs 후 다시 진행

 

※11gR2는 리스너 자체가 GI HOME에서 실행되기에 위 같은 문제는 발생하지 않는다.

'Knowledge > RAC' 카테고리의 다른 글

11.2.0.4 crsd.bin kill test  (0) 2016.10.19
runcluvfy post 실행결과  (0) 2015.12.16
Replace OCR, votedisk to ASM Disk Group  (0) 2014.02.24
RAC 환경에서 DB 수동으로 Drop  (0) 2013.12.18
RAC Failover Test 10.2.0.2 64bit on linux 4.5  (0) 2013.06.28
Posted by neo-orcl
,

희안하고 재미있는 현상이었다.

RAC 설치 후 클라이언트에서 토드 같은 툴을 통해 접속시 하나 접속할때는 괜찮은데 다른 접속을 추가하면

ORA-12545가 나타난다.

tnsnames.ora 설정의 내용을 간략히 보면 아래와 같다 형식은 틀리지만 내용중 중요한 부분만 파악해두자.

1.1.1.5와 1.1.1.6은 각 rac1-vip, rac2-vip의 ip이다.

 

ora=

(load_balance=off)

(faolover=on)

(protocol=tcp)(address=1.1.1.5)(port=1521)

(service=ora)

(protocol=tcp)(address=1.1.1.6)(port=1521)

(service=ora)

 

그런데 DB가 설치된 서버에서 직접 같은 tnsnames.ora로 해보면 아주 잘 된다.

서버는 리스너 크로스 등록을 해둬서 서버측 로드밸런스를 구현한 상태이다.

listener.ora 설정은 대략 아래와 같다.

rac1

listener=

(protocol=tcp)(address=rac1-vip)(port=1521)

(protocol=tcp)(address=1.1.1.1)(port=1521)

 

rac2

listener=

(protocol=tcp)(address=rac2-vip)(port=1521)

(protocol=tcp)(address=1.1.1.2)(port=1521)

 

당연히 서버의 /etc/hosts 파일에 rac1-vip와 rac2-vip 내용은 등록되어있다.

그럼 뭐가 문제일까?

 

클라이언트측 로드밸런싱과 달리 서버측 로드밸런싱은 클라이언트에서도 리스너의 주소를 resolution 할 수 있어야 하는 점이 포인트였다.

호스트 측에서 /etc/hosts 혹은 /windows/system32/drivers/hosts 파일에

1.1.1.5 rac1-vip

1.1.1.6 rac2-vip

설정 후 정상화되었다.

Posted by neo-orcl
,