13 データベース増分管理戦略の策定
この章の内容は次のとおりです。
パージ・スクリプトおよびコンポーネント表のパーティション化によるデータベースの増分の管理の詳細は、「データベース増分の管理」を参照してください。
トラブルシューティングの詳細は、「パラレル・パージと表のパーティション化の問題」を参照してください。
ノート:
この章は、データベース管理者を対象としています。
データベース増分計画の概要
Oracle SOA Suite 12c のインストールでは、Oracle SOA Suiteデータベースの増分管理など、データベース管理者にかかわる課題がいくつか存在します。データベース管理の重要性を軽視すると、データベースが本番環境に移行したときに問題が発生する可能性があります。この章は、適切な戦略の決定に役立つもので、また、キャパシティ・プランニング、テストおよび監視の必要性に重点を置いています。
推奨される戦略は、Oracle SOA Suiteインストールのプロファイルまたは予測サイズを基準にします。戦略を実装するツールおよび技術はわかりやすく、推奨事項の単純化に役立ちます。ただし、これは設計どおりに実装しなければならない特定のツール・セットを使用するように管理者を制限するものではありません。
増分管理戦略の効率性およびリソース要件の決定には、テストと監視が必要です。テストにより、ツール、データベースおよびハードウェア・リソースのすべてをまとめて、現在および将来のデータベース増分予測のニーズに合致することが保証されます。
データベースのプロファイルまたはサイズの確認
ここでは、Oracle SOA Suiteデータベースのプロファイルまたはサイズを確認して、最適な増分管理戦略を決定する戦略を説明します。詳細は、「増分管理の課題およびテスト戦略の理解」を参照してください。
ディスク領域使用量の概算のためにこの項で詳述する計算は、全体的な領域キャパシティ・プランニングの実施に置き換わるものではありません。ただし、この推定は適切な増分管理戦略の結論の導出には十分ですが、ディスクキャパシティ・プランニングの必要性も重要事項です。
ノート:
この項の領域計算の説明の詳細では、「領域使用量、ハードウェア・リソース、およびデータベース・パフォーマンスの監視」を頻繁に参照します。
表13-1は、毎日永続的に使用されるコンポジット領域および最小保持領域に基づいて、小規模、中規模および大規模なインストールのプロファイルを示しています。保存ポリシーで数日間以上データを保持できなくてもインスタンスのインフローが高くなることがあるため、これら2つのメトリックは、and/or条件に関連します。
表13-1 Oracle SOA Suiteのデータベース・プロファイル
データベース・プロファイル | 毎日永続するコンポジット領域 | 最小保持領域 |
---|---|---|
小 |
< 10 GB |
< 100 GB |
中 |
10-30 GB |
100-300 GB |
大 |
> 30 GB |
> 300 GB |
データのインフローの確認
コンポジット・インフローおよび領域使用量の比率は、長期間の負荷テスト後に導出される平均として最適であると理解されます。これによって、割り当てられた領域(セグメントのエクステント)の利用を改善できます。インフローを把握するため、次のデータ・ポイントが調査されます。
毎日生成されるインスタンス数の確認
次の計算式を使用して、毎日生成されるインスタンス数を確認します。
Daily-inflow-composite = (Instance Total / Period)
たとえば、合計コンポジット件数100,000で5日間の負荷テストを行い、それに基づいて生成されるインスタンスの平均数を計算します。
(20,000 = (100,000 / 5))
詳細は、「コンポーネントの増加傾向の判定」を参照してください。
各インスタンスが使用するディスク領域の確認
次の計算式を使用して、各インスタンスが使用するディスク領域を確認します。
Inflow-space-per-instance = (SOA Schema Size /Instance Total)
たとえば、合計コンポジット数100,000、およびOracle SOA Suiteスキーマ・サイズ約200GBで、各インスタンスが使用する平均ディスク領域を計算します。
(2MB = (200 GB / 100,000))
詳細は、「スキーマの増加傾向の判定」を参照してください。
毎日永続的に使用されるコンポジット領域の確認
次の計算式を使用して、毎日永続的に使用されるコンポジット領域を確認します。
Daily-inflow-composite-space = (Daily-inflow-composite * Inflow-space-per-composite)
たとえば、それぞれが2MBの20,000個のコンポジットで、毎日コンポジットが使用する平均ディスク領域を計算します。
(40 GB = (20,000 * 2 MB))
別の方法の例を示します。
Daily-inflow-composite-space = (SOA Schema Size / Period)
Oracle SOA Suiteセグメントの領域配分の分析
Oracle SOA Suiteのスキーマの形状を分析して、セグメント領域(表、索引およびラージ・オブジェクト(LOB))の配分を把握し、問題となる可能性がるセグメントを特定できるようにします。
-
コンポジットの増加傾向を判定します。詳細は、「コンポーネントの増加傾向の判定」を参照してください。
-
日次の負荷テスト後にコンポーネントの統計を収集して、平均増分を判定できるようにします。
-
-
Oracle SOA Suiteスキーマの増加傾向を判定します。詳細は、「スキーマの増加傾向の判定」を参照してください。
-
日次の負荷テスト後にスキーマ・サイジングの統計を収集して、平均増分を判定できるようにします。
-
-
最大セグメントを判別します。詳細は、「最大セグメントの判別」を参照してください。
-
表と索引の増加傾向を判定します。詳細は、「表と索引の増加傾向の判定」を参照してください。
-
表および索引の増加統計は、自動ワークロード・リポジトリ(AWR)によって自動的に収集されます。
-
詳細は、「コンポーネントの増加傾向の判定」を参照してください。
保存ポリシーの策定
コンポジットをデータベース内に保存する期間を検討する必要があります。これはOracle SOA Suiteのスキーマおよびパージ・スクリプトのパフォーマンスに影響します。保存ポリシーに影響するファクタ次のとおりです。
-
法律的な要件
-
ライン・オブ・ビジネスの要件
-
データの保存に関する全般的な会社のポリシー
保存ポリシーが長くなるほど、格納する必要があるデータの量が増加し、それに応じて必要なディスク容量も多くなります。
最小保存ディスク領域の決定
次の計算式を使用して、最小保存ディスク領域を確認します。Daily-inflow-composite-space
の詳細は、「毎日永続的に使用されるコンポジット領域の確認」を参照してください。
Min-space-retain = Daily-inflow-composite-space * Retention Period in days
たとえば、毎日永続的に使用されるコンポジット領域40GB、保存期間10日間で最小保存ディスク領域を計算します。
(400 GB = (40 GB * 10))
最小保存コンポジット数の判定
次の計算式を使用して、最小保存コンポジット数を確認します。Daily-inflow-composite
確認の詳細は、「毎日生成されるインスタンス数の確認」を参照してください。
Min-composites-retain = Daily-inflow-composite * Retention Period in days
たとえば、毎日作成されるコンポジット数20,000、および保存期間10日間で最小保存コンポジット数を計算します。
(200,000 = (20,000 * 10))
これにより、10日間の保存ポリシーに基づいて、200,000個のコンポジットが平均400GBのデータを保存すると述べることができます。
ノート:
前述の計算により、最小ディスク領域使用量の概算が定義されます。実際の最小ディスク領域使用量は、品質保証テストによってより正確に判定されます。詳細は、「品質保証テスト」を参照してください。
データのアウトフローの確認
コンポジットのアウトフローは、削除されたインスタンス数の測定です。これはデータベース・プロファイルの決定時のファクタではありませんが、増分管理戦略の効率の評価時に重要なメトリックです。
アウトフロー測定の目標は、次の事項を確認することです。
-
インフローが削除可能であること。
-
できれば、領域使用量の安定状態が最小保存ディスク領域使用量を少し上回るものであること。
詳細は、「最小保存ディスク領域の決定」を参照してください。
次の2つのサイクルを最初に定義する必要があります。
-
パージ・サイクル: パージ・スクリプトの複数回の実行が必要になる可能性がある期間を指します。
-
メンテナンス・サイクル: すべての領域管理操作の実行が必要な日数を指します。詳細は、「データファイルのコンポーネントの概要」を参照してください。
適切な増分管理戦略には、パージとパーティション化の両方が含まれる場合があります。したがって、アウトフローは適切なパーティションが削除されるまで測定できません。パーティションの削除はメンテナンス操作です。このため、メンテナンス・サイクルが終了するまではアウトフローを測定しても有意義ではありません。
メンテナンス・サイクルの前後に次のメトリックを取得することで、戦略の効率性を把握し、領域配分を再評価できます。
-
コンポジットの増加傾向を判定します。詳細は、「コンポーネントの増加傾向の判定」を参照してください。
-
Oracle SOA Suiteスキーマの増加傾向を判定します。詳細は、「スキーマの増加傾向の判定」を参照してください。
-
最大セグメントを判別します。詳細は、「最大セグメントの判別」を参照してください。
-
表と索引の増加傾向を判定します。詳細は、「表と索引の増加傾向の判定」を参照してください。
ノート:
安定状態に達している場合、コンポーネントおよびスキーマの増分に関するメトリックの前後の差はゼロに近い数値またはマイナスになります。それ以外の場合は、パージ戦略で対処できていないか、データのインフローが増加している可能性があります。
長期間実行されるコンポジットおよび表のパーティション化の確認
長期間実行されるコンポジットは、保存期間より長期にわたってオープンしているコンポジットです。これらのコンポジットはパージ・スクリプトに大きく関係しませんが、表のパーティション化の実装時に影響が感知されます。(「増分管理の課題およびテスト戦略の理解」では、中規模および大規模のインストールでは表のパーティション化を検討するようにお薦めしています。)
パーティション化された表は、その領域がデータベースのALTER
TABLE
...
DROP
PARTITION
コマンドによって再利用されるため、パージ・スクリプトの対象から除外されます(また、除外する必要があります)。長期間実行されるコンポジットは、必要とされる保存期間を超えてオープンした状態で保持されるため、パーティションの削除は行われず、領域の再利用は行われません。したがって、パーティション化された表のサイズを推定する際は、使用される保存期間を実行期間が最長のコンポジットと同じにする必要があります。
Retention period = Longest Running Composite
「増分管理の課題およびテスト戦略の理解」で説明しているように、長時間実行されているトランザクションの領域影響やパーティション表のサイズは、品質保証テストを行うと最も正確に理解できます。ただし、パーティション化された各表で使用される領域を推定する場合は、次の各項の計算を使用してください。
パーティション化する各表に対する推奨事項
数日以上の期間にわたって表に負荷をかけて合理的な平均を生成する方法が最も適しています。表13-2に詳細を示します。
表13-2 表のパーティション化の推奨事項
アクション | コマンド |
---|---|
各表で毎日生成される平均の行数を判定します。 |
(Total rows / period) |
最も長く実行されるコンポジットに基づいて、行数を推定します。 |
((Total rows / period) * Longest running composite in days) |
行の計算に基づいて表と索引の領域使用量を推定します。 |
「表サイズの推定」および「索引サイズの推定」を参照してください。 |
ノート:
Oracle SOA Suiteリリース11g R1 (11.1.1.6)では、行移行と呼ばれるスクリプトのセットが提供されていました。これらのスクリプトは、パーティション間で長期間実行されるコンポジットを移動し、これによってパーティションの削除を容易にします。ただし、ベスト・プラクティスはパーティション表の領域所要量を計画することであり、行移行スクリプトに依存することではありません。
領域使用量、ハードウェア・リソース、およびデータベース・パフォーマンスの監視
次の各項では、領域使用量の監視方法について説明します。
次の各項では、ハードウェア・リソースとデータベース・パフォーマンスの監視方法を説明します。
領域の使用量の監視
領域の監視は、データベース管理者およびシステム管理者にとって計画外停止を回避するための重要な作業です。ここでは、キャパシティ・プランニングおよび増分管理戦略の効率性の判定に役立つアドバイスを提供します。監視およびキャパシティ・プランニングのあらゆる側面の包括的なガイドを提供するものではありません。
コンポーネントの増加傾向の判定
コンポーネントのマスター表には、各行の作成日付が記録され、特定期間の増加傾向の判定に使用されます。
-
SCA_FLOW_INSTANCE: CREATED_TIME
-
CUBE_INSTANCE
:CREATION_DATE
ただし、コンポーネントのマスター表への問合せは、定期的なパージによってデータが削除されるために制限され、傾向の予測を困難にします。特定期間全体の傾向を判定するには、関連付けられたタイムスタンプとともにデータを定期的に収集する必要があります。これは、毎日移入される単純なコンポーネント履歴表によって実現できます。増分管理戦略の効率性および増加傾向の判定にはこの表で十分になります。
-
パフォーマンス上の理由により、次の例に示すように履歴表をコンポーネント別に作成することが最適である可能性があります。
SQL> CREATE TABLE SOA_FABRIC_HIST (SFH_DATE TIMESTAMP, SFH_COUNT NUMBER); SQL> INSERT INTO SOA_FABRIC_HIST SELECT SYSTIMESTAMP, COUNT(*) FROM SCA_FLOW_INSTANCE GROUP BY SYSTIMESTAMP; SQL> CREATE TABLE SOA_BPEL_HIST (SBH_DATE TIMESTAMP, SBH_COUNT NUMBER); SQL> INSERT INTO SOA_BPEL_HIST SELECT SYSTIMESTAMP, COUNT(*) FROM CUBE_INSTANCE GROUP BY SYSTIMESTAMP;
このようになります。
-
表の分析であれば、各コンポーネント表での行数のカウントの代替方法として、
USER_TABLES
からNUM_ROWS
列を問い合せます。
Oracle SOA Suiteスキーマの増加傾向の判定
Oracle SOA Suiteスキーマに作成されるオブジェクト(表、索引およびLOB)は、多様な表領域に拡散している場合がありますが、領域使用量をグループ化するためすべて同じ所有者(*soainfra
)になります。各コンポジットの領域所要量を判定する際は、索引とLOBセグメントが反映されるため、スキーマ全体を測定することで優れた領域メトリックを取得できます。
単純な履歴表に毎日移入することで、Oracle SOA Suiteスキーマの増加を監視できます。領域管理の効率性の判定にはこの表で十分になります。詳細は、「領域管理の理解」を参照してください。
-
次の例で示すように、オブジェクト・タイプに基づきスキーマの増分表を作成します。
SQL> CREATE TABLE SOA_SIZE_SCHEMA_HIST (SSCH_DATE TIMESTAMP, SSCH_SUM_MB NUMBER); SQL> INSERT INTO SOA_SIZE_SCHEMA_HIST SELECT SYSTIMESTAMP, SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE OWNER='<SOA_OWNER>' GROUP BY SYSTIMESTAMP;
-
最大セグメントと結合してパーティション化や不足領域管理が必要な表を確認する際は、必要に応じて、オブジェクト・タイプ別(表、索引、LOBなど)の履歴表を作成すると便利です。次の例は、履歴表を作成します。
SQL> CREATE TABLE SOA_SIZE_TYPE_HIST (SSCH_DATE TIMESTAMP, SSCH_TYPE VARCHAR2(18), SSCH_SUM_MB NUMBER); SQL> INSERT INTO SOA_SIZE_TYPE_HIST SELECT SYSTIMESTAMP, SEGMENT_TYPE, SUM(BYTES)/1024/1024 FROM DBA_SEGMENTS WHERE OWNER='SOA_OWNER' GROUP BY SYSTIMESTAMP, SEGMENT_TYPE;
最大セグメントの判別
スキーマ内でどのセグメントが最大であるかを把握することは、レンジ・パーティション化された表として管理することが適している表の判別に役立ちます。さらに、最大セグメントを監視することで、不足している領域管理操作や不適切な監査設定を発見できる可能性もあります。
-
次の例に示すように、Oracle SOA Suiteスキーマの最大から20個までのセグメントを特定します。
SQL> SELECT SEGMENT_NAME, SEGMENT_TYPE, (SUM(BYTES)/1024/1024) MB_SIZE FROM DBA_SEGMENTS WHERE OWNER='SOA_OWNER' AND ROWNUM < 20 GROUP BY SEGMENT_NAME, SEGMENT_TYPE ORDER BY 3 DESC;
-
次の例に示すように、最大セグメントはLOBセグメントである可能性があります。
SQL> SELECT L.TABLE_NAME, S.SEGMENT_NAME, (SUM(BYTES)/1024/1024) MB_SIZE FROM DBA_LOBS L, DBA_SEGMENTS S WHERE S.OWNER='<SOA_OWNER>' AND S.SEGMENT_TYPE = 'LOBSEGMENT' AND S.SEGMENT_NAME = L.SEGMENT_NAME AND S.OWNER='SOA_OWNER'' GROUP BY L.TABLE_NAME, S.SEGMENT_NAME;
または
SQL> SELECT L.TABLE_NAME FROM DBA_LOBS L WHERE L.OWNER ='<SOA_OWNER>' AND L.SEGMENT_NAME = ‘SEGMENT_NAME';
-
個別のセグメントのサイズを判定するには:
SQL> SELECT SEGMENT_NAME, (SUM(BYTES)/1024/1024) MB_SIZE FROM DBA_SEGMENTS WHERE OWNER='SOA_OWNER' AND SEGMENT_NAME = ‘TABLE_NAME' GROUP BY SEGMENT_ NAME;
表と索引の増加傾向の判定
DBMS_SPACE
パッケージのOBJECT_GROWTH_TREND
関数を使用して、表の領域増加傾向を示します。詳細は、Oracle Database管理者ガイドを参照してください。
DBMS_SPACE
パッケージ・プロシージャのOBJECT_GROWTH_TREND
関数では、特定の時点におけるオブジェクトの領域使用が各行に記述された1行以上の表が作成されます。この関数は、AWRから領域合計を取得するか、現在の領域を計算して、AWRから取得した領域の変化履歴と結合します。
次の例は、SCA_FLOW_INSTANCE
表の使用済および割当て済領域の時間経過による増加を示しています。
SQL> SELECT TIMEPOINT, SPACE_USAGE, SPACE_ALLOC, QUALITY FROM TABLE (DBMS_ SPACE.OBJECT_GROWTH_TREND ('DEV_SOAINFRA','SCA_FLOW_INSTANCE','TABLE'));
次の例は、dbms_space.object_growth_trend
プロシージャの完全な構文を示します。
dbms_space.object_growth_trend ( object_owner in varchar2, object_name in varchar2, object_type in varchar2, partition_name in varchar2 default null, start_time in timestamp default null, end_time in timestamp default null, interval in dsinterval_unconstrained default null, skip_interpolated in varchar2 default 'false', timeout_seconds in number default null, single_datapoint_flag in varchar2 default 'true')
表13-3は、object_growth_trend
関数のパラメータの説明です。
表13-3 OBJECT_GROWTH_TRENDファンクションのパラメータ
パラメータ | 説明 |
---|---|
|
オブジェクトを含むスキーマ。 |
|
オブジェクトの名前。 |
|
オブジェクトのタイプ。 |
|
関連する場合は、表または索引パーティションの名前。それ以外の場合は、 |
|
増加傾向分析の開始を示すタイムスタンプ値。 |
|
増加傾向分析の終了を示すタイムスタンプ値。デフォルトは |
|
間隔であるか(yes)、そうでないか(no)。この設定は、結果表がグラフではなく表として表示される場合に便利です。これは、実際の記録間隔が要求されたレポート間隔とどのように関連しているかをより明確に確認できるためです。この関数は、行ごとに1つの間隔のオブジェクトの領域使用情報が表示された表を返します。返される表が非常に大きい場合は、情報が作成されると同時に別のアプリケーションが使用できるように結果がパイプライン化されます。 |
|
欠落値の補間をスキップするかどうかを指定します( |
|
関数のタイムアウト値(秒)。 |
|
統計がないときにセグメントをサンプリングするかどうかを指定します。 |
返される値を次の例で示します。
TYPE object_growth_trend_row IS RECORD( timepoint timestamp, space_usage number, space_alloc number, quality varchar(20));
表13-4は、object_growth_trend_row
の戻り値の説明です。
表13-4 OBJECT_GROWTH_TREND_ROWの戻り値
パラメータ | 説明 |
---|---|
|
レポート間隔の時間を示すタイムスタンプ値。最も古いオブジェクトの記録統計よりも前の |
|
オブジェクト・データとして実際に使用されているバイト数。 |
|
その時点で表領域のオブジェクトに割り当てられていたバイト数。 |
|
要求されたレポート間隔と実際の統計記録が一致している程度を示す値。オブジェクト・サイズ使用統計には保証されているレポート間隔はなく、実際のレポート間隔は時間の経過およびオブジェクトによって変わるため、この情報が役立ちます。
|
表サイズの推定
dbms_space
パッケージのcreate_table_cost
プロシージャを使用すると、既存の表の予想行数を使用するか、表の列定義に基づいて表のサイズを推定できます。表のサイズは、このプロシージャからの表領域の記憶域属性に従って大きく異なる場合があります。このプロシージャには、次の2つのオーバーロードがあります。
-
最初のプロシージャは、表の列情報を取得します。
-
2番目のプロシージャは、表の平均行サイズを取得します。
Oracle SOA Suiteの表は既存のため、2番目のバリアントが最も有益です。次の例は、10000行があり、行の長さの平均が360で、PCT
FREE
が10の表CUBE_INSTANCE
のサイズを推定しています。
-
次のコマンドを実行します。行の長さの平均と現在の
PCT_FREE
は、表が分析されていることが確認された後にDBA_TABLES
から導出されます。SQL> SELECT AVG_ROW_LEN, PCT_FREE FROM DBA_TABLES WHERE TABLE_NAME = 'CUBE_INSTANCE' AND OWNER = 'DEV_SOAINFRA';
-
dbms_space.create_table_cost
プロシージャを実行します。set serverout on declare v_used number(10); v_alloc number(10); begindbms_space.create_table_cost ('SOA1_SOAINFRA',360,10000,10, v_used,v_Alloc); dbms_output.put_line('used bytes: ' || to_char(v_used)); dbms_output.put_line('allocated bytes: ' || to_char(v_alloc)); end; /
次の例は、列定義に基づいて表の領域使用量を推定しています。
set serveroutput on declare v_used_bytes number(10); v_allocated_bytes number(10); v_type sys.create_table_cost_columns; begin v_type := sys.create_table_cost_columns ( sys.create_table_cost_colinfo('number',9), sys.create_table_cost_colinfo('varchar2',50), sys.create_table_cost_colinfo('varchar2',15), sys.create_table_cost_colinfo('date'f,null), sys.create_table_cost_colinfo('date'f,null) ); dbms_space.create_table_cost ('users',v_type,10000,7,v_used_bytes,v_allocated_bytes); dbms_output.put_line('used bytes: ' || to_char(v_used_bytes)); dbms_output.put_line('allocated bytes: ' || to_char(v_allocated_bytes)); end; /
dbms_space
.create_table_cost
プロシージャの完全な構文を次の例で示します。
-
最初のオーバーロード:
dbms_space.create_table_cost (tablespace_name in varchar2, colinfos in create_table_cost_columns, row_count in number, pct_free in number, used_bytes out number, alloc_bytes out number); create type create_table_cost_colinfo is object (col_type varchar(200), col_size number);
-
2番目のオーバーロード:
dbms_space.create_table_cost (tablespace_name in varchar2, avg_row_size in number, row_count in number, pct_free in number, used_bytes out number, alloc_bytes out number);
いずれのバリアントでも、表13-5および表13-6に示された入力が必要です。
表13-5 CREATE_TABLE_COSTプロシージャのパラメータ
パラメータ | 説明 |
---|---|
|
オブジェクトが作成される表領域。デフォルトは |
|
表の予測行数。 |
|
更新の結果、既存の行を将来拡張するために各ブロックで確保される空き領域の割合(パーセンテージ)。 さらに、最初のバリアントには、入力値として また、2番目のバリアントは、予想された各列値を |
表13-6 CREATE_TABLE_COSTプロシージャの戻り値
パラメータ | 説明 |
---|---|
|
ブロック・メタデータ、 |
|
表領域のエクステントの特性を考慮してオブジェクトに割り当てられる予測領域量。 |
索引サイズの推定
dbms_space
パッケージのcreate_index_cost
プロシージャを使用すると、既存の表での索引作成の領域使用コストを推定できます。これを使用して、Oracle SOA Suiteスキーマに索引を追加する際のコストを判定します。
次の例は、データ定義言語(DDL)に基づいて新しい索引のサイズを推定します。
set serveroutput on declare v_used_bytes number(10); v_allocated_bytes number(10); begin dbms_space.create_index_cost( ‘create index cube_index on cube_instance(cikey)' v_used_bytes, v_allocated_bytes); dbms_output.put_line(‘used bytes: ‘ || to_char(v_used_bytes)); dbms_output.put_line(‘allocated bytes: ‘|| to_char(v_allocated_bytes));end; /
DBMS_SPACE.CREATE_INDEX_COST
プロシージャの完全な構文は次のとおりです。
dbms_space.create_index_cost (ddl in varchar2, used_bytes out number, alloc_bytes out number, plan_table in varchar2 default null);
このプロシージャには、表13-7に示された入力値が必要です。
表13-7 DBMS_SPACE.CREATE_INDEX_COSTの値
パラメータ | 説明 |
---|---|
|
索引を作成する |
|
(オプション)使用する計画表の名前。デフォルトは
|
使用上のノート:
-
索引が作成される表は、すでに存在している必要があります。
-
索引サイズの計算は、セグメント上で集められた統計情報に依存します。
-
表は分析直後である必要があります。
-
正しい統計がないと、結果が不正確になる可能性があります。
未使用索引の監視
Oracleデータベースには、索引を監視して使用されているかどうかを判定する手段が用意されています。索引が使用されていない場合は、それを削除して不要な文によるオーバーヘッドを解消できます。
-
索引使用の監視を開始するには次の文を入力します。
SQL> ALTER INDEX INDEX_NAME MONITORING USAGE;
-
監視を停止するには次の文を入力します。
SQL> ALTER INDEX INDEX_NAME NOMONITORING USAGE;
監視対象の索引について、その索引が使用されているかどうかを確認するには、ビューV$OBJECT_USAGE
を問い合せます。このビューにはUSED
列があり、監視期間中に索引が使用されたかどうかによってYES
またはNO
の値を持ちます。また、このビューには監視の開始時間と停止時間も記録され、MONITORING
列(YES
/NO
)には使用状況の監視が現在アクティブであるかどうかが示されます。MONITORING
USAGE
を指定するたびに、指定された索引のV$OBJECT_USAGE
ビューはリセットされます。前回の使用方法の情報はクリアまたはリセットされ、新しい開始時間が記録されます。NOMONITORING
USAGE
を指定すると、それ以降の監視は実行されず、監視期間の終了時間が記録されます。次にALTER INDEX...MONITORING
USAGE
文が発行されるまで、ビューの情報は変更されずに保持されます。
ハードウェア・リソースおよびデータベースの監視
ハードウェア・リソースは増分戦略の実装に選択されたツールをサポートする必要があります。オンライン・トランザクション処理(OLTP)およびメンテナンス期間、特にこれらの期間が重複する際にハードウェア・リソースを監視することが重要です。
ハードウェア- OSWatcher Black Box
CPU、ディスク、メモリーおよびネットワークO/Sリソースを監視するため、オラクル社はOSWatcher Black Boxを提供しており、これをOracle SOA Suiteインストールのすべてのレイヤーにインストールする必要があります。
OSWatcher Black Boxは、オペレーティング・システムおよびネットワークのメトリックを収集およびアーカイブして、Oracleサポート・サービスでのパフォーマンスに関連する問題の診断を支援するUNIXシェル・スクリプトのコレクションです。OSWatcher Black Boxは、サーバー上のバックグラウンド・プロセスのセットとして動作し、vmstat
、netstat
、iostat
などのUNIXユーティリティを起動して定期的にOSデータを収集します。
OSWatcher Black Boxユーザー・ガイドおよび製品は、Metalinkサポート・ノート301137.1からダウンロードできます。
https://support.oracle.com
データベース – AWR / ADDM
オラクル社は、データベース・パフォーマンス統計の収集および分析のための、AWRおよび自動データベース診断モニター(ADDM)を用意しています。
AWRは、パフォーマンス統計のスナップショットを定期的に自動収集する構成も、手動でトリガーする構成も可能です。その後ADDMユーティリティで、2つのスナップショット間隔間の統計を分析し、以下が含まれるパフォーマンス・サマリー・レポートを作成できます。
-
CPUのボトルネック
-
サイズ設定が小さすぎるメモリー構造
-
I/O容量の問題
-
高負荷のSQL文
-
高負荷のPL/SQL実行およびコンパイルの問題、および高負荷のJavaの使用
-
Oracle Real Application Clusters固有の問題
-
アプリケーションによるOracleデータベースの非効率的な使用
-
データベース構成の問題
-
同時実行の問題
-
ホット・オブジェクト
AWRおよびADDMユーティリティは手動で、またはOracle Enterprise Manager Database Controlから実行できます。詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。
ディスクI/O-Oracle Orion
完全なOracle SOA SuiteのI/O設計は、この章の範囲に含まれていません。ただし、『Oracle Databaseパフォーマンス・チューニング・ガイド』には、適切なアドバイスが記載されています。適切に計画されているI/O計画では、容量、可用性およびパフォーマンスが考慮されます。
AWRレポートは、アクセス頻度の高いセグメント、データファイルおよび表領域を特定します。OSWatcherは、長時間かかるI/Oキューを特定します。これらのツールを組み合せることによって、問題のあるディスク・デバイスおよびファイルが特定されます。これによって、I/Oの均衡化、または低速ボリューム上のRedundant Arrays of Independent Disks (RAID)の変更のためのファイルの再分散の必要性を識別できる可能性があります。
OracleデータベースのI/O調整機能 (Oracle Orion)は、記憶域メディアへのアクセスにOracleデータファイルを使用して、ランダムI/Oを発行します。これにより、データベースの実際のパフォーマンスにほとんど一致する結果が生成されます。Oracle Orionは特に、Oracleと同じI/Oソフトウェア・スタックを使用してOracleデータベースのI/Oワークロードをシミュレートするように設計されています。Oracle Orionは、Oracle Automatic Storage Managementによって実行されるストライプ化の影響をシミュレートすることもできます。
増分管理の課題およびテスト戦略について
ここでは、Oracle SOA Suiteデータベースの増分管理に適したツールに関する推奨事項を説明しています。提示されるアドバイスは、新規インストール、または現在の戦略に監視や領域管理が不足している既存のインストールに向けたものです。その他の推奨事項は、「パラレル・パージと表のパーティション化の問題」を参照してください。
領域使用量、ハードウェア・リソース、およびデータベース・パフォーマンスの監視を参照して、データベース増分の管理で説明するOracle SOA Suiteのパージおよびパーティション化ツールについて十分に理解しておくことをお薦めします。
データベース増分管理の課題
ここで説明する課題は、推奨される戦略に関係する状況を説明することによって背景知識を提供します。
非効率的な増分管理戦略によるOracle SOA Suiteの表の過度の増大化
非効率的なパージ戦略が実装されていると、Oracle SOA Suiteの表が非常に大きく増大する場合があります。これによって、緊急に領域再利用の必要が発生することになります。表が大きいほど、行の削除や領域の再利用が困難になります。
パラレル・パージ・スクリプトのパフォーマンスは、CPUリソース、ディスクI/Oの速度などのファクタに依存します。ただし、非常に大きな表は問題であることが判明しています。この問題は、削除可能なコンポジットを決定するために解析が必要になるデータ量が原因で生じます。この解析は、パージ・スクリプト全体の経過時間を独占的に使用する場合があります。詳細は、「パラレル問合せスレーブの使用」を参照してください。
この状況は、増分管理戦略の効率性の監視が常に必要であること、および表が非常に大きくなる前に可能なかぎり速やかに対応措置をとる必要があることを強調するものです。
インフローを処理できない調整済のパラレル・パージ・スクリプト
パラレル・パージ・スクリプトのパフォーマンスを向上させるため、経過時間の長い表はレンジ・パーティション化してスクリプトから除外できます。ただし、表のパーティション化が本番環境で必要な場合は、これによって停止時間の問題が生じます。表は再定義パッケージによってオンラインでパーティション化できますが、非常に大きい表で発生した場合は、この操作が合理的な時間内に完了しない場合があります。Oracle SOA Suiteリリース11g R1 (11.1.1.6)以降は、パーティション化が可能な表の粒度が改善されています。マスター表のみで高ボリュームの表のパーティション化を実行できます。これによってパーティション化の注目度が上がり、実現性も高くなります。
長時間実行されるコンポジットが原因で削除できない表パーティション
長期間実行されるコンポジットは、保存期間より長期にわたってオープンしているコンポジットです。含まれるすべてのコンポジットが完了されるまでは削除できないため、これはOracle SOA Suite の表パーティションに影響を及ぼします。1つのフロー・インスタンスであっても、パーティションの削除および領域の再利用ができなくなる可能性があります。この状況からOracle SOA Suite リリース11g R1 (11.1.1.6)で導入された行移行スクリプトが生まれました。
最も長時間実行されるコンポジットの保存期間を含め、パーティション化された表を収容するために十分なディスク領域を計画します。領域の再利用が緊急に必要な場合は、修正処理として行の移行スクリプトをお薦めします。
行移行スクリプトによるコンポジット・データの移動によって、次の問題が発生します。
-
このスクリプトは、スクリプトによるパフォーマンスの問題を回避するためパーティション内のデータの約5%が移動されると想定して作成されています。
-
同一レベルのパーティション化の要件を維持するには、多数の表の行の5%の移動が必要です。同一レベル・パーティション化の詳細は、「参照整合性および同一レベル・パーティション化」を参照してください。
-
5%の任意数は、パーティションのサイズを意味するものではなく、インフロー率およびパーティションの期間(日次、週次および月次)に依存します。
-
-
最新のパーティション、またはアクティブ・コンポジットのプール専用として作成されたパーティションに実行時間の長いコンポジットの移行を繰り返すと、累積が発生することがあります。
-
特定のパーティションが非常に増大して、別の影響が生じるパージが必要になります。詳細は、「パーティション・プルーニング」を参照してください。
-
品質保証テスト
ツールおよび技術の習熟および理解を保証するには増分管理戦略のテストが非常に重要です。品質保証テストに使用可能なハードウェア・リソースは本番環境と同じであることはほとんどありません。したがって、管理者が本番稼働ホストに結果を反映する際は慎重に予測する必要があります。
次の項目について説明します。
Metalinkサポート・ノート1384379.1の確認
サポート・ノートDoc ID 358.1 メンテナンスおよび管理アドバイザ: Oracle Fusion Middleware (FMW) SOA 11gインフラストラクチャのデータベースを確認します。
https://support.oracle.com
Oracle SOA Suiteスキーマの作成 - テスト環境
本番環境と比較可能なテスト環境を作成することは困難ですが重要です。パージ・スクリプトのパフォーマンスは、解析が必要なデータの量によっては悪影響を受ける場合があります。したがって、パージのパフォーマンスを把握するにはサイジングが適切なテスト環境が重要です。詳細は、「パラレル問合せスレーブの使用」を参照してください。
スキーマに移入される混在ワークロードは、ペイロード・サイズとコンポジット起動数が本番環境と類似している必要があります。データは、何日分もの負荷をシミュレートして、領域平均と推計サイズの判定を向上させる必要があります。
インフローおよび推定領域の測定
データの負荷時は、表別の使用領域および各領域の配分の判定に時間をかけてください。インフローの計算の詳細は、「データのインフローの確認」を参照してください。
-
コンポジットの増加傾向を判定します。詳細は、「コンポーネントの増加傾向の判定」を参照してください。
-
Oracle SOA Suiteスキーマの増加傾向を判定します。詳細は、「スキーマの増加傾向の判定」を参照してください。
パーティション化を念頭に置いてメトリックを収集します。
-
最大セグメントを判別します。詳細は、「最大セグメントの判別」を参照してください。
-
表と索引の増加傾向を判定します。詳細は、「表と索引の増加傾向の判定」を参照してください。
-
表のサイズを推定します。詳細は、「表サイズの推定」を参照してください。
-
索引のサイズを推定します。詳細は、「索引サイズの推定」を参照してください。
パラレルまたはシングル・スレッド・スクリプトの実行および領域の再利用
次の2つのサイクルをまず理解しておく必要があります。
-
パージ・サイクル: パージ・スクリプトの複数回の実行が必要になる可能性がある期間を指します。
-
メンテナンス・サイクル: すべての領域管理操作の実行が必要な日数を指します。詳細は、「データファイルのコンポーネントの概要」を参照してください。
目標は、パージ・スクリプトおよびメンテナンス・操作を実行して、パージに増大の余裕があることを保証してそれぞれに最適なサイクルを判定することです。パージ・スクリプトは、1日に複数回実行する必要がある場合があり、またメンテナンス操作は数日間にまたがる可能性があります。
後続の各項で領域の調整、監視、再利用の方法について説明します。
-
パラレル・パージ。詳細は、「パラレル・パージ・スクリプトの実行」を参照してください。
-
ハードウェアおよびデータベースの監視。詳細は、「ハードウェア・リソースおよびデータベースの監視」を参照してください。
-
領域管理操作。詳細は、「データファイルのコンポーネントの概要」を参照してください。
テスト結果の確認
目標は次のとおりです。
-
パージによって、インフローと同等またはそれ以上の領域の削除および再利用を実行できるかを判定します。詳細は、「保存ポリシーの策定」および「データのアウトフローの確認」を参照してください。
-
パージ要件に一致させるためにパージの実行が必要な回数およびパージ・サイクルの合計経過時間を判定します。このパージ・サイクルは、その実行に割り当てられた時間の80%以内で完了する必要があります。
-
ボトルネックの表を判別します。詳細は、「パージ操作のデバッグとトレース」を参照してください。
-
データベースおよびO/Sレポートでのリソース競合および待機を確認します。詳細は、「ハードウェア・リソースおよびデータベースの監視」を参照してください。
ボトルネックを発生する表のパーティション化
大規模インストールでは、パージが困難であると確認された表のパーティション化を検討する必要があります。これらの表は、最大の表でもある可能性があります。表のパーティション化は、一括データ削除として実証済の方法です。Oracle SOA Suiteスキーマは、レンジ・パーティション化を容易にするパーティション・キーを備えています。
Oracle SOA Suiteリリース11g R1 (11.1.1.6)以降は、パーティション化が可能な表の粒度が改善されました。マスター表のみで高ボリュームの表のパーティション化を実行できます。これによってパーティション化の注目度が上がり、実現性も高くなります。
-
部分的なパーティション化。
-
長時間実行されるコンポジット。詳細は、「長期間実行されるコンポジットおよび表のパーティション化の確認」を参照してください。
パージ・テストと確認の反復およびパーティション化された表の除外
「パラレルまたはシングル・スレッド・スクリプトの実行および領域の再利用」および「テスト結果の確認」で説明されているパージ・テストとテスト結果の確認を繰り返します。パーティション化された表は除外します。
推奨される増分管理戦略
次の推奨される増分管理戦略は、Oracle SOA Suiteデータベース・プロファイルを基準にしています。
戦略には、効率性を判定するためのテストが必要です。テストでは以下について確認する必要があります。
-
パージ・スクリプトに増大の余裕があること。
-
パーティション化された表に十分なディスク領域があること。
-
増大が監視されていること。
-
メンテナンス実行時のOLTPパフォーマンスへの影響が最小であること。
大規模データベース・プロファイルの推奨事項
大規模なデータベース・プロファイルのあるインストールでは、戦略の一環として表のパーティション化を真剣に検討する必要があります。表のレンジ・パーティション化は大型の表の実証済の管理方法です。
- レンジ時間隔パーティション化はレンジ・パーティション化の拡張で、データベースはパーティションを自動的に割り当てます。詳細は、「レンジ時間隔パーティション化」を参照してください。
- パーティション化された表を除いてパラレル・パージを実行します。詳細は、「dbms_schedulerを使用したパラレル・スクリプトでのループされるパージ」を参照してください。
- パージ・スクリプトを実行する際に、ボトルネックの原因となる表をパーティション化します。詳細は、「コンポーネント表のパーティション化」を参照してください。
- メンテナンス・サイクルの一環として、領域を再利用します。詳細は、「データファイルのコンポーネントの概要」を参照してください。
- メンテナンス・サイクルの一環として、適切なパーティションを削除します。詳細は、「検証スクリプトの実行」を参照してください。
- インフローおよびアウトフローを監視します。詳細は、「保存ポリシーの策定」および「データのアウトフローの確認」を参照してください。
- データベースおよびハードウェア・リソースを監視します。詳細は、「セグメントおよびデータファイル領域の再利用」を参照してください。
小規模データベース・プロファイルの推奨事項
CPU、メモリー、ディスク領域が限定的な小規模インストールでは、シングル・スレッド・パージから開始し、その後パラレル・パージに移ります。
-
シングル・スレッド・パージを実行します。詳細は、「ループされるパージ・スクリプト」を参照してください。
-
パラレル・パージを実行します。詳細は、「dbms_schedulerを使用したパラレル・スクリプトでのループされるパージ」を参照してください。
-
シングル・スレッド・パージを実行していない場合は、パラレル・パージをテストする必要があります。
-
-
インフローおよびアウトフローを監視します。詳細は、「保存ポリシーの策定」および「データのアウトフローの確認」を参照してください。
-
データベースおよびハードウェア・リソースを監視します。詳細は、「セグメントおよびデータファイル領域の再利用」を参照してください。
領域管理の理解
この項の情報の多くは、様々なOracle Database管理ガイドにも記載されています。ここに概要が記載された領域管理の概念およびコマンドは、Oracle SOA Suiteのパージ・スクリプトによる領域の再利用に関する誤解を解決します。領域を再利用するには、データベースのメンテナンス操作を実行する必要があります。
デフォルトでは、自動セグメント領域管理(ASSM)によってローカルで管理される表領域にOracle SOA Suiteスキーマが作成されます。したがって、アドバイスはすべてこの状況に限定しています。この項はすべてのデータベース領域管理機能の包括的なガイドを目指したものではありません。
データファイルのコンポーネントの概要
データファイルは、次のコンポーネントに分けることができます。
-
セグメント: 特定タイプのデータベース・オブジェクトが格納されます。つまり、表は表セグメントに格納され、索引は索引セグメントに格納されます。
-
エクステント: セグメント内のデータ・ブロックの連続したセットです。Oracleデータベースは、セグメントの領域を1つのエクステント単位に割り当てます。
-
データ・ブロック: データベース・ブロックとも呼ばれ、データベース記憶域のI/Oの最小単位です。エクステントは複数の連続するデータ・ブロックから構成されます。
-
表領域: 1つ以上の物理データ・ファイルで構成されます。ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域の割当てまたは解放時に、Oracleデータベースはビットマップ値を変更して、ブロックの新しいステータスを反映させます。
セグメント、エクステントおよびデータ・ブロックはすべて論理構造です。
図13-1は、論理記憶域と物理記憶域間の関係を示しています。
セグメント最高水位標
領域を管理するため、Oracleデータベースはセグメント内のブロックの状態を追跡します。最高水位標(HWM)は、セグメント内の位置を指し示し、その位置を超えると、データ・ブロックは未フォーマットであり、使用されていません。HWMと低いHWMとの間のブロックに空きがなくなると、HWMが右側に拡張されて、低いHWMも以前のHWMの場所まで拡張されます。図13-2に詳細を示します。データベースにデータが徐々に挿入されるにつれて、HWMは次第に右側へと拡張され、それに伴い、低いHWMもHWMに従って拡張されます。手動でオブジェクトを再構築、切捨て、縮小/割当て解除しないかぎり、HWMは再処理しません。
セグメントおよびデータファイル領域の再利用
次の各項は、セグメントおよびデータ・ファイル領域の再利用に使用される一般的な技術について説明しています。
オンラインのセグメント縮小の実行
パージ・スクリプトはデータベース・セグメント(表および索引)から行を削除し、データ・ブロック内の領域を解放して再利用できるようにしますが、一部の領域で小さすぎて再利用できない断片化も発生します。オンラインのセグメント縮小を実行することで、領域の断片化を解消でき、エクステントの再利用が可能になります。縮小操作によって、HWMを下回る空き領域を統合し、セグメントを圧縮できます。その後、HWMを移動してHWMを上回る領域を割当て解除します。
データ操作言語(DML)は、セグメント縮小のデータ移動フェーズでも発行できます。ただし、縮小操作の最後に領域が割当て解除される際は、短い時間ですがDML操作がブロックされます。索引は縮小操作中も維持され、使用可能な状態に保持されます。
セグメント・アドバイザは、オンラインのセグメント縮小を活用できるセグメントを識別できます。ただし、定期パージ後はOracle SOA Suiteセグメントの大半がオンラインの縮小操作の候補になります。セグメント・アドバイザの詳細は、『Oracle Database管理者ガイド』を参照してください。
一般的なオンラインのセグメント縮小ステップは次のとおりです。
-
縮小コマンドを実行する目に、行移動を有効化する必要があります。
SQL> ALTER TABLE TABLE_NAME ENABLE ROW MOVEMENT;
-
セグメントを縮小するには:
SQL> ALTER TABLE TABLE_NAME SHRINK SPACE;
-
COMPACT
句を指定すると、セグメントの縮小操作を2つのフェーズに分割できます。COMPACT
を指定すると、セグメント領域の断片化が解消され、行が圧縮されますが、HWMのリセットおよび領域の割当て解除は延期されます。大型の表では操作を2フェーズに分割すると便利で、割当て解除フェーズのDMLのブロックによる影響が減少します。オフピーク時に
COMPACT
句なしでSHRINK SPACEを再発行することで、第2フェーズを完了できます。SQL> ALTER TABLE TABLE_NAME SHRINK SPACE COMPACT;
-
CASCADE
句を指定すると、オブジェクトのすべての依存セグメントにセグメントの縮小操作が拡張されます。たとえば、表セグメントの縮小時にCASCADE
を指定すると、表のすべての索引も縮小されます。SQL> ALTER TABLE TABLE_NAME SHRINK SPACE COMPACT CASCADE;
-
非常に大型の表の場合は、縮小を2フェーズで実行し、
CASCADE
句を使用しないことをお薦めします。最初にCOMPACT
操作を実行すると、多くの場合はその前に基本LOBが圧縮されてから通常の縮小コマンドが実行され、未使用領域が再利用されます。 -
オンラインのセグメント縮小は、以下を除くすべてのセグメント・タイプで使用できます。
-
索引構成表(IOT)マッピング表
-
行IDベースのマテリアライズド・ビュー
-
ファンクション索引がある表
-
セキュアなファイルのLOB
-
圧縮表
-
表13-8は、オンラインのセグメント縮小の例を示しています。
表13-8 オンラインのセグメント縮小の例
シナリオ | 例 |
---|---|
大型の表を2フェーズで縮小します。 |
SQL> ALTER TABLE TABLE_NAME ENABLE ROW MOVEMENT; SQL> ALTER TABLE TABLE_NAME SHRINK SPACE COMPACT; SQL> ALTER TABLE TABLE_NAME SHRINK SPACE; |
表およびその依存セグメント( |
SQL> ALTER TABLE TABLE_NAME SHRINK SPACE CASCADE; |
|
SQL> ALTER TABLE TABLE_NAME MODIFY LOB (LOB_NAME) (SHRINK SPACE); |
パーティション化された表の単一パーティションを縮小します。 |
SQL> ALTER TABLE TABLE_NAME MODIFY PARTITION P1 SHRINK SPACE; |
未使用領域の割当て解除
DEALLOCATE
UNUSED
コマンドを使用すると、手動で未使用領域を割当て解除できます。このコマンドは、HWMを上回る未使用領域を解放します。オンラインのセグメント縮小でもHWMを上回る領域が解放されます。
SQL> ALTER TABLE TABLE_NAME DEALLOCATE;
オプションのKEEP
句を使用して、表、索引、またはクラスタのセグメントに保持する領域量を指定します。
SQL> ALTER TABLE TABLE_NAME DEALLOCATE UNUSED KEEP INTEGER; SQL> ALTER INDEX INDEX_NAME DEALLOCATE UNUSED KEEP INTEGER;
ノート:
DBMS_SPACE
パッケージのUNUSED_SPACE
プロシージャは、HWMの位置、およびセグメント内の未使用領域量に関する情報を返します。ASSMを使用してローカルで管理されるセグメントでは、SPACE_USAGE
プロシージャを使用して未使用領域に関するより精度の高い情報を取得します。(割当て解除された領域の確認にはDBA_FREE_SPACE
ビューを使用します。)
索引の結合および再構築
BTREE索引を再構築するかどうかは、データベース管理者によって見解が異なります。時間の経過とともにOracle SOA Suiteのパージ・スクリプトではOracle SOA SuiteのBTREE索引の大半で断片化が進むため、SQLパフォーマンスを維持するには再構築が必要になります。
パージ・スクリプトはクローズしたコンポジットのみを削除し、オープンのものは各索引のデータ・ブロック内に保持します。Oracle SOA Suiteの索引キーの多くは増大する一方であるため、データ・ブロックの空き領域は再利用されません。
SQL> ALTER INDEX INDEX_NAME REBUILD OR COALESCE
表13-9に、索引の結合および再構築に関するコストと利点を示します。
表13-9 索引の結合と再作成に関するコストと利点
索引の再作成 | 索引の結合 |
---|---|
索引を別の表領域に迅速に移動できます。 |
索引は別の表領域に移動できません。 |
高コスト: 多くのディスク領域を必要とします。 |
低コスト: 多くのディスク領域を必要としません。 |
新しいツリーを作成して、可能であればその高さを縮小します。 |
ツリーの同じブランチ内のリーフ・ブロックを結合します。 |
オリジナルの索引を削除せずに、記憶域パラメータと表領域パラメータを迅速に変更できる。 |
索引のリーフ・ブロックを迅速に解放できる。 |
索引の再構築の必要に対して有効な方法の1つに、グローバル・ハッシュ索引への変換があります。一方的に増加するキーをハッシュ化してデータ・ブロックにランダムに分散することによって、領域の再利用が改善されます。これ以外にもホットな索引ブロックのバッファ・ビジー待機の減少などの改善があります。しかし、Oracle SOA Suiteの索引のすべてが、変換に適しているわけではありません。以下のドキュメントを参照してください。
http://www.oracle.com/technetwork/database/options/clustering/overview/index-086583.html
表パーティションの削除
表のパーティションを削除すると、表データを一括削除して、領域を再利用できます。Oracle SOA Suite内では、削除が可能であることが確認されるまでパーティションを削除しないでください。詳細は、「検証スクリプトの実行」を参照してください。
パーティションの削除
SQL> ALTER TABLE TABLE_NAME DROP PARTITION P1;
DROP
PARTITION
操作は時間が長くかかりますが、UPDATE
INDEXES
句を指定することで索引の再構築の必要を回避する価値があります。
パーティション化された表に対する表のメンテナンス操作の多くは、対応する索引または索引パーティションを無効化します(UNUSABLE
とマーク)。索引全体または各パーティション(グローバル索引の場合)を再作成する必要があります。メンテナンス操作のALTER
TABLE
文でUPDATE
INDEXES
を指定すると、データベースでこのデフォルトの動作をオーバーライドできます。この句を指定すると、メンテナンス操作のDDL文の実行時に、データベースにより索引が更新されます。これによって、この項で説明した利点が得られます。
次の操作では、UPDATE
INDEXES
句がサポートされています。
-
ADD
PARTITION
-
COALESCE
PARTITION
-
DROP
PARTITION
-
EXCHANGE
PARTITION
-
MERGE
PARTITION
-
MOVE
PARTITION
-
SPLIT
PARTITION
-
TRUNCATE
PARTITION
状況によっては、問題に対処するために表13-10に示されたパーティション操作が必要になる場合があります。
表13-10 パーティションの操作
パーティションの操作 | 説明 |
---|---|
表パーティションの縮小 |
SQL> ALTER TABLE TABLE_NAME MODIFY PARTITION P1 SHRINK SPACE; |
表パーティションの切捨て |
SQL> ALTER TABLE ... TRUNCATE PARTITION |
表パーティションの圧縮 |
SQL> ALTER TABLE TABLE_NAME MOVE PARTITION PART_NAME TABLESPACE TABLESPACE_NAME NOLOGGING COMPRESS FOR OLTP; 重要な制限事項:
|
セキュアなファイルのLOBの構成
セキュアなファイルとは、従来のLOBアクセスと比較して高速で優れた多数のファクタによってパフォーマンス上の利点を提供するLOB記憶域アーキテクチャです。セキュアなファイルは、現在は基本ファイルと呼ばれる以前のLOB記憶域アーキテクチャの完全なリライトです。
セキュアなファイルでは次の拡張機能がサポートされます。
-
非重複化: 同一のセキュアなファイル・データは1コピーのみ格納されます。
-
圧縮: 記憶域、I/O、Redoログおよび暗号化のオーバーヘッドを削減します。圧縮があるため、セキュアなファイルのLOBではオンラインのセグメント縮小コマンドがサポートされません。
-
暗号化
セキュアなファイルは、Oracle 11gデータベースで導入された機能です。既知の問題を回避するため、利用可能な最新のデータベース・パッチ・セットを適用することをお薦めします。
セキュアなファイルの変換
デフォルトでOracle SOA Suiteの表を作成するリポジトリ作成ユーティリティ(RCU)も基本ファイルを作成します。ただし、SOAスキーマの作成時にはセキュアなファイルのLOBも作成できます。次のプロセスは、作成時にのみ使用されます。その他の場合については、「セキュアなファイルの移行」を参照してください。
セキュアなファイルの移行
オンラインの再定義は、セキュアなファイルのLOBへの変換に推奨されるオンラインによる方法です。ただし、オフラインの方法も存在します。
-
Create Table as Select (CTAS)スクリプト
-
Insert Table as Select (ITAS)
-
エクスポート/インポート
オンラインでの再定義の利点
-
表またはパーティションをオフラインにする必要がありません。
-
パラレル実行が可能です。
オンラインでの再定義の短所
-
表またはパーティション全体およびすべてのLOBセグメントと同じだけの追加記憶域が必要です。
-
グローバル索引の再作成が必要です。
Redo生成の防止やパラレル実行など、オンラインでのREDFINITON
パッケージの実行に関するベスト・プラクティスは、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』で、BasicFiles LOBからSecureFiles LOBへの列の移行に関する項を参照してください。
その他のデータベース管理方法
ここでは、データベース増分管理に利用できるその他の方法について説明します。
TRUNCATE文
Truncate文では、すべての行が表から削除されます。したがって、Oracle SOA Suiteの本番環境では、これが実行されたり、必要になる可能性はほとんどありません。詳細は、「表削除なしでの実行時表からのレコードの削除」を参照してください。
データ・ファイルのサイズ変更
表領域の領域を使い果たした場合は、まずアプリケーション・エラーと手動の介入を回避するため、データファイルをAUTOEXTEND
に設定します。
データファイルの初期割当てが過剰な場合、またはセグメントで過剰な増大が許可されている場合は、データファイルのサイズを変更できます。
データファイルのサイズを変更します。ただし、これは領域がセグメントによって使用されていないことを前提としています。
SQL> ALTER DATABASE DATAFILE '/U01/DATAFILE.DBF'' RESIZE 50M;
必ずしもファイルのサイズを指定した値まで縮小できるわけではありません。使用されれていると、データベースから次のエラーが返されます。
ORA-03297: file contains used data beyond requested RESIZE value