Oracle Maximum Availability Architectureホワイト …...ExadataでのSiebel実行 3...

ExadataでのSiebel実行

Oracle Maximum Availability Architectureホワイト・ペーパー

2010年10月


概要 ..................................................................................................................................... 2

はじめに .............................................................................................................................. 4

プロジェクトの計画 ........................................................................................................... 5

準備 ................................................................................................................................ 5

テスト ............................................................................................................................ 7

移行 ................................................................................................................................ 9

Oracle Real Application Testingを使用したSiebelのテスト ............................................. 10

Real Application Testing向けのデータベース・パッチ・レベル ................................. 10

SQL Performance Analyzerのベスト・プラクティス ................................................. 10

Database Replayのベスト・プラクティス .................................................................. 11

Database Machine上でのSiebel実行に関するベスト・プラクティス ............................. 15

データベース層の構成 ................................................................................................. 15

Siebel層の構成 ............................................................................................................ 16

バックアップとリストア ............................................................................................. 18

MAAラボでのベスト・プラクティスの検証 ..................................................................... 18

テスト・ワークロード ................................................................................................. 18

テスト環境の構成 ........................................................................................................ 19

データベースの圧縮テスト ......................................................................................... 19

Database Replayのテスト ........................................................................................... 19

パフォーマンス・テスト ............................................................................................. 21

負荷テスト ................................................................................................................... 21

結論 ................................................................................................................................... 24

参考資料 ............................................................................................................................ 25


2

概要

Sun Oracle Database Machineは、データウェアハウス・アプリケーションやOLTPアプリケーショ

ン、またデータベースの統合に最適なデータベース・プラットフォームであり、高速InfiniBandファ

ブリックを介して接続された業界標準サーバー（コンピューティング・サーバーとストレージ・サー

バー）によるスケーラブルなグリッドです。すべてのDatabase Machineは高度に最適化されており、

すぐに実行できるように事前構成されています。さまざまな機能を持つSun Oracle Database

Machineは、Siebelデータベースのホスティング・ソリューションとして簡単に配置できる上に、高

水準のパフォーマンスと可用性を実現します。

このホワイト・ペーパーでは、既存のSiebel実装からSun Oracle Database Machineへ移行して、

卓越したパフォーマンスと最大限の可用性を達成するためのベスト・プラクティスについて説明

します。


3

ベスト・プラクティスを開発し、検証するため、Maximum Availability Architecture（MAA）構成に

よるクォーター・ラックのSun Oracle Database Machine上にSiebel 8.0.0.8 Financial Servicesアプ

リケーションを配置しました。MAAは、Oracle Real Application Clusters、Oracle Data Guard、フ

ラッシュバック・テクノロジーといったオラクルの高可用性テクノロジーを実装するためのベス

ト・プラクティスによるブループリントです。

データベースの動作とパフォーマンスは複数のテスト・ワークロードを使用して評価され、次の結

果が得られました。

コール・センター、パートナー・サービス、Webサービスの組合せで構成された3万の同時ユー

ザーによって、1時間に443,334件のビジネス・トランザクションが処理され、エンドユーザーの

平均応答時間として0.12秒が達成されました。データベース・サーバーのCPU使用率は23%、ス

トレージI/O処理数は1秒当たり9,571に過ぎなかったため、同じプラットフォーム上にその他の

アプリケーションを統合する余力が残されました。

Siebel EIMを特別なチューニングなしで使用して、1分当たり37,037件の顧客がインポートされ

ました。

さらにチューニングを実施することでパフォーマンスをいっそう向上させることも可能ですが、こ

のホワイト・ペーパーの目的は全体的なベスト・プラクティスの説明であり、最大限のパフォーマ

ンスを達成することではない点に注意してください。

新しいプラットフォームへ移行する場合、実際の移行の前に徹底的なテストを実施することが常に

重要になります。一般的に、テストはその場限りの手段を通じて実施されますが、Oracle 11gのReal

Application Testingを利用すると、はるかに包括的で系統立った方法を使用して、既存の本番ワーク

ロードを新しいプラットフォームでテストすることができます。このホワイト・ペーパーでは、Real

Application Testingを使用したDatabase Machineへの移行に関するベスト・プラクティスについて説

明します。アプローチの検証に使用されたテスト・ワークロードはOracle Real Application Testing

を使用して取得され、相違を最小限に抑えて再生されました。

またExadata Hybrid Columnar Compressionを使用した場合のSiebelデータの動作を示す例として、

Exadata Hybrid Columnar Compressionを使用したSiebelデータ表で10対1の圧縮率を達成した金融

顧客での成果について紹介します。


4

はじめに

このホワイト・ペーパーでは、卓越したパフォーマンスと最大限の可用性を達成するためのベスト・

プラクティスを使用して、SiebelデータベースからDatabase Machineへ移行する方法についての推奨事

項を提供します。

このホワイト・ペーパーは、次の各章に分かれています。

プロジェクト計画 - 移行を成功させるための鍵となる準備作業とテスト作業。後半のセクション

へのリンクと外部ドキュメントへのリンクを含みます。

Oracle Real Application Testingを使用したSiebelのテスト - SiebelのテストにReal Application

Testingを使用する際の詳しいベスト・プラクティス。

Database Machine上でのSiebel実行に関するベスト・プラクティス - Siebel実行時に優れたパ

フォーマンスと最大可用性を実現するための推奨事項。

MAAラボでのベスト・プラクティスの検証 - 推奨事項とベスト・プラクティスを開発し、検証

するために使用されたオラクルの内部テスト。このテストには、Siebel 8.0.0.8とOracle Database 11g

Release 2が使用されました。


5

プロジェクトの計画

Database Machineへ移行する場合、最終的な本番稼働を成功に導くには入念な準備とテストが必要に

