db 시작단계
NOMOUNT (인스턴스 시작)
startup nomount
- Instance 가 구성되는 단계
- 파라미터 파일 필요 (PFILE, SPFILE)
- $ORACLE_HOME/dbs 초기화 파일 읽기 (spfileSID.ora > spfile.ora > initSID.ora)
- PFILE 위치 : $ORACLE_HOME/dbs/init[SID].ora
- SPFILE 위치 : $ORACLE_HOME/dbs/spfile[SID].ora
- 파라미터 파일을 읽어 들여서 인스턴스 생성
- 파라미터 파일을 읽어올 때 컨트롤 파일도 포함해서 올라옴 (컨트롤파일 - SCN, Data 정보 등이 저장)
- SGA 할당
- 백그라운드 프로세스 시작
- alert[SID].log 파일 및 trace file 열기
✅ 이 단계에서는 db생성과 컨트롤파일을 생성할 수 있다.
MOUNT (데이터 파일이 인스턴스에 연결)
alter database mount
- 데이터 파일 정보를 컨트롤 파일에서 읽어서 인스턴스와 연결 (인스턴스와 데이터베이스를 연결)
- 파라미터 파일에 지정된 컨트롤 파일 찾아 오픈
- 컨트롤 파일 필요
✅ database의 구조를 변경하는 작업을 할 수 있다.
(예: data file의 이름이나 위치 변경하는 작업, database 모드를 아카이브 모드로 변경하는 작업, database를 read only로 여는 작업)
OPEN (서버 시작할 수 있는단계)
alter database open
- 오라클 서버를 시작할 수 있는 단계
- 데이터 파일, 리두로그 파일 필요
- 이때 SCN 값이랑 datafile값이 같으면 정상적으로 오픈
- 값이 다르면 redo로그 파일에서 확인하고 더 이전 값은 아카이브로그 파일에서 확인 (recovery 해줌)
- 정합성 검사 후 DB 오픈
- 이 단계에서 select 가능
✅ smon이 open 단계에서 리두로그 파일을읽는다. 인스턴스 리커버리가 일어난다.
db 종료모드 4가지
❓ 왜 dba가 db를 내리는지?
1. 오라클 파라미터 값을 변경한 것을 인스턴스에 적용하고자 할 때
2. 오라클 upgrade와 patch를 수행
3. 오라클 데이터를 백업할 때
shutdown normal: 누가 scott으로 접속해있다? 누군가 update치고있다? 하면 안내려감. 사람들이 다 접속이 안되어있을 때, 체크포인트 일으키고 내려간다. (사용자들이 모두 정상종료 후 내려감)shutdown transactional: 현재 접속되어있는 세션 다 끊어버리지만 누가 update중이라면 기다려준다. commit시에 디비 내려간다. (사용자들의 트랜잭션이 모두 종료된 후 내려감)shutdown immediate: 현재 접속되어있는 세션 다 끊고 누가 update중? 다무시(rollback됨) (커밋된 데이터들은 버퍼캐시에서 데이터파일로 저장하고 다른데이터는 롤백 후 인스턴스 종료)shutdown abort: 얘는 진짜 급하게 할때.. 다 허용안하고 체크포인트도 안일으킨다. 어느정도 데이터 유실이 생길 확률이 있다. 체크포인트는 평상시에 수시로 일어나기 때문에 그렇게 크리티컬하게 문제가 생기지는 않을것이다. (디비 올릴 때 SMON이 인스턴스 리커버리를 해주어야한다.)
➡️ shutdown immediate로 db 내리자. 그런데 몇시간이 지나도 내려갈 기미가 안보인다면 shutdown abort를 하기
💡 dba를 위한 tip - shutdown immediate시
만약 shutdown immediate 하기 전에 대량의 DML작업이 있었다면 셧다운 할 때 시간이 오래 걸립니다. 왜냐하면 rollback을 해야 할 데이터가 많아서 입니다. 가급적 대량의 DML작업한 이후에 바로 DB를 내리지 않는게 좋습니다. 굳이 꼭 내려야한다면 수동으로 checkpoiint를 일으키고 shutdown immediate를 하세요! shutdown immediate할 때 체크포인트가 일어나는데 이 때 시간을 좀 줄일 수 있다.
💡 dba를 위한 tip - shutdown abort시
✅ 대량의 DML작업이 일어나는중에 갑자기 정전이 되거나 shutdown abort를 하면 메모리에서 commit한 데이터와 commit되지 아낳은 데이터가 다 사라지게 됩니다. data file에 반영 안된 상태에서 다 사라져 버립니다. 그러면 startup 할 때 open 단계에서 SMON이라는 백그라운드 프로세서가 redo logfile의 내용을 보고 하나하나 복구를 해줍니다.
이 때 !
대량의 DML작업이 일어난 중에 갑자기 서버가 꺼지게 되면, startup 할 때 시간이 오래 걸리게 되는데 그 때 SMON이 얼마나 바쁜지 모니터링을 해야합니다. -> 사람들이 계속 얼마나 걸려요 라고 묻기때문
💡 instance recovery 는 db가 완전히 starup 된 이후에도 계속해서 작업합니다.
그런데 이 때 cpu와 memory를 상당히 많이 사용해서 db가 여전히 느릴 수 있습니다. 따로 할 수 있는것은 없고 그냥 기다려야 한다. 딱 한가지 해결방법이 있는데, shutdown immediate로 내렸다가 startup하면 풀린다.
startup force = shutdown abort + startup
