01 주차 정리 내용 - 김영승

[김영승]

(한글 파일엔 사진 나옴)

1주차 정리 내용 – 김영승

핵심 내용은 6절, 7절 (용현이 형)

오라클 만의 독특한 consistent 모드 읽기를 집중적으로 해부하고, current모드 읽기와의 차이점을 명확히 밝힌다.

Chapter 1. 오라클 아키텍처

01. 기본 아치텍처

오라클은 데이터베이스(데이터를 저장하는 파일 집합)와 이를 액세스하는 프로세스 사이에

*SGA라고 하는 메모리 캐시 영역을 두고 있다.

많은 프로세스가 동시에 데이터를 액세스 하므로 사용자 데이터를 보호하는 Lock은 물론

공유 메모리 영역인 SGA상에 위치한 데이터 구조에 대한 엑세스를 직렬화하기 위한

LOCK 매커니즘(=래치, Latch, library cache)이 필요

=> 동시에 한 데이터에 두 개의 프로세스가 접속하여 한쪽에서는 수정 한쪽에선 읽기를

할 경우 데이터는 이미 변경 되어 있으나 같은시점 다른 프로세스가 읽은 데이터는

수정 전 데이터를 읽음으로서 읽기 일관성이 깨진다.

오라클은 블록단위로 읽고, 저장할 때도 변경이 발생한 블록만 찾아 블록 단위로 저장.

오라클은 백그라운드에서 DBWR(Database writer)와 *CKPT(CheckPoint) 프로세스가 캐시와 데이터 파일 간 동기화를 주기적으로 수행

데이터베이스 = 디스크에 저장된 데이터 집합(datafile, redo log file, control file 등)

인스턴스 = SGA공유 메모리 영역 + 엑세스하는 프로세스

서버 프로세스

=> SQL을 파싱하고 필요하면 최적화를 수행하며, 커서를 열어 SQL을 실행하면서 블록을

읽고, 읽은 데이터를 정렬해서 클라이언트가 요청한 결과집합을 만들어 네트워크를 통해

전송하는 일련의 작업을 처리

리스너(Listener)에 연결요청을 하는 순간 하나의 프로세스를 띄우고(fork)

PGA(Process Global Area = 서버 프로세스만을 위한 독립적인 메모리 공간)

메모리를 할당 => 비용이 크므로 일련의 SQL문을 수행할 때 마다 연결 요청은 비효율

=>커넥션 풀(Connection Pool)을 이용한다.

: 한번 커넥션을 맺으면 작업을 완료하더라도 이를 해제하지 않고 애플리케이션 서버에 Pooling 하고 있다가 반복 재사용한다.

02. DB 버퍼 캐시 : 한번 읽은 데이터 블록을 캐싱해 두는 메모리 공간

(1) 블록 단위 I/O

-인덱스를 경유한 테이블 액세스 시에는 한 번에 한 블록씩

-Full Scan, DBWR dirty 블록 처리 시에는 성능 향상을 위해 한 번에 여러 개 블록씩

옵티마이저가 인덱스를 이용한 테이블 엑서스를 할지 아니면 Full Table Scan 할지의

판단기준(레코드의 수 X)

(2) 버퍼 캐시 구조

출처: http://mydblife.blogspot.kr/2011/01/workshop-data-buffer-cache.html

데이터가 입수되는 시점이 다르므로 바둑판 모양을 이루게 됨

해시 테이블 구조로 관리 : key와 value가 하나의 쌍을 이루는 자료구조

해시 버킷 : Hash Key를 포함한 슬롯의 모임

해시 체인: 데이터 블록 주소를 해시함수에 입력해 리턴 받은 해시 값이 같은 블록들을 같은 해시 버킷에 연결리스트 구조로 연결될 때 각각의 연결리스트

버퍼 캐시에 해당 데이터가 없을시 디스크에서 읽어 해시 체인에 연결한 후 읽는다(재사용성)

