데이터베이스 기동과 종료 (STARTUP, SHUTDOWN)

#핵심 요약

기동은 인스턴스 시작(NOMOUNT), 데이터베이스 마운트(MOUNT), 데이터베이스 열기(OPEN) 단계로 나뉨

종료 모드는 기다리는 대상이 다름
NORMAL은 접속한 사용자가 모두 나갈 때까지, TRANSACTIONAL은 진행 중인 트랜잭션이 끝날 때까지 기다리고, IMMEDIATE는 기다리지 않고 롤백한 뒤 끊으며, ABORT는 롤백도 하지 않음

ABORT로 내린 뒤에는 다음 기동 때 자동 인스턴스 복구가 필요함
다른 세 모드는 필요하지 않음

#개념과 동작 원리

#기동 단계

MOUNT 성공만으로 데이터 파일의 실제 존재까지 확인된 것은 아님
컨트롤 파일이 없으면 NOMOUNT까지, 필요한 데이터 파일이 없으면 MOUNT까지 진행한 뒤 다음 단계에서 실패할 수 있음
수업 설명에는 STARTED에서 멈추면 파라미터 파일, 메모리 문제라고 적혀 있으나, 실습에서는 컨트롤 파일 누락 상태에서도 STARTED에 도달했음
상태와 오류 메시지를 함께 확인해야 함

데이터 파일 이름 변경을 MOUNT 작업으로 분류하는 것은 전체 DB를 닫아 처리하는 방식임
실습에는 OPEN에서 MOVE DATAFILE을 쓰거나 비 SYSTEM 테이블스페이스를 OFFLINE으로 바꾼 뒤 이름을 변경한 사례도 있음
세부 절차는 데이터 파일과 OMF에 연결됨

CDB의 OPEN과 업무용 PDB의 OPEN은 별개임
수업에서는 PDB를 별도로 열었으나, Oracle 19c에서는 SAVE STATE로 재기동 시 PDB의 OPEN 상태를 보존할 수도 있음
PDB 상태와 구조는 CDB와 PDB 구조와 함께 확인함

#파라미터 파일을 찾는 순서

기동 시 플랫폼 기본 위치에서 다음 순서로 파일을 찾음
앞의 세 개가 SPFILE이고 마지막이 텍스트 파라미터 파일임

1. SRVCTL의 -spfile 옵션으로 지정한 위치(Oracle Restart, Clusterware 환경)
2. spfile<ORACLE_SID>.ora
3. spfile.ora
4. init<ORACLE_SID>.ora

DBCA가 SPFILE을 ASM 디스크 그룹에 만들었다면 그 디스크 그룹에서 찾음

#종료 모드

SQL*Plus에서 옵션 없는 SHUTDOWN의 기본 모드는 NORMAL임

IMMEDIATE도 커밋 안 된 긴 트랜잭션이 있으면 롤백 때문에 빨리 끝나지 않을 수 있음

수업 설명의 NORMAL 종료 후 커밋은 SQLPlus에서 옵션 없는 EXIT로 정상 종료한 실습 조건과 구분해야 함
SQLPlus의 옵션 없는 EXIT는 커밋하지만 EXIT ROLLBACK은 롤백함
로그아웃 시 커밋 여부는 클라이언트와 종료 옵션에 따라 달라짐

수업 메모에는 CDB에서 TRANSACTIONAL로 종료하면 PDB의 미커밋 작업은 기다리지 않았다는 설명이 있으나, 해당 실행 출력과 재현 조건은 기재 없음
이 관찰을 PDB 트랜잭션 전체에 적용할 수 있는지는 확인 불가임

NORMAL, TRANSACTIONAL, IMMEDIATE는 정상 종료를 완료하면 버퍼의 변경을 파일에 기록하고 데이터베이스를 일관된 상태로 닫음
정상 종료 순서는 데이터 파일, 온라인 리두 로그 닫기, 컨트롤 파일 닫기와 마운트 해제, 백그라운드 프로세스 종료와 SGA 해제임

#ABORT와 인스턴스 복구

ABORT와 인스턴스 장애 후에는 다음 데이터베이스 열기 과정에서 자동 인스턴스 복구가 필요함
실행 중인 인스턴스에 STARTUP FORCE를 쓰면 ABORT 후 재기동하므로 같은 복구 경로를 거침
인스턴스가 이미 내려가 있다면 FORCE가 항상 ABORT를 발생시키는 것은 아님

복구는 CKPT가 컨트롤 파일에 기록한 마지막 체크포인트 위치에서 시작함
CURRENT 그룹이나 임의의 ACTIVE 그룹의 맨 처음이 시작점인 것은 아님
체크포인트 위치가 이전 ACTIVE 그룹 안에 있으면 그 그룹의 리두도 필요하므로 CURRENT 그룹 하나로 충분하다고 판단하면 안 됨

