x10 или кое-что о событиях ожидания

Update 1. В комментариях отозвался автор презентации, цитата: "главное здесь слова, жесты, мимика, а презентация всего лишь фон". 

Я случайно обнаружил весьма занятную презентацию, которую судя по url читали на вот этом событии. Я обратил внимание на слайд 23, картинку с которого вы видите слева. Текст на слайде гласит:  "суммарное время на операции ввода-вывода сократилось в 10 раз". Это, несомненно потрясающий результат. Наверняка это еще и говорит о том что скорость обработки возрастет в 10 раз, не так ли ? Сейчас мы это узнаем. 

Приглядевшись к списку событий ожидания я увидел, что складываются яблоки и апельсины - события ожидания foreground процессов вместе с ожиданиями background процессов.  Для конечного пользователя конечно же интересны только события ожидания, которые могут испытывать foreground процессы. С какой там скоростью работает db writer (если он справляется) пользователям не важно. Складывать такие события ожидания это достаточно грубая ошибка, говорящая о непонимании как архитектуры так и  response time formula : 

Время ответа конкретной сессии определяется по формуле 

R = W + S, где W суммарное время ожидания данной сессии,  S суммарное время обслуживания сессии
Некоторые события ожидания вместе с примечанием (Foreground  и/или Background) процесс могут их испытывать (картинка из книги Oracle Wait Interface)

Мы видим что (например) log file parallel write это событие ожидания для background процесса и к поэтому никак не может влиять на производительность сессии конечного пользователя.   Но автора презентации это не останавливает и он суммирует это время с  db file sequencial read.

Таким образом изо всех сил складывались события, в том числе не относящиеся к пользовательским сессиям.  Повторюсь, такая суммарная цифра бессмысленна, кроме как блеснуть ей в PowerPoint.

Теперь давайте посмотрим на действительно пользовательские события ожидания: 

- db file sequental read было 5.91  ms а превратился в cell single block physical read c 0.91 ms 

- log file sync было 26 ms а превратилось в 12 ms 

- db file scattered read было 5.3 ms а превратилось в cell multiblock physical read 2.04 ms 

- read by other session было 7 ms,  а стало 14 ms 

- direct path read - было 3 ms, стало 1 ms (хотя они все должны были бы превратиться в cell smart table scan)

Что можно сказать - у базы данных явно проблемы с log file sync, и следовало бы обратить внимание на эту проблему.   Read by Other Sesson =  7 ms это очень много, больше времен ввода-вывода. Это надо срочно исправлять, искать сегмент  за который идет такая конкуренция. Улучшились времена по вводу - выводу ? Да, соглашусь.  Теперь, если вы обратите внимание на предыдущий слайд, стр 22, вы увидите что DB CPU это 89% от всего времени, а I/O ~6%. На основании имеющихся данных, у данной базы I/O не является узким местом.Показатель Parse Cpu to Parse Elapsed ~50% косвенно подтверждает что присутствуют  проблемы с процессорным временем (возможно из-за парсинга)

Возвращаясь к Response time formula Service time занимает у нас 89% времени ожидания (например logical reads, parsing), мы же в это время пытаемся сократить в 10 раз I/O  что не даст нам видимого пользователями эффекта.

PS Мне стало интересно, как же Oracle допустил такой ляп ? Поиск подсказывает,  что данная презентация сделана на основе вот этой, с OpenWorld. И конечно оригинальная версия не содержит ничего такого и никаких в 10 раз. Видимо 10 раз появляется исключительно в результате пересечения атлантического океана -)