쿠키 기본 설정 선택

당사는 사이트와 서비스를 제공하는 데 필요한 필수 쿠키 및 유사한 도구를 사용합니다. 고객이 사이트를 어떻게 사용하는지 파악하고 개선할 수 있도록 성능 쿠키를 사용해 익명의 통계를 수집합니다. 필수 쿠키는 비활성화할 수 없지만 '사용자 지정' 또는 ‘거부’를 클릭하여 성능 쿠키를 거부할 수 있습니다.

사용자가 동의하는 경우 AWS와 승인된 제3자도 쿠키를 사용하여 유용한 사이트 기능을 제공하고, 사용자의 기본 설정을 기억하고, 관련 광고를 비롯한 관련 콘텐츠를 표시합니다. 필수가 아닌 모든 쿠키를 수락하거나 거부하려면 ‘수락’ 또는 ‘거부’를 클릭하세요. 더 자세한 내용을 선택하려면 ‘사용자 정의’를 클릭하세요.

설정
문의하기
피드백
AWS Documentation
AWS 계정 생성
Babelfish 및 SQL Server 격리 수준 비교 - Amazon Aurora
SQL Server READ UNCOMMITTED 격리 수준과 비교한 Babelfish READ UNCOMMITTEDSQL Server READ COMMITTED 격리 수준과 비교한 Babelfish READ COMMITTEDSQL Server READ COMMITTED SNAPSHOT 격리 수준과 비교한 Babelfish READ COMMITTEDSQL Server REPEATABLE READ 격리 수준과 비교한 Babelfish REPEATABLE READSQL Server SERIALIZABLE 격리 수준과 비교한 Babelfish SERIALIZABLE

Babelfish 및 SQL Server 격리 수준 비교

PDFRSS

다음은 SQL Server와 Babelfish가 ANSI 격리 수준을 구현하는 방식의 미묘한 차이에 대한 몇 가지 예입니다.

참고

  • REPEATABLE READ 및 SNAPSHOT 격리 수준은 Babelfish에서 동일합니다.

  • READ UNCOMMITTED 및 READ COMMITTED 격리 수준은 Babelfish에서 동일합니다.

다음 예제에서는 아래에 언급된 모든 예제에 대한 기본 테이블을 생성하는 방법을 보여줍니다.

CREATE TABLE employee (
    id sys.INT NOT NULL PRIMARY KEY,
    name sys.VARCHAR(255)NOT NULL,
    age sys.INT NOT NULL
);
INSERT INTO employee (id, name, age) VALUES (1, 'A', 10);
INSERT INTO employee (id, name, age) VALUES (2, 'B', 20);
INSERT INTO employee (id, name, age) VALUES (3, 'C', 30);

SQL Server READ UNCOMMITTED 격리 수준과 비교한 Babelfish READ UNCOMMITTED

다음 표는 동시 트랜잭션이 실행될 때 더티 읽기에 대한 세부 정보를 제공합니다. 이는 Babelfish 구현과 비교하여 SQL Server에서 READ UNCOMMITTED 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server READ UNCOMMITTED Babelfish READ UNCOMMITTED

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;

없음

없음

트랜잭션의 유휴 상태

UPDATE employee SET age=0;

업데이트 성공

업데이트 성공

트랜잭션의 유휴 상태

INSERT INTO employee VALUES (4, 'D', 40);

삽입 성공

삽입 성공

SELECT * FROM employee;

트랜잭션의 유휴 상태

트랜잭션 1은 트랜잭션 2에서 커밋되지 않은 변경 사항을 확인할 수 있습니다.

Babelfish의 READ COMMITTED와 동일합니다. 트랜잭션 2의 커밋되지 않은 변경 사항은 트랜잭션 1에 표시되지 않습니다.

트랜잭션의 유휴 상태

COMMIT

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

트랜잭션 2에서 커밋된 변경 사항을 확인합니다.

트랜잭션 2에서 커밋된 변경 사항을 확인합니다.

SQL Server READ COMMITTED 격리 수준과 비교한 Babelfish READ COMMITTED

다음 표에서는 동시 트랜잭션이 실행될 때 읽기-쓰기 차단 동작에 대한 세부 정보를 제공합니다. 이는 Babelfish 구현과 비교하여 SQL Server에서 READ COMMITTED 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server READ COMMITTED Babelfish READ COMMITTED

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

UPDATE employee SET age=100 WHERE id = 1;

업데이트 성공

업데이트 성공

UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);

트랜잭션의 유휴 상태

트랜잭션 2가 커밋될 때까지 단계가 차단됩니다.

트랜잭션 2 변경 사항은 아직 표시되지 않습니다. id = 3인 행을 업데이트합니다.

트랜잭션의 유휴 상태

COMMIT

