구동 순서
간단하게 기술하면 다음과 같다. 운영체제가 ohad를 구동시키고 ohasd는 데몬들(gipcd, mdnsd,gpnpd, ctssd, ocssd, crsd, evmd, asm등) 을 구동시킨다. 그리고 crsd는 사용자 리소스들 (Database,SCAN, listener등)을 구동시키는 agent들을 구동시킨다.
Grid InfraStructure Clusterware에 대한 자세한 구동절차는 문서 1053147.1을 참고하기 바란다.
클러스터 상태
클러스터와 데몬들 상태를 알기 위해서는 다음과 같은 명령들을 사용한다.
crs 상태 체크
$GRID_HOME/bin/crsctl check crs
CRS-4638: Oracle High Availability Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
-- > 모두 online이 된 것을 확인한다.
세부 데몬 상태 체크
$GRID_HOME/bin/crsctl stat res -t -init
--------------------------------------------------------------------------------
NAME TARGET STATE SERVER STATE_DETAILS
--------------------------------------------------------------------------------
Cluster Resources
--------------------------------------------------------------------------------
ora.asm
1 ONLINE ONLINE rac1 Started
ora.crsd
1 ONLINE ONLINE rac1
ora.cssd
1 ONLINE ONLINE rac1
ora.cssdmonitor
1 ONLINE ONLINE rac1
ora.ctssd
1 ONLINE ONLINE rac1 OBSERVER
ora.diskmon
1 ONLINE ONLINE rac1
ora.drivers.acfs
1 ONLINE ONLINE rac1
ora.evmd
1 ONLINE ONLINE rac1
ora.gipcd
1 ONLINE ONLINE rac1
ora.gpnpd
1 ONLINE ONLINE rac1
ora.mdnsd
1 ONLINE ONLINE rac1
For 11.2.0.2 and above, there will be two more processes:
ora.cluster_interconnect.haip
1 ONLINE ONLINE rac1
ora.crf
1 ONLINE ONLINE rac1
오프라인 데몬을 구동하려면 다음과 같이 수행한다. 예를 들어 ora.crsd가 오프라인 상태라면 다음과 같이 구동한다.
$GRID_HOME/bin/crsctl start res ora.crsd -init
Case1 : ohasd가 구동되지 않는 경우
ohasd.bin 은 다른 모든 클러스터웨어 프로세스들을 직접 또는 간전적으로 구동시킬 책임이 있는 프로세스이기 때문에 맨 먼저 구동될 필요가 있다. 만약에 ohasd.bin이 구동되지 않으면 그것의 상태를 점검할 때 CRS-4639(could not contact oracle high availability services) 메세지가 보고될 것이다. 그리고 만약에 ohasd.bin이 이미 구동되어 있는 상태에서 다시 구동 시키려고 시도할 때는 CRS-4640 메세지를 보게 될 것이다. 만약에 ohasd.bin의 구동이 실패하게 되면 다음과 같은 메세지가 보고될 것이다.
CRS-4124:Oracle High Availability Services startup failed.
CRS-4000: Command Start failed, or completed with errors.
ohasd.bin 의 자동 구동 (Automatic startup)은 다음과 같은 요소들에 의해 영항 받는다.
1. 적합한 OS의 run level
crs가 구동되기전에 OS는 특정 런레벨로 설정될 필요가 있다.
클러스터웨어가 구동되기 위해 필요한 런레벨은 다음과 같이 알 수 있다.
centos 5
cat /etc/inittab | grep init.ohasd
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
AIX
cat /etc/inittab | grep init.ohasd
h1:2:respawn:/etc/init.ohasd run >/dev/null 2>&1 </dev/null
위 예제는 CRS가 런레벨(run level) 3과 5에서 수행되기로 되어 있는 것을 보여준다.
밑의 AIX는 런레벨 2에서 수행되기로 되어있다.
레벨의 의미는 다음과 같다.
0 : 시스템 종료이다. 이것으로 설정하게되면 리눅스가 시작되자마자 종료하므로 싱글부트
모드로 접속하여 값을 변경해서 복구시켜야한다. (사용금지)
1 : 윈도우 시스템의 안전모드와 비슷하다. 싱글 부트모드로 접속하는것인데 쓸일이 별로 없을것이다.
왜냐, 보통 싱글부트모드는 grub에서 변경해서 들어가는 방법을 사용하므로.
2 : 네트워크가 연결 되지 않은 상태로 부팅이다.
3 : 리눅스의 기본 모드로서 CUI 환경이다. 텍스트 모드라고 봐도 무방.
4 : 사용자 정의 레벨 으로서 예약된곳이다. 비워져 있다.
5 : 그래픽모드 즉 x-windows 를 부팅할때 자동으로 불러오려면 5를 사용하게 된다.
6 : reboot , 부팅되자마자 재부팅이 된다 (사용금지)
플랫폼의 종류에 따라서 CRS는 다른 런레벨(run level)에 수행될 수 있음을 주목할 필요가 있다.
현재의 run level을 확인하려면 다음과 같이 수행한다.
##AIX
who -r
. run-level 2 Mar 17 03:21 2 0 S
##Oracle Linux
who -r
run-level 3 2024-01-13 22:42
/etc/inittab 파일은 리눅스, 유닉스 계열의 os에서 부팅시 어떠한 방법으로 부팅할 것인지 설정할 수 있는 파일이다.
해당 파일을 init 프로세서가 돌면서 읽게되고 해당 설정에 따라 부팅을 하게된다.
Oracle Linux 6 (OL6) 또는 Red Hat Linux 6 (RHEL6) 은 더 이상 inittab을 가지고 있지 않다. 그래서 init.ohasd는 upstart 방식으로 /etc/init 안에 설정될 것이다. 하지만 "/etc/init.d/init.ohasd run"은 여전히 구동되어야만 한다.
하지만 7버전대 와서는 init을 쓰지 않게 되면서 파일 내용이 아래와 같이 변경
결론은 아래 파일을 보고 systemctl 명령어로 runlevel을 변경하면 됨
# systemctl get-default // 현재 runlevel을 보여주기
# systemctl set-default multi-user.target // 멀티유저(runlevel 3)으로 변경
# systemctl set-default graphical.target // 그래피컬(runlevel 5)로 변경
[root@localhost etc]# cat inittab
# inittab is no longer used when using systemd.
#
# ADDING CONFIGURATION HERE WILL HAVE NO EFFECT ON YOUR SYSTEM.
#
# Ctrl-Alt-Delete is handled by /usr/lib/systemd/system/ctrl-alt-del.target
#
# systemd uses 'targets' instead of runlevels. By default, there are two main targets:
#
# multi-user.target: analogous to runlevel 3
# graphical.target: analogous to runlevel 5
#
# To view current default target, run:
# systemctl get-default
#
# To set a default target, run:
# systemctl set-default TARGET.target
#
2. "init.ohasd run" process 구동 여부
Linux/Unix 상에서 "init.ohasd run"은 /etc/inittab 안에 설정되기 때문에 프로세스 init( pid 1
Linux/Solaris/Hp-ux 에서는 /sbin/init, AIX에서는 /usr/sbin/init) 이 "init.ohasd run " 프로세스를 구동시킨다.
만약 이것이 실패 하면 "init.ohasd run " 이 구동되지 않기 때문에 ohasd.bin 도 구동되지 않는다.
ps -ef | grep init.ohasd | grep -v grep
위에서 말했다 싶이 Oracle Linux 6 (OL6) 또는 Red Hat Linux 6 (RHEL6) 은 더 이상 inittab을 가지고 있지 않다. 그래서 init.ohasd는 upstart 방식으로 /etc/init 안에 설정될 것이다. 하지만 "/etc/init.d/init.ohasd run"은 여전히 구동되어야만 한다.
만약에 rc Snncommand 스크립트(rcn.d 안에 존재, 예를들면 S98gcstartup)가 전혀 동작하지 않는 상태(stuck)가 되면 init 프로세스는 "/etc/init.d/init.ohasd run" 을 구동시키지 않을수도 있다. Snncommand script 이 동작하지 않은 원인을 밝히기 위해서는 OS 벤더에 의뢰하기 바란다.
에러 "[ohasd(<pid>)] CRS-0715:Oracle High Availability Service has timed out waiting for init.ohasd to be started." 은 init.ohasd 가 정해진 시간 안에 구동되지 못할때 보여진다.
만약에 SA가 init.ohasd가 구동되지 못하는 원인을 찾을 수 없는 경우, 다음과 같은 단기 해결책(workaround)를 사용할 수 있다.
nohup ./init.ohasd run &
3. Clusterware 자동 구동 활성화 하기
이것은 기본적으로 활성화 되어 있다. 기본적으로 CRS는 node reboot시에 자동으로 구동되도록 설정되어 있다. 이를 명시적을 활성화 하지 위해서는 다음 명령을 사용한다.
$GRID_HOME/bin/crsctl enable crs
자동 구동이 활성화 되어있는지 확인하기 위해서는 다음 명령어를 사용한다.
$GRID_HOME/bin/crsctl config crs
만약에 OS 메시지 파일안에 다음과 같은 로그가 있으면
Feb 29 16:20:36 racnode1 logger: Could not access /var/opt/oracle/scls_scr/racnode1/root/ohasdstr
그 이유는 파일이 존재하지 않거나 접근할 수 없기 때문이다. 이는 누군가가 수동으로 수정하거나 도는 GI패치를 적용하기 위해서 잘못된 opatch를 사용했기 때문이다. ( 예를 들어 linux 에 패치를 적용하기 위해서 Solaris x64용 opatch를 사용한 경우)
위 메세지가 보이지 않을 또 다른 가능성은 syslogd(/usr/sbin/syslogd)가 완전히 구동되지 않았을 경우이다. 그리드는 이러한 경우도 또한 구동에 실패하게 된다. 이 경우는 AIX에는 젹용되지 않는다. 노드가 구동되고 있는 동안 OS가
S96ohasd 을 수행할 수 있는지를 알아보기 위해서 S96ohasd 를 다음과 같이 수정해 본다.
To find out whether OS is able to execute S96ohasd while node is coming up, modify S96ohasd:
From:
enable*)
$LOGERR "Oracle HA daemon is enabled for autostart."
To:
enable*)
/bin/touch /tmp/ohasd.start."`date`"
$LOGERR "Oracle HA daemon is enabled for autostart."
노드가 리부트(reboot)된 후에 /tmp/ohasd.start.timestamp 이 생성되지 않았다면 그것은 OS가 다른 Snn 스크립트의 영향으로 더 이상 진행하지 못하고 있다는 뜻이다. 만약에 /tmp/ohasd.start.timestamp 은 생성되어 있으나 메시지 파일 안에서 "Oracle HA daemon is enabled for autostart" 를 볼 수 없다면 그것은 syslogd 가 완전히 구동되지 않았다는 뜻이다. 두 경우 시스템 관리자(System Administrator)에게 의뢰하여 OS 레벨에서 문제를 살펴 보아야 한다. 후자의 경우에 있어서 임시적인 해결책은 약 2분동안 "sleep" 하는 것이다. 이를 위해서 다음과 같이 수정하면 된다:
From:
enable*)
$LOGERR "Oracle HA daemon is enabled for autostart."
To:
enable*)
/bin/sleep 120
$LOGERR "Oracle HA daemon is enabled for autostart."
다음과 같은 메시지가 OS messages 파일 안에 기록되어야 한다.
..
Jan 20 20:46:57 rac1 logger: exec /ocw/grid/perl/bin/perl -I/ocw/grid/perl/lib /ocw/grid/bin/crswrapexece.pl /ocw/grid/crs/install/s_crsconfig_rac1_env.txt /ocw/grid/bin/ohasd.bin "reboot"
ls -l $GRID_HOME/cdata/*.olr
-rw------- 1 root oinstall 272756736 Feb 2 18:20 rac1.olr
사용 가능한 olr 파일 위치 확인 하는법
$GRID_HOME/bin/ocrconfig -local -showbackup
만약 OLR이 접근 불가능 하거나 손상되면 ohasd.log는 아래와 같은 형태의 비슷한 메시지를 가지게 될 것이다.
2010-01-24 22:59:10.470: [ default][1373676464] Initializing OLR
2010-01-24 22:59:10.472: [ OCROSD][1373676464]utopen:6m':failed in stat OCR file/disk /ocw/grid/cdata/rac1.olr, errno=2, os err string=No such file or directory
2010-01-24 22:59:10.472: [ OCROSD][1373676464]utopen:7:failed to open any OCR file/disk, errno=2, os err string=No such file or directory
2010-01-24 22:59:10.473: [ OCRRAW][1373676464]proprinit: Could not open raw device
2010-01-24 22:59:10.473: [ OCRAPI][1373676464]a_init:16!: Backend init unsuccessful : [26]
2010-01-24 22:59:10.473: [ CRSOCR][1373676464] OCR context init failure. Error: PROCL-26: Error while accessing the physical storage Operating System error [No such file or directory] [2]
2010-01-24 22:59:10.473: [ default][1373676464] OLR initalization failured, rc=26
2010-01-24 22:59:10.474: [ default][1373676464]Created alert : (:OHAS00106:) : Failed to initialize Oracle Local Registry
2010-01-24 22:59:10.474: [ default][1373676464][PANIC] OHASD exiting; Could not init OLR
또는
2010-01-24 23:01:46.275: [ OCROSD][1228334000]utread:3: Problem reading buffer 1907f000 buflen 4096 retval 0 phy_offset 102400 retry 5
2010-01-24 23:01:46.275: [ OCRRAW][1228334000]propriogid:1_1: Failed to read the whole bootblock. Assumes invalid format.
2010-01-24 23:01:46.275: [ OCRRAW][1228334000]proprioini: all disks are not OCR/OLR formatted
2010-01-24 23:01:46.275: [ OCRRAW][1228334000]proprinit: Could not open raw device
2010-01-24 23:01:46.275: [ OCRAPI][1228334000]a_init:16!: Backend init unsuccessful : [26]
2010-01-24 23:01:46.276: [ CRSOCR][1228334000] OCR context init failure. Error: PROCL-26: Error while accessing the physical storage
2010-01-24 23:01:46.276: [ default][1228334000] OLR initalization failured, rc=26
2010-01-24 23:01:46.276: [ default][1228334000]Created alert : (:OHAS00106:) : Failed to initialize Oracle Local Registry
2010-01-24 23:01:46.277: [ default][1228334000][PANIC] OHASD exiting; Could not init OLR
또는
2010-11-07 03:00:08.932: [ default][1] Created alert : (:OHAS00102:) : OHASD is not running as privileged user
2010-11-07 03:00:08.932: [ default][1][PANIC] OHASD exiting: must be run as privileged user
또는
또는
2010-08-04 13:13:11.102: [ CRSPE][35] Resources parsed
2010-08-04 13:13:11.103: [ CRSPE][35] Server [] has been registered with the PE data model
2010-08-04 13:13:11.103: [ CRSPE][35] STARTUPCMD_REQ = false:
2010-08-04 13:13:11.103: [ CRSPE][35] Server [] has changed state from [Invalid/unitialized] to [VISIBLE]
2010-08-04 13:13:11.103: [ CRSOCR][31] Multi Write Batch processing...
2010-08-04 13:13:11.103: [ default][35] Dump State Starting ...
..
2010-08-04 13:13:11.112: [ CRSPE][35] SERVERS:
:VISIBLE:address{{Absolute|Node:0|Process:-1|Type:1}}; recovered state:VISIBLE. Assigned to no pool
------------- SERVER POOLS:
Free [min:0][max:-1][importance:0] NO SERVERS ASSIGNED
2010-08-04 13:13:11.113: [ CRSPE][35] Dumping ICE contents...:ICE operation count: 0
2010-08-04 13:13:11.113: [ default][35] Dump State Done.
해결책은 아래 명령어를 사용하여 정상적인 OLR 백업을 리스토어 하는것이다.
ocrconfig -local -restore <ocr_backup_name>
기본적으로 OLR은 인스톨이 완료되면 $GRID_HOME/cdata/$HOST/backup_$TIME_STAMP.olr로 backup 될 것이다.
OLR 수동 백업 방법
ocrconfig -local -manualbackup
6. ohasd.bin 은 네트워크 소켓 파일 (network socket file)을 접근할 수 있어야 한다.
2010-06-29 10:31:01.571: [ OCRSRV][1217390912]th_listen: CLSCLISTEN failed clsc_ret= 3, addr= [(ADDRESS=(PROTOCOL=ipc)(KEY=procr_local_conn_0_PROL))]
2010-06-29 10:31:01.571: [ OCRSRV][3267002960]th_init: Local listener did not reach valid state
그리드 인프라스트록처 환경 하에서 ohasd에 관련된 소켓 파일들은 root 에 의해서 소유되어야 한다. 그러나 Oracle Restart 환경 하에서 그것 들은 grid 유저에의해서 소유된다. 예제는 "네트워크 소켓 파일 위치, 소유권 및 허가권" 섹션을 참조하기 바란다.
7. ohasd.bin 이 로그 파일(log file)이 존재하는 위치를 접근할 수 있어야 한다.
OS messages/syslog는 다음과 같은 내용을 보여준다.
Feb 20 10:47:08 racnode1 OHASD[9566]: OHASD exiting; Directory /ocw/grid/log/racnode1/ohasd not found.
예제로 "로그 파일 위치, 소유권(Ownership)과 허가권(Permission)" 섹션을 참고하기 바란다. 만약에 예상된 디렉토리가 없다면 적합한 소유권과 허가권을 가지고 생성되어야 한다.
8. SUSE 리눅스 상에서 노드 리부트 후 ohasd 구동이 실패할 수도 있다.
이에 대해서는 "note 1325718.1 - OHASD not starting after reboot on SLES"
를 참조하길 바란다.
9. OHASD 구동이 실패했을 때,
"ps -ef| grep ohasd.bin" 는 ohasd.bin 이 시작됨을 보여 주나 $GRID_HOME/log/<node>/ohasd/ohasd.log 안에는 수분 동안 아무런 것도 기록되지 않는 경우가 있다. 이럴 때 truss를 수행해 보면 non-opened 파일 핸들들을 계속해서 반복적으로 종료하려 하고 있음을 볼 수 있다 :
15058/1: 0.1995 close(2147483646) Err#9 EBADF
15058/1: 0.1996 close(2147483645) Err#9 EBADF
..
pstack으로부터 ohasd.bin 의 Call Stack은 다음과 같이 보여 진다.
그 원인은 bug 11834289 이다 이는 11.2.0.3 또는 그 이상 버전에서 해결되었다. 이 버그의 또 다른 증상은 클러스터웨어 프로세스들이 동일한 Call Stack과 truss output("close" OS call을 반복적으로 수행)을 보이면서 구동이 실패하는 것이다. 만약에 다른 리소들을 구동하려고 할때 해당 버그를 만나게 되면 "CRS-5802: Unable to start the agent process" 메시지가 또한 보일 것이다.
이 외에 다른 원인과 해결책은 note 1069182.1- OHASD Failed to Start: Inappropriate ioctl for device 에 기술되어 있다.
12. ohasd.bin 이 정상적으로 구동 되었으나 "crsctl check crs" 명령이 오직 아래 결과만 보여 주고 다른 결과는 보여 주지 않는 경우가 있다.
또한 "crsctl stat res -p -init" 명령도 아무런 결과를 보여 주지 않는다.
그 원인은 OLR이 손상되었기 때문이다. OLR을 복구하기 위해서 note 1193643. 을 참조하기 바란다.
ohasd 구동이 여전히 실패 하면
<grid-home>/log/<nodename>/ohasd/ohasd.log 와 ohasdOUT.log 파일을 참조할 필요가 있다.
'Oracle > Admin' 카테고리의 다른 글
| [Oracle] v$sqlarea vs v$sql cusor sharing 테스트 (0) | 2024.06.14 |
|---|---|
| [Oracle] 병렬 프로세스 간 데이터 분배 비교 방식과 PQ_DISTRIBUTE 힌트 사용 (1) | 2024.06.13 |
| [Oracle]Fatal NI connect error 12170. (0) | 2024.05.27 |
| [Oracle]Oracle DB 접속 방식 두가지 (0) | 2024.05.21 |
| [Oracle] Oracle Dump (0) | 2024.05.09 |