FAST_START_MTTR_TARGET은 복구 시간 목표이며 완료 시간을 보장하는 값이 아님
작은 목표는 평상시 체크포인트 쓰기 비용을 늘릴 수 있음
0은 목표를 설정하지 않은 상태로 설명되며 체크포인트 자체가 전부 중지되는 뜻은 아님
목표, 예상 시간과 RAC 생존 인스턴스의 복구 실측은 RAC 병렬 처리와 복구 성능에 연결됨

#PDB 단위 ABORT

기존의 인스턴스 종료 표와 PDB 종료는 적용 범위가 다름
현재 컨테이너가 PDB라면 SHUTDOWN ABORT는 해당 PDB만 MOUNTED로 닫으며 CDB 인스턴스의 SGA와 백그라운드 프로세스는 유지됨
CDB$ROOT에서 같은 명령을 실행하면 인스턴스 전체와 그 안의 PDB가 종료됨

루트에서 ALTER PLUGGABLE DATABASE <PDB_NAME> CLOSE ABORT로 대상을 명시할 수 있음
해당 PDB의 미커밋 변경은 닫을 때 롤백하지 않으며 다시 사용할 때 복구가 필요함
수업에서는 다시 OPEN하는 절차로 설명하지만 Oracle 19c 문서는 단일 인스턴스의 PDB ABORT에 PDB 미디어 복구가 필요하다고 명시함
RAC에서는 마지막으로 열려 있던 인스턴스에서 PDB를 ABORT한 경우에 해당함
OPEN 한 번으로 복구가 항상 끝난다고 단정할 수 없으며, 실제 복구 명령과 완료 출력은 기재 없음

#필수 명령어 또는 SQL

#기동

STARTUP
STARTUP NOMOUNT
STARTUP MOUNT

ALTER DATABASE MOUNT;
ALTER DATABASE OPEN;

결과 해석:

STARTUP은 OPEN까지 진행함
NOMOUNT나 MOUNT로 올린 뒤 ALTER DATABASE로 다음 단계로 넘어갈 수 있음

#종료

SHUTDOWN IMMEDIATE

SHUTDOWN ABORT

결과 해석: 실습 기록의 IMMEDIATE 출력은 Database closed., Database dismounted., ORACLE instance shut down. 순서임
인스턴스 ABORT 출력은 ORACLE instance shut down. 한 줄임

#강제 재기동

STARTUP FORCE

결과 해석:

공식 문서는 SHUTDOWN NORMAL, IMMEDIATE, TRANSACTIONAL로 내릴 수 없거나 기동에 문제가 있을 때 쓰라고 적음
인스턴스가 떠 있으면 ABORT 모드로 내린 뒤 다시 기동함

#상태 확인

SELECT status FROM v$instance;

결과 해석:

실습 기록에서 NOMOUNT는 STARTED, 데이터 파일 누락 후 OPEN 실패 상태는 MOUNTED, 복구 후 상태는 OPEN이었음

#실습 1: 단계별 조회와 파일 누락

먼저 정상 종료 후 NOMOUNT까지만 시작하고 인스턴스 상태, 백그라운드 프로세스, 데이터 파일 조회 가능 여부를 비교함

SHUTDOWN IMMEDIATE
STARTUP NOMOUNT

SELECT status FROM v$instance;
SELECT COUNT(*) FROM v$bgprocess WHERE paddr <> '00';
SELECT name FROM v$datafile;

결과 해석: 실습의 상태 출력은 STARTED임
백그라운드 프로세스 수의 실제 조회 출력은 기재 없음
NOMOUNT의 데이터 파일 조회는 ORA-01507로 실패한다는 확인 포인트가 있으나 해당 조회의 출력 표는 기재 없음

이어서 MOUNT로 전환해 같은 데이터 파일 목록을 조회하고 OPEN으로 전환함
MOUNT에서 일반 사용자 접속을 시도하면 ORA-01033으로 실패한다는 확인 포인트가 있음
CDB를 연 뒤에도 접속 대상 PDB가 열렸는지 별도로 확인함

ALTER DATABASE MOUNT;
SELECT status FROM v$instance;
SELECT name FROM v$datafile;
ALTER DATABASE OPEN;

결과 해석: MOUNT에서는 컨트롤 파일의 데이터 파일 목록을 읽을 수 있음
이 단계별 조회 묶음의 전체 실행 출력은 기재 없음

결과 해석: 파라미터 파일 문제는 인스턴스 구성 전, 컨트롤 파일 문제는 MOUNT, 필요한 데이터 파일 문제는 OPEN에서 드러난 실습임
정확한 백업 방식과 명령은 파라미터 파일, 컨트롤 파일 백업, 복구, 데이터 파일, 블록 복구와 함께 확인함