트랜잭션 2가 성공적으로 커밋됩니다. 이제 트랜잭션 1의 차단이 해제되고 트랜잭션 2의 업데이트를 확인할 수 있습니다.

트랜잭션 2가 성공적으로 커밋됩니다.

SELECT * FROM employee;

트랜잭션의 유휴 상태

트랜잭션 1이 id = 1인 행을 업데이트합니다.

트랜잭션 1이 id = 3인 행을 업데이트합니다.

SQL Server READ COMMITTED SNAPSHOT 격리 수준과 비교한 Babelfish READ COMMITTED

다음 표에서는 동시 트랜잭션이 실행될 때 새로 삽입된 행의 차단 동작에 대한 세부 정보를 제공합니다. 이는 READ COMMITTED Babelfish 구현과 비교하여 SQL Server에서 READ COMMITTED SNAPSHOT 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server READ COMMITTED SNAPSHOT Babelfish READ COMMITTED

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

없음

없음

INSERT INTO employee VALUES (4, 'D', 40);

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

UPDATE employee SET age = 99;

트랜잭션 1가 커밋될 때까지 단계가 차단됩니다. 삽입된 행은 트랜잭션 1에 의해 잠깁니다.

3개 행이 업데이트됩니다. 새로 삽입된 행은 아직 표시되지 않습니다.

COMMIT

트랜잭션의 유휴 상태

커밋 성공. 이제 트랜잭션 2가 차단 해제됩니다.

커밋 성공.

트랜잭션의 유휴 상태

SELECT * FROM employee;

4개 행 모두 age=99가 됩니다.

id = 4인 행은 업데이트 쿼리 중에 트랜잭션 2에 표시되지 않았으므로 age 값이 40입니다. 다른 행은 age=99로 업데이트됩니다.

SQL Server REPEATABLE READ 격리 수준과 비교한 Babelfish REPEATABLE READ

다음 표에서는 동시 트랜잭션이 실행될 때 읽기-쓰기 차단 동작에 대한 세부 정보를 제공합니다. 이는 REPEATABLE READ Babelfish 구현과 비교하여 SQL Server에서 REPEATABLE READ 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server REPEATABLE READ Babelfish REPEATABLE READ

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

없음

없음

UPDATE employee SET name='A_TXN1' WHERE id=1;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

SELECT * FROM employee WHERE id != 1;

없음

없음

트랜잭션의 유휴 상태

SELECT * FROM employee;

트랜잭션 2는 트랜잭션 1이 커밋될 때까지 차단됩니다.

트랜잭션 2는 정상적으로 진행됩니다.

COMMIT

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

SELECT * FROM employee;

트랜잭션 1의 업데이트가 표시됩니다.

트랜잭션 1의 업데이트가 표시되지 않습니다.

COMMIT

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

SELECT * FROM employee;

트랜잭션 1의 업데이트를 확인합니다.

트랜잭션 1의 업데이트를 확인합니다.

다음 표에서는 동시 트랜잭션이 실행될 때 쓰기-쓰기 차단 동작에 대한 세부 정보를 제공합니다. 이는 REPEATABLE READ Babelfish 구현과 비교하여 SQL Server에서 REPEATABLE READ 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server REPEATABLE READ Babelfish REPEATABLE READ

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

없음

없음

UPDATE employee SET name='A_TXN1' WHERE id=1;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

UPDATE employee SET name='A_TXN2' WHERE id=1;

트랜잭션 2가 차단됩니다.

트랜잭션 2가 차단됩니다.

COMMIT

트랜잭션의 유휴 상태

커밋이 완료되고 트랜잭션 2가 차단 해제되었습니다.

동시 업데이트로 인해 액세스를 직렬화할 수 없다는 오류와 함께 커밋이 완료되고 트랜잭션 2가 실패합니다.

트랜잭션의 유휴 상태

COMMIT

커밋 성공.

트랜잭션 2는 이미 중단된 상태입니다.

트랜잭션의 유휴 상태

SELECT * FROM employee;

id=1인 행에서 name='A_TX2'입니다.

id=1인 행에서 name='A_TX1'입니다.

다음 표에서는 동시 트랜잭션이 실행될 때 가상 읽기 동작에 대한 세부 정보를 제공합니다. 이는 REPEATABLE READ Babelfish 구현과 비교하여 SQL Server에서 REPEATABLE READ 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server REPEATABLE READ Babelfish REPEATABLE READ

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

INSERT INTO employee VALUES (4, 'NewRowName', 20);

트랜잭션 2는 차단 없이 진행됩니다.

트랜잭션 2는 차단 없이 진행됩니다.

트랜잭션의 유휴 상태

SELECT * FROM employee;

새로 삽입한 행이 표시됩니다.

새로 삽입한 행이 표시됩니다.

트랜잭션의 유휴 상태