버퍼 헤더(포인터)만 체인에 연결되어 관리

(3) 캐시 버퍼 체인

해시 체인은 래치(Latch)에 의해 보호

래치(Latch) => 여러 프로세스에 의한 동시 엑세스를 방지를 위한 직렬화를 위한 일종의 Lock 매커니즘

래치를 획득한 프로세스만이 그 래치에 의해 보호되는 자료구조로의 진입이 허용

Cache buffers chains : 버퍼 캐시에 연결된 체인구조를 보호

Cache buffers chains 래치는 여러 개의 해시 체인(32개의 버킷을 관리)을 동시에 관리

+ 버퍼 캐시의 크기와 버전에 따라 달라짐

하나의 체인에 하나의 버퍼만 달리는 것이 이상적

9i부터 읽기전용 작업(해시 체인을 스캔하면서 필요한 블록을 찾는 작업)일 때는 cache buffers chains 래치를 획득 => select문장을 동시에 수행하면 래치경합이 발생

(4) 캐시 버퍼 LRU 체인

버퍼의 상태

- LRU(least recently used)알고리즘

: 버퍼 캐시가 사용빈도가 높은 데이터 블록들 위주로 구성 될 수 있도록 함

-LRU 체인에 연결 해 사용빈도 순으로 정렬되어 있다가 추가 메모리가 필요 할때마다

사용빈도가 낮은 버퍼 블록 헤더를 없앰

LRU 내의 두 개의 리스트

Dirty 리스트(LRUW리스트 = LRU Write)

=> 캐시 내에서 변경 됐지만, 아직 디스크에 기록되지 않은 Dirty 버퍼 블록들

2. LRU 리스트 : 캐시와 디스크의 데이터 상대가 동일한 버퍼 블록들(Free 버퍼)

읽기 또는 쓰기 작업을 위해 핵세스 되는 동안에는 리스트에서 잠시 풀려남(Pinned 버퍼)

+ LRU 리스트를 보호하는 래치 => cache buffers lru chain 래치

03. 버퍼 Lock

(1) 버퍼 Lock 이란?

래치를 해제 하지 않으면 하나의 cache buffers chains 래치에 여러 개의 해시 체인이

달렸으므로(Cache buffers chains 래치는 여러개의 체인을 관리) 래치에 대한 경합이 발생 할수 있으므로 래치를 해지 해야 하는데 해당 버퍼가 다른 프로세스에 의해 사용 중일 때

래치를 해제 하면서도 하나의 버퍼를 두 개의 프로세스가 접근 하지 못하게 막기 위하여 사용

-버퍼 내용을 읽기만 할 때 share모드 lock

-버퍼 내용을 변경 할 때 Exclusive모드 lock

래치를 획득하고 버퍼를 찾았으나 다른 프로세스가 버퍼 lock을 exclusive 모드로 점유한 채 내용을 갱신 중일 때

=> 버퍼 해더에 있는 버퍼 lock 대기자 목록에 자신을 등록하고 래치를 해제

버퍼 lock 대기자 목록에 등록 돼 있는 동안 buffer busy waits 대기 이벤트 발생

출처 : http://wiki.gurubee.net/pages/viewpage.action?pageId=3900104

버퍼 lock을 획득하여 원했던 작업을 진행 한 후 lock 해제 시 해당 버퍼 해더를 엑세스 하려는 다른 프로세스와의 충돌이 생길 수 있으므로 다시 해당 버퍼가 속한 체인 래치를 획득한 후 lock을 해제 후 래치 해제

(2) 버퍼 핸들

버퍼 lock (= 버퍼 pin)

변경 시에는 하나의 프로세스만 Pin을 설정 할 수 있지만 읽기작업을 위해서라면 여러 개 프로세스가 동시에 Pin을 설정할 수 있다.

버퍼 핸들(Buffer Handle): 버퍼 해더에 Pin을 설정 하려고 사용하는 오브젝트

