출처 : http://kr.forums.oracle.com/forums/thread.jspa?threadID=477195&tstart=45

10G CRS 설치 절차와 문제 해결(LINUX)
=====================================

PURPOSE

---

리눅스 환경에서 10g CRS 설치 절차 및 문제 해결 방법 소개

Explanation

---

1. 적용 범위

리눅스 환경에서의 설치 및 구성

2. 개관

이 문서는, Cluster Ready Services 10.1.0.1 를 설치하고 구성하는데 도움이 되는
지침과 문제 해결 방법을 소개 한다.

10G RAC설치를 위해서는 다음과 같은 절차를 밟아야 한다.

1) CRS 설치 및 구성 Cluster Ready Services
2) RAC의 설치 및 구성
3) VIPCA Virtual IP Configuration Assistant를 사용한 VIP의 구성

3. 가정

저장 공간으로 공유 디스크를 갖춘 (CFS or RAWDEVICE) 2개의 리눅스 노드.

OH=ORACLE_HOME 오라클을 설치하고자 하는 디렉토리 예: /project/linux/10/rac/10B2/RAC
CRSHOME=CRS_HOME CRS를 설치하고자 하는 디렉토리 예: /project/linux/10/rac/10B2/CRS
OB=ORACLE_BASE 예: /project/linux/10/rac/10B2

OB는 다른 위치이어야만 한다.

CRS는 RAC의 기본 콤포넌트이다. (특히 리눅스 환경에서는 필수 요소) 따라서, CRS 설치 관련 이슈를 이 문서에
다룬다.

4. 선행조건

노드 N1와 N2에서 ssh가 동작되는지 확인한다.
예를 들어, N2에서 ssh N1을 실행하면, passwd 확인 없이 N2에 연결되어야 한다.

다음 4가지 조합을 모두 테스트 해 본다.

예. N1 -> N1
N1 -> N2
N2 -> N1
N2 -> N2

백업 목적으로 /etc/inittab 파일을 /etc/inittab.orig 으로 복사해 둔다.

5. 상세 내역

1) 설치 원본을 포함한 디스크의 CRS shiphome에서 runinstaller를 실행시킨다.

./runInstaller -invPtrLoc $OB/invptr.loc

2) orainventory를 확인하는 화면에서 새로운 위치를 다음과 같이 지정한다 .

$OB/oraInventory.

참고: 10G RAC 설치시, orainventory는 CRS 및 RAC 설치시 공유된다. 따라서, RAC 설치시에도
동일한 인벤토리를 지정하도록 한다.

3) 클러스터를 구성하는 노드 명을 확인하는 화면이 나타난다.
적절한 값을 입력한다. public node name 필드에 입력을 하기 위해서는, 명령행에서
/bin/hostname을 실행시키고 명령 실행 결과에따라 나타나는 nodename을 입력해 public nodelist entry
값을 채운다.

적절한 private node name을 찾기위해서는 유사한 절차를 거쳐, private node name entry 값을 채운다.

값이 정말 올바른지 확인 하기 위해 마지막으로 다음과 같은 명령을 실행시킨다.

% ping <private node name>

노드가 존재한다면, 명령 실행 결과를 통해 확인할 수 있다.
또한 결과 값을 /sbin/ifconfig -a 명령과 비교해 본다.
/etc/hosts가 public nodename 및 private nodename을 둘다 포함하고 있는지를 확인한다.

4) 다음 화면은 ocr device entry값을 묻는 화면이다.
여기서는, 두 노드에서 모두 접근 가능한 공유 디스크상의 파일을 입력한다.

예 : /ocfs/OCR/ocr.disk 또는 /dev/rawocr rawdevices 가 존재하고, 올바로 구성되어야 함
만약 이 파일이 존재한다면, 올바른 권한이 설정되어 있으며, 어떤 데이터도 포함하지 않고 있는지 여부를
확인 하여야 한다.

OCR을 위해 깨끗한 디스크를 사용하는 지 여부를 확인하기 위해 다음과 같은 명령을 실행시킨다.

dd if=/dev/zero of=<ocr device name> bs=<X> count=1000
여기서 X 는 1232896 값으로 지정한다 (1024 * 1024)

이 entry는 이후 root.sh를 실행시킬 때 공통의 OCR 위치에 ( 예 /var/opt/oracle/srvConfig.loc )
저장되다는 점에 유의해야 한다.

만약 /var/opt/oracle/srvConfig.loc 파일이 이미 존재한다면, ocr 디바이스를 묻는 화면이 나타나지
않는다. 이 경우 동일한 OCR 파일이 9i 설치시 사용되었다면 먼저 디바이스를 백업 해야 한다.

동일 클러스트에 9i를 설치했고, 10G CRS를 설치할 계획이라면,ocr 내용은, 자동으로 9i에서 10G 포맷으로
업그레이드 된다.

