UPDATE = DELETE(삭제) + INSERT?

UPDATE = DELETE(삭제) + INSERT?

이것은 SQL Server 질문이지만 다른 DBMS 컨텍스트가 제대로 확인되면 답변을 주시면 감사하겠습니다.

MSDN 포럼에서 제 질문에 대한 Seth Lynch의 답변:

• (NOLOCK) 힌트를 사용하여 반으로 쓴 값 판독을 방지합니까?

다음을 알려줍니다.

"데이터 업데이트 시 덮어쓰기 되지 않음 - 원래 행이 삭제된 것으로 표시되고 새 행이 삽입됨"

정확한 진술입니까?문서에서 이를 뒷받침하는 참고 자료를 줄 수 있습니까?
어떻게 검증할 수 있습니까?

관련 토론:

• SQL에서 업데이트는 항상 DELETE+보다 빠릅니다.삽입?

업데이트: 얼마 전 저는 READ UNCOMITED 트랜잭션 격리 수준(또는 WITH(NOLOCK) 힌트를 통해 SQL Server에서 동일한 것)에서 허용되는 읽기(또는 다른 트랜잭션에서 아직 변경되지 않은 경우 커밋되지 않은(또는 커밋된) 값이지만 부분적으로 변경되지 않은(부분적으로 업데이트된, 부분적으로 삭제된, 또는 부분적으로 삽입된) 값이 있다고 믿었습니다.

RESUME': 간단히 말하면, 이 문구는 일반적이고 대부분의 경우 부정확합니다(SQL Server에서는 다소 흔하지 않은 경우에 대해 자세히 설명하지만).

Calen Delaney에 따르면, 그녀의 책 Inside Microsoft SQL Server 2005에서: Storage Engine, SQL Server 2005(그리고 현재 2008)는 삽입/삭제를 사용하거나 한 열의 값을 변경하는 것만으로 행을 업데이트할 수 있습니다.그 책의 306-311쪽에 그녀가 말하는 것을 간단히 요약하면 다음과 같습니다.

SQL Server 2005/2008의 일반 동작은 행을 제자리에 업데이트하는 것입니다.행은 페이지의 동일한 위치에 유지되고 영향을 받는 바이트만 변경됩니다.이러한 예로는 curstered index의 일부가 아닌 정수 열의 값을 업데이트하는 것이 있습니다.

행의 크기가 변경되어 원래 페이지에 더 이상 맞지 않는 경우 행이 삽입/삭제로 업데이트될 수 있습니다.이 문제는 varchar 열에서 값을 변경하고 값을 길게 할 때 발생할 수 있습니다.또한 클러스터된 인덱스 열이 변경 중이고 인덱스 위치 때문에 행을 이동해야 하는 경우에도 발생합니다(클러스터된 키에 의해 행 순서가 지정되므로).예를 들어, 성에 클러스터된 인덱스가 있는 테이블에서 누군가의 성을 "스미스"에서 "존스"로 변경하는 것이 있습니다.

이것은 구현에 따라 다릅니다.

일반적으로 다중 버전 컨서런시 제어(Multi Version Concurrency Control, MVCC)를 사용하는 경우 원래 행은 유지됩니다.트랜잭션이 삭제되고 대체 행이 생성된 트랜잭션에 의해 삭제된 것으로 표시되거나 트랜잭션이 커밋하고 델타가 기존 행에 적용될 때까지 트랜잭션 컨텍스트의 다른 곳에 델타가 저장됩니다.

잠금 기반 동시성 제어에서는 단일 트랜잭션만 행을 읽고 쓸 수 있기 때문에 행을 현장에서 변경할 수 있습니다.

세부 사항은 구현에 따라 다릅니다.일부 시스템에서는 커밋할 때까지 델타를 사용하고 일부 시스템에서는 행을 변경하지만 롤백 시 사용할 원본 복사본을 유지합니다.

Oracle에서 UPDATE는 항상 원래 행을 변경합니다.행의 이전 값은 다중 버전 동시성 제어(Multi Version Concurrency Control, MVCC) 구현의 일부로 UndO 로그에 기록되고 한동안 유지됩니다.

새 값이 커밋되지 않는 한, 다른 모든 트랜잭션은 UndO 로그에서 이전 값을 가져옵니다.쿼리가 새 값의 COMIT 이전에 또는 특정 트랜잭션 분리 모드에서 시작된 경우에도 동일하게 발생합니다.

새 값이 더 커서 행이 같은 페이지에 더 이상 맞지 않으면 행이 새 페이지로 마이그레이션되고 이전 페이지의 공간이 확보됩니다.

언급URL : https://stackoverflow.com/questions/4291540/is-update-deletemarked-as-insert