동시성 문제
잠금을 사용할 수 없는데 여러 사용자가 데이터베이스에 동시에 액세스하면 트랜잭션에서 동시에 같은 데이터를 사용하는 경우 문제가 발생할 수 있습니다. 동시성 문제에는 다음이 포함됩니다.
- 손실 업데이트
- 커밋되지 않은 종속성(커밋되지 않은 읽기)
- 일관성 없는 분석(반복하지 않는 읽기)
- 팬텀 읽기
손실 업데이트
손실 업데이트는 둘 이상의 트랜잭션이 같은 행을 선택한 다음 원래 선택한 값을 기준으로 행을 업데이트할 때 발생합니다.
이 때 각 트랜잭션은 다른 트랜잭션을 인식하지 못합니다. 마지막 업데이트가 다른 트랜잭션의 업데이트를 겹쳐쓰므로 데이터가 손실됩니다.
예를 들어, 두 명의 사용자가 같은 문서를 복사한다고 가정합니다.
각 사용자가 각자 복사본을 변경한 다음 변경된 복사본을 저장하면 원본 문서가 겹쳐써집니다.
변경된 복사본을 마지막으로 저장한 사용자는 먼저 사용자가 변경한 내용을 겹쳐씁니다.
이러한 문제를 해결하려면 다른 사용자가 변경 작업을 마칠 때까지 변경할 수 없게 해야 합니다.
커밋되지 않은 종속성(커밋되지 않은 읽기)
커밋되지 않은 종속성은 다른 트랜잭션이 업데이트 중인 행을 선택할 때 발생합니다.
두 번째 트랜잭션이 읽고 있는 데이터는 아직 커밋되지 않았지만 현재 행을 업데이트 중인 트랜잭션에 의해 변경될 수 있습니다.
예를 들어, 한 사용자가 문서를 변경 중이라고 가정합니다.
변경하는 동안 다른 사용자가 그 시점까지 변경한 내용을 모두 포함하여 문서를 복사한 다음 다른 사용자에게 문서를 배포합니다.
첫 번째 사용자가 그 때까지 변경한 내용이 잘못되었다고 판단하여 편집 내용을 지우고 문서를 저장할 수 있습니다.
배포된 문서에는 틀린 내용이 있으므로 이 내용은 무시해야 합니다.
이러한 문제를 해결하려면 첫 번째 사용자가 변경한 내용이 최종이라고 결정할 때까지
다른 사용자가 변경된 문서를 읽을 수 없게 해야 합니다.
일관성 없는 분석(반복하지 않는 읽기)
일관성 없는 분석은 두 번째 트랜잭션이 같은 행에 액세스할 때마다 다른 데이터를 읽을 때 발생합니다.
일관성 없는 분석은 두 번째 트랜잭션이 읽고 있는 데이터를 다른 트랜잭션이 변경하고 있다는 점에서 커밋되지 않은 종속성과 비슷합니다.
그러나 일관성 없는 분석에서는 두 번째 트랜잭션이 읽은 데이터가 변경한 트랜잭션에 의해 커밋된 것이며
같은 데이터를 읽을 때마다 매번 다른 트랜잭션이 정보를 변경하는 것입니다. 이를 반복하지 않는 읽기라고 합니다.
예를 들어, 한 사용자가 같은 문서를 두 번 읽는데 각 읽기 사이에 다른 사용자가 문서를 다시 작성할 수 있습니다.
한 사용자가 같은 문서를 다시 읽으면 이 문서가 변경되어 있을 것이므로 원래의 읽기는 반복되지 않습니다.
이러한 문제를 해결하려면 한 사용자가 문서를 모두 작성한 후에만 다른 사용자가 문서를 읽게 합니다.
팬텀 읽기
팬텀 읽기는 한 트랜잭션이 읽고 있는 행 범위의 한 행에 대해 다른 트랜잭션이 삽입 또는 삭제 작업을 수행할 때 발생합니다.
다른 트랜잭션의 삭제 작업으로 인해 트랜잭션이 첫 번째 행 범위를 읽을 때 읽은 행이 다음에 읽을 때 없어질 수 있습니다.
마찬가지로 다른 트랜잭션의 삽입 결과로 처음 읽을 때 없던 행이 다음에 읽을 때 생길 수도 있습니다.
예를 들어, 문서 작성자가 제출한 문서를 편집자가 변경하는 중
생산 부서에서 문서의 마스터 복사본으로 변경 내용을 통합할 때 작성자가 편집되지 않은 새 자료를 문서에 추가할 될 수 있습니다.
이 문제를 해결하려면 편집자나 생산 부서가 원본 문서 작업을 완료할 때까지 다른 사용자가 새 자료를 문서에 추가할 수 없게 합니다.
--------------------------------------------------------------------------------------
SQL Server 잠금 이해
Microsoft? SQL Server™ 2000은 한 트랜잭션으로 여러 유형의 리소스를 잠글 수 있는 다양한 세분성의 잠금을 제공합니다.
잠금 비용을 최소화하기 위해 SQL Server는 자동으로 작업에 맞는 수준에서 리소스를 잠급니다.
행과 같이 작은 세분성에서 잠그면 동시성이 향상되지만 많은 행을 잠글 경우 더 많은 잠금을 보유해야 하므로 오버헤드가 늘어납니다.
테이블과 같이 큰 세분성에서 잠그면 전체 테이블을 잠궈서 다른 트랜잭션이 테이블에 액세스하지 못하게 제한하므로 동시성은 떨어지지만 처리할 잠금 수가 적으므로 오버헤드는 줄어듭니다.
SQL Server는 다음과 같은 리소스를 잠글 수 있습니다. 다음 표는 세분성이 큰 순서부터 나열한 것입니다.
리소스 | 설명 |
---|---|
RID | 행 식별자입니다. 테이블 내에서 행 하나를 잠글 때 사용합니다. |
키 | 인덱스에 있는 행 잠금입니다. 순차 가능한 트랜잭션에서 키 범위를 보호하기 위해 사용합니다. |
페이지 | 8KB 데이터 페이지 또는 인덱스 페이지입니다. |
익스텐트 | 인접한 8개의 데이터 페이지 또는 인덱스 페이지 그룹입니다. |
테이블 | 모든 데이터와 인덱스가 포함된 전체 테이블입니다. |
DB | 데이터베이스입니다. |
----------------------------------------------------------------------------------------
SET TRANSACTION
ISOLATION LEVEL
한 연결에서 실행한 모든 Microsoft? SQL Server™ SELECT 문에 대해 기본 트랜잭션 잠금 동작을 제어합니다.
구문
SET TRANSACTION ISOLATION LEVEL
{ READ COMMITTED
| READ UNCOMMITTED
| REPEATABLE READ
| SERIALIZABLE
}
인수
READ COMMITTED
데이터를 읽을 때는 공유 잠금이 유지되도록 해서 커밋되지 않은 데이터 읽기가 이루어지지 않도록 지정하지만,
트랜잭션이 끝나기 전에 데이터가 변경되어 반복하지 않는 읽기 또는 팬텀 데이터가 만들어질 수 있습니다.
이 옵션은 SQL Server의 기본값입니다.
READ UNCOMMITTED
불필요한 읽기나 격리 수준 0을 구현합니다. 이렇게 하면 공유 잠금이 만들어지지 않고 단독 잠금이 무시됩니다.
이 옵션을 설정하면 커밋되지 않은 데이터나 불필요한 데이터를 읽을 수 있습니다.
데이터의 값이 변경될 수 있으며 트랜잭션이 끝나기 전에 데이터 집합에 행이 나타나거나 사라질 수도 있습니다.
이 옵션은 트랜잭션에서 모든 SELECT 문의 모든 테이블에 NOLOCK을 설정하는 것과 같습니다.
네 가지 격리 수준 중 제한이 가장 적습니다.
REPEATABLE READ
쿼리에서 사용되는 모든 데이터에 잠금을 배치해 다른 사용자가 데이터를 업데이트할 수 없도록 하지만,
다른 사용자가 데이터 집합에 새 허위 행을 삽입해 현재 트랜잭션의 이후 읽기에 포함될 수 있도록 합니다.
병행성이 기본 격리 수준보다 낮기 때문에 필요할 때만 이 옵션을 사용하도록 하십시오.
SERIALIZABLE
데이터 집합에 범위 잠금을 배치해 트랜잭션이 완료될 때까지
다른 사용자가 행을 업데이트하거나 데이터 집합에 삽입할 수 없도록 합니다. 네 가지 격리 수준 중 제한이 가장 많습니다.
병행성이 더 낮기 때문에 필요할 때만 이 옵션을 사용하도록 하십시오.
이 옵션은 트랜잭션의 모든 SELECT 문의 모든 테이블에 HOLDLOCK을 설정하는 것과 같습니다.
---------------------------------------------------------------------------------------
Transaction Isolation Level
Level 0 READUNCOMMITTED - Oracle Default
Level 1 READCOMMITTED - SQL SERVER 2000 Default
Level 2 REPEATABLEREAD
Level 3 SERIALIZABLE
[출처] 항해자
"쇼핑몰·홈페이지·오픈마켓
블로그·페이스북·이메일 등의 각종 마케팅 글쓰기, 각종 광고, 영업, 판매, 제안서, 전단지 반응율 3배×10배 이상 높이는 마법의 8단계 공식" |
![]() |
☞자세히보기 |
|
|