pin설정시 버퍼 핸들을 얻어 버퍼 헤더에 있는 소유자 목록(Holder List)에 연결시키는 방식

cache buffer handles 래치 : 버퍼 핸들을 얻으려고 사용 하는 래치

버퍼를 Pin하는 오퍼레이션이 많을수록 오히려 cache buffer handles 래치가 경합지점이 되므로 각 프로세스 마다 _db_handles_cached 개수 만큼의 버퍼 핸들을 미리 할당(default 5)

-각 세션은 이를 캐싱하고 있다가 'Buffer Pin'을 할 때마다 사용하며, 추가로 필요할 때 'cache buffer handles' 래치를 얻고 추가로 버퍼 핸들을 할당받음

(3) 버퍼 Lock 의 필요성

DML Lock 과 블록 Lock을 획득해야 하는 이유

=> 하나의 레코드를 갱신하더라도 블록 단위로 I/O를 수행하기 때문

ex 1) 해당 블록의 로우를 변경하는 도중 다른 프로세스가 해당로우를 검색하면 잘못된 값이 검색 됨

ex 2) 두 개의 프로세스가 동시에 로우 단위 lock을 설정하려고 시도 할 때

(로우 lock 시도도 일종의 레코드 속성 변경)

+ Pin된 버퍼 블록은 버퍼 캐시 전체를 비우려고 해도 밀려나지 않는다.

(4) 버퍼 Pinning

같은 블록을 반복적으로 읽을 때 래치 획득 과정을 생략하여 속도를 증가시키고 싶을 때 버퍼를 읽고 나서 버퍼 Pin을 즉각 해제하지 않고 유지함

버퍼 Pinning은 하나의 데이터베이스 Call 내에서만 유효함

출처 : http://cafe.naver.com/ocmkorea/book3846732/14417

04. Redo

모든 변경 사항의 로그 기록

구성

Online Redo

Redo로그 버퍼에 버퍼링된 로그 엔트리를 기록하는 파일

최소 2개이상의 파일로 구성 하여 현제 사용중인 Redo 로그 파일이 꽉차면 다음 Redo로그 파일로 스위칭 하며 모든 Redo로그 파일이 꽉 차면 다시 첫 번째 Redo로그 파일에 쓰는 라운드 로빈 방식으로 사용

2.Archived(=Offline)Redo 로그

2번째 Redo로그파일이 꽉차기 전에 1번째 로그파일을 다른 위치로 백업해둔 파일

-목적

Database Recovery

물리적으로 디스크가 깨지는 등의 Media Fail 발생 시 데이터 베이스를 복구하기 위해 사용 => Archived Redo 로그를 이용 (Media Recovery)

Cache Recovery

Cache Recovery(= Instance Recovery)

: 성능 향상을 위해 버퍼 캐시를 도입하나 이는 휘발성이므로 캐시에 저장된 변경하항이

디스크 상의 데이터 블록에 아직 기록되지 않은 상태에서 정전 등이 발생해 인스턴스가 비정상적으로 종료되면, 그때까지의 작업내용을 모두 잃게 될 때의 Recovery

Checkpoint 이후부터 roll forward -> Undo(roll back)

Fast Commit

우선 변경사항을 빠르게 로그파일에 기록하고 redo로그를 믿고 빠르게 커밋을 완료 처리

redo 레코드를 기록할 때도 곧바로 Redo 로그 파일에 저장하는 것이 아니라 먼저 Redo로그 버퍼에 기록 한후 저장됨, 저장 될 때 LGWR 프로세스에 의해 Redo 로그 버퍼에 있는 내용을 Redo 로그에 기록

LGWR의 Redo로그 버퍼 기록 시점

3초바다 DBWR 프로세스로부터 신호를 받을 때

