03 주차 정리 내용 - 이은규

[이은규]

03주차 정리

09.Snapshot too old

-snapshot too old를 조회해보면 두 가지로 정리된다.

->첫째, Undo 블록이 다른 트랜잭션에 의해 이미 재사용돼 필요한 Undo 정보를 얻을 수 없는 경우

->둘째，커밋된 트랜잭션 테이블 슬롯이 다른 트랜잭션에 의해 재사용돼 커밋 정보를 확인할 수 없는 경우

(1) Undo 실패

-Undo 블록을 찾을 수 없어 에러가 발생하는 경우

1.쿼리 실행

2.실행이 되는 중에 커밋이 일어나서 SCN이 변경이 됩니다.

3. 쿼리가 실행이 완료되고 SCN을 확인 하였을 때 SCN 값이 실행되었을 때 맞지 않음

4.트랜잭션이 재사용되어서 에러가 발생된다.

(2) 블록 클린아웃 실패

-대량 업데이트 후에 커밋된 트랜잭션은 변경했던 블록들을 모두 클린아웃하지 않은 상태에서 자신이 사용하던 트랜잭션 테이블 슬롯을 Free 상태로 변경하고 트랜잭션을 완료

-트랜잭션 테이블 슬롯은 다른 트랜잭션에 의해 재사용될 수 있다.

-시간이 흘러 그 변경된 블록들이 읽혀야 하는 시점에 Delayed 블록 클린아웃을 위해 트랜잭션 테이블 슬롯을 찾아갔는데, 해당 슬롯이 다른 트랜잭션에 의해 이미 재사용되고 없다면 정상적인 블록 클린아웃과 일관성 모드 읽기가 불가능해질 수 있다.

- Delayed 블록 클린아웃에 의해 Snapshot too old가 발생하는 원인은, ‘최저 커밋 SCN’이 쿼리 SCN보다 높아질 정도로 갑자기 트랜잭션이 몰리는 데에 있으며, 이때는 추정에 의한 블록 SCN이 쿼리 SCN보다 높아지게 된다. 

(3) Snapshot too old 회피 방법

1. 불필요하게 커밋을 자주 수행하지 않는다.

2. fetch across commit 형태의 프로그램 작성을 피해 다른 방식으로 구현한다 ANSI 표준에 따르면 커밋 이전에 열려 있던 커서는 더는 Fetch 하면 안 된다.

3. 트랜잭션이 몰리는 시간대에 오래 걸리는 쿼리가 같이 수행되지 않도록 시간을 조정한다.

4. 큰 테이블을 일정 범위로 나누어 읽고 단계적으로 실행할 수 있도록 코딩한다.

Snapshot too old 발생 가능성을 줄일 뿐 아니 라 문제가 발생했을 때 특정 부분부터 다시 시작할 수도 있어 유리하다.

물론 그렇게 해도 읽기 일관성에 문제가 없을 때 에만 적용해야한다.

5. 오랜 시간에 걸쳐 같은 블록을 여러 번 방문하는 Nested Loop 형태의 조인문 또는 인덱스를 경유한 테이블 액세스를 수반하는 프로그램이 있는지 체크하고， 이를 회피 할 수 있는 방법을 찾는다.

6. 소트 부하를 감수하더라도 order by 등을 강제로 삽입해 소트연산이 발생하도록 한다.

많은 데이터를 오랜 시간에 걸쳐 Fetch 하는 동안 Undo 정보를 지속적으로 참조하기 때문에 문제가 발생하는 것이므로. 서버 내에서 빠르게 데이터를 읽어 Temp 세그먼트에 저장하는 데에만 성공하면 이후에는 같은 블록을 아무리 재방문하더라도 더는 에러가 발생할까 걱정하지 않아도 된다.

7. 만약 delayed 블록 클린아웃에 의해 Snapshot too old가 발생하는 것으로 의심되면 대량 업데이트 후에 곧바로 해당 테이블에 대해 Full Scan 하도록 쿼리를 날리는 것 도 하나의 해결방법이 될 수 있다.

10.대기 이벤트

(1) 대기 이벤트란?

-오라클 인스턴스는 분업사회처럼 프로세스들이 역할을 분담해서 맡은 바 임무를 수행한다.

-함께 일을 하는 동안 프로세스 간 커뮤니케이션과 상호작용이 필요하고 때로는 다른 프로세스가 일을 마칠 때까지 기다려야만 하는 상황이 자주 발생한다. 그러면 오라클 프로세스는 일을 계속 진행할 수 있는 조건이 충족 될 때까지 수면상태에 빠지는데 이런 현상이 발생하는 것을 대기 이벤트라고 부른다. 그리고 그때마다 오라클은 그 상태정보를 파일 또는 SGA 메모리 내에 저장해둔다.

