Oracle Real Application Testing を使ってみよう！その1

2023年3月8日 Oracle Real Application Testing

1 はじめに
2 性能テストはいろいろ大変だ！
- 2.1 求められるテスト・ソリューション
3 RATって何？
4 RATの2つの機能
- 4.1 SQL Performance Analyzer (SPA)
- 4.2 Database Replay (DB Replay)
5 2つの機能の使い分け
6 次回へ続く！

はじめに

みなさん、こんにちは！まっつんです。
今回はOracle Real Application Testingに関して３回に分けてわかりやすく記載していきます。
第１回目です！宜しくお願いします。

プラチナホルダーでリーダーのまっつんの連載スタートです！

性能テストはいろいろ大変だ！

日頃システム開発者を悩ます問題の1つとして、システムテストや性能テスト、とりわけ性能テストについては、ミッション・クリティカルなシステムであるほど重要な工程でありながらも、開発期間等プロジェクト遅延の影響を受けて期間短縮を余技なくされるケースが多く見られます。

結果、テスト不足を起因とした品質の低下・リリースの遅延・スケジュールの圧迫からのさらなるテスト不足という負のスパイラルに陥ることは珍しいことではありません。

プロジェクトの計画段階において “性能テスト” は他のテストよりも軽視されがち
他の工程よりも後であることから、前工程での要件定義や設計フェーズで遅れの影響を受け、システム・カットオーバの日付を後ろ倒しにもできないため、結果としてテスト期間が削られる

求められるテスト・ソリューション

こうした悩みを解決する一助として、システムテスト・性能テストを効率化/自動化できるさまざまなツールが各社からリリースされています。

それらは、データベース性能を測るもの1つとっても、テストケースを自動で作成したり、WebブラウザなどのGUIベースとしたユーザーのアクティビティを網羅するものから、疑似業務アプリケーションとしてSQL発行を代行するだけのものまで、実に多岐にわたり多種多様です。

そんな中、オラクル社からもデータベースの性能テストを目的とするツールが提供されています。
それが Oracle Real Application Testing（以下、RAT）です。
今回はこのRATの、データベース性能を測る上での優位性や有効性などをツールの概要から紹介していきたいと思います。

オラクル社自ら提供しているDB性能を担保するツール、果たして実力のほどは？

RATって何？

RATは、オラクル社が提供する データベース性能を担保するための、プロアクティブな管理ツール で、以下の目的を掲げています。

アプリケーションのサービス品質の向上
迅速なアップグレードを可能にし、リスクを軽減
リスクの無いアップグレードと新しいテクノロジーの採用によりビジネスの俊敏性が向上
DBAの生産性を大幅に向上

RATを利用するには、Oracle Database Enterprise Edition での有償追加オプション「Oracle Real Application Testing」のライセンスが必要です。

ただし、後述する“STS”使用だけであれば Enterprise Edition だけでオプションは不要です。

ツールの実体は Enterprise Edition に機能として実装されているため、ライセンスがあれば別途インストールなどの作業なしにすぐ利用できます。

また、ほとんどのオペレーションがSQL、PL/SQLプロシージャでの操作ですのでDB管理者にとってはとっつきやすく習得も早いのではないでしょうか。

当然、Oracle Cloud にも対応していますので、オンプレ環境から Oracle Cloud へ移行時の性能検証にも有効な手段です。

RATの2つの機能

RATは、大きく分けて以下の2つの機能「SQL Performance Analyzer (SPA)」と「Database Replay (DB Replay)」で構成されています。

SQL Performance Analyzer (SPA)

SPAでは、以下のことが可能です。

本番環境のSQLワークロードをテスト環境で再現、SQL単位のパフォーマンス比較
実行計画が変動するSQLの特定、性能劣化が予測されるSQLについては事前にチューニング

SPAでは、SQLのレスポンス・タイムについてのテストがメインになります。
システム変更前/変更後など2つの環境で、SQL単位での比較を実施し、改善に役立つレポートを生成します。

SPAの特徴

SQL単体テスト向き
本番環境で実行された問合せと、その実行計画を記録
テスト環境で問合せを再実行し、パフォーマンスと実行計画比較レポートを作成

主な手順概要

[SPA手順1] SQLチューニング・セット(STS)作成
– 本番環境でSQLワークロード(指定期間に実行されたSQL群の情報)を取得、SQL Tuning Set (STS) に格納
[SPA手順2] SQLチューニング・セット(STS)移動
– STSを本番環境からテスト環境にExport/Importで移動
[SPA手順3] SQLテスト
– システム変更の前にSQLを実行し、変更前のベースラインを取得 (本番で取得済のものを利用することで省略も可能)
– システム変更を実施し、同様にSQLを実行
[SPA手順4] レポート生成
– 比較レポート生成、STS全体とSQL単位についてそれぞれのパフォーマンス情報を比較

SPA実行の流れ

手順の詳細については次回以降に紹介します。

Database Replay (DB Replay)

DB Replay では、以下のことが可能です。

本番環境と同じ負荷を利用したテストの実現
業務アプリケーションを使用せずにトランザクションを完全再現

DB Replayでは、本番環境におけるトランザクション・セッションなどの実際のワークロードを記録し、テスト環境などで再現し比較レポートを生成します。

DB Replayの特徴

システム・テスト向き
本番環境で実行されたトランザクションを時系列に記録
テスト環境で本番環境の負荷を忠実に再現
本番環境とテスト環境で自動的に取得された統計情報を元にパフォーマンス比較レポートを作成

手順概要

[DBR手順1] ワークロードのキャプチャ
– キャプチャした情報は、キャプチャファイルとしてファイルに格納
[DBR手順2] キャプチャファイルのコピー
– コピーしたキャプチャファイルを、テスト環境側でリプレイ可能なフォーマットに変換
[DBR手順3] ワークロードのリプレイ
– コピー先環境でのワークロードの再現
[DBR手順4] レポートの生成
– さまざまな観点でデータベース全体としてのパフォーマンス情報や負荷情報が比較して分析することができる

DB Replay実行の流れ

手順の詳細については次回以降に紹介します。

2つの機能の使い分け

2つの機能「SQL Performance Analyzer (SPA)」と「Database Replay (DB Replay)」のそれぞれの特徴を以下にまとめておきます。

	SQL Performance Analyzer(SPA)	Database Replay(DB Replay)
目的	単体SQLの応答時間の変化の確認	システム全体のスループットの変化の確認
テスト対象	特定の重要なSQL	本番環境での負荷全体
何ができる	SQL応答時間の変化	テスト環境での本番負荷の再現
仕組み	STSから前後の実行計画/統計値の比較	本番負荷の再現