Oracle 11g　インターバル・パーティションに関する検証　その８

＜Oracle 11g　インターバル・パーティションに関する検証　その８＞
ペンネーム：ミラニスタ

どのパーティションにも格納（マップ）されない新規レコードに対して、
Oracleが自動的に適切なパーティションを追加してくれるインターバル・パー
ティションを検証しています。

▼ 読者の声から

前回の記事に対して、読者の方から以下のようなご意見をいただきました。
ご本人の了解を得ていますので、ご紹介させていただきます。

===========================================
> だから、「PARTITION_COUNT列は常に最大パーティション数（1048575）に固
> 定してしまえ！」とインターバル・パーティションの開発者が考えたとしても
> 不思議ではありません。
> さらに、割り切って考えると、パーティション追加時の Update文は同じ値
> で更新しているので、あえて実行する必要はないかもしれません。

これは開発者本意の発言であってユーザは第２という事を云ってますよね。
おら！オラ！ Oracleには常にユーザ側に立った見方をして欲しいと思います。
でなければただの興味本位のOracleマニアのサイトでしかないと思うので。
===========================================

そもそも、今回の検証はインターバル・パーティションについて調べていて

・USER_PART_TABLES.PARTITION_COUNT列値がリファレンス・マニュアルの説明
と異なっている。
・実行計画に表示されるパーティション範囲の終了値が実際と異なっている。
（下のPstop値。実際は「10」）

実行計画
----------------------------------------------------------------
| Id  | Operation           | Name    | Rows  || Pstart| Pstop |
----------------------------------------------------------------
|   0 | SELECT STATEMENT    |         |   100 ||       |       |
|   1 |  PARTITION RANGE ALL|         |   100 ||     1 |1048575|
|   2 |   TABLE ACCESS FULL | INTER01 |   100 ||     1 |1048575|
----------------------------------------------------------------

という点で、従来のレンジ・パーティションとは違っていることに気付いたの
が発端です。

内部SQLやバインド変数を確認して、内部動作をある程度把握することがで
きたのですが、マニュアルと異なる現象を（インターバル・パーティション
独自の）「新たな仕様」としてご紹介するスタイルとなってしまいました。

しかし、私がユーザの一人としてこのような現象に違和感を持ったこともま
た事実です。ご指摘いただいたように、おかしいことはおかしいときちんと問
題提議をすべきでした。ユーザに裏技的な知識を求めるというのはやはりある
べき姿ではありませんし、そのような印象を与えてしまったことは反省させて
いただきたいと思います。

読者の皆様には忌憚のないご意見を、今後ともよろしくお願いいたします。

そして、ご意見をくださったＹ様、ありがとうございました！

▼ 情報ライフサイクル管理（ILM:Information Lifecycle Management）の
ベースとなるインターバル・パーティション

インターバル・パーティションについて7回にわたって紹介してきたわけで
すが、情報ライフサイクル管理という考え方を紹介し、インターバル・パー
ティションの活用について考えてみたいと思います。

最近、ある案件で「非重複化技術」を活用したストレージ（ディスク装置）
を利用する機会がありました。（このキーワードで是非検索してみてください。）
今まで、1GBあたりの単価が安いストレージと言えばテープ装置が代表格だっ
たのですが、テープ装置のデメリットをあえて挙げると以下のようになります。

・テープに保存したデータはオンラインで使用できない。
・テープからディスクへのリストアは非常に時間がかかる。（いざという場合
の復旧に時間がかかる。）
・テープに保存されているデータが万一壊れていても、リストア（利用）する
までわからない。
・テープは消耗品なので、何度も使いまわすといずれ使えなくなる。
・補充するテープ代が意外と高い。

このように、安価だと思われているテープにはいろいろな問題があります。

これに対してデータ非重複化（Data De-duplication）技術を応用したスト
レージでは、前回保存してから変わっていない重複データを除外することによ
り、実際の容量の数十分の１のディスクにデータを保管することができます。
私が確認した実例では、40倍近くの圧縮率で保管できていました。（圧縮効果
はデータの内容に依存しますので、必ずしもこのような結果にはなりません。）

