무신 말씀이신지....

select시에 select가 종료되면 lock을 release하는데요??

sybase가 개발하기에는 안좋지만 ...뭐 그렇게 우울한 db는 아닌데요~

아마 update lock을 물어보시는 건가요?

질문하시기 전에 조금이라도 공부하시고 명확한 질문을 해주세요

select 시에도 락을 건다는 말씀이네요

여러 동시 사용자가 select 할 경우 각 세션마다 for update 처리하므로 시리얼하게 처리한다는 말씀이네요.

오라클은 Multi-version read-consistent concurrency mode 이기 때문에 이럴 필요가 없거든요. 답글 감사합니다.

transaction level을 조정하면 lock을 안걸수도 있습니다.

set transaction isolation level 0를 실행후 쿼리를 수행하거나

select 시 at isolation 0 롤 주고 읽으면 아무런 lock 도 발생 안합니다.

update lock은 cursor를 사용시 default는 for update 며

이를 피하기 위해서는 for read only를 주시면.....

물론  isolation level 0 으로 주면은 락은 피할수 있겠지만은

아시다시피 dirty data 읽게 되므로 정확한 데이타라고는

볼수 없겠죠. ms-sql 튜닝쪽은 이렇게 많이 하는데...

정확한 데이타가 아니라도 괜찮으면은 0 레벨주면 성능에도

좋겠죠... 이런것들이 오라클에서는 필요없죠..

그래서 금융권쪽에서는 오라클밖에 쓸수없는 ^^........

오라클에선 로우에 대한 Shared Lock이 없습니다.

즉 Shared Row Lock이라는거 자체가 없지요.

Select 문자 실행시 변경중인 데이터나 변경 후 Commit되었어도 Select 문장 실행시점보다 느게 변경 커밋 되었다면 Rollback seg,에 있는 변경전의 데이터를 보여주니까요...

그런관점에서 볼때 우울한건 오라클도 마찬가지 일겁니다. 과연 오라클의 Select도 현재의 정확한 데이터를 보여주고 있는걸까요??? 금융권에서 오라클을 쓸수밖에 없다구요??? 아마도 select for update를 할 수 밖에 없을 겁니다.

계좌정보 변경시 잔고조회 할때 그냥 Select 했다간 큰일 나겠죠. 님께서 MS SQL 튜닝할때 isol..0로 하셨다는데 그렇게 해도 문제가 없어서 가능한 것이지요. 오라클 역시 before image(RBS)를 보여주는 것이 select의 기본 사상이지만 이거 역시 정확한 데이터가 아닌건 마찬가지입니다.

이경우 before data(오라클) 냐 After Data(사이베)는 선택과 관점의 문제이지 맞고 틀리고의 문제는 아니라고 생각합니다.