오라클에서 커밋되지 않은 읽기 옵션을 허용합니까?

오라클에서 커밋되지 않은 읽기 옵션을 허용합니까?

db2에서 'with ur' 절이 있는 쿼리는 쿼리를 커밋되지 않은 읽기로 허용하며 mysql의 'with no lock' 절도 마찬가지입니다.오라클에도 그런 옵션이 있습니까?왜가 아니라면요?

Tom은 이에 대한 훌륭한 답변을 제공합니다: 트랜잭션 격리 수준에서

그는 말합니다.

READ UNCommitted 분리 수준은 더티 읽기를 허용합니다.Oracle Database는 더티 읽기를 사용하지 않으며 더티 읽기도 허용하지 않습니다.READ UNCOMMITED 분리 수준의 기본 목표는 비차단 읽기를 허용하는 표준 기반 정의를 제공하는 것입니다.

...

더티 읽기를 허용하는 데이터베이스...그것은 오답을 돌려줄 뿐만 아니라 ...도 돌려줍니다.[대답] ... 테이블에 존재하지 않는 것.다중 사용자 데이터베이스에서 더티 읽기는 위험한 기능이 될 수 있습니다.개인적으로, 저는 그것의 유용성을 본 적이 없습니다.

여기서 요점은 더러운 읽기는 기능이 아니라 부담이라는 것입니다.Oracle Database에서는 필요하지 않습니다.잘못된 결과 없이 더티 읽기(차단 없음)의 모든 이점을 얻을 수 있습니다.

Tom Kyte의 대답은 정확한 WRT 오라클입니다. MVCC(Multi-Version Concurrency Control) 아키텍처로 인해 더티 읽기와 같은 것은 없습니다.

응용프로그램 기능의 관점에서 볼 때, 저는 Tom의 의견에 전적으로 동의합니다. 그럴만한 이유나 더러운 읽을거리는 없습니다.

Oracle 외부에서 사용하는 이유는 무엇입니까?MVCC(예: MySQL, Ingres)가 없는 경우 제대로 조정되지 않으면 성능이 저하되거나 잠금 시스템이 "잠금 부족" 상태가 될 수 있는 잠금 문제를 피하기 위한 속임수입니다.Oracle에서 롤백/실행 취소를 조정해야 하는 것과 마찬가지로 비MVCC 데이터베이스에서도 잠금 시스템을 관리해야 합니다.

그렇다면 Oracle에서 "잘못된 데이터"가 발생할 가능성이 매우 낮고 중요하지 않은 읽기 전용 기능의 성능 향상으로 유용한 이유는 무엇입니까?MySQL/DB2/Ingres/Informix(SQL Server/Sybase에 대한 확신 없음)에서는 성능을 위해 잠금 관리 기능을 우회하는 데 사용할 수 있습니다.

다음은 읽기에 일관성이 필요하지 않은 상황의 예입니다.

• 모든 제품 목록

다음은 읽기에 일관성이 필요한 상황의 예입니다.

• 재고품 리스트

Oracle은 더티 읽기에 대한 개념조차 없으며 실제로 성능의 이점을 잃지 않고는 "기능으로 추가"할 수 없습니다(즉, Oracle의 실제 MVCC 아키텍처에서 더티 데이터를 가져오려면 너무 많은 트릭이 필요함).

UR 근거 포함:SELECT ONLY(보고서) 쿼리의 경우 커밋을 기다리는 것은 의미가 없습니다.업데이트되는 테이블에 대해 보고하는 경우 해당 업데이트를 받았는지 여부는 중요하지 않습니다.더티 읽기는 커밋 후 데이터만큼 유효합니다.쿼리가 1초 전에 잠긴 레코드에 도달했는지 고려합니다.

변경되는 테이블에 대해 쿼리를 실행하면 설정된 시점을 얻을 수 없습니다.쿼리 시작 시 액세스되는 데이터는 쿼리 종료 시 액세스되는 데이터보다 이전 시점에 있습니다.쿼리 결과에 포함되거나 포함되지 않을 수 있는 테이블에 대한 업데이트가 많이 있을 수 있습니다.

WITH UR 및 기타 DBMS 등가물을 사용하면 쿼리가 커밋을 기다리지 않고 데이터 무결성이 손실되지 않으므로 성능이 향상됩니다.

(ps. 제가 다른 반응에 대해 언급할 수 없도록 제 계정을 설정하기만 하면 됩니다.)

위의 답변이 정확하지만, 자율 트랜잭션은 권장되지 않으며, 여기서는 자율 트랜잭션과 잘못된 인식 기능의 단점을 살펴볼 수 있습니다.

UR은 다른 장기 실행 트랜잭션의 커밋되지 않은 읽기를 의미합니다.더티 읽기는 커밋되지 않은 읽기의 오래된 용어입니다.불완전한 실제 페이지는 DB2에서는 읽을 수 없고 Oracle에서도 읽을 수 있기를 바랍니다.SET Isolation Level Read Uncommitted를 찾습니다. Oracle에서도 가능할 것 같습니다.CS가 값에 도달하지 못해 한 테이블에 대해 직렬화된 서로 다른 반환을 생성할 수 있기 때문에 일관성을 얻는 관점에서 READ UNCOMMITED를 선호합니다.보고서나 덤프에서 요청한 내용이 아닐 수 있습니다.예를 들어, 나중에 커밋될 거래의 가치를 이론적으로 알고 싶다면..

https://docs.oracle.com/javadb/10.6.2.1/ref/rrefsqlj41180.html

언급URL : https://stackoverflow.com/questions/208236/does-oracle-allow-the-uncommitted-read-option