별도의 컨트롤 파일 재생성 실습에서는 ORA-00283, ORA-00264가 출력된 뒤 최종 상태가 OPEN으로 조회되었음
오류 메시지의 한글 부분은 판독 불가이므로 성공 메시지만 있는 첫 실습과 구분해야 함
해당 실습의 컨트롤 파일 생성 시각은 26/08/19 10:13:26에서 26/08/19:11:01:23으로 바뀐 기록임

#실습 2: NORMAL, IMMEDIATE, TRANSACTIONAL 비교

세션 A에서 기준 행을 커밋하고 NORMAL 비교용 행은 미커밋 상태로 둠

CREATE TABLE shut_test (id NUMBER, memo VARCHAR2(20));
INSERT INTO shut_test VALUES (1, 'BEFORE');
COMMIT;
INSERT INTO shut_test VALUES (2, 'NORMAL_TEST');

세션 B에서 NORMAL로 종료를 요청한 다음 세션 A에서 EXIT함

SHUTDOWN NORMAL

EXIT

세션 B에서 종료 완료 후 STARTUP하고 아래 조회를 수행함
실습 확인 포인트는 NORMAL_TEST 행이 남는 것이며, 이는 SQL*Plus EXIT의 커밋 조건임
해당 SELECT의 실제 출력 표는 기재 없음

STARTUP

SELECT * FROM <SCHEMA>.shut_test;

세션 A를 재접속해 다음 행을 미커밋 상태로 둔 뒤 세션 B에서 IMMEDIATE 종료와 STARTUP을 수행하고 같은 조회로 비교함

INSERT INTO shut_test VALUES (3, 'IMMEDIATE_TEST');

결과 해석: 실습 확인 포인트는 미커밋 IMMEDIATE_TEST 행이 롤백되어 남지 않는 것임
개별 INSERT, SELECT의 출력 표는 기재 없음

TRANSACTIONAL 비교에서는 세션 A를 재접속해 다음 행을 미커밋 상태로 둠
세션 B가 종료를 요청한 뒤 세션 A에서 COMMIT해 진행 중 트랜잭션을 끝냄

INSERT INTO shut_test VALUES (4, 'TRANS_TEST');

SHUTDOWN TRANSACTIONAL

COMMIT;

결과 해석: 실습 확인 포인트는 COMMIT 전까지 종료가 기다리고, 재기동 후 TRANS_TEST 행이 남는 것임
수업 절차에는 COMMIT 전에 추가 INSERT를 새 트랜잭션으로 보고 거절된다고 설명한 부분이 있으나, 진행 중 트랜잭션 안의 추가 DML은 새 트랜잭션 시작과 구분해야 함
그 INSERT의 실제 오류 출력과 행 조회 출력은 없어 거절 여부는 확인 불가임

비교가 끝나면 세션 B에서 STARTUP 후 동일 조회를 수행하고, 세션 A를 재접속해 실습 테이블을 정리함

DROP TABLE shut_test PURGE;

결과 해석: DROP 실행 결과는 기재 없음
실습 환경의 해당 테이블만 삭제하며 PURGE는 휴지통을 거치지 않는 삭제임

#실습 3: ABORT와 FORCE의 복구 흔적

세션 A에서 값을 바꾸고 커밋하지 않음

UPDATE emp SET sal = 8888 WHERE empno = 7369;

세션 B에서 현재 컨테이너를 확인한 뒤 위의 SHUTDOWN ABORT와 STARTUP을 차례로 사용함
정상 기동된 상태에서 STARTUP FORCE도 별도로 비교함
각 재기동 뒤 업무용 PDB가 닫혀 있으면 대상 PDB를 열어 같은 행을 확인함

SHOW CON_NAME

tail -40 <ALERT_LOG>
grep -i "crash recovery\|redo scan\|redo application" <ALERT_LOG> | tail -10

결과 해석: 실습 설명에는 Beginning crash recovery와 Completed crash recovery를 확인하도록 되어 있음
로그 전체 출력과 시작, 완료 시각은 기재 없음
단순 tail 결과에는 이전 복구가 섞일 수 있어 이번 기동에 해당하는 기록인지 확인해야 함

SELECT sal FROM scott.emp WHERE empno = 7369;

결과 해석: 실습 설명에는 미커밋 8888이 롤백되어 800으로 돌아간다고 적혀 있음
해당 SELECT의 출력 표는 기재 없음
추가 확인 문제는 급여를 9500으로 바꾸고 COMMIT 직후 ABORT한 경우의 재기동 후 값을 비교하는 것이며, 그 문제의 실제 결과는 기재 없음

#실습 4: 체크포인트와 복구 목표

