이미 소장하고 있다면 판매해 보세요.
|
Chapter 1 I/O와 디스크의 관계 1
오라클을 이해하기 위한 필수 키워드 2 오라클과 디스크(하드디스크) 3 디스크의 동작 4 데이터를 보증하기 위한 디스크 11 1장 요약 13 Chapter 2 오라클의 여러 프로세스 15 이 책에서의 오라클 그림 16 데이터베이스의 데이터는 모두의 것 18 오라클이 여러 개의 프로세스로 구성된 이유 22 서버 프로세스와 백그라운드 프로세스의 역할 24 각 프로세스가 수행하는 처리 26 2장 요약 29 Chapter 3 캐시와 공유 메모리 31 캐시가 필요한 이유는 무엇인가? 32 캐시란 대체 무엇인가? 33 데이터는 블록 단위로 관리한다 35 캐시의 사용으로 인덱스 검색을 효율적으로 37 프로세스는 캐시를 공유한다 39 공유 메모리에 필요한 설정 41 공유 메모리는 어떤 식으로 보이는가? 43 버퍼 캐시를 정리하는 LRU 알고리즘 45 오라클뿐만이 아닌 OS나 스토리지에 대해서도 생각하자 47 3장 요약 51 Chapter 4 SQL문 분석과 공유 풀 53 SQL문의 분석과 공유 풀은 왜 배우는가? 54 SQL문과 일반적인 프로그래밍 언어의 차이 54 서버 프로세스와 분석 55 최적인 실행 계획을 판단하기 위해서는 57 공유 풀의 동작과 구조 61 수치로 알아보는 분석과 공유 풀의 정보 64 4장 요약 66 Chapter 5 오라클의 기동과 정지 69 기동과 정지를 왜 배워야 하는가? 70 오라클의 기동/정지의 개요 70 업무의 시작에 해당하는 오라클의 기동 71 인스턴스, 데이터베이스, 그리고 주요 파일의 구성 72 기동 처리의 흐름과 내부 동작 75 업무 종료에 해당하는 오라클의 정지 81 수작업으로 데이터베이스 생성하기 83 5장 요약 85 Chapter 6 커넥션과 서버 프로세스의 생성 89 애플리케이션에서의 커넥션을 왜 배워야 하는가? 90 오라클의 커넥션 동작 91 커넥션 동작의 확인 97 정지나 리스너의 상태 확인 99 성능을 개선하려면 100 6장 요약 102 Chapter 7 오라클의 데이터 구조 105 오라클의 데이터 구조는 왜 배워야 하는가? 106 가변 길이 데이터를 관리하기 위한 프로그램 106 오라클의 데이터 구조 109 각 데이터 구조는 어떤 것일까? 113 실제 흐름을 따라 각 동작을 확인해 보자 118 프로세스에서 본 데이터 구조 120 7장 요약 122 Chapter 8 오라클의 대기와 락 125 대기나 오라클의 락을 왜 배워야 하는가? 126 데이터베이스에 락이 필요한 이유 126 대기와 락 대기 129 래치의 구조 135 8장 요약 139 Chapter 9 리두와 언두의 동작 141 리두와 언두를 왜 배워야 하는가? 142 지속성을 구현하기 위해서는 143 리두와 언두의 개념 145 리두의 아키텍처 147 언두의 아키텍처 150 여러 상황에서의 리두와 언두의 동작 152 9장 요약 158 Chapter 10 백업/복구의 아키텍처와 동작 161 백업/복구를 왜 배워야 하는가? 162 백업/복구에 필요한 지식의 복습 162 백업의 종류와 특징 164 데이터베이스 손상의 예 166 기본적인 복구의 종류와 동작 168 기본적인 복구의 흐름(데이터베이스 전체의 복구) 172 리스토어한다 174 그 외의 복구 177 복구한다 178 10장 요약 181 Chapter 11 백그라운드 프로세스의 동작과 역할 183 백그라운드 프로세스를 왜 배워야 하는가? 184 백그라운드 프로세스와 서버 프로세스의 관계 184 DBWR(DBW)의 동작과 역할 190 LGWR의 동작과 역할 194 PMON의 동작과 역할 195 SMON의 동작과 역할 197 ARCH의 동작과 역할 197 그 외의 백그라운드 프로세스 198 11장 요약 201 Chapter 12 오라클 아키텍처와 동작에 관한 Q&A 203 11장까지의 복습 204 오라클의 동작에 관한 질문 207 모니터링/운영에 관한 질문 208 해답과 해설: 오라클의 동작에 관한 질문 209 해답과 해설: 모니터링/운영에 관한 질문 217 정리 220 |
|
오라클의 프로세스가 비정상적으로 종료했다고 해도 데이터는 무사합니다. 이 점이 DBMS와 다른 프로그램과의 차이점 중 하나입니다. 예를 들어, 엑셀(Excel)에서는 저장한 시점 이후의 데이터는 없어집니다. 이미 알고 있듯이, 프로그램이 비정상적으로 종료되거나 전원 버튼을 눌러서 전원을 끊으면 데이터는 없어집니다. _11
일반적으로 캐시를 ‘작업장’이나 ‘작업대’에 비교하는 경우가 많습니다. 여러분이 일할 때 빈번하게 사용하는 도구나 책을 필요할 때마다 서랍이나 책장에서 꺼내어 사용하고, 끝나면 바로 다시 서랍이나 책장에 집어넣는 식으로 사용하는 분은 없으실 것으로 생각합니다. 빈번하게 사용한다면 책상 위나 손이 잘 닿는 곳에 놔둘 것입니다. 캐시의 목적도 이것과 같습니다. _33p 오라클에서는 관리하기 위한 단위로 ‘인스턴스(instance)’라는 용어를 사용합니다. 인스턴스는 ‘백그라운드 프로세스 + 공유 메모리’를 말합니다. 인스턴스라고 하면 객체지향 언어의 경험에서 ‘엔티티(entity)’를 떠올리는 분들도 계실 것으로 생각하지만, 오라클에서는 백그라운드 프로세스 + 공유 메모리입니다. 그림 1의 ‘NOMOUNT’ 상태가 인스턴스가 기동한 상태입니다. 인스턴스는 ‘데이터베이스를 관리하는 것(프로세스 + 메모리)’이며, 데이터베이스가 아닙니다(그림 2). _72p 시스템을 운영하다 보면 많은 시스템에서 데이터베이스 안에 대기가 발생해 성능이 제대로 나오질 않거나 처리가 지연되기도 합니다. 대기의 구조를 제대로 이해하지 않으면 튜닝도 못 하고, 지연을 해소할 수도 없습니다. 나아가 ‘락 대기(lock wait)’, ‘데드락(dead lock)’과 같은 장애를 만날 수도 있습니다. 이런 경우도 대기나 락의 구조를 제대로 이해하고 있지 않으면 대처도 어렵고 애플리케이션 담당자에게 설명하기도 어렵습니다. _126p 백업에는 ‘온라인 백업(핫 백업)’과 ‘콜드 백업’의 두 종류가 있습니다. 콜드 백업은 가장 무난한 백업으로, 인스턴스를 완전히 정지한 상태에서 받는 백업을 말합니다. 모든 데이터가 파일에 기록된(체크포인트 완료) 상태이기 때문에 할 수 있다면 콜드 백업을 받는 편이 간단하고 편합니다. _164p DBWR의 대기 이벤트 ‘rdbms ipc message’는 아이들 상태라는 것을 나타내며, ‘db file parallel write’는 동시에 병렬로 데이터를 디스크에 기록하고 있다는 것을 의미합니다(단, 최근 오라클에서는 기록하고 있는 도중에도 이런 대기 이벤트가 표시되기도 합니다). 단, OS에 따라서는 비동기 I/O를 사용하기 위한 조건이 있어서 실제로는 그림 5와 같이 한 개의 I/O가 끝나고 다음 I/O를 처리하는 형태일 때도 있습니다. ---p.192 |