|
|
この節では、WebLogic Portal データベースの設定とメンテナンスを行う際の考慮事項について説明します。
チーム開発でのデータベース環境の考慮事項については、『プロダクション業務ガイド』を参照してください。
ベンダ固有の考慮事項と推奨事項の詳細については、このガイドのデータベース ベンダに関連する章を参照してください。
WebLogic Portal のデータベース作成スクリプト (create_db.cmd/sh) は、JDBCDataLoader を呼び出すときにドメインの salt ファイルを使用します。
データベース プロパティ ファイル (database.properties および groupspace_database.properties など) のデータベース パスワードは、プレーン テキストを使用するかまたは暗号化することができます。暗号パスワードを取得するには、weblogic.security.Encrypt を使用します。パスワードの暗号化と暗号化解除に使用する salt ファイルは、ドメインの DOMAIN_HOME/security/SerializedSystemIni.dat salt ファイルです。
weblogic.security.Encrypt の詳細については、WebLogic Server ドキュメントの「WebLogic Server Java ユーティリティの使い方」を参照してください。
Localization Industry Standards Association (LISA) は、インターナショナライゼーションとローカライゼーションを次のように定義しています。
「インターナショナライゼーションとは、製品を再設計することなく複数の言語と文化的慣習に対応できるように、製品を汎用化するプロセスです。インターナショナライゼーションは、プログラム設計とドキュメント開発のレベルで行われます。」
「ローカライゼーションとは、製品が使用され、販売される対象地域 (国、地域および言語) に、製品を言語的、文化的に適応させることです。」
この節では、データベースの言語設定、文字セット、および照合 (ソート) 設定を選択する方法について説明します。節の内容は以下のとおりです。
ローカライズされるポータル アプリケーションを搭載する SQL Server を使用するには、データベースの作成を実行する前に、WL_HOME\portal\db\sql_server\admin\create_database.sql スクリプトの言語設定を変更する必要があります。
たとえば、言語設定を米国英語から日本語に変更するには、以下のように変更します。
SQL Server がポートする言語の詳細については、ベンダのドキュメントを参照してください。
Unicode 言語をサポートするポータル アプリケーションをローカライズする場合は、WL_HOME\portal\db\sql_server\admin\alter_use_unicode_columns.sql スクリプトを編集し、実行して、TEXT、CHAR、および VARCHAR タイプのすべてのカラムを対応する Unicode タイプ (それぞれ NTEXT、NCHAR、および NVARCHAR) を使用するように変更することができます。
| 警告 : | これらのカラムのデータ型の変更は、パフォーマンスに影響を与える場合があります。変更された各カラムは、元のデータ型の 2 倍の格納スペースが必要になります。 |
| 警告 : | このスクリプトを実行する前に、ポータル スキーマを含むデータベースをバックアップしてください。 |
このスクリプトを実行後、DBCC CHECKDB コマンドを使用して、物理ストレージとテーブルの制約を確認することができます。
データベースの文字セットは、データベースで使用できる言語を指定します。データベースの照合 (ソート順) は、ソートと比較の対象となる文字のルールを指定します。
グローバライズされた WebLogic Portal アプリケーションでは、データベースを設定する前にデータベースの文字セットとソート順を選択します。既存のデータベースの文字セットとソート順の変更作業は、時間とリソースを大量に消費します。一般的に、対象の文字セットがソース文字セットのサブセットである場合にのみ変更できます。
以下の節では、WebLogic Portal でサポートされるデータベースの文字セットとソート順の考慮事項について説明します。詳細については、ベンダ提供のドキュメントを参照してください。
Oracle の場合、データベースの作成時に文字セットを定義します。グローバライズされた Oracle 9i および 10g データベースでは、一般に使用される文字セットは AL32UTF8 です。
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\admin\create_database.sql にあります。これにより、WebLogic Portal データベースが COLLATE SQL_Latin1_General_CP1_CS_AS の設定で定義されます。
この定義では、大文字と小文字が区別されます。データベースで大文字と小文字を区別するように設定すると、SQL Server に対するコンテンツ管理のクエリは他のデータベースを対象にした場合と同様に動作します。コンテンツ管理の検索クエリが大文字と小文字を区別する環境用に記述されていない場合、予期しない結果が発生する場合があります。
sp_helpdb dbname ストアド プロシージャを使用して、SQL Server データベースの文字セットとソート順を表示できます。
MySQLでは文字セットを定義し、データベースの作成時に collate を設定します。MySQL の共通の文字セットおよび collate は、CHARACTER SET latin1 および COLLATE latin1_general_cs です。
MySQL では、UTF8 文字セットを使用する場合、キーの長さを1000バイトに制限します。UTF8 文字セットを使用する場合、CM_NODE.FULL_PATH および CM_PROPERTY.PROPERTY_NAME カラムは VARCHAR(255) の最大サイズに制限されているため、デフォルトでは MySQL データベースの文字セットを UTF8 にするとデータベース オブジェクト作成エラーが送出されます。したがって、今回は MySQL で UTF8 文字セットを使用しません。
Sybase では、Sybase インスタンスの作成時に文字セットとソート順を定義します。Sybase で一般に使用される文字セットとソート順は以下のとおりです。
Character Set = 2, cp850 Code Page 850 (Multilingual)
Sort Order = 50, bin_cp850 Binary ordering, for use with Code Page 850 (cp850).
sp_helpsort ストアド プロシージャを使用して、インスタンスの文字セットとソート順の情報を表示できます。
DB2 データベースでは、個々のデータベースに対して文字エンコーディングを設定できます。デフォルトの文字エンコーディングは、オペレーティング システムによって異なります。
DB2 で一般に使用される文字エンコーディングは UTF-8 です。
DB2 CODESET コンフィグレーション パラメータを使用して、データベースのコードセットを確認できます。
この節では、データベースのパフォーマンスを最適化する際に考慮すべき要因について詳細に説明します。節の内容は以下のとおりです。
ネットワーク レイテンシの問題を防ぐには、同じデータ センタ内にデータベースと WebLogic Portal インスタンスを探す必要があります。この推奨は、Propagation Utility を使用する場合に、大きな伝播プロセスが正常に完了するようにするために特に重要です。
データベース アクセスの頻度は、使用する機能とそれを使用する方法によって大幅に異なります。データベース アクセスの頻度を減らすことによって、最適パフォーマンスのポータルをコンフィグレーションする場合、キャッシングが大きな役割を果たします。
コア ポータル フレームワークでは、すべてのユーザが共有するポータルの分類が初期化時にメモリにロードされます。したがって、データベース アクセスは通常初期化後に頻度が低下します。ユーザがポータルをカスタマイズしている場合は、初めてアクセスするときにデータベースの読み込みを行い、カスタマイズ設定、ユーザ プリファレンスなどを取得する必要があります。
また、その他多くの製品の機能が、コンテンツ管理ストアなどのデータベースを使用します。コンテンツが頻繁にアクセスされる場合は、できるかぎりキャッシングを使用することをお勧めします。そうでない場合、データベース アクセスではコンテンツの取得が必要になります。
いくつかのデータベースには、データベース テーブルをメモリにキャッシュまたは固定する機能があります。アプリケーションにデプロイされている WebLogic Portal コンポーネントとそのデプロイ方法に基づいて、データベース キャッシュの実装を選択します。
各データベース タイプでサポートされる、データベース テーブルのキャッシュまたは固定機能について説明します。環境によっては、キャッシュ戦略の対象を小さいテーブルおよび頻繁に参照されるテーブルに設定することができます。
DBCC PINTABLE (database_id, table_id) コマンドを使用できる。sp_objects_stats で必要なオブジェクトを識別し、キャッシュを使用して最適化します。Sybase モニタ ツールまたは sp_sysmon を使用して、キャッシュ ヒット率が許容できるかどうかを判断します。 BUFFERPOOL コンフィグレーション パラメータを使用して、データベースのデータをキャッシュする。この処理はチューニング作業の中心になります。DB2 では個々のテーブルおよびインデックスをバッファプールに割り当てることができます。
Sybase インスタンスのデフォルトのロック メカニズムは ALL PAGES です。同時実行性のため、Sybase データベースの各テーブルについてロックを定義することもできます。
以下の Sybase 用の WebLogic テーブルは LOCK DATAROWS で定義されています。Sybase のその他の WebLogic Portal テーブルは LOCK DATAPAGES で定義されています。
Sybase データベースを使用する WebLogic Portal コンポーネントの使用方法に基づいて、追加のテーブルを LOCK DATAROWS に変更できます。
WebLogic Portal 内のコンテンツ検索では、一般にコンテンツ リポジトリに関連付けられたインデックスを使用した場合に最良のパフォーマンスが得られます。Oracle オプティマイザでは、データベース統計に応じて、データのアクセスにインデックスの代わりにテーブルスペース スキャンが実行される場合があります。このような場合、インデックスを使用した場合に比べて応答が非常に遅くなります。
応答時間を改善するには、optimizer_mode の Oracle 初期化パラメータが choose に設定されていることを確認します。
また、テーブルスペース スキャンよりも Oracle インデックスが確実に優先されるように、以下の 2 つの初期化パラメータを変更できます。
optimizer_index_cost_adj (0 - 100 の範囲に設定)
optimizer_index_caching (0 - 100 の範囲に設定)
これらの設定の詳細については、Oracle ドキュメントを参照してください。インストールすると変更の効果が反映されます。
各 DBMS には、クエリ オプティマイザで使用されるデータベース統計を更新するための独自のユーティリティやコマンドがあります。多くの場合、データベースで収集される統計にはデータベースのテーブルおよびインデックスに関する編成情報が含まれています。データベース管理者は定期的なジョブをスケジュールし、データベース統計を管理する必要があります。
WebLogic Portal アプリケーションで実行される DML (Data Manipulation Language) 操作 (たとえば、DELETE、INSERT、UPDATE) は、テーブルおよびインデックスの編成に影響することがあります。これはデータベースのパフォーマンスにも影響する場合があります。テーブルとインデックスの再編成に使用できるユーティリティ、および再編成を行う時期の判断方法の詳細については、データベース ベンダのドキュメントを参照してください。
以下の節では、インデックスの配置、CLOB/BLOB/TEXT/IMAGE データ ストレージ、および行動追跡に関する特別な考慮事項、推奨事項、要件について説明します。
Oracle データベースでは、rebuild_indexes.sql スクリプトを使用して、インデックスを WEBLOGIC_INDEX テーブルスペースなどの固有のテーブルスペースに移動します。WebLogic Portal データベースの作成後に手動でこのスクリプトを実行し、インデックスを専用のテーブルスペースに移動します。詳細については、「Oracle データベースのコンフィグレーション」を参照してください。
SQL Server および Sybase では、インデックスを専用のファイル グループまたはセグメントに配置するための非クラスタ インデックス用データ定義言語 (DDL) が ON WEBLOGIC_INDEX で定義されています。WebLogic Portal データベースの作成スクリプトまたは更新スクリプトを実行する前に、WEBLOGIC_INDEX ファイル グループまたはセグメントを定義しておく必要があります。付属の create_database.sql サンプル スクリプトは WEBLOGIC_INDEX を適切に定義します。
この節では、CLOB/BLOB (Oracle/DB2) または TEXT/IMAGE (Sybase/SQL Server) データがテーブルに含まれる場合の推奨事項および特別な考慮事項について説明します。
一般的に、サポートされるすべての WebLogic Portal データベース プラットフォームで最適なパフォーマンスを得るためには、CLOB/BLOB/TEXT/IMAGE テーブル データはその他のタイプのデータと物理的に分離する必要があります。しかし、デプロイメントを簡素化してコンフィグレーションの柔軟性を高めるため、デフォルトの WebLogic Portal データベース スキーマではデプロイの際にデータが分離されていません。特定のアプリケーションで CLOB/BLOB/TEXT/IMAGE ストレージを分離すべきかどうかを判断するには、使用している環境で以下の考慮事項を評価します。
該当するテーブル カラムは BT_EVENT.XML_DEFINITION です。
ストレージ割り当ての変更については、ベンダのドキュメントの CLOB/BLOB/TEXT/IMAGE データの設定の変更に関する詳細を参照してください。
CLOB/BLOB または TEXT/IMAGE データ型を含む以下のカラムが追加されました。これらを使用して実際にストレージを変更し、パフォーマンスにどの程度影響があるかを確認できます。
行動追跡により、パーソナライズされたポータル アプリケーションを開発、管理、および測定できます。イベントを記録することにより、ポータル アプリケーションをカスタマイズし、訪問者の行動を追跡することができます。
行動追跡を有効に設定した場合、BT_EVENT テーブルに書き込める行数が非常に多くなるため、行動追跡データの格納に別個のデータベース (DBMS によってはテーブルスペースとスキーマ) を使用できます。
PointBase 以外のデータベースの場合、行動追跡イベント用の独立したデータベースの作成の詳細については、このガイドのデータベース ベンダに関連する章を参照してください。
この節では、データベース、ページ、ブロック、およびデータ型のサイズ構成の考慮事項について説明します。
WebLogic Portal データベースにサイズ構成は、以下の事項を含むさまざまな要因によって異なります。
以下の節では、増分を緊密に監視する必要のあるいくつかの WebLogic Portal データベース テーブルについて説明します。
行動追跡が有効に設定されている場合、BT_EVENT テーブルは非常に大きくなる可能性があります。
以下のデータベース テーブルにはパーソナライゼーション データが格納されます。これらのデータの増分を監視する必要があります。
以下のテーブルは Portal Framework および WSRP (Web Services for Remote Portlets) で使用され、規模が大きくなる可能性があるため、データの増分を監視する必要があります。
BOOK_DEFINITION のインスタンスが識別されます。最低 1 つのブック インスタンス (プライマリ インスタンス) が常に存在します。他のすべてのインスタンスは、管理者またはエンド ユーザによるカスタマイズを表します。ユーザ カスタマイズが多数発生した場合、このテーブルは非常に大きくなる可能性があります。 ユーザ数 * ページ数 * ポートレット数 = 行数
ポートレット定義の数 * インスタンス数 = 行数
ポータル数 * デスクトップ数 + カスタマイズした訪問者数
= 行数
以下のデータベース テーブルにはコンテンツ管理 (CM) データが格納されます。これらのデータの増分を監視する必要があります。
BOOK のプロパティである SUBJECT の値には、FINANCE などがあります。コンテンツ管理を使用して大量のデータを格納する場合、このテーブルは非常に大きくなる可能性があります。各コンテンツ ノードに関連付けられたメタデータを格納するため、ほとんどの場合、このテーブルが最も大きいコンテンツ管理テーブルになります。
以下のデータベース テーブルにはコミュニティ データが格納されます。これらのデータの増分を監視する必要があります。複数のコミュニティを使用しているか、ユーザ数が多い場合は、これらのテーブルが基本的なポータル フレームワークのカスタマイズ テーブルより大きなスペースを使用すると考えられます。
Oracle および SQL Server データベースのデフォルトのページ サイズとブロック サイズは 8K です。
DB2 データベースでは、大きいプール サイズ (デフォルトの 4K よりも大きい) を必要とする WebLogic Portal のテーブルおよびインデックス用に 8K のバッファプールが定義されています。
Sybase データベースでは、WebLogic Portal のテーブルおよびインデックス用に 8K のページ サイズが必要な場合があります。Sybase では、ページ サイズは 2K であり、複数のページにまたがる行を使用できません。Sybase インスタンスのページ サイズが 2K または 4K の場合は、8K の Sybase インスタンスを新たに作成します。Sybase には、ページ サイズが異なるサーバ間でデータを移行するための、移行ユーティリティが用意されています。
| 注意 : | データベース固有の考慮事項の詳細については、このガイドのデータベース ベンダに関連する章を参照してください。 |
DB2 および PointBase データベースでは、データベース テーブルの作成時に、WebLogic Portal が 30MB の最大 BLOB/CLOB サイズを指定します。もっと大きいサイズが必要な場合は、該当するデータベース作成スクリプトを編集して、この値を変更することができます。データベース スクリプトの場所と説明については、「プロパティ ファイルおよびデータベース スクリプト」とこのガイドのデータベース ベンダに関連する章を参照してください。
一般的には、データベースに適用されるサイズ制限に注意する必要があります。この制限はデータベースのバージョンによって異なる場合があります。詳細については、ベンダのドキュメントを参照してください。
WebLogic Portal データベースで行うバックアップと回復には、他のデータベース データと同じ手順を使用します。
バックアップと回復のための一般的な推奨事項は以下のとおりです。
定期的にテスト復元を行い、バックアップに問題がないことを確かめます。
WebLogic Portal Propagation Utility を使用して、ポータルのメタデータを 1 つのポータル環境から別のポータル環境に移動します。このユーティリティを使用する際には、使用法に注意が必要です。また、伝播を行う前にデータベースをバックアップする必要があります。
設計では、ポータル環境を移動する場合、すべてのデータベース データは伝播されません。たとえば、ユーザおよびグループ データは伝播されません。
Propagation Utility と伝播されるデータベース データの詳細については、『プロダクション業務ガイド』を参照してください。このガイドは、チーム開発の場合のデータベース環境の考慮事項についても説明しています。
コマース機能を使用する場合は、portalDataSourceNeverXA-jdbc.xml などの非 XA データ ソース コンフィグレーションを使用する必要があります。
portalDataSource-jdbc.xml ファイルから jndi-name weblogic.jdbc.jts.commercePool を削除し、portalDataSourceNeverXA-jdbc.xml ファイルに追加します。
伝達情報を格納する JMS および JMS データベース テーブルがデータベースに作成されていない場合、WebLogic Server によって自動的に作成されます。ポータル リソースの伝達モード設定では、ポータル リソース (ページ、ブック、ポートレット) の更新をデスクトップおよびユーザによりカスタマイズされたインスタンスに転送、つまり伝達する方法を指定します。WebLogic Portal Administration Console を使用して、このモードを非同期、同期、またはオフに設定することができます。
伝達が非同期 (デフォルト) で実行される場合、JMS キューが使用されます。このために XA ドライバが必要になります。この場合は、portalDataSourceAlwaysXA-xml データ ソースが使用されます。このため、データベース環境が XA をサポートするようにコンフィグレーションする必要があります。
WebLogic Portal データベース オブジェクトの作成や更新に create_db.cmd （または create_db.sh) コマンドを実行すると、weblogic ユーザの管理者のパスワードは、デフォルトでは weblogic に設定されます。管理者ユーザにデータベースのパスワードを設定するには、以下の手順に従います。
  
|