롤백시 커밋하지 않은 내용을 Redo로그에 없는 내용이 데이터 파일에 기록돼 있으면 사용자가 커밋하지 않은 데이터가 커밋 되는 결과가 발생함

로그 버퍼의 1/3이 차거나 기록된 Redo 레코드량이 1MB를 넘을 때

사용자가 커밋 또는 롤백 명령을 날릴 때

05. Undo(Rollback)

각 트랜잭션(작업) Undo 세그먼트를 할당(다수의 작업을 하나의 Undo 세그먼트에 할당가능)하여 해당 트랜잭션이 발생시킨 테이블과 인덱스에 대한 변경사항들을 Undo 레코드 단위로 Undo세그먼트 블록에 차곡차곡 기록

AUM(Automatic Undo Management)

Undo 세그먼트 수를 오라클이 자동관리(세그먼트와 트랜잭션이 1:1로 할당되는 것이 목표)

Undo세그먼트가 없을시 적게 사용되는 Undo 세그먼트 중 하나를 할당

목적

1. Transaction Rollback

트랜잭션에 의한 변경사항을 최종 커밋하지 않고 롤백하고자 할때

2. Transaction Recovery(Instance Recovery 시 rollback 단계)

Redo로 복원 후 커밋 되지 않은 상태로 되돌릴 때

-출처: http://wiki.gurubee.net/display/STUDY/1st_Undo

3. Read Consistency

읽기 일관성(Read Consistency)을 위하여 (다음주에 자세히)

(1) Undo 세그먼트 트랜잭션 테이블 슬롯

-Undo 세그먼트 중 첫 번째 익스텐트, 첫 번째 블록에는 Undo 세그먼트 헤더 정보

-Undo 세그먼트 헤더에는 트랜잭션 테이블 슬롯(Transaction Table Slot)이 위치

각 슬롯에 기록되는 사항들

1. 트랜잭션 ID