なります。この章では、準備、テスト、移行の各フェーズについて詳しく説明します。

準備

Database Machineへの移行準備は、詳細なプロジェクト手順を計画して、可能性のある障害物を特定

できるように、できる限り早期に開始する必要があります。ここからは、考慮する必要のある領域

について詳しく説明していきます。

製品バージョンとパッチ・レベル

Database Machine、現在のデータベース・サーバー、Siebelに対して必要な製品バージョンとパッチ・

レベルを特定し検証します。

SiebelデータベースとSiebelアプリケーションのバージョン

Database MachineでサポートされるデータベースはOracle Database 11g Release 2のみであるため、現在

のSiebel実装で以前のバージョンが使用されている場合はアップグレードが必要になります。Exadata

へ移行する前にデータベース・アップグレードを実行することが推奨されています。

また、Oracle Database 11g Release 2でサポートされているSiebelバージョンへのアップグレードまた

はパッチ適用が必要になる場合もあります。これらのパッチ適用やアップグレードは、Database

Machineへの移行を始める前に、独立した作業として実行すると良いでしょう。

Database Machineのパッチ・レベル

最新のOracleデータベース・バージョンとバンドル・パッチ・レベルが、Database Machineのパッチ・

レベルを決めるための出発点になります。詳しくは、『Support Note 888828.1 - Database Machine and

Exadata Storage Server 11g Release 2 (11.2) Supported Versions』を参照してください。また、次のパッ

チ適用が必要になる場合もあります。

Real Application Testingに対する推奨パッチ。詳しくは、Real Application Testing向けのデータベー

ス・パッチ・レベルの項を参照してください。

場合によっては、現在の本番環境で発見された問題に対するパッチが、最新のDatabase Machine

パッチ・レベルで修正されていない可能性もあります。

現在の本番データベースに対するReal Application Testingのパッチ

場合によっては、SQL Performance Analyzer（SPA）やDatabase Replayを使用してテストを実施するた

めの代表的な本番ワークロードを取得できるようにするため、現在の本番システムに追加のパッチ

を適用する必要があります。詳しくは、Real Application Testing向けのデータベース・パッチ・レベ

ルの項を参照してください。


6

現在の本番ワークロードの特性とおもなパフォーマンス・メトリック

機能とパフォーマンスに関して有意義な目標を設定するには、移行プロジェクトを開始する前に、

現在の本番ワークロードの特性とおもなパフォーマンス・メトリックを明確に把握する必要があり

ます。

一般に、ワークロードはさまざまな種類（オンライン、バッチ、レポーティングなど）に分かれて

おり、1日の中でも異なる時間帯に実行されます。1日や1週間の中で理解しておくべき重要なビジー

時間帯がある場合や、ワークロードの将来的な増加が分かっている場合もあるでしょう。

測定値はアプリケーション・レベル（経過時間、応答時間、ビジネス・スループット）で取得して

おくと、新しいデータベース・プラットフォームへの変換が容易になります。バッチ処理の経過時

間は通常、レポートやトレース・ファイルから取得できます。応答時間はWebサーバーのレポートか

ら収集できるでしょう。またビジネス・スループットの値は、一般に分析レポートやグラフから得

られます。

データベース移行プロセスの開発

Database Machineへデータベースをコピーする際に使用する移行プロセスを開発し、テストに使用し

ます。この移行プロセスは、最終的な稼働前の移行にも使用します。現在のデータベース・プラッ

トフォームやシステムの可用性要件によって、移行プロセスは異なります。テストに遅れが生じな

いように、プロセス開発を最優先事項として取り組む必要があります。

テスト中に実行される移行によって、移行プロセス自体をテストし、実践し、改良する機会が与え

られます。稼働開始時にまったく同じプロセスを再現できるようにするため、正確にメモを取りま

しょう。また、プロセスの精度を上げ、エラーを減らすために、手順をスクリプト化することを推

奨します。さらに、各ステップの実行時間を測定しておくと、本番移行時間を正確に見積もること

ができるため便利です。

Siebelデータベースを現在のプラットフォームからDatabase Machineへ移行するには、標準的なデータ

ベース移行テクニックを使用します。現在のデータベース・プラットフォームやシステムの可用性

要件によって、使用されるプロセスは異なります。詳しくは、『Best Practices for Migrating to Sun

Oracle Database Machine and Exadata Cell』を参照してください。場合によっては、移行後にオプティ

マイザ統計を収集する必要があることに注意してください。

Oracle以外のデータベース（SQL ServerまたはDB2）から移行する場合、Siebelのdataexpツールと

dataimpツールを使用する移行方法がサポートされています。


7

初期のテスト構成

テストを開始する前に、Database Machineを構成する必要があります。この作業には、オペレーティ

ング・システムとデータベースの構成変更が含まれる場合があります。テストに向けての適切な出

発点に立つには、次を含む資料から得た情報について十分に検討しておく必要があります。

Database Machine上でのSiebel実行に関するベスト・プラクティス - 詳しくは、Database Machine

上でのSiebel実行に関するベスト・プラクティスの項を参照してください。

現在の本番システムとデータベースの構成 - これらの情報が適切に文書化されており、各設定が

必要になる理由が明記されていれば理想的です。

一般的なSiebelチューニングのベスト・プラクティス

場合によっては、複数の資料間で矛盾があり、どちらの設定が最善であるかを決定することは難し

いかもしれません。このため、重要な問題をテストし、解決する時間を確保できるように、早めに

テストを開始することを推奨します。

テストが実施および分析されるに従って、構成は変更され、やがては最終的な本番構成に至ります。

このプロセスを注意深く管理し、文書化してください。

テスト計画の開発