5) 다음 화면에서는 voting device entry 입력을 요청한다. step 4에서 설명한 방식 처럼 비슷한 device를
저정한다. 예: /ocfs/Voting/voting.disk. 이것은, ocssd daemon에 의해 사용된다.
유의해야 할 점은, 4단계 및 5단계에서 입력하는 내용이 파일이지 디렉토리가 아니라는 점이다.
만약 파일이 존재한다면, owner와 root에 read write 권한이 있어야 한다.
이 entry로 CRS 설치가 시작되고, 어느정도 설치 된 시점에서 root.sh을 root 권한으로 실행 시킬 것을
요청하게 된다. root.sh은 Cluster Ready Services를 구성하고 구동시킨다. 클러스터에 속하는 모든 노드에서
root.sh을 실행 시켜야 한다.

6. Root.sh

root.sh의 실행.
이 스크립트는 2 단계에서 CRS를 구동시킨다. 처음에는 CRS를 테스트 목적으로 일반 사용자 권한으로 구동시킨다.
만약 정상으로 실행된다면, 적절한 entry 값이 시스템 디렉토리에 추가 된 후, CRS가, /etc/inittab을 통해
적절하게 구동된다. 이 단계에서는, crsd가 root 프로세스로 구동되는 반면 다른 두개의 데몬 (evmd, ocssd)는
일반 사용자 프로세스로 기동된다. 이 단계에서 css가 실패할 경우 시스템은, 리부팅된다.
리부팅을 방지하기 위해서는, 위에서 언급한 1단계 절차를 거치도록 한다.

유의해야 할 또다른 사항은, CRS를 성공적으로 구동 시킨 이후, 다른 이유로 인해 CSS 데몬이 죽을 경우,
노드가 리부팅 된다는 것이다. 이것 또한 1단계에 기술된 내용이 적절하게 수행되지 않을 경우 그럴 수 있다.
정상적으로 수행되었을 경우, CRS는 자동으로 다시 살아나게 된다.

7. Troubleshooting tips

만약 시스템에서 처음으로 CRS 서비스를 구동 시키는 것 이라면, 모든 서비스가 정상적으로 구동될 지 여부를
알 수 없다. 설정상의 이유로 css가 실패할 경우, 시스템에 리부팅이 된다는 점을 유념해야 한다.

이와 같은 상황을 예방하기 위해서는, 다음과 같은 절차를 거쳐야 한다.

1) $CRSHOME/css/admin/init.cssd 파일에서 $FAST_REBOOT을 포함하는 라인을 주석처리 한다. 이 작업을
양쪽 노드에서 수행한다.
2) root.sh 실행이 실패할 경우, 로그파일을 확인하여, 문제 추적을 할 수 있다.

CRS는 다음과 같이 3개의 데몬으로 구성되어 있다.
a> cssd
b> evmd
c> crsd

각 데몬의 로그 파일은, $CRSHOME/<daemon name>/log/ 디렉토리에 기록된다. 로그 파일의 내용은, 대부분
문제가 발생한 원인을 밝혀 내는데 도움이 될 만한 정보를 포함하고 있다.
만약, 로그 파일을 분석하여 문제를 해결하고 root.sh를 다시 실행 시켜야 할 경우에는, 다음과 같이 한다.

- 위에서 말한 데몬들이 모두 죽어 있는지 확인한다. 만약 살아 있는 프로세스가 있다면 kill 시켜야한다.
- 흔히 발생하는 실수는, 데몬의 목록을 확인하는 다음 명령을 실행 시키는 것이다.
ps -eaf | grep ocssd
위 명령은, CRS 데몬의 이름을 포함하지 않으므로, 데몬이 모두 죽어 있다고 착각하기 쉽다.

대신 다음과 같은 명령을 통해 확인 해야 한다.

ps -elf | grep ocssd or
ps -efww | grep ocssd

프로세스를 kill 시킨 후에는, $CRSHOME/<daemon_name>/init/ 디렉토리 내의 파일을 삭제한다.
또한, ocr device가 CRS를 재 구동할 때 마다 적절하게 clean up 되었는지 여부를 확인 해야 한다.
ocr device를 clean out 시키기 위해서는, 위에서 언급한 4단계 작업을 수행하면 된다.

그리고 나서, 문제가 발생된 모든 원인을 해소했는지 여부를 확인 한 후 root.sh를 실행시킨다.

3) root.sh이 성공적으로 실행되면 - 예를 들어 CRS 데몬이 노드 1에 성공적으로 구동되면, root.sh을 나머지 노드에서도 실행시킨다.

8. CRS 서비스를 중단 시키는 절차.

CRS와 RAC가 설치되어 운영중일 경우, CRS 서비스를 중단 시켜야 할 때 다음과 같은 절차를 따른다.

1) /etc/inittab.orig 파일을 /etc/inittab 으로 복사한다. (/etc/inittab.orig 파일은 앞에서 기술한 선행 조건에서
복사한 파일을 말함.

2) 서비스 중인 CRS와 연관된 자원이 있을 경우, 해당 애플리케이션을 모두 중단시킨다. 다음은 관련된 명령이다.

$RACHOME/bin/srvctl stop instance -i <instance name> -d <dbname>
$RACHOME/bin/srvctl stop nodeapps -n <N1>
$RACHOME/bin/srvctl stop nodeapps -n <N2>

3) root 계정에서 다음과 명령을 실행시킨다. /sbin/init q

4) /etc/init.d/init.crs stop

만약 위 절차를 따르지 않고 CRS 데몬을 kill 시킬 경우, 데몬이 계속해서 다시 살아나게 될 것이다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.