Oracle Clusterware 리소스가 기동되지 않고 OFFLINE 상태에 머무를 때는 단순 재시작보다 의존 리소스, 프로파일 속성, 에이전트 로그, 권한과 저장소 연결 상태를 순서대로 확인해야 합니다. 상태 출력과 오류 시각을 기준으로 원인을 좁히는 점검 흐름을 정리합니다.
클러스터 리소스가 OFFLINE에서 멈출 때 의존성과 에이전트 로그를 분리하는 법
클러스터 리소스가 기동 요청 뒤에도 OFFLINE에 머무르면, 재시작 횟수보다 마지막 실패 시각과 선행 리소스 상태를 먼저 대조해야 합니다. TARGET은 ONLINE인데 STATE가 OFFLINE인 경우에는 해당 리소스의 실행 실패, 의존성 미충족, 저장소 또는 네트워크 조건 누락을 순서대로 살펴봐야 합니다. 특히 하면 STATUS_DEVICE_OFFLINE처럼 상태 코드가 함께 보일 때에는 장치·마운트·ASM 디스크그룹 등 하위 계층의 준비 상태를 빼놓지 않는 것이 중요합니다. 화면을 여러 번 갱신하거나 전체 클러스터를 재기동하기 전에 상태 출력과 오류 시각을 텍스트로 보관해 두면 원인을 훨씬 빠르게 좁힐 수 있습니다. 긴급하게 원격 확인이 필요하면 동네형컴퓨터 010-6833-8119 로 현재 리소스명과 오류 발생 시각을 먼저 전달하면 됩니다.
리소스 대상 상태와 의존성 그래프 확인
첫 단계는 crsctl stat res -t 결과에서 TARGET과 STATE를 별개로 읽는 것입니다. TARGET이 OFFLINE이면 관리자가 중지했거나 정책상 기동 대상이 아닌 상태일 수 있습니다. 반대로 TARGET은 ONLINE인데 STATE가 OFFLINE, INTERMEDIATE 또는 UNKNOWN이라면 Clusterware 가 기동을 시도했지만 조건을 충족하지 못했을 가능성이 높습니다.
한 줄의 상태만 보지 말고 같은 계층에 있는 리소스를 함께 기록해야 합니다. 예를 들어 데이터베이스 리소스가 내려가 있다면 ASM 디스크그룹, VIP, 리스너, 파일시스템 또는 사용자 정의 애플리케이션 리소스가 먼저 실패하지 않았는지 확인합니다. 후행 리소스만 강제로 시작하면 의존 조건이 다시 걸리면서 실패가 반복될 수 있습니다.
| 확인 결과 | 우선 해석 | 다음 점검 |
|---|---|---|
| TARGET OFFLINE / STATE OFFLINE | 의도된 중지 가능성 | 운영 정책과 기동 대상 여부 확인 |
| TARGET ONLINE / STATE OFFLINE | 기동 실패 또는 선행 조건 실패 | 의존성, 에이전트 로그, 반환 코드 확인 |
| 반복적인 ONLINE·OFFLINE 전환 | 재시작 정책 소진 또는 실행 실패 반복 | 최초 실패 시각의 로그부터 확보 |
다음으로 crsctl status resource <리소스명> -p를 사용해 프로파일 속성을 확인합니다. 여기서는 START_DEPENDENCIES, STOP_DEPENDENCIES, RESTART_ATTEMPTS를 중점적으로 봅니다. 시작 의존성에 포함된 리소스가 내려가 있으면 현재 보이는 OFFLINE은 결과일 뿐입니다. 재시도 횟수가 소진된 흔적이 있다면 원인을 고치지 않은 상태에서 다시 기동하는 대신, 최초 실패 메시지를 먼저 확보해야 합니다.
CRS 에이전트 로그에서 실패 유형 가르기
상태 출력으로 실패 범위를 정했다면 장애 시각 전후의 crsd 로그와 해당 사용자 계정의 oraagent 로그를 대조합니다. 두 로그의 시간을 맞추면 Clusterware 가 기동 명령을 내린 시점, 에이전트가 실행 파일을 호출한 시점, 종료 코드가 반환된 시점을 구분할 수 있습니다. 이 순서가 잡히면 리소스 정의 문제인지, 운영체제 실행 환경 문제인지 판단하기 쉬워집니다.
로그는 크게 실행 파일 경로 오류, 권한 또는 소유자 오류, 접속 오류, 의존성 오류로 나누어 읽습니다. 실행 파일을 찾지 못했다면 경로와 마운트 상태를 확인하고, 권한 오류라면 리소스를 실행하는 계정과 파일 권한을 비교합니다. 접속 오류는 리스너·VIP·서비스 상태를 함께 보며, 의존성 오류는 앞선 리소스가 실제로 ONLINE이 되었는지 다시 확인합니다. 하면 STATUS_DEVICE_OFFLINE 메시지가 같은 시각에 반복된다면 리소스 자체의 명령문보다 장치 인식, 디스크그룹 상태, 마운트 경로의 접근 가능성을 우선 점검하는 편이 안전합니다.
반복 기동 흔적이 있다고 해서 전체 리소스를 연속으로 재시작하면 최초 오류가 뒤섞일 수 있습니다. 가장 이른 실패 메시지 한 건과 그 직후의 반환 코드를 기준점으로 잡으십시오. 이후 메시지는 재시도 과정에서 생긴 2 차 오류일 수 있으므로, “마지막 오류”만으로 원인을 단정하지 않는 것이 좋습니다.
실행 실패를 단일 리소스부터 검증하는 절차
조치 전에는 해당 대상이 srvctl로 관리되는 구성요소인지, crsctl로 직접 관리되는 리소스인지 구분합니다. 데이터베이스, 인스턴스, 리스너, ASM처럼 서버 구성요소와 연결된 대상은 srvctl status와 srvctl config 결과를 함께 비교해야 실제 구성과 현재 상태의 차이를 확인할 수 있습니다. 사용자 정의 리소스라면 프로파일의 실행 경로와 의존성 정의가 핵심입니다.
기동 순서는 하위 조건부터 위로 올리는 방식이 좋습니다. ASM 디스크그룹이 필요한 대상은 디스크그룹 상태와 접근 경로를 먼저 확인하고, 네트워크 의존성이 있으면 VIP와 리스너의 상태를 점검합니다. 공유 파일시스템 또는 외부 스토리지를 참조하는 리소스는 마운트 여부와 읽기·실행 권한도 확인합니다. 선행 조건이 정상이라는 근거를 확보한 뒤 해당 리소스 하나만 기동하고, 다시 crsctl stat res -t로 TARGET과 STATE가 일치하는지 검증합니다.
이 과정에서 노드 전체 재부팅이나 일괄 기동은 마지막 선택지로 남겨두는 것이 좋습니다. 범위를 넓히면 정상 리소스까지 영향을 받을 수 있고, 장애 시각의 로그 연속성도 약해집니다. 확인된 실패 계층만 조치한 뒤 단일 리소스부터 상태 변화를 검증하는 방식이 원인 분리와 복구 검증 모두에 유리합니다.
방문·원격 일정은 장애 범위에 맞춰 조율
원격 점검 전에는 서버 콘솔 또는 운영체제 접근 권한 여부, 업무 중단 가능 시간, 현재 클러스터가 실제 서비스 중인지부터 정리합니다. 원격 지원은 새벽 시간을 제외하고 가능하며, 현장 작업이 필요한 경우에는 09:00~18:00 사이 서울·경기·인천·세종 일정 범위에서 조율할 수 있습니다. 작업 전 상태 출력과 오류 발생 시각을 텍스트로 남겨 두면 접속 뒤 재현하지 않아도 로그 구간을 바로 좁힐 수 있습니다.
최초 실패 로그를 남긴 뒤 문의하기
같은 리소스가 재시작을 반복하거나 의존 리소스까지 연쇄적으로 멈췄다면, 추가 재시작 전에 점검 자료를 확보하는 편이 좋습니다. 준비할 내용은 crsctl stat res -t 결과, 정확한 리소스명, 오류 화면 또는 로그 일부, Grid Infrastructure 버전, 장애 발생 시각입니다. 가능하다면 crsctl status resource <리소스명> -p 결과도 함께 보관하면 의존성 및 재시작 정책을 빠르게 비교할 수 있습니다.
OFFLINE 고정 상태는 단순히 “올리지 못한 리소스”가 아니라, 어느 계층에서 기동 조건이 끊겼는지 찾아야 하는 신호입니다. 대상 상태와 실제 상태를 분리하고, 선행 리소스와 에이전트 로그의 시간을 교차 확인한 뒤, 실패한 단일 대상부터 검증하는 흐름으로 접근하십시오.
상태 출력과 최초 오류 로그를 정리한 뒤 동네형컴퓨터 010-6833-8119 로 문의하거나 https://udns.kr/에서 점검 요청을 남길 수 있습니다.
자주 묻는 질문
Q. OFFLINE 상태는 항상 장애를 뜻하나요?
아닙니다. TARGET도 OFFLINE이면 의도적으로 중지된 상태일 수 있습니다. TARGET은 ONLINE인데 STATE가 OFFLINE이면 기동 실패 원인을 확인해야 합니다.
Q. 리소스를 바로 재시작해도 되나요?
선행 의존성이나 저장소 문제가 남아 있으면 재시작만 반복될 수 있습니다. 대상 상태, 의존성, 최초 오류 로그를 확인한 뒤 단일 리소스부터 조치하는 편이 안전합니다.
Q. 원격 점검에 필요한 정보는 무엇인가요?
Grid Infrastructure 버전, 리소스명, 상태 출력, 오류 발생 시각, 관련 로그 일부가 필요합니다. 운영체제 또는 서버 콘솔 접근 권한 여부도 함께 확인합니다.