COMMIT

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

트랜잭션 2에서 삽입한 새 행이 표시됩니다.

트랜잭션 2에서 삽입한 새 행이 표시되지 않습니다.

COMMIT

트랜잭션의 유휴 상태

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

새로 삽입한 행이 표시됩니다.

새로 삽입한 행이 표시됩니다.

다음 표는 동시 트랜잭션이 실행되는 시기 및 REPEATABLE READ Babelfish 구현과 비교하여 SQL Server에서 REPEATABLE READ 격리 수준을 사용할 때의 다양한 최종 결과를 제공합니다.

트랜잭션 1 트랜잭션 2 SQL Server REPEATABLE READ Babelfish REPEATABLE READ

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

없음

없음

UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);

트랜잭션의 유휴 상태

트랜잭션 1이 id = 1인 행을 업데이트합니다.

트랜잭션 1이 id = 1인 행을 업데이트합니다.

트랜잭션의 유휴 상태

UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);

SELECT 문이 트랜잭션 1의 UPDATE 쿼리로 잠긴 행을 읽으려고 하기 때문에 트랜잭션 2가 차단됩니다.

트랜잭션 2는 읽기가 차단되지 않으므로 차단 없이 진행됩니다. SELECT 문이 실행되고 마지막으로 트랜잭션 1의 변경 내용이 아직 표시되지 않으므로 id = 3인 행이 업데이트됩니다.

트랜잭션의 유휴 상태

SELECT * FROM employee;

이 단계는 트랜잭션 1이 커밋된 후에 실행됩니다. id = 1인 행은 이전 단계의 트랜잭션 2에 의해 업데이트되며 여기에 표시됩니다.

트랜잭션 2가 id = 3인 행을 업데이트합니다.

COMMIT

트랜잭션의 유휴 상태

이제 트랜잭션 2가 차단 해제됩니다.

커밋 성공.

트랜잭션의 유휴 상태

COMMIT

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

두 트랜잭션 모두 id = 1인 행에서 업데이트를 실행합니다.

트랜잭션 1과 2가 서로 다른 행을 업데이트합니다.

SQL Server SERIALIZABLE 격리 수준과 비교한 Babelfish SERIALIZABLE

다음 표에서는 동시 트랜잭션이 실행될 때 범위 잠금에 대한 세부 정보를 제공합니다. 이는 SERIALIZABLE Babelfish 구현과 비교하여 SQL Server에서 SERIALIZABLE 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server SERIALIZABLE Babelfish SERIALIZABLE

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

INSERT INTO employee VALUES (4, 'D', 35);

트랜잭션 2는 트랜잭션 1이 커밋될 때까지 차단됩니다.

트랜잭션 2는 차단 없이 진행됩니다.

트랜잭션의 유휴 상태

SELECT * FROM employee;

없음

없음

COMMIT

트랜잭션의 유휴 상태

트랜잭션 1이 성공적으로 커밋됩니다. 이제 트랜잭션 2가 차단 해제됩니다.

트랜잭션 1이 성공적으로 커밋됩니다.

트랜잭션의 유휴 상태

COMMIT

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

새로 삽입한 행이 표시됩니다.

새로 삽입한 행이 표시됩니다.

다음 표는 동시 트랜잭션이 실행되는 시기 및 SERIALIZABLE Babelfish 구현과 비교하여 SQL Server에서 SERIALIZABLE 격리 수준을 사용할 때의 다양한 최종 결과를 제공합니다.

트랜잭션 1 트랜잭션 2 SQL Server SERIALIZABLE Babelfish SERIALIZABLE

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

없음

없음

트랜잭션의 유휴 상태

INSERT INTO employee VALUES (4, 'D', 40);

없음

없음

UPDATE employee SET age =99 WHERE id = 4;

트랜잭션의 유휴 상태

트랜잭션 1은 트랜잭션 2가 커밋될 때까지 차단됩니다.

트랜잭션 1은 차단 없이 진행됩니다.

트랜잭션의 유휴 상태

COMMIT

트랜잭션 2가 성공적으로 커밋됩니다. 이제 트랜잭션 1이 차단 해제됩니다.

트랜잭션 2가 성공적으로 커밋됩니다.

COMMIT

트랜잭션의 유휴 상태

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

새로 삽입된 행의 age 값이 99로 표시됩니다.

새로 삽입된 행의 age 값이 40으로 표시됩니다.

다음 표는 고유한 제약 조건이 있는 테이블에 INSERT하는 경우의 세부 정보를 제공합니다. 이는 SERIALIZABLE Babelfish 구현과 비교하여 SQL Server에서 SERIALIZABLE 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server SERIALIZABLE Babelfish SERIALIZABLE

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

없음

없음

트랜잭션의 유휴 상태

INSERT INTO employee VALUES (4, 'D', 40);