従って、テープ媒体よりは高価な磁気ディスクであっても、1GBあたりの単価
がテープに比べても遜色のないレベルまで安くなっています。
むしろ、オンラインで利用できる、データの検査をしながら保存ができる、
RAID構成により冗長化を図ることが可能、といった磁気ディスク装置のメリット
を生かした低コスト・ストレージとしてこのタイプのディスクは今後脚光を浴
びていくものと思われます。
筆者はこれをNASストレージとして使用することができる製品を利用しまし
た。

情報ライフサイクル管理（ILM:Information Lifecycle Management）とは、
このような低コスト・ストレージの出現によって現実化してきた、データ管理
の考え方です。

例えば

(1) 直近3年以内のデータ
(2) 3～5年のデータ
(3) 5年以上経過しているデータ

という3つの区分があり、データへのアクセス頻度が

(1) > (2) >> (3) とするならば、

データの格納先として

(A) 高性能・高信頼性ハイエンドストレージ（RAID0+1）
(B) ミッドレンジストレージ（RAID5）
(C) 非重複化ストレージ（NAS）

を用意しておけば

(1)-(A)、(2)-(B)、(3)-(C)という組み合わせで、コスト・パフォーマンスの
高いストレージ構成を実現できるというのがILMの基本的な考え方です。

つまり、頻繁にアクセスするデータを身近なハイエンドストレージに、あま
り利用する機会のないデータは低速・安価なディスクに置くことにより、スト
レージ全体に関わるコストを最適化しようとする試みです。

このような考え方に、パーティション化は非常に相性のよい技術と言えます。
つまり、パーティション単位で任意のストレージ（表領域）にコマンド1つ
でデータを移動することができるからです。
以下、インターバル・パーティションを使いILMに準拠した運用の例を示し
ます。

1. 異なるストレージに表領域を作成する。

以下のように、1GBあたりのコストが異なる3種類のストレージに表領域を作
成しているものとします。（表領域HIGH_ENDがデフォルト表領域です。）

SQL> SELECT NAME TABLESPACE_NAME FROM V$TABLESPACE
  2  WHERE NAME LIKE '%_END';

TABLESPACE_NAME
—————-
HIGH_END <= (A) ハイエンドストレージ　（デフォルト表領域）
MID_RNG <= (B) ミッドレンジストレージ
LOW_END CREATE TABLE TMINT02(itime date)
2 PARTITION BY RANGE(itime)
3 INTERVAL(numtoyminterval(3′,’month’))
4 (PARTITION VALUES LESS THAN (to_date(‘1995/04/01”,’yyyy/mm/dd’)));

表が作成されました。

3. データのInsert

パーティションが追加されるようなデータをInsertします。今まで検証して
きたとおり、パーティション・キーの昇順にInsertされる必要がないことを認
識してください。

SQL> insert into TMINT02 values (to_date('2008/10/01','yyyy/mm/dd'));
SQL> insert into TMINT02 values (to_date('2008/07/01','yyyy/mm/dd'));
.....................................................................
SQL> insert into TMINT02 values (to_date('1995/04/01','yyyy/mm/dd'));
SQL> insert into TMINT02 values (to_date('1995/01/01','yyyy/mm/dd'));
SQL> commit;

SQL> select to_char(itime,'yyyy/mm/dd') itime from TMINT02;

ITIME
----------
1995/01/01
1995/04/01
..........
2008/07/01
2008/10/01

56行が選択されました。

テーブルを作成した際の諸元に基づき、データに応じた適切なパーティショ
ンが自動的に追加されるのがインターバル・パーティションの優れたところで
す。

パーティション追加は自動的に行われるようになりましたが、古いパーティ
ションをどのように管理していくかということは、DBAが主体的に判断していか
なければなりません。

具体的にどのような手順でメンテナンスしたらよいかを引き続き紹介します。

4. パーティション名の変更

