[oracle architecture][2015 04-09] consistency

WareValleyhttp://www.WareValley.com

Database Audit and Protection [ DB 접근통제 ]

Database Encryption [ DB 암호화 ]

Database Vulnerability Assessment [ DB 취약점 분석 ]

Database SQL Query Approval [ DB 작업결재 ]

Database Performance Monitoring and Management [ DB 성능관리 및 개발 ]

WareValley

Oracle ArchitectureConsistency

오렌지팀 윤석준 선임연구원

Database security and management, WareValley.http://www.WareValley.com

Consistency

단일 SQL문 (또는 Transaction) 수행시 다른 Transaction에 의해서 값이 변하더

라도 일관성 있는 result-set을 return 하는 것

문장수준 읽기 일관성 (Statement-Level Read Consistency)

- 단일 SQL문에서의 읽기 일관성

- Dirty-read (아직 Commit 되지 않은 값을 읽음) 을 허용하면 보장이 안됨

- 타 DBMS는 Row-lock 을 사용하여 Drity-read 방지

(읽기는 shared-lock을 사용. exclusive-lock은 못읽음)

- 하지만 Table-lock을 사용하지 않고, 단지 Dirty-read방지 만으로는 일관성 보장이 힘듬


Consistency

Account Balances

1 1,000

2 1,000

3 1,000

4 1,000

5 1,000

6 1,000

7 1,000

8 1,000

9 1,000

10 1,000

11 500

Tx 1 : SELECT SUM(Balances) FROM Accounts

Accounts

Tx 2 : INSERT INTO Accounts VALUES ( 11, 500 );

(( 수행 중 ))

e.g. 1

①

③

②

Tx 1 결과 : 5,500 (OK)

Account Balances

1 1,000

2 1,000

3 1,000

4 1,000

5 1,000

11 500

6 1,000

7 1,000

8 1,000

9 1,000

10 1,000

Accounts

Case 2

①

③

②

Tx 1 결과 : 5,000 (NG)

Case 1


Consistency

Account Balances

1 1,000

2 1,000

3 1,000

4 900

5 1,000

6 1,000

7 1,100

8 1,000

9 1,000

10 1,000

Tx 1 : SELECT SUM(Balances) FROM AccountsAccounts

Tx 2 : UPDATE AccountsSET Balances = Balances + 100

WHERE Account = 7;

UPDATE Accounts SET Balances = Balances – 100

WHERE Account = 2;

(( 수행 중 ))

e.g. 2

①

③②

Tx 1 결과 : 4,900 (NG)

Case

④

⑤


Consistency

Solution

1. 트랜잭션 고립화 수준을 높인다.

(transaction isolation level)

2. Table Lock을 사용한다.

3. 하지만…

Oracle은 Lock을 사용하지 않고,

Undo Segment를 사용하므로

잘된다고 합니다. ( 아~ 예. 예….)


Transaction Isolation Level

Level 1, Read Committed

값을 읽는 순간에만 shared-lock을 걸었다가 읽고 난 뒤에 해제

=> 읽기 일관성 보장이 힘듬 (앞에 사례들)

Level 2, Repeatable Read

Transaction 완료 (commit or rollback) 전까지는

shared-lock을 풀지 않음

=> 성능 저하는 물론이거니와…

(뽀나스) 교착상태 (deadlock) 발생가능성이 높아짐. (사례2)

Account Balances

1 1,000

2 1,000

3 1,000

4 900

5 1,000

6 1,000

7 1,100

8 1,000

9 1,000

10 1,000

Accounts

① s-l

③ wait

② x-l

④ wait


Consistent Mode Block Read

• Current Block : 현재 상태의 Block

• CR Block : Current Block에 Undo Segment를 반영하여 만든 특정 시점 (SCN)의 Block

• SCN (System Commit Number) : 사용자가 Commit 할 때마다 증가하는 Global 변수

(Background Process도 증가 시킴)

• Block SCN : Block이 마지막으로 변경된 시점의 SCN (Block header에 저장)


Multi-version Read Consistency Model

Current Block 에서 CR Copy Block을 생성하여 읽기 일관성을 지원하는 Oracle의 매커니즘

(RAC의 경우 RAC Cache Fusion Mechanism을 활용하여 전체 Instance 의 SCN을 비교)



① 모든 SQL의 SCN 확인 (Query SCN or Snapshot SCN)

② Consistent Mode에서는 Query SCN보다 같거나 작은 Block SCN의 Block만 읽을 수 있다.

③ Data Modify는 Current Block에만 가능하다.

• DBA 당 CR 개수 제한 : 기본적으로 Data Block 마다 6개의 CR Copy 허용

( _db_block_max_cr_dba )

• CR Copy는 LRU List에서 항상 LRU end에 위치하여 free buffer 요구시 1순위로 지워짐



Case 1

Current Block SCN <= Query SCN 이면서 Committed 상태

=> 그냥 Current Block를 읽으면 됨.

Case 2

Current Block SCN > Query SCN 이면서 Committed 상태

=> Query SCN 보다 작거나 같은 버전의 Committed CR Block를 생성

[ CR Cloning : Undo Segment를 이용하여 계속해서 이전 버전의 CR Block을 생성 ]

Case 3

Current Block 이 Active 상태 (당연히 Uncommitted)

=> Transaction Table로부터 Commit 정보를 가져와 Block Cleanout 시도

=> 그 결과 Query SCN 이전에 Committed 된 것으로 확인되면 Case 1

아니면 Case 2 처럼 CR Copy를 만들어서 찾음

[oracle architecture][2015 04-09] consistency

Software