適切な成功基準を満たすテストを定義し、優先順位を付けます。このようなテストには、通常、機

能テスト、パフォーマンス・テスト、負荷テストの組合せが含まれます。

Oracle SQL Performance Analyzerは、SQL文のパフォーマンスを測定し、チューニングするためのユー

ザー・テスト・ツールです。SPAは本番データベースで使用されているSQL文を取得し、まったく同

じSQL文をテスト環境で実行します。その後、実行計画と実行時間を比較して潜在的な問題を突き止

めます。オラクルはSPAを使用してSQLパフォーマンスをテストし、チューニングすることを強く推

奨します。また、優れたパフォーマンスを発揮するSQLによって後続のテストが円滑に進むように、

この作業を最初のステップとして実行することを推奨します。

Oracle Database Replayを使用すると、負荷テストと同時実行性テスト向けに本番ワークロードを再生

できます。Database Machineでの負荷テストと同時実行性のテストには、Database Replayの使用を強

く推奨します。Database Replayを使用すると、本番で同時実行されるフル・ワークロードをもっとも

簡単かつ正確にテスト環境で再現できます。

テスト

プロジェクトのテスト・フェーズでは、次の作業が実行されます。

リモートSPAテスト環境の構成

SPAは、"リモート"構成で実行することを推奨します。この構成では、本番データベースに接続して

SQL Tuning Set（STS）を取得し、テスト・データベースに接続してSQLテストを実行します。こう

することで、プロジェクト期間中、SPAテスト機能とテスト結果に対して安定した一元化アクセス・

ポイントを利用できるようになります。最新のSPA機能を使用できるように、このデータベースの

バージョンとパッチ・レベルを最新に維持することを推奨します。


8

Database Replayによる取得を有効化するための現在の本番データベースへのパッチ適用

Database Replayでの取得を実行する前に、すべての必要なSPAパッチを現在の本番データベースに適

用してください。

テストに向けたDatabase Machineの準備と構成

このホワイト・ペーパーでは、移行プロジェクトのテスト環境として新しいDatabase Machineが使用

されることを前提としていますが、常にこれが当てはまるとは限りません。テスト・マシンは初期

のテスト構成に従って構成する必要があります。詳しくは、初期のテスト構成の項を参照してくだ

さい。

SPAテストとチューニングの実施

SPA分析を実施する際の一般的なステップは、次のとおりです。

カーソル・キャッシュの増分取得手法を使用して、関心のある（ピークまたは重要な）ワークロー

ド時間帯に対して、現在の本番システム上の代表的なSQLチューニング・セットを取得します。

ここでの目的は、重要なSQL文を取得し、これらの文が新システム上でどのように実行されるか

を正確に把握することです。

SPA移行プロセスのために、現在の本番データベースをDatabase Machineにコピーします。詳しく

はデータベース移行プロセスの開発の項を参照してください。現実的なテストを実行するには、

本番と同じデータ量とオプティマイザ統計を使用することが重要です。

SPAを使用して、Database Machine上で本番のSQL文をテストします。

結果の分析とチューニングを繰り返して実行します。SPAでは、SQL計画ベースラインまたはSQL

プロファイルを作成（SQL Tuning Advisorを使用）することで、パフォーマンスの不十分な計画

をユーザーが修正できます。

詳しくは、SQL Performance Analyzerのベスト・プラクティスの項を参照してください。

Database Replayテストとチューニングの実施

SPAテストが進んでSQLパフォーマンスを十分理解したら、次にデータベース再生テストを実行しま

す。データベース再生を実施する際の一般的なステップは、次のとおりです。

本番システム上で代表的なワークロードを取得します。

再生テスト向けに現在の本番データベースをDatabase Machineにコピーします。クリーンな再生

を実行するには、一般に、データベースを特定の時点にリストアする必要があります。

ワークロードを再生します。

結果の分析とチューニングを繰り返して実行します。

詳しくは、"Database Replayのベスト・プラクティス"の項を参照してください。


9

社内の機能テスト、パフォーマンス・テスト、負荷テスト、受入れテストの実施

おそらくは、システムの稼働を開始する準備が整うまでにその他のテストを実行する必要があるで

しょう。たとえば、フル・スタックのテストを実行して、システム内のすべてのコンポーネントが

正しく構成されており、適切に連携することを確認すると良いでしょう。すでに説明したとおり、

最善の方法は、SPAを使用したテストとチューニングが十分に進んでから追加テストを開始すること

です。

最終的な本番構成の定義と本番向けDatabase Machineの準備

すべてのテストが完了したら、最終的な本番構成を定義して文書化し、本番稼働の準備として

Database Machineに適用します。

稼働開始テストの実施

最終的な本番移行までに尐しの時間があり、エラーの余地がほとんどない場合、実際の稼働開始日

にすべてが円滑に進むように、稼働開始手順をテストし、実践しておくと良いでしょう。

移行

テストとチューニングの作業が完了したら、稼働開始の準備へと進みます。この作業に必要なステッ

プは次のとおりです。

現在の本番システムを停止します。おそらくこの時点では、移行にかかる時間が推測できている

ため、それに従って停止時間の準備を行います。

Database Machineへデータベースをコピーします。これはテスト中に実行したような、特定の時

点（SCN）までの移行ではなく、最新データの完全移行である点に注意します。

Siebel接続をDatabase Machineへリダイレクトし、Siebelを起動します。中間層の構成変更が完了

していない場合、この時点でこれを実装します。詳しくは、Siebel層の構成の項を参照してくだ

さい。

受入れテストを実施します。

Database Machineでの本番稼働を開始します。


10

Oracle Real Application Testingを使用したSiebelのテスト

オラクルは、本番稼働を開始する前に、Oracle Real Application Testing（SQL Performance Analyzerと

