티스토리 뷰

 

 


12c 지원은 이미 종료가 되었고,
19c라도 Upgrade해야 하는데...
어디서부터 손대야 하지?

 

RAC 환경을 운영하는 관리자라면, 한 번쯤 이런 고민에 머리가 복잡해진 경험이 있을 거라 생각해요.

단일 인스턴스도 아니고, 클러스터 노드가 엮인 환경이라 괜히 건드렸다가 장애라도 나면 주말이 통째로 날아가고...

서비스 중단이라는 최악의 상황까지...

 

그래서 오늘은 Oracle 12c RAC에서 19c로 넘어가는 전 과정을 절차, 주의사항, 실전 스케줄까지 한 자리에 모아 정리했습니다.

공식 문서와 현장 경험을 토대로 작성한 내용이니 북마크해 두시면 분명 쓸모가 있을 겁니다.

 


 

. Oracle 19c, 왜 올려야 할까?

 

이미 알고 있으시겠지만, 12c는 2022년 7월에 모두 공식 지원 종료되었습니다.

Oracle 공식 홈페이지에서 확인해보면 19c는 2027년 4월까지로 명시되어 있는 상태입니다.

그렇다고 23c나 26ai로 한번에 Upgrade하기에는 부담스러워 19c를 고민하고 계실거라 생각합니다.

현 시점에서는 19c로 Upgrade를 해야, 보안 패치와 기술 지원이 유지되기 때문에, 지금 전환해 두면 당분간은 걱정 없이 운영에 집중할 수 있습니다.



 

 

. 핵심 절차 한눈에 보기, 
  이 순서만 기억하세요

 

RAC 환경에서 가장 중요한 원칙은 딱 하나 입니다.

Grid Infrastructure를 먼저 올리고, 그 다음 Database를 올린다. 

상위 버전 Grid Infrastructure는 하위 버전 DB를 품을 수 있지만, 반대는 작동하지 않기 때문입니다.

 

Q. 우리 12c 버전에서 바로 19c로 갈 수 있나요?

  • 12.1.0.2 또는 12.2.0.1이라면 Direct Upgrade 가능
  • 12.1.0.1 이하라면 12.1.0.2로 중간 단계를 거친 뒤 진행

 

Q. Grid Infrastructure는 구체적으로 어떻게 올리나요?

1. 기존 Home과 별도 디렉토리에 19c Grid Infrastructure 소프트웨어 설치 (Out-of-Place 방식)

2. gridSetup.sh 실행 후 "Upgrade Oracle Grid Infrastructure" 옵션 선택

3. 각 노드에서 rootupgrade.sh를 순서대로 실행

 

Q. DB 전환에 권장되는 도구는 무엇인가요?

Oracle은 기존 DBUA 대신 AutoUpgrade Utility를 강력히 권장합니다. My Oracle Support에서 최신 autoupgrade.jar를 내려받은 뒤 세 단계로 진행합니다.

1. 분석 모드(Analyze) : 잠재적 문제 사전 탐지

2. 준비 모드(Fixups) : 발견된 이슈 자동 수정

3. 배포 모드(Deploy) : 실제 전환 수행

 

여러 인스턴스를 한 번에 제어할 수 있어 관리 부담이 확 줄어드는 점도 큰 장점입니다.




 

. 4주 Plan으로 Risk 줄이기

 

운영 환경 적용 전 최소 4주의 준비 기간을 확보하는 것이 정석입니다. 아래 타임라인을 기준으로 조직 상황에 맞게 조정해 보세요.

구간
핵심 작업
포인트
사전 준비
(1 ~ 2주차)
소프트웨어 및 최신 RU 패치 확보, OS 커널 파라미터 점검, 디스크 여유 공간 100GB 이상 확인, AutoUpgrade 분석 모드 실행
이슈를 일찍 발견할수록
비용이 적다
테스트 시뮬레이션
(3주차)
복제 환경에서 Dry-Run 수행, 소요 시간 측정, 폐지 기능과 Optimizer 변경에 따른 애플리케이션 호환성 검증
Cut-over Plan 확정
주말 운영 전환
D-Day
최종 RMAN Full Backup 및 OCR/Voting Disk 백업 후 GI Rolling 전환, 이어서 DB AutoUpgrade Deploy
서비스 중단 최소화
사후 안정화
(4주차)
딕셔너리 통계 갱신, AWR 보고서로 성능 비교, 1~2주 관찰 후 COMPATIBLE 파라미터 상향
한번 올리면 되돌릴 수
없으므로 신중하게

 


 

. DBA라면 꼭 챙기는 체크리스트

 
항목
세부 내용
Backup
전환 직전 Full RMAN Backup과 OCR/Voting Disk 백업은 선택이 아닌 필수
COMPATIBLE
Parameter
성능 검증이 끝날 때까지 절대 올리지 않기, 한번 변경하면 다운그레이드 불가
Non-CDB
Architecture
19c부터 Deprecated 상태이므로 PDB 전환 검토 필요
Timezone Patch
전환 전후 DST 버전 일치 여부 반드시 확인
Invalid Object
전환 전 utlrp.sql 실행으로 모든 객체를 Valid 상태로 정리
네트워크 대역폭
RAC 노드 간 Interconnect가 19c 요구사항에 부합하는지 재점검
Rollback 계획
GI 전환 실패 시 복구 스크립트를 문서화해 작업 옆에 비치
실시간 로그 감시
전환 중 별도 터미널에서 AutoUpgrade 로그와 CRS 로그를 tail -f로 모니터링

 

Oracle ACE 커뮤니티의 실무 사례를 보면, ORACLE_HOME 안에 남아 있는 잔여 프로세스나 공유 메모리 세그먼트를 미리 정리하지 않아 rootupgrade.sh 도중 드라이버 로딩 오류가 터지는 경우가 생각보다 흔합니다. 사소하지만 간과하면 새벽에 당황하게 되는 포인트이니 꼭 잊지마시고, 사전 점검하시기 바랍니다.

 

 

 


DB Upgrade는 복잡해 보여도, 순서를 지키고 충분히 리허설하면 생각보다 수월하게 끝나는 작업입니다. 

"준비 80%, 실행 20%"
라는 말이 이 작업에 딱 들어맞습니다.

 

혹시 현재 운영 중인 12c 패치 버전이나 전환 과정에서 마주친 ORA 에러가 있다면 댓글로 남겨 주세요.

같은 고민을 하는 분들과 경험을 나누면 훨씬 든든해집니다. 😉