oracle partitioningの能力を最大限に活用する...•...

Copyright © 2016, Oracle and/or its affiliates.All rights reserved.|

Oracle Partitioningの能力を最大限に活用する

実践ガイドとリファレンス

バージョン5.0


始める前に...• ご意見をお寄せください

–まだ実現していないアイディアや課題も多数あります

–お寄せいただいたご意見で方向性が決まります

• 次のような情報を求めています

–興味深いユースケースや実装

–拡張の要望

–不満な点

– [email protected]または[email protected]までお送りください

mailto:[email protected]

mailto:[email protected]


• 12.2の新機能

• パーティション化の要約

• パーティション化の利点

• パーティション化の概要

• パーティション化方法

– レンジ・パーティション化

– ハッシュ・パーティション化

– リスト・パーティション化

– インターバル・パーティション化

– レンジとインターバル

– 参照パーティション化

– インターバル参照パーティション化

– バーチャル・カラム・パーティション化

• パーティション化方法

– コンポジット・パーティション化

– 複数列レンジ・パーティション化

– レンジ・パーティション化されたハッシュ・クラスタ

• パーティション表の索引付け

– ローカル索引

– グローバル非パーティション索引

– グローバル・パーティション索引

– 一意制約と主キーの索引付け

– 部分索引

– 使用禁止索引と部分索引

• パフォーマンス向上のためのパーティション化

• パーティションのメンテナンス

– 複数パーティションでのメンテナンス

– 参照パーティション化のためのカスケード切捨てとカスケード交換

– パーティションのオンライン移動

– 非同期グローバル索引メンテナンス

• パーティション化の統計管理

• 属性クラスタリング/ゾーン・マップ

• ヒントとコツ

– パーティション化の戦略について

– 物理属性と論理属性

– ホット・スポットの除外

– スマートな部分交換

– PKおよびUKとの交換

目次


Oracle Database 12c Release 2の新機能


• 新しい中核機能

–自動リスト・パーティション化

–複数列リスト・パーティション化

–パーティション外部表

• 新規のパフォーマンス機能– オンライン・パーティション・メンテナンス操作

– パーティション表へのオンライン表変換

– DDLによるカーソル無効化の減少

• 新規の管理性機能

– フィルタ付きパーティション・メンテナンス操作

– 読取り専用パーティション

– 交換用の表の作成

12.2の新機能


新しい中核機能


自動リスト・パーティション化


自動リスト・パーティション化

• データを受け取ると自動的にパーティションが作成されます–リスト・パーティション化の拡張機能

–別個のパーティション・キー値はすべて別々のパーティションに格納されます

BMW Mercedes PorscheBMW MercedesBMW


自動リスト戦略の詳細

• パーティションあたり1つの値を含む新しいリスト・パーティションを自動的に作成します

– 12.2.0.1では最上位レベルのパーティション化戦略としてのみ利用可能

• DEFAULTパーティションの概念はありません

• 自動作成されたパーティションのパーティション名はシステムが生成します– [サブ]パーティション識別の確定にはFOR VALUES句を使用します

• リスト・パーティション化を自動リスト・パーティション化に進化させられます

–要件はDEFAULTパーティションがないことのみ

–投資費用の保護


構文例

自動リスト・パーティション表

CREATE TABLE sales ( brand VARCHAR2(50),model VARCHAR2(50), …)

PARTITION BY LIST (brand) AUTOMATIC( partition p1 values (‘BMW’));


自動リストはリスト+ DEFAULTとは異なる

• 異なるユースケース・シナリオ

• DEFAULTパーティション化を含むリスト

– “ノイズ”を含む複数の大規模な個別リスト値向け

• 自動リスト・パーティション化–パーティション・キー値ごとに‘記録のクリティカルマス’があると想定

–リスト+ DEFAULTを使用するための先行状態として使用できます


自動リストはリスト+ DEFAULTとは異なる• 異なるユースケース・シナリオ

• DEFAULTパーティション化を含むリスト

– “ノイズ”を含む複数の大規模な個別リスト値向け

• 自動リスト・パーティション化–値ごとに‘記録のクリティカルマス’があると想定

–リスト+ DEFAULTを使用するための先行状態として使用できます

• ..さらに、2つのパーティション化は機能が競合していて併用できません–新しいパーティション・キー値に対して新しいパーティションを取得するか

– ..あるいは、一つにまとめて“ダンプ”します


複数列リスト・パーティション化



• データは複数値のリスト（複数列）で整理されています–個々のパーティションには複数値のセットを含むことができます

–DEFAULTパーティションの機能（未指定値を一つにまとめる）

• たとえば（リージョン、チャネル）など、個別の値ペアのセグメント化に最適です

…(USA, Direct)

(USA, Partners)

((JAPAN, Partners),(JAPAN, Web)) DEFAULT(GERMANY

, Direct)


複数列リスト戦略の詳細

• パーティション化キーとして複数列を指定できます

–最大16個のパーティション・キー列

–パーティション化キーの各セットは一意である必要があります

• 1つのみのDEFAULTパーティション

• 機能のサポート

–パーティションおよびサブパーティションの戦略としてサポート

–ヒープ表のサポート

–外部表のサポート

–参照パーティション化および自動リスト・パーティション化でサポート


構文例

複数列リスト・パーティション表

CREATE TABLE sales ( region VARCHAR2(50),channel VARCHAR2(50), …)

PARTITION BY LIST (region, channel)( partition p1 values (‘USA’,’Direct’),partition p2 values (‘USA’,’Partners’),partition p3 values (‘GERMANY’,’Direct’),

… partition p44 values ((‘JAPAN’,’Partners’),

(‘JAPAN’,’Web’)),partition p45 values (DEFAULT)

);



• (USA, Partners)はどこに格納するか

列ごとにDEFAULTが存在する場合はどうするか

…(USA, Direct)

(Germany, Direct)

(USA, DEFAULT)

(DEFAULT, Partners)



• (USA, Partners)はどこに格納するか

–唯一のDEFAULTパーティション内

列ごとにDEFAULTが存在する場合はどうするか

…(USA, Direct)

(Germany, Direct) (DEFAULT)


• リスト–リスト・パーティション化

–ほぼ同等

–キーとしては2つの列だけ使用可能（2レベル）

–概念上は対称

12.2より前の複数列リスト・パーティション化

…JUL 2016 AUG 2016 SEP 2016 JAN 2015 FEB 2015

…EMEA

USA


• リスト–リスト・パーティション化

–ほぼ同等

–キーとしては2つの列だけ使用可能（2レベル）

–概念上は対称

• 複数列レンジ・パーティション化

–同等ではない

–一致する場合のみ条件を階層的に評価

12.2より前の複数列リスト・パーティション化


…EMEA

USA

YEAR値は境界より小さいか

YEAR値は境界と等しいか

パーティションの評価

次のパーティションへ

insert

MONTH値は境界より小さいか

いいえ

はい

はい

いいえ

いいえはい


パーティション外部表


パーティション外部表

• 外部表はあらゆるパーティション化手法を使用してパーティション化できます

–複数列パーティション化は、パーティション化されたHIVE表に最適です

• パーティション・プルーニングと限られたパーティションのメンテナンス

–パーティションの追加、パーティションの削除、パーティションの名前変更だけをサポート

…USA, Direct USA, Partners JAPAN,

Partners DEFAULTGERMANY, Direct

HIVEパーティション HIVEパーティション HIVEパーティション HIVEパーティションHIVEパーティション


新規のパフォーマンス機能


オンライン・パーティション・メンテナンス操作


追加のオンラインDDL機能

• ALTER TABLE MODIFY（非パーティション表をパーティション表に）

• ALTER TABLE MOVE ONLINE（ヒープ表の場合）

• ALTER TABLE SPLIT PATITION ONLINE

12.2


パーティション表へのオンライン表変換


オンライン表変換

SALES SALES

• 完全ノンブロッキング（オンライン）DDL

USA GERMANY

JAPAN DEFAULT


オンライン表変換構文例

CREATE TABLE sales ( order_num NUMBER, region VARCHAR2 (10), … );

ALTER TABLE sales MODIFY PARTITION BY LIST (region)(partition p1 values (‘USA’),partition p2 values (‘Germany’),partition p3 values (‘Japan’),partition p4 values (DEFAULT))

UPDATE INDEXES ONLINE;


オンライン表変換

• 索引は変換プロセスを通じてオンラインに保持して変換されます

• 索引には大きな柔軟性（さまざまなルールに従う）

• アクセス変更動作を最小限に抑えるためのデフォルトの索引付けルール

–グローバル・パーティション索引は、元のパーティション形態を保持します。

–非同一キー索引は、グローバル非パーティション索引になります。

–同一キー索引は、ローカル・パーティション索引に変換されます。

–ビットマップ索引は、ローカル・パーティション索引になります。

索引付け


DDLのカーソル無効化の減少


DDLによるカーソル無効化の減少

• DDLが引き起こすハード解析の数を減少させます– ハード解析が避けられない場合、ワークロードを経時的に分散します

• 一部のDDL用の新しいオプション句“[DEFERRED | IMMEDIATE] INVALIDATION” – DEFERREDの場合、可能なときは依存性カーソルの無効化を回避します

– IMMEDIATEの場合、依存性カーソルを即座に無効化します

– どちらでもない場合、CURSOR_INVALIDATIONパラメータがデフォルト動作を制御します

• サポートされるDDL：– CREATE INDEX、DROP INDEX、ALTER INDEX– AlTLER TABLE（列の操作）

– AlTLER TABLE（セグメントの操作）

– TRUNCATE TABLE


DDLによるカーソル無効化の減少構文例

DROP INDEX emp_index DEFERRED INVALIDATION;


新規の管理性機能


フィルタ付きパーティション・メンテナンス操作



• フィルタ条件を追加して特定のデータのみを選択できます

• データのメンテナンスをパーティションのメンテナンスと組み合わせます

パーティションの移動例

ORDERS

ORDERS

Q3_2015

表領域：アクティブ

表領域：アーカイブ

Q3_2015


フィルタ付きパーティション・メンテナンス操作の詳細

• MOVE、SPLITおよびMERGE操作に単一表のフィルタ条件を指定できます

–指定は、すべてのパーティションのメンテナンス全体で一貫している必要があります

–指定では、対象データを明確に指定する必要があります

• 指定は再帰的に生成されたCTASコマンドに追加され、さまざまな新しいパーティションまたはサブパーティション・セグメントを作成します

• フィルタ条件は、オフラインおよび新しいオンラインのパーティション・メンテナンス操作（PMOP）の両方に対して動作します


パーティションの移動の構文例


ALTER TABLE orders MOVE PARTITION q3_2015 TABLESPACE archiveINCLUDING ROWS WHERE order_state = ‘open’;


フィルタ付きパーティション・メンテナンス操作パーティションの移動の構文例

ALTER TABLE orders MOVE PARTITION q3_2015 TABLESPACE archiveINCLUDING ROWS WHERE order_state = ‘open’;

..オンラインの場合はどうなるでしょうか


オンライン動作時の場合のDML動作


• フィルタ条件は、進行中の同時DMLには適用されません

INCLUDING ROWS WHERE order_state = ‘open’


フィルタ付きパーティション・メンテナンス操作オンライン動作時の場合のDML動作

• 挿入は、常に実行されます



INSERT VALUES(order_state =‘closed’)




• 含まれているデータに対する削除は、常に実行されます

• 削除されたデータに対する削除は無効です



DELETE WHERE order_state = ‘open’

DELETE WHERE order_state = ‘closed’





• 含まれているデータに対する削除は、常に実行されます

• 削除されたデータに対する削除は無効です

• 含まれているデータに対する更新は常に実行されます

• 除外されたデータに対する更新は無効です



DELETE WHERE order_state = ‘open’

DELETE WHERE order_state = ‘closed’

UPDATE set order_status = ‘closed’WHERE order_state = ‘open’

UPDATE set order_status = ‘open’WHERE order_state = ‘closed’



読取り専用パーティション



• パーティションとサブパーティションは、読取り専用または読取り/書込みに設定できます

• 読取り専用パーティションでデータを変更しようとするとエラーが発生します

• ユーザーまたはトリガーによる意図しないDMLからデータを保護するのに最適

…Q1 2015 Q2 2015 Q3 2015 Q4 2015

読取り専用読取り専用読取り専用読取り/書込み

insert

ブロックされたDML操作許可された

DML操作

modify delete insert


読取り専用パーティションの詳細

• 読取り専用属性は、データの不変性を保証します

– 表または[サブ]パーティションが読取り専用に設定されると、“SELECT <column_list> FROM <table>”は常に同じデータセットを戻します

• 指定しない場合、各パーティションおよびサブパーティションは最上位レベルの親から読取り専用プロパティを継承します

– 下位レベルの読取り専用プロパティを変更すると、上位レベルのプロパティをオーバーライドします

– 表領域変更はもっとも高い優先順位を持っていて、上書きできません

• データの不変性が表のすべてのDDLを不可能にするわけではありません

– ADDおよびMODIFY COLUMNは許可されており、既存データのデータ不変性に違反しません

– DROP/RENAME/SET UNUSED COLUMNなどは禁止されています

– DROP PARTITIONも禁止です。表のデータ不変性に違反します



CREATE TABLE orders ( order_id number, order_date DATE, … ) read only

PARTITION BY RANGE(order_date)( partition q1_2015 values less than (‘2016-10-01’),partition q2_2015 values less than (‘2015-01-01’), partition q3_2015 values less than (‘2015-04-01’),partition q4_2015 values less than (‘2015-07-01’) read write

);


読取り専用表領域と読取り専用パーティション読取り専用パーティションはOracle Database 12c Release 2で導入


TS1 TS2 TS3 TS4

読取り専用表領域とパーティション

• パーティションとサブパーティションは、読取り専用表領域に配置できます

• 読取り専用表領域でデータを変更しようとするとエラーが発生します

…Q1 2015 Q2 2015 Q3 2015 Q4 2015


insert

ブロックされたDML操作許可されたDML操作




• パーティションとサブパーティションは、読取り専用または読取り/書込みに設定できます

• 読取り専用パーティションでデータを変更しようとするとエラーが発生します

TS1

…Q1 2015 Q2 2015 Q3 2015 Q4 2015


insert

ブロックされたDML操作許可されたDML操作



読取り専用オブジェクトと読取り専用表領域

• 読取り専用表領域は、物理ストレージを更新から保護します