Database Replay）を使用してDatabase Machine上でワークロードをテストし、チューニングすること

を推奨します。ここからは、Siebelに対してReal Application Testingを使用する際のデータベース・パッ

チ要件とベスト・プラクティスについて説明します。

Real Application Testing向けのデータベース・パッチ・レベル

場合によっては、Real Application Testingを正常に実行するため、現在の本番システムまたはDatabase

Machineにパッチを適用する必要があります。Real Application Testingの実行に必要または推奨されて

いるパッチについて、詳しくは『Support Note 560977.1 - Real Application Testing Now Available for

Earlier Releases』を参照してください。パッチは、現在の本番システム（取得用）またはDatabase Machine

（テスト用）に適用されます。

SQL Performance Analyzerのベスト・プラクティス

SQL Performance Analyzerを使用すると、現在の本番データベース上で実行されている既存のSQL文

を収集し、Database Machineでのパフォーマンスを評価できます。詳しい分析レポートが提供され、

パフォーマンスの不十分な文や実行計画の異なる文が明らかにされます。SPAはオーバーヘッドをほ

とんど発生させることなくSQLワークロードを取得し、問題の領域を素早く特定して、その後の分析

とチューニングを可能にします。オラクルは、十分にチューニングされた基盤が後続のテストに提

供されるようにするため、その他のチューニングよりも先にSPA分析を実施することを推奨します。

ここからは、その他の推奨事項について説明します。

小規模からの開始とテスト環境の検証

はじめに、尐数のSQL文を使用したエンド・ツー・エンド・テストを実行し、取得およびテスト環境

が正しく機能していることを確認してから、大規模なテストへと拡張すると良いでしょう。こうす

ることで、素早く問題を見つけて迅速に再テストを行い、解決作業を検証できます。

Siebelによるセッション・レベルのデータベース・パラメータの設定

Siebel Object Managerは、データベースへのログイン時にセッション・レベルのデータベース・パラ

メータを設定しますが、SPAを使用したテストでは、デフォルトではこのような設定は行われないた

め、問合せ計画が異なる可能性が高くなります。設定を変更したい場合もあるため、この設定機能

は便利です。セッション・レベルのパラメータを適用するには、次のような方法があります。

取得した環境の設定を使用するように、SPAに指定します。

exec dbms_sqlpa.set_analysis_task_parameter('TASK_123',


11

'APPLY_CAPTURED_COMPILENV', 1);

APPLY_CAPTURED_COMPILENVによって取得環境の設定がテスト時に使用されるため、テスト環

境のシステム・レベルまたはセッション・レベルのデータベース・パラメータ設定は無視されます。

ログオン・トリガーを使用してSiebelのセッション変数を設定します。次にその例を示します。

すべてのテストにこの設定が適用されるように、テスト環境のシステム・レベルでパラメータを設

定します。

バインド・ピーキング

バージョンによっては、SiebelによってSQL文の実行時にバインド・ピーキングが実行されます。こ

のため、SPAテストが取得時と同じ方法で実行されない場合があります。この対策として、ログオン・

トリガーに"_optim_peek_user_binds"パラメータを設定すると、Siebelの動作と合わせることができま

す。ログオン・トリガーの例について、Siebelによるセッション・レベルのデータベース・パラメー

タの設定の項を参照してください。

Database Replayのベスト・プラクティス

オラクルが実施したSiebelテストでは、Siebelワークロード全体を取得し、SCN順に再生することで、

再生の相違をゼロにすることに成功しました。

Oracle Database 11.2.0.2パッチセットでは、Database ReplayとSPAの統合がサポートされているため、

1回の反復でSTS取得とDatabase Replayを実行できます。

オラクルが推奨するベスト・プラクティスは次のとおりです。

小さく始める

はじめに小規模のワークロード（長さ5分間のワークロードや、ごく数名の同時ユーザーによるワー

クロード）を使用したエンド・ツー・エンド・テストを実行し、取得およびテスト・プロセスが正

しく機能していることを確認してから大規模なロードへと拡張すると良いでしょう。こうすること

で、素早く問題を見つけて再テストを行い、解決作業を検証できます。


12

取得ポイントへのデータベース・リストア

Siebelのコミット時ロックの特性から、再生を開始する前に、取得が開始された正確な時点にSiebel

データベースをリストアしておく必要があります。詳しくは、Siebelのコミット時ロックとRow ID生

成の背景の項を参照してください。

同期モードでの再生

Siebelのコミット時ロックの特性から、信頼できる結果を得るには正確にSCN順にコールを再生する

必要があります。このため、同期モードで再生を実行します。詳しくは、Siebelのコミット時ロック

とRow ID生成の背景の項を参照してください。

Siebelワークロード全体の取得

Siebelのコミット時ロックとRow ID生成の特性から、ある時点で実行されているSiebelワークロード

の全体を取得し、再生する必要があります。詳しくは、Siebelのコミット時ロックとRow ID生成の背

景の項を参照してください。

Siebel起動前の取得の開始

クリーンな取得基点を確立するには、Siebelを起動する前に取得を開始すると良いでしょう。こうす

ることで、すべてのSiebelデータベース・セッションに対するセッション環境設定（alter session文）

を完全に取得し、再生することができます。

取得を開始するためのSiebel再起動に都合の良いタイミングを見つけることができない場合、取得開

始時に一部のSiebelデータベース接続がすでに実行されていて、これらの接続に対するセッション環

境設定が取得されない場合があります。このような場合、再生環境にログオン・トリガーを実装し

ておくと、すべてのセッションに対して適切なalter session文を実行できます。次にトリガーの例を示

します。


13

接続タイムアウトの防止

再生中、クライアント接続は厳密に順序付けされていますが、場合によって、ログインを待機する

