Отправляет email-рассылки с помощью сервиса Sendsay

Открыто о СУБД Oracle на русском

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "СУБД Oracle "с нуля"" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Октябрь 2003   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Автор
Сергей

Статистика

10.773 подписчиков
-8 за неделю
←   Все выпуски   →

Открыто о СУБД Oracle на русском : выбор уровня изолированности транзакций


Информационный Канал Subscribe.Ru

Выпуск 51

Уважаемые подписчики рассылки!

Этот короткий выпуск посвящен выбору уровня изолированности транзакций. По мотивам интересной публикации на сайте Тома Кайта от 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 не снижает общую производительность:

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

Оригинал обсуждения этого вопроса можно найти здесь.

Copyright © 2003 Oracle Corporation

Прежние выпуски

Все вышедшие выпуски рассылки можно найти на сайте рассылки. Там же реализована возможность поиска материалов по ключевым словам (с помощью Google...)

В следующем выпуске

Перевод очередной статьи Джонатана Льюиса, про стабилизацию плана оптимизатора и хранимые шаюблоны, опубликованной на сайте DBAzine.com.

С наилучшими пожеланиями,

  В.К.

http://subscribe.ru/
E-mail: ask@subscribe.ru 		Отписаться
Убрать рекламу
В избранное