없음

없음

INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);

트랜잭션의 유휴 상태

트랜잭션 1은 트랜잭션 2가 커밋될 때까지 차단됩니다.

트랜잭션 1은 트랜잭션 2가 커밋될 때까지 차단됩니다.

트랜잭션의 유휴 상태

COMMIT

트랜잭션 2가 성공적으로 커밋됩니다. 이제 트랜잭션 1이 차단 해제됩니다.

트랜잭션 2가 성공적으로 커밋됩니다. 키 값 중복 오류로 인해 트랜잭션 1이 중단되었으며 고유한 제약 조건을 위반했습니다.

COMMIT

트랜잭션의 유휴 상태

트랜잭션 1이 성공적으로 커밋됩니다.

트랜잭션 간의 읽기 또는 쓰기 종속성으로 인해 액세스를 직렬화할 수 없어 트랜잭션 1 커밋이 실패합니다.

SELECT * FROM employee;

트랜잭션의 유휴 상태

행 (5, 'E', 50)이 삽입됩니다.

4개의 행만 존재합니다.

Babelfish에서 직렬화 가능(serializable) 격리 수준으로 실행되는 동시 트랜잭션은 이러한 트랜잭션의 실행이 해당 트랜잭션의 가능한 모든 직렬(한 번에 하나씩) 실행과 일치하지 않으면 직렬화 이상 오류가 발생하여 실패합니다.

다음 표에서는 동시 트랜잭션이 실행될 때 직렬화 이상에 대한 세부 정보를 제공합니다. 이는 SERIALIZABLE Babelfish 구현과 비교하여 SQL Server에서 SERIALIZABLE 격리 수준을 사용할 때 관찰된 결과를 보여줍니다.

트랜잭션 1 트랜잭션 2 SQL Server SERIALIZABLE Babelfish SERIALIZABLE

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

없음

없음

UPDATE employee SET age=5 WHERE age=10;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

SELECT * FROM employee;

트랜잭션 2는 트랜잭션 1이 커밋될 때까지 차단됩니다.

트랜잭션 2는 차단 없이 진행됩니다.

트랜잭션의 유휴 상태

UPDATE employee SET age=35 WHERE age=30;

없음

없음

COMMIT

트랜잭션의 유휴 상태

트랜잭션 1이 성공적으로 커밋됩니다.

트랜잭션 1이 먼저 커밋되고 커밋을 완료할 수 있습니다.

트랜잭션의 유휴 상태

COMMIT

트랜잭션 2가 성공적으로 커밋됩니다.

직렬화 오류로 인해 트랜잭션 2 커밋이 실패하고 전체 트랜잭션이 롤백되었습니다. 트랜잭션 2를 재시도합니다.

SELECT * FROM employee;

트랜잭션의 유휴 상태

두 트랜잭션의 변경 사항이 모두 표시됩니다.

트랜잭션 2가 롤백되었습니다. 트랜잭션 1의 변경 사항만 표시됩니다.

Babelfish에서는 모든 동시 트랜잭션이 SERIALIZABLE 격리 수준에서 실행되는 경우에만 직렬화 이상이 발생할 수 있습니다. 다음 표에서는 위 예제를 사용하되 트랜잭션 2를 REPEATABLE READ 격리 수준으로 설정해 보겠습니다.

트랜잭션 1 트랜잭션 2 SQL Server 격리 수준 Babelfish 격리 수준

BEGIN TRANSACTION

BEGIN TRANSACTION

없음

없음

SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;

SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;

없음

없음

SELECT * FROM employee;

트랜잭션의 유휴 상태

없음

없음

UPDATE employee SET age=5 WHERE age=10;

트랜잭션의 유휴 상태

없음

없음

트랜잭션의 유휴 상태

SELECT * FROM employee;

트랜잭션 2는 트랜잭션 1이 커밋될 때까지 차단됩니다.

트랜잭션 2는 차단 없이 진행됩니다.

트랜잭션의 유휴 상태

UPDATE employee SET age=35 WHERE age=30;

없음

없음

COMMIT

트랜잭션의 유휴 상태

트랜잭션 1이 성공적으로 커밋됩니다.

트랜잭션 1이 성공적으로 커밋됩니다.

트랜잭션의 유휴 상태

COMMIT

트랜잭션 2가 성공적으로 커밋됩니다.

트랜잭션 2가 성공적으로 커밋됩니다.

SELECT * FROM employee;

트랜잭션의 유휴 상태

두 트랜잭션의 변경 사항이 모두 표시됩니다.

두 트랜잭션의 변경 사항이 모두 표시됩니다.

도움이 필요하십니까?

프라이버시사이트 이용 약관쿠키 기본 설정
© 2025, Amazon Web Services, Inc. 또는 계열사. All rights reserved.