Oracle Database12c 新機能! 情報ライフサイクル管理の自動化第127回夜な夜な! なにわオラクル塾日本オラクル株式会社

Transcription

Presented with
第127回夜な夜な! なにわオラクル塾
Oracle Database12c 新機能!
情報ライフサイクル管理の自動化
日本オラクル株式会社
データベース事業統括
ソリューション本部
中部・西日本SC部
2014年07月16日
Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2
Program Agenda
1
ILMの課題とソリューション
2
パーティショニング
3
パーティションの新機能
4
ILMの新機能
3
4
ILM（Information Lifecycle Management）とは
• 同じ表でもアクセスが高い部分と低い部分を分割して運用管理する事に
よって、データを効率的に保存管理する考え方。
• これにより、大幅なコスト削減も可能
高アクセス
低アクセス
ハイパフォーマンス
ストレージ層
ローコスト
ストレージ層
履歴データ
オンラインアーカイブ
ストレージ層
アーカイブ
オフライン
アーカイブ
5
11g以前
ストレージコスト削減
 圧縮
− Basic圧縮
− OLTP圧縮
− Hybrid Columnar圧縮
 低コスト・ストレージへの移動
 使われなくなったデータのパージ
性能改善
安全なデータ
 パーティション（行移動）
 権限とビューの設定
 DB／Audit Vault の利用
 VPD／OLS の利用
 Flashback Data Archive の利用
 高性能ストレージへの移動
 監査／ファイングレイン監査の利用  データの暗号化
6
11g以前
ILMの構築
データ区分
経過時間に応じて決められた処理
スコープ
 ステージ① ：1ヶ月経過後
−
− 表
OLTP圧縮
 ステージ② ： 2ヶ月経過後
− 表パーティション
−
HCC圧縮＋低コスト・ストレージへ移動
 ステージ③ ： 11ヶ月経過後
−
HCC圧縮＋さらに低コスト・ストレージへ移動
 最終ステージ： 6年経過後 ⇒ パージ
ステージ
ステージ⓪
ステージ①
ステージ②
ステージ③
ストレージ層
高性能
高性能
低コスト
オンライン・アーカイブ
圧縮属性
なし
OLTP圧縮
HCC圧縮クエリー・モード
HCC圧縮アーカイブ・モード
期間
1カ月間
2か月間
11か月間
6年間
最終ステージ
パージ
7
12c
ILMの課題
ストレージコスト削減
安全なデータ
データ増
VS
I/O性能
 爆発的なデータ増
 規制による要件の増加
性能改善
 規制による要件の増加
8
12c
ILM ソリューション
ILM アクションの自動化
 ストレージ・コスト削減
▪ 実際のアクセス・パターンに応じて、最適なストレージ層に
データを配置することで、より効果的なストレージ管理
▪ 圧縮の利用による許容データ量の拡大
 性能改善
• 実際のアクセス・パターンに応じて、圧縮レベルの使い分け
適切なタイミングで実施
時間経過と共にアクセス頻度が低下するデータ
最も
アクティブ
アクティブ
•更新：低、検索：高
•HCC 圧縮クエリー・モード(10x)
•高性能ストレージ層
低頻度
•更新： ≒なし、検索：低
•HCC 圧縮クエリー・モード (10x)
•低コスト・ストレージ層
Automatic Data Optimization
▪
ユーザ定義のルール（ポリシー）に従って圧縮
▪
表領域が逼迫したら、利用頻度の低いものから移動
In-Database Archiving
•
行単位でのアーカイブ属性
•
行単位での有効期間属性
•最近作成／更新されたデータ
•Advanced Row Compression (2-4x) ※OLTP圧縮
•SSD またはメモリー内へのキャッシュ
休眠
•長期間データの分析／コンプライアンス用途
•HCC 圧縮アーカイブ・モード(15-50x)
•アーカイブ層 (DB or tape)
9
12c
ILMの構築
Automatic Data Optimization ／ Heat Map
データ区分
何を？
自動検知
アクセスパターンがどうなった時？
スコープ
 行レベル
自動実行
ILM 操作は？
アクション
起動条件
 追跡対象の操作は？
 セグメントレベル
−
Creation
 表領域レベル
−
Access
 グループ・レベル
−
Modification
 圧縮
−
段階的に高い圧縮レ
ベルを適用
 タイミングは？
−
After n days
−
After n year
−
Tablespace full
 移動
−
低コストストレージへ
の移動
 圧縮＋移動
