この項の内容：
この章の情報は、ブロック・ストレージ・データベースのみに適用され、集約ストレージ・データベースとは関係がありません。集約ストレージとブロック・ストレージの比較。も参照してください。
データベースが読取り/書込みモードにある場合、Essbaseでは、サーバーへのすべての更新要求(データ・ロード、計算、計算スクリプト内のステートメントなど)がトランザクションと見なされます。Essbaseは、トランザクション制御ファイル(dbname.tct)内のトランザクションに関する情報を追跡します。
トランザクション制御ファイルには、各トランザクションのエントリが含まれており、各トランザクションの現在の状態(アクティブ、コミット済または異常終了)が追跡されています。
Essbaseによるトランザクションの処理方法の理解を参照してください。
分離レベルによって、Essbaseがディスクへのデータをコミットする方法が決定されます。データがコミットされると、そのデータはサーバー・メモリーから取得され、ディスク上のデータベースに書き込まれます。Essbaseは、ディスクへのデータを自動的にコミットします。データ・ブロックをコミットするためにユーザーが実行する明示的なコマンドは存在しません。ただし、データベースの分離レベルを設定すると、Essbaseがデータ・ブロックを自動的にコミットする方法が定義されます。
Essbaseは、コミット・アクセスとアンコミット・アクセス(デフォルト)という、トランザクションのための2つの分離レベルを提供しています。コミット・アクセスを使用して、データの整合性を最適化できます。
アクセス・タイプの説明については、コミット・アクセスおよびアンコミット・アクセスを参照してください。
Essbaseは、作成、更新または削除されるブロックに対して書込み(排他)ロックを発行し、アクセスはされるが、変更は許可されないブロックに対して読取り(共有)ロックを発行します。適切なロックを発行することによって、Essbaseでは、ある操作で変更されたデータが同時更新によって壊されることがないようにしています。
この項では、データベース・アーティファクトに対するロックではなく、データ・ブロックに対するロックについて説明します。アウトラインやその他のアーティファクトのロックおよびロック解除については、アーティファクトのロックおよびロック解除を参照してください。
表156で、ロック・タイプについて説明します:
表 156. 基本的なロック・タイプ
|
ロックされたデータ・ブロックが、他の任意のトランザクションによってアクセスされないようにします。スプレッドシートのロックして送信操作を含む、すべてのデータ・ブロック更新に使用されます。 | |
|
他のトランザクションがデータ・ブロックに対して読取り専用アクセスを行えるようにしますが、データ・ブロックの変更はできないようにします。 |
表157は、Essbaseが様々なタイプの操作のために発行するロックを示しています。
Essbaseがロックを処理する方法は、コミット・アクセスまたはアンコミット・アクセスのどちらが使用可能になっているかによって異なります。
コミット・アクセスでは、一度に1つのトランザクションのみがデータ・ブロックを更新できるため、高レベルのデータの一貫性が提供されます。コミット・アクセスの場合、Essbaseは、トランザクションが完了してコミットされるまで、そのトランザクションに関連したすべてのデータ・ブロックに対する読取り/書込みロックを保持できるようにします。ただし、最後にコミットされたデータ値への読取り専用アクセスは引き続き許可できます。
Essbaseには、データ・ブロックに対するロックの発行時期を決定するためのオプションが用意されています:
プリイメージ・アクセスが使用可能であれば、ユーザーは、データ・ブロックへの読取り専用アクセスには制限されません。ロックされたブロックへの書込みアクセスが必要な場合は、待機またはタイムアウトの設定に応じて、トランザクションが書込みアクセスを待機するか、またはタイムアウトします。トランザクションは、別のトランザクションによってロックされていないデータ・ブロックへの書込みアクセスを即座に取得します。
プリイメージ・アクセスが使用不可であり、ロックされたブロックへの読取りまたは書込みアクセスが必要な場合は、待機またはタイムアウトの設定に応じて、トランザクションが書込みアクセスを待機するか、またはタイムアウトします。
コミット・アクセスでは、メモリーに関して次の点を考慮する必要があります:
Essbaseでは、トランザクションがコミットされるまで、冗長データが保持されます。冗長データを収容するために、ディスク・スペースがデータベースのサイズの2倍になるようにしてください。
多数のブロックを含むモデルでは、コミット・アクセスでのメモリーに関する問題が発生する場合があります。1つの計算当たり各ロック(ブロックごとに1つのロック)に約80バイトのメモリーが使用され、各ロックはトランザクションが完了するまでメモリー内に保持されます。プロセス当たりのアドレス可能なメモリー・スペースには制限があるため、多数のブロックを含むモデルは最終的にこの制限に達する可能性があり、それによってトランザクションが終了します。このような場合は、アンコミット・アクセスを使用することを検討してください。
コミット・アクセスでは、読取りおよび書込みアクセスのためにEssbaseによってブロックがロックされます:
表158は、複数のトランザクションが同じデータに対するロックの取得を競合しているときのコミット・アクセスでのロックの動作を示しています。この例では、トランザクションTx1が実行中であり、トランザクションTx2が同じデータへのアクセスを要求しています。(ロックされたブロックへのアクセスが、使用可能になっているオプションによって異なることに注意してください。オプションの説明については、コミット・アクセスを参照してください。)
並行性パラメータの設定情報については、データの整合性設定の指定を参照してください。
コミット・アクセスでは、2つのトランザクションが同じブロックをロックしたり、同じブロックにアクセスしようと待機したりしているとデッドロックが発生して、どちらのトランザクションも完了できなくなる状態になる場合があります。
たとえば、トランザクションTx1で最初にデータ・ブロックB1を、次にデータ・ブロックB2を更新する必要がある場合は、まずB1をロックした後、B2をロックしようとします。一方、トランザクションTx2で最初にデータ・ブロックB2を、次にブロックB1を更新する必要がある場合、Tx2はまずB2をロックした後、B1をロックしようとします。Tx1はB1をロックした後にB2を待機しており、Tx2はB2をロックした後にB1を待機しています。
Essbaseのトランザクションは、ロックを取得しようと待機している間、定期的にデッドロック検出を実行します。デッドロックが検出された場合は、Essbaseによってエラー・メッセージが発行され、そのトランザクションは失敗します。
別のユーザーによってロックされているブロックを更新しようとすると、Essbaseは次のように動作します:
並行性オプションの設定方法については、データの整合性設定の指定を参照してください。
コミット・アクセスでは、サーバーがクラッシュした場合、サーバーが停止した時点で実行されていたトランザクションによるすべてのデータベース更新がEssbaseによってロール・バックされ、中止されたトランザクションによって実行された変更は確実に元に戻されます。
トランザクションが致命的でないエラーのために中止された場合は、そのトランザクションによって実行されたすべての変更がロール・バックされます。
クラッシュしたデータベースのリカバリを参照してください。
アンコミット・アクセス(デフォルトで使用可能)では、Essbaseカーネルは、トランザクションがブロックごとに読取り/書込みロックを保持できるようにします。Essbaseは、更新されたブロックを解放しますが、トランザクションが完了するか、または指定された制限(「同期ポイント」)に達するまでそのブロックをコミットしません。この制限は、下に示す方法で設定できます。
アンコミット・アクセスでは、最後にコミットされた時点のデータへの読取り専用アクセスがEssbaseによって許可されるため、同じデータ・ブロックにユーザーが同時にアクセスすると予期しない結果が発生する場合があります。
アンコミット・アクセスでは、次に示す同期ポイント・パラメータを指定することによって、Essbaseによって明示的なコミット操作が実行されるタイミングを制御できます:
「行のコミット」(同期ポイントが発生するまでのデータ・ロードの行数)。デフォルトは0です。これは、データ・ロードの最後に同期ポイントが発生することを示します。
「ブロックのコミット」または「行のコミット」のどちらかが0以外の値になっている場合は、最初のしきい値に達した時点で同期ポイントが発生します。たとえば、「ブロックのコミット」は10だが、「行のコミット」が0のときにデータをロードした場合は、10ブロックが更新された後に同期ポイントが発生します。「ブロックのコミット」が5で、「行のコミット」が5のときにデータをロードした場合は、5行のロードと5ブロックの更新のどちらか早い方の後に同期ポイントが発生します。
操作中にユーザー定義のしきい値を超えると、Essbaseにより、その時点まで処理されたデータをコミットするための同期ポイントが発行されます。Essbaseでは、操作を完了するために必要な数だけの同期ポイントが実行されます。
Essbaseでは、並列計算の使用の実行可能性を分析中に「ブロックのコミット」と「行のコミット」の値を分析します。これらのパラメータが低すぎる値に設定されていることがEssbaseによって検出されると、値は自動的に増加します。 |
同期ポイント・パラメータを指定する方法については、データの整合性設定の指定を参照してください。
Essbaseでは、トランザクション・セマンティクスを適用するために冗長データが保持されます。特に「ブロックのコミット」と「行のコミット」の両方を0に設定する場合は、冗長データを収容するために、ディスク・スペースがデータベースのサイズの2倍になるようにしてください。 |
データ・キャッシュが小さすぎるために「ブロックのコミット」や「行のコミット」の設定で指定されたブロック数を保持できない場合は、トランザクションがコミットされる前であっても、キャッシュがいっぱいになるとすぐにブロックがディスクに書き込まれます。
アンコミット・アクセスでは、Essbaseでブロックの更新が終了するまで、書込みアクセスのためにEssbaseによってブロックがロックされます。コミット・アクセスでは、トランザクションが完了するまで、Essbaseによってロックが保持されます。
表159は、多数のトランザクションが同じデータに対するロックの取得を競合しているときのアンコミット・アクセスでのロックの動作を示しています。この例では、トランザクションTx1が実行中であり、トランザクションTx2が同じデータへのアクセスを要求しています。
アンコミット・アクセスでは、サーバーがクラッシュした場合、最後の正常なコミットの時点からのすべてのデータベース更新がEssbaseによってロール・バックされます。中止されたトランザクションの一部である更新がコミットされている可能性があります。トランザクションが、ユーザーが期待している方法で更新をコミットしたかどうかは、重複したトランザクションによってデータが更新され、コミットされた順序によって異なります。
トランザクションが致命的でないエラーのために中止された場合は、そのトランザクションが中止される前にトランザクションによって処理が終了したデータのみがEssbaseによってコミットされます。
クラッシュしたデータベースのリカバリを参照してください。
データベースのパフォーマンス。
アンコミット・アクセスでは常に、コミット・アクセスより優れたデータベースのパフォーマンスが得られます。アンコミット・アクセスを使用している場合は、トランザクションの処理中に保持されるロックがEssbaseによって作成されず、短期間の書込みロックに基づいてデータがコミットされます。
データの一貫性。
コミット・アクセスでは、アンコミット・アクセスより高いレベルのデータの一貫性が提供されます。データベースからの取得の一貫性も優れています。また、分離レベルがコミット・アクセスに設定されている場合は、一度に1つのトランザクションのみがデータ・ブロックを更新できます。複数のトランザクションがデータベースを同時に更新しようとするデータベースでは、この要素が重要です。
データの並行性。
アンコミット・アクセスでは、コミット・アクセスより優れたデータの並行性が提供されます。ブロックは、コミット・アクセス中よりも頻繁に解放されます。コミット・アクセスでは、デッドロックが発生する可能性があります。
データベースのロールバック。
アクティブなトランザクション中にサーバーのクラッシュやその他のサーバーの中断が発生した場合は、サーバーが再起動されたきに、Essbaseカーネルによってトランザクションがロール・バックされます。コミット・アクセスでは、ロールバックによって、データベースはトランザクションの開始前の状態に戻ります。アンコミット・アクセスでは、ロールバックによって、コミットされるデータとコミットされないデータが発生する可能性があります。
サーバーの中断が発生した場合に予測される結果を参照してください。
Essbaseではトランザクションを開始から終了まで追跡し、必要に応じてメモリーへのデータ・ブロックのスワップ・インやスワップ・アウトを行ったり、トランザクションの完了時にデータ・ブロックをコミットしたりします。次のリストは、Essbaseでトランザクションを処理する方法を示しています。これらのリスト・アイテムはすべて、コミットおよびアンコミット・アクセスに適用されます(分離レベルの理解を参照)。
Essbaseカーネルにより、要求されたデータが特定されます。OLAPエンジンに、データと関連付けられた制御情報が渡されます。スプレッドシートを使用している場合は、シート上にこのデータが表示されます。
OLAPエンジン側で操作が完了すると、OLAPエンジンは更新についてEssbaseカーネルに通知し、Essbaseカーネルがそれに応じて内部のデータ構造を更新します。
トランザクションが終了します。トランザクション処理中にEssbaseでエラーが検出された場合は、そのトランザクションが中止されます。エラーが発生しない場合は、Essbaseによってそのトランザクションがコミットされます。コミット・アクセスとアンコミット・アクセスでのコミット動作の違いについては、分離レベルの理解を参照してください。
Essbaseは、クライアントにトランザクションが完了したことを通知するメッセージ(たとえば「計算の合計経過時間...」)を発行します。
アンコミット・アクセスでは、アクティブな複数のトランザクションが同じデータにアクセスしている場合に、コミットされていないデータにアクセスしてしまうことがあります。アンコミット・アクセスでは、トランザクションの結果は予測できません。
アンコミット・アクセスでは、コミットしきい値が定義されていると、Essbaseで1つのデータベース操作を複数の同期ポイントに分割する必要がある場合があります。コミットしきい値については、アンコミット・アクセスを参照してください。
Administration Services、MaxLまたはESSCMDを使用して、分離レベル、同期ポイント・パラメータおよび並行性パラメータを指定できます。分離レベル設定への変更は、次回、アクティブなトランザクションが存在しなくなったときに有効になります。どちらの設定を選択するかの判断については、コミット・アクセスおよびアンコミット・アクセスを参照してください。
ESSCMDで分離レベル設定を指定するには、ESSCMDでSETDBSTATEITEM 18と入力し、プロンプトに従うか、コマンドラインに必要な値を入力します。
1 (コミット・アクセス)または2 (アンコミット・アクセス、デフォルト)を選択します。指定した値に応じて、ESSCMDから他のパラメータを入力するよう求められます(または、コマンドラインで値を指定できます)。
1 (コミット・アクセス)を選択した場合、次の情報の入力を求めるプロンプトが表示されます:
2 (アンコミット・アクセス)を選択した場合は、ESSCMDから次の値を入力するよう求められます。これらのオプションの説明については、アンコミット・アクセスを参照してください。
また、SETDBSTATEITEMで19から22のパラメータを指定することによって、分離レベル・パラメータ(プリイメージ・アクセスなど)を指定できます。パラメータを指定しないでSETDBSTATEITEMを入力すると、ESSCMDによって、各パラメータの番号とそれぞれの説明が記載されたリストが表示されます。
分離レベルを設定するためのSETDBSTATEITEMの使用例を次に示します。この例では、コミット・アクセスおよびプリイメージ・アクセスを使用可能にして、無限の待機時間を指定します。
SETDBSTATEITEM 18 "SAMPLE" "BASIC" "1" "Y" "-1"
データの整合性を保証するために、Essbaseカーネルでは、冗長な(重複した)情報が一時的に保持されます。冗長な情報を収容するために、ディスク・スペースがデータベースのサイズの2倍になるようにしてください。
データベースの整合性を検証し、データベースの破損がないかどうかを確認するには、次のアクションを実行します:
密な再構築を実行します。密な再構築では、データベース内のすべてのブロックが再作成されるので、これにより各ブロックのインデックス・ノードやセルが確認されます。
データベースからすべてのレベルのデータをエクスポートします。データベース全体のエクスポートでは、データベース全体にわたるブロックおよびすべてのデータ値がアクセスされます。
ESSCMD VALIDATEコマンドを使用して、構造およびデータの整合性を確認します。VALIDATEを使用した整合性の検査を参照してください。
これらのいずれかの確認中にエラーが発生した場合は、データベースをバックアップから復元します。『Oracle Hyperion Enterprise Performance Management Systemバックアップおよびリカバリ・ガイド』を参照してください。
VALIDATEコマンドによって、多くの構造およびデータの整合性が検査されます:
Essbaseで不一致が検出されると、VALIDATEエラー・ログにエラー・メッセージが記録されます。エラー・ログのファイル名を指定できます。指定しなかった場合は、Essbaseからこの情報を入力するよう求められます。VALIDATEユーティリティは、データベース全体を確認し終わるまで実行されます。
ESSCMDのVALIDATEコマンドで、これらの構造の整合性の検査を実行できます。
インデックスの空きスペースの検証中に、VALIDATEコマンドによってインデックス内の空きスペース情報の構造の整合性が確認されます。整合性エラーがあった場合は、それらのエラーがEssbaseによってVALIDATEログに記録されます。エラー・ログは、VALIDATEコマンドで指定したファイルに保持されます。
VALIDATEでインデックスの空きスペース情報に関連した整合性エラーが検出された場合は、データベースを再構築する必要があります。再構築を行うには、次の3つの方法があります:
データベースの再構築の最適化および『Oracle Hyperion Enterprise Performance Management Systemバックアップおよびリカバリ・ガイド』を参照してください。
VALIDATEを使用しない場合でも、読取り操作が実行される場合は常にEssbaseによって一定の妥当性の検査が自動的に実行され、インデックスがデータと同期されていることが確認されます。
すべての読取り操作について、Essbaseによってインデックス・ページ内のデータ・ブロック・キーと対応するデータ・ブロック内のデータ・ブロック・キーが比較され、ブロック内の他のヘッダー情報が確認されます。
クラッシュなどのサーバーの中断の後、Essbaseによってデータベースがリカバリされ、中断の発生時にアクティブであったすべてのトランザクションがロール・バックされます。リカバリ時間は、インデックスのサイズによって異なります。インデックスが大きいほど、時間がかかります。
また、Essbaseによって、空きフラグメント(データ・ブロック内の未使用のアドレス可能な単位)もリカバリおよび統合されます。ただし、空きスペースのリカバリはデータベース・リカバリにおいて最も時間のかかる処理であるため、デフォルトでは後回しにされます。空きスペースのリカバリは、デフォルト設定を変更していないかぎり明示的にトリガーする必要があります。空きスペースのリカバリを遅らせることのメリットとデメリットについては、空きスペースのリカバリを参照してください。
Essbaseでは、サーバーの中断の後、サーバーが起動されるとすぐにデータがリカバリされます。リカバリのフェーズは次のとおりです:
メディア障害(欠陥のあるディスク、ディスク障害またはヘッド・クラッシュ)が発生した場合は、バックアップからデータを復元する必要があります。『Oracle Hyperion Enterprise Performance Management Systemバックアップおよびリカバリ・ガイド』を参照してください。
essxxxxx.ind、essxxxxx.pag、dbname.ind、dbname.esm、dbname.tctの各ファイルは移動、コピー、変更または削除しないでください。データが破損する場合があります。 |
Essbaseカーネルは、致命的なエラーの処理を使用することにより、発生したエラーに応じて適切なメッセージを表示したり、サーバーをシャット・ダウンしたりします。致命的なエラーの処理の動作については、致命的なエラーの処理の理解を参照してください。
クラッシュの後にトランザクションがロール・バックされる方法については、コミット・アクセスとアンコミット・アクセスの比較を参照してください。
データベース・リカバリは、直前にクラッシュしたか、または異常終了したアプリケーションをロードしたときに実行されます。空きスペースのリカバリは、データベース・リカバリの中で最もコストの高い部分であるため、Essbaseによって自動的には実行されません。空きスペースのリカバリを明示的にトリガーするか、またはEssbaseによって空きスペースが自動的にリカバリされるようにデフォルト設定を変更する必要があります。
空きスペースをリカバリするかどうかにかかわらず、すべてのデータベース機能が正常に実行されます。空きスペースをリカバリした場合は、データ・ファイル内の空きとしてマークされたディスク・スペースを再利用できます。空きスペースのリカバリには時間がかかるため、より適切な時期まで遅らせることもできます。
ただし、データ・ファイル内の空きスペースを利用したり、データベースが破損していないことを確認したりするためには、できるだけ早く空きスペースのリカバリを実行する必要があります。また、データベースが繰り返しクラッシュしていて、空きスペースのリカバリを実行していない場合は、データ・ファイルが不必要に大きくなっている可能性があります。
空きスペースのリカバリをトリガーするには、MaxLのalter databaseコマンドを使用します。例:
alter database DBS-NAME recover freespace
空きスペースのリカバリに対するデフォルトの動作を変更するには、DELAYEDRECOVERY構成設定をFALSEに変更します。『テクニカル・リファレンス』の「設定の構成」を参照してください。
空きスペースのリカバリに関する情報を取得するには、GETDBSTATSコマンドを使用します。GETDBSTATSでは、空きスペースのリカバリに関する次の情報が提供されます:
Free Space is Recoverable : true/false
Estimated Bytes of Recoverable Free Space :
nnn
表160は、Essbaseサーバーの中断のタイプとその結果を示しています:
表 160. Essbaseのリカバリ処理
|
Essbaseにより致命的なエラーの処理が実行されます。より多くのメモリーまたはディスク・スペースを割り当て、サーバーを再起動することが必要な場合があります。 | |
|
Essbase例外マネージャによって、タイプ.xcpのエラー・ログが作成されます。サーバーが停止します。サーバーを再起動すると、Essbaseによってデータベースがリカバリされます。 |
表161は、トランザクション中にサーバーの中断が発生した場合に実行する必要のある手順を示しています。Essbaseが中断からリカバリする方法は、トランザクションの分離レベル設定(コミット・アクセスまたはアンコミット・アクセス)によって異なります。コミット・アクセスでのロールバックおよびアンコミット・アクセスでのロールバックを参照してください。
|
Essbaseによってエラーが発行された場合は、最後の送信操作を繰り返します。 スプレッドシートが失われたか、または存在しないとき、SSAUDITのスプレッドシート・ロギングを使用している場合は、dbname.atxファイルを再ロードします。スプレッドシート更新ロギングの使用方法を参照してください。 | |
|
サーバー・ログおよびアプリケーション・ログを確認して、計算がどこで中断しているかを確認します。Essbaseサーバー・ログおよびアプリケーション・ログの表示を参照してください。計算をやり直すかどうかを決定します。最後の計算を繰り返します。 | |
| |
|
データベースがコミット・アクセスに設定されている場合は、データを再ロードします。(トランザクションはロール・バックされています。) データベースがアンコミット・アクセスに設定されている場合は、一部のデータがロードされているため、すべてのデータを再ロードすると、2回ロードされたデータ値が原因で結果が不正確になります。そのため、次のアクションを実行します: | |
|
再構築が完了していません。.pan、.innおよび.otnの一時的な再構築ファイルを削除します。再構築を実行した最後の操作を繰り返します。 |
データ損失に対する追加の保護およびスプレッドシート監査情報のために、Essbaseには、スプレッドシート更新ロギングが用意されています。この機能は、サーバー上のessbase.cfgファイル内のSSAUDITまたはSSAUDITRパラメータで使用可能にできます。SSAUDITは、サーバー上のすべてのデータベースに対して、または個別のデータベースに対して指定できます。『Oracle Essbaseテクニカル・リファレンス』を参照してください。
通常の状況では、Essbaseによってリカバリが処理されます。ただし、スプレッドシート更新ログを手動でロードすることもできます。たとえば、最新のバックアップから復元したが、そのバックアップ以降に加えられた変更を失いたくない場合や、メディア障害が発生した場合は、更新ログからトランザクションをリカバリできます。これには、Essbaseサーバー・ウィンドウから、Essbaseのコマンドライン機能であるESSCMDを使用します。
次の一連のESSCMDコマンドで、更新ログがロードされます:
LOGIN
hostnode username password
SELECT
appname dbname
LOADDATA 3
filepath
:
appname
.ATX
EXIT
更新ログのロードを簡略化するには、バッチ・プロセスにおけるスクリプト・ファイルおよびバッチ・ファイルの使用で説明されているバッチ・ファイルを準備します。
SSAUDITまたはSSAUDITRが指定されている場合は、Essbaseによって、スプレッドシート更新トランザクションが時間の経過順にログに記録されます。Essbaseでは、次の2つのファイルが使用されます:
スプレッドシート更新ログはかなり大きくなることがあり、SSAUDITRを使用している場合でも、Essbaseではデータがバックアップされた後でしかログが消去されません。スプレッドシート更新を頻繁に行う場合は、ログを手動で定期的に削除することを検討してください。
スプレッドシート・ロギングが使用可能になっている場合は、シャットダウン後にデータベースを起動すると、Essbaseによって次のメッセージがデータベース・ログに書き込まれます:
Starting Spreadsheet Log
volumename\app\
appname
\
dbname
\
dbname
.atx for database
dbname
Starting Spreadsheet Log Hyperion\products\Essbase\EssbaseServer\app\app1\sample\sample.atx for database Sample
スプレッドシート更新ロギングが正常に記録されるようにするため、アプリケーションを停止して再起動を行う前に、次のいずれかの処理を実行するようにしてください:
再構築が実行される任意の操作。データベースの再構築の最適化。を参照してください。
CREATEAPP
CREATEDB
COPYDB
RENAMEDB
Essbaseでは、スプレッドシート・ロギングを使用可能にすると、更新が実行された場合はその更新が必ず記録されます。なんらかの理由で、Essbaseで更新ログに書き込めない場合は、Essbaseによってトランザクションが停止され、エラー・メッセージが発行されます。
ハイブリッド分析によりリレーショナル・データベースを多次元データベースと統合できるため、下位レベルのメンバーとそれに関連付けられたデータはリレーショナル・データベース内に残し、上位レベルのメンバーとそれに関連付けられたデータをEssbaseデータベース内に置くことができます。このオプションによって、データの一貫性と整合性に関連した追加の問題が発生します。
データがすべての場所で正しいことを確認するための方法については、ハイブリッド分析でのデータの一貫性の管理を参照してください。