SELECT group#, sequence#, status, archived FROM v$log ORDER BY group#;
SELECT file#, checkpoint_change#, last_change# FROM v$datafile_header;
SELECT checkpoint_change#, controlfile_type, open_mode FROM v$database;
SELECT current_scn FROM v$database;
SHOW PARAMETER fast_start_mttr_target
SELECT recovery_estimated_ios, estimated_mttr, target_mttr FROM v$instance_recovery;

결과 해석: ACTIVE 그룹은 현재 쓰는 그룹이 아니어도 인스턴스 복구에 필요한 리두를 포함할 수 있음
그룹 상태 조회의 실제 출력 표는 기재 없음

ALTER SYSTEM CHECKPOINT;

결과 해석: 실습 기록에는 System altered. 출력 후 CURRENT_SCN 5498655, CHECKPOINT_CHANGE# 5498651, 다시 조회한 CURRENT_SCN 5498667이 적혀 있음
SCN_TO_TIMESTAMP로 5498651을 변환한 출력은 20-AUG-26 10.13.00.000000000 AM임
이 값들은 해당 실습의 기록이며 현재 DB에 적용할 고정값이 아님

ALTER SYSTEM SET fast_start_mttr_target=60;

SHOW PARAMETER fast_start

결과 해석: 실습 기록은 System altered., FAST_START_IO_TARGET 0, FAST_START_MTTR_TARGET 60, FAST_START_PARALLEL_ROLLBACK LOW임
실제 복구가 60초 안에 완료되었다는 기록은 아님

목표별 쓰기 비용은 MTTR Advisor로 비교함
Oracle 19c의 Advisor 활성화 조건은 STATISTICS_LEVEL이 TYPICAL 또는 ALL이고 FAST_START_MTTR_TARGET이 0보다 큰 상태임
대표 부하를 처리한 뒤 조언 값을 비교함

ALTER SYSTEM SET statistics_level = TYPICAL;

SELECT mttr_target_for_estimate, advice_status, dirty_limit,
       estd_cache_writes, estd_total_writes, estd_total_ios
  FROM v$mttr_target_advice
 ORDER BY mttr_target_for_estimate;

결과 해석: 목표별 예상 캐시 쓰기, 전체 쓰기, 전체 I/O를 비교하는 조회임
판독 가능한 텍스트 결과 표는 기재 없음
어떤 목표가 적합한지와 실제 복구 시간은 이 조회만으로 확정할 수 없음

#실습 5: PDB만 ABORT하고 범위 확인

루트에서 상태를 확인한 뒤 대상 PDB로 이동하고 현재 위치를 다시 확인함

SHOW CON_NAME
SELECT name, open_mode FROM v$pdbs;

ALTER SESSION SET CONTAINER = <PDB_NAME>;
SHOW CON_NAME

SHUTDOWN ABORT

결과 해석: 실습 확인 포인트의 종료 문구는 Pluggable Database closed.임
인스턴스 종료의 ORACLE instance shut down.과 구분함
실제 세션 출력 묶음은 기재 없음

루트로 돌아와 인스턴스 상태와 PDB 상태를 비교함

ALTER SESSION SET CONTAINER = CDB$ROOT;

SELECT status FROM v$instance;
SELECT name, open_mode FROM v$pdbs;

결과 해석: 실습 확인 포인트는 인스턴스 OPEN 유지와 대상 PDB만 MOUNTED로 바뀌는 것임
개별 조회의 출력 표는 기재 없음

수업의 다시 열기와 대상 명시 비교 절차는 다음과 같음
앞서 설명한 PDB 미디어 복구 요구와 오류를 확인한 뒤 진행해야 하며 복구 완료 결과를 가정하면 안 됨

ALTER PLUGGABLE DATABASE <PDB_NAME> OPEN;

ALTER PLUGGABLE DATABASE <PDB_NAME> CLOSE ABORT;

결과 해석: 현재 컨테이너에 의존해 PDB를 닫는 방식과 루트에서 대상을 명시하는 방식을 비교함
수업 절차에는 PDB 이름 철자가 서로 다른 부분이 있어, 같은 PDB를 닫고 다시 여는 절차로 볼 수 있는지는 확인 불가임
실습에서는 실제 대상 이름을 V$PDBS로 확인해야 함

#구문과 옵션 설명

#사용 조건과 주의사항

ABORT는 다음 기동 때 인스턴스 복구가 필요함
평소 종료에는 IMMEDIATE나 TRANSACTIONAL을 쓰고, 다른 방법이 통하지 않을 때만 ABORT를 씀

PDB를 닫는 것은 해당 PDB의 서비스 중단이며 CDB 인스턴스 종료와 구분해야 함
ABORT 직후의 파일 사본을 정상 종료 상태의 백업과 동일하게 취급하면 안 됨

#확인 문제와 판단 기준