クライアントが"ORA-01270: TNS:Connect Timeout"エラーによってタイムアウトになる可能性があ

ります。このエラーの発生を防止するには、ワークロード再生クライアントに使用される

SQLNET.ORAファイルに、長時間の接続タイムアウトを設定します。次にその例を示します（時間

は秒数を指定）。

TCP.CONNECT_TIMEOUT=500000

SQLNET.OUTBOUND_CONNECT_TIMEOUT=500000

プロセス・スレッドの設定

Siebelではよくあることですが、同時実行性の高いワークロードを再生中に、各再生クライアントが

多数のプロセス・スレッドを実行する場合があります。この際、スレッド数がスレッド制限に達す

ると、"ORA-15563: workload replay client cannot spawn new threads"エラーが返されます。このエラー

の発生を防止するには、/etc/security/limits.confファイルのnproc制限値を高く設定することで、再生を

実行するユーザーに対してスレッドの上限を増やします。

oracle soft nproc 100000

oracle hard nproc 100000

再生ワークロードの高速化

データベース再生を高速化して、取得したワークロードより大きなワークロードをシミュレートで

きます。これには、think_timeパラメータとconnect_timeパラメータの値を調節します。次にその例を

示します。

think_time=>50, connect_time=>50

Siebelのコミット時ロックとRow ID生成の背景

Siebelのコミット時ロックでは、すべてのSiebel表に定義されているMODIFICATION_NUM列が使用

されます。この列はすべての問合せで読み取られ、行が更新されるときはまずチェックされて、そ

の後で値が増やされます。問合せと更新の間に値が変更されている場合、その行は更新されません。

次に、update文の例を示します。


14

WHERE句の中でMODIFICATION_NUMが検証されており、同じ文のSET句で値が増やされている点

に注意してください。この文は、最後の問合せ以降に値が変更されていない場合にのみ成功します。

取得中に更新された行が再生中に更新されないと、"DMLs with Different Number of Rows Modified"や

"New Errors Seen During Replay"といった再生の相違につながります。

ワークロードが再生される際、バインド変数にバインドされる値は取得時のままであり、再生中に

読み取られた値と後続の更新処理時の値に相関関係は存在しません。その結果、次の問題が発生す

る場合があります。

行に含まれるMODIFICATION_NUMの値が取得中の値と正確に一致しない場合、この行は更新さ

れません。

正しい順序で更新が再生されない場合、この行は更新されません。

更新が一度省略されるか、失敗すると、後続の更新すべてで処理が実行されません。

また、S_SSA_ID表はすべてのSiebelプロセスによってSiebelのRow IDを生成するために使用されてお

り、この表には1行しか含まれないことに注意してください。S_SSA_IDにもSiebelのコミット時ロッ

クが適用されているため、相違の発生を回避するには、この表に対する更新を実行するすべてのプ

ロセスを取得し、再生する必要があります。


15

Database Machine上でのSiebel実行に関するベスト・プラクティス

Maximum Availability Architectureの推奨事項に従って、卓越したパフォーマンスと可用性を実現するに

は、SiebelとDatabase Machineに対する正しい構成が不可欠です。ここからは、テストを通じて特定およ

び検証されたベスト・プラクティスの推奨事項について説明します。これらの推奨事項は、Siebelおよ

びOracle Databaseに対して文書化されたインストールおよび構成手順とともに実装してください。特に

テストは実施していませんが、Siebel 8.1に対しても同じベスト・プラクティスを推奨します。

データベース層の構成

ここからは、データベース・サーバーの構成について考慮すべき事項を説明していきます。

パッチ・レベル

最新のDatabase Machineでサポートされているバージョンとバンドル・パッチについて、詳しくは

『Support Note 888828.1 - Database Machine and Exadata Storage Server 11g Release 2 (11.2) Supported

Versions』を参照してください。

ヒュージページの構成

一般的に、Siebelは多数のデータベース接続とサイズの大きいSGAを持つため、Siebelデータベース・

インスタンスに対してヒュージページを構成する必要があります。実行方法について、詳しくは

『Support Note 744769.1 - How to Configure HugePages for Oracle Database on 64-bit Linux Platforms』を参

照してください。

データベース・サービスの作成と透過的アプリケーション・フェイルオーバー（TAF）の構成

データベース・サービスによって、データベースへのアクセスを簡単に指定できるアクセス・ポイ

ントと、より便利なTAF構成が提供されます。サービスはOracle Real Application Clusters（Oracle RAC）

クラスタ内の複数のインスタンスに物理的にまたがっており、簡単にインスタンス間を移動できま

す。Siebelからデータベースへの接続をサービス経由のみに限定すると、Siebelを再設定しなくても

サービスを再配置または再設定することが可能になります。

データベース・サービスは、Oracle Enterprise Managerまたはsrvctlコマンドライン・ツールを使用し

て作成および設定されます。またSiebelでは"SELECT"フェイルオーバー・タイプおよび"BASIC"フェ

イルオーバー・メソッドがサポートされており、ほとんどの構成に適用できます。次に、srvctlを使

用したサービス作成例を示します。

srvctl add service -d SIEBEL -s SIEBEL -r “SIEBEL, SIEBEL2” -p

basic -e SELECT -j LONG

それぞれのパラメータは、次のとおりに定義されています。

-d SIEBEL：データベース固有の名前


16

-s SIEBEL：データベース・サービス名

-r "SIEBEL 1, SIEBEL 2"：サービスを開始する優先データベース・インスタンス

-P basic：TAFフェイルオーバー・メソッド

-e SELECT：TAFフェイルオーバー・タイプ

-j LONG：接続のロードバランシング方法（通常Siebel接続は長時間持続します）

