WebLogic Portal データベース管理ガイド
|
 |
 |
|
この節では、データベース管理者が WebLogic Portal データベースの設定とメンテナンスを行う際に考慮する必要のある事項について説明します。
チーム開発でのデータベース環境の考慮事項については、次の URL にある『プロダクション業務ユーザーズ ガイド』の「共有ポータル ドメインの作成」(http://edocs.beasys.co.jp/e-docs/wlp/docs81/prodOps/index.html) の節を参照してください。
データベース固有の考慮事項および推奨事項の詳細については、このドキュメントの個々のデータベースの節を参照してください。
データベース文字セットは、データベースで使用できる言語を指定します。データベースのソート順または照合は、ソートと比較の対象となる文字のルールを指定します。
グローバライズされた WebLogic Portal アプリケーションでは、データベースを設定する前にデータベースの文字セットとソート順を決める必要があります。既存のデータベースの文字セットとソート順の変更作業は、時間とリソースを大量に消費します。一般的に、対象の文字セットがソース文字セットまたは元の文字セットのサブセットである場合にのみ変更できます。
以下の節では、Portal でサポートされるデータベースの文字セットとソート順の考慮事項について説明します。
Oracle の場合、データベースの作成時に文字セットを定義します。
AL32UTF8 が使用されます。 UTF8 が文字セットとして使用されます。 Oracle データベースの文字セットとソート順に関する情報は、SYS.NLS_DATABASE_PARAMETERS テーブルにクエリすることで取得できます。
SQL Server では、文字セットとソート順をインスタンス レベルおよびデータベース レベルの両方で定義できます。SQL Server のインスタンス レベルのデフォルト文字セットは、Windows オペレーティング システムのロケール設定によって異なります。以下のサンプル出力は sp_helpsort ストアド プロシージャによるもので、一般的なインスタンス レベルのソート順を示しています。
Latin1-General, case-insensitive, accent-sensitive, kanatype-insensitive, width-insensitive for Unicode Data, SQL Server Sort Order 52 on Code Page 1252 for non-Unicode Data.
データベース作成スクリプトのサンプルは WL_HOME¥portal¥db¥sql_server¥2000¥admin¥create_database.sql にあります。これにより、WebLogic Portal データベースが COLLATE SQL_Latin1_General_CP1_CS_AS の設定で定義されます。この定義では、大文字と小文字が区別されます。データベースで大文字と小文字を区別するように設定すると、SQL Server に対するコンテンツ管理のクエリは他のデータベースを対象にした場合と同様に動作します。コンテンツ管理の検索クエリが大文字と小文字を区別する環境用に記述されていない場合、予期しない結果が取得されることがあります。
sp_helpdb <dbname> ストアド プロシージャを使用して、SQL Server データベースの文字セットとソート順を表示できます。
Sybase では、Sybase インスタンスの作成時に文字セットとソート順を定義します。Sybase で一般に使用される文字セットとソート順は以下のとおりです。
sp_helpsort ストアド プロシージャを使用して、インスタンスの文字セットとソート順の情報を表示できます。
DB2 データベースでは、個々のデータベースに対して文字エンコーディングを設定できます。デフォルトの文字エンコーディングは、オペレーティング システムによって異なります。
DB2 で一般に使用される文字エンコーディングは UTF-8 です。
DB2 CODESET コンフィグレーション パラメータで、データベースのコードセットを確認できます。
以下の節では、インデックスの配置、CLOB/BLOB/TEXT/IMAGE データ ストレージ、および行動追跡に関する特別な考慮事項、推奨事項、要件について説明します。
Oracle データベースでは、rebuild_indexes.sql スクリプトを使用してインデックスを WEBLOGIC_INDEX テーブルスペースに配置します。WebLogic Portal データベースの作成後に手動でこのスクリプトを実行し、インデックスを専用のテーブルスペースに移動します。
SQL Server および Sybase では、インデックスを専用のファイル グループまたはセグメントに配置するための非クラスタ インデックス用データ定義言語 (DDL) が ON WEBLOGIC_INDEX で定義されています (8.1 SP4 現在)。WebLogic Portal データベースの作成スクリプトまたは更新スクリプトを実行する前に、WEBLOGIC_INDEX ファイル グループまたはセグメントを定義しておく必要があります。SP4 でのデータベースの変更の詳細については、http://edocs.beasys.co.jp/e-docs/wlp/docs81/upgrade/index.html にある『WebLogic Portal 8.1 へのアップグレード』を参照してください。
この節では、CLOB/BLOB (Oracle/DB2) または TEXT/IMAGE (Sybase/SQL Server) データがテーブルに含まれる場合の推奨事項および特別な考慮事項について説明します。
一般的に、サポートされるすべての Portal データベース プラットフォームで最適なパフォーマンスを得るためには、CLOB/BLOB/TEXT/IMAGE テーブル データは非 CLOB/BLOB/TEXT/IMAGE データと物理的に分離する必要があります。しかし、デプロイメントを簡素化してコンフィグレーションの柔軟性を高めるため、デフォルトの Portal データベース スキーマではデプロイの際にデータが分離されていません。特定のアプリケーションで CLOB/BLOB/TEXT/IMAGE ストレージを分離すべきかどうかを判断するには、使用している環境で以下の考慮事項を評価します。
ストレージ割り当ての変更については、データベースのドキュメントの CLOB/BLOB/TEXT/IMAGE 設定の変更に関する詳細を参照してください。
CLOB/BLOB または TEXT/IMAGE データ型を含む以下のテーブルが追加されました。これらを使用して実際にストレージを変更し、パフォーマンスにどの程度影響があるかを確認できます。
行動追跡は、主にイベントを記録することで訪問者の行動の追跡に使用します。
行動追跡を有効に設定した場合、BT_EVENT テーブルに書き込める行数が非常に多くなるため、行動追跡データの格納に別個のデータベース (DBMS によってはテーブルスペースとスキーマ) を使用できます。
以下の節では、PointBase 以外の各データベース タイプで行動追跡イベント用に別個のデータベースを作成する方法を説明します。
いくつかのサードパーティ製の行動追跡レポート作成ツールでは、BT_EVENT テーブルからデータを展開して別のデータベース テーブル セットに格納します。レポート作成ツールおよび解析ツールの詳細については、http://dev2dev.bea.com/products/wlportal/psc/Reporting_Analytics_BI.jsp にある「Portal Solutions Catalog」を参照してください。
いくつかのデータベースには、データベース テーブルをメモリにキャッシュまたは固定する機能があります。アプリケーションにデプロイされている WebLogic Portal コンポーネントとそのデプロイ方法に基づいて、データベース キャッシュの実装を選択します。
各データベース タイプでサポートされる、データベース テーブルのキャッシュまたは固定機能について説明します。環境によっては、キャッシュ戦略の対象を小さいテーブルおよび頻繁に参照されるテーブルに設定します。
DBCC PINTABLE (database_id, table_id) が使用できます。sp_objects_stats で頻繁にアクセスされるオブジェクトを識別し、キャッシュを使用して最適化します。Sybase モニタ ツールまたは sp_sysmon を使用して、キャッシュ ヒット率が許容できるかどうかを判断します。 バッファプールが使用され、バッファプールのコンフィグレーションが最も重要なチューニング領域とされています。DB2 では個々のテーブルおよびインデックスをバッファプールに割り当てることができます。 注意 : データベース固有の考慮事項および推奨事項の詳細については、個々のデータベースの章を参照してください。
Oracle および SQL Server データベースのデフォルトのページ サイズとブロック サイズは 8K です。
DB2 では、大きいプール サイズ (デフォルトの 4K よりも大きい) を必要とする WebLogic Portal のテーブルおよびインデックス用に 8K のバッファプールが定義されています。
Sybase データベースでは、WebLogic Portal のテーブルおよびインデックス用に 8K のページ サイズが必要な場合があります。
Sybase インスタンスのデフォルトのロック メカニズムは「ALL PAGES」です。同時実行性のため、Sybase データベースの各テーブルについてロックを定義することもできます。
8.1 SP4 では、Sybase 用の WebLogic テーブルは LOCK DATAROWS で定義されています。その他の Sybase 用 WebLogic Portal テーブル (collaboration_create_tables.sql で定義されているテーブルを除く) は LOCK DATAPAGES で定義されています。
Sybase データベースを使用する WebLogic Portal コンポーネントの使用方法に基づいて、追加のテーブルを LOCK DATAROWS に変更できます。
WebLogic Portal データベースに必要なサイズは、以下の事項を含むさまざまな要因によって異なります。
以下の節では、データ量が増えた際に、特に増分を監視する必要のある WebLogic Portal データベース テーブルについて説明します。
行動追跡が有効に設定されている場合、BT_EVENT テーブルは非常に大きくなる可能性があります。
以下のデータベース テーブルにはパーソナライゼーション データが格納されます。これらのデータの増分を監視する必要があります。
以下のテーブルは Portal Framework または WSRP(Web Services for Remote Portlets) で使用され、規模が大きくなる可能性があるため、データの増分を監視する必要があります。
BOOK_DEFINITION のインスタンスが識別されます。最低 1 つのブック インスタンス (プライマリ インスタンス) が常に存在します。他のすべてのインスタンスは、管理者またはエンド ユーザによるカスタマイズを表します。ユーザ カスタマイズが多数発生した場合、このテーブルは非常に大きくなる可能性があります。 以下のデータベース テーブルは、コンテンツ管理 (CM) およびバージョン管理 (CMV) データを格納します。これらのデータの増分を監視する必要があります。
ブックのプロパティである SUBJECT の値には、FINANCE などがあります。コンテンツ管理を使用して大量のデータを格納する場合、このテーブルは非常に大きくなる可能性があります。各コンテンツ ノードに関連付けられた実際のコンテンツを格納するため、ほとんどの場合、このテーブルが最も大きいコンテンツ管理テーブルになります。
WebLogic Portal 内のコンテンツ検索では一般に、コンテンツ リポジトリに関連付けられたデータベース インデックスにアクセスした場合に最良のパフォーマンスが得られます。Oracle オプティマイザでは、データベース統計に応じて、データのアクセスにインデックスの代わりにテーブルスペース スキャンが実行される場合があります。このような場合、インデックスを使用した場合に比べて応答が非常に遅くなります。
応答時間を向上させるには、以下の Oracle 初期化パラメータが設定されていることを確認します。
optimizer_mode=choose
また、テーブルスペース スキャンよりも Oracle インデックスが確実に優先されるように、以下の 2 つの初期化パラメータを変更します。
optimizer_index_cost_adj (0 ～ 100 の範囲に設定)
optimizer_index_caching (0 ～ 100 の範囲に設定)
Oracle ドキュメントを参照してこれらの設定による影響を確認し、使用している環境に適合するかを確認してください。
各 DBMS には、クエリ オプティマイザで使用されるデータベース統計を更新するための独自のユーティリティやコマンドがあります。データベース管理者は定期的なジョブをスケジュールし、データベース統計を管理する必要があります。
多くの場合、データベースで収集される統計にはデータベースのテーブルおよびインデックスに関する編成情報が含まれています。
WebLogic Portal アプリケーションで実行される通常の DML 操作 (たとえば、DELETE、INSERT、UPDATE) は、テーブルおよびインデックスの編成に影響することがあります。これはデータベースのパフォーマンスにも影響する場合があります。テーブルとインデックスの再編成に使用できるユーティリティ、および再編成を行う時期の判断方法の詳細については、データベース ベンダの製品ドキュメントを参照してください。
WebLogic Portal データベースで行うバックアップと回復には、他のデータと同じ手順を使用します。以下に一般的な推奨事項を示します。
定期的にテスト復元を行い、バックアップに問題がないことを確かめます。
XA 用にコンフィグレーションされた Portal ドメインでオプションのコマース機能を使用する場合は、weblogic.jdbc.jts.commercePool JNDI 名を、portalFrameworkPool から cgDataSource-nonXA JDBC Tx データ ソースに移す必要があります。コマース機能の使い方の詳細については、WebLogic Workshop ヘルプの「アプリケーションにコマース サービスを追加する」を参照してください。
Propagation ユーティリティは、ポータル フレームワーク、datasync、セキュリティ データなど、あるポータル ドメイン環境のコンフィグレーション コンテンツを別のポータル ドメイン環境に伝播するプロセスをガイドします。たとえば、ステージング環境からプロダクション環境にポータル アプリケーションを移行する場合に、Propagation ユーティリティが役立ちます。
このユーティリティを使用する際には、使用法に注意が必要です。また、伝播を行う前にデータベースをバックアップする必要があります。このユーティリティの詳細については、BEA カスタマ サポートまでお問い合わせください。
可能な最大のパフォーマンスを達成するには、データベースと WebLogic Portal のインストールを共存させ、高速ネットワーク接続を使用して接続することによりネットワーク レイテンシの問題を回避する必要があります。この推奨は、Propagation ユーティリティを使用する場合に、大きな伝播プロセスが正常に完了するようにするために特に重要です。
|
|
|