Уважаемые подписчики рассылки!
Этот короткий выпуск посвящен выбору уровня изолированности транзакций.
По мотивам интересной публикации на сайте
Тома Кайта
от 27 сентября 2003 года.
Мне в гостевой задали следующий вопрос по прошлому выпуску рассылки:
В оригинале статьи Oracle_trace - the Best Built-in Diagnostic Tool? by Jonathan Lewis есть примечание редактора
Editor"s Note: Shortly after this article was published, it came to light that the Oracle 9.2 Performance Guide and Reference has now identified Oracle Trace as a deprecated product.
-------------------------- Oracle9i Database Performance Tuning Guide and Reference Release 2 (9.2) Part Number A96533-02 Chapter 12 Note: Oracle Trace will be deprecated in a future release. Oracle Corporation strongly advises the use of SQL Trace and TKPROF instead.Немножко странно, что эти нюансы оказались утеряны при переводе. Или это как-то связано с названием статьи?
Я ответил так:
Да, действительно, сейчас там есть такое примечание. К сожалению, в то время, когда я скачивал себе оригинал (14.10.2002), этого примечания еще не было.
Тем не менее, в версии 9.2 oracle_trace есть и работает, а 10g еще только выходит и далеко не всеми будет использоваться... Думаю, на ближайших лет 5 списывать oracle_trace еще рано!
А про TKPROF Том Кайт писал (а я переводил и публиковал) и так уже немало...
Привет, Том!
В ходе чтения твоих книг и ответов в этом форуме, а также руководства
"Oracle Database Concepts", у меня возник ряд вопросов о транзакциях
и уровнях изоляции.
1. Ты утверждаешь, что использование уровня изолированности serialazable не снижает общую производительность:
Однако в руководстве 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-операторы были выполнены):
Аналогичное утверждение ты делаешь в главе 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 - это, фактически, просто своеобразный оператор изменения данных.
Оригинал обсуждения этого вопроса можно найти здесь.
Copyright © 2003 Oracle Corporation
Все вышедшие выпуски рассылки можно найти на сайте рассылки. Там же реализована возможность поиска материалов по ключевым словам (с помощью Google...)
Перевод очередной статьи Джонатана Льюиса, про стабилизацию плана оптимизатора и хранимые шаюблоны, опубликованной на сайте DBAzine.com.
С наилучшими пожеланиями,
В.К.
|
|