database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
ㆍOracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
Oracle Q&A 39106 게시물 읽기
No. 39106
Locking 메커니즘에 대한 질문
작성자
oracle
작성일
2011-11-17 14:52ⓒ
2011-11-17 15:03ⓜ
조회수
4,296

Locking 메커니즘에 관해 질문을 드립니다.

Oracle은 Row Level Locking 방식으로 한셰션에서 Delete,update문을 실행하고

다른셰션에서 select 를 하면 select 세션은 이전 데이터를 보는 것으로 알고 있습니다.

그럼 한셰션에서 한 페이지(block)에 존재 하는 하나의 Row 값을 update 실행하고 있고

다른 셰션에서 위에서 update치고 있는 다른페이지(다른 block)에 존재(위의 세션에 있는 페이지(block)가 아닌)하는 다른 Row값을 update친다면

Locking 이 걸리지 않는게 맞나요?

물론 둘다 exclusive Lock이라 Locking 이 유발될거라 생각되지만 Row 단위의 Lock 메커니즘 이면 전혀 상관없는

페이지(block)에 존재하고 조건값이 다른 Row라면  Locking 유발이 안되는것이 아닐까요? 

이 글에 대한 댓글이 총 1건 있습니다.

 오라클은 페이지 단위가 없습니다. 잠금은 row level lock이 기본입니다. table 레벨레도 잠글 수는 있지만 타 DBMS처럼 자동으로 락 에스컬레이션하지는 않습니다.

(

참고: 제가 MS-SQL이나 타 DBMS 쓸 때 Update, Update 다량으로 걸리는 상황에서 자동으로 락 에스컬레이션하다가 마지막엔 테이블 락을 걸어버리는 바람에 황당했던 경험이 있었습니다. 먹통이죠.

오라클이라면 절대 발생할 수 없는 경우죠. 오라클은 별도의 락 매니저가 없으므로 락이 많아진다고 하여 관리 오버헤드가 있지 않습니다.

)

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

 

위의 경우 서로 다른 레코드이므로 lock경합이 발생하지 않습니다.

다만 물리적으로 동일 블록에 들어가야 하므로 블록 헤더를 갱신하거나 할 경우 경합이 생길 순 있으나 이건 경합이지 락은 아닙니다.

 

오라클은 Multi-version Read consistency model을 채택하고 있으며, 위의 조회의 경우에는 CR 블록을 생성하여 읽기 일관성을 유지합니다.  

물론 이 과정에서 Undo를 사용하여 과거를 재현하므로 너무 오래된  경우 Snapshot too old라는 오라클 특유의 문제점을 유발하기도 하나 지엽적인 문제로 보이구요. 해결책도 존재합니다.

자세한 사항은 Thomas kyte의 expert one on one이나 최근에 나온 '오라클 성능 고도화 원리' 1권을 참조 바랍니다.

 

아무거나님이 2011-11-17 16:53에 작성한 댓글입니다.
이 댓글은 2011-11-17 16:56에 마지막으로 수정되었습니다. Edit
[Top]
No.
제목
작성자
작성일
조회
39110필드를 수정하고 싶습니다. [1]
오라초보
2011-11-18
4067
391091:1 1:N N:1 확인 쿼리 문의 [2]
쿼리
2011-11-18
4387
39107oracle 함수질문입니다.. [2]
추평사
2011-11-17
4129
39106Locking 메커니즘에 대한 질문 [1]
oracle
2011-11-17
4296
39105[질문] 오라클에도 DB Profiler 같은게 있나요?
궁금이
2011-11-17
3682
39104조회만 하는 Stored Procedure 작성 예제 좀.. [1]
궁금이
2011-11-16
4647
39103쿼리 속도 개선 좀 부탁합니다. [1]
박진경
2011-11-16
4991
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2024 DSN, All rights reserved.
작업시간: 0.016초, 이곳 서비스는
	PostgreSQL v16.2로 자료를 관리합니다