パーティションの名前をシステムが勝手につけた「SYS_Pxxx」から、どのよ
うなデータが格納されているか一目でわかるように、「Pyyyymm」の形に変更
します。
これは、必須手順ではありませんが、後でパーティションのメンテナンスを
行う際に、間違って別のパーティションを対象としてしまわないようにするた
めの名称変更です。

SQL> ALTER TABLE TMINT02 RENAME PARTITION SYS_P41 TO P199504;
SQL> ALTER TABLE TMINT02 RENAME PARTITION SYS_P42 TO P200901;
.............................................................
SQL> ALTER TABLE TMINT02 RENAME PARTITION SYS_P95 TO P199510;
SQL> ALTER TABLE TMINT02 RENAME PARTITION SYS_P96 TO P199507;

ここまでのパーティションの状況を確認すると次のようになります。

SQL> SELECT PARTITION_NAME,PARTITION_POSITION,TABLESPACE_NAME
  2  FROM USER_TAB_PARTITIONS
  3  WHERE TABLE_NAME = 'TMINT02'
  4  ORDER BY PARTITION_POSITION;

PARTITION_NAME   PARTITION_POSITION TABLESPACE_NAME
---------------- ------------------ --------------------
P199504                           1 HIGH_END
P199507                           2 HIGH_END
........................................................
P200810                          55 HIGH_END
P200901                          56 HIGH_END

5. ILMに基づくパーティションのメンテナンス

この段階で、すべてのパーティションはデフォルトのHIGH_END表領域にあり
ます。
ILMの考え方に基づき、保管年月に応じた表領域にパーティションを移動さ
せます。

SQL> ALTER TABLE TMINT02 MOVE PARTITION P199504 TABLESPACE LOW_END;
SQL> ALTER TABLE TMINT02 MOVE PARTITION P199507 TABLESPACE LOW_END;
SQL> ..............................................................
SQL> ALTER TABLE TMINT02 MOVE PARTITION P200310 TABLESPACE LOW_END;
SQL> ALTER TABLE TMINT02 MOVE PARTITION P200401 TABLESPACE MID_RNG;
SQL> ..............................................................
SQL> ALTER TABLE TMINT02 MOVE PARTITION P200507 TABLESPACE MID_RNG;
SQL> ALTER TABLE TMINT02 MOVE PARTITION P200510 TABLESPACE MID_RNG;

SQL> SELECT PARTITION_NAME,PARTITION_POSITION,TABLESPACE_NAME
  2  FROM USER_TAB_PARTITIONS
  3  WHERE TABLE_NAME = 'TMINT02'
  4  ORDER BY PARTITION_POSITION;

PARTITION_NAME   PARTITION_POSITION TABLESPACE_NAME
---------------- ------------------ --------------------
P199504                           1 LOW_END
P199507                           2 LOW_END
........................................................
P200310                          35 LOW_END    <===5年以上経過
P200401                          36 MID_RNG
........................................................
P200510                          43 MID_RNG     ALTER TABLE TMINT02 DROP PARTITION P199504;

▼ おわりに

パーティショニングオプションという別途ライセンス費用が発生する機能の
検証をあえて選んでみたのですが、いかがだったでしょうか？

第1回でご紹介したように、今までのレンジ・パーティションではパーティ
ションを人間が手動で追加しなければなりませんでした。

パーティション追加というのは決して難しい作業ではありません。だからこ
そスペシャリストとしてのDBAは、このような単純な作業から解放され、もっと
創造的な仕事をすべきだと思い、インターバル・パーティションを取り上げま
した。

パーティションに関しては、パーティション索引等まだまだ検証ネタとして
面白い材料は多いのですが、インターバル・パーティションに関する検証はこ
れで終わりです。

来週から「フラッシュバック・データ・アーカイブ」に関する検証が始ま
ります。

最近朝晩めっきり寒くなった
恵比寿より

Oracle 11g インターバル・パーティションに関する検証 その８

Oracle 11g　インターバル・パーティションに関する検証　その８