-z（フェイルオーバーの再試行）パラメータと-w（フェイルオーバーの遅延）パラメータは、Siebel

の動作に影響を与えないことに注意してください。Siebelは常に、5秒の遅延で24回の再試行を実行

します。

詳しくは、『Oracle Real Application Clusters管理およびデプロイメント・ガイド』を参照してください。

データベース・パスワードの有効期限処理

Oracle Database 11gではデフォルト動作が変更されており、データベース・ユーザーのパスワードが

180日後に期限切れになります。このため、定期的にパスワードを更新するか、または有効期限を延

長または無効化するプロセスを配置する必要があります。パスワードが期限切れになると、Siebelア

プリケーションの可用性に影響が及びます。次のコマンドを利用すると、デフォルト・ユーザー・

プロファイルに対してパスワードの有効期限を無効化できます。

alter profile default limit password_life_time unlimited;

Siebel層の構成

ここからは、Siebelサーバーの構成について考慮すべき事項を説明していきます。

Siebel構成によるデータベース・サービスへの接続

データベース・サービスの作成と透過的アプリケーション・フェイルオーバー（TAF）の構成の項で

説明したとおり、SiebelでTAFを利用するにはデータベース・サービスに接続する必要があります。

またフェイルオーバー時にはRACクラスタに含まれるすべてのリスナーを試行するように、クライ

アントを設定する必要があります。こうすることで、特定のリスナーに対するハングアップが回避

され、存続ノードに対して新規接続が確立されます。変更は、各Siebelサーバー上のTNSNAMES.ORA

ファイルに対して実施します。このファイルの構成方法は、Siebelサーバー上にインストールされた

データベース・クライアントのソフトウェア・バージョンによって異なります。ここからは、2つの

ケースについて説明します。

Oracle Database Client 11g Release 2を使用したSiebelサーバー構成

Siebelからデータベース・サービスへの接続を構成するには、SERVICE_NAMEパラメータを指定し

ます。これは、すべてのOracle Database Clientバージョンに当てはまります。


17

Siebelサーバーが、Database MachineのRACクラスタに含まれるいずれのノードにもアクセスできる

ようにするため、SCANアドレスを指定します。接続タイムアウトはCONNECT_TIMEOUTパラメー

タで指定され、再試行回数はRETRY_COUNTパラメータによって制御されます。Oracle Database 11g

Release 2で新しく導入されたSCANアドレス、CONNECT_TIMEOUTパラメータ、RETRY_COUNTパ

ラメータについて、詳しくは『SINGLE CLIENT ACCESS NAME (SCAN)』を参照してください。

CONNECT_TIMEOUT パラメータを設定すると、 SQLNET.ORA ファイルの

SQLNET.OUTBOUND_CONNECT_TIMEOUTパラメータ設定は無視されます。

次に、CONNECT_TIMEOUT（3秒）、RETRY_COUNT（3回）、SCANアドレス、SERVICE_NAME

を指定したTNSNAMES.ORA構成の例を示します。

上記の構成変更をすべてのSiebelサーバーに対して実行する必要があります。

Oracle Database Client 11g Release 1以下を使用したSiebelサーバー構成

Siebelからデータベース・サービスへの接続を構成するには、SERVICE_NAMEパラメータを指定し

ます。これは、すべてのOracle Database Clientバージョンに当てはまります。

Siebelサーバーが、Database MachineのRACクラスタに含まれるいずれのノードにもアクセスできる

ようにするため、ADDRESS_LISTにそれぞれのSCAN VIPを指定します。11g Release 2のRACデータ

ベースに対して以前のデータベース・クライアント・バージョンを構成する方法とSCAN VIPについ

て、詳しくは『SINGLE CLIENT ACCESS NAME (SCAN)』を参照してください。

次に、クォーター・ラックのDatabase Machineに対するTNSNAMES.ORAの構成例を示します。

データベースに接続または再接続する場合、Siebelでは接続を確立するまで、アドレス・リストにあ

るすべてのアドレスへの接続が試行され続けます。Siebelが1つのアドレスに"足止め"されると接続の

遅延につながるため、これを回避することが重要です。SQLNET.OUTBOUND_CONNECT_TIMEOUT

パラメータを使用して、リスト内の次のアドレスにスキップするまでの、アドレスからの応答に対

する最大待ち時間（秒単位）を指定します。推奨される設定は3秒であり、ほとんどの場合はこの設

定にしておけば問題ありません。このパラメータに3秒未満の値を設定しないでください。次に、

SQLNET.ORAの例を示します。

SQLNET.OUTBOUND_CONNECT_TIMEOUT=3

上記の構成変更をすべてのSiebelサーバーに対して実行する必要があります。


18

TCP Keepaliveタイムアウトの構成

Siebelは現在、OracleのFast Application Notification（FAN）をサポートしていないため、データベース・

ノードのクラッシュやネットワーク障害の発生時にSiebelサーバーがデータベース接続を解放する

よう、TCP Keepaliveタイムアウトを短く設定する必要があります。これは、TCP接続をクリーンアッ

プする前にデータベース・ノードのクラッシュやネットワーク障害が発生するような稀なケースや、

障害時にデータベース要求が実行中であったり、仮想インターネット・プロトコル（VIP）アドレス

を存続ノードへ切り替える前に新規リクエストが要求されたりといった場合でのみ使用されます。

その他のケースでは、データベースの接続障害が検出されると、すぐに存続ノードで新規接続が確

立されます。

TCP Keepaliveタイムアウトの設定方法について、詳しくは『Support Note 249213.1 - Performance

problems with Failover when TCP Network goes down (no IP address)』を参照してください。これらの設

定変更によってネットワークの利用効率に逆効果を与えることがあるため、すべての変更を慎重に

テストして監視する必要があります。

バックアップとリストア

