ターミナル・ウィンドウを開き、SQLファイルが含まれるディレクトリで次のコマンドを入力します。 setup_demo.shスクリプトは適切なデータベース・オブジェクトを作成し、このチュートリアルで使用するデータをロードします。 このスクリプトの実行には数分かかる場合があります。

cd <your working directory>/spa
./setup_demo.sh

これで、run_workload_50q.shスクリプトを実行して、先ほどロードしたデータに対するワークロードを生成できるようになりました。 以下のスクリプトを実行します。

./run_workload_50q.sh 2

注： '2'は、スクリプト内で問合せが実行される回数を示しています。 このスクリプトの実行には数分かかる場合があります。

この他に、create_sts.sqlスクリプトを実行して、先ほど実行したワークロードのSQL Tuning Setを作成する必要があります。 以下のコマンドを実行します。

sqlplus apps/apps
@create_sts

ブラウザを起動し、次のURLを入力します。

http://<hostname>:1158/em

ユーザー名にsystemを入力し、パスワードを指定し、「Login」をクリックします。

「Software and Support」タブをクリックします。

Real Application Testingの下の「SQL Performance Analyzer」を選択します。

SQL Performance Analyzer Workflowsの下の「Guided Workflow」を選択します。

最初に実行するタスクは、SQL Tuning Setに基づいたSQL Performance Analyzerタスクの作成です。 このタスクの「Execute」アイコンをクリックします。

NameにOBE1を入力し、SQL Tuning Setで懐中電灯型のアイコンをクリックします。

SQL Tuning Setで「HR_WORKLOAD」を選択し、「Select」をクリックします。

「Create」をクリックして、SQL Performance Analyzeタスクを作成します。

これで初期の環境のSQL Tuning Setを作成および再生でき、変更を加えた後に比較するための基準を作成できます。 Guided Workflowの2番目の手順で、「Execute」アイコンをクリックします。 SQL Tuning Setを再生すると、SQL Tuning Set内のSQLはアプリケーションを再起動することなく、環境に対して1つずつテストを実行します。

NameにOBE_BEFORE_CHANGEを入力し、「Trial environment established」のチェック・ボックスにチェックを入れて、「Submit」をクリックします。

ジョブが実行されます。 ジョブが完了するまで、「Refresh」を数回クリックします。 ジョブの実行には1～2分かかる場合があります。

緑色のチェックが表示されたら、ジョブは完了です。

次に、変更を実行する必要があります。 このシナリオでは、ここでパッチセットを適用します。 ターミナル・ウィンドウに戻り、make_changes.shスクリプトを実行します。

./make_changes.sh

これで、パッチセットを適用したSQL Tuning Setを再生し、比較を実行できるようになりました。 Guided Workflowの3番目の手順で、「Execute」アイコンをクリックします。

NameにOBE_AFTER_CHANGEを入力し、「Trial environment established」のチェック・ボックスにチェックを入れて、「Submit」をクリックします。

ジョブが実行されます。 ジョブが完了するまで、「Refresh」を数回クリックします。 これで、2つの再生ジョブを比較できる状態になりました。 Guided Workflowの4番目の手順で、「Execute」アイコンをクリックします。

Trial 1 NameにOBE_BEFORE_CHANGEが選択されており、またTrial 2 NameにOBE_AFTER_CHANGEが選択されていることを確認します。 Comparison Metricで「Buffer Gets」を選択し、「Submit」をクリックします。

4番目のタスクが完了したら、5番目の手順の「Execute」アイコンをクリックして、比較レポートを表示します。

パッチセットを適用すると、多くのSQLは改善されますが、ここでは小さなリグレッションが発生しています。 Regressionの棒グラフをクリックします。

詳細を検証する必要のあるSQL文が4つあります。 ブレッドクラムをクリックして、前のウィンドウに戻ります。

SQL Performance Analyzer Task Reportページで、「Run SQL Tuning Advisor」をクリックします。

Tuning Task NameにOBE_TUNE_REGRESSED_SQLと入力し、「OK」をクリックします。

チューニング・タスクの作成に成功しました。 「Advisor Central」ブレッドクラムをクリックします。

ジョブが完了するまで待ちます。 これには、数分かかる場合があります。 ジョブが完了したら、「OBE_TUNE_REGRESSED_SQL」リンクをクリックします。

SQL Tuning Result Summaryを見ると、4つのSQL文が調査され、それぞれの文に対して推奨されるSQLプロファイルが見つかったことが分かります。 「Show all results」をクリックして、詳しい調査結果を確認します。