- 트랜잭션 ID는 [USN# + Slot# + Wrap#]으로 구성된다.

- USN은 Undo Segment Number의 약자다

2. 트랜잭션 상태정보(Tranaction Status)

- 트랜잭션을 시작하려면 먼저 Undo 세그먼트에 있는 트랜잭션 테이블로부터 슬롯(solt)을 할당받아야

하며， 할당받은 슬롯에 자신이 현재 Active 상태임을 표시

- undo segment tx slot

=>트랜잭션 슬롯을 곧바로 얻지 못해 이용 가능한 슬롯이 생기기를 기다릴 때 발생하는 대기 이벤트

3. 커밋 SCN(커밋된 경우)

4. Last UBA(Undo Block Address)

트랜잭션의 기록사항들을 가장 마지막 Undo 레코드 뒤에 계속 추가해 나가려고 유지하는 일종의 포인터

각 Undo 레코드 간에는 체인형태로 연결되어 있어 데이터를 롤백하고자 할 때 이 체인을 따라 거슬러 올라가며 작업을 수행

5. 기타

각 DML 오퍼레이션 별로 Undo 레코드에 기록되는 내용

Insert : 추카된 레코드의 rowid

Update : 변경되는 컬럼에 대한 before image

Delete : 지워지는 로우의 모든 컬럼에 대한 before image

+ insert 또는 delete 시에는 인덱스 하나당 하나의 Undo레코드가 추가,

update시에는 내부적으로 delete & insert 방식으로 수행되기 때문에 두 개의 레코드 추가

commit 되기 전에는 절대로 재사용 되지 않으며 commit시 상태정보를 committed으로

바꾸고 커밋 SCN을 트랜잭션 슬롯에 저장해 둔 후 재사용됨 (먼저 커밋된 순서대로 )

(2) 블록 헤더 ITL 슬롯

Undo 세그먼트 헤더에 트랙잭션 테이블 슬롯이 있다면 각 데이터 블록과 인덱스 블록 헤더에는 ITL(Interested Transaction List)이 있음

ITL : Block Header 내부 Transaction 정보를 관리하는 List 자체

-출처 : http://blog.naver.com/PostView.nhn?blogId=senda2&logNo=140049739403

① ITL 슬롯 번호

② 트랜잭션 ID

③ UBA (Undo Byte Address)

④ 커밋 Flag

⑤ Locking 정보

⑥ 커밋 SCN

- 특정 블록에 속한 레코드를 갱신하려면 먼저 블록 헤더로부터 ITL 슬롯을 확보해야한다.

그후 트랜잭션 ID를 기록하고 현재 해당 트랜잭션이 Active 상태임을 표시한 후라야 블록 갱신 가능

ITL 슬롯을 할당 받지 못하면 트랜잭션은 계속 진행하지 못하고 블로킹됨

블록킹 현상을 최소화 하는 3가지 옵션

initrans

=> 블록을 사용하려고 처음 포맷할 때 블록 헤더에 ITL 슬롯 할당 수를 정하는 파라미터

maxtrans

=> 미리 할당한 ITL 슬롯이 모두 사용 중이라면 maxtrans로 지정된 개수 만큼 영역에 추가

pctfree

=> 예약된 공간

ITL을 할당받지 못해 Lock 경합이 발생

(ITL 슬롯이 부족할 때 발생하는 대기 이벤트(willl event)가 enq: TX - al10cate ITL entry)

=> 자세한 사항은 2장 이은규가 발표

(3) Lock Byte

-오라클 레코드가 저장되는 로우마다 그 헤더에 Lock Byte를 할당해 로우를 갱신 중인 트랜잭션의 ITL 슬롯 번호를 기록해 둔다 => 로우 단위 LOCK

로우단위 Lock + 트랜잭션 Lock(TX Lock) = 로우 Lock

트랜잭션 Lock : 레코드 갱신시 대상 레코드의 Lock Byte가 활성화 => ITL 슬롯

=> 트랜잭션 테이블 슬롯의 활성화(active) => 대기

자세한건 2장에서 => 이은규

*참고자료 SGA

SGA(System Global Area 또는 Shared Global Area)

- 오라클 서버의 메모리 영역

- 오라클의 인스턴스에 대한 데이터와 제어정보를 가지는 공유 메모리 영역의 집합

- 전체 SGA를 실제 메모리 크기가 허용하는 범위에서 가장 크게 잡으면 디스크 I/O를

줄이고 메모리에 가능한 많은 데이타를 저장 할 수 있으므로 최적의 성능을 낼 수 있다.

- SGA는 공유 풀(Shared Pool), 데이터베이스 버퍼캐쉬(Database Buffer Cache),

리두버퍼로그(Redo Log Buffer) 와 LARGE POOL , JAVA POOL로 구성 되어 있다.

1. 공유 풀(Shared Pool)

Shared Pool은 Library Cache와 데이터 사전 캐쉬(Data Dictionary Cache)로 구성

Shared Pool은 하나의 데이타베이스에 행해지는 모든 SQL 문을 처리하기 위하여 사용

Shared Pool은 문장을 실행하기 위해 그 문장과 관련된 실행 계획과 구문분석 정보 저장

Shared Pool의 사이즈는 SHARED_POOL_SIZE 파라미터 값으로 결정합니다.

① Library Cache

라이브러리 캐쉬는 가장 최근에 사용된 SQL 문장의 명령문과, 구문 분석 트리, 실행계획 정보를 저장

Shared SQL과 Shared PL/SQL 영역으로 구분되어 있습니다.

Shared SQL 영역 : SQL문장에 대한 실행계획과 파싱 트리를 저장하고 공유 합니다. 동일한 문장이 다음번에 실행되면 Shared SQL 영역에 저장되어 있는 실행계획과 파싱 트리를 그대로 이용하기 때문에 SQL 문장의 처리 속도는 향상 됩니다.

Shared PL/SQL 영역 : 가장 최근에 실행한 PL/SQL 문장을 저장하고 공유 합니다. 파싱 및 컴파일 된 프로그램 및 프로시져(함수, 패키지, 트리거)가 저장 됩니다.

② Data Dictionary Cache

테이블, 컬럼, 사용자 이름, 사용 권한 같은 가장 최근에 사용된 데이터 사전의 정보를 저장

구문 분석 단계에서 서버 프로세스는 SQL문에 지정된 오브젝트 이름을 찾아내고 접근 권한을 검증하기 위해 Dictionary Cache의 정보를 찾아봅니다

2. 데이터베이스 버퍼 캐쉬(DataBase Buffer Cache)

데이터베이스 버퍼 캐쉬는 가장 최근에 사용된 데이타를 저장하는 메모리 공간

이 버퍼는 아직까지 디스크에 완전히 쓰여지지 않는 수정된 데이타를 보유할 수도 있습니다.(Drity Block?)

LRU 알고리즘에 의하여 가장 오래전에 사용된 것은 디스크에 저장하고 메모리에는 가장 최근에 사용된 데이타를 저장 함으로, 디스크 입출력이 줄어 들고, 데이타베이스 시스템의 성능이 증가 됩니다.

LRU(least recently used) 알고리즘 : 최근에 사용된 블록을 유지하기 위해 오래된 것을 제거하는 알고리즘. (책에 나오는 버퍼 LRU 체인)

3. 리두 로그 버퍼(Redo Log Buffer)

리두 로그 버퍼는 데이터베이스에서 일어난 모든 변화를 저장하는 메모리 공간 입니다.

DB에서 발생한 모든 변화는 LGWR에 의해 리두 로그 파일에 저장 합니다.

리두 로그 버퍼는 Database의 변경 사항 정보를 유지하는 SGA에 있는 Circular(순환) 버퍼 입니다

Redo Log Buffer의 크기는 오라클 파라미터 LOG_BUFFER에서 지정합니다.

4. Java Pool과 Large Pool

Java Pool

Java Pool은 자바로 작성된 프로그램을 실행할 때 실행 계획을 저장하는 영역 입니다.

Java Pool은 JAVA_POOL_SIZE 파라미터로 관리되며, 기본 크기 24MB가 할당 됩니다.

Large Pool

Large Pool은 Oracle 백업 및 복원 작업에 대한 대용량 메모리 할당, I/O 서버 프로세스 및 다중 스레드 서버와 Oracle XA에 대한 세션 메모리를 제공하는 SGA의 선택적인 영역입니다

Large Pool은 LARGE_POOL_SIZE 파라미터로 관리되며, 기본 크기는 0 bytes 입니다.

출처: http://www.gurubee.net/lecture/1854

*참고자료 Checkpoint ( CKPT )

Checkpoint

: 데이터 정합성 유지

: 데이터 버퍼 캐쉬의 변경된 데이터 블록을 데이터 파일에 기록,

메모리 내의 데이터와 데이터 파일에 저장된 데이터를 일치시키는 일련의 작업.

CKPT의 절차 및 활동 주기

체크포인트 큐 ( CKPT Queue )

: 변경된 데이터 블록의 주소 값을 저장하고 있으며,

체크포인트가 발생하면 큐 안에 존재하는 변경된 데이터 블록을

DBWR 이 데이터 파일로 기록하게 된다.

체크포인트 번호 ( CKPT NO )

: 데이터의 정합성을 비교하는 기준.

: 체크포인트 번호는 컨트롤 파일과 모든 데이터 파일 헤더에 지속적으로 기록되고,

데이터베이스 오픈시에 체크포인트 번호가 일치하지 않으면 데이터베이스 복구 절차를 수행해야만 오픈된다.

-- 정합성 유지

체크포인트의 활동 주기

로그 스위치가 발생하는 경우

3초마다 발생

테이블스페이스가 오프라인으로 변경될 경우

데이터베이스가 정상 종료

ALTER SYSTEM CHECKPOINT 로 유저 체크포인트 발생시

파라메터에서 정한 값에 의해 활동 주기가 되었을 경우

-- FAST_START_MTTR_TARGET 파라메터 값은 sec 단위이다.

[출처] http://dkseth.blog.me/130092417464

-옵티마이져(Optimizer)란?

옵티마이져는 입력된 SQL을 Parsing 하여 Soft Parsing 하거나 Hard Parsing 하여 실행계획을 세우는 일을 한다.

SQL( Structured Query Language ): 데이타베이스를 조작하기 위한 언어

Parsing: 문법적 오류 검사 및 필요한 객체가 실존하는지 여부를 확인하여 문제가 있다면 에러메시지를 반환하고 종료하는 과정

Soft Parsing: 해당 쿼리를 실행했던 적이 있어 Shared Pool에 있다면 그것을 실행

Hard parsing: 쿼리에 쓰여진 객체의 접근가능성을 검사하고 실행계획을 수립gks enl Shared Pool에 저장하고 실행

출처 : http://bluekms21.blog.me/10182558698

-Append / Logging

http://cafe.naver.com/prodba/1105

You Asked (Jump to Tom's latest followup)

Tom

I've been re-visiting my knowledge on NOLOGGING as a colleague asked me a

question about it today and I hate to say I couldn't remember fully why the term

is a tiny bit of a misnomer (there's no denying that there is a general

confusion "out there" about NOLOGGING and its consequences for redo generation,

recoverability etc.).

Anyway, with NOLOGGING "switched" on for already created tables and indexes, it

seems that all DML is logged unless you use direct path in some way. If I have a

NOLOGGING table and INSERT without /*+ APPEND */ I get logging, and if I have a

LOGGING table and INSERT with /*+ APPEND */ I get logging. I only get no logging

when I have a NOLOGGING table with /*+ APPEND */.

But I'm not sure about ALTER TABLE MOVE and ALTER INDEX REBUILD. If I leave the

tables and indexes in NOLOGGING mode and then perform either of these rebuilds

without specifying the NOLOGGING clause in the ALTER statement, will the action

be logged? If the answer is yes, then would it make sense just to leave all

tables and indexes in NOLOGGING mode anyway?

Regards

Adrian

and we said...

It is even more deep then that. For example:

Table Mode Insert Mode ArchiveLog mode result

----------- ------------- ----------------- ----------

LOGGING APPEND ARCHIVE LOG redo generated

NOLOGGING APPEND ARCHIVE LOG no redo

LOGGING no append "" redo generated

NOLOGGING no append "" redo generated

LOGGING APPEND noarchive log mode no redo

NOLOGGING APPEND noarchive log mode no redo

LOGGING no append noarchive log mode redo generated

NOLOGGING no append noarchive log mode redo generated

(geez -- I hope i got that table right! AND the table changes for 9iR2 which

can be run in "FORCE LOGGING" mode meaning the 4th column ALWAYS say "redo

generated")

Basically -- if you change Insert Mode to "UNRECOVERABLE OPERATION" -- the table

is the same (eg: are you performing an operation which MIGHT be able to be done

without redo generation)....

It will only NOT generate redo in the 3 cases above:

o Object is NOLOGGING and database is ARCHIVE LOG

o Object is either NOLOGGING or LOGGING and database is NO ARCHIVE LOG

NO NO NO -- it does not make sense to leave objects in NOLOGGING mode in a

production instance!!!! it should be used CAREFULLY, and only in close

coordination with the guys responsible for doing backups -- every non-logged

operation performed makes media recovery for that segment IMPOSSIBLE until you

back it up.

-출처 

[페르디안]

그림이 안보여 ㅋㅋ

[김영승]

미완성 분이였어요 마지막장 부터 3장이 하일라이였네요 ㄱ=...