Real Application Testing – механизмы промышленного тестирования версий и изменений
Жизнь не стоит на месте, и вокруг нас все постоянно меняется. Чтобы не отстать от конкурентов, мы вынуждены менять компьютеры в ЦОД, добавлять процессоры и память, патчировать ОС и менять ее версию, патчировать СУБД и переходить к новым более мощным и современным версиям СУБД. В процессе работы приходится постоянно менять параметры работы СУБД и структуры данных, создавать новые объекты в БД (индексы, материализованные представления и т.д.), менять архитектуру вычислительной системы (например, переходить от одного компьютера к кластеру или GRID), выполнять рекомендации службы технической поддержки, опытных коллег, руководства и т.д.
К сожалению, любые из этих необходимых действий могут привести не к улучшению работы системы, а к ухудшению или остановке работы. Автор знает примеры совершенно безобидных изменений, которые резко ухудшали скорость работы системы. А уж апгрейд на новую версию СУБД – это хуже пожара. Зная все это, администраторы БД оттягивают внесение изменений до последнего момента, не желая рисковать. Единственная возможность решить эту проблему – позволить заранее протестировать любые из перечисленных изменений (ОС, оборудования, структур данных, архитектуры) на тестовой системе (до их выполнения на промышленной системе) и оценить последствия. Для этого используется тестовая копия БД; у некоторых производителей в качестве тестовой можно временно использовать резервную БД (Oracle Snapshot Standby).
Существует много пакетов, позволяющих имитировать нагрузку на тестовой системе для выполнения функционального и нагрузочного тестирования. Однако все эти пакеты создают не реальную, а синтетическую нагрузку, дороги, требуют длительного времени для анализа работы системы и создания тестовых скриптов. И в результате многие проблемы так и остаются не выявленными.
Появившийся у Oracle продукт RAT (Real Application Testing), очевидно, вскоре будет реализован в большинстве СУБД, т.к. он позволяет на реально работающей под нагрузкой производственной системе захватить (с минимальными накладными расходами) реальную нагрузку (с учетом времени выполнения, одновременности, зависимости операций) и воспроизвести эту нагрузку на тестовой БД, не устанавливая там приложение.
Захват и проигрывание нагрузки легко выполнить, и они позволяют выявить появившиеся/ пропавшие/изменившиеся после выполнения изменений ошибки, изменения в планах и результатах выполнения реальных SQL, проблемы снижения производительности как всей системы, так и отдельных запросов. После анализа результатов система дает рекомендации по улучшению работы SQL, позволяет попробовать различные варианты оптимизации работы. Откатывая тестовую БД назад, можно тестировать различные изменения и их совокупность. И только после того, как все проблемы выявлены и решены, изменения можно произвести в производственной среде.
Поскольку захват, проигрывание, анализ, оптимизация проводятся в автоматическом или автоматизированном режиме, они не требуют много времени от администратора БД. Впервые появилась возможность значительно снизить риски перехода от старой версии СУБД к новой, более совершенной. Регулярный апгрейд СУБД становится обычным рутинным делом (рис 3).
Рис. 3. Oracle Real Application Testing
