추가 적립 안내

오라클 데이터베이스의 구조와 본질을 그림으로 쉽게 이해!
스테디셀러 《그림으로 공부하는 오라클 구조》의 최신 개정판!
일본에서 50만 부 이상의 판매를 보인 ‘그림으로 공부하는’ 시리즈의 대표작!

커맨드나 기능명 등을 암기하는 것만으로는 오라클 데이터베이스의 관리 업무 능력을 익히기 어렵습니다. 이 책은 오라클 데이터베이스의 아키텍처나 내부 동작/기본 동작을 하드웨어나 OS의 동작과 더불어 알기 쉬운 그림으로 구성되어 있습니다. 언뜻 봐서는 복잡해 보이는 아키텍처나 내부 동작도 일반 창고 회사의 구조에 빗대어 도식화하였습니다. 따라서 오라클에 대해 머릿속에 그림을 그려 가듯 손쉽게 이해할 수 있습니다. 이번 개정판에서는 내용의 모달화를 포함해 컬럼이나 부록(커맨드에 따른 기본적인 오라클 조작을 설명)도 추가하였습니다. 일상의 오라클 운용/관리 업무에 도움이 될 뿐만 아니라 응용력 있는 엔지니어가 되기 위한 지식을 배우고자 하는 분께 적합합니다.

이 책의 대상 독자
● 오라클을 처음 배우는 분
● 오라클을 배웠지만 아키텍처에는 자신이 없는 분
● 오라클을 배우다가 좌절한 분
● 오라클이 잘 이해되지 않아 고민 중인 분
● 한 단계 더 도약한 데이터 엔지니어가 되고 싶은 분

CHAPTER 1 I/O와 디스크의 관계 1
1.1 오라클을 이해하기 위한 필수 키워드 2
1.2 오라클과 디스크(하드디스크) 3
1.3 디스크의 동작 4
1.4 데이터를 보증하기 위한 디스크 12
1.5 요약 14

CHAPTER 2 오라클의 여러 프로세스 17
2.1 오라클의 역할 이미지 18
2.2 데이터베이스의 데이터는 모두의 것 20
2.3 오라클이 여러 개의 프로세스로 구성된 이유 25
2.4 서버 프로세스와 백그라운드 프로세스의 역할 27
2.5 각 프로세스가 수행하는 처리 29
2.6 요약 32

CHAPTER 3 캐시와 공유 메모리 37
3.1 어째서 캐시가 필요한 것인가? 38
3.2 그래서 캐시란 대체 무엇인가? 39
3.3 데이터는 블록 단위로 관리 41
3.4 캐시를 사용해서 인덱스 검색을 효율적으로 43
3.5 프로세스는 캐시를 공유 45
3.6 공유 메모리에 필요한 설정 48
3.7 공유 메모리는 어떤 식으로 보이는가? 50
3.8 버퍼 캐시를 정리하는 LRU 알고리즘 52
3.9 오라클뿐만이 아닌 OS나 스토리지에 대해서도 생각하자 54
3.10 요약 58

CHAPTER 4 SQL문 분석과 공유 풀 61
4.1 SQL문의 분석과 공유 풀을 왜 배워야 하는가? 62
4.2 SQL문과 일반적인 프로그래밍 언어의 차이 62
4.3 서버 프로세스와 분석 63
4.4 실행 계획이 최적이라는 것을 판단하기 위해서는? 66
4.5 공유 풀의 동작과 구조 71
4.6 수치로 알아보는 분석과 공유 풀의 정보 74
4.7 요약 76

CHAPTER 5 오라클의 기동과 정지 79
5.1 기동과 정지를 왜 배워야 하는가? 80
5.2 오라클의 기동/정지의 개요 80
5.3 업무의 시작에 해당하는 오라클의 기동 81
5.4 인스턴스, 데이터베이스, 그리고 주요 파일의 구성 82
5.5 기동 처리의 흐름과 내부 동작 85
5.6 업무 종료에 해당하는 오라클의 정지 91
5.7 데이터베이스를 수동으로 생성하기 93
5.8 요약 95

CHAPTER 6 커넥션과 서버 프로세스의 생성 97
6.1 애플리케이션에서의 접속을 왜 배워야 하는가? 98
6.2 오라클의 접속 동작 99
6.3 접속 동작의 확인 106
6.4 정지나 리스너의 상태 확인 110
6.5 성능을 개선하기 위해서는? 111
6.6 요약 113

CHAPTER 7 오라클의 데이터 구조 115
7.1 오라클의 데이터 구조를 왜 배워야 하는가? 116
7.2 가변 길이 데이터를 관리할 프로그램을 만들기 위해서는? 117
7.3 오라클의 데이터 구조 120
7.4 데이터 구조에는 어떤 것들이 있는가? 123
7.5 실제 흐름을 따라 각 동작을 확인 128
7.6 프로세스에서 본 데이터 구조 130
7.7 요약 132

CHAPTER 8 오라클의 대기와 Lock 135
8.1 대기와 오라클의 Lock을 왜 배워야 하는가? 136
8.2 데이터베이스에 Lock이 필요한 이유 136
8.3 대기와 Lock 대기 139
8.4 Latch의 구조 147
8.5 요약 150

CHAPTER 9 REDO와 UNDO의 동작 153
9.1 REDO와 UNDO를 왜 배워야 하는가? 154
9.2 지속성을 구현하기 위해서는 156
9.3 REDO와 UNDO의 개념 158
9.4 REDO의 구조 160
9.4.1 REDO의 요약 163
9.5 UNDO의 구조 163
9.6 여러 상황에서 REDO와 UNDO의 동작 165
9.7 요약 171