10
パーティショニング
11
パーティショニングとは？
大きな表や索引をデータベース内部で
複数の領域に分割して管理する
通常の１つの表
パーティション化された表
1月
4月
２月
３月
5月
6月
内部的に
表を分割
検索したいデータが一部でも、
表全体または索引を利用してアクセス
検索したいデータが格納されている
パーティションにのみアクセス
各種メンテナンス作業も
表全体に影響が及んでしまう
各種メンテナンス作業も
パーティション単位で実施可能
12
アプリケーションの変更が不要！
• クライアント側では特に意識することなく、対象のデータが格納されている
パーティションだけにアクセスすることが可能
emp表
• テーブル構造の変更も必要なし
0～999
⇒ アプリケーションの変更が発生しない!
(emp_id)
社員番号1000番のデータ
が見たい
1000～1999
(emp_id)
2000～2999
オプティマイザ
(emp_id)
3000～3999
SELECT * FROM emp
WHERE emp_id = 1000;
(emp_id)
13
このような売上表をパーティショニングすると…
売上日
製品
支店
顧客名
売上
・・・
2013/04/03
液晶テレビ
丸の内
井上憲三郎
¥183,620
・・・
2013/04/03
液晶テレビ
丸の内
椛田正臣
¥43,3800
・・・
2013/04/04
炊飯器
神奈川
藤田佳子
¥26,320
・・・
2013/04/05
携帯電話
井上あつし
¥23,620
・・・
多摩
・・
・
2013/06/26
腕時計
・・
・
2013/12/31
・・
・
電気ポット
・・
・
埼玉
・・
・
影山治子
2014/01/01
携帯電話
新潟
山本健
・・
・
・・
・
・・
・
・・
・
丸の内
・・
・
・・
・
・
・
・
・・
・
松沢惇
¥155,490
・・
・
・
・
・
・・
・
・・
・
・・・
¥25,400
・・・
¥23,620
・・・
・
・
・
14
DB内部で分割して管理します
売上日
製品
支店
顧客
売上
・・・
2013/01/03
液晶テレビ
丸の内
井上憲三郎
¥83,620
・・・
2013/02/12
液晶テレビ
丸の内
椛田正臣
¥43,380
・・・
2013/03/19
炊飯器
神奈川
藤田佳子
¥96,320
・・・
2013年Q1
売上日
製品
支店
顧客名
売上
・・・
2013/01/03
液晶テレビ
丸の内
井上憲三郎
¥83,620
・・・
2013/02/12
液晶テレビ
丸の内
椛田正臣
¥43,380
・・・
2013/03/19
炊飯器
神奈川
藤田佳子
¥96,320
・・・
2013/04/05
携帯電話
井上あつし
¥43,620
・・・
¥155,490
・・・
¥265,420
・・・
¥35,830
・・・
多摩
・
・・
・
・・
2013/06/26
腕時計
・・
・
・
・・
丸の内
・・
・
・
・
・
松沢惇
・・
・
・
・
・
2013/10/31
電気ポット
埼玉
影山治子
2013/11/20
携帯電話
新潟
山本健
・・
・
・・
・
・・
・
・
・
・
・
・
・
売上日
製品
支店
売上
・・・
2013/04/05
携帯電話
丸の内
井上あつし
¥33,620
・・・
2013/05/03
液晶テレビ
丸の内
田中大輔
¥43,380
・・・
2013/06/26
炊飯器
千葉由
¥96,320
・・・
埼玉
2013年Q2
・・
・
・
・
・
・
・
・
顧客
売上日
製品
支店
顧客
売上
・・・
2013/10/31
携帯電話
丸の内
影山治子
¥83,620
・・・
2013/11/20
液晶テレビ
丸の内
山本健
¥43,380
・・・
2013/12/20
炊飯器
林順
¥96,320
・・・
埼玉
2013年Q4
アプリケーションから見たら
1つの表ですが…
内部的には表を分割して管理します
15
表・パーティションの種類
• 単一レベル・パーティション
– レンジ・パーティション
– リスト・パーティション
– ハッシュ・パーティション
• コンポジット・パーティション
サブ
メ
イ
ン
レンジ
リスト
ハッシュ
レンジ
11g
9i
8i
リスト
11g
11g
11g
• パーティション化の拡張
– インターバル・パーティション
– リファレンス・パーティション
– バーチャルカラム・パーティション
16
レンジ・パーティション
リスト・パーティション
ハッシュ・パーティション
• 値の範囲でデータを分割する
特定の連続するデータ（売上日、ログ取得日 etc）の範囲によって分割
※パーティションキーが文字の場合、文字の各バイトのバイナリ値の範囲で区切られます
売上表
2013年 1～3月
(orderdate)
2013年 4～6月
(orderdate)
2013年 7～9月
(orderdate)
2013年 10～12月
(orderdate)
17
• レンジ・パーティションのメリット
履歴管理がしやすい
パーティション・プルーニングによる範囲検索の高速化
（例）
・売上データを日付単位、週単位、月単位で管理
・従業員表の従業員番号など、順序付けられた番号の範囲で管理
・アルファベット順に並べられたデータのアルファベットの範囲で管理
売上表
2013年 1～3月
Sales_p1
(orderdate)
2013年 4～6月
Sales_p2
(orderdate)
2013年 7～9月
Sales_p3
(orderdate)
2013年 10～12月
(orderdate)
Sales_p4
18
• 値の集合でデータを分割する
特定のデータ（製品名、店舗名 etc）のカテゴリーによって分割
売上表
東京
神奈川
大阪
京都
福岡
長崎
宮城
青森
関東パーティション
近畿パーティション
九州パーティション
東北パーティション
19
• リスト・パーティションのメリット
不連続な値の集合を管理できる
関連もなく順序づけもされていないデータのセットを、自然な形でグループ化して管
理できる
（例）
・売上履歴データを支店ごとに管理
・仕入履歴データを商品ごとに管理
・ログデータを支社ごとに管理
売上表
東京
神奈川
大阪
京都
関東パーティション
近畿パーティション
福岡
長崎
九州パーティション
宮城
青森
東北パーティション
20
• パーティションにデータを均等に配分する
内部的に生成されるハッシュ値を使って、データを分割する
売上表
ハッシュ値1
ハッシュ値2
ハッシュ値3
ハッシュ値4
21
• ハッシュ・パーティションのメリット
Partition Size
レンジ、リストパーティション
データ量に差があるため、
各パーティションサイズが均等ではない
P1
1－3月
P2
4－6月
P3
7－9月
P4
10－12月
ハッシュパーティション
パラレル
プロセス
パラレル
プロセス
パラレル
プロセス
パラレル
プロセス
各パーティションサイズがほぼ均等になる
Partition Size
パラレルDMLなどのパフォーマンスが最適化できる
P1
P2
P3
P4
22
レンジ-リスト・コンポジット・パーティション
• レンジ・パーティションをさらにリスト・パーティションに分割
例えば、売上表を「期間」（レンジ）と「地域」（リスト）で分割する
リスト・サブパーティション
東京
神奈川
大阪
京都
福岡
長崎
宮城
青森
2013年 1～3月
売上表
(orderdate)
2013年 4～6月
(orderdate)
2013年 7～9月
(orderdate)
2013年 10～12月
(orderdate)
23
レンジ-リスト・コンポジット・パーティション
• レンジ-リスト・コンポジット・パーティションの使用例
【メンテナンス要件】
– 毎日各支店ごとにデータローディング
【検索要件】
・全支店横断的に検索
・ 1日単位、1週間単位、1ヶ月単位、
四半期単位などの売上を集計
支店ごとの売上
データの集計
A支店
B支店
C支店
D支店
毎日支店ごとに
データローディング
2013年 6月1日
(orderdate)
2013年 6月2日
(orderdate)
2013年 6月3日
全支店横断的に検索
(orderdate)
2013年 6月4日
(orderdate)
24
レンジ-ハッシュ・コンポジット・パーティション
• レンジ・パーティションをさらにハッシュ・パーティションに分割
ハッシュ・サブパーティション
ハッシュ値1
ハッシュ値2
ハッシュ値3
ハッシュ値4
売上表
2013年 4～6月
(date)
2013年 7～9月
(date)
2013年 10～12月
(date)
2014年 1～3月
(date)
25
レンジ-ハッシュ・コンポジット・パーティション
• レンジ-ハッシュ・コンポジット・パーティションの使用例
• 【メンテナンス要件】
– バッチ処理が頻繁に走る
• 【検索要件】
バッチ処理
– 1日、1週間、1ヶ月、四半期単位での範囲指定の検索が必要
ハッシュ・パーティションにより
各パーティションのデータ量が均一の為、
パラレルでのバッチ処理が高速化
パラレル
プロセス
ハッシュ値１
パラレル
パラレル
パラレル
プロセス
ハッシュ値２
ハッシュ値３
ハッシュ値４
プロセス
プロセス
2013年 1～3月
(date)
2013年 10～12月
(date)
2013年 7～9月
(date)
2013年 4～6月
(date)
26
レンジ-レンジ・コンポジット・パーティション
• レンジ・パーティションを2段階設定
「受注日付」と「出荷日付」のように、時系列データを複数持つ場合に有効
レンジ・サブパーティション
売上表
2013年
4～6月
2013年
7～9月
2013年
10～12月
2014年
1～3月
(shipdate)
(shipdate)
(shipdate)
(shipdate)
2013年 4～6月
(oderdate)
2013年 7～9月
(oderdate)
2013年 10～12月
(oderdate)
2014年 1～3月
(oderdate)
27
リスト-レンジ・コンポジット・パーティション
• リストとレンジ・パーティションを組み合わせて設定
地域別や担当者別のように不連続値で分割したデータを、
レンジ・サブパーティション
さらに時系列で分割する場合に有効
売上表
2013年
4～6月
2013年
7～9月
2013年
10～12月
2014年
1～3月
(oderdate)
(oderdate)
(oderdate)
(oderdate)
東京
神奈川
大阪
京都
福岡
長崎
青森
宮城
28
リスト-リスト・コンポジット・パーティション
• リスト・パーティションを2段階設定
地域別、販売チャネル別、担当営業別等、複数の不連続値を複数持つ場合に有効
直接販売
間接販売
カタログ販売
ネット
販売
売上表
東京
神奈川
大阪
京都
福岡
長崎
青森
宮城
29
リスト-ハッシュ・コンポジット・パーティション
• リストとハッシュ・パーティションを組み合わせて設定
ハッシュ値1
ハッシュ値2
ハッシュ値3
ハッシュ値4
売上表
東京
神奈川
大阪
京都
福岡
長崎
青森
宮城
30
31
1. 複数パーティションへの対応
2. パーシャル索引
3. グローバル索引メンテナンスの非同期実行
4. インターバル・リファレンス・パーティショニング
5. リファレンス・パーティションの CASCADE 処理
6. オンラインでのパーティションの移動
7. XMLIndex の対応拡張
32
1
複数パーティションへの対応
一つのコマンドで複数パーティションへをメンテナンス
11g 複数のパーティションのメンテナンスは
パーティション毎にコマンド実行が必要
12c 複数のパーティションのメンテナンスを
一つのコマンドで一括して実行可能
パーティション表
(ex) 3つのパーティションの削除は
DROP PARTITION を3回実行
drop partition
Partition P02
drop partition
Partition P03
drop partition
Partition P04
(ex) 3つのパーティションの削除は
DROP PARTITION を1回実行
拡張された処理
DROP / ADD / TRUNCATE / MERGE /
SPLIT
Partition P01
Partition1
Partition2
drop partition
Partition3
Partition4
33
複数パーティションへの一括処理
1
実行コマンドの例
• ADD PARTITION
ALTER TABLE parttab ADD
PARTITION p11 VALUES LESS THAN (111),
PARTITION p12 VALUES LESS THAN (121),
PARTITION p13 VALUES LESS THAN (131);
• DROP PARTITION
ALTER TABLE parttab DROP PARTITION p02, p03, p04;
• TRUNCATE PARTITION
ALTER TABLE parttab TRUNCATE PARTITION p01, p02, p03;
34
複数パーティションへの一括処理
1
実行コマンドの例
• MERGE PARTITION
ALTER TABLE parttab MERGE PARTITIONS p11, p12, p13
INTO PARTITION p10;
• SPLIT PARTITION
ALTER TABLE
( PARTITION
PARTITION
PARTITION
PARTITION
parttab SPLIT p10 INTO
p11 VALUES LESS THAN (111),
p14 );
35
2
パーシャル索引
特定のパーティション/サブパーティションに対する索引の作成
• パーシャル索引
– 特定のパーティションのみに作成する索引
アクセス頻度が低い
パーティション
未使用だが削除不可な
パーティション
索引未作成
Partition P01
Partition P02
Partition P03
索引作成
Partition P04
◆ 索引付けを行わない
・ DISK領域の削減
・統計情報取得時間削減
36
2
パーシャル索引とは
• パーシャル索引
– パーティション/サブパーティション毎に設定した
INDEXING 属性のON / OFF で制御
– 索引作成時に INDEXING PARTIAL を指定
– ローカル索引・グローバル索引の両方で
使用可能
– 索引作成後に、INDEXING 属性を変更する
ことも可能
索引未作成
INDEXING OFF
Partition P01
INDEXING OFF
Partition P02
INDEXING ON
Partition P03
INDEXING ON
Partition P04
索引作成
• 動的な索引付け・排除が可能
37
2
パーシャル索引の作成方法
• パーシャル索引の作成
– パーティション表作成時に INDEXING を指定
– 索引作成時に INDEXING PARTIAL を指定
CREATE TABLE parttab (c1 number, c2 number)
PARTITION BY RANGE(c1)
(PARTITION p01 VALUES LESS THAN (10001) INDEXING OFF,
PARTITION p02 VALUES LESS THAN (20001) INDEXING OFF,
PARTITION p03 VALUES LESS THAN (30001) INDEXING ON,
PARTITION p04 VALUES LESS THAN (maxvalue));
索引未作成
INDEXING OFF
Partition P01
INDEXING OFF
Partition P02
INDEXING ON
Partition P03
INDEXING ON
Partition P04
索引作成
CREATE INDEX parttab_ind1 ON parttab(c1) LOCAL INDEXING PARTIAL;
CREATE INDEX parttab_ind2 ON parttab(c2) GLOBAL INDEXING PARTIAL;
38
2
パーティション/サブパーティションの指定と索引の指定
• パーティション表、索引での INDEXING 属性指定による
索引の作成状況の違い
索引未作成
索引作成
デフォルト値に依存
パーティション/サブパーティションでの指定
INDEXING OFF
索
引
で
の
指
定
INDEXING ON
INDEXING 未指定
INDEXING
PARTIAL
INDEXING FULL
INDEXING 指定なし
39
3
グローバル索引メンテナンスの非同期実行
DROP/TRUNCATE PARTITION でのグローバル索引のメンテナンス
• DROP/TRUNCATE PARTITION 文で UPDATE INDEXES を指定した場合の
グローバル索引のメンテナンス処理を非同期に実行
– SYS.PMO_DEFERRED_GIDX_MAINT_JOB のジョブが索引データを更新
– UPDATE INDEXES 未指定時は、11g と同様に索引が UNUSABLE となる
drop partition P03
索引データの更新
[ AM 02:00 ]
Job
drop partition P03
Part P01
Part P02
Part P03
UPDATE INDEXES
Global Index
◆ 非同期メンテナンス
• メタデータのみ更新
することで高速化
メタデータのみ更新
40
3
• 自動メンテナンス
– ジョブにより毎日 AM2時にメンテナンス処理を実行
– ジョブのスケジュールの手動での変更は可能
• ジョブの削除は非推奨
• 対象外のケース : 11g と同様の動作となる
– オブジェクト型を含む表
– ドメイン索引を含む表
– SYS スキーマの表
• ユーザが新規に作成した表も含む
41
3
• 手動でのメンテナンス
– 一括メンテナンス (DB全体)
SQL> EXECUTE DBMS_PART.CLEANUP_GIDX;
– スキーマ単位でのメンテナンス
SQL> EXECUTE DBMS_PART.CLEANUP_GIDX ('SCOTT');
– 表単位でのメンテナンス
SQL> EXECUTE DBMS_PART.CLEANUP_GIDX ('SCOTT', 'PARTTAB');
– 索引単位でのメンテナンス
SQL> ALTER INDEX parttab_ind_global COALESCE CLEANUP;
– ジョブの実行
SQL> EXECUTE
DBMS_SCHEDULER.RUN_JOB('PMO_DEFERRED_GIDX_MAINT_JOB');
42
3
• メンテナンス必要性の判断
– *_INDEXES の ORPHANED_ENTRIES 列から確認可能
実行例
SQL> select table_name, index_name,partitioned,status,orphaned_entries
from user_indexes;
TABLE_NAME INDEX_NAME
PARTITIONED STATUS
ORPHANED_ENTRIES
---------- ------------------ ----------- -------- ---------------PARTTAB
PARTTAB_IND_GLOBAL NO
VALID
NO
メンテナンス不要
SQL> ALTER TABLE parttab TRUNCATE PARTITION p01 UPDATE GLOBAL INDEXES;
SQL> select table_name, index_name,partitioned,status,orphaned_entries
from user_indexes;
TABLE_NAME INDEX_NAME
PARTITIONED STATUS
ORPHANED_ENTRIES
---------- ------------------ ----------- -------- ---------------メンテナンスが必要
PARTTAB
PARTTAB_IND_GLOBAL NO
VALID
YES
43
4
インターバル・リファレンス・パーティショニング
リファレンス・パーティションの親表をインターバル・パーティションで作成可
◆ 親表
Orders
表名
列名
order_id
Ordes
◆ リファレンス・パーティション
12c • インターバル・パーティションを
親表とした構成をサポート
customer_id
自動的に追加
order_date
パーティション・キー
◆ 子表
OrderItems
表名
列名
参照整合性制約
orderitems_fk
Y2012Q3
Y2012Q4
order_id
OrderItems
Y2013Q1
Y2013Q2
自動的に追加
line_item_id
product_id
quantity
パーティション・キー不要
Y2012Q3
Y2012Q4
Y2013Q1
Y2013Q2
44
5
リファレンス・パーティションの Cascade 処理
1. CASCADE での TRUNCATE PARTITION
◆ 親表
Orders
表名
列名
order_id
Ordes
12c • 親表への TRUNCATE 時に
子表への TRUNCATE を自動実行
customer_id
TRUNCATE
order_date
ON DELETE
CASCADE
◆ 子表
OrderItems
表名
列名
orderitems_fk
CASCADE
Y2012Q3
Y2012Q4
order_id
OrderItems
Y2013Q1
TRUNCATE
line_item_id
product_id
quantity
Y2012Q3
Y2012Q4
Y2013Q1
45
5
リファレンス・パーティションの Cascade 処理
2. CASCADE での EXCHANGE PARTITION
表名
列名
order_id
Orders
(親表)
12c
• 親表への EXCHANGE 時に
子表への EXCHANGE を自動実行
customer_id
order_date
表名
order_id
Y2013Q1_P
(親表)
列名
Y2013Q1_fk
Y2012Q3
Y2012Q4
Y2013Q1
CASCADE
表名
order_id
OrderItems
(子表)
customer_id
order_date
EXCHANGE
orderitems_fk
表名
列名
列名
order_id
line_item_id
Y2013Q1_S
(子表)
product_id
EXCHANGE
quantity
Y2012Q3
Y2012Q4
line_item_id
product_id
quantity
Y2013Q1
46
オンラインでのパーティションの移動
6
オンラインでのパーティションの移動
• DML 実行中の ALTER TABLE .. MOVE PARTITION / SUBPARTITION
の実行が可能に
実行例
SQL> ALTER TABLE parttab MOVE PARTITION p01 TABLESPACE newtbs ONLINE;
SQL> ALTER TABLE parttab MOVE SUBPARTITION p01_s01 TABLESPACE newtbs
ONLINE;
• 制限 : ONLINE で実行できないケース
– 以下の表に対する処理は実行不可
•
•
•
•
SYS スキーマの表
索引構成表
オブジェクト型の列を持つヒープ構成表
ビットマップ索引 / ビットマップ結合索引 / ドメイン索引が作成されている表
– データベースでサプリメンタル・ロギングが設定されている場合
47
7
XMLIndex の対応拡張
XMLIndex 作成可能なパーティショニング・メソッドの追加
• XMLType 表 / XMLType 列を含む表のパーティション化
– ハッシュ / インターバル・パーティションにも XMLIndex の作成が可能に
パーティショニング・メソッド
11g
12c
レンジ
リスト
ハッシュ
インターバル
◆ XMLType 表 / XMLType 列を含む表のパーティショニング
メソッドによる XMLIndex 作成の可否
48
ILMの新機能
～データの移動・圧縮の自動化～
49
ILM の新機能～データの移動・圧縮の自動化～
• Automatic Data Optimization
– ILMアクション（圧縮／移動）と、そのアクションをどのタイミングで実行するかをポリ
シーとして設定し自動実行
• Heat Map
– データへのアクセスパターン、アクセス頻度を記録・管理
50
Automatic Data Optimization とは
概要
• Automatic Data Optimization（以下ADO）では、ILM処理（移動・圧縮）と起動
条件をポリシーとして定義し、ILM処理を自動実行
– 移動は表領域の利用率に応じて実施
– 圧縮はアクセスパターンの変化に応じて実施
– 実施条件は上記のデフォルトの記述方法に加え、PL/SQLファンクション
を使ったカスタム条件の利用も可能
• Heat Map機能では、データへのアクセスパターンとそのアクセスが最後に発
生した日時を記録
– ADOポリシーが起動タイミングを自動検知するために利用
51
動作の仕組み
1
DBA
3
初期化パラメータ HEAT_MAP = ON
圧縮ポリシーの作成
V$HEAT_MAP_SEGMENT
SGA
ディクショナリー
1時間毎にフラッシュ
2
DB サーバー
Real Time
ILM処理の登録
Rowレベルポリシー以外
メンテナンス
Window
DBA_HEAT_MAP_SEGMENTS
アクセス統計の収集
移動ポリシーの作成
4
ポリシー
評価・実行
MMON
HEAT_MAP_STAT$ 表
15分毎（Rowレベルポリシーのみ）
データへのアクセス
ステージ⓪
一般ユーザー
ステージ①
ステージ②
ステージ③
ストレージ
高性能
高性能
低コスト
アーカイブ
圧縮
なし
OLTP圧縮
HCC圧縮
：クエリー
HCC圧縮
：アーカイブ
最終ステージ
52
1
1
DBA
3
V$HEAT_MAP_SEGMENT
SGA
2
DB サーバー
Real Time
ILM処理の登録
メンテナンス
Window
4
ポリシー
評価・実行
MMON
HEAT_MAP_STAT$ 表
ステージ⓪
一般ユーザー
ステージ①
ステージ②
ステージ③
ストレージ
高性能
高性能
低コスト
アーカイブ
圧縮
なし
OLTP圧縮
HCC圧縮
：クエリー
HCC圧縮
：アーカイブ
最終ステージ
53
1
①初期化パラメータの設定
• Heat Map 情報の収集を有効にするためSYSTEMレベルで初期化パラメー
タを設定
• この設定により SYSTEM および SYSAUX 表領域以外に格納されているオ
ブジェクトへのアクセス追跡を開始
• セッションレベルでも設定可能
– この場合は、アクセス統計の収集（Heat Map機能）のみが有効化／無効化
54
2
1
DBA
3
V$HEAT_MAP_SEGMENT
SGA
2
DB サーバー
Real Time
ILM処理の登録
メンテナンス
Window
4
ポリシー
評価・実行
MMON
HEAT_MAP_STAT$ 表
ステージ⓪
一般ユーザー
ステージ①
ステージ②
ステージ③
ストレージ
高性能
高性能
低コスト
アーカイブ
圧縮
なし
OLTP圧縮
HCC圧縮
：クエリー
HCC圧縮
：アーカイブ
最終ステージ
55
2
②アクセス統計（Heat Map）の自動収集
• 初期化パラメータ HEAT_MAP=ON の設定レベルによる設定範囲の違い
– SYSTEMレベル
– SESSIONレベル
データ区分
何を？
スコープ
：ADOの機能も同時に有効化／無効化
：Heat Map機能のみ有効化／無効化
自動検知
アクセスパターンがどうなった時？
起動条件
「売上データ」へのアクセスパターンと頻度
自動実行
ILM 操作は？
アクション
56
2
②Heat Map情報のモニター：セグメント・レベル
• DBA_HEAT_MAP_SEGMENT より戻される最終アクセス日時の例 :
最終アクセス日時 : 14 : 00
最終アクセス日時 : 13 : 00
最終アクセス日時 : SYSDATE
最終アクセス日時 : SYSDTAE
インスタンス
起動
フラッシュ
フラッシュ
フラッシュ
12 : 00
13 : 00
14 : 00
15 : 00
セグメントへのアクセス(1回目)
12 : 10
セグメントへのアクセス(2回目)
13 : 30
57
2
View によるモニター
• DBA_HEAT_MAP_SEG_HISTOGRAM
• DBA_HEAT_MAP_SEGMENT
• V$HEAT_MAP_SEGMENT
58
2
• セグメント・レベルの最終アクセス日時
• 1時間毎にV$HEAT_MAP_SEGMENTの情報がDBA_HEAT_MAP_SEGMENTへフラッシュされるため
DBA_HEAT_MAP_SEGMENTより戻される最終アクセス日時の値は、最終アクセス後にフラッシュが行われた日時となる
• DBA_HEAT_MAP_SEGMENTを問い合わせた時点で、最終アクセス後にフラッシュが実施されていない
場合は問い合わせ時点の日時(SYSDATE)が戻される
59
2
②Heat Map情報のモニター：ブロック・レベル
PL/SQL関数によるモニター
• DBMS_HEAT_MAP.BLOCK_HEAT_MAP
60
2
②Heat Map情報のモニター：エクステント・レベル
PL/SQL関数によるモニター
• DBMS_HEAT_MAP.EXTENT_HEAT_MAP
61
2
②Heat Map情報のモニター：アクセス・ランキング（表領域・レベル）
SQL> SELECT TABLESPACE_NAME, SEGMENT_COUNT
2
, ALLOCATED_BYTES, MAX_WRITETIME
2
, MAX_READTIME, MAX_FTSTIME,
MAX_LOOKUPTIME
3 FROM DBA_HEATMAP_TOP_TABLESPACES;
TABLESPACE_NAME
SEGMENT_COUNT ALLOCATED_BYTES MAX_WRIT MAX_READ
-------------------- ------------- --------------- -------- -------HIGH_PERF_TBS
3
33554432 13-06-04 13-06-04
USERS
19
76349440 13-06-04 13-06-03
MAX_FTST
-------13-06-04
13-06-04
MAX_LOOK
-------13-05-31
13-06-03
62
2
②Heat Map情報のモニター：アクセス・ランキング（オブジェクト・レベル）
SQL> SELECT OWNER, OBJECT_NAME, SEGMENT_COUNT
2
, OBJECT_SIZE, MAX_WRITETIME, MAX_READTIME
3
, MAX_FTSTIME, MAX_LOOKUPTIME
4 FROM DBA_HEATMAP_TOP_OBJECTS;
OWNER
---------ILM
ILM
ILM
MIGUSER
MIGUSER
MIGUSER
MIGUSER
OBJECT_NAME
SEGMENT_COUNT OBJECT_SIZE MAX_WRIT MAX_READ MAX_FTST MAX_LOOK
------------- ------------- ----------- -------- -------- -------- -------SALES3_PT
2
16 13-06-04 13-06-04
NOTMOVE
1
15 13-06-04
SALES3_PT
2
16 13-06-04 13-06-04
SALGRADE
1
.0625 13-06-03
EMP
1
.0625 13-06-03
DUMMY
1
.0625 13-06-03
DEPT
1
.0625 13-06-03
63
3
1
DBA
3
V$HEAT_MAP_SEGMENT
SGA
2
DB サーバー
Real Time
ILM処理の登録
メンテナンス
Window
4
ポリシー
評価・実行
MMON
HEAT_MAP_STAT$ 表
ステージ⓪
一般ユーザー
ステージ①
ステージ②
ステージ③
ストレージ
高性能
高性能
低コスト
アーカイブ
圧縮
なし
OLTP圧縮
HCC圧縮
：クエリー
HCC圧縮
：アーカイブ
最終ステージ
64
3
③ADOポリシーの作成
• 宣言型ポリシー設定: （圧縮）
ALTER TABLE sales ILM ADD POLICY
圧縮タイプ
ROW STORE COMPRESS ADVANCED
ROW AFTER 3 DAYS OF NO MODIFICATION;
実行レベル
圧縮タイプ
起動タイミング
実行レベル
圧縮タイプの指定処理対象
（スコープ）
アクセスパターン
アクセスの状態
指定された「アクセ
スパターン」となって
からの時間
65
3
圧縮タイプ
圧縮タイプ
• 圧縮タイプの指定
− ROW STORE COMPRESS （Basic 圧縮）
− ROW STORE COMPRESS ADVANCED （Advanced Row 圧縮）
− COLUMN STORE COMPRESS FOR QUERY LOW/HIGH （HCC Query モード）
− COLUMN STORE COMPRESS FOR ARCHIVE LOW/HIGH （HCC Archive モード）
66
3
実行レベル
実行レベル
• 処理対象（スコープ）の指定
− Tablespace ---> 格納されるオブジェクトのデフォルトとして設定される
− Group ---> 対象オブジェクトの索引やLOBも含めてILM 処理を適用する
− Segment ---> 表／パーティション／サブパーティション
− Row ---> ブロック単位の処理（Advanced Row圧縮のみ指定可能）
67
3
• アクセスの状態
− NO MODIFICATION ---> Insert/Updata/Delete が無い
− NO ACCESS ---> Insert/Update/Delete/Select が無い
− CREATION ---> セグメントの作成
− ・・・
68
3
• 指定された「アクセスパターン」となってからの時間
− n DAY[s]
− n MONTH[s]
− n YEAR[s]
69
3
• 宣言型ポリシー設定: （移動）
TIER TO Low_Cost_tbs;
移動タイプ
移動先
移動タイプ
移動先
TIER TO のみ
表領域を指定
70
3
• 宣言型ポリシー設定: （カスタム・ポリシー）
ALTER TABLE emp ILM ADD POLICY
SEGMENT ON custom_ilm_rules;
ユーザー定義のPL/SQL関数を利用
TIER TO users ON custom_ilm_rules;
PL/SQLを使って起動条件をカスタマイズ
71
3
• ポリシーの継承
– 表領域に設定されたポリシー
• 格納される表・パーティションに継承（既存の表・パーティションには継承されない）
• 表・パーティションに作成されているポリシーが優先
– 表に設定されたポリシー
• パーティションに継承（既存のパーティションにも継承される）
• パーティションに作成されているポリシーが優先
72
3
設定可能なアクションとアクセスパターンの組合せ
Acc Pattern
No modification
Creation
No Access
Tablespace fullness
Custom Policy
Act (Scope)
Compression(Row)
✔
Compression(Segment)
✔
✔
Compression(Group)
✔
✔
Compression(Tablespace)
✔
✔
✔
✔
Storage Tiering(Segment)
✔
Storage
Tiering(Tablespace)
✔
✔
73
3
③ADOポリシーの作成：表領域レベル／グループレベル
• 表領域レベル：圧縮ポリシー
• グループレベル：圧縮ポリシー
74
3
③ADOポリシーの作成：セグメントレベル／行レベル
• セグメントレベル：圧縮ポリシー
• 行レベル：圧縮ポリシー
75
4
動作の仕組み
1
DBA
3
V$HEAT_MAP_SEGMENT
SGA
2
DB サーバー
Real Time
ILM処理の登録
メンテナンス
Window
4
ポリシー
評価・実行
MMON
HEAT_MAP_STAT$ 表
ステージ⓪
一般ユーザー
ステージ①
ステージ②
ステージ③
ストレージ
高性能
高性能
低コスト
アーカイブ
圧縮
なし
OLTP圧縮
HCC圧縮
：クエリー
HCC圧縮
：アーカイブ
最終ステージ
76
4
④ポリシーの評価・実行
• 自動実行
– MMON（15分毎）
– メンテナンスWindow
：処理対象が Row のポリシーのみ
：処理対象が Row のポリシー以外
• 強制実行
– DBMS_ILM.EXECUTE_ILM(
owner
object_name
task_id
subobject_name
policy_name
execution_mode
IN
IN
OUT
IN
IN
IN
VARCHAR2,
VARCHAR2,
NUMBER,
VARCHAR2 DEFAULT NULL,
VARCHAR2 DEFAULT ilm_all_policies,
NUMBER DEFAULT ilm_execution_online)
77
4
• DBA_ILMRESULTS
SQL>
2
3
4
5
SELECT task_id, policy_name, object_name, subobject_name,
selected_for_execution, job_name
FROM DBA_ILMEVALUATIONDETAILS
WHERE object_name = 'SALES2_PT'
ORDER BY task_id;
TASK_ID
---------3580
3580
3580
3580
POLICY_NAME
--------------P1734
P1734
P1734
P1734
OBJECT_NAME
--------------SALES2_PT
SALES2_PT
SALES2_PT
SALES2_PT
SUBOBJECT_NAME
-------------------SALES2_PT_Q1_2012
SALES2_PT_Q4_2012
SALES2_PT_Q3_2012
SALES2_PT_Q2_2012
SELECTED_FOR_EXECUTION
JOB_NAME
------------------------------ ---------SELECTED FOR EXECUTION
ILMJOB4762
PRECONDITION NOT SATISFIED
78
4
• DBA_ILMRESULTS
SQL>
2
3
4
5
6
7
8
SSELECT task_id, job_name, job_state
,TRUNC(start_time) start_time
,TRUNC(completion_time) completion_time
FROM DBA_ILMRESULTS
WHERE job_name IN
(SELECT job_name FROM DBA_ILMEVALUATIONDETAILS
WHERE object_name = 'SALES2_PT')
ORDER BY job_name;
TASK_ID JOB_NAME
JOB_STATE
START_TIME COMPLETION
---------- ------------- ---------------------- ---------- ---------3446 ILMJOB4566
COMPLETED SUCCESSFULLY 13-05-27
13-05-27
79
制限事項
ILM 新機能の制限事項
• ADO および Heat Map は、CDB/PDB では非サポート
• 処理対象が Row のADOポリシーは、Temporal Validity では非サポート
• 期間の終端を示す列でパーティション化されているセグメント・レベルのポリシーの場合はサポート
• 処理対象が Row のADOポリシーは、In-Database Archiving では非サポート
• ただし ORA_ARCHIVE_STATE 列でパーティション化されているセグメント・レベルのポリシーの場合はサポート
• カスタム・ポリシー（ユーザー定義の関数利用）は、表領域レベルでは非サポート
• ADOは、移動を実施する際、移動先表領域の空き容量をチェックしない
• ADOは、オブジェクト型を持つ表やマテリアライズド・ビューでは非サポート
• ADOのジョブ実行の同時実行性は、Oracle Scheduler の同時実行性に依存
• ADOのジョブが2回以上失敗した場合、ジョブが無効とされるため、手動メンテナンスが必要
• ADOのポリシー（処理対象が Row 以外）は、メンテナンスWindow のオープン期間内のみで評価・実行
• 期間外でも強制実行は可能
• 移動を行うADOポリシーでは、表や表パーティションのMOVE句と同じ制約を受けます
• Temporal Validity は、CDB/PDBでは非サポート
80
その他の新機能
81
その他の新機能
• データ圧縮
• OLTP表圧縮の機能拡張
• ネットワーク圧縮
82
データ圧縮
Oracle Advanced Compression
• 格納データ量：約1/2から1/3（ストレージ容量の節約）
• ディスクI/O量が減り、性能向上
更新処理時間の検証
検索処理時間の検証
検索処理における
処理時間の内訳イメージ
検索の処理時間が
大幅に短縮
非圧縮環境
圧縮環境
更新処理における
処理時間の内訳イメージ
更新のオーバーヘッド
もほとんどない
非圧縮環境
■CPU時間
■I/O時間
圧縮環境
■CPU時間
■I/O時間
83
Advanced Compression
• Advanced Compression はOracle 11g 以降で動作
–
–
–
–
全てのタイプのデータ
バックアップ  新しいRMAN 圧縮アルゴリズム
Data Pump エクスポート
Data Guard ギャップ解決とLGWR ASYNC 転送
• リソース要求とコストを削減!!!
– ストレージ
– パフォーマンス
• 一般的に2倍から4倍の圧縮が可能
DML
非圧縮
PCTFREE 到達:
圧縮!
さらなるDML
非圧縮
PCTFREE 到達:
圧縮!
オーバーヘッド
空き領域
非圧縮
圧縮
84
Advanced Compression
• Compression アドバイザ
– DBMS_COMPRESSION since Oracle 11.2
– Download for earlier releases
http://www.oracle.com/technetwork/database/options/compression/index.html
85
Hybrid Columnar Compression (HCC)
• Exadata, ZFS とPillar Axiom 600 Storage のみで利用可能
–
–
–
–
追加ライセンス不要
ほとんど変更のない履歴データ用
とても高い圧縮率
動作
• 表はCompression Units (CUs) 内に構造化される
– CUs はデータベース・ブロックより大きい
• Compression Units 内で、データは行の代わりに列で構造化される
– 列の構造は類似の値をすぐ近くに持ってくる、圧縮の拡張
Compression Unit
10x から15x
削減
WP: http://www.oracle.com/technetwork/middleware/bi-foundation/ehcc-twp-131254.pdf
86
Oracle Advanced Compression
• 構造化または非構造化、バックアップ、ネットワーク、アーカイブおよび
Data Guard REDOトランスポート・トラフィックのすべてのデータ型に対して
包括的なデータ圧縮と情報ライフサイクル管理(ILM)機能を提供
利用可能な機能
高度な行圧縮
Data Guard REDOトランスポート圧縮
高度なLOB圧縮
フラッシュバック・データ・アーカイブ履歴表の最適化
高度なLOB重複除外
記憶域スナップショットの最適化
ヒート・マップ
オンライン移動パーティション(任意の圧縮形式に対応)
自動データ最適化
RMANバックアップ圧縮
(RMAN DEFAULT COMPRESSにはAdvanced Compressionオプションが不要)
高度なネットワーク圧縮
データ・ポンプのデータ圧縮
(COMPRESSION=METADATA_ONLYにはAdvanced Compressionオプションが不要)
87
OLTP表圧縮の機能拡張
1000列までの表に対するサポート
• Oracle Database 12cでは、1000列までの表に対して、Advanced Row圧縮が
可能
– Oracle Database 11g R2までは、254列までの表が対象
• 255以上の列が含まれる表は圧縮不可
• OLTP表圧縮を利用したくても、この上限値により適用できないケースも
より広範な表の圧縮が可能となり、ストレージコストの削減に寄与
88
ネットワーク圧縮
• Oracle Netのレイヤーでクライアント間での通信データを圧縮する
– ネットワークボトルネックが発生した場合の帯域向上
– 通信データを圧縮することにより、ネットワーク帯域の有効活用が可能
データベース
側で圧縮
LAN or WAN
89
ネットワーク圧縮
設定方法
• ネットワーク圧縮を有効化するには、サーバーおよびクライアントの
sqlnet.oraファイルにいくつかの項目を手動で追加する
– 設定を行うパラメータ
• SQLNET.COMPRESSION=[ON/OFF/AUTO]
– ネットワーク圧縮の有効化を設定する。デフォルトはOFF
• SQLNET.COMPRESSION_LEVELS=[HIGH/LOW]
– 圧縮のレベルを設定する。デフォルトはLOW
• SQLNET.COMPRESSION_THRESHOLD=1024(bytes)
– ネットワーク圧縮が行われるデータサイズを設定する。このサイズ以下のデータは圧縮が行われずに送信
される。デフォルトは1024(bytes)
90
Flashback Data Archive とは
• 従来の Oracle の Flashback Technology を進化させた長期間型の変更履歴貯蓄機能
– 更新処理があった場合、変更履歴を保存
– 履歴の参照には従来のFlashback Query, Flashback Version Queryを使用
– 保存期間・サイズを指定して使用
履歴表（履歴データを格納）
Select
Update
Update
Insert
Insert
Delete
Delete
emp表
Flashback Data Archive
（履歴表を格納する場所）
91
Flashback Data Archive とは
• バックグランド・プロセス 'FBDA' により、非同期で
UNDO から履歴を自動取得 (基本 5 分間隔)
• 履歴データは、自動的に圧縮、パーティション化
DML
• 保存期間を過ぎた履歴データは自動で削除
• 表名や列名等のスキーマ変更にも対応
Original
data in buffer
cache
– パーティション化により高速な Flashback Query を実現
DML
• 履歴データは Read Only となり、改ざんは不可
– FBDA プロセスは、負荷に応じて自動的にスレッドを
作成しパラレル処理を実行
undo
Undo
data
Background (fbda)
process
help
..
負荷に応じて拡張
emp 表
履歴データ
92
Flashback Data Archive新機能
• In-Database Archiving
– オンライン状態を維持したまま通常セッションからはアクセス制限
• 行単位にアーカイブ属性を設定
• アプリケーション性能を犠牲にすることなく、より長期間オンラインで保持
• Temporal Validity
– 属性として有効期間を持つデータに対するアクセス制限
• 有効期間を示す列を定義することにより、ある地点で有効なデータを検索することが可能
– ユーザー定義の列に対して設定する
– 隠し列として設定する
93
まとめ
• Oracle Partitioning / Oracle Advanced Compression オプションにより
様々なレベルで表パーティション、圧縮、移動の設定が可能で
情報ライフサイクル管理（ＩＬＭ）の自動化が可能
– Automatic Data Optimization
– Heat Map機能
94
Oracle Confidential –
95

Oracle Database12c 新機能! 情報ライフサイクル管理の自動化第127回夜な夜な! なにわオラクル塾日本オラクル株式会社

Transcription

Similar documents

Document 6597866

The Saturable Reactor Type Constant Voltage Automatic

Oracle Database12c 新機能! 情報ライフサイクル管理の自動化 第127回 夜な夜な! なにわオラクル塾 日本オラクル株式会社

Transcription

Similar documents

Document 6597866

ä¹±æµæ§é ã«åºã¥ãSGSã¢ãã«ãç¨ãã å¾®æ°è±¡å ´ã®æ°å¤è¨ç®ææ³ã®éçº

The Saturable Reactor Type Constant Voltage Automatic

Oracle Database12c 新機能! 情報ライフサイクル管理の自動化第127回夜な夜な! なにわオラクル塾日本オラクル株式会社

ä¹±æµæ§é ã«åºã¥ãSGSã¢ãã«ãç¨ãã å¾®æ°è±¡å ´ã®æ°å¤è¨ç®ææ³ã®éçº