フル・ラックのDatabase Machineと高パフォーマンスのディスク・ドライブを使用して、非常に高速

なバックアップとリカバリを実現できます。オラクルのテストでは、次の結果が達成されました。

ディスクベースのフル・イメージ・バックアップ - 最大7.1TB/時

ディスクベースの増分バックアップ - 10～48TB/時（実効速度）

データベース・リストア - 23TB/時

REDO Apply - 2.1TB/時（637MB/秒）

これらの速度は、ターゲット・データベース・サーバー上のCPU使用率が10%未満の状態で達成され

ているため、同時ユーザーのワークロードに十分な帯域幅が残されています。詳しくは、『Exadata

セルおよびSun Oracle Database Machineを使用したバックアップおよびリカバリのパフォーマンスと

ベスト・プラクティス』を参照してください。

MAAラボでのベスト・プラクティスの検証

テスト・ワークロード

このテスト・ワークロードは、数千の同時アクティブ・ユーザーによって構成された大規模なコー

ル・センター組織をシミュレートするように設計されました。シミュレートされたユーザーは次の

とおりです。

Siebel Financial Services Call Centerを実行するサービス担当者

Siebel Partner Relationship Managementを実行するパートナーのサービス担当者

Webサービスを呼び出す外部アプリケーション・ユーザー


19

シード・データ

テストを実行する前に、顧客、担当者、活動、案件、サービス・リクエストを含む100GB以上のデー

タがデータベースに挿入されました。

ビジネス・トランザクション

シミュレートされた各ユーザーによって、さまざまなビジネス処理（"新規担当者の作成"や"案件へ

の製品の追加"など）を含む複雑なビジネス・トランザクションが実行されました。処理ごとの応答

時間とビジネス・トランザクションの完了速度が測定されました。

テスト環境の構成

初期のテストから見積もった結果、Siebel中間層の能力に見合ったテスト・ターゲットとしてクォー

ター・ラックのDatabase Machineと3万のユーザー・ワークロードが設定されました。

テスト環境の構成は次のとおりです。

9台の負荷生成装置（Microsoft Windows Server 2003 R2）

Siebel Webサーバーのロードバランシングを行うF5 BIG-IP 6400アプライアンス

2台のSiebel Webサーバー（Oracle HTTP Server、Siebel 8.0.0.8、OEL 4 Update 8、Oracle VM 2.1.2）

- 8個のインテルXeon X5355 - 32GB RAM

8台のSiebelアプリケーション・サーバー（Siebel 8.0.0.8、OEL 4 Update 8、Oracle VM 2.1.2） - 8

個のインテルXeon E5430 - 32GB RAM

Sun Oracle Database Machineクォーター・ラック（詳しい仕様は『Sun Oracle Database Machine』を

参照）

データベースの圧縮テスト

Exadata上でSiebelを実行していた金融サービス顧客では、S_EVT_ACT表の圧縮から次の結果が得ら

れています。

TABLE S_EVT_ACT

圧縮モード比率

問合せ（HCC） 9:1

アーカイブ（HCC） 10:1

Database Replayのテスト

既存のSiebelデータベースからDatabase Machineへの移行に際して、Siebelワークロードのパフォーマ

ンスをテストしてチューニングするためDatabase Replayが使用されますが、このDatabase Replayの使

用法を検証するためにテストが実施されました。次の項では、テストの詳細と結果について説明し

ます。


20

Siebel 8.0.0.8を使用した3万ユーザーによるDatabase Replayテスト

フル・ロードのテスト・ワークロードが取得され、Database Machine上で再生されました。何度かの

繰返しの後で再生に成功し、次の結果が得られました。

Siebel 8.0.0.8を使用した3万ユーザーによるDatabase Replayテストの結果

ユーザー・コール数 70,959,030

相違のあったユーザー・コール数 133

相違率 0.00019%


21

パフォーマンス・テスト

SiebelでDatabase Machineの機能を利用する方法を理解して、構成のベスト・プラクティスを開発し、

検証できるようにするため、パフォーマンス・テストが実施されました。ここからは、テストの詳

細と結果について説明します。

Siebel 8.0.0.8のEIMを使用した顧客インポート・テスト

テストの前に、次のPL/SQLスクリプトを使用して、EIMインタフェース表に顧客レコードが挿入さ

れました。

バッチ番号1のEIMジョブが実行され、経過時間が記録されました。結果は次のとおりです。

EIMによる顧客インポートのパフォーマンス

インポートされた顧客レコード数経過時間 1分当たりの顧客数

50,000 81秒 37,037

負荷テスト

Database MachineでのSiebel実行に対するベスト・プラクティスを見出し、検証するために、負荷テス

トが実施されました。負荷テストは、MAAベスト・プラクティスで推奨されているとおり、フラッ

シュバック・データベースを有効化した状態で、アーカイブ・ログ・モードで実行されました。次

の項では、テストの詳細と結果について説明します。


22

Siebel 8.0.0.8を使用した3万ユーザーによる負荷テスト

これらの結果は一般的な情報提供を目的としており、実装に特化したサイジングやベンチマークの

代わりになるものではありません。

すべてのケースで、データベースが初期状態にリストアされてから、データベース・サーバーが2ノー

ドのRAC構成で開始されました。次にSiebelサーバーとWebサーバーが開始され、その後でワーク

ロードが開始されて、同時ユーザーによる一定の負荷になるまでワークロードが増加されました。

この負荷が維持された状態で、30分間にわたって測定が実施されました。

約3万の同時ユーザーで構成されたテストの結果を次に示します。

応答時間とビジネス・トランザクションのスループット

ワークロードユーザー数平均応答時間（秒）ビジネス・トランザクション数/時

合計 30,276 0.12 443,334