–格納に影響しないDDL操作は許可されます• たとえば、ALTER TABLE SET UNUSED、DROP TABLE

–データ不変性は保証されません

• 読取り専用オブジェクトは、データを更新から保護します

– ‘データの不変性’–データの中身に影響しない変更は禁止されません

• たとえば、ALTER TABLE MOVE COMPRESS、ALTER TABLE MERGE PARTITIONS



• 読取り専用属性は、データの不変性を保証します

– 表または[サブ]パーティションが読取り専用に設定されると、“SELECT <column_list> FROM <table>”は常に同じデータセットを戻します

• データの不変性が表のすべてのDDLを不可能にするわけではありません– ADDおよびMODIFY COLUMNは許可されており、既存データのデータ不変性に違反しません

– DROP/RENAME/SET UNUSED COLUMNなどは禁止されています

– DROP PARTITIONも禁止です。表のデータ不変性に違反します


交換用の表の作成


交換用の表の作成

• 単純なDDLコマンド

• パーティション交換コマンドが常に成功するように、セマンティックおよび内部的な表形態の同一性が保証されます

• 特別なCREATE TABLE AS SELECT操作のように動作します

• 常に空の表を作成します


交換用の表の作成構文例

CREATE TABLE emp_ex TABLESPACE sysauxFOR EXCHANGE WITH TABLE emp;


パーティション化の要約


Oracle Partitioningとは

オブジェクトをより小さな部分に論理的に分割する強力な機能

高パフォーマンスや高可用性を必要とする大規模データベースのキー要件

業務要件ごとに作動


Oracle Partitioningを使用する理由

パフォーマンス - データ・アクセス時間を短縮

可用性 - 重要情報へのアクセスを改善

コスト - 複数のストレージ層を活用

実装が容易 - アプリケーションや問合せの変更不要

成熟した機能 - 幅広いパーティション化方法をサポート

高い評価 - 何千もの顧客が使用


パーティション化と2人のユーザー

SALES

JAN

FEB

EMEA APAC

SELECT * FROM SALES;

MOVE PARTITION COMPRESS READ ONLY;


パーティション化のしくみ大規模なデータベースや索引を、より小規模で扱いやすい部分に分割できます

課題：大規模な表は管理が困難

解決方法：パーティション化• 分割して管理• データ管理が容易• パフォーマンスが向上

SALES SALES

JAN

FEB

EMEA APAC

JAN

FEB

SALES


パーティション化の利点


パフォーマンスの向上

パーティション化すると、次のようなデータ管理操作が

• データのロード、結合およびプルーニング、

• 索引の作成と再構築

• バックアップおよびリカバリ

関連するデータに対してのみ動作

結果：パフォーマンスが桁違いに向上

表全体でなくパーティション・レベルで可能になります


パフォーマンスの向上 - 例

• パーティション・エリミネーション（除外）

–ストレージから取得するデータ量を激減させます

–関連するパーティション上でのみ操作を実行します

–問合せのパフォーマンスを透過的に向上させ、リソース使用状況を最適化します

パーティション・プルーニング

5月1～2日の総売上は?

SALES5月5日

5月4日

5月3日

5月2日

5月1日

4月30日

4月29日


パフォーマンスの向上 - 例パーティション・ワイズ結合

… …MAR APRFEBJAN

JAN

• 大規模結合は複数の小規模結合に分割され、並行して実行されます

–結合するパーティション数は、DOPの倍数である必要があります

–両方の表が、結合列上で同じ方法でパーティション化されている必要があります

CUSTOMER

hash 1

hash 2

hash 3

hash 4

hash1

CUSTOMERFEB MAR APR

hash 1

hash 2

hash 3

hash 4

hash 1


コスト削減

パーティション化は、次の項目間にバランスをもたらし

• データの重要性、

• ストレージ・パフォーマンス、

• ストレージの信頼性、

• ストレージの形式

データを最適な方法で格納

結果：ストレージ・コストを2倍以上削減

複数のストレージ層が活用可能になります


ハイエンド・ストレージ層

コスト削減 - 例階層型ストレージ用パーティション

ローエンド・ストレージ層TBあたり2～3倍の削減

2009 2012 2015

5%アクティブ95%非アクティブ

… …


可用性の向上

パーティション化により削減されるもの

• メンテナンス期間

• 定期的な停止時間や障害による影響、

• リカバリ時間

個々のパーティションの管理性

結果：重要情報へのアクセスを改善

重要な表および索引がパーティション化されている場合


可用性の向上 - 例管理性/可用性を高めるためのパーティション

他のパーティションを表示、使用可能

Q2’14 Q3’14 Q4’14Q1’14


実装が容易

• パーティション化に、アプリケーションや問合せの変更は不要

–パーティション化の利点をフル活用するための調整が必要になることがあります

アプリケーションに対して透過的


成熟した定評ある機能

• 何万もの顧客が使用

• 幅広いパーティション化方法をサポート

10年以上の開発史


Oracle Partitioning中核機能パフォーマンス管理性

Oracle 8.0 レンジ・パーティション化

ローカルおよびグローバルのレンジ索引

静的パーティション・プルーニング基本メンテナンス：ADD、DROP、EXCHANGE

Oracle 8i ハッシュ・パーティション化レンジ-ハッシュ・パーティション化

パーティション・ワイズ結合動的パーティション・プルーニング

拡張メンテナンス：MERGE

Oracle 9i リスト・パーティション化グローバル索引のメンテナンス

Oracle 9i R2 レンジ-リスト・パーティション化高速パーティションSPLIT

Oracle 10g グローバル・ハッシュ索引ローカル索引のメンテナンス

Oracle 10g R2 表あたり1Mのパーティション複数ディメンション・プルーニング高速DROP TABLE

Oracle 11g バーチャル・カラム・パーティション化多くの種類のコンポジット・パーティション参照パーティション化

インターバル・パーティション化Partition Advisor増分統計管理

Oracle 11g R2 ハッシュ-*パーティション化拡張参照パーティション化

“AND”プルーニング複数ブランチの実行（表拡張とも呼ばれる）

Oracle 12c R1 インターバル-参照パーティション化複数パーティションでのパーティションのメンテナンス非同期グローバル索引のメンテナンスゾーン・マップ

オンライン・パーティションMOVETRUNCATEとEXCHANGEのカスケード部分索引

Oracle 12c R2 自動リスト・パーティション化複数列リスト・パーティション化パーティション外部表

オンライン・パーティション・メンテナンス操作パーティション表へのオンライン表変換DDLによるカーソル無効化の減少

フィルタ付きパーティション・メンテナンス操作読取り専用パーティション交換用の表の作成

10年以上の開発と改善の歴史


パーティション化の概要


定義：パーティション

– “Miriam Webster Dictionary”

（何かを）部分に分割すること


物理パーティション化

• 基本的なシステム・セットアップ要件

– ノードがDBの一部を所有

– 並列処理を有効化

• パーティションの数は必要最小限の並列度と同等

– 常にハッシュまたはランダムな分散が必要

• 適切なロードバランシングには、ノードごとに等サイズ設定されたパーティションが必要

シェアード・ナッシング・アーキテクチャ


論理パーティション化

• 根本的に制約がありません

– SMPも、MPPも、クラスタも、グリッドも可能

• ビジネス要件に基づきます

–可用性、管理性、パフォーマンス

• すべての環境で有効

–もっとも包括的な機能を提供

シェアード・エブリシング・アーキテクチャ - Oracle


パーティション化方法


パーティション化の対象

• 表–ヒープ表

–索引構成表

• 索引

–グローバル索引

–ローカル索引

• マテリアライズド・ビュー

• ハッシュ・クラスタ

グローバル・パーティション索引

ローカル・パーティション索引

グローバル非パーティション索引


レンジ・パーティション化Oracle 8.0で導入


レンジ・パーティション化

• データはレンジで整理されています–下限は、前のパーティションの上限によって導出されます

–ギャップはありません

• 時系列データに最適



ハッシュ・パーティション化Oracle 8i（8.1）で導入


ハッシュ・パーティション化

• データはパーティション・キーのハッシュ値に基づいて配置されます

–ハッシュ・バケットの数はパーティションの数と同じです

• 均等にデータ分散するのに最適–均等にデータ分散するには、パーティション数は2の累乗にしてください

キー値

ハッシュ関数


リスト・パーティション化Oracle 9i（9.0）で導入


リスト・パーティション化

• データは値リストで整理されています–リストあたり1つ以上の、順序付けられていない別個の値

–DEFAULTパーティションの機能（未指定値を一つにまとめる）

• リージョンなど、個別の値のセグメント化に最適です

…USA GERMANY JAPAN DEFAULTFRANCE


インターバル・パーティション化Oracle 11g Release 1（11.1）で導入


インターバル・パーティション化

• レンジ・パーティションの拡張機能

• 等間隔レンジ・パーティションの完全自動化

• パーティションはメタデータ情報としてのみ作成されます

–開始パーティションは永続化されます

• 新しいデータを受け取るとすぐにセグメントが割り当てられます–新しいパーティションを作成する必要がありません

–ローカル索引も作成、メンテナンスされます

パーティション管理は一切必要ありません



• データを受け取ると自動的にパーティションが作成されます–レンジ・パーティション化の拡張機能

JAN 2017 FEB 2017 MAR 2017JAN 2015 FEB 2015JAN 2015


インターバル・パーティション化非常に簡単…

最初のパーティションが作成されます

