11g roadshow, part 4

Последняя часть моего рассказа об 11g roadshow.

Она посвещена наиболее "раскрученной" новинке в 11g - real application testing.

Рекомендую посмотреть презентацию этой технологии.

Ну и ниже мои комментарии:

Во-первых почему "real" - потому что проигрываться на тестовой систем будут ваши реальные транзакции с боевой системы. Т.е. Вам не нужно придумывать нагрузку, а нужно ее "захватить".

Делается это очень просто - на производственной системе включается ..трассировка на все сессии. Product manager пояснил, что все очень оптимально, на диск пишутся не сырые trace file, а уже в binary формате.

В принципе уже в 9i существовала возможность писать трассировки в кольцевой буфер в памяти и сбрасывать его на диск время от времени. Мне кажется данный механизм и используется. Только не было доступно извне, когда буфер заполнился, поэтому простым смертным это было тяжело использовать.


Знание как захватывается нагрузка дает нам:

- Прямо перед включением захвата нужен полный backup. Чтобы затем его восстановить на тестовой систем. Это повысит аккуратность "проигрывания". В противном случае часть транзакций, скажем, не найдет "своих" счетов.

- Нужно заготовить серьезное дисковое пространтсво под хранение данных

- Нужно приготовиться к уменьшению производительности.
Конечно, будет какое-то проседание производительности для конечного пользователя. В свое время мы исследовали как проседает производительность при включении обычной трассировки. Если это обычное OLTP приложение то можно оценить примерно в 10%


- Будут затрачены доп. ресурсы на захват

Ребята из внутренней группы тестирования провели тесты, с целью узнать накладные расходы. Так вот, для OLTP это примерно 10% доп CPU времени, для приложения, которое осуществлят массовую загрузку данных - в среднем 20%, но может доходить и до 40%


Проигрывание может осуществляться как в реальном режиме времени (т.е. с теми задержками которые были у Вас, так и в стресс-режиме - он позволят проиграть всю захваченную нагрузку быстрее)

Кочено гарантируется, что транзакции будут проигрываться в правильном порядке.

Можно ли осуществлять захват отдельных пользовательских сессий ? По документации можно, но по bug report'ам похоже, что пока это не работает.

Из общих соображений понятно, что поскольку все захвачено в binary виде, то нет возможности вмешаться в SQL код. Скажем Вы догадались, какие SQL плохие, но никак изменить их при проигрывании не можете.
Т.е. не можете оценить общий эффект от их модификации. Нужно менять на производственной системе, еще раз производить захват и проигрывание.

Для оценки производительности можно построить новые индексы, materialized view, можно даже тестироваться на новом patchset (или даже захватить на 10.2.0.4 а проиграсть на 11g) - но вот как работать с SQL планами при этом я не понял.

В заключение: несомненно, крайне полезная опция, несмотря на свою цену и некоторые ограничения при использовании.