|
페이지
|
원문
|
수정문
|
|
018
(그
림1-4)
239
(그
림3-18)
243
(그
림4-1)
345
(그
림5-1)
431
(그
림6-1)
|
Darabase Writer(DBW0)
|
Database Writer(DBWn)
|
|
Archiver(ARC0)
|
Archiver(ARCn)
|
|
1장. 오라클 아키텍처
|
|
062
|
읽는 중에 CR copy를 생성할 필요가 없어 Current 블록을 읽더라도
Consistent 모드에서 읽었다면
‘guery’ 항목에 집계된다.
|
읽는 중에 CR copy를 생성할 필요가 없어 Current 블록을 읽더라도
Consistent 모드에서 읽었다면
‘query
’
항목에 집계된다.
|
|
081
|
이 프로그램이 돌기 시작한지 얼마 지나지 않아 다른 트랜잭션에
의해 홍길동 고객의 수납액이
10,000원에서 20,000원으로 변경되고 나서 커밋되었다.
|
이 프로그램이 돌기 시작한지 얼마 지나지 않아 홍길동 고객의 수납액을 10,000원에서 20,000원으로 변경하고 나서 커밋하였다.
|
|
083
(그
림 1-17)
|
쿼리 SCN 123
|
쿼리 SCN 90
|
|
2장. 트랜잭션과 Lock
|
|
110
|
UPDATE 계좌
SET 잔고 = 잔고 - 50000
, 등급 = 'A'
WHERE 계좌번호 = 123;
|
UPDATE 계좌
SET 잔고 = 잔고 - 50000
WHERE 계좌번호 = 123;
|
|
112
(맨
하단)
|
트랜잰션
|
트랜잭션
|
|
119
(첫
문장)
|
Lock에 때문에
|
Lock 때문에
|
|
121
(하
단에 추가)
|
| 중대한 버그 |
|
본서가 출간되고 2쇄를 시작하기 직전, 방금 설명한 기능(ora_rowscn을 이용한 동시성 제어)에 중대한 버그(Bug
5270479)가 있음을 발견하였다. 트랜잭션이 아래 패턴 1과 같을 때는 정상적인 결과에 이르지만, 패턴 2(--> 두
트랜잭션이 update를 동시에 진행)와 같을 때는 TX1이 TX2의 갱신을 덮어써 Lost Update가 발생하는 버그다.
< 패턴 1 >
< 패턴 2 >
---------------+----+--------------- ----------------+----+---------------
TX1 | |
TX2
TX1 | |
TX2
---------------+----+--------------- ----------------+----+---------------
select ... ; | t1 | select
... ; | t1 |
| t2 | update ... ; |
t2 | update ... ;
| t3 | commit; update
... ; | t3 |
update ... ; | t4 | |
t4 | commit;
---------------+----+--------------- ----------------+----+---------------
안타까운 것은, 11gR2(11.2.0.1)에서도 Bug Fix가 되지 않았다는 사실(Bug 7338384)이다.
결론적으로, (언제일지 모르지만) 버그가 고쳐질 때까지 이 기능을 이용한 동시성 제어를 할 수 없게 되었다. 버그 리포트(Bug
5270479)에서 오라클이 제시하는 대안은 다음과 같다. 즉, 기존 방식대로 동시성 제어를 하라는 뜻이다.
"Include a sequence column in the table and increment that on every
UPDATE then use that in predicates to ensure that the row has not been
modified."
|
|
|
131
|
이제 TX Lock을 획득했으므로 트
랜잭을 위한 일련의 작업들을 수행할 수 있다.
|
이제 TX Lock을 획득했으므로 트
랜잭션을 위한 일련의 작업들을 수행할 수 있다.
|
|
3장. 오라클 성능 관리
|
|
168
|
각 단계에서 읽거나 갱시한
처리 건수
|
각 단계에서 읽거나 갱신한
처리 건수
|
|
173
|
이를 통해 CPU time과 Elapsed time 간에 갭(GAP)이 발생했던 이유를
설명할 수 있다.
|
이를 통해 CPU time과 Elapsed time 간의 갭(GAP), 그리고
사용자가 느낀 총 소요시간과의 갭이 발생했던 이유를 설명할 수 있다.
|
|
187
|
select * from
table(dbms_xplan.display_cursor('[sql_id]',[child_no],'[format)'));
|
select * from
table(dbms_xplan.display_cursor('[sql_id]',[child_no],'[format]'));
|
|
192
|
작업을 수행할 세션과는 별도의
세션을
하나 더 열어 아래 create문을 수행한다.
|
작업을 수행할 세션과 별도로
세션을 하나
더 열어 아래 create문을 수행한다.
|
|
206
|
and t2.col between :range1 and range2 ;
|
and t2.col between :range1 and :range2 ;
|
|
210
(하
단 주석)
|
오라클 8 이전에도 ultbstat/utleatat
스크립트를 이용해 비슷한 리포트를 뽑아볼 수 있었다. |
오라클 8 이전에도 utlbstat/utlestat
스크립트를 이용해 비슷한 리포트를 뽑아볼 수 있었다. |
|
224
(그
림 위 문장)
|
이미 AWR에 쓰여진 된
것이므로... |
이미 AWR에 쓰여진 것이므로... |
|
226
|
본 장에서
설명하려는 ~~
|
본 절에서
설명하려는 ~~
|
|
238
(맨
하단)
|
이를 위해서는 다음 장부터 설명하는 원리들을 십분 이해해고 활용할 수 있어야만 한다. |
이를 위해서는 다음 장부터 설명하는 원리들을 십분 이해하고 활용할 수 있어야만 한다. |
|
5장. 데이터베이스 Call 최소화 원리
|
|
354
(맨
하단)
|
Execute Call이 최대 100만
번, 따라서 최대 200만 번의 데이터베이스 Call이
발생하게 된다.
|
Execute Call이 최대 500만
번, 따라서 최대 600만 번의 데이터베이스 Call이
발생하게 된다.
|
|
402~403
|
(403 페이지 첫 줄에 문자가 겹쳤음. 아래와 같이 수정함)
아래처럼 일반 조인문 또는 스칼라 서브쿼리를 사용할 때만 완벽한 문장수준 읽기 일관성이 보장된다.
# 일반 조인문
select a.지수업종코드
……
|
|
6장. I/O 효율화 원리
|
|
449
(맨
하단)
|
db_block_size는 16이고, Multiblock I/O 단위는 16이다.
|
db_block_size는 8,192이고, Multiblock I/O 단위는 16이다.
|
|
453
(맨
하단)
|
개별 쿼리의 수행 속도를 향상시키는 데 주로 도움을 준다.
|
I/O를 위한 시스템 Call을 줄이고 개별 쿼리의
수행 속도를 향상시키는 데 주로 도움을 준다.
|
|
460
(하
단)
|
~~ 데이터파일에 직접 insert하므로 일반적인 insert와는 비교할 수 없을 정도로
빠르다.
게다가 Direct Path Insert에서는 Redo와 Undo 엔트리를
로깅하지 않도록 옵션을 줄 수도 있어 더 빠른 insert가 가능하다.
|
~~ 데이터파일에 직접 insert하므로 일반적인 insert와는 비교할 수 없을 정도로
빠르다. HWM 바깥 영역에 데이터를 입력하므로 Undo 발생량도 최소화된다(HWM 뒤쪽에 입력한 데이터는 커밋하기 전까지 다른
세션에 읽히지 않으므로 Undo 데이터를 제공하지 않아도 되고, 롤백할 때는 할당된 익스텐트에 대한 딕셔너리 정보만 롤백하면
되기 때문). 게다가 Direct Path Insert에서는 Redo 로그까지
최소화(데이터 딕셔너리 변경사항만 로깅)하도록 옵션을 줄 수도 있어 더 빠른 insert가 가능하다.
|
|
부록
|
|
495
(그
림 7-1)
|
중간에 EMP 테이블(TYPE:TABLE)이 2개
|
오른쪽은 EMP가 아니라 DEPT임
|