-대기 이벤트는 원래 오리클 개발자들이 디버깅 용도로 개발한 것이라고 한다.

(2) 대기 이벤트는 언제 발생할까?

-대기 이벤트가 발생하게 되는 상황

1. 자신이 필요로 하는 특정 리소스가 다른 프로세스에 의해 사용 중일 때

2. 다른 프로세스에 의해 선행 작업이 완료되기를 기다릴 떄

3. 할 일이 없을 떄

(3) 대기 이벤트는 언제 사라질까?

-오라클 프로세스가 자신이 작업을 진행할 대 선행 프로세스가 먼저 점유하여 대기 상태에 빠질 경우 선행작업이 끝나고 나서 자신에게 알려주어 일을 진행하거나, 타이머에 설정된 시간에 깨어나 선행 프로세스가 작업을 모두 마쳤는지 확인할 때 사라짐

-대기 중이 던 프로세스가 활동을 재개하는 시점

1. 대기 상태에 빠진 프로세스가 기다리던 리소스가 시용 가능해 지거나

2. 작업을 계속 진행하기 위한 선행 작업이 완료되거나

3. 해야 할 일이 생겼을 때

(4) 래치와 대기 이벤트 개념 명확화

-래치를 얻는 과정 자체가 경합을 의미하지는 않는다. 공유된 자원을 읽으려면 래치를 얻는 것이 당연한 일이므로 v$latch 뷰 에서 gets 횟수가 증가한다고 해서 문제 될 것은 없다. 다만 래치를 얻는 과정 중 에서 다른 프로세스와 경합이 발생하는지를 관심 있게 살펴봐야 하며, 마약 그렇다면 시스템 동시성이 저하되므로 문제다.

11. Shared Pool

- SGA의 가장 중요한 구성요소 중 하나

-Shared Pool은 크게 딕셔너리 캐시 와 라이브러리 캐시로 나뉜다.

(1) 딕셔너리 캐시

-말 그래로 오라클 딕셔너리 정보를 저장해 두는 캐시영역으로서 Row 단위로 읽고 쓰기 때문에 '로우 캐시(Row Cache)' 라고도 불린다.

-테이블, 인덱스 같은 오브젝트는 물론 테이블 스페이스, 테이터파일, 세그먼트, 익스텐트, 사용자, 제약, Sequence, DB Link에 과한 정보들을 캐싱한다.

(2) 라이브러리 캐시

- 라이브러리 캐시는 사용자가 던진 SQL과 그 실행계획을 저장해 두는 캐시영역

- 하드 파싱 : 쿼리 구문을 분석해서 문법 오류 및 실행 권한 등을 체크하고, 최적화 과정을 거쳐 실행 계획을 만들고, SQL 실행 엔진이 이해할 수 있는 형태의 포맷팅하는 전 과정을 하드 파싱으로한다.

-소프트 파싱 : 반복적인 하드 파싱을 최소화하기 위한 새로운 캐시 공간을 두게 되었고, 바로 라이브러리 캐시 영역

02 트랜잭션 Lock

01 트랜잭션 동시성 제어

(1) 동시성 제어

-동시에 실행되는 트랜잭션 수를 최대화 하면서도 입력, 수정, 삭제, 검색시 데이터의 무결성이 유지될수 수 있도록 노력하는 것을 말한다.

-여러개의 트랜잭션이 동시에 수행될 때, 테이터베이스 애플리케이션은 이들 트랜색션이 서로 간섭을 일으키는 현상을 최소화 하면서 데이터의 일관성과 무결성이 보장되도록 개발되어야 한다.

-동시성 : 다중 사용자가 같은 테이터를 동시에 액세스

-일관성 : 자시이 발생시킨 변경사항과 다른 트랜잭셔의 변경 사항( 읽을 수 있는 버전만 허용)을 포함해 일관성 있는 상태로 데이터를제공

(2) 트랜잭션이란?

-여러 개의 수정작업이 하나의 작업처럼 전부 처리되거나 아예 전부 처리가 안 되도록(ALL or Nothing)하는 것인데, 이러한 일의 최소 단위가 트랜잭션이다.

(3) 트랜잭션의 특징(ACID)

-원자성(Atomicity) : 트랜잭션의 더이상 분해가 불가능한 업무의 최소단위

-일관성(Consistency) : 트랜잭션 실행의 결과로 데이터베이스 상태가 모순되지 않도록 하는 것