各SQL文に対し、SQLプロファイルが推奨されたことが確認できます。 「Implement All SQL Profiles」をクリックします。

実装を確定するため、「Yes」をクリックします。

SQLプロファイルが作成されました。 「Advisor Central」ブレッドクラムをクリックします。

「SQL Performance Analyzer」リンクを選択します。

SQL Performance Analyzer Tasksで、「OBE1」リンクを選択します。

SQL Trialsで、「Create SQL Trial」をクリックします。

NameにOBE_AFTER_TUNE_REGRESSED_SQLを入力し、「Trial environment established」のチェック・ボックスにチェックを入れて、「Submit」をクリックします。

SQL再生ジョブの作成に成功しました。 ジョブが完了するまで、「Refresh」をクリックします。 これで、OBE_BEFORE_CHANGEトライアルとOBE_AFTER_TUNE_REGRESSED_SQLトライアルとの比較レポートを実行できるようになりました。 「Run SQL Trial Comparison」をクリックします。

Trial 1 Nameで「OBE_BEFORE_CHANGE」を選択し、Trial 2 Nameで「OBE_AFTER_TUNE_REGRESSED_SQL」を選択します。 Comparison Metricで「Buffer Gets」を選択し、「Submit」をクリックします。

比較結果が作成されました。 新しく作成された比較レポートのメガネ・アイコンをクリックします。

この時点で何もリグレッションがないことが確認できます。 また、パフォーマンスが87%改善されるため、チューニング済みSQLを使用してパッチセットを適用しても問題ありません。

「SQL Performance Analyzer」リンクを選択します。

ターミナル・ウィンドウを使用し、DBAユーザーとしてSQL*Plusセッションを開始したら、flush.sqlスクリプトを実行して各種のSGAキャッシュを空にします。

sqlplus / as sysdba
@flush

Oracle Enterprise Managerに戻り、「Exadata Simulation」をクリックします。

Task NameにCOMPARE_EXADATAと入力し、SQL Tuning SetにAPPS.HR_WORKLOADと入力したら、「Submit」をクリックします。

SQL Performance Analyzerタスクが実行されます。 「Refresh」をクリックしてタスクの進捗を見守るか、またはタスクが完了するまでそのまま待ちます。

タスクが完了したら、「COMPARE_EXADATA」リンクをクリックします。

一方ではExadataシミュレーションが無効化され、もう一方ではExadataの使用がシミュレートされた状態で、2つのSQLトライアルが調査されたことが分かります。 また、2つのSQLトライアルを比較したレポートも提供されています。 新しく作成された比較レポートのメガネ・アイコンをクリックします。

比較レポートを確認すると、このワークロードに対してExadataを使用した場合、ストレージとデータベース・インスタンス間で転送されるデータ量が大幅に削減されることが分かります。

ページ下部までスクロールし、Top 10 SQL Statements Based on Impact on Workloadの最後に表示されたSQL文へのリンクをクリックします。

SQL Textラベルの隣のプラス・ボタンをクリックします。

これで、完全なSQL文が表示されました。 このSQL文は2つの表を結合し、非常に限られた属性値を持つレコードのみを返しています。

下方向にスクロールして、Plan Comparisonセクションを表示します。 Exadataを使用しない場合、全表スキャン（TABLE ACCESS FULL）が2回実行されていることが分かります。 非定型の問合せをサポートするための索引は定義されていない場合もあるため、データウェアハウス環境ではこれは非常によくあることです。 Exadataを使用した場合、フィルタ条件がExadataストレージ・サーバーに対して直接適用されていることが分かります（TABLE ACCESS STORAGE FULL）。 これによって、フィルタ条件に合った行のみがデータベース・サーバーに返されるため、この文に対するI/Oインターコネクト・バイトが大幅に少なくなります。

ページ上部にある「SQL Performance Analyzer Task Report」ブレッドクラムをクリックし、比較レポートに戻ります。

Exadataを使用すると、このワークロードに対してストレージからデータベース・サーバーへ返される情報量が激減することが確認できました。 これにより、データベース・サーバーはより効率的にワークロードを処理できるようになるため、全体的なパフォーマンスも向上すると考えられます。

ターミナル・ウィンドウに戻り、reset_demo.shスクリプトを実行します。

./reset_demo.sh

この時点で、このOBEチュートリアルを再度実行できます。 ただし、その際には、環境のセットアップのトピックにある手順1を実行する必要はありません。 ワークロードを実行する手順2から開始できます。