CREATE TABLE sales (order_date DATE, ...)PARTITON BY RANGE (order_date)INTERVAL(NUMTOYMINTERVAL(1,'month')(PARTITION p_first VALUES LESS THAN ('01-JAN-2013');

JAN 2016 ... ... ...



JAN 2016 ... ... ...

他のパーティションは、表メタデータ内にのみ存在します



新しいパーティションは自動的に

インスタンス化されます

INSERT INTO sales (order_date DATE, ...)VALUES (’30-MAR-2013',...);

JAN 2016 ... ... ...MAR 2016



新しいパーティションのデータを受け取り次第

INSERT INTO sales (order_date DATE, ...)VALUES (’04-FEB-2017',...);

JAN 2016 ... ... ...MAR 2016 FEB 2017



• レンジ・パーティション表をインターバル・パーティション表に拡張できます

–簡単なメタデータ・コマンド

–投資の保護

... Q1 2016 Q3 2016Q2 2016 Q4 2016 ...JAN 2017 FEB 2017

新しい月次のインターバル・パーティション

古いレンジ・パーティション表

ALTER TABLE sales SET INTERVAL(NUMTOYMINTERVAL(1,'month');



• インターバル・パーティション表には、旧来のレンジ・セクションと自動化されたインターバル・セクションがあります

–自動化された新しいパーティション管理と完全なパーティションのメンテナンス機能:“いいとこ取り”

... 2015 Q2 2016Q1 2016 Q3 2016 ...

自動化されたインターバル・パーティション・セクション

旧来のレンジ・パーティション・セクション

Q4 2016 Q2 2015



1. ILM用の古いパーティションをマージおよび移動します

...


Q4 2016 Q2 2015


2015 Q2 2016Q1 2016 Q3 2016...



1. ILM用の古いパーティションをマージおよび移動します

2. 新しいデータを挿入します–自動パーティション・インスタンス化

... 2015 Q2 2016Q1 2016 Q3 2016 ...



Q4 2016

Values (‘13-JAN-2017’)

Q1 2017



–パーティションの最大数はあらかじめ100万に固定されています• 明示的に定義されたパーティションとインターバル・ベースのパーティション

–データのないパーティションにはセグメントが割り当てられません• 新しいレコードの挿入によりセグメント作成がトリガーされます

–絶えず増大する表に最適

遅延セグメント作成による“標準”パーティション化

–明示的に定義されたパーティションのみが存在します• 新しいパーティションはDDLによって追加されます

–データのないパーティションにはセグメントが割り当てられません• 新しいレコードを挿入して、データがあらかじめ定義されたパーティションに適合する場合、セグメント作成がトリガーされます

–移入済データの少ない事前定義表に最適

遅延セグメント作成とインターバル・パーティション化


レンジとインターバルの相違点



• 等間隔レンジ・パーティションの完全自動化

• パーティションはメタデータ情報としてのみ作成されます

–開始パーティションは永続化されます

• 新しいデータを受け取るとすぐにセグメントが割り当てられます–新しいパーティションを作成する必要がありません

–ローカル索引も作成、メンテナンスされます

• インターバル・パーティション化は、レンジ・パーティション化への透過的な拡張とほぼ同じです

– ..しかし、インターバル実装にはいくつかの微妙な相違点があります


パーティション・バウンド

–インターバル・パーティションには下限と上限があります• 上限が無限（MAXVALUES）ということはありません

–レンジ・パーティションには上限のみあります• 下限は前のパーティションにより導出されます

• 上限を無限（MAXVALUES）にできます

パーティションの命名

–インターバル・パーティションには事前に名前を指定できません• PARTITION FOR (<value>)句を使用します

–レンジ・パーティションは名前を指定する必要があります

インターバル・パーティション化とレンジ・パーティション化


インターバル・パーティション化とレンジ・パーティション化（続き）

• パーティション・マージ

–存在しない複数のインターバル・パーティションは告知なくマージされます

–レンジ・パーティションは、隣接した2つのみ、任意の時点でマージできます

• パーティションの数

–インターバル・パーティション表は、常に100万のパーティションを持ちます• 存在しないパーティションは、INTERVAL句を介して“存在”させられます

• インターバル・パーティション化にはMAXVALUE句はありません

– 最大値は、パーティション数とINTERVAL句によって定義されます

–レンジ・パーティションでは、最大で100万のパーティションを持てます• MAXVALUE句が一番上のパーティションを定義します



• パーティションには上限のみあります• 下限は、前のパーティションの上限によって導出されます

レンジ・パーティション化のパーティション・バウンド

OCT 2016 NOV 2016 DEC 2016 JAN 2017 FEB 2017

values less than (’01-FEB-2017’) values less than (‘01-JAN-2017’)


インターバル・パーティション化とレンジ・パーティション化レンジ・パーティション化のパーティション・バウンド

OCT 2016 NOV 2016 DEC 2016 FEB 2017

values less than (’01-MAR-2017’) values less than (‘01-JAN-2017’)

• 前のパーティションが削除されると下限が移動します–“FEB 2017”は01-JAN-2017から28-FEB-2017までを生成することになります



• パーティションには上限と下限があります– INTERVAL関数と最後のレンジ・パーティションによって導出されます

インターバル・パーティション化のパーティション・バウンド

OCT 2016 NOV 2016 JAN 2017 FEB 2017

values less than (’01-DEC-2016’)

less than (’01-DEC-2016’ + 2 x INTERVAL (1 MONTH))




• 削除してもパーティションの境界には影響しません–“FEB 2017”は変わらず01-FEB-2017から28-FEB-2017までを生成します

インターバル・パーティション化のパーティション・バウンド

OCT 2016 NOV 2016 FEB 2017

values less than (’01-DEC-2016’)





• レンジ・パーティションには名前を指定できます– 指定しない場合、システムが名前を生成します

• インターバル・パーティションには名前を指定できません– 常にシステムが名前を生成します

• 新しく設定するのにPARTITION FOR ()拡張機能を使用します

パーティションの命名

SQL> alter table t add partition values less than(20);Table altered.SQL> alter table t add partition P30 values less than(30);Table altered.

SQL> alter table t add partition values less than(20);*

ERROR at line 1:ORA-14760:ADD PARTITION is not permitted on Interval partitioned objects

SQL> alter table t1 rename partition for (9) to p_10;Table altered.


インターバル・パーティション化とレンジ・パーティション化パーティション・マージ – レンジ・パーティション化

SEP 2016 OCT 2016 JAN 2017

• レンジ・パーティション化では隣接した2つのパーティションがマージされます–上位のパーティションの上限が新しい上限になります

–下限は、前のパーティションの上限によって導出されます

MERGE PARTITIONS NOV_2016, DEC_2016 INTO PARTITION NOV_DEC_2016

DEC 2016NOV 2016


インターバル・パーティション化とレンジ・パーティション化パーティション・マージ – レンジ・パーティション化

SEP 2016 OCT 2016 JAN 2017

• マージされたパーティションに対して新しいセグメントが作成されます–表の残りの部分には影響ありません


NOV_DEC_2016


インターバル・パーティション化とレンジ・パーティション化パーティション・マージ – インターバル・パーティション化

OCT 2016 JAN 2017

• インターバル・パーティション化では隣接した2つのパーティションがマージされます–上位のパーティションの上限が新しい上限になります

–下限は、最初のパーティションの下限によって導出されます


NOV 2016 DEC 2015


インターバル・パーティション化とレンジ・パーティション化パーティション・マージ – インターバル・パーティション化

JAN 2017

• マージされたパーティションに対して新しいセグメントが非インターバルとして作成されます–マージされたパーティションの前の空間も、告知なく“マージ”されます

• インターバルは、もっとも上位の非インターバル・パーティションより高いレベルでのみ有効です


OCT 2016 NOV_DEC_2016


参照パーティション化Oracle 11g Release 1（11.1）で導入


参照パーティション化パーティション化戦略を継承

ORDERS

BACK ORDERS

STOCK HOLDS LINE ITEMS

PICK LISTS

ORDERSを日付でパーティ

ション化

ORDERS

BACK ORDERS


PICK LISTS

ORDERS

BACK ORDERS


PICK LISTS

ORDERS

BACK ORDERS


PICK LISTS

ORDERS

BACK ORDERS


PICK LISTS

JAN FEB

MAR APR


ビジネス上の問題

• 同じパーティション化戦略からの関連した表の利点– サンプル（第3正規形）注文入力データ・モデル

• 同じ情報の冗長格納による問題を解決– データとメンテナンスのオーバーヘッド

解決方法

• 参照パーティション化はOracle Database 11gで導入– 子表はPK-FKを介して親表のパーティション化戦略を継承します

– 直観的なモデリング

• パフォーマンスと管理性の向上

参照パーティション化


参照パーティション化がない場合

ORDERS

…

LINE_ITEMS

…

RANGE(order_date)Primary key order_id

RANGE(order_date)Foreign key order_id

• 冗長格納• 冗長メンテナンス

SEP 2016 OCT 2016 NOV 2016 FEB 2017

FEB 2017NOV 2016OCT 2016SEP 2016


参照パーティション化がある場合

ORDERS

…

LINE_ITEMS

…

RANGE(order_date)Primary key order_id

RANGE(order_date)Foreign key order_id

• パーティション化キーの継承はPK-FKリレーションシップによる

SEP 2016 OCT 2016 NOV 2016 FEB 2017

FEB 2017NOV 2016OCT 2016SEP 2016



• 従来のリレーション・モデル

–主キーは子のすべてのレベルまで下に継承され、主キー定義の一部になります

• オブジェクト指向型モデル

–複数レベルの主-外部キー・リレーションシップ

–各レベルでの主キーは、主キー+“オブジェクトID”です

• 参照パーティション化はどちらのモデル化手法にも最適になっています

ユースケース


リレーション・モデル “オブジェクト型”モデル


親PK：(親キー)

子FK：(外部キー)

PK：(親キー、子キー)

孫FK：(親キー、子キー)

PK：(親キー、子キー、孫キー)

親PK：(親キー)

子FK：(外部キー)

PK：(親キー、子キー)

孫FK：(親キー、子キー)

FK：(親キー)PK：(親キー、孫キー)


参照パーティション化例

create table project (project_id number not null, project_number varchar2(30), project_name varchar2(30), …constraint proj_pk primary key (project_id))

partition by list (project_id)(partition p1 values (1),partition p2 values (2),partition pd values (DEFAULT));

create table project_customer (project_cust_id number not null,project_id number not null,cust_name varchar2(30),constraint pk_proj_cust primary key

(project_id, project_cust_id),constraint proj_cust_proj_fk foreign key

(project_id) references project(project_id))partition by reference (proj_cust_proj_fk);


参照パーティション化例（続き）

create table proj_cust_address (project_cust_addr_id number not null,project_cust_id number not null,project_id number not null,cust_address varchar2(30),constraint pk_proj_cust_addr primary key

(project_id, project_cust_addr_id),constraint proj_c_addr_proj_cust_fk foreign key

(project_id, project_cust_id) references project_customer

(project_id, project_cust_id))partition by reference (proj_c_addr_proj_cust_fk);


参照パーティション化メタデータ例

SQL> SELECT table_name, partitioning_type, ref_ptn_constraint_name FROM user_part_tables WHERE table_name IN ('PROJECT','PROJECT_CUSTOMER','PROJ_CUST_ADDRESS');

TABLE_NAME PARTITION REF_PTN_CONSTRAINT_NAME----------------------- --------- ------------------------------PROJECT LISTPROJECT_CUSTOMER REFERENCE PROJ_CUST_PROJ_FKPROJ_CUST_ADDRESS REFERENCE PROJ_C_ADDR_PROJ_FK

表情報

SQL> SELECT table_name, partition_name, high_value FROM user_tab_partitions WHERE table_name in ('PROJECT','PROJECT_CUSTOMER’)ORDER BY table_name, partition_position;

TABLE_NAME PARTITION_NAME HIGH_VALUE----------------------- ------------------- ---------------------------PROJECT P1 1PROJECT P2 2PROJECT PD DEFAULTPROJECT_CUSTOMER P1PROJECT_CUSTOMER P2PROJECT_CUSTOMER PD

パーティション情報


参照パーティション化パーティションのメンテナンス

PROJECT

1 D2

1 D2

1 D2

PROJECT_CUSTOMER

PROJECT_CUST_ADDRESS

ALTER TABLE project SPLIT PARTITION pd VALUES (4,5) INTO (PARTITION pd, PARTITION p45);



• PROJECTのパーティションPDが分割されます

– “Default”と(4,5)

• PROJECT_CUSTOMERは依存パーティションを分割します

– 同等のPROJECTの親レコードと共通位置

– (4,5)の親レコードは(4.5)の子レコードを意味します

• PROJECT_CUST_ADDRESSは依存パーティションを分割します

– 同等のPROJECT_CUSTOMERの親レコードと共通位置

• どちらの配置にも1レベルのルックアップが必要です

パーティションのメンテナンス

PROJECT

1 4,52

1 4,52

1 4,52


D

D

D

PROJECT_CUSTOMER

ALTER TABLE project SPLIT PARTITION pd VALUES (4,5) INTO (PARTITION pd, PARTITION p45);


参照パーティション化パーティションのメンテナンス

PROJECT

1 D2

1 D2

1 D2

PROJECT_CUSTOMER


ALTER TABLE project_cust_address DROP PARTITION pd;

• PROJECTのパーティションPDが削除されます

– PK-FKには違反状態がないことが保証されます

• PROJECT_CUSTOMERは依存パーティションを削除します

• PROJECT_CUST_ADDRESSは依存パーティションを削除します

• “通常の”パーティション表とは異なり、PK-FKリレーションは有効のままです

– PK-FKリレーションのPKを使用してパーティションを任意に削除または切捨てることはできません

• TRUNCATEについても同様です

– ボトムアップ操作


インターバル参照パーティション化Oracle 12c Release 1（12.1）で導入


インターバル-参照パーティション化

JAN 2015 FEB 2015JAN 2015

BACK ORDERS


PICK LISTS

JAN

BACK ORDERS


PICK LISTS

JAN

BACK ORDERS


PICK LISTS

FEB

INSERT INTO orders VALUES (’01-FEB-2015’, ...);

• 新しいデータを受け取ると、新しいパーティションが自動的に作成されます

• すべての子表は自動的にメンテナンスされます

• ビジネス・モデリング改善のための2つの役に立つパーティション化戦略の組合せ



• 新しいデータを受け取ると、新しいパーティションのみが作成されます

–すべての参照ツリーのために自動パーティション・インスタンス化は行われません（子パーティションも新しいデータを受け取ると）

–移入済データの少ない参照パーティション表に最適化されています

• パーティション名は既存のパーティションから継承されます–直接に関係する名前を継承

–親パーティションp100から子パーティションp100が生成されます

–親パーティションp100と子パーティションc100から孫パーティションc100が生成されます


バーチャル・カラム・パーティション化Oracle 11g Release 1（11.1）で導入


バーチャル・カラム・パーティション化

• REGIONは格納を必要としません

• ORDER_DATE、REGIONでパーティション化します

ORDERS

ORDER_ID ORDER_DATE CUSTOMER_ID...REGION AS (SUBSTR(ORDER_ID,6,2))---------- ----------- ----------- -- --------------------------------9834-US-14 12-JAN-2015 65920 US8300-EU-97 14-FEB-2015 39654 EU3886-EU-02 16-JAN-2015 4529 EU2566-US-94 19-JAN-2015 15327 US3699-US-63 02-FEB-2015 18733 US

JAN 2015 FEB 2015

EU

USA


バーチャル・カラム

• すべての属性を持つベース表...

例

CREATE TABLE accounts

(acc_no number(10) not null,

acc_name varchar2(50) not null, …

12500125071266612875

AdamsBlakeKingSmith



• すべての属性を持つベース表......が、バーチャル（導出された）カラムで拡張されます

例

CREATE TABLE accounts (acc_no number(10) not null,acc_name varchar2(50) not null, ...acc_branch number(2) generated always as (to_number(substr(to_char(acc_no),1,2)))

12500125071266612875

AdamsBlakeKingSmith

12121212



• すべての属性を持つベース表......が、バーチャル（導出された）カラムで拡張されます

...バーチャル・カラムはパーティション化キーとして使用されます

例

CREATE TABLE accounts (acc_no number(10) not null,acc_name varchar2(50) not null, ...acc_branch number(2) generated always as (to_number(substr(to_char(acc_no),1,2)))

partition by list (acc_branch) …

12500125071266612875

AdamsBlakeKingSmith

12121212

32320324073275832980

JonesClarkHurdKelly

32323232

…



• 概念モデルは、バーチャル・カラムを、表示および使用できる属性とみなします

• 現在、パーティション・プルーニングは、バーチャル・カラム（パーティション・キー）上の条件のみによって機能します–ベース・カラムの条件では影響しません

–将来的には拡張が予定されています



コンポジット・パーティション化レンジ-ハッシュはOracle 8iで導入レンジ-リストはOracle 9i Release 2で導入[インターバル|レンジ|リスト|ハッシュ]-[レンジ|リスト|ハッシュ] はOracle 11g Release 1|2で導入*ハッシュ-ハッシュは11.2


コンポジット・パーティション化

• データは2つのディメンションに沿って整理されています–レコード配置はディメンションによって明確に識別されます

• 例：レンジ-リスト


…EMEA

USA


コンポジット・パーティション化概要


CREATE TABLE SALES ..PARTITION BY RANGE (time_id)



CREATE TABLE SALES ..PARTITION BY RANGE (time_id)SUPARTITION BY LIST (region)


…EMEA

USA

… … … … …






…EMEA

USA

… … … … …

…メタデータのみ

JUL 2016 AUG 2016 SEP 2016 JAN 2017 FEB 2017

物理セグメント


コンポジット・パーティション化レンジ-リスト



…EMEA

USA

… … … … …


AUG 2016のEMEAデータ


コンポジット・パーティション化リスト-レンジ

CREATE TABLE SALES ..PARTITION BY LIST (region)SUPARTITION BY RANGE (time_id)

…USA EMEA APAC FRANCE UK

…

JUL 2016

… … … … …

…

AUG 2016

USA EMEA APAC FRANCE UK

AUG 2016のEMEAデータ


コンポジット・パーティション化パーティション・プルーニング


…EMEA

USA

… … … … …

…

• パーティション・プルーニングはコンポジットの順序とは関係ありません– 1つまたは両方のディメンションに沿ったプルーニング– レンジ-リストとリスト-レンジに同じプルーニング

WHERE region = ‘EMEA’ AND time_id = ‘Aug 2016’



コンポジット・インターバル・パーティション化

• サブパーティション・テンプレートがない場合、1つのサブパーティションのみが作成されます

– レンジ：MAXVALUE– リスト：DEFAULT– ハッシュ：1つのハッシュ・バケット

パーティションの追加

JAN 2015 FEB 2015 JAN 2017 FEB 2017 MAR 2017


コンポジット・インターバル・パーティション化

• サブパーティション・テンプレートは、将来のサブパーティションの形態を定義します

–任意の時点で追加したり変更したりできます

–既存の[サブ]パーティションへの影響はありません

• サブパーティションの物理属性句も制御します

–パーティションに対するパーティション表のデフォルト設定と同様です

• インターバル・パーティション化とレンジ・パーティション化の相違

–命名テンプレートはレンジのみ（パーティション名_サブパーティション名）

–インターバルでは名前はシステム生成

サブパーティション・テンプレート


コンポジット・パーティション化パーティションの追加

• ADD PARTITIONは常に最上位レベルのディメンション上に–新しく追加されたすべてのサブパーティションで同一

• レンジ-リスト：新しいtime_idレンジ• リスト-レンジ：新しいリージョン値のリスト


…

…

…EMEA

USA

… … … … …

MAR 2017

…

JUL 2016 AUG 2016 SEP 2016 JAN 2017 FEB 2017 MAR 2017


コンポジット・パーティション化サブパーティションの追加

EMEA

USA …JUL 2016 AUG 2016 SEP 2016 JAN 2017 FEB 2017

…… … … … …

…

APAC

• 1つのパーティションのみに対するADD SUBPARTITION– 非対称、サブパーティション・レベル上でのみ可能– パーティション・ワイズ結合に影響



コンポジット・パーティション化サブパーティションの追加

EMEA

USA

APAC

• すべてのパーティションに対するADD SUBPARTITION– N回の操作が必要です（既存の各パーティションに対応）– 将来のパーティションのサブパーティション・テンプレートを調整します


…

…

…




• サブパーティションの数は、個々のパーティションで異なります

–リスト・サブパーティション戦略でもっとも一般的

非対称サブパーティション

E36

E34

E90

JAN 2017 FEB 2017

DEFAULT

CREATE TABLE CARS..PARTITION BY RANGE (time_id)SUPARTITION BY LIST (model)

…… …

…

JAN 2017 FEB 2017



• サブパーティションの数は、個々のパーティションで異なります

–リスト・サブパーティション戦略でもっとも一般的

• パーティション・プルーニング機能への影響はなし

非対称サブパーティション

E36

E34

E90

JAN 2017 FEB 2017

DEFAULT

SELECT ..FROM carsWHERE model = ‘E90’;

…… …

…

JAN 2017 FEB 2017


コンポジット・パーティション化非対称サブパーティション

E36

E34

E90

JAN 2017

DEFAULT


……

FEB 2017

……

MAR 2017

……

JAN 2017 FEB 2017 MAR 2017


コンポジット・パーティション化非対称サブパーティション

E36

E34

E90

JAN 2017

DEFAULT


……

FEB 2017

……

MAR 2017

……

APR 2017

……

JAN 2017 FEB 2017 MAR 2017 APR 2017



• 常に適切なコンポジット戦略を使用します–トップレベルのディメンションは、主に管理性で選択されます

• たとえば、時間範囲の追加や削除

–サブレベルのディメンションは、パフォーマンスや管理性で選択されます• たとえばload_id、customer_id

–非対称には利点もありますが、よく考えてください• たとえば異なるリージョンでの異なる時間粒度

• 非対称コンポジット・パーティション化の影響を忘れないでください


複数列レンジ・パーティション化Oracle 8i（8.1）で導入


複数列レンジ・パーティション化

• パーティション化キーが複数の列で構成され、後続の列は前の列より高い粒度を定義します

–例 (YEAR, MONTH, DAY)– nディメンションのパーティション化ではありません

• 主要な着目点は、パーティション境界の評価方法の相違です

–単純なレンジでは、境界は未満（排他）です

–複数列レンジの境界は、未満または等しいです• 複数列キーの先頭の値（n-1）がパーティションの境界（n-1）に完全に一致する場合のみ、第n番目の列が調査されます

概要


複数列レンジ・パーティション決定ツリーのサンプル (YEAR, MONTH)

YEAR境界値より小さいか

YEAR境界値と等しいか



insert

MONTH境界値より小さいか

いいえ

はい

はい

いいえ

いいえはい


複数列レンジ・パーティション例

YEAR=2016境界値より小

さいか

YEAR=2016境界値と等し

いか



insert

MONTH=1境界値より小

さいか

いいえ

はい

はい

いいえ

いいえはい

(2016, 1)

はい

(YEAR,MONTH)境界値

(2016,1)

(2016,4)

(2016,7)

(2016,10)

(2017,1)

(MAXVALUE,0)

(2013, 12)

(2013, 12)

(2016, 1)


複数列レンジ・パーティション例（続き）


さいか


いか



insert


さいか

いいえ

はい

はい

いいえ

いいえはい

(2016, 1)


(2016,1)

(2016,4)

(2016,7)

(2016,10)

(2017,1)

(MAXVALUE,0)

(2013, 12)

いいえ

はい

いいえ

(2016, 3)

(2016, 4)




さいか


いか



insert


さいか

いいえ

はい

はい

いいえ

いいえはい


(2016,1)

(2016,4)

(2016,7)

(2016,10)

(2017,1)

(MAXVALUE,0)

(2013, 12)

いいえ

はい

(2016, 4)

(2016, 3)

はい

(2016, 3)

(2016, 4)




さいか


いか



insert

MONTH=1値は境界より小さいか

いいえ

はい

はい

いいえ

いいえはい


(2016,1)

(2016,4)

(2016,7)

(2016,10)

(2017,1)

(MAXVALUE,0)

(2013, 12)

はい

(2017, 1)

(2016.5, 33)

(2016, 3)

(2016.5, 33)

(2017, 1)


複数列レンジ・パーティション化

• 3番目（またはそれ以上）のディメンションを追加するための強力なパーティション化機構

–より小さなデータ・パーティション

• プルーニングは、先頭列をフィルタリングしない後続列の条件に対しても機能します（KEY(MC)動的プルーニング）

• 境界は、1つのパーティション定義だけで適用されません（次頁以降参照）

–レンジは連続しています（同じレンジ値が存在するとき）

• 論理的なADDパーティションは、表中へのSPLITパーティションを意味することもあります

いくつかの留意事項


複数列レンジ・パーティション

• 3番目の（数値ではない）ディメンションを導入するために使用される複数列レンジ

わずかに異なる現実のシナリオ

CREATE TABLE product_sales (prod_id number, site_id CHAR(2),start_date date)PARTITION BY RANGE (site_id, start_date)SUBPARTITION BY HASH (prod_id) SUBPARTITIONS 16(PARTITION de_2013 VALUES LESS THAN ('DE',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION de_2016 VALUES LESS THAN ('DE',to_date('01-JAN-2015','dd-mon-yyyy')),PARTITION us_2013 VALUES LESS THAN ('US',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION us_2016 VALUES LESS THAN ('US',to_date('01-JAN-2015','dd-mon-yyyy')),PARTITION za_2013 VALUES LESS THAN ('ZA',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION za_2016 VALUES LESS THAN ('ZA',to_date('01-JAN-2015','dd-mon-yyyy'))

);

文字のSITE_IDを順序付けて定義する必要があります





CREATE TABLE product_sales (prod_id number, site_id CHAR(2),start_date date)PARTITION BY RANGE (site_id, start_date)SUBPARTITION BY HASH (prod_id) SUBPARTITIONS 16(PARTITION de_2013 VALUES LESS THAN ('DE',to_date('01-JAN-2014','dd-mon-yyyy')),(PARTITION de_2013 VALUES LESS THAN ('DE',to_date('01-JAN-2015','dd-mon-yyyy')),PARTITION us_2013 VALUES LESS THAN ('US',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION us_2016 VALUES LESS THAN ('US',to_date('01-JAN-2015','dd-mon-yyyy')),PARTITION za_2013 VALUES LESS THAN ('ZA',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION za_2016 VALUES LESS THAN ('ZA',to_date('01-JAN-2015','dd-mon-yyyy'))

);

定義されていないSITE_IDはLESS THANプローブに従い、常に定義済みSITE_IDのもっとも下位のパーティションで終わります

AC、CNEE、ES、UK

VE、VN





CREATE TABLE product_sales (prod_id number, site_id CHAR(2),start_date date)PARTITION BY RANGE (site_id, start_date)SUBPARTITION BY HASH (prod_id) SUBPARTITIONS 16(PARTITION de_2013 VALUES LESS THAN ('DE',to_date('01-JAN-2014','dd-mon-yyyy')),(PARTITION de_2013 VALUES LESS THAN ('DE',to_date('01-JAN-2015','dd-mon-yyyy')),PARTITION us_2013 VALUES LESS THAN ('US',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION us_2016 VALUES LESS THAN ('US',to_date('01-JAN-2015','dd-mon-yyyy')),PARTITION za_2013 VALUES LESS THAN ('ZA',to_date('01-JAN-2014','dd-mon-yyyy')),PARTITION za_2016 VALUES LESS THAN ('ZA',to_date('01-JAN-2015','dd-mon-yyyy'))

);

将来の日付は、常に次に大きいSITE_IDのもっとも下位のパーティションに入るか、拒否されます

(DE, 2015)(US, 2015)

(ZA, 2015)

?





create table product_sales (prod_id number, site_id CHAR(2),start_date date)partition by range (site_id, start_date)subpartition by hash (prod_id) subpartitions 16(partition below_de values less than ('DE',to_date('01-JAN-1492','dd-mon-yyyy')),partition de_2013 values less than ('DE',to_date('01-JAN-2014','dd-mon-yyyy')),partition de_2016 values less than ('DE',to_date('01-JAN-2015','dd-mon-yyyy')),partition de_max values less than ('DE',MAXVALUE),partition below_us values less than ('US',to_date('01-JAN-1492','dd-mon-yyyy')),…

partition za_max values less than ('ZA',MAXVALUE),partition pmax values less than (MAXVALUE,MAXVALUE));

ダミーの‘BELOW_XX’パーティションを導入して“下位の”定義されていないSITE_IDを捕捉します

AC、CNEE、ES、UK







MAXVALUE 'XX_MAX'パーティションを導入して将来の日付を捕捉します

(DE, 2015) (ZA, 2015)







必要に応じて、境界が無制限のSITE_IDを捕捉します（先頭キー列）


レンジ・パーティション化されたハッシュ・クラスタOracle 12c Release 1（12.1.0.2）で導入


レンジ・パーティション化されたハッシュ・クラスタ

• 単一レベルのレンジ・パーティション化

–コンポジット・パーティション化はできない

–索引クラスタは使用できない

CLUSTERJAN 2016

CLUSTERFEB 2016

CLUSTERMAR 2016

CLUSTERNOV 2016

CLUSTERDEC 2016

…

CLUSTERORDER_ID


パーティション表の索引付け


索引のパーティション化

• グローバル索引は任意のパーティションの行を参照します

– 索引はパーティション化しても、しなくてもかまいません

– パーティション・メンテナンスは索引全体に影響を及ぼします

• ローカル索引は表と同様にパーティション化されます

– 索引パーティション化キーは索引キーと異なることがあります

– 索引パーティションは個別にメンテナンスできます





ローカル索引

• 索引は、データと同じ境界に従ってパーティション化されます

– Bツリーまたはビットマップ

• 長所

–管理が容易

–パラレル索引スキャン

• 短所

–少量のデータを取得するには効率が悪い



• すべてのパーティションにわたる1つの索引Bツリー構造

• 長所

–任意の個別レコードへの効率的アクセス

• 短所

–パーティション・メンテナンスには常に索引メンテナンスが含まれる



• 索引はデータとは関係なくパーティション化されます

–索引構造ごとにすべてのパーティションを参照する場合があります。

• 長所

–可用性と管理性

• 短所

–パーティション・メンテナンスには常に索引メンテナンスが含まれる


一意制約と主キーの索引付け


一意制約/主キー

• 一意索引により一意制約が適用されます

–主キー制約は列にNOT NULLを追加します

–表は主キーを1つのみ持てます（“一意の識別子”）

• パーティション表には、2つのタイプの索引があります


–グローバル索引（パーティションおよび非パーティション）

• どちらを選択すべきか

–そもそも選択可能か



• ローカル索引は、表に対して同一レベル・パーティション化されます–表パーティションの自律性の概念に従います

• “自分のことしか気にしません”

• 一意性を適用するためのローカル索引の要件–パーティション・キー列を一意キーのサブセットにすること

ローカル索引の適用可能性



• ローカル索引は、表に対して同一レベル・パーティション化されます

–表パーティションの自律性の概念に従います• “自分のことしか気にしません”

• 一意性を適用するためのローカル索引の要件

–パーティション・キー列を一意キーのサブセットにすること

ローカル索引の適用可能性（続き）

PARTITION BY (col1), PK(col1) PARTITION BY (col1), PK(col2)



• グローバル索引は、表のパーティションに対してリレーションを何も持ちません

–定義上、グローバル索引は、すべてのパーティションからのデータを含みます

–両方のグローバル索引（パーティションと非パーティション）に当てはまります

• グローバル索引は、常に一意性を適用するために使用できます

グローバル索引の適用可能性

PARTITION BY (col1), PK(col1) PARTITION BY (col1), PK(col2)


部分索引Oracle 12c Release 1（12.1）で導入


Oracle Partitioningでの索引付けの強化

• ローカル索引

• 非パーティションまたはパーティションのグローバル索引

• Usable（使用可能）またはUnusable（使用禁止）の索引セグメント

–非永続ステータスの索引、表へのリレーションなし

Oracle Database 12cより前の索引付け



• ローカル索引

• 非パーティションまたはパーティションのグローバル索引

• Usable（使用可能）またはUnusable（使用禁止）の索引セグメント

–非永続ステータスの索引、表へのリレーションなし

• 部分ローカル索引と部分グローバル索引

–部分索引により、表および[サブ]パーティション・レベルのメタデータが導入されます

–ローカル・パーティション索引のusable/unusable状態を活用できます

–部分索引のポリシーは上書きできます

Oracle Database 12cでの索引付け



• 部分索引は一部のパーティションのみに関わります

• ローカル索引とグローバル索引に適用可能

• 完全索引付けを補完します

• ビジネス・モデリングの強化

部分ローカル索引と部分グローバル索引



部分ローカル・パーティション索引

部分グローバル索引

部分グローバル・パーティション索引


完全索引付け

索引付けなし

索引付けオン

部分索引

索引付けオフ

完全索引付け



変更前

部分ローカル索引と部分グローバル索引

変更後


Oracle Partitioningでの索引付けの強化部分ローカル索引と部分グローバル索引

• パーティション4を除外する部分グローバル索引


使用禁止索引と部分索引


使用禁止索引• 使用禁止索引パーティションは、高速ロード要件がある環境で一般的に使用されます

–データ挿入時の索引メンテナンスのための時間を“節約”します

–使用禁止索引セグメントは、領域を消費しません（11.2）

• 使用禁止索引はオプティマイザによって無視されます

• 一部のパーティションが使用禁止の場合も、オプティマイザによってパーティション索引を使用できます

– 11.2より前は、静的プルーニングと使用可能な索引パーティションのアクセスのみになるが必須

– 11.2では、UNION ALLを使用した問合せのインテリジェント・リライト（表拡張）

SKIP_UNUSABLE_INDEXES = [TRUE | FALSE ]


表拡張

• 部分的に使用禁止索引がある場合のインテリジェントなUNION ALLへの拡張

– 透過的な内部リライト

– 使用可能な索引パーティションが使用されます

– 使用禁止な索引パーティションに対するフル・パーティション・アクセス

複数のSQLブランチが生成、実行されます


表拡張サンプル計画 - 複数のSQLブランチが生成、実行されます


パフォーマンス向上のためのパーティション化



• パフォーマンスを向上させるために、パーティション化が透過的に活用されます

• パーティション・プルーニング

–パーティション化メタデータを使用して対象パーティションにのみアクセスします

• パーティション・ワイズ結合–最小のリソース消費で同一レベル・パーティション表を結合します

– RAC環境の同一インスタンス内での処理

• パーティション交換ロード

–メタデータ操作を使用して新しいデータを“ロード”します



• パーティション・エリミネーション（除外）

–ストレージから取得するデータ量を激減させます

–関連するパーティション上でのみ操作を実行します

–問合せのパフォーマンスを透過的に向上させ、リソース使用状況を最適化します


SALES5月5日

5月4日

5月3日

5月2日

5月1日

4月30日

4月29日

4月28日

4月27日

5月1～2日の総売上は?



• 単純および複雑なSQL文に対して機能します

• いかなるアプリケーションに対しても透過的

• 2種類のプルーニング

–コンパイル時の静的プルーニング

–実行時の動的プルーニング

• Exadata Storage Serverを補完

–パーティション化はパーティション・エリミネーションを介して論理的にプルーニングします

– Exadataはストレージ索引を使用して物理的にプルーニングします• フィルタリングと射影（列の絞り込み）を使用してデータをさらに削減


2TBのユーザー・データ100TBのユーザー・データ 10TBのユーザー・データ

パーティション・プルーニングを使用1/10に圧縮

パフォーマンス機能の利点を増幅

2TBのユーザー・データ 100GBのユーザー・データ

ストレージ索引とゾーン・マップを使用

ディスク上に1TB、インメモリに1TB 索引なし

秒未満のスキャン30GBのユーザー・データ

Smart Scanを使用


静的パーティション・プルーニング

• 関連パーティションは、コンパイル時に分かります–実行計画ではPSTART/PSTOP列で実際の値を見ることができます

• オプティマイザは、SQL文に対するもっとも正確な情報を持っています

SELECT sum(amount_sold) FROM salesWHERE times_id BETWEEN ‘01-MAR-2016’ and ‘31-MAY-2016’;

3月14日2月14日1月14日 4月14日 5月14日 6月14日


静的プルーニングサンプル計画

SELECT sum(amount_sold) FROM sh.sales s, sh.times t WHERE s.time_id = t.time_idAND s.time_id between TO_DATE(‘01-JAN-2016’, ‘DD-MON-YYYY’)

and TO_DATE(‘01-JAN-2015’, ‘DD-MON-YYYY’)

Plan hash value:2025449199

---------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |---------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 3 (100)| | | || 1 | SORT AGGREGATE | | 1 | 12 | | | | || 2 | PARTITION RANGE ITERATOR | | 313 | 3756 | 3 (0)| 00:00:01 | 9 | 13 ||* 3 | TABLE ACCESS FULL | SALES | 313 | 3756 | 3 (0)| 00:00:01 | 9 | 13 |---------------------------------------------------------------------------------------------------

Predicate Information (identified by operation id):---------------------------------------------------

3 – filter(“S”.”TIME_ID”<=TO_DATE(‘ 2015-01-01 00:00:00’, ‘syyyy-mm-dd hh24:mi:ss’))

22 rows selected.


• 複雑な問合せのための先進のプルーニング機構

• 関連パーティションは実行時に決定されます–実行計画ではPSTART/PSTOP列でワード‘KEY’を探します

動的パーティション・プルーニング

SELECT sum(amount_sold)FROM sales s, times tWHERE t.time_id = s.time_id AND t.calendar_month_desc IN

(‘MAR-2016’, ‘APR-2016’, ‘MAY-2016’);

時間

1月14日

2月14日

3月14日

4月14日

5月14日

6月14日


サンプルで計画の出力を説明します

動的パーティション・プルーニングサンプル計画 - ネステッド・ループ

SELECT sum(amount_sold) FROM sales s, times t WHERE s.time_id = t.time_idAND t.calendar_month_desc in (‘MAR-2016’, ‘APR-2016’, ‘MAY-2016’)


---------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |---------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 13 (100)| | | || 1 | SORT AGGREGATE | | 1 | 28 | | | | || 2 | NESTED LOOP | | 2 | 56 | 13 (0)| 00:00:01 | | ||* 3 | TABLE ACCESS FULL | TIMES | 2 | 32 | 13 (8)| 00:00:01 | | || 4 | PARTITION RANGE ITERATOR| | 2 | 24 | 0 (0)| | KEY | KEY ||* 5 | TABLE ACCESS FULL | SALES | 2 | 24 | 0 (0)| | KEY | KEY |---------------------------------------------------------------------------------------------------


3 – filter((“T”.”CALENDAR_MONTH_DESC”=‘MAR-2016’ OR “T”.”CALENDAR_MONTH_DESC”=‘APR-2016’ OR “T”.”CALENDAR_MONTH_DESC”=‘MAY-2016’))

5 – filter(“T”.”TIME_ID”=“S”.”TIME_ID”)

26 rows selected.


動的パーティション・プルーニングサンプル計画 - 副問合せプルーニング

SELECT sum(amount_sold)FROM sales s, times t WHERE s.time_id = t.time_idAND t.calendar_month_desc in (‘MAR-2016’, ‘APR-2016’, ‘MAY-2016’)


---------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |---------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 2000K(100)| | | || 1 | SORT AGGREGATE | | 1 | 28 | | | | ||* 2 | HASH JOIN | | 24M| 646M| 2000K(100)| 06:40:01 | | ||* 3 | TABLE ACCESS FULL | TIMES | 2 | 32 | 43 (8)| 00:00:01 | | || 4 | PARTITION RANGE SUBQUERY| | 10G| 111G| 1166K(100)| 03:53:21 |KEY(SQ)|KEY(SQ)|| 5 | TABLE ACCESS FULL | SALES | 10G| 111G| 1166K(100)| 03:53:21 |KEY(SQ)|KEY(SQ)|---------------------------------------------------------------------------------------------------


2 – access(“S”.”TIME_ID”=“T”.”TIME_ID”)3 – filter((“T”.”CALENDAR_MONTH_DESC”=‘MAR-2016’ OR “T”.”CALENDAR_MONTH_DESC”=‘APR-2016’

OR “T”.”CALENDAR_MONTH_DESC”=‘MAY-2016’))

26 rows selected.


動的パーティション・プルーニングサンプル計画 – ブルーム・フィルタ・プルーニングSELECT sum(amount_sold)FROM sales s, times t WHERE s.time_id = t.time_idAND t.calendar_month_desc in (‘MAR-2016’, ‘APR-2016’, ‘MAY-2016’)


--------------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |--------------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 19 (100)| | | || 1 | SORT AGGREGATE | | 1 | 28 | | | | ||* 2 | HASH JOIN | | 2 | 56 | 19 (100)| 00:00:01 | | || 3 | PART JOIN FILTER CREATE | :BF0000 | 2 | 32 | 13 (8)| 00:00:01 | | ||* 4 | TABLE ACCESS FULL | TIMES | 2 | 32 | 13 (8)| 00:00:01 | | || 5 | PARTITION RANGE JOIN-FILTER| | 960 | 11520 | 5 (0)| 00:00:01 |:BF0000|:BF0000|| 6 | TABLE ACCESS FULL | SALES | 960 | 11520 | 5 (0)| 00:00:01 |:BF0000|:BF0000|--------------------------------------------------------------------------------------------------------


2 – access(“S”.”TIME_ID”=“T”.”TIME_ID”)4 – filter((“T”.”CALENDAR_MONTH_DESC”=‘MAR-2016’ OR “T”.”CALENDAR_MONTH_DESC”=‘APR-2016’

OR “T”.”CALENDAR_MONTH_DESC”=‘MAY-2016’))

27 rows selected.


“AND”プルーニング

• パーティション・キーに対するすべての条件がプルーニングに使用されます–動的条件と静的条件を組み合わせて使用するようになりました

• 例：–FACT表とディメンションの両方にプルーニング条件があるスター変換

FROM sales s, times t …WHERE s.time_id = t.time_id ..AND t.fiscal_year in (2016,2015)AND s.time_id between TO_DATE('01-JAN-2016','DD-MON-YYYY’)and TO_DATE('01-JAN-2017','DD-MON-YYYY’)

動的プルーニング

静的プルーニング


“AND”プルーニングサンプル計画


----------------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |----------------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 24 | 17 (12)| 00:00:01 | | || 1 | SORT AGGREGATE | | 1 | 24 | | | | ||* 2 | HASH JOIN | | 204 | 4896 | 17 (12)| 00:00:01 | | || 3 | PART JOIN FILTER CREATE| :BF0000 | 185 | 2220 | 13 (8)| 00:00:01 | | ||* 4 | TABLE ACCESS FULL | TIMES | 185 | 2220 | 13 (8)| 00:00:01 | | || 5 | PARTITION RANGE AND | | 313 | 3756 | 3 (0)| 00:00:01 |KEY(AP)|KEY(AP)||* 6 | TABLE ACCESS FULL | SALES | 313 | 3756 | 3 (0)| 00:00:01 |KEY(AP)|KEY(AP)|----------------------------------------------------------------------------------------------------


2 – access(“S”.”TIME_ID”=“T”.”TIME_ID”)4 – filter(“T”.”TIME_ID”<=TO_DATE(‘ 2015-01-01 00:00:00’, ‘syyyy-mm-dd hh24:mi:ss’) AND

(“T”.”FISCAL_YEAR”=2016 OR “T”.”FISCAL_YEAR”=2015) AND “T”.”TIME_ID”>=TO_DATE(‘ 2016-01-01 00:00:00’, ‘syyyy-mm-dd hh24:mi:ss’))


22 rows selected.


パーティション・プルーニングの保証パーティション・キー・フィルタ条件に対して関数を使用しないでください

SELECT sum(amount_sold) FROM sh.sales s, sh.times t WHERE s.time_id = t.time_idAND TO_CHAR(s.time_id, ‘YYYYMMDD’) between ‘20160101’ and ‘20170101’


---------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 6 (100)| | | || 1 | SORT AGGREGATE | | 1 | 12 | | | | || 2 | PARTITION RANGE ALL| | 2 | 24 | 6 (17)| 00:00:01 | 1 | 16 ||* 3 | TABLE ACCESS FULL | SALES | 2 | 24 | 6 (17)| 00:00:01 | 1 | 16 |---------------------------------------------------------------------------------------------


3 – filter((TO_CHAR(INTERNAL_FUNCTION(“S”.”TIME_ID”),’YYYYMMDD’)>=‘20160101’ ANDTO_CHAR(INTERNAL_FUNCTION(“S”.”TIME_ID”),‘YYYYMMDD’)<=‘20170101’))

23 rows selected.


パーティション・プルーニングの保証パーティション・キー・フィルタ条件に対して関数を使用しないでください

SELECT sum(amount_sold) FROM sh.sales s, sh.times t WHERE s.time_id = t.time_idAND TO_CHAR(s.time_id, ‘YYYYMMDD’) between ‘20160101’ and ‘20170101’


---------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 6 (100)| | | || 1 | SORT AGGREGATE | | 1 | 12 | | | | || 2 | PARTITION RANGE ALL| | 2 | 24 | 6 (17)| 00:00:01 | 1 | 16 ||* 3 | TABLE ACCESS FULL | SALES | 2 | 24 | 6 (17)| 00:00:01 | 1 | 16 |---------------------------------------------------------------------------------------------


3 – filter((TO_CHAR(INTERNAL_FUNCTION(“S”.”TIME_ID”),’YYYYMMDD’)>=‘20160101’ ANDTO_CHAR(INTERNAL_FUNCTION(“S”.”TIME_ID”),‘YYYYMMDD’)<=‘20150101’))

23 rows selected.

SELECT sum(amount_sold) FROM sh.sales s, sh.times t WHERE s.time_id = t.time_idAND s.time_id between TO_DATE(‘20160101’,’YYYYMMDD’) and TO_DATE(‘20170101’,’YYYYMMDD’)


---------------------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop |---------------------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | | | 3 (100)| | | || 1 | SORT AGGREGATE | | 1 | 12 | | | | || 2 | PARTITION RANGE ITERATOR| | 313 | 3756 | 3 (0)| 00:00:01 | 9 | 13 ||* 3 | TABLE ACCESS FULL | SALES | 313 | 3756 | 3 (0)| 00:00:01 | 9 | 13 |---------------------------------------------------------------------------------------------



22 rows selected.


パーティション・ワイズ結合（PWJ）パーティション・プルーニングとPWJの実際の動作

… …MAR APRFEBJAN … …JAN FEB MAR APR

Jan, Hash 1

Jan, Hash 2

JAN JAN

• 大規模結合は複数の小規模結合に分割され、並行して実行されます– 結合するパーティション数は、DOPの倍数である必要があります

– 両方の表が、結合列上で同じ方法でパーティション化されている必要があります


パーティション・ワイズ結合（PWJ）パーティション・プルーニングとPWJの実際の動作

… …MAR APRFEBJAN

JAN

• 大規模結合は複数の小規模結合に分割され、並行して実行されます

–結合するパーティション数は、DOPの倍数である必要があります

–両方の表が、結合列上で同じ方法でパーティション化されている必要があります

CUSTOMER

hash 1

hash 2

hash 3

hash 4

hash1

CUSTOMERFEB MAR APR

hash 1

hash 2

hash 3

hash 4

hash 1


パーティションのパージとロード

• メタデータのみの操作としてデータを削除および追加します

–パーティションのメタデータを交換します

• スタンドアロン表（非パーティション表）を任意の単一パーティションと交換します

–データ・ロード：スタンドアロン表にロード対象の新しいデータが含まれています

–データ・パージ：データを含むパーティションが空の表と交換されます

• パージの代替としてDROPパーティションを行います

–データは永久に失われます

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

2016年 5月24日

売上表

“空”


パーティション化のメンテナンス



• パフォーマンスがもっとも目立ちますが、次のことも忘れないでください

–パーティション化は、パフォーマンス、管理性、および可用性の、すべての業務関連領域に対処できる必要があります

• パーティションの自律性が重要です–任意のパーティション・メンテナンス操作の基本要件

–パーティションをデータ・ディクショナリのメタデータと認識すること

成功のための基本概念



• 完全なパーティション自律性を提供します

– 可能な場合は常にローカル索引を使用します

– パーティションに対するすべての表レベル操作を有効にします（たとえばTRUNCATE、MOVE、COMPRESS）

• データベース管理のためにパーティションを分かりやすいようにします

– 使いやすいようにパーティションを命名します

• メンテナンス操作はパーティション対応である必要があります

– 索引についても同様

• メンテナンス操作は、パーティション表のオンライン使用に干渉してはなりません

成功のための基本概念


データ管理について

• データの高速移入– EXCHANGE–パーティションごとのダイレクト・パス・ロード

• データの高速削除

– DROP、TRUNCATE、EXCHANGE

• データの高速再編成

– MOVE、SPLIT、MERGE

パーティション・メンテナンス操作で対処



すべてのパーティションを常に利用できます

• 影響が及ぶパーティションに対するDMLロック

• オンラインでのパーティション移動はまったくロックされません

表のパーティション・メンテナンス操作ALTER TABLE ADD PARTITION(S)ALTER TABLE DROP PARTITION(S)ALTER TABLE EXCHANGE PARTITIONALTER TABLE MODIFY PARTITION

[PARALLEL][ONLINE]ALTER TABLE MOVE PARTITION [PARALLEL][ONLINE]ALTER TABLE RENAME PARTITIONALTER TABLE SPLIT PARTITION [PARALLEL][ONLINE]ALTER TABLE MERGE PARTITION(S) [PARALLEL]ALTER TABLE COALESCE PARTITION [PARALLEL]ALTER TABLE ANALYZE PARTITIONALTER TABLE TRUNCATE PARTITION(S)Export/Import [by partition]Transportable tablespace [by partition]

索引メンテナンス操作ALTER INDEX MODIFY PARTITIONALTER INDEX DROP PARTITION(S)ALTER INDEX REBUILD PARTITIONALTER INDEX RENAME PARTITIONALTER INDEX RENAMEALTER INDEX SPLIT PARTITIONALTER INDEX ANALYZE PARTITION


複数パーティションでのパーティションのメンテナンスOracle 12c Release 1（12.1）で導入


パーティション・メンテナンス操作の強化

• 単一の操作で複数パーティション上のパーティションをメンテナンス

• 完全並列性

• ローカル索引とグローバル索引の透過的メンテナンス

複数のパーティションに対する操作

…JAN 2016 FEB 2016 MAR 2016 APR 2016 DEC 2016

…Q 1 2016 APR 2016 DEC 2016

ALTER TABLE orders MERGE PARTITIONS Jan2016, Feb2016, Mar2016INTO PARTITION Q1_2016 COMPRESS FOR ARCHIVE HIGH;


パーティション・メンテナンス操作の強化複数のパーティションに対する操作

• 複数パーティションを順に指定します

• パーティションのレンジを指定します

• すべてのPMOPに対して動作

• 高速分割などの最適化をサポート

SQL > alter table pt merge partitions for (5), for (15), for (25) into partition p30;

Table altered.

SQL > alter table pt merge partitions part10 to part30 into partition part30;Table altered.

SQL > alter table pt split partition p30 into 2 (partition p10 values less than (10),3 partition p20 values less than (20),4 partition p30);

Table altered.


参照パーティション化のためのカスケード切捨てとカスケード交換Oracle 12c Release 1（12.1）で導入


高度なパーティション化のメンテナンスTRUNCATEおよびEXCHANGE PARTITIONのカスケード

• 業務継続性向上のためのTRUNCATEおよびEXCHANGEのカスケード

• 単一の原子トランザクションではデータ整合性が保持されます

• 単純化され、エラーが発生しにくいコード開発

ALTER TABLE orders TRUNCATE PARTITION Jan2015 CASCADE;

BACK ORDERS


PICK LISTS

JANBACK ORDERS


PICK LISTS

FEBBACK ORDERS


PICK LISTS

MAR

JAN FEB MAR


TRUNCATE PARTITIONのカスケード

親

子1 子2

孫1 孫2 孫3

曾孫1

親

子1 子2

孫1 孫2 孫3

曾孫1

• 適切なボトムアップ処理が必要です

• 7つの個別切捨て操作

• 1つの切捨て操作

17

5 6

1 2 4

3


TRUNCATE PARTITIONのカスケード


TRUNCATE PARTITIONのカスケード• CASCADEは参照ツリー全体に対して適用されます

– 単一の原子トランザクション（オール・オア・ナッシング）

– 階層の複雑さや深さは重要ではありません

– 参照パーティション表の任意のレベル上で指定できます

• すべての外部キーに対してON DELETE CASCADEが必要です

• TRUNCATEのカスケードは、非パーティション表にも利用できます

– 非パーティション表の依存性ツリーは、無効な外部キー制約で中断できます

• 参照パーティション階層は、交換対象のターゲットおよび表に適合する必要があります

• 複数の子が同じレベルにある複雑なツリーでは、所定のレベルにあるそれぞれの子が親表の異なるキーを参照する必要があります

– 階層ツリーの表を明確なペアにするために必要です


EXCHANGE PARTITIONのカスケード

親

子1 子2

孫1 孫2 孫3

曾孫1

親

子

孫

• ターゲットからのボトムアップ交換（クリア）

• ターゲットへのトップダウン交換（移入）

1

2

3

4

5

6



• ターゲットからのボトムアップ交換（クリア）

• ターゲットへのトップダウン交換（移入）

親

子1 子2

孫1 孫2 孫3

曾孫1

親

子

孫1

2

3

4

5

6

親

子1 子2

孫1 孫2 孫3

曾孫1

親

子

孫

1

• 階層ツリーのすべてを交換します

• 1つの交換操作


パーティションのオンライン移動Oracle 12c Release 1（12.1）で導入



• 透過的なMOVE PARTITION ONLINE操作

• 同時に実行されるDMLと問合せ

• ローカル索引とグローバル索引の索引メンテナンス

オンライン・パーティション移動

…JAN 2016 SEP 2016 OCT 2016 NOV 2015 DEC 2015



• 透過的なMOVE PARTITION ONLINE操作

• 同時に実行されるDMLと問合せ

• ローカル索引とグローバル索引の索引メンテナンス

オンライン・パーティション移動

…JAN 2016

SEP 2016 OCT 2016 NOV 2015 DEC 2015



• 可能な場合、同時DML操作はなるべく少なくします–ジャーナリング用に追加のディスク領域とリソースが必要です

–ジャーナルは、初回バルク移動の後で再帰的に適用されます

–ジャーナルが大きくなるほど、実行時間は長くなります

• 同時DMLは圧縮効率に影響します–初回バルク移動が最大の圧縮率

オンライン・パーティション移動 – ベスト・プラクティス


非同期グローバル索引メンテナンスOracle 12c Release 1（12.1）で導入



• 索引メンテナンスなしでのDROPおよびTRUNCATE PARTITION後に使用可能なグローバル索引

–影響を受けたパーティションは内部的に判別でき、データ・アクセス時に除外されます

• DROPおよびTRUNCATEは、高速なメタデータのみの操作になります–大幅な高速化と初期リソース消費の低減

• グローバル索引メンテナンスの遅延

– ALTER INDEX REBUILD|COALESCEを介した遅延メンテナンス

–スケジュール済ジョブを使用した自動クリーンアップ

非同期グローバル索引メンテナンス



変更前

非同期グローバル索引メンテナンス

変更後


パーティション化の統計管理


統計収集

• オプティマイザ統計を収集する必要があります

–動的サンプリングの使用は適切な解決方法でありません

–グローバルおよびパーティション・レベルでの統計を推奨• サブパーティション・レベルはオプション

• 空の表に対してすべての問合せを実行して、列の使用状況を設定します

–これは、どの列のヒストグラムを自動的に取得するか識別する助けになります

• オプティマイザ統計はデータがロードされた後、索引が作成される前に収集してください

–索引の統計は、作成時に自動収集されます


統計収集

• デフォルトでは、DBMS_STATSは各表の次の統計を収集します

– グローバル（表レベル）、パーティション・レベル、サブ・パーティション・レベル

• 問合せが2つ以上のパーティションに関与する場合、オプティマイザはグローバル統計を使用します

• 問合せがパーティションの除外を行い、問合せに答えるのに必要なパーティションが1つの場合、オプティマイザはパーティション統計を使用します

– 問合せが2つ以上のパーティションに関与する場合、オプティマイザはグローバル・レベルとパーティション・レベルの統計を組み合わせて使用します

• 問合せがパーティションの除外を行い、問合せに答えるのに必要なサブパーティションが1つの場合、オプティマイザはサブパーティション・レベルの統計のみを使用します


効率的な統計管理

• AUTO_SAMPLE_SIZEを使用します

–新しい効率的な統計収集を可能にする唯一の設定

–ハッシュ・ベースのアルゴリズム、表全体をスキャン• サンプリング速度、計算の正確さ

• 増分グローバル統計収集を可能にします

–単一パーティションの変更後にすべてのパーティションをスキャンするのを回避します• 11.1より前は、グローバル統計に必要なすべてのパーティションをスキャン

–表単位で管理されます• 静的設定

–非パーティション表を交換するためのシノプシスを作成します（Oracle Database 12c）


増分グローバル統計

1.パーティション・レベルの

統計が収集され、シノプシスが作成されます

2.グローバル統計は、

パーティションのシノプシスを集計することによって生成されます2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

S1

S2

S3

S4

S5

S6

グローバル統計

Sysaux表領域


増分グローバル統計（続き）

3.新しいパーティションが表

に追加され、データがロードされます

4.新しいパーティションのパーティション統計を収集します

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

2016年 5月24日 S7


増分グローバル統計（続き）

5.Sysauxから他の各パーティションのシノプシスを取得します

6.グローバル統計は、元の

パーティション・シノプシスを新しいものとともに集計することによって生成されます

S1

S2

S3

S4

S5

S6

グローバル統計

Sysaux表領域

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

2016年 5月24日 S7


• 表の増分機能をオンにします

• ロード後にGATHER_TABLE_STATSを使用して表統計を収集します• パラメータの指定は不要です

• コマンドはパーティションの統計を収集し、パーティション・レベルの統計およびシノプシスに基づいてグローバル統計を更新します

• すべての表に対して増分をtrueに設定可能• 既存の表に対してのみ機能します

正確な統計を収集するのに必要な手順

EXEC DBMS_STATS.SET_TABLE_PREFS('SH’,'SALES','INCREMENTAL','TRUE');

EXEC DBMS_STATS.GATHER_TABLE_STATS('SH','SALES');

EXEC DBMS_STATS.SET_GLOBAL_PREFS('INCREMENTAL','TRUE');


属性クラスタリングとゾーン・マップOracle 12c Release 1（12.1.0.2）で導入


属性クラスタリングによるゾーン・マップ

• 相乗的な利点

• 問合せパフォーマンスと同時実行性の向上

– 物理データ・アクセスの低下

– 高度に選択的な操作に対する大幅なIO縮小

• 領域使用の最適化

– 索引の必要性の低下

– データ・クラスタリングを介した圧縮率の改善

• 完全なアプリケーション透過性

– あらゆるアプリケーションにメリット

属性クラスタリング

列値がまとまってディスクに格納されるようにデータを配列

ゾーン・マップ

ゾーンごとに指定した列の最小値/最大値を格納

問合せ実行時に必要ないデータをフィルタするのに使用



• 選択した列値“属性”に基づいて緊密な近接性が維持されるようにデータを配列します

• 属性は、単一の表または複数の表から取得できます

– たとえばファクト表やディメンション表から

• ゾーン・マップとの使用時に大幅なIOプルーニング

• 索引範囲スキャンでの表参照に対するブロックIOの低下

• ソートと集計を行う問合せは事前順序付けデータも活用できます

• 圧縮率の改善を可能にします

– 順序付けられたデータは順序付けられていないデータより圧縮効率はよい傾向があります

概要と利点


ゾーン・マップのための属性クラスタリング

• カテゴリ値BOYS、GIRLSおよびMENを含む順序付けられた行。

• ゾーンマップは、特定の列値の範囲を含む、行やゾーンのカタログ領域です。

• デフォルトで、各ゾーンは、最大1024ブロックです。

• たとえば、カテゴリ“GIRLS”を検索する場合、スキャンする必要があるのはこのゾーンのみです。他のゾーンはすべてスキップできます。

順序付けられた行

ALTER TABLE salesADD CLUSTERING BYLINER ORDER (category);

ALTER TABLE sales MOVE;



• 2タイプの属性クラスタリング

– LINEAR ORDER BY• 旧来の順序付け

– INTERLEAVED ORDER BY• 複数ディメンションの順序付け

• 単一表上の単純な属性クラスタリング

• 結合属性クラスタリング

– 複数の表の結合で導出された属性のクラスタ

• 最大4つの表

• 非重複結合（結合された表上のPKまたはUKが必要）

基本


属性クラスタリング例

• CLUSTERING BY LINEAR ORDER (category, country)

• CLUSTERING BY INTERLEAVED ORDER (category, country)

INTERLEAVED ORDER• LINEAR ORDER



• 表レベルで指定されたクラスタリング・ディレクティブ

– ALTER TABLE ...ADD CLUSTERING ...

• ディレクティブは新しいデータおよびデータ移動に適用されます

• ダイレクト・パス処理

– INSERT APPEND、MOVE、SPLIT、MERGE– 従来のDMLには適用されません

• オンデマンドで有効化/無効化できます

– ヒントや特定の構文

基本



• 指定した列の最小値と最大値を格納します– 情報はゾーンごとに格納されます

– 多次元パーティション・プルーニングのためのパーティション表の[サブ]パーティション-レベルのロールアップ情報

• 粗い索引構造に類似– 索引よりはるかにコンパクト

– ゾーン・マップは必要ないものを除外し、索引は必要なものを検出します

• 完全なアプリケーション透過性による大幅なパフォーマンスの向上– 結合ゾーン・マップ（“階層ゾーン・マップ”とも呼ばれます）を使用した、表自体または結合された表の条件による表スキャンのIO低減

• 順序付けられたデータでメリットが最大になります– 属性クラスタリングまたは自然に順序付けられたデータと組み合わせて使用されます

概要と基本



• 表のために作成された独立アクセス構造

– マテリアライズド・ビューのタイプを使用して実装されます

– パーティション表および非パーティション表に対して

• 表につき1つのゾーン・マップ

– パーティション表のゾーン・マップは、[サブ]パーティションごとの集計エントリを含みます

• 透過的に使用されます

– 問合せの変更やヒントは不要

• 暗黙的または明示的な作成と列選択

– 属性クラスタリングを介して：CREATE TABLE … CLUSTERING– CREATE MATERIALIZED ZONEMAP … AS SELECT …

基本


属性クラスタリングを持つゾーン・マップ

• CLUSTERING BY LINEAR ORDER (category, country)

• 順序付けられたデータでゾーン・マップのメリットが最大になります

次によるプルーニング：

SELECT ..FROM tableWHERE category =

‘BOYS’;


‘BOYS’;AND country = ‘US’;

• LINEAR ORDER


• INTERLEAVED ORDER

属性クラスタリングを持つゾーン・マップ

• CLUSTERING BY INTERLEAVED ORDER (category, country)

• 順序付けられたデータでゾーン・マップのメリットが最大になります

次によるプルーニング：


‘BOYS’;

SELECT ..FROM tableAND country = ‘US’;


‘BOYS’AND country = ‘US’;



• DMLおよびパーティション操作が、ゾーン・マップの完全または部分的な失効を引き起こすことがあります

–ダイレクト・パス・インサートによりゾーン・マップが失効することはありません

• 単一表‘ローカル’ゾーン・マップ

–更新および挿入により、影響を受けるゾーン（および任意の集計済パーティション・エントリ）が失効とマークされます

–削除用のゾーン・マップには影響ありません

• 結合されたゾーン・マップ

–ファクト表に対するDMLは、単一表ゾーン・マップと同等の動作です

–ディメンション表に対するDMLは、依存しているゾーン・マップを完全に失効します

失効



• DMLの要求に応じた増分と完全リフレッシュ

–ゾーン・マップ・リフレッシュには、マテリアライズド・ビュー・ログが必要です• 失効したゾーンのみが、MVをリフレッシュするためにスキャンされます

–結合されたゾーン・マップの場合• ファクト表に対するDML：増分リフレッシュ

• ディメンション表に対するDML：完全リフレッシュ

• ゾーン・マップのメンテナンス– DBMS_MVIEW.REFRESH()– ALTER MATERIALIZED ZONEMAP <xx> REBUILD;

リフレッシュ


例 - ディメンション階層

id product_id location_id amount

1 3 23 2.00

2 88 55 43.75

3 31 99 33.55

4 33 62 23.12

5 21 11 38.00

6 33 21 5.00

7 44 71 10.99

location_id State county

23 California Inyo

102 New Mexico Union

55 California Kern

1 Ohio Lake

62 California Kings

CREATE TABLE orders ( ...)CLUSTERING ordersJOIN locations ON (orders.location_id = locations.location_id) BY INTERLEAVED ORDER (locations.state, locations.county)WITH MATERIALIZED ZONEMAP …

注：ゾーンには通常、ここに示すよりはるかに多くの行が含まれます。これは、説明のみを目的としています。

ORDERS LOCATIONS




1 3 23 2.00

2 88 55 43.75

3 31 99 33.55

4 33 62 23.12

5 21 11 38.00

6 33 21 5.00

7 44 71 10.99


23 California Inyo


55 California Kern

1 Ohio Lake

62 California Kings

SELECT SUM(amount)FROM ordersJOIN locations ON (orders.location.id = locations.location.id)WHERE state = ‘California’;

注：ゾーンには通常、ここに示すよりはるかに多くの行が含まれます。これは、説明のみを目的としています。

ORDERS LOCATIONS

ゾーンのスキャン




1 3 23 2.00

2 88 55 43.75

3 31 99 33.55

4 33 62 23.12

5 21 11 38.00

6 33 21 5.00

7 44 71 10.99


23 California Inyo


55 California Kern

1 Ohio Lake

62 California Kings

SELECT SUM(amount)FROM ordersJOIN locations ON (orders.location.id = locations.location.id)WHERE state = ‘California’AND county = ‘Kern’;注：ゾーンには通常、ここに示すよりはるかに多くの行が含まれます。

これは、説明のみを目的としています。

ORDERS LOCATIONS

ゾーンのスキャン


ゾーン・マップとパーティション化

• ゾーン・マップは、パーティション（あるいは、サブパーティション）キーに含まれない列に対して、パーティションをプルーニングすることができます

JAN FEB MAR APR

パーティション・キー：ORDER_DATE

ゾーン・マップ：SHIP_DATE

ゾーン・マップ列SHIP_DATEはパーティション・キーORDER_DATEと相関する

JAN FEB MAR


ゾーン・マップとパーティション化

JAN FEB MAR APR

パーティション・キー：ORDER_DATE

ゾーン・マップ：SHIP_DATE

MARパーティションとAPRパーティションはプルーニングされます

JAN FEB MAR

WHERE ship_date = TO_DATE(’10-JAN-2011’)

• ゾーン・マップは、パーティション（あるいは、サブパーティション）キーに含まれない列に対して、パーティションをプルーニングすることができます


ゾーン・マップとストレージ索引

• 属性クラスタリングとゾーン・マップは、Exadataストレージ索引とともに透過的に機能します

– Exadataストレージ索引の利点は、引き続きフル活用されます

• また、ゾーン・マップは（属性クラスタリングと使用されるとき）

– さらに大幅なIO最適化を可能にします

• 特に大規模表で、索引に代わる選択肢を提供します

• 結合とファクト-ディメンション問合せ（ディメンション階層検索を含む）

• 特にスター・スキーマとスノーフレーク・スキーマに関連

– パーティションとサブパーティションの全体をプルーニングできます

– ダイレクト・パスと従来型パスのいずれの読取りにも効果的です

– 結合と索引範囲スキャンの最適化を含みます

– 物理データベース設計の部分：DBAによって明示的に作成、制御されます


パーティション化のヒントとコツ


• パーティション化の戦略について

• 物理属性と論理属性

• ホット・スポットの除外

• スマートな部分交換

• PKおよびUKとの交換

パーティション化のヒントとコツ


パーティション化の戦略について


パーティション化戦略の選択

• 考慮事項

–データ

–使用状況

• パーティション化に期待する内容

–問合せパフォーマンスの向上

–ロード（またはパージ）パフォーマンスの向上

–データ管理の向上



• システムへのデータの挿入方法

• システムでのデータのメンテナンス方法

• システムのデータへのアクセス方法

データの論理形態




–時間、場所、テナント、ビジネス・ユーザー、…–レンジ、無関係な値リスト、“それらの多く”、…









–アクティブなデータ、法律的要件、“永続的”データの時間枠の移動…–未定








–アクティブなデータ、法律的要件、“永続的”データの時間枠の移動…–未定


–常にフル・スキャン、共通のFILTER条件付き、常時索引アクセス…–未定




• 問合せの高速化

–パーティション・エリミネーション

–パーティション・ワイズ結合

• DMLの高速化

–競合ポイントの緩和

• データのメンテナンス

– DMLでなくDDL

パフォーマンスの向上



• I/Oの削減は、プルーニングされるパーティションの数に比例します–1/10：IOが10倍少なくなります

–1/100：IOが100倍少なくなります

• 実行時間を短縮する要因–CPU動作に対するIOの相対的な影響の大きさ

–以降の操作への潜在的な影響

データ・アクセス - フル・テーブル・アクセス



• グローバル索引は任意のパーティションの行を指します

–索引はパーティション化しても、しなくてもかまいません

• ローカル索引は表と同じパーティションになります

–パーティション化キーは索引キーと異なることがあります

パーティション表の索引付け





• 単一パーティション・プルーニングによるパーティション索引アクセス

• パーティション・プルーニングのないパーティション索引アクセス

パーティション化戦略の選択データ・アクセス - ローカル索引とグローバル・パーティション索引


ローカルおよびグローバルのパーティション索引

• アクセスされたパーティションの数と同一の索引プローブの数

–パーティション・プルーニングがないと、すべての索引パーティションにプローブを行います

• OLTP環境に適していますが最適ではありません

–常にパーティション・プルーニングがある保証はありません

–例外：DML競合緩和のためのグローバル・ハッシュ・パーティション索引• もっとも一般的に少ない数のパーティション

• 索引接頭辞に基づくグローバル・パーティション索引に対するプルーニング

–索引の先頭キーと同一な索引接頭辞（索引のパーティション・キー）

データ・アクセス


パーティション化戦略の選択グローバル非パーティション索引

• 違いがわかりますか


• 違いがわかりますか

• ほとんどありません*

パーティション化戦略の選択グローバル非パーティション索引

* rowidが大きいため索引サイズが多少異なります


グローバル索引

• 非パーティション索引にプルーニングはありません

– 単一索引セグメントを常にプローブします

• 索引の先頭キーと同一なグローバル・パーティション索引接頭辞（索引のパーティション・キー）

– 表のパーティション・キー列でなく索引接頭辞に対するプルーニング

• OLTP環境でもっとも一般的

データ・アクセス

PARTITION BY (col1), idx(col1) PARTITION BY (col1), idx(col2)


データのメンテナンス


• レコードが削除されます

– 索引のメンテナンス

– UNDOとREDO

• パーティションが削除されます

– 高速なグローバル索引のメンテナンス（12c）

– 最少のUNDO

• パーティションが削除されます

– ローカル索引が削除されます

– 最少のUNDO

DELETE FROM ... WHERE ... ALTER TABLE ...DROP PARTITION ...


ローカル索引

• 増分索引作成が可能です

–まず使用禁止で作成し、個別のパーティションを再構築

• 1つのパーティションにのみ影響するすべてのパーティション・メンテナンス操作に対する高速索引メンテナンス（メタデータのみのメンテナンス）

–交換、削除、切捨て

• 複数のパーティションに影響するパーティションのメンテナンスには、索引のメンテナンスが必要です

–マージ、分割により新しいデータ・セグメントを作成します

–新しい索引セグメントも作成されます



グローバル索引

• 増分索引作成は、不可能ではありませんが困難です

• Oracle Database 12c以降、削除と切捨ては“高速”索引メンテナンス

–高速とは、実際には遅延索引メンテナンスです

• 削除と切捨てを除くパーティションのメンテナンスには索引のメンテナンスが必要です

–従来の索引のメンテナンスは、PMOPを表すDML操作と同等です



適切なパーティション数とは


適切なパーティション数とは

場合によります


データ・ボリュームとパーティションの数

• 表が100TBの場合–100万のパーティションでは、各パーティションのサイズは100MBです








• ご使用のシステムで1MBを読み取るのに必要な時間は?–Exadataの全表スキャン速度は25GB/秒…（ディスクのみ、フル・ラックX5-2）



• 多ければいいわけではありません–すべてのパーティションは、ディクショナリ内のメタデータを表します

–すべてのパーティションでSGA内のメタデータ領域を増大させます

• パーティション数とその平均サイズの最適なバランスを模索します–“通常のシステム”上のセグメントでは、1桁のGBサイズでもかまいません

–5GB以上のセグメント・サイズの場合、より多くのパーティションを考慮します



• レンジ（インターバル）が、いまだにもっとも一般的なパーティション化戦略です

–たいてい、ある程度の時間依存性があります

• リストは、ますます一般化しています

–多くの場合、時間にも基づいています

–多くの場合、サブパーティション化戦略として

• ハッシュは、パフォーマンス（PWJ、DML競合）目的に使用されるだけではありません

–データ配置は管理しませんが、ある程度把握しています

– 2の累乗のルールを忘れないでください

顧客使用状況パターン



• インターバル・パーティション化（急成長している新しいパーティション化戦略）

–レンジ・パーティション化の管理性を拡張

• 参照パーティション化

–データ・モデルに合わせてPK/FK制約を活用します

• インターバル-参照パーティション化（Oracle Database 12cの新機能）

• バーチャル・カラム・パーティション化

–アプリケーションの変更を必要としない導出された属性

• 上記のあらゆるバリエーション

パーティション化戦略の強化


物理属性と論理属性



• 論理属性–パーティション化のセットアップ

–索引付けと索引のメンテナンス

–読取り専用（表領域の分離との組合せ）

• 物理属性–データ配置

–一般にはセグメント・プロパティ


非パーティション表

• 論理表プロパティ

– 列とデータ型

– 制約

– 索引、…

• 物理表プロパティ

– セグメントと同等な表

– 表領域

– 圧縮、[ Logging|NoLogging ]、…– インメモリ

– セグメント・レベルで管理、変更されるプロパティ



パーティション表

• 論理表プロパティ

– 列とデータ型

– 制約

– 部分索引、…– 物理プロパティ・ディレクティブ

• 物理[サブ]パーティション・プロパティ

– セグメントに同等な[サブ]パーティション

– 表領域

– 圧縮、[Logging|NoLogging ]、…– インメモリ

– セグメント・レベルで管理、変更されるプロパティ


パーティションパーティション

表


パーティション表

• 表はメタデータのみで、将来のパーティションのためのディレクティブです

–表レベルの物理セグメントはありません

–指定した場合、物理属性は新しいパーティションのためのディレクティブになります

• 単一レベルのパーティション表

–パーティションはセグメントと同等です

–物理属性は、パーティション・レベルで管理、変更されます

• コンポジット・レベルのパーティション表

–パーティションはメタデータのみで、将来のサブパーティションのためのディレクティブです

–サブパーティションはセグメントと同等です



パーティション表でのデータ配置

• 各パーティションまたはサブパーティションは、別々のオブジェクトです

• 個々のレベルでストレージ属性を指定します

–下位レベルの配置ポリシーとして

–個々の[サブ]パーティションに対して

• ストレージ属性を指定しない場合、標準的な階層継承が有効になります

表

パーティション

表領域

サブパーティション



• インターバル・パーティション化によりすべてのパーティションが”事前作成”されます

– 100万の[サブ]パーティションはすべて論理的に存在します

• 物理ストレージも（ほとんど）決定されます

• パーティション配置

– 表レベルから継承

– ラウンドロビン・パーティション配置のためのSTORE IN ()句

• サブパーティション配置

– サブパーティション・テンプレートの使用

• バグ・フィックス#8304261が必要（11.2.0.3に含まれる）

– STORE IN句は、現在ノーオペレーションです

特殊ケースのインターバル・パーティション化

表

表領域

パーティションP1

パーティションP2

サブパーティション1






• Oracle Database 9 Release 2より導入されました。

– 将来のパーティション用のサブパーティションの事前定義を可能にします

– データ・ディクショナリのメタデータとして格納されます

サブパーティション・テンプレート

将来のすべてのパーティションのサブパーティション

定義

サブパーティションは、すべてのパーティション

に適用されます

CREATE TABLE stripe_regional_sales(deptno number, item_no varchar2(20), txn_date date, txn_amount number, state varchar2(2))

PARTITION BY RANGE (txn_date)SUBPARTITION BY LIST (state)SUBPARTITION TEMPLATE

(SUBPARTITION northwest VALUES (‘OR’, ‘WA’) TABLESPACE tbs_1SUBPARTITION southwest VALUES (‘AZ, ‘UT’, ‘NM’) TABLESPACE tbs_2SUBPARTITION northeast VALUES (‘NY’, ‘VM’, ‘NJ’) TABLESPACE tbs_3SUBPARTITION southeast VALUES (‘FL’, ‘GA’) TABLESPACE tbs_4SUBPARTITION midwest VALUES (SD’, ‘WI’) TABLESPACE tbs_5SUBPARTITION south VALUES (‘AL’, ‘AK’) TABLESPACE tbs_6SUBPARTITION south VALUES (DEFAULT) TABLESPACE tbs_7)

(PARTITION q1_2016 VALUES LESS THAN ( TO_DATE(‘01-APR-2016’, ‘DD-MON-YYYY’)),(PARTITION q2_2016 VALUES LESS THAN ( TO_DATE(’01-JUL-2016’, ‘DD-MON-YYYY’)),(PARTITION q3_2016 VALUES LESS THAN ( TO_DATE(’01-OCT-2016’, ‘DD-MON-YYYY’)),(PARTITION q4_2016 VALUES LESS THAN ( TO_DATE(’01-JAN-2015’, ‘DD-MON-YYYY’)),);


パーティション化を使用したホット・スポットの除去



• RACでは、DMLワークロードが高くなると、キャッシュ・フュージョン・トラフィックも高くなります

–このブロックをpingと呼んでいます

非パーティション表

ノード2

INSERT ..North

INSERT ..South

INSERT ..North

INSERT ..South

ノード1

INSERT ..North

INSERT ..South

INSERT ..North

INSERT ..South



• RACでは、DMLワークロードが高くなると、キャッシュ・フュージョン・トラフィックも高くなります

– このブロックをpingと呼んでいます

• ハッシュ（またはリスト）パーティション表により、この状況を軽減できます

– 注意事項：通常、なんらかの“アプリケーション・パーティション化”または“アプリケーションRAC対応”が必要です

ハッシュ・パーティション表

ノード1

INSERT ..North

INSERT ..South

INSERT ..North

INSERT ..South

ノード2

INSERT ..North

INSERT ..South

INSERT ..North

INSERT ..South



• DMLワークロードが高くなると、索引ブロックにホット・スポット（競合）が作成されることがあります

–たとえば、人為的な（右上がりの）主キー索引

ハッシュ・パーティション索引

INSERT ..1INSERT ..2





• DMLワークロードが高くなると、索引ブロックにホット・スポット（競合）が作成されることがあります

–たとえば、人為的な（右上がりの）主キー索引

• ハッシュ・パーティション索引の場合、ウォーム・スポットが発生します。

ハッシュ・パーティション索引





INSERT ..5


INSERT ..6


ホット・スポットの除去 – ユースケース課題

• O/R（オブジェクト・リレーショナル）マッピングを使用する小売アプリケーション

• “一般的な”データベース機能のみが使用されます

• どの1行も、単一のトランザクションで更新する必要があります

• 一括インポートは完全に不可能です

• 何千もの小規模なSQL文が発行されます

• ユーザー・アクセスの突然の高負荷ピーク

– たとえば期末セール、クリスマス・セール、特別セール、…

• 散発的に競合が発生


ホット・スポットの除去 – ユースケース

PoC（SKUデータ・ロード）からの結果

• リファレンス・システム：秒あたり120SKU

• Exadataマシン（単一ノード・ロード）

– 秒あたり2,500SKU（20倍高速)

• ExadataマシンX3-2（2ノード・ロードでパーティションなし）

– 秒あたり1,900SKUのみ（単一ノード・ロードより低速）

• ExadataマシンX3-2（2ノード・ロードで適切なパーティションあり）– 秒あたり4,800SKU（40倍高速)

• 適切なパーティション化により線形スケーリングが可能になります

アプリケーション・コード変更なしの場合のパフォーマンス



• ハッシュ・パーティション化により、表に<n>個のエントリ・ポイントが作成されます

方法（代替選択肢A、IDのハッシュ・パーティション化）

CREATE TABLE <table_name> ( ID NUMBER(10) NOT NULL,Cn ...)

PARTITION BY HASH(ID) PARTITIONS <n>TABLESPACE <tablespace_name> STORAGE ( ...);

CREATE UNIQUE INDEX <index_name> ON <table_name>(ID) LOCAL TABLESPACE <tablespace_name> STORAGE ( ...);

INSERT INTO <table_name> (ID, ...) SELECT SEQ_ID.nextval, ...;



• シーケンスSEQ_IDを使用すると、IDは各パーティション内で一意になります

• リスト・パーティション化は、エントリ・ポイントをインスタンスごとに完全に分離します

方法（代替選択肢B、インスタンス番号のリスト・パーティション化）

CREATE TABLE <table_name> ( ID NUMBER(10) NOT NULL,

Cn ... ...,INSTANCE_NUMBER NUMBER(1) DEFAULT sys_context('USERENV','INSTANCE') NOT NULL)

PARTITION BY LIST (INSTANCE_NUMBER)( PARTITION P1 VALUES(1),PARTITION P2 VALUES(2),...PARTITION Pn VALUES(n))

TABLESPACE <tablespace_name> STORAGE ( ...);

CREATE UNIQUE INDEX <index_name> ON <table_name>(ID, INSTANCE_NUMBER) LOCAL TABLESPACE <tablespace_name> STORAGE ( ...);

INSERT INTO <table_name> (ID, ...)SELECT SEQ_ID.nextval, ...;



• シーケンスSEQ_IDを使用すると、IDは各パーティション内で一意になります

方法（代替選択肢Bの強化、インスタンス番号のハッシュ・パーティション化）

CREATE TABLE <table_name> ( ID NUMBER(10) NOT NULL,

Cn ... ...,INSTANCE_NUMBER NUMBER(1) DEFAULT sys_context('USERENV','INSTANCE') NOT NULL)

PARTITION BY LIST (INSTANCE_NUMBER)SUBPARTITION BY HASH (ID) SUBPARTITIONS <m>( PARTITION P1 VALUES(1),PARTITION P2 VALUES(2),...PARTITION Pn VALUES(n))

TABLESPACE <tablespace_name> STORAGE ( ...);CREATE UNIQUE INDEX <index_name> ON <table_name>(ID, INSTANCE_NUMBER) LOCAL TABLESPACE <tablespace_name> STORAGE ( ...);INSERT INTO <table_name> (ID, ...)SELECT SEQ_ID.nextval, ...;


スマートな部分パーティション交換“フィルタ付きパーティション・メンテナンス”


ロードおよびパージのためのパーティション交換

• メタデータのみの操作としてデータを削除および追加します–パーティションと表のメタデータを交換します

• データ・ロード：スタンドアロン表にロード対象の新しいデータが含まれています

• データ・パージ：データを含むパーティションが空の表と交換されます

• パージの代替としてDropパーティションを行います–データは永久に失われます

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

<表>


スマートな部分パーティション交換

• 簡単そうですが…

• パーティション境界が100%揃っていない場合はどうしたらよいでしょうか?–“部分パージ”



• パージされるパーティションをロックします

部分パージ

LOCK TABLE ...PARTITION ... 2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表




• 残りのデータセットを含む表を作成します

部分パージ


2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

CREATE TABLE ...AS SELECT WHERE ...

“残り”





• もしあれば、必須の索引を作成します

部分パージ


2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表


“残り”





• もしあれば、必須の索引を作成します

• パーティションを交換します

部分パージ

LOCK TABLE ...PARTITION ... “残り”

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表


ALTER TABLE ...EXCHANGE PARTITION ...

2016年 5月18日


一意と主キー制約存在下での交換



• 一意索引により一意制約が適用されます

–主キー制約は列にNOT NULLを追加します

–表は主キーを1つのみ持てます（“一意の識別子”）

• パーティション表には、2つのタイプの索引があります


–グローバル索引（パーティションおよび非パーティション）


パーティション交換

• メタデータのみの操作としてデータを削除および追加します

–パーティションのメタデータを交換します

• どちらの表でも論理形態が同一であることが、交換成功のための必須の事前要件です–列の数とデータ型は同じ

• 列名は重要でないことに注意してください

–同一の制約

–索引の数と型は同じ

パーティションのロードとパージとも呼ばれる

交換表

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

2016年 5月24日空または新規データ


ローカル索引


• 交換表のいかなる索引も、ローカル・パーティション索引と同等です

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

<表>


ローカル索引


• 交換表のいかなる索引も、ローカル・パーティション索引と同等です

• パーティション表のPK索引がグローバル索引の実施を必要とする場合はどうしたらいいですか?–論理的に同一という要件を忘れないでください

2016年 5月18日

2016年 5月19日

2016年 5月20日

2016年 5月21日

2016年 5月22日

2016年 5月23日

売上表

<表>


パーティション交換とPK/一意制約

• グローバル索引は、パーティション表のためにのみ存在します–しかし、交換表の一意性のために索引が必要では…

ジレンマ



• グローバル索引は、パーティション表のためにのみ存在します–しかし、交換表の一意性のために索引が必要では…

• 一般的には正しくない–一意索引は制約がENABLE状態（新規データの制約チェック）のためにのみ必要です（存在します）

–新規または変更されたデータは索引プローブを介して制約チェックします

実際はジレンマでない



• グローバル索引は、パーティション表のためにのみ存在します

–しかし、交換表の一意性のために索引が必要では…

• 一般的には正しくない–一意索引は制約がENABLE状態（新規データの制約チェック）のためにのみ必要です

–新規または変更されたデータは索引プローブを介して制約チェックします

– DISABLE VALIDATE状態の制約はデータ挿入を防止します

実際はジレンマでない

SQL> alter table tt add(constraint x unique (col1) disable validate);

Table altered.

SQL> insert into tt values(1,2);insert into tt values(1,2);* ERROR at line 1;ORA-25128:No insert/update/delete on table with constraint (SCOTT.X) disabled and validated



• パーティション化されたターゲット表

–グローバル索引（パーティションまたは非パーティション）によってPKまたは一意制約を実施

• 交換するスタンドアロン表（“交換表”）–制約をDISABLE VALIDATE状態（既存データの制約チェックと新規データ不可）とする

–制約チェックのための索引なし、パーティション交換の問題なし

解決方法


パーティション交換とPK/一意制約簡単な例

SQL > CREATE TABLE tx_simple2 (3 TRANSACTION KEY NUMBER,4 INQUIRY_TIMESTAMP TIMESTAMP(6),5 RUN_DATE DATE6 )7 PARTITION BY RANGE (RUN_DATE)8 (9 PARTITION TRANSACTION_201605 VALUES LESS THAN (TO_DATE(‘20160601’, ‘yyyymmdd’)),10 PARTITION TRANSACTION_201606 VALUES LESS THAN (TO_DATE(‘20160701’, ‘yyyymmdd’)),11 PARTITION TRANSACTION_201607 VALUES LESS THAN (TO_DATE(‘20160801’, ‘yyyymmdd’)),12 PARTITION TRANSACTION_201608 VALUES LESS THAN (TO_DATE(‘20160901’, ‘yyyymmdd’)),13 PARTITION TRANSACTION_201609 VALUES LESS THAN (TO_DATE(‘20161001’, ‘yyyymmdd’)),14 PARTITION TRANSACTION_201610 VALUES LESS THAN (TO_DATE(‘20161101’, ‘yyyymmdd’)),15 PARTITION TRANSACTION_MAX VALUES LESS THAN (MAXVALUE)16 )17 /

Table created.




Table created.

SQL > INSERT into tx_simple (2 select object_id, LAST_DDL_TIME, 3 add months(TO_DATE(‘20160501’, ‘yyyymmdd’), mod(OBJECT_ID,

12))4 from DBA_OBJECTS5 where object_id is not null) 6 /

73657 rows created.




Table created.

SQL > INSERT into tx_simple (2 select object_id, LAST_DDL_TIME, 3 add months(TO_DATE(‘20160501’, ‘yyyymmdd’), mod(OBJECT_ID,

12))4 from DBA_OBJECTS5 where object_id is not null) 6 /

73657 rows created.

SQL > CREATE UNIQUE INDEX tx_simple_PK ON tx_simple (TRANSACTION_KEY) nologging2 GLOBAL PARTITION BY RANGE (TRANSACTION_KEY) (3 PARTITION P_Max VALUES LESS THAN (MAXVALUE)4 )5 /

Index created.

SQL > ALTER TABLE tx_simple ADD ( CONSTRAINT tx_simple_PK PRIMARY KEY (TRANSACTION_KEY)2 USING INDEX nologging);

Table altered.


パーティション交換とPK/一意制約簡単な例（続き）

SQL > alter table tx_simple2 exchange partition TRANSACTION_2016073 with table daily_ETL_table4 including indexes5 --excluding indexes6 WITHOUT VALIDATION7 UPDATE GLOBAL INDEXES8 /

Table altered.

SQL > create table DAILY_ETL_table2 as3 select * from tx_simple partition (TRANSACTION_201607);

Table created.

SQL > alter table daily_etl_table add ( constraint pk_etl primary key (transaction_key) disable validate);

Table altered.

oracle partitioningの能力を 最大限に活用する...•...

Documents

oracle partitioningの能力を最大限に活用する...•...