23

データベース・サーバーのパフォーマンス

コンピューティング・ノード1 コンピューティング・ノード2 合計

CPU利用率（%） 23% 24% 23%

SGAサイズ（MB） 36,864 36,864 73,728

REDO生成（B/秒） 3,740,945 4,005,464 7,746,408

論理読取り（ブロック/秒） 215,609 233,991 449,600

物理読取り（ブロック/秒） 253 273 526

物理書込み（ブロック/秒） 710 1,209 1,920

トランザクション数/秒 459 482 941

ユーザー・コール数/秒 7,380 7,609 14,990

フラッシュ・キャッシュの読取り

ヒット数/秒

123 132 255

フラッシュ・キャッシュのヒット

率（%）

50% 49% 49%

物理書込みリクエスト数/秒 1,596 1,713 3,310

ストレージ・セルのパフォーマンス

セル1 セル2 セル3 合計

読取り操作数/秒 216 193 195 604

書込み操作数/秒 2,725 3,072 3,171 8,968

合計I/O操作数/秒 2,941 3,264 3,366 9,571

読取りMB/秒 5 6 6 17

書込みMB/秒 42 48 48 138

合計MB/秒 47 54 54 155


24

結論

このホワイト・ペーパーでは、既存のSiebel実装からSun Oracle Database Machineへ移行し、卓越した

パフォーマンスと最大限の可用性を達成するためのベスト・プラクティスについて説明しました。

ベスト・プラクティスを開発し、検証するため、Maximum Availability Architecture（MAA）構成によ

るクォーター・ラックのSun Oracle Database Machine上にSiebel 8.0.0.8 Financial Servicesアプリケー

ションが配置されました。MAAは、Oracle Real Application Clusters、Oracle Data Guard、フラッシュ

バック・テクノロジーといったオラクルの高可用性テクノロジーを実装するためのベスト・プラク

ティスによるブループリントです。

データベースの動作とパフォーマンスは複数のテスト・ワークロードを使用して評価され、次の結

果が得られました。

コール・センター、パートナー・サービス、Webサービスの組合せで構成された3万の同時ユー

ザーによって、1時間に443,334件のビジネス・トランザクションが処理され、エンドユーザーの

平均応答時間として0.12秒を達成しました。データベース・サーバーのCPU使用率は23%、スト

レージI/O処理数は1秒当たり9,571に過ぎなかったため、同じプラットフォーム上にその他のアプ

リケーションを統合する余力が残されました。

Siebel EIMを特別なチューニングなしで使用して、1分当たり37,037件のアカウントがインポート

されました。

さらにチューニングを実施することでパフォーマンスをいっそう向上させることも可能ですが、こ

のホワイト・ペーパーの目的は全体的なベスト・プラクティスの説明であり、最大限のパフォーマ

ンスを達成することではない点に注意してください。

新しいプラットフォームへ移行する場合、実際の移行の前に徹底的なテストを実施することが常に

重要になります。一般的に、テストはその場限りの手段を通じて実施されますが、Oracle 11gのReal

Application Testingを利用すると、はるかに包括的で系統立った方法を使用して、既存の本番ワーク

ロードを新しいプラットフォームでテストできます。このホワイト・ペーパーでは、Real Application

Testingを使用したDatabase Machineへの移行に関するベスト・プラクティスについて説明しました。

アプローチの検証に使用されたテスト・ワークロードはOracle Real Application Testingを使用して取

得されたものであり、相違を最小限に抑えて再現されました。

またExadata Hybrid Columnar Compressionを使用した場合のSiebelデータの動作を示す例として、

Exadata Hybrid Columnar Compressionを使用したSiebelデータ表で10対1の圧縮率を達成した金融顧客

での成果について紹介しました。


25

参考資料

『Sun Oracle Database Machine and Exadata Storage Server』

http://www.oracle.com/technetwork/jp/database/exadata/index.html

Oracle Maximum Availability ArchitectureのWebサイト

http://www.oracle.com/technetwork/jp/database/maa-098142-ja.html

『Oracle Database Real Application Testingユーザーズ・ガイド』（原本部品番号：E12254）

http://www.oracle.com/pls/db112/to_toc?pathname=server.112/e16540/toc.htm

『Best Practices for Migrating to Oracle Exadata Storage Server』

http://www.oracle.com/technetwork/jp/database/xmigration-11-157620-ja.pdf

http://www.oracle.com/technetwork/jp/database/exadata/index.html

http://www.oracle.com/technetwork/jp/database/maa-098142-ja.html

http://www.oracle.com/pls/db112/to_toc?pathname=server.112/e16540/toc.htm

http://www.oracle.com/technetwork/jp/database/xmigration-11-157620-ja.pdf


2010年10月

著者：Richard Exley

Oracle Corporation

World Headquarters

500 Oracle Parkway

Redwood Shores, CA 94065

U.S.A.

海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

www.oracle.com

Copyright © 2010, Oracle and/or its affiliates.All rights reserved.本文書は情報提供のみを目的として提供されており、ここに記

載される内容は予告なく変更されることがあります。本文書は一切間違いがないことを保証するものではなく、さらに、口述に

よる明示または法律による黙示を問わず、特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み、いかなる

他の保証や条件も提供するものではありません。オラクル社は本文書に関するいかなる法的責任も明確に否認し、本文書によっ

て直接的または間接的に確立される契約義務はないものとします。本文書はオラクルの書面による許可を前もって得ることな

く、いかなる目的のためにも、電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません。

Oracleは米国Oracle Corporationおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

0109

Oracle Maximum Availability Architectureホワイト …...ExadataでのSiebel実行 3...

Documents

Transcript of Oracle Maximum Availability Architectureホワイト …...ExadataでのSiebel実行 3...