CHAPTER 10 백업/복구의 구조와 동작 175
10.1 백업/복구를 왜 배워야 하는가? 176
10.2 백업/복구에 필요한 지식의 복습 177
10.3 백업의 종류와 특징 179
10.4 데이터베이스 손상의 예 181
10.5 기본적인 복구의 종류와 동작 183
10.6 기본적인 복구의 흐름(데이터베이스 전체의 복구) 188
10.7 그 외의 복구 192
10.8 요약 196

CHAPTER 11 백그라운드 프로세스의 동작과 역할 199
11.1 백그라운드 프로세스를 왜 배워야 하는가? 200
11.2 백그라운드 프로세스와 서버 프로세스의 관계 200
11.3 DBWR의 동작과 역할 205
11.4 LGWR의 동작과 역할 209
11.5 SMON의 동작과 역할 210
11.6 PMON의 동작과 역할 211
11.7 LREG의 동작과 역할 211
11.8 ARCH의 동작과 역할 212
11.9 그 외의 백그라운드 프로세스 214
11.10 요약 216

CHAPTER 12 오라클 아키텍처와 동작에 관한 Q&A 217
12.1 지금까지의 복습 218
12.2 오라클의 동작에 관한 질문 222
12.3 모니터링/운영에 관한 질문 223
12.4 해답과 해설 오라클의 동작에 관한 질문 224
12.5 해답과 해설 모니터링/운영에 관한 질문 233
12.6 요약 235

APPENDIX 유스케이스로 배우는 오라클 239
A.1 A 씨에게 준비된 과제 240
A.2 오라클의 기동 240
A.3 리스너를 통한 접속 242
A.4 데이터 파일의 추가 245
A.5 백업하기 247
A.6 OS 명령어를 사용한 데이터 파일 삭제 253
A.7 현재 상태의 백업 255
A.8 복원 258
A.9 복구 260
A.10 데이터 파일의 제거 263
A.11 오라클의 정지 265

오라클은 ‘블록’이라고 하는 단위로 데이터를 관리합니다. I/O의 단위도 블록을 기반으로 하고 있으며, 버퍼 캐시도 블록 단위로 관리하고 있습니다. 블록은 단순하게 ‘정리용 상자’라고 생각하시면 됩니다. 일상생활에서도 크기가 작고 양이 많은 물건들을 정리할 때는 상자를 몇 개 준비하고 그 안에 보관하는 경우가 많습니다. 오라클의 데이터는 수 바이트에서 수천 바이트 이상의 여러 ‘로우(행)’로 존재하므로, 오라클 역시 블록이라고 하는 정리용 상자를 준비해서 보관하는 것입니다. 오라클 블록의 대략적인 구조는 그림 3.6과 같습니다. _41p

리스너는 서버 프로세스 생성이 끝나면 소켓을 서버 프로세스에 인계합니다. 창고 회사로 비유해서 설명해보면 회사의 대표 전화번호로 받은 전화를 접수 데스크가 담당자에게 돌려주는 과정과 같습니다. 리스너가 인계한 후부터 서버 프로세스와 오라클 클라이언트는 직접 송수신하므로 리스너는 자유로워집니다. 이것은 이 책의 1장에서 나열했던 오라클을 이해하기 위한 키워드 중 하나인 ‘병렬 처리를 가능케 하고 높은 처리량을 실현한다’에 해당합니다. _104p

SQL의 처리 과정을 튜닝한다는 관점으로 바라보면, ‘Non-Idle 대기 이벤트 + SQL 처리에 사용하는 CPU 시간’이 SQL에 걸린 시간이므로 이 부분은 매우 중요한 개념입니다. 튜닝을 할 때 이들 항목에는 항상 신경을 쓸 필요가 있습니다. 대기 이벤트는 스태츠팩(또는 AWR)이나 v$session_wait에서 볼 수 있습니다(리스트 8.1). 각 프로세스가 이런 식으로 작업을 처리하거나 다른 프로세스의 처리를 기다리는 등, 다른 프로세스에게 일을 의뢰하고 자신은 기다리는 동작을 마치 사람처럼 수행하기 때문에 개인적으로는 오라클의 프로세스를 사람의 형태로 의인화해서 표현할 때가 많습니다. _141p

완전 복구란, 데이터베이스를 최신 데이터까지 복구한다는 의미입니다. 이와 대조적으로 불완전 복구는 어떤 시점(도중)까지만 복구한다는 의미입니다. 일반적으로 특별한 이유가 없는 한 완전 복구를 선택하며, 오라클도 특별히 지정하지 않으면 완전 복구를 수행합니다. 불완전 복구를 선택하는 것은 아카이브 REDO 로그가 유실되었을 때나 어떤 사정으로 인해 특정 시점의 데이터로 바꾸고 싶을 때 등입니다. _184p

오라클이 과부하가 걸리기 전이라면 오라클 안에 부자연스러운 대기는 없으며, 도착한 SQL을 거의 즉시 처리해서 되돌려주는 상태일 것입니다. 지금까지의 설명에서 알 수 있듯이, 과부하 상태가 되면 주로 오라클 내부에서 대기열이 생기며, 애플리케이션의 응답 시간이 악화됩니다(그림 12.11). _230p