Рівні ізольованості транзакцій

У ході читання твоїх книжок і відповідей у цьому форумі, а також керівництва "Oracle Database Concepts", У мене виникла низка питань про транзакції і рівнях ізоляції.

1. Ти стверджуєш, що використання рівня ізольованості serialazable не знижує загальну продуктивність:


http://asktom.oracle.com/pls/ask/f?p=4950:8:2084716298042783235::NO::F4950_P8_DISPLAYID, F4950_P8_CRITERIA: 776821414494,


Проте в керівництві Oracle Database Concepts, Мені здається, стверджується, що рівень ізольованості serializable призводить до зниження продуктивності в порівнянні з read committed:


http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c21cnsis.htm # 2799


Процитую розділ "Read Committed Isolation“:



"Рівень ізольованості читання зафіксованого (read committed) може забезпечувати більш високу ступінь паралелізму за рахунок підвищення ймовірності отримати неузгоджені результати в деяких транзакціях з-за неповторяемости при читанні і читання фантомів. "


"У багатьох високопродуктивних середовищах з великою частотою транзакцій потрібно б о льшая пропускна здатність і більш швидкий відгук, ніж може забезпечуватися рівнем ізольованості serializable.”


Це що, розходження в масштабах?


2. Якщо суттєвої різниці продуктивності не спостерігається (у контексті певної програми, звичайно), мені здається, краще використовувати рівень ізольованості serializable замість read committed, щоб отримати повторюваність при читанні і т.д.


Чи є у тебе якісь критерії визначення того, який рівень ізольованості встановлювати? Мене цікавлять, перш за все, додатки ООТ (OLTP). Я не можу придумати причину встановлювати рівень, відмінний від serializable, але хотілося б запитати у більш досвідченої людини.


3. Далі, у наступному обговоренні ти дав зрозуміти, що сеанс не завжди знаходиться в транзакції, якщо використовується рівень ізольованості read committed (припускаючи, що якісь SQL-оператори були виконані):


http://asktom.oracle.com/pls/ask/f?p=4950:8:2084716298042783235::NO::F4950_P8_DISPLAYID, F4950_P8_CRITERIA: 8913646338893,


Аналогічне твердження ти робиш у розділі 4 книги Expert One-on-One (“Oracle для професіоналів"В моєму перекладі – прим. В.К.),"Оператори управління транзакціями":" Транзакція неявно починається з першого оператора, що змінює дані …".


Однак, в керівництві Oracle Database Concepts досить ясно стверджується, що сеанс знаходиться в транзакції, якщо виконаний хоч один SQL-оператор:


http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96524/c01_02intro.htm # 54005


Не міг би ти дозволити мої сумніви на цей рахунок?


Відповідь Тома Кайта


1) Я не згоден з їх висновками.


Ми запускаємо тести TPC-C з рівнем ізольованості serializable (це потрібно за умовами тесту). Я б навіть сказав, що в багатьох випадках вірно зворотне – рівень ізольованості serializable є одним із способів досягнення високої пропускної здатності і прискорити час відповіді, прчем, з мінімальним об'ємом коду.


2) Ні, так робити не варто. Рівень ізольованості serializable підвищить ймовірність невдалого завершення транзакції при збільшенні її тривалості. Він підходить як раз для середовищ з великою частотою транзакцій, коли вони короткі і виконуються швидко, читаючи і змінюючи дані. Такий рівень ізольованості не підходить для багатьох систем.


Я використовую майже винятково рівень read committed. Рівень serializable я використовую тільки коли необхідна узгодженість з читання декількох операторів, що потрібно рідко, а якщо і потрібно, то, в основному, для побудови звітів – для них же я зазвичай використовую транзакції лише для читання.


3) Оператор select не починає транзакцію на рівні ізольованості читання зафіксованого (read committed). Вона починається при зміні даних. На рівні serializable початок транзакції відзначає оператор set (Він повинен бути першим)


Розглянемо приклад:

ops$tkyte@ORA920> select * from dual;

D

X

ops $ tkyte @ ORA920> set transaction isolation level serializable;

Transaction set.


Якби оператор select зазначав початок транзакції, оператор set transaction Не спрацювала б, як у наступному випадку:

ops$tkyte@ORA920> commit;

Commit complete.

ops$tkyte@ORA920> update emp set empno = 1 where rownum = 1;

1 row updated.

ops $ tkyte @ ORA920> set transaction isolation level serializable;
set transaction isolation level serializable
*
ERROR at line 1:
ORA-01453: SET TRANSACTION must be first statement of transaction


А наступний приклад показує, що оператор SET дійсно починає транзакцію:

 ops $ tkyte @ ORA920> set transaction isolation level serializable;

Transaction set.

ops$tkyte@ORA920> declare
2 pragma autonomous_transaction;
3 begin
4 delete from emp;
5 commit;
6 end;
7 /

PL/SQL procedure successfully completed.


Тепер виконаємо запит до таблиці emp – Якщо ми побачимо дані, значить, транзакція була розпочата, оскільки дані видаються в тому вигляді, як вони були на момент виконання оператора set transaction


ops$tkyte@ORA920> select empno from emp;

EMPNO
———-
1
7499
7521
7566
7654
7698
7782
7788
7839
7844
7876
7900
7902
7934

14 rows selected.

ops$tkyte@ORA920> commit;

Commit complete.

ops$tkyte@ORA920> select empno from emp;

no rows selected


Це доводить, що оператор SET був першим оператором в транзакції.


Фактично починають транзакцію, відзначаючи її початок, тільки оператори, що змінюють дані, і оператори set transaction.


Оператор select теж може почати транзакцію, якщо це select … for update, Але select … for update – Це, фактично, просто своєрідний оператор зміни даних.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*