-격리성(Isolation) : 트랜잭션이 실행 중에 생성하는 연산의 중간 결과는 다른 트랜잭션이 접근할 수 없다.

-영속성(Durability) : 트랜잭션이 일단 그 실행을 성공적으로 완료하면 그 결과는 데이터베이스에서 영속적으로 저장된다.

02 트랜잭션 수준 읽71 일관성

(1) 트랜잭션 수준 읽기 일관성이란?

-문장수준 읽기 일관성(Statement-Level Read Consistency) : 쿼리가 시작된 시점을 기준으로 테이터를 일관성 있게 읽어들이는 것을 말함

-트랜잭션 수준 읽기 일관성(Transaction-Level Read Consistency) : 트랜잭션이 시작된 시점을 기준으로 일관성 있게 데이터를 읽어 들이는 것을 말함.

-오라클은 완벽한 문장수준의 읽기 일관성은 보장하나 트랜잭션에 대해서는 기본적으로 보장하지 않는다.

(2) 트랜잭션 고립화 수준

-DBMS마다 구현방식이 달라 본서에서 자세히 다루는 것은 적절치 않다고 생각한다.

-ANSI/ISO SQL standard(SQL192)

레벨 0(= Read Uncommitted)

-트랜잭션에서 처리 중인/ 아직 커밋되지 않은 테이터를 다른 트랜잭션이 읽는 것을 허용.

-Dirty Read, Non-Repeatable Read, Phantom Read 현상 발생

-오라클은 이 레벨을 지원하지않음

레벨 1(=Read Committed)

-Dirty Read 방지 : 트랜잭션이 커밋되어 확정된 테이터만 읽는 것을 허용

-대부분의 DBMS가 기본모드로 채택하고 있는 일관성 모드

-DB2, SQL Server, Sybase의 경우 읽기 공유 Lock을 이용해서 구현, 하나의 레코드을 읽을 때 Lock을 설정하고 해당 레코드를 빠져 나가는 순간 Lock 해제

-Oracle은 Lock을 사용하지 않고 쿼리시작 시점의 Undo 데이터를 제공하는 방식으로 구현

레벨 2(-Repeatable Read)

-선행 트랜잭션이 읽은 테이터는 트랜잭션이 종료될 때 까지 후행 트랜잭션이 갱신하거나 삭제하는 것은 불허함으로써 같은 데이터를 두 번 쿼리했을때 일관성 있는 결과를 리턴

-Phantom Read 현상은 여전히 발생

-DB2, SQL Server의 경우 트랜잭션 고립화 수준을 Repeatable Read로 변경하면 읽은 테이터에 걸린 공유 Lock을 커밋할 때까지 유지하는 방식으로 구현

-Oracle은 이 레벨을 명시적으로 지원하지 않지만 for update 절을 이용해 구현가능, SQL Server등에서도 for update절을 사용할 수 있찌만 커서를 명시적으로 선언 할 때만 사용 가능함

 레벨 3(=Serializable Read)

-선행 트랜잭션이 읽은 데이터를 후행 트랜잭션이 갱신하거 삭제하지 못할 뿐만 아니라 중간에 새로운 레코드를 삽입하는 것도 막아줌

-완벽한 읽기 일관성 모드를 제공

(3) Dirty Read(=Uncommitted Dependency)

-아직 커밋되지 않은 수정 중인 테이타를 다른 트랜잭션에서 읽을 수 있도록 허용할 때 발생한다.

-오라클은 다중 버전 읽기 일관성 모델을 채택함으로써 Lock을 사용하지 않고도 Dirty Read를 피해 일관성 있는 데이터 읽기가 가능하고, 따라서 레벨 0수준으로 트랜잭션 고립화 수준으로 트랜잭션 고립화 수준을 낮추는 방법을 제공하지 않음.

(4) Non-Repeatable Read(= Inconsistent Analysis)

-한 트랜잭션 내에서 같은 쿼리를 두 번 수행할 때, 그 사이에 다른 트랜잭션이 값을 수정 또는 삭제함으로써 두쿼리의 결과가 상이하게 나타는 비 일관성이 발생하는 것을 말한다.

(5) Phantom Read

-한 트랜잭션 안에서 일정 범위의 레코드를 두번 이상 읽을 때, 첫번째 쿼리에서 없던 레코드가 두번재 쿼리에서 나타난현상.(이는 새로운 레코드가 삽입되는 것을 허용하기 때문에 나타나는 현상임)

-Phantom Read현상을 방지하려면 트랜잭션 고립화 수준을 레벨3으로 올려 주어야 한다.