В ходе чтения твоих книг и ответов в этом форуме, а также руководства "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 - это, фактически, просто своеобразный оператор изменения данных.