| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11gリリース1 (11.1.1.7) B55916-10 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle SOA SuiteおよびOracle Business Process Management Suite管理者ガイド 11gリリース1 (11.1.1.7) B55916-10 |
|
前 |
次 |
この章では、データベースの最適なプロファイルまたはサイズの決定、領域使用量、ハードウェア・リソースおよびデータベース・パフォーマンスの監視、増分管理の課題およびテスト戦略について、および領域管理についてなど、データベースの増分管理戦略の策定戦略を説明しています。
この章では、次の項目について説明します。
パージ・スクリプトおよびコンポーネント表のパーティション化の詳細は、第10章「データベースの増分の管理」を参照してください。
トラブルシューティングの詳細は、第B.2項「パラレル・パージと表のパーティション化の問題」を参照してください。
|
注意: この章は、データベース管理者を対象としています。 |
Oracle SOA Suite 11gのインストールでは、Oracle SOA Suiteデータベースの増分管理など、データベース管理者にかかわる課題がいくつか存在します。データベース管理の重要性を軽視すると、データベースが本番環境に移行したときに問題が発生する可能性があります。この章は、適切な戦略の決定に役立つもので、また、キャパシティ・プランニング、テストおよび監視の必要性に重点を置いています。
推奨される戦略は、Oracle SOA Suiteインストールのプロファイルまたは予測サイズを基準にします。戦略を実装するツールおよび技術はわかりやすく、推奨事項の単純化に役立ちます。ただし、これは設計どおりに実装しなければならない特定のツール・セットを使用するように管理者を制限するものではありません。
増分管理戦略の効率性およびリソース要件の決定には、テストと監視が必要です。テストにより、ツール、データベースおよびハードウェア・リソースのすべてをまとめて、現在および将来のデータベース増分予測のニーズに合致することが保証されます。
ここでは、Oracle SOA Suiteデータベースのプロファイルまたはサイズを確認して、最適な増分管理戦略を決定する戦略を説明します。詳細は、第9.4項「増分管理の課題およびテスト戦略の理解」を参照してください。
ディスク領域使用量の概算のためにこの項で詳述する計算は、全体的な領域キャパシティ・プランニングの実施に置き換わるものではありません。ただし、この推定は適切な増分管理戦略の結論の導出には十分ですが、ディスクキャパシティ・プランニングの必要性も重要事項です。
表9-1は、毎日永続的に使用されるコンポジット領域および最小保持領域に基づいて、小規模、中規模および大規模なインストールのプロファイルを示しています。保存ポリシーで数日間以上データを保持できなくてもコンポジットのインフローが高くなることがあるため、これら2つのメトリックは、and/or条件に関連します。
表9-1 Oracle SOA Suiteのデータベース・プロファイル
| データベース・プロファイル | 毎日永続するコンポジット領域 | 最小保持領域 |
|---|---|---|
|
小規模 |
< 10 GB |
< 100 GB |
|
中規模 |
10-30 GB |
100-300 GB |
|
大規模 |
> 30 GB |
> 300 GB |
コンポジット・インフローおよび領域使用量の比率は、長期間の負荷テスト後に導出される平均として最適であると理解されます。これによって、割り当てられた領域(セグメントのエクステント)の利用を改善できます。インフローを把握するため、次のデータ・ポイントが調査されます。
次の計算式を使用して、毎日生成されるコンポジット数を確認します。
Daily-inflow-composite = (Composite Total / Period)
たとえば、合計コンポジット件数100,000で5日間の負荷テストを行い、それに基づいて生成されるコンポジットの平均数を計算します。
(20,000 = (100,000 / 5))
詳細は、第9.3.1.1項「コンポーネントの増加傾向の判定」を参照してください。
次の計算式を使用して、各コンポジットが使用するディスク領域を確認します。
Inflow-space-per-composite = (SOA Schema Size /Composite Total)
たとえば、合計コンポジット数100,000、およびOracle SOA Suiteスキーマ・サイズ約200GBで、各コンポジットが使用する平均ディスク領域を計算します。
(2MB = (200 GB / 100,000))
詳細は、第9.3.1.2項「Oracle SOA Suiteスキーマの増加傾向の判定」を参照してください。
次の計算式を使用して、毎日永続的に使用されるコンポジット領域を確認します。
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のスキーマの形状を分析して、セグメント領域(表、索引およびラージ・オブジェクト(LOB))の配分を把握し、問題となる可能性がるセグメントを特定できるようにします。
コンポジットの増加傾向を判定します。詳細は、第9.3.1.1項「コンポーネントの増加傾向の判定」を参照してください。
日次の負荷テスト後にコンポーネントの統計を収集して、平均増分を判定できるようにします。
Oracle SOA Suiteスキーマの増加傾向を判定します。詳細は、第9.3.1.2項「Oracle SOA Suiteスキーマの増加傾向の判定」を参照してください。
日次の負荷テスト後にスキーマ・サイジングの統計を収集して、平均増分を判定できるようにします。
最大セグメントを判別します。詳細は、第9.3.1.3項「最大セグメントの判別」を参照してください。
表と索引の増加傾向を判定します。詳細は、第9.3.1.4項「表と索引の増加傾向の判定」を参照してください。
表および索引の増加統計は、自動ワークロード・リポジトリ(AWR)によって自動的に収集されます。
詳細は、第9.3.1.1項「コンポーネントの増加傾向の判定」を参照してください。
コンポジットをデータベース内に保存する期間を検討する必要があります。これはOracle SOA Suiteのスキーマおよびパージ・スクリプトのパフォーマンスに影響します。保存ポリシーに影響するファクタ次のとおりです。
法律的な要件
ライン・オブ・ビジネスの要件
データの保存に関する全般的な会社のポリシー
保存ポリシーが長くなるほど、格納する必要があるデータの量が増加し、それに応じて必要なディスク容量も多くなります。
次の計算式を使用して、最小保存ディスク領域を確認します。Daily-inflow-composite-spaceの詳細は、第9.2.1.3項「毎日永続的に使用されるコンポジット領域の確認」を参照してください。
Min-space-retain = Daily-inflow-composite-space * Retention Period in days
たとえば、毎日永続的に使用されるコンポジット領域40GB、保存期間10日間で最小保存ディスク領域を計算します。
(400 GB = (40 GB * 10))
次の計算式を使用して、最小保存コンポジット数を確認します。Daily-inflow-composite確認の詳細は、第9.2.1.1項「毎日生成されるコンポジット数の確認」を参照してください。
Min-composites-retain = Daily-inflow-composite * Retention Period in days
たとえば、毎日作成されるコンポジット数20,000、および保存期間10日間で最小保存コンポジット数を計算します。
(200,000 = (20,000 * 10))
これにより、10日間の保存ポリシーに基づいて、200,000個のコンポジットが平均400GBのデータを保存すると述べることができます。
|
注意: 前述の計算により、最小ディスク領域使用量の概算が定義されます。実際の最小ディスク領域使用量は、品質保証テストによってより正確に判定されます。詳細は、第9.4.2項「品質保証テスト」を参照してください。 |
コンポジットのアウトフローは、削除されたコンポジット数の測定です。これはデータベース・プロファイルの決定時のファクタではありませんが、増分管理戦略の効率の評価時に重要なメトリックです。
アウトフロー測定の目標は、次の事項を確認することです。
インフローが削除可能であること。
できれば、領域使用量の安定状態が最小保存ディスク領域使用量を少し上回るものであること。
詳細は、第9.2.2.1項「最小保存ディスク領域の決定」を参照してください。
次の2つのサイクルを最初に定義する必要があります。
パージ・サイクル: パージ・スクリプトの複数回の実行が必要になる可能性がある期間を指します。
メンテナンス・サイクル: すべての領域管理操作の実行が必要な日数を指します。詳細は、第9.5.1項「データファイルのコンポーネントの概要」を参照してください。
適切な増分管理戦略には、パージとパーティション化の両方が含まれる場合があります。したがって、アウトフローは適切なパーティションが削除されるまで測定できません。パーティションの削除はメンテナンス操作です。このため、メンテナンス・サイクルが終了するまではアウトフローを測定しても有意義ではありません。
メンテナンス・サイクルの前後に次のメトリックを取得することで、戦略の効率性を把握し、領域配分を再評価できます。
コンポジットの増加傾向を判定します。詳細は、第9.3.1.1項「コンポーネントの増加傾向の判定」を参照してください。
Oracle SOA Suiteスキーマの増加傾向を判定します。詳細は、第9.3.1.2項「Oracle SOA Suiteスキーマの増加傾向の判定」を参照してください。
最大セグメントを判別します。詳細は、第9.3.1.3項「最大セグメントの判別」を参照してください。
表と索引の増加傾向を判定します。詳細は、第9.3.1.4項「表と索引の増加傾向の判定」を参照してください。
|
注意: 安定状態に達している場合、コンポーネントおよびスキーマの増分に関するメトリックの前後の差はゼロに近い数値またはマイナスになります。それ以外の場合は、パージ戦略で対処できていないか、データのインフローが増加している可能性があります。 |
長期間実行されるコンポジットは、保存期間より長期にわたってオープンしているコンポジットです。これらのコンポジットはパージ・スクリプトに大きく関係しませんが、表のパーティション化の実装時に影響が感知されます。(第9.4項「増分管理の課題およびテスト戦略の理解」では、中規模および大規模のインストールでは表のパーティション化を検討するようにお薦めしています。)
パーティション化された表は、その領域がデータベースのALTER TABLE … DROP PARTITIONコマンドによって再利用されるため、パージ・スクリプトの対象から除外されます(また、除外する必要があります)。長期間実行されるコンポジットは、必要とされる保存期間を超えてオープンした状態で保持されるため、パーティションの削除は行われず、領域の再利用は行われません。したがって、パーティション化された表のサイズを推定する際は、使用される保存期間を実行期間が最長のコンポジットと同じにする必要があります。
Retention period = Longest Running Composite.
長期間実行されるトランザクションとパーティション化された表のサイズの領域に対する影響を最もよく理解するには、第9.4項「増分管理の課題およびテスト戦略の理解」の説明に従って品質保証テストを行います。ただし、パーティション化された表のそれぞれが使用する領域の推定には、次の項の計算を使用してください。
数日以上の期間にわたって表に負荷をかけて合理的な平均を生成する方法が最も適しています。表9-2に詳細を示します。
表9-2 表のパーティション化の推奨事項
| アクション | コマンド |
|---|---|
|
各表で毎日生成される平均の行数を判定します。 |
(Total rows / period) |
|
最も長く実行されるコンポジットに基づいて、行数を推定します。 |
((Total rows / period) * Longest running composite in days) |
|
行の計算に基づいて表と索引の領域使用量を推定します。 |
第9.3.1.5項「表サイズの推定」および第9.3.1.6項「索引サイズの推定」を参照してください。 |
|
注意: Oracle SOA Suite Release 11g R1 (11.1.1.6)以降は、行移行と呼ばれるスクリプトの新しいセットが提供されています。これらのスクリプトは、パーティション間で長期間実行されるコンポジットを移動でき、これによってパーティションの削除を容易にします。ただし、ベスト・プラクティスはパーティション表の領域所要量を計画することであり、行移行スクリプトに依存することではありません。 |
次の各項では、領域使用量の監視方法について説明します。
次の各項では、ハードウェア・リソースとデータベース・パフォーマンスの監視方法を説明します。
領域の監視は、データベース管理者およびシステム管理者にとって計画外停止を回避するための重要な作業です。ここでは、キャパシティ・プランニングおよび増分管理戦略の効率性の判定に役立つアドバイスを提供します。監視およびキャパシティ・プランニングのあらゆる側面の包括的なガイドを提供するものではありません。
キャパシティ・プランニングおよびしきい値監視の詳細は、『Oracle Database管理者ガイド』を参照してください。
コンポーネントのマスター表には、各行の作成日付が記録され、特定期間の増加傾向の判定に使用されます。
COMPOSITE_INSTANCE: CREATED_TIME
CUBE_INSTANCE: CREATION_DATE
MEDIATOR_INSTANCE: CREATED_TIME
ただし、コンポーネントのマスター表への問合せは、定期的なパージによってデータが削除されるために制限され、傾向の予測を困難にします。特定期間全体の傾向を判定するには、関連付けられたタイムスタンプとともにデータを定期的に収集する必要があります。これは、毎日移入される単純なコンポーネント履歴表によって実現できます。増分管理戦略の効率性および増加傾向の判定にはこの表で十分になります。
パフォーマンス上の理由により、例9-1に示されるように履歴表をコンポーネント別に作成することが最適である可能性があります。
例9-1 履歴表の作成
SQL> CREATE TABLE SOA_FABRIC_HIST (SFH_DATE TIMESTAMP, SFH_COUNT NUMBER); SQL> INSERT INTO SOA_FABRIC_HIST SELECT SYSTIMESTAMP, COUNT(*) FROM COMPOSITE_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スキーマに作成されるオブジェクト(表、索引およびLOB)は、多様な表領域に拡散している場合がありますが、領域使用量をグループ化するためすべて同じ所有者(*soainfra)が使用されます。各コンポジットの領域所要量を判定する際は、索引とLOBセグメントが反映されるため、スキーマ全体を測定することで優れた領域メトリックを取得できます。
単純な履歴表に毎日移入することで、Oracle SOA Suiteスキーマの増加を監視できます。領域管理の効率性の判定にはこの表で十分になります。詳細は、第9.5項「領域管理の理解」を参照してください。
スキーマ内でどのセグメントが最大であるかを把握することは、レンジ・パーティション化された表として管理することが適している表の判別に役立ちます。さらに、最大セグメントを監視することで、不足している領域管理操作や不適切な監査設定を発見できる可能性もあります。
例9-4に示されるように、Oracle SOA Suiteスキーマの最大から20個までのセグメントを特定します。
例9-5に示されるように、最大セグメントはLOBセグメントである可能性があります。
例9-5 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から取得した領域の変化履歴と結合します。
次の例は、COMPOSITE_INSTANCE表の使用済および割当て済領域の時間経過による増加を示しています。
SQL> SELECT TIMEPOINT, SPACE_USAGE, SPACE_ALLOC, QUALITY FROM TABLE (DBMS_
SPACE.OBJECT_GROWTH_TREND ('DEV_SOAINFRA','COMPOSITE_INSTANCE','TABLE'));
例9-6は、dbms_space.object_growth_trendプロシージャの完全な構文を示しています。
例9-6 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')
表9-3は、object_growth_trend関数のパラメータの説明です。
表9-3 OBJECT_GROWTH_TREND関数のパラメータ
| パラメータ | 説明 |
|---|---|
|
|
オブジェクトを含むスキーマ。 |
|
|
オブジェクトの名前。 |
|
|
オブジェクトのタイプ。 |
|
|
関連する場合は、表または索引パーティションの名前。関連しない場合は |
|
|
増加傾向分析の開始を示すタイムスタンプ値。 |
|
|
増加傾向分析の終了を示すタイムスタンプ値。デフォルトは |
|
|
間隔であるか(yes)、そうでないか(no)。この設定は、結果表がグラフではなく表として表示される場合に便利です。これは、実際の記録間隔が要求されたレポート間隔とどのように関連しているかをより明確に確認できるためです。この関数は、行ごとに1つの間隔のオブジェクトの領域使用情報が表示された表を返します。返される表が非常に大きい場合は、情報が作成されると同時に別のアプリケーションが使用できるように結果がパイプライン化されます。 |
|
|
欠落値の補間をスキップするかどうかを指定します( |
|
|
関数のタイムアウト値(秒)。 |
|
|
統計がないときにセグメントをサンプリングするかどうかを指定します。 |
戻り値を例9-7に示します。
例9-7 戻り値
TYPE object_growth_trend_row IS RECORD( timepoint timestamp, space_usage number, space_alloc number, quality varchar(20));
表9-4は、object_growth_trend_rowの戻り値の説明です。
表9-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;
/
例9-8は、列定義に基づいて表の領域使用量を推定しています。
例9-8 領域使用量の推定
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プロシージャの完全な構文は、例9-9および例9-10に示されています。
最初のオーバーロード
2番目のオーバーロード
例9-10 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);
いずれのバリアントでも、表9-5および表9-6に示された入力が必要です。
表9-5 CREATE_TABLE_COSTプロシージャのパラメータ
| パラメータ | 説明 |
|---|---|
|
|
オブジェクトが作成される表領域。デフォルトは |
|
|
表の予測行数。 |
|
|
更新の結果、既存の行を将来拡張するために各ブロックで確保される空き領域の割合(パーセンテージ)。 さらに、最初のバリアントには、入力値として また、2番目のバリアントは、予想された各列値を |
dbms_spaceパッケージのcreate_index_costプロシージャを使用すると、既存の表での索引作成の領域使用コストを推定できます。これを使用して、Oracle SOA Suiteスキーマに索引を追加する際のコストを判定します。
例9-11は、データ定義言語(DDL)に基づいて新しい索引のサイズを推定します。
例9-11 新しい索引のサイズ
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);
このプロシージャには、表9-7に示された入力値が必要です。
表9-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)およびメンテナンス期間、特にこれらの期間が重複する際にハードウェア・リソースを監視することが重要です。
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ユーティリティで、2つのスナップショット間隔間の統計を分析し、以下が含まれるパフォーマンス・サマリー・レポートを作成できます。
CPUのボトルネック
サイズ設定が小さすぎるメモリー構造
I/O能力に関連する問題
高負荷のSQL文
高負荷のPL/SQL実行およびコンパイルの問題、および高負荷のJavaの使用
Oracle Real Application Clusters固有の問題
アプリケーションによるOracleデータベースの非効率的な使用
データベース構成の問題
同時実行の問題
ホット・オブジェクト
AWRおよびADDMユーティリティは手動で、またはOracle Enterprise Manager Database Controlから実行できます。詳細は、『Oracle Database 2日でパフォーマンス・チューニング・ガイド』を参照してください。
完全なOracle SOA SuiteのI/O設計は、この章の範囲に含まれていません。ただし、『Oracle Databaseパフォーマンス・チューニング・ガイド』には、適切なアドバイスが記載されています。適切に計画されているI/O計画では、容量、可用性およびパフォーマンスが考慮されます。
AWRレポートは、アクセス頻度の高いセグメント、データファイルおよび表領域を特定します。OSWatcherは、長時間かかるI/Oキューを特定します。これらのツールを組み合せることによって、問題のあるディスク・デバイスおよびファイルが特定されます。これによって、I/Oの均衡化、または低速ボリューム上のRedundant Arrays of Inexpensive 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 Databaseパフォーマンス・チューニング・ガイド』を参照してください。
ここでは、Oracle SOA Suiteデータベースの増分管理に適したツールに関する推奨事項を説明しています。提示されるアドバイスは、新規インストール、または現在の戦略に監視や領域管理が不足している既存のインストールに向けたものです。その他の推奨事項は、第B.2項「パラレル・パージと表のパーティション化の問題」を参照してください。
この項の前に、第9.3項「領域使用量、ハードウェア・リソース、およびデータベース・パフォーマンスの監視」を参照して、Oracle SOA Suiteのパージおよびパーティション化ツールについて十分に理解しておくことをお薦めします。
ここで説明する課題は、推奨される戦略に関係する状況を説明することによって背景知識を提供します。
非効率的なパージ戦略が実装されていると、Oracle SOA Suiteの表が非常に大きく増大する場合があります。これによって、緊急に領域再利用の必要が発生することになります。表が大きいほど、行の削除や領域の再利用が困難になります。
パラレル・パージ・スクリプトのパフォーマンスは、CPUリソース、ディスクI/Oの速度などのファクタに依存します。ただし、非常に大きな表は問題であることが判明しています。この問題は、削除可能なコンポジットを決定するために解析が必要になるデータ量が原因で生じます。この解析は、パージ・スクリプト全体の経過時間を独占的に使用する場合があります。詳細は、第B.2.1.3項「パラレル問合せスレーブの使用」を参照してください。
この状況は、増分管理戦略の効率性の監視が常に必要であること、および表が非常に大きくなる前に可能なかぎり速やかに対応措置をとる必要があることを強調するものです。
パラレル・パージ・スクリプトのパフォーマンスを向上させるため、経過時間の長い表はレンジ・パーティション化してスクリプトから除外できます。ただし、表のパーティション化が本番環境で必要な場合は、これによって停止時間の問題が生じます。表は再定義パッケージによってオンラインでパーティション化できますが、非常に大きい表で発生した場合は、この操作が合理的な時間内に完了しない場合があります。Oracle SOA Suite Release 11g R1 (11.1.1.6)移行は、パーティション化が可能な表の粒度が改善されています。現在は、マスター表のみで高ボリュームの表のパーティション化を実行できます。これによってパーティション化の注目度が上がり、実現性も高くなります。詳細は、第10.4.8項「コンポーネントの部分的なパーティション化」を参照してください。
長期間実行されるコンポジットは、保存期間より長期にわたってオープンしているコンポジットです。含まれるすべてのコンポジットがクローズされるまでは削除できないため、これはOracle SOA Suiteの表パーティションに影響を及ぼします。オープンのコンポジットが数個であっても、パーティションの削除および領域の再利用ができなくなる可能性があります。この状況からOracle SOA Suiteリリース11g R1 (11.1.1.6)で使用可能な行移行スクリプトが生まれました。詳細は、第10.4.7項「別のパーティションへの長時間実行されているアクティブなインスタンスの移動」を参照してください。
最も長時間実行されるコンポジットの保存期間を含め、パーティション化された表を収容するために十分なディスク領域を計画します。領域の再利用が緊急に必要な場合は、修正処理として行の移行スクリプトをお薦めします。
行移行スクリプトによるコンポジット・データの移動によって、次の問題が発生します。
このスクリプトは、スクリプトによるパフォーマンスの問題を回避するためパーティション内のデータの約5%が移動されると想定して作成されています。
同一レベルのパーティション化の要件を維持するには、多数の表の行の5%の移動が必要です。同一レベル・パーティション化の詳細は、第B.2.2.1項「参照整合性および同一レベル・パーティション化」を参照してください。
5%の任意数は、パーティションのサイズを意味するものではなく、インフロー率およびパーティションの期間(日次、週次および月次)に依存します。
最新のパーティション、またはアクティブ・コンポジットのプール専用として作成されたパーティションに実行時間の長いコンポジットの移行を繰り返すと、累積が発生することがあります。
特定のパーティションが非常に増大して、別の影響が生じるパージが必要になります。詳細は、第B.2.2.5項「パーティション・プルーニング」を参照してください。
ツールおよび技術の習熟および理解を保証するには増分管理戦略のテストが非常に重要です。品質保証テストに使用可能なハードウェア・リソースは本番環境と同じであることはほとんどありません。したがって、管理者が本番稼働ホストに結果を反映する際は慎重に予測する必要があります。
この項の項目は次のとおりです。
サポート・ノートDoc ID 358.1 メンテナンスおよび管理アドバイザ: Oracle Fusion Middleware (FMW) SOA 11gインフラストラクチャのデータベースを確認します。
https://support.oracle.com
監査設定が本番環境に適しているかを確認します。詳細は、第B.2.3項「監査レベルの低減」を参照してください。
本番環境と比較可能なテスト環境を作成することは困難ですが重要です。パージ・スクリプトのパフォーマンスは、解析が必要なデータの量によっては悪影響を受ける場合があります。したがって、パージのパフォーマンスを把握するにはサイジングが適切なテスト環境が重要です。詳細は、第B.2.1.3項「パラレル問合せスレーブの使用」を参照してください。
スキーマに移入される混在ワークロードは、ペイロード・サイズとコンポジット起動数が本番環境と類似している必要があります。データは、何日分もの負荷をシミュレートして、領域平均と推計サイズの判定を向上させる必要があります。
データの負荷時は、表別の使用領域および各領域の配分の判定に時間をかけてください。インフローの計算の詳細は、第9.2.1項「データのインフローの確認」を参照してください。
コンポジットの増加傾向を判定します。詳細は、第9.3.1.1項「コンポーネントの増加傾向の判定」を参照してください。
Oracle SOA Suiteスキーマの増加傾向を判定します。詳細は、第9.3.1.2項「Oracle SOA Suiteスキーマの増加傾向の判定」を参照してください。
パーティション化を念頭に置いてメトリックを収集します。
最大セグメントを判別します。詳細は、第9.3.1.3項「最大セグメントの判別」を参照してください。
表と索引の増加傾向を判定します。詳細は、第9.3.1.4項「表と索引の増加傾向の判定」を参照してください。
表のサイズを推定します。詳細は、第9.3.1.5項「表サイズの推定」を参照してください。
索引のサイズを推定します。詳細は、第9.3.1.6項「索引サイズの推定」を参照してください。
次の2つのサイクルをまず理解しておく必要があります。
パージ・サイクル: パージ・スクリプトの複数回の実行が必要になる可能性がある期間を指します。
メンテナンス・サイクル: すべての領域管理操作の実行が必要な日数を指します。詳細は、第9.5.1項「データファイルのコンポーネントの概要」を参照してください。
目標は、パージ・スクリプトおよびメンテナンス・操作を実行して、パージに増大の余裕があることを保証してそれぞれに最適なサイクルを判定することです。パージ・スクリプトは、1日に複数回実行する必要がある場合があり、またメンテナンス操作は数日間にまたがる可能性があります。
後続の各項で領域の調整、監視、再利用の方法について説明します。
パラレル・パージ。詳細は、第B.2.1項「パラレル・パージ・スクリプトの実行」を参照してください。
ハードウェアおよびデータベースの監視。詳細は、第9.3.2項「ハードウェア・リソースおよびデータベースの監視」を参照してください。
領域管理操作。詳細は、第9.5.1項「データファイルのコンポーネントの概要」を参照してください。
目標は次のとおりです。
パージによって、インフローと同等またはそれ以上の領域の削除および再利用を実行できるかを判定します。詳細は、第9.2.2項「保存ポリシーの策定」および第9.2.3項「データのアウトフローの確認」を参照してください。
パージ要件に一致させるためにパージの実行が必要な回数およびパージ・サイクルの合計経過時間を判定します。このパージ・サイクルは、その実行に割り当てられた時間の80%以内で完了する必要があります。
ボトルネックの表を判別します。詳細は、第B.2.1.4項「パージ操作のデバッグとトレース」を参照してください。
データベースおよびO/Sレポートでのリソース競合および待機を確認します。詳細は、第9.3.2項「ハードウェア・リソースおよびデータベースの監視」を参照してください。
大規模インストールでは、パージが困難であると確認された表のパーティション化を検討する必要があります。これらの表は、最大の表でもある可能性があります。表のパーティション化は、一括データ削除として実証済の方法です。Oracle SOA Suiteスキーマは、レンジ・パーティション化を容易にするパーティション・キーを備えています。
Oracle SOA Suiteリリース11g R1 (11.1.1.6)以降は、パーティション化が可能な表の粒度が改善されています。現在は、マスター表のみで高ボリュームの表のパーティション化を実行できます。これによってパーティション化の注目度が上がり、実現性も高くなります。
部分的なパーティション化。詳細は、第10.4.8項「コンポーネントの部分的なパーティション化」を参照してください。
長時間実行されるコンポジット。詳細は、第9.2.4項「長期間実行されるコンポジットおよび表のパーティション化の確認」を参照してください。
第9.4.2.4項「パラレルまたはシングル・スレッド・スクリプトの実行および領域の再利用」および第9.4.2.5項「テスト結果の確認」で説明されているパージ・テストとテスト結果の確認を繰り返します。パーティション化された表は除外します。
次の推奨される増分管理戦略は、Oracle SOA Suiteデータベース・プロファイルを基準にしています。
戦略には、効率性を判定するためのテストが必要です。テストでは以下について確認する必要があります。
パージ・スクリプトに増大の余裕があること。
パーティション化された表に十分なディスク領域があること。
増大が監視されていること。
メンテナンス実行時のOLTPパフォーマンスへの影響が最小であること。
大規模なデータベース・プロファイルのあるインストールでは、戦略の一環として表のパーティション化を真剣に検討する必要があります。表のレンジ・パーティション化は大型の表の実証済の管理方法です。
パーティション化された表を除いてパラレル・パージを実行します。詳細は、第10.3.2項「dbms_schedulerを使用したパラレル・スクリプトでのループしたパージ」を参照してください。
パージ・スクリプトに対してボトルネック表をパーティション化します。詳細は、第10.4項「コンポーネント表のパーティション化」を参照してください。
メンテナンス・サイクルの一環として、領域を再利用します。詳細は、第9.5.1項「データファイルのコンポーネントの概要」を参照してください。
メンテナンス・サイクルの一環として、適切なパーティションを削除します。詳細は、第10.4.5項「検証スクリプトの実行」を参照してください。
インフローおよびアウトフローを監視します。詳細は、第9.2.2項「保存ポリシーの策定」および第9.2.3項「データのアウトフローの確認」を参照してください。
データベースおよびハードウェア・リソースを監視します。詳細は、第9.5.2項「セグメントおよびデータファイル領域の再利用」を参照してください。
中規模データベース・プロファイルのインストールは、潜在的に増大化する可能性があります。このため、推奨事項は大規模プロファイルと同じになります。詳細は、第9.4.3.1項「大規模データベース・プロファイルの推奨事項」を参照してください。
本番環境の表のパーティション化では停止時間が必要になる可能性があるため、中規模のインストールでは厳密な品質保証テストを実行することが重要です。
唯一追加される推奨事項は、表の再作成スクリプト(TRSスクリプト)をパージの代替にできることです。これは、実際に中規模とされるデータベースのサイズ、およびメンテナンス・ウィンドウにおける停止時間の可用性に依存します。
TRSスクリプトの詳細は、第10.6項「オープン・コンポジット・インスタンスでの表の再作成およびデータベース領域の再利用」を参照してください。
CPU、メモリー、ディスク領域が限定的な小規模インストールでは、シングル・スレッド・パージから開始し、その後パラレル・パージに移ります。
シングル・スレッド・パージを実行します。詳細は、第10.3.1項「ループされるパージ・スクリプト」を参照してください。
パラレル・パージを実行します。詳細は、第10.3.2項「dbms_schedulerを使用したパラレル・スクリプトでのループしたパージ」を参照してください。
シングル・スレッド・パージを実行していない場合は、パラレル・パージをテストする必要があります。
インフローおよびアウトフローを監視します。詳細は、第9.2.2項「保存ポリシーの策定」および第9.2.3項「データのアウトフローの確認」を参照してください。
データベースおよびハードウェア・リソースを監視します。詳細は、第9.5.2項「セグメントおよびデータファイル領域の再利用」を参照してください。
唯一追加される推奨事項は、TRSスクリプトをパージの代替にできることです。これは、実際に小規模とされるデータベースのサイズ、およびメンテナンス・ウィンドウにおける停止時間の可用性に依存します。
この項の情報の多くは、様々なOracle Database管理ガイドにも記載されています。ここに概要が記載された領域管理の概念およびコマンドは、Oracle SOA Suiteのパージ・スクリプトによる領域の再利用に関する誤解を解決します。領域を再利用するには、データベースのメンテナンス操作を実行する必要があります。
デフォルトでは、自動セグメント領域管理(ASSM)によってローカルで管理される表領域にOracle SOA Suiteスキーマが作成されます。したがって、アドバイスはすべてこの状況に限定しています。この項はすべてのデータベース領域管理機能の包括的なガイドを目指したものではありません。
データファイルは、次のコンポーネントに分けることができます。
セグメント: 特定タイプのデータベース・オブジェクトが格納されます。つまり、表は表セグメントに格納され、索引は索引セグメントに格納されます。
エクステント: セグメント内のデータ・ブロックの連続したセットです。Oracleデータベースは、セグメントの領域を1つのエクステント単位に割り当てます。
データ・ブロック: データベース・ブロックとも呼ばれ、データベース記憶域のI/Oの最小単位です。エクステントは複数の連続するデータ・ブロックから構成されます。
表領域: 1つ以上の物理データ・ファイルで構成されます。ローカル管理表領域では、データファイル・ヘッダー内に、データファイル本体の空き領域および使用済領域を追跡するためのビットマップが保持されています。各ビットは、1ブロック・グループに対応します。領域の割当てまたは解放時に、Oracleデータベースはビットマップ値を変更して、ブロックの新しいステータスを反映させます。
セグメント、エクステントおよびデータ・ブロックはすべて論理構造です。
図9-1は、論理記憶域と物理記憶域間の関係を示しています。
領域を管理するため、Oracleデータベースはセグメント内のブロックの状態を追跡します。最高水位標(HWM)は、セグメント内のポイントで、これを超えるとデータ・ブロックがフォーマットされず、使用されないことになります。HWMと低いHWMとの間のブロックに空きがなくなると、HWMが右側に拡張されて、低いHWMも以前のHWMの場所まで拡張されます。図9-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
圧縮表
表9-8は、オンラインのセグメント縮小の例を示しています。
表9-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;
|
注意:
|
BTREE索引を再構築するかどうかは、データベース管理者によって見解が異なります。時間の経過とともにOracle SOA Suiteのパージ・スクリプトではOracle SOA SuiteのBTREE索引の大半で断片化が進むため、SQLパフォーマンスを維持するには再構築が必要になります。
パージ・スクリプトはクローズしたコンポジットのみを削除し、オープンのものは各索引のデータ・ブロック内に保持します。Oracle SOA Suiteの索引キーの多くは増大する一方であるため、データ・ブロックの空き領域は再利用されません。
SQL> ALTER INDEX INDEX_NAME REBUILD OR COALESCE
表9-9は、索引の結合および再構築に関するコストと利点を示しています。
表9-9 索引の結合と再作成に関するコストと利点
| 索引の再構築 | 索引の結合 |
|---|---|
|
索引を別の表領域に迅速に移動できます。 |
索引は別の表領域に移動できません。 |
|
高コスト: 多くのディスク領域を必要とします。 |
低コスト: 多くのディスク領域を必要としません。 |
|
新しいツリーを作成して、可能であればその高さを縮小します。 |
ツリーの同じブランチ内のリーフ・ブロックを結合します。 |
|
オリジナルの索引を削除せずに、記憶域パラメータと表領域パラメータを迅速に変更できる。 |
索引のリーフ・ブロックを迅速に解放できる。 |
索引の再構築の必要に対して有効な方法の1つに、グローバル・ハッシュ索引への変換があります。一方的に増加するキーをハッシュ化してデータ・ブロックにランダムに分散することによって、領域の再利用が改善されます。これ以外にもホットな索引ブロックのバッファ・ビジー待機の減少などの改善があります。しかし、Oracle SOA Suiteの索引のすべてが、変換に適しているわけではありません。Oracle FMW 11g R1 SOA with Oracle Database Real Application Clustersの評価を参照してください。
http://www.oracle.com/technetwork/database/availability/maa-fmw-soa-racanalysis-427647.pdf
表のパーティションを削除すると、表データを一括削除して、領域を再利用できます。Oracle SOA Suite内では、削除が可能であることが確認されるまでパーティションを削除しないでください。詳細は、第10.4.5項「検証スクリプトの実行」を参照してください。
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
状況によっては、問題に対処するために表9-10に示されたパーティション操作が必要になる場合があります。
表9-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記憶域アーキテクチャの完全なリライトです。
セキュアなファイルでは次の拡張機能がサポートされます。
非重複化: 同一のセキュアなファイル・データは1コピーのみ格納されます。
圧縮: 記憶域、I/O、Redoログおよび暗号化のオーバーヘッドを削減します。圧縮があるため、セキュアなファイルのLOBではオンラインのセグメント縮小コマンドがサポートされません。
暗号化
セキュアなファイルはOracle 11gデータベースで導入された比較的新しい機能であるため、提供されている最新のデータベース・パッチ・セットを適用して既知の問題を回避することをお薦めします。
セキュアなファイルを使用するには、次の設定が必要です。
COMPATIBLE初期化パラメータを11.0.0.0.0より大きく設定します。
SQL> show parameter COMPATIBLE;
DB_SECUREFILE初期化パラメータは、LOB記憶域に関するデータベースのデフォルトのアクションを制御します(PERMITTEDの場合のデフォルト)。
SQL> ALTER SYSTEM SET DB_SECUREFILE = 'ALWAYS'; SQL> SHOW PARAMETER DB_SECUREFILE
| パラメータ | 説明 |
|---|---|
|
|
ASSM表領域内のすべてのLOBが、セキュアなファイルのLOBとして作成されます。ASSM以外の表領域のLOBは、明示的にセキュアなファイルと指定しないかぎり、基本ファイルのLOBとして作成されます。基本ファイル記憶域オプションは無視され、セキュアなファイルのデフォルトの記憶域オプションがすべての未指定オプションに使用されます。 |
|
|
すべてのLOBがセキュアなファイルのLOBとして作成されます。LOBがASSM以外の表領域で作成されと、例外がスローされます。基本ファイル記憶域オプションは無視され、セキュアなファイルのデフォルトの記憶域オプションがすべての未指定オプションに使用されます。 |
|
|
|
|
|
セキュアなファイルのLOBは許可されません。 |
|
|
セキュアなファイルのLOBの作成が行われず、セキュアなファイルの記憶域オプションに関連するすべてのエラーが無視されます。 |
ASSMをサポートするように表領域を構成します。
SQL> SELECT SEGMENT_SPACE_MANAGEMENT FROM DBA_TABLESPACES WHERE TABLESPACE_NAME
= 'TABLESPACE_NAME';
デフォルトでOracle SOA Suiteの表を作成するリポジトリ作成ユーティリティ(RCU)も基本ファイルを作成します。ただし、SOAスキーマの作成時にはセキュアなファイルのLOBも作成できます。次のプロセスは、作成時にのみ使用されます。その他の場合については、第9.5.2.5.3項「セキュアなファイルの移行」を参照してください。
要件に一致していること、およびDB_SECUREFILEデータベース初期化パラメータがALWAYSまたはFORCEに設定されていることを確認します。要件の詳細は、第9.5.2.5.1項「セキュアなファイルの要件」を参照してください。
適切なOracle SOA SuiteのRCUユーティリティを実行して、スキーマを作成します。LOBは基本として定義されていますが、これはセキュアなファイルとして作成されます。基本ファイルのLOB記憶域パラメータは無視されます。
圧縮、非重複化および暗号化の拡張機能はデフォルトでは有効化されていません。
次のコマンドを入力して、セキュアなファイルのLOB列で拡張機能が有効化されているかどうかを判定します。
SQL> SELECT TABLE_NAME, COLUMN_NAME, SECUREFILE, RETENTION, ENCRYPT, COMPRESSION, DEDUPLICATION FROM DBA_LOBS;
RCUの使用直後に、拡張機能を有効化するALTERコマンドを実行する必要があります。
SQL> ALTER TABLE LOB_TABLE MODIFY LOB(LOB_COLUMN) (COMPRESS); SQL> ALTER TABLE LOB_TABLE MODIFY LOB(LOB_COLUMN) (DEDUPLICATE);
|
注意: 圧縮、非重複化または暗号化は、 |
オンラインの再定義は、セキュアなファイルのLOBへの変換に推奨されるオンラインによる方法です。ただし、オフラインの方法も存在します。
Create Table as Select (CTAS)スクリプト
Insert Table as Select (ITAS)
エクスポート/インポート
TRSスクリプト
詳細は、第10.6項「オープン・コンポジット・インスタンスでの表の再作成およびデータベース領域の再利用」を参照してください。
オンラインでの再定義の利点
表またはパーティションをオフラインにする必要がありません。
パラレル実行が可能です。
オンラインでの再定義の短所
表またはパーティション全体およびすべてのLOBセグメントと同じだけの追加記憶域が必要です。
グローバル索引の再作成が必要です。
Redo生成の防止やパラレル実行など、オンラインでのREDFINITONパッケージの実行に関するベスト・プラクティスは、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』で、BasicFiles LOBからSecureFiles LOBへの列の移行に関する項を参照してください。
ここでは、データベース増分管理に利用できるその他の方法について説明します。
TRSスクリプトは、オープンのコンポジットのみを選択するため、デフォルトでは指定の保存期間を超過したクローズ済のコンポジットがすべて削除されます。表および索引の再作成プロセスでも、領域の再編成および再利用が行われます。詳細は、第10.6項「オープン・コンポジット・インスタンスでの表の再作成およびデータベース領域の再利用」を参照してください。
Truncate文では、すべての行が表から削除されます。したがって、Oracle SOA Suiteの本番環境では、これが実行されたり、必要になる可能性はほとんどありません。詳細は、第10.5項「表削除なしでの実行時表からのレコードの削除」を参照してください。
表領域の領域を使い果たした場合は、まずアプリケーション・エラーと手動の介入を回避するため、データファイルをAUTOEXTENDに設定します。
データファイルが自動拡張可能であるかを判定するには、DBA_DATA_FILESビューの列AUTOEXTENSIBLEを問い合せます。
SQL> SELECT AUTOEXTENSIBLE FROM DBA_DATA_FILES
ファイルの自動拡張は、データファイルの作成または変更時にAUTOEXTEND ON句を指定することによって指定します。
SQL> ALTER TABLESPACE TABLESPACE_NAME ADD DATAFILE '/U01/DATAFILE.DBF' SIZE 10M AUTOEXTEND ON; SQL> ALTER DATABASE DATAFILE '/U01/DATAFILE.DBF' AUTOEXTEND ON;
データファイルの初期割当てが過剰な場合、またはセグメントで過剰な増大が許可されている場合は、データファイルのサイズを変更できます。
データファイルのサイズを変更します。ただし、これは領域がセグメントによって使用されていないことを前提としています。
SQL> ALTER DATABASE DATAFILE '/U01/DATAFILE.DBF'' RESIZE 50M;
必ずしもファイルのサイズを指定した値まで縮小できるわけではありません。使用されれていると、データベースから次のエラーが返されます。
ORA-03297: file contains used data beyond requested RESIZE value
