マルチテナント・アーキテクチャ - oraclecopyright © 2014 oracle and/or its...

マルチテナント・アーキテクチャ検討事例と活用ポイント

草彅康裕

日本オラクル株式会社テクノロジーコンサルティング統括本部テクニカルアーキテクト本部

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

Oracle DBA & Developer Days 2014for your Skill

使える実践的なノウハウがここにある

#odddtky

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

•以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

3


アジェンダ

マルチテナント・アーキテクチャ概要

マルチテナント・アーキテクチャ構成検討事例

マルチテナント・アーキテクチャの活用ポイント

1

2

3

4


アジェンダ




1

2

3

5


マルチテナント・アーキテクチャ

• Oracle Database 12cから利用可能な構成

• Oracle Multitenantオプションが必要

– 必要となるのはマルチテナント構成のみ

• 複数DBシステムをPDBとして単一CDB内に集約

– アプリケーションの変更は不要

• 高速で簡単なプロビジョニング

• サーバのリソース使用率の向上

プロセスプロセスプロセス

SGA

プロセス

SGA SGA SGA

6


選択可能なデータベース構成

Non-CDB構成

•従来型のデータベース構成

シングルテナント構成

•CDB 内にPDBが１つ存在する構成

マルチテナント構成

•CDB内にPDBが２つ以上有する構成

•Enterprise EditionにてOracle Multitenantオプションが必要

プロセスプロセスプロセス

SGA

プロセス

SGA

プロセス

SGA SGA SGA

7


データベース

従来からのデータベース(Non-CDB)

• Oracleインスタンスは、サーバー上で確保されるメモリー領域(SGA)とプロセス群から構成

• OracleデータベースはOracleインスタンスと、ストレージに格納されるデータベース（ファイル群）により構成される

SGA

プロセス

インスタンス

データファイル

制御ファイル

REDOログファイル

アーカイブREDOログファイル

8


マルチテナント・アーキテクチャ対応のデータベース(CDB)

• CDBでは、複数のPDBを作成可能

• プロセスやメモリー、メタデータは、すべてのPDB間で共有する

• 各PDBに固有の部分は、共有化する部分とは分離される

• 同一あるいは異なるCDB間で、容易にPDBの取り付け(plug)や取り外し(Unplug)が可能

データベース

SGA

プロセス

インスタンス

データファイル

制御ファイル

REDOログファイル

アーカイブREDOログファイル

PDB

データファイルデータファイルデータファイル

PDBPDB

9


マルチテナント・コンテナ・データベース（CDB)

• マルチテナント・コンテナ・データベース（CDB）は以下の要素で構成される

マルチテナント・コンテナ・データベース

内部管理データルート（CDB$ROOT）

プラガブル・データベース（PDB）シード（PDB$SEED）

ユーザーデータ

10


データベースの根幹

ルート（CDB$ROOT）

• データベース全体で共有するオブジェクトやメタデータを含む

– Oracleデータベースによって提供されるスキーマ

– ユーザーが作成するスキーマ

• データベース作成時に1つのみ作成される

• ルートのデータ・ディクショナリにはデータベース全体で共有する情報として、付属するすべてのPDBの情報が含まれる

内部管理データ


11


プラガブル・データベース作成時のテンプレート

シード（PDB$SEED）

• PDB を新規作成する際に使用するテンプレート

– Database Configuration Assistant（DBCA）によるデータベース作成時や作成後に、PDB を作成する場合

– データベース作成後に、手動でPDBを作成する場合

• データベース作成時に1つのみ作成される

– 読み取り専用

• オブジェクトの追加や変更は不可内部管理データ


12


スキーマやオブジェクトの集合

プラガブル・データベース（PDB）

• スキーマや表領域を含む論理的なセット

• 同一CDB内に複数作成することが可能（シードを除いて最大 252 まで）

• PDB間は排他的な関係にあり、データは論理的に分離される

• CDBから取り外した（Unplug）後、再度取り付けたり（Plug）、異なるCDBへ取り付けることが可能内部管理データ


13


アジェンダ




1

2

3

14


対象システム

ホストExadata X4-2

Eighth Rack ×2(本番機、ステージング機)

• 10個のサブシステムから構成されるシステム

• ホストからExadata X4 Eighth Rackへの移行

• 過去にホストからExadata X2 Quater Rackへ既存システムを移行済

• 運用負荷を増加させないよう、既存Exadataでの運用ポリシーを基本的に踏襲したい

移行

15


既存Exadata構成X2-2 Quarter Rack

Xeon-X5670(6ｺｱ) 2.93GHz×2Memory:196GB

X2-2 Quarter RackXeon-X5670(6ｺｱ) 2.93GHz×2

Memory:196GB

本番環境

研修環境

リリース前テスト用環境

テスト環境

移行環境

開発環境

本番機ステージング機

16


課題１（Exadata構成）X2-2 Quarter Rack


X2-2 Quarter RackXeon-X5670(6ｺｱ) 2.93GHz×2

Memory:196GB

本番機ステージング機

⇒移行対象システムではマルチテナント・アーキテクチャ採用により運用負荷を軽減できないか？

本番環境

研修環境

リリース前テスト用環境

テスト環境

移行環境

開発環境

・移行済システムでは各システム毎の開発環境がスキーマ単位で複数存在・開発環境作成依頼のたびにスキーマ作成、データセットアップ作業が発生することが運用負荷となっている

17


課題２（数年後に控えたクラウド環境への移行）X2-2 Quarter Rack


移行済システム

移行済システム

移行対象システムX4-2 Quarter Rack

Xeon E5-2697(12ｺｱ) 2.7GHz×2Memory:256GB

移行対象システム

⇒移行対象システムではマルチテナント・アーキテクチャ採用により移行負荷を軽減できないか？

移行クラウド環境(構築予定)

移行

18


マルチテナント・アーキテクチャ構成検討の流れ

• １）システム分割方式の検討–サブシステムの分割方式の軸を、DB分割、PDB分割、スキーマ分割のどれにするか

• ２）インスタンス構成の検討– CDBをどう分割するか、PDB、スキーマをどう分割するか

19





20


DB分割(non-CDB、CDB)

PDB分割(1CDB、nPDB)

スキーマ分割

構成

DB構成は、以下の分割方式もしくはその組み合わせとなるため、それぞれのメリット/デメリットを比較した上で、分割方式の軸を決定

DB

App App App

スキーマスキーマスキーマ

OS

DBDBDB

App App App

OS

CDB

PDB PDB PDB

App App App

OS

１）システム分割方式の検討•検討構成

21


項目DB分割

(non-CDB、CDB)PDB分割

(1CDB、nPDB)スキーマ分割

1)インプリの容易性

△・DB毎にインスタンス設計、物理設計は必要

◎・PDB毎のインスタンス設計は不要・PDB毎の物理設計は必要・クローニングにより容易に作成可能・DB分割よりも作成時間が短い

○・スキーマ毎のインスタンス設計は不要・スキーマ毎に個別に表領域を割りてる場合は物理設計が必要・スキーマ名、オブジェクト名が重複しないよう配慮が必要

2)アプリケーションの独立性（操作）

◎・独立した起動停止が可能・独立したオブジェクトの保持が可能・独立したユーザ作成が可能・独立したパッチレベルの保持は可能(ORACLE_HOMEを分ける場合)

○・独立した起動停止が可能・独立したオブジェクトの保持が可能・独立したユーザ作成が可能・独立したパッチレベルの保持は不可

△・独立した起動停止は不可・独立したオブジェクトの保持は不可・独立したユーザ作成は不可

・独立したパッチレベルの保持は不可

3)障害時の影響範囲

◎・BGプロセス障害、ファイル破損は1DBのみに影響

△・BGプロセス障害は全体に影響・ファイル破損がSYSTEM表領域（CDB$ROOT）、UNDO表領域で発生した場合はDB全体に影響

△・BGプロセス障害は全体に影響・ファイル破損がSYSTEM表領域、UNDO表領域で発生した場合はDB全体に影響

１）システム分割方式の検討• メリット/デメリット比較①

22


項目DB分割



4)スケーラビリティ△

・DB毎にメモリー、プロセスが必要

○・PDB増加によりメモリー、プロセスは増加しない

○・スキーマ増加によりメモリー、プロセスは増加しない

5)パフォーマンス△

・DB毎にメモリー量が制限される・BGプロセスが増えることによりCPUオーバヘッドが増加

○・サーバ全体のメモリーを使用可能・PDBが増えてもBGプロセスは増えない

○・サーバ全体のメモリーを使用可能・スキーマが増えてもBGプロセスは増えない

6)リソース管理

◎・CPU、I/O制御、メモリーが可能

○・CPU、I/O制御が可能・メモリーはKEEP(メモリー、フラッシュメモリー)を使用

△・CPU、I/O制御にはスキーマとコンシューマグループの関連付けが必要・メモリーはKEEP(メモリー、フラッシュメモリー)を使用

7)パッチ適用△

・DB毎に適用が必要

○・1回で全体に対する適用が可能

◎・1回で全体に対する適用が可能・DB分割、PDB分割と比較し、パッチ適用時間を最小化可能

１）システム分割方式の検討• メリット/デメリット比較②

23


項目DB分割



8)環境移行の容易性 △・DB移行が必要

◎・PDBのunplug/plugにより容易

△・スキーマデータの移行が必要

9)バックアップ/リカバリ

△・DB毎に操作が必要

◎・全体/PDB単位での処理が可能

○・DB単位での処理・スキーマ毎に表領域が分かれている場合は表領域単位での処理が可能(分かれていない場合は論理バックアップにて対応)

10)追加オプションライセンス

○・不要

△・2PDB以上の場合は、マルチテナントオプションが必要

○・不要

11)その他考慮点

・ローカル接続にてアプリケーションデータにアクセスする場合は、従来のバージョンと接続方法が異なる・キャラクタセットは統一する必要あり

１）システム分割方式の検討• メリット/デメリット比較③

24


１）システム分割方式の検討•検討結果

以下のメリットを重視し、PDB分割を軸とした構成を行うことを決定

–開発環境作成の負荷を軽減（インプリの容易性）

–数年後に控えたクラウド環境への移行負荷を軽減（移行の容易性）

25





26


２）インスタンス構成の検討•構成検討のステップ

CDB

PDB

App App

OS

スキーマスキーマ

PDB


CDB

PDB


PDB


App App App App App App

【CDB分割】・以下の場合に分けることを推奨□障害時の影響範囲を限定したい場合□運用管理者が異なる場合□SLA(停止時間、サービス可用性、要求レスポンス時間)が異なる場合□ORACLE_HOMEを分けたい場合□パラメータ(文字コード、アーカイブ設定など)を分けたい場合・DB毎にメモリーが必要となる点に考慮が必要

【スキーマ分割】・システム間の性能を求める場合に検討・スキーマ名、オブジェクト名の重複に考慮が必要・障害時は他スキーマへの影響あり

【PDB分割】・基本1システム1PDBとする・スキーマ名、オブジェクト名重複の考慮不要・インプリ・移行を容易に行いたい単位となる

以下のステップに則り、インスタンス構成を検討

①CDB分割を検討(CDBの制約を検討)②PDB分割、スキーマ分割の検討

27


２）インスタンス構成の検討１）CDB分割の検討

検討方針

CDB分割基準と、1サーバあたりのメモリー上限値を考慮し、分割する環境を決定する

検討結果

以下の観点から環境別(本番、研修、リリース前テスト、テスト、移行、開発)にCDB分割することを決定

・障害時の影響範囲は環境別に限定したい・サブシステムごとにSLAに大きな違いはない・サブシステム全体で運用管理者も同一・環境別にバックアップ設定を分けたい（バックアップ対象は本番環境とテスト環境）

28


２）インスタンス構成の検討2) PDB分割・スキーマ分割の検討

検討方針

インプリ、移行時の負荷を軽減するため、サブシステム単位でのPDB分割を検討

ただし、PDB間の性能を求める場合はスキーマ分割を検討

29


CDB

システム1

システム2

システム3

システム4

システム5

システム6

システム7

システム8

システム9

システム10


PD

B

PD

B

PD

B

環境ごとの分割方式を、以下の2パターンから検討

orCDB

PDB

システム1

システム2

システム3

スキーマ

スキーマ

スキーマ

スキーマ

ローカルアクセスDBリンクアクセス

1)スキーマ分割 2)PDB分割

PD

B

システム4

システム5

システム6

システム7

システム8

システム9

システム10

スキーマ

スキーマ

スキーマ

スキーマ

スキーマ

スキーマ

PD

B

PD

B

PD

B

PD

B

PD

B

PD

B

30


項目スキーマ分割 PDB分割

開発フェーズ

環境作成方法 ○・スキーマを作成

○・PDBおよびサービスを作成

データ投入△

・Export/Importにて実施

○・PDBクローニングも使用可能・Export/Importでも可能

サービス数○

・1

△・10・PDBごとにサービスを作成

PDB数、スキーマ数 ○・1PDB 10スキーマ

○・10PDB 1スキーマ

スキーマ名、オブジェクト名重複への配慮 ○・新規設計のため考慮が不要

○・考慮不要

２）インスタンス構成の検討2) PDB分割・スキーマ分割の検討運用ライフサイクルの項目ごとに、メリット/デメリットを比較

31



利用フェーズ

他システムへのアクセス性能 ○・他システムへはスキーマ間アクセス

△・他システムへはDBリンクアクセス

接続方法(サービス接続) ○

・1つのサービスに対してアクセス

△・システム毎に別々のサービスに対してアクセス

環境間移行

△・Export/Importを使用

○・サブシステム単位での移行ではPDBのクローンやUnplug/Plugを用いた手順の簡略化が可能・Export/Importも使用可能

起動/停止 △・スキーマ単位の起動/停止は不可

○・PDB単位の起動/停止が可能

リソース制御△

・スキーマとコンシューマグループの関連付けが必要

○・PDB単位での設定が容易に可能


32



利用フェーズ

パッチ適用時間○

・スキーマ数に依存してパッチ適用時間は増加しない

△・PDB数に依存してパッチ適用時間が増加

バックアップ/リカバリ△

・スキーマ単位で表領域が分かれている場合のみリカバリが可能

○・PDB単位でのリカバリが可能

削除フェーズ

環境削除方法○

・スキーマの削除により対応

○・PDBの削除により対応


33



検討結果以下の理由より、本番環境についてはスキーマ分割構成を採用する

・他システムへのアクセス性能がDBリンクに比べて良いこと・パッチ適用時間が複数PDB時と比較して短いこと

研修環境、リリース前テスト環境、テスト環境、移行環境については、本番環境と合わせスキーマ分割構成を採用するが、開発環境については以下の理由からPDB分割構成とする

・環境作成、データ投入手順がクローニングにより簡略化できること※他システムへのアクセス性能とパッチ適用時間については開発環境のため許容されると判断

・1PDB内でのスキーマ分割構成とすることで数年後に控えたクラウド環境への移行負荷を軽減

・開発環境作成の負荷を軽減

34


アジェンダ




1

2

3

35


マルチテナント・アーキテクチャの活用ポイント• １）システム統合

ポイント

・複数システムがOracleDBを使用している場合は、スキーマ名、オブジェクト名に対する考慮が不要となるため、作業コストの削減が期待できる(ただし、ホストからの移行については、DB設計は新規となるため当てはまらない)

考慮点

・PDB間でのアクセスが発生する場合にはDBリンクが使用されることに考慮が必要(PDB間アクセスが発生しない場合、性能要件が高くない場合であれば問題はない)

36


マルチテナント・アーキテクチャの活用ポイント• ２）環境移行

ポイント

・Unplug/Plugを使用することにより、容易に環境を移行可能

考慮点

・Unplug/Plugのみで移行するためにはUnplug対象データベースが以下の条件を満たす必要あり•バージョン：Oracle Database 12c以上•DB構成：CDB構成(マルチテナント・アーキテクチャ構成)

37


マルチテナント・アーキテクチャの活用ポイント• ３）環境作成

ポイント

・DB分割と比較し、作業時間の短縮と、作業工数の削減が期待できる・環境作成及びデータ投入の頻度が高く、そのデータが一定となる場合には、PDBクローニングをより有効に活用可能

考慮点

・PDBのデータファイルサイズに依存してクローニング時間が増加・スキーマ構成や投入データが変更された場合は、クローニング元PDB、もしくはクローニング先PDBに対し、別途作業が必要

38

Oracle Database 12c新機能の活用ポイント

塩原浩太

日本オラクル株式会社テクノロジーコンサルティング統括本部ビジネスアライアンス部

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

Oracle DBA & Developer Days 2014for your Skill

使える実践的なノウハウがここにある

#odddtky


•以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とするものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することをコミットメント（確約）するものではないため、購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関して記載されている機能の開発、リリースおよび時期については、弊社の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。文中の社名、商品名等は各社の商標または登録商標である場合があります。

40


本セッションについて

• 目的

– 新機能の検討事項に関する技術情報、知見を提供する

– 検討ポイントを共有する

– 関連する技術情報を提供する

• 内容

– MTA以外の新機能に関する技術情報の説明

– 新機能に関する検証内容に基づいた気付きをフィードバック

• 注意事項– 本セッション/資料の内容は2014/11/19時点での情報となります。

– 本セッション/資料の内容はPSR12.1.0.2.0 OracleLinux-R6-U4-Server-x86_64環境での検証内容をベースに記載しています。

– 本セッション/資料記載の機能をご使用を検討する際には自身での十分な検証をお願い致します。

– 本セッション/資料では検討ポイントとして考えられる幾つかのポイントを記載しています。

実際の使用可否についてはシステム要件を加味してご検討下さい。

41


アジェンダ

1

2

3

4

クラスタ構成

ILM実装方式

リソース管理方式

オプティマイザ機能使用方針

42


クラスタ構成方式：検討事項

検討項目検討事項

Flex ASM 従来のASM構成とするかFlex ASM構成とするか

43


ASM概要

• Oracle Database に対してボリューム・マネージャ兼ファイルシステムとして機能し、ディスク構成を仮想化

• エディション(EE / SE) に関係なくシングル環境、クラスタ環境共に使用可能

Oracle Automatic Storage Management (ASM)

ASM Disk Group

Oracle Instance

ASMInstance

CSS

Oracle Database にフラットなディスク・プールを

提供 + ディスク管理工数を大幅削減

複数のディスク・アレイにまたがってディスクを

仮想化し、ディスク追加 / 削除でもデータを

透過的に再配分

44


Oracle ASM ～11R211gR2までの ASM 構成の課題

• 全サーバーにASMインスタンスが必要(主にメモリリソースを使用)

• インスタンスはローカルのASMにのみ接続可能

• ASM インスタンスの停止＝サーバー上の全データベース・インスタンスの停止

ASM インスタンス

データベースインスタンス

DB1 DB2 DB1 DB2 DB1 DB2 DB1 DB2 DB1 DB2

45


Oracle Flex ASM12cからの新機能

• ASM インスタンスをデータベース・インスタンスが稼働するサーバーと分離

– データベース・インスタンスはネットワーク経由でASM インスタンスにリモート接続

• 接続先ASMインスタンス障害発生時は別の ASM インスタンスへフェイル・オーバー

– ASM インスタンスへの依存性が低減し、データベース・サービスの可用性が向上

– 指定したASMインスタンス数(カーディナリティ数)を維持するよう動作

ASM停止サーバのインスタンスは自動接続

ASM インスタンス

データベースインスタンス

DB1 DB2 DB1 DB2 DB1 DB2 DB1 DB2 DB1 DB2

ASMにリモート接続

46

Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 47

ポイント• ASMインスタンス停止時もデータベース・インスタンスの停止を回避可能• クラスタを構成するサーバ台数が多い場合にはリソースを削減できる• Oracle ASMインスタンス数(カーディナリティ数)は維持される(リソースの余裕は必要)

考慮点• ローカルアクセスに比べ通信のオーバヘッドが発生する• 12.1より前のリリースのDBが混在する環境ではASMインスタンス数(カーディナリティ)を

ALLに設定が必要(12c 以前のDBはリモートサーバのASMにアクセス出来ないため)• Oracle Restart 環境は対象外

Flex ASM検討ポイント


OSの統計情報を取得し、データをリポジトリDB(GIMR )に保持する

Oracle Database Quality of Service Management、Memory Guard で使用される

•システム監視サービスシステム監視サービス(osysmond)：データをクラスタ・ログ出力サービスに送信するオペレーティング・システ

ム・メトリック収集サービス

• クラスタ・ログ出力サービスクラスタ・ログ出力サービス(ologgerd)は、クラスタ内の1つのノードのみ1つ存在し、

各ノードから送られてきたデータをリポジトリDBで管理するサービス

Cluster Health Monitor (CHM)Grid Infrastructureに統合された管理サービス

48


GIMR (Grid Infrastructure Management Repository)

• GI 12.1.0.2ではGrid Infrastructureインストール時に自動的に構成される

※ GI 12.1.0.1ではインストールはオプション(インストール時に選択が可能)

関連リソース

– ora.MGMTLSNR

– ora.mgmtdb

– CHMによって収集されたリアルタイムOSメトリックを格納するOracleデータベース

– クラスタ内のいずれか1ノードで稼働する (クラスタ・ログ出力サービスと連動)

– データファイルはOCR/Voting Diskと同じDiskgroupに配置される

– OCLUMONコマンドによって操作を行う

CHMによって収集されたデータを格納するリポジトリデータベース

49


アジェンダ

1

2

3

4

クラスタ構成

ILM実装方式



50


ILM実装方式：検討事項


ILM実装方式：HEATMAP&ADO

HEATMAP&ADO使用有無

51


対象：表、表パーティション

Oracle が実現する ILM (~11gR2 )経過時間ベースで保存先を変更

OLTP圧縮 HCC圧縮低コストストレージへの移動

削除

業務処理内容に基づいたデータの移動・圧縮を実施するタイミングを決める

Q1 Q2 Q3 Q4

1ヶ月経過後 2ヶ月経過後 1年経過後 6年経過後

52


Oracle が実現する ILM (12c)アクセスベースで自動実行

対象自動検知自動アクション

Automatic Data Optimization ／ Heat Map

追跡操作

− 作成

− アクセス

− 変更

タイミング

− 経過日数

− 経過年数

− 表域使用率

圧縮

− 段階的な

圧縮レベルの変更

移動

− ストレージ移動

圧縮＋移動

行

セグメント

表領域

グループ

53


Heat Map＆ Automatic Data Optimization

Heat Map(アクセス情報の取得機能)

•データの参照・更新の状況を保持し、アクセス統計を収集しディクショナリに格納

•データベース、パーティション、列、または、ブロック/エクステントのレベルで利用状況を確認可能

• ADOポリシーが起動タイミングを自動検知するために利用

Automatic Data Optimization(ILM処理の自動実行)

•移動は表領域の利用率に応じて実施される

•圧縮はアクセスパターンの変化に応じて実施される

• PL/SQLファンクションを使ったカスタム条件の利用も可能

アクセス追跡機能とアクション実行機能

54


Automatic Data Optimizationとは動作の仕組み

データへのアクセス

HEAT_MAP = ON

圧縮ポリシーの作成

移動ポリシーの作成

DBA_HEAT_MAP_SEGMENT

HEAT_MAP_STAT$表

ディクショナリー

初期化パラメータ

ILM処理の登録

DBA

DBサーバー

一般ユーザー

SGA

メンテナンスWindow

1

アクセス統計の収集

2

3

4

ストレージ高性能高性能低コストアーカイブ

圧縮なし OLTP圧縮 HCC圧縮：クエリー

HCC圧縮：アーカイブ

最終ステージステージ③ステージ②ステージ①ステージ⓪

V$HEAT_MAP_SEGMENTポリシー評価

Real Time

1時間毎にフラッシュ

MMON

15分毎

ポリシー実行

5

55


Automatic Data Optimizationの追跡対象と操作

アクセスパターン

アクション変更なし作成アクセスなし表領域フル

カスタムポリシー

圧縮(行)

✔

圧縮(セグメント)

✔ ✔ ✔

圧縮(グループ)

✔ ✔

圧縮(表領域)

✔ ✔ ✔

記憶域階層化(セグメント)

✔ ✔

記憶域階層化(表領域)

✔

指定出来るアクセスパターンとアクション(対象)は組み合わせで決まる

56


Heat Map＆Automatic Data Optimization検討ポイント

57

ポイント• アクセスベース、表領域使用率に応じた自動アクションが可能• セグメントの移動は表領域の使用閾値に達した場合に実行される• 表領域(データファイル)の移動ポリシーはない• Heat Mapの収集情報を活用した独自の仕組みも実装可能

考慮点• 現時点(2014/11/18)において、PSR 12.1.0.2.0までのリリースではMTAとの併用は出来ない• Advanced Compressionライセンスが必要


ILMに有効な新機能 -オンラインデータファイル移動

オンライン実行

– データベースファイルがオンラインでも実行可能

– 移動中もDML操作可能

ファイルの自動コピー

MOVE DATAFILE コマンドによるオンライン移動

ALTER DATABASE MOVE DATAFILE '<移動元のパス>' TO '<移動先のパス>';

Disk1 Disk2

Datafile1

Datafile2

Datafile1

Datafile2

58


ILMに有効な新機能 -オンラインパーティション移動

• DML 実行中の ALTER TABLE .. MOVE PARTITION / SUBPARTITIONの実行が可能

– DML実行中にも実行可能(ORA-00054は発生しない)

– オンラインパーティション移動中にもDML操作が可能(DDL操作は対象外)

• 制限 : ONLINE で実行できないケース

– 以下の表に対する処理は実行不可

• SYS スキーマの表

• 索引構成表

• オブジェクト型の列を持つヒープ構成表

• ビットマップ索引 / ビットマップ結合索引 / ドメイン索引が作成されている表

– データベースでサプリメンタル・ロギングが設定されている場合

ALTER TABLE MOVE PARTITION/SUBPARTITION の ONLINE オプション

SQL> ALTER TABLE sales MOVE PARTITION sales_p01 COMPRESS ONLINE; SQL> ALTER TABLE sales MOVE PARTITION sales_p01 TABLESPACE lowtbs UPDATE INDEXES ONLINE;

59


ILMに有効な新機能 -複数パーティションの一括処理

• 複数パーティションのメンテナンス操作を1回のコマンドで一括処理可能

– ADD /DROP / TRUNCATE / MERGE / SPLIT

• パーティションのロールアウトやロールアウト処理が容易に

＋＋＋Q1 Q2 Q3 Q42014

SQL> ALTER TABLE sales MERGE PARTITIONS sales_p1, sales_p2, sales_p3, sales_p4 INTO PARTITION p2014;

SQL> ALTER TABLE sales SPLIT P2014 INTO( PARTITION sales_p1 VALUES LESS THAN(TO_DATE('2014/04/01','YYYY/MM/DD')) , PARTITION sales_p2 VALUES LESS THAN(TO_DATE('2014/07/01','YYYY/MM/DD')) ,PARTITION sales_p3 VALUES LESS THAN(TO_DATE('2014/10/01','YYYY/MM/DD')) ,PARTITION sales_p4);

一つのコマンドで複数パーティションをメンテナンス可能

Q1Q2

Q3 Q4

60


Q1

Q2

Q3

Q4

ILMに有効な新機能 -パーシャル索引

パーシャル索引• パーティション/サブパーティション毎に設定したINDEXING 属性のON / OFF で制御

• ローカル索引・グローバル索引の両方で使用可能

• 索引作成後にINDEXING 属性を変更することで動的な索引付け・排除が可能

– ローカル索引のセグメントは即時に削除される

– グローバル索引もUNUSABLEとはならない(詳細は次頁)

特定のパーティション/サブパーティションに対する索引の作成・削除

パーティション表

Q1

Q2

Q3

Q4

SQL> CREATE INDEX i_sales_col1 ON sales(col1) GLOBAL INDEXING PARTIAL;SQL> CREATE INDEX i_sales_col2 ON sales(col2) LOCAL INDEXING PARTIAL;SQL> ALTER TABLE sales MODIFY PARTITION sales_p4 INDEXING OFF;

61


ILMに有効な新機能 -グローバル索引メンテナンス非同期実行

• UPDATE INDEXES 句を指定したグローバル索引へのDROP/TRUNCATE PARTITION 文のメンテナンス処理は非同期に実行することが可能(UNUSALBEにならずに継続使用が可能)

– SYS.PMO_DEFERRED_GIDX_MAINT_JOB のジョブが索引データを更新(セグメント解放)

– ALTER INDEX ....REBUILDやCOALESCEの実行でもクリーンナップが可能

– デフォルトでは毎日午前2時にクリーンナップジョブがスケジュールされている。

スケジュールの変更は可能だがジョブの削除は非推奨。

制限 : 以下の表には適用されない

–オブジェクト型を含む表

–ドメイン索引を含む表

– SYS スキーマの表

DROP/TRUNCATE PARTITION のグローバル索引のメンテナンス

62


アジェンダ

1

2

3

4

クラスタ構成

ILM実装方式



63


リソース制御実装方式：検討事項


インスタンスケージング Partitioningアプローチ/Over-Provisioningアプローチ

OSプロセッサグループ numa_nodes /cpus

64


インスタンス・ケージングPartitioningアプローチ

• 全インスタンスCPU_COUNTの合計がCPU総数を超えないように設定

– インスタンス毎に設定したCPU_COUNTの割合まで常にCPUを使用可能(使用率)

– 他のインスタンスがCPUを使用していなくても、設定したCPU_COUNT以上を使用することはない。

CPUリソースの使用効率が低くなりうるケースも考えられる

例)

Aインスタンス：CPU_COUNT=3Bインスタンス：CPU_COUNT=3Cインスタンス：CPU_COUNT=3Dインスタンス：CPU_COUNT=3

各インスタンスの最大CPU使用率は25%となる

cpu_countの合計(12)

CPUの総数 = 12

6

9

12

3Aインスタンス

Bインスタンス

Cインスタンス

Dインスタンス

65


インスタンス・ケージングOver-Provisioningアプローチ

• 全インスタンスのCPU_COUNTの合計値がCPU総数を上回って設定

例)

Aインスタンス：CPU_COUNT=4Bインスタンス：CPU_COUNT=4Cインスタンス：CPU_COUNT=4Dインスタンス：CPU_COUNT=4

各インスタンスは25%から33%の間のCPU使用率となる

• 他インスタンスがCPUを使用していない場合においても、

CPUリソースを効率よく使用出来る

• 他インスタンスの負荷により、使用率が制限される

• 重要度の低いシステムなどに適用

cpu_countの合計(16)

CPUの総数 = 12

8

12

4

16

Aインスタンス

Bインスタンス

Cインスタンス

Dインスタンス

66


OSのプロセッサ・グループの使用

• 初期化パラメータPROCESSOR_GROUP_NAMEでインスタンスが稼働するプロセッサ・グループ(コントロールグループ)を指定することが可能

– インスタンスのプロセスは指定されたプロセッサ・グループ(コントロールグループ)に割り当てられたリソースを使用する

– Linuxでは、cgroup（2.6.32カーネル以上）、Solarisでは、リソース・プール（Solaris 11 SRU4）に対応

control_a(cpus : 0 - 3) control_b(cpus : 4,5)

設定方法Using PROCESSOR_GROUP_NAME to bind a database instance to CPUs or NUMA nodes on Linux (Doc ID 1585184.1)

67

processprocessprocessprocess

インスタンスA

processprocess

インスタンスB

コントロールグループcontrol_bというコントロールグループはCPUコア4，5が割り当てられている

PROCESSOR_GROUP_NAME=control_b

OSレイヤ

CPUコア

OSの資源管理機能を使用したリソース制御


インスタンス・ケージングとの違い

• インスタンス・ケージングは、DBでのCPU使用率をOracleの機能で調整

– どのコアを使用するかはOS側の制御にゆだねられる

• プロセッサ・グループ(コントロールグループ)はOS（カーネル）機能でリソースを制御

– カーネルでグループに対するCPU割り当てを制御する

制御機能と制御方法

OSレイヤ

CPU使用量（CPU_COUNT/OSの総CPU数）を上限にCPUを制御CPU数ではない。

コントロールグループA(cpus 0,1)

cgroupではOS（カーネル）のレイヤーで、CPUリソースをグループ毎に制御する。指定した物理CPUコア(リソース)のみを使用する

インスタンスケージングの場合

プロセッサ・グループの場合

リソースマネージャ

68

processprocessprocessprocess

OSレイヤ

processprocess


• PROCESSOR_GROUP_NAMEは、データベース・インスタンスに対して、

指定されたオペレーティング・システム・プロセッサ・グループ内で自身を実行するように

指示します。すべてのOracleプロセスはこのグループ内のCPUにバインドされ、

これらのCPU上でのみ実行されます。NUMAシステムの場合、データベース・インスタンスに

よって割り当てられるすべてのSGAおよびPGAメモリーは、グループ内のNUMAノードから割り

当てられます。

• このパラメータは、USE_DEDICATED_BROKER初期化パラメータもTRUEに設定してあるデータベースでのみ設定することをお薦めします。

出典：Oracle® Databaseリファレンス 12cリリース1 (12.1)

初期化パラメータ：PROCESSOR_GROUP_NAME

69

PROCESSOR_GROUP_NAMEの可能性


リソース制御検討ポイント

70

インスタンスケージング• Oracleの機能で制御• CPU使用量で制御されており全コアを使用可能、他インスタンスと共有• 設定変更にインスタンスの再起動は不要• EEライセンスが必要

OSプロセッサグループ• OS機能を使用して制御• 特定物理リソースに対してインスタンスを固定化出来るため占有が可能• OSプロセッサグループは物理コアが固定されるため、コア数が少ないと同時処理能力が低下• 設定変更にインスタンスの再起動が必要• OSプロセッサグループはSEでも使用可能


プロセス管理の新機能

• マルチプロセス(デフォルトアーキテクチャ)–Oracle プロセスと OS プロセスは 1対1

• マルチスレッド(追加されたアーキテクチャ)–OS プロセス 1つに対し、複数のOracle プロセスがスレッドとして実行される

– PMON・DBW・ VKTM ・PSPはそれぞれ独自のプロセスとなる

Linux / UNIX システムで12.1より導入

DBW0PMON

サーバプロセス

SMON

MMON

LGWR

71

Oracle Process OSプロセス

DBW0PMON

サーバプロセス

SMON

MMON

LGWR

OSプロセスOracle Process スレッド

マルチ・スレッドマルチ・プロセス


マルチスレッドアーキテクチャ

• メリット

– CPU、メモリ使用量の削減

• 設定方法

– 初期化パラメータ：THREADED_EXECUTION =TRUEに設定

– DEDICATED_THROUGH_BROKER_listener-name=ONをlistener.oraファイルに追加

• 制限

– OS認証 (sqlplus / as sysdba) によるログイン不可

– スレッド化して実行されるプロセスはPGA、SGAを使用する(動作に変更はない)

設定方法

72


アジェンダ

1

2

3

4

クラスタ構成

ILM実装方式



73


オプティマイザ機能使用方針：検討事項


適応計画有効/レポートモード/無効

動的統計レベル(0/2/11)

自動再最適化有効/無効

SQL計画ディレクティブ有効/無効

74


オプティマイザ新機能新機能の位置づけ

75

適応問合わせ最適化

適応計画

結合方法パラレル配分方法

適応統計

動的統計自動再最適化SQL計画

ディレクティブ

SQL実行時に作動

二回目以降の実行時

再解析実行時統計情報が不十分な場合

(初回実行時含む)

SQL実行時前に作動


適応計画SQL実行時の動的プラン変更

• 問合わせ実行時に収集した統計を基に最終的なプランを決定

– 既存の統計を基にプランを作成(デフォルトプラン)

– 実行時に収集した統計を基に、一部のプランについて最適なサブプランを選択する

• ネステッドループ結合⇒ハッシュ結合への変更

• パラレル実行時のデータの配分方法をハッシュ⇒ブロードキャストへ変更

– バインド変数を使用していないSQLにも対応

– 適応カーソル共有とは異なり、一回目のSQL実行時から最適な計画に適応させようと動作する

– 適応後の子カーソルの実行では、オプティマイザによって同じ計画が使用され、この計画がキャッシュから破棄されるか、別のオプティマイザ機能(適応カーソル共有や統計フィードバックなど)によって無効化されるまで使用が続く。

76


適応計画の制御OPTIMIZER_ADAPTIVE_REPORTING_ONLY

• 初期化パラメータ OPTIMIZER_ADAPTIVE_REPORTING_ONLY で有効/無効を設定

– デフォルトは有効 ( 設定値: FALSE )

– ALTER SYSTEM、ALTER SESSIONによる設定が可能

• OPTIMIZER_ADAPTIVE_REPORTING_ONLY を TRUE に設定した場合

– レポートのためのモードとなり、プランの変更は行わない

– 適応計画に必要な統計の収集は実施

77


適応計画のレポート出力実行時プランと最終プランの確認

• プランの適応内容を表示– デフォルトプランと適応後のプランを表示

– 実行時のプランを変更せずに適応によるプランの変化を確認可能

– レポート・モード時にのみ出力可能(OPTIMIZER_ADAPTIVE_REPORTING_ONLY=TRUE)

• 出力方法1. 調査SQL文を実行

2. DBMS_XPLAN.DISPLAY_CURSOR ファンクションの FORMAT パラメータに ’REPORT’ を指定して実行

78

SQL> ALTER SESSION SET OPTIMIZER_ADAPTIVE_REPORTING_ONLY=TRUE;SQL> 調査SQLの実行SQL> SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR(FORMAT=>'REPORT'));


動的統計の強化サンプリングレベル11(AUTO)の導入

• 動的統計(以前は動的サンプリングという名称でした)

– 統計情報が欠落しているか不十分な場合に統計情報を補完する機能

– 初期化パラメータ OPTIMZER_DYNAMIC_SAMPLINGの設定により実行内容を指定

• サンプリングレベル11設定時動作

– 動的統計を取得するかどうか、取得サンプルサイズを自動的に判断

– オプティマイザ統計が不十分な時に選択される

– 収集した統計をメモリ上に記録し、他のクエリからも使用可能

– SQL計画ディレクティブの指示になりやすい

79


自動再最適化

• 11g Release 2のカーディナリティ・フィードバックの進化機能

– 見積もりと実際のカーディナリティに大きな差異があった場合に、

正しい見積もりをオプティマイザにフィードバックし、次回問合せ実行時のプランを最適化

• 適応計画では解決できないプランも修正可能

– 結合順序、索引の使用有無

• 再最適化機能の種類

– 統計フィードバック

• 前回の問い合わせ実行時に収集した統計を使用してプランを作成

– パフォーマンス・フィードバック

• 収集した統計(例えば CPU time )を使用してパラレル度を改善

• 問い合わせ対象オブジェクトに対する他のSQLを最適化するため、 SQL 計画ディレクティブを生成(動的統計取得指示など)

80

統計フィードバック機能


SQL 計画ディレクティブ

• オプティマイザがより適したプランを作成するための追加情報や指示

– 動的統計の収集、列グループ統計の作成指示など

• SQL計画ディレクティブ作成タイミング

– SQL 実行時にカーディナリティが誤って見積もられた場合

(適応計画や自動再最適化実行時など)

• SQL計画ディレクティブはSQLではなくオブジェクトに紐づく

– 複数のSQLで利用可能

• SQL計画ディレクティブの保存

– 作成されたSQL計画ディレクティブはメモリーに格納され、その後15分おきにSYSAUX 表領域に格納し、永続化される。

81

SQL計画ディレクティブ概要


SQL 計画ディレクティブの管理ディクショナリ/DBMS_SPDパッケージ

• SQL計画ディレクティブ確認ディクショナリ

– DBA_SQL_PLAN_DIRECTIVES

– DBA_SQL_PLAN_DIR_OBJECTS

• SQL計画ディレクティブのSYSAUXへの手動フラッシュ方法

– DBMS_SPD.FLUSH_SQL_PLAN_DIRECTIVEプロシージャでフラッシュ

• SQL計画ディレクティブの保持期間設定

– 使用されないディレクティブは53週後に自動的にパージ(デフォルト)

– DBMS_SPD.SET_PREFSプロシージャで期間を設定

• SQL計画ディレクティブの手動削除方法

– DROP_SQL_PLAN_DIRECTIVEプロシージャでdirective_idを指定

82


SQL 計画ディレクティブの制御

• 初期化パラメータ OPTIMIZER_ADAPTIVE_FEATURES で有効/無効を設定

– デフォルトは有効 ( 設定値: TRUE )

• OPTIMIZER_ADAPTIVE_FEATURESを無効に設定した場合、以下機能が無効化される

– 適応計画

– 自動再最適化

– SQL計画ディレクティブ

※動的統計は無効化されない

83

OPTIMIZER_ADAPTIVE_FEATURE


オプティマイザ機能使用方針検討ポイント

84

ポイント• 適応計画はバインド変数を使用した結合SQLに有効• 運用にて統計情報やSQLの実行計画管理が出来る場合には機能の停止も考えられる• 運用コストの低減や管理できない場合には、オプティマイザ新機能の活用を検討• レベル11の動的統計は他のセッション(オブジェクトベース)と共有される(コンサル検証ベース)• 動的統計が実行される場合にはSQL計画ディレクティブは生成されない(コンサル検証ベース)• SQL計画ディレクティブの動的統計取得指示はレベル11で実行される(コンサル検証ベース)• 自動再最適化はバインド変数を使用している場合は機能しない(コンサル知見)

考慮点• 動的統計・自動再最適化は、統計情報を適切に取得していれば必要ない。• OTLP処理などでは動的統計取得のオーバーヘッドを考慮し機能の使用有無を検討• SQL計画ディレクティブはSYSスキーマでも取得される(コンサル検証ベース)• 適応計画はEEライセンスが必要


バルク・ロードのためのオンライン統計収集

• 取得対象バルク・ロード操作

– CREATE TABLE AS SELECT

– INSERT INTO … SELECT (空テーブルへのダイレクト・パス・インサート)

• 表統計、列統計を収集

– インデックス統計、ヒストグラムは収集しない

• 制限：以下の条件に合致する表には自動取得されない。

– 空ではない表へのINSERT INTO ... SELECT

– Oracle所有のスキーマ内に存在する表(SYSなど)

– ネストした表

– 索引構成表(IOT)

– 外部表

– ON COMMIT DELETE ROWSとして定義されたグローバル一時表

– 仮想列を含む表など

85

バルク・ロード操作の一部として統計の集を自動的に実施


同時統計収集の機能強化

• 自動統計収集ジョブ、複数のパーティション表

• マルチCPU環境では総収集時間の短縮が可能

• 同時統計収集の有効化

– DBMS_STATS.SET_GLOBAL_PREFSプロシージャを使用してCONCURRENTプリファレンスを設定

86

複数のオブジェクトに対し統計情報の並行収集が可能


コース内容

はじめにコンテナおよびプラガブル・データベースのアーキテクチャ

CDBおよびPDBの作成 CDBおよびPDBの管理

CDBおよびPDBの記憶域の管理 CDBおよびPDBのセキュリティの管理

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

その他

受講前提条件・「Oracle Database 12c: 管理ワークショップ」の受講相当の知識

・「Oracle Database 12c: バックアップ・リカバリ」の受講相当の知識

対象者・データベース管理者（システム構築、運用管理などに携わるエンジニア）

・ORACLE MASTER Gold Oracle Database 12cの取得を目指される方

・サポート・エンジニア

コース日程２日間

このコースでは、Oracle Database 12c の新機能であるマルチテナント・アーキテクチャのすべての機能について学習します。マルチテナント・コンテナ・データベースおよび関連付けられたプラガブル・データベースのコンポーネントに関する詳細な情報から

、ビジネス・アプリケーションに適した記憶域構造を持つマルチテナント・コンテナ・データベースおよび関連付けられたプラガ

ブル・データベースを作成および管理する方法について学習します。また、マルチテナント・コンテナ・データベースのデータベ

ースを接続および切断する実践的な演習に加えて、共通ユーザーとローカル・ユーザーを作成して、ビジネス要件に合わせてデー

タベース・セキュリティを管理する方法についても学習しますマルチテナント・コンテナ・データベースおよび関連付けられたプ

ラガブル・データベースの効果的かつ効率的に管理する方法について学習します。

※ORACLE MASTER Gold Oracle Database 12c対応研修コースです。

Oracle Database 12c: マルチテナント・アーキテクチャ

日程の詳細は Oracle University Webサイトにてご確認ください。

87

研修のご紹介

http://education.oracle.com/pls/web_prod-plq-dad/db_pages.getCourseDesc?dc=D58682JP10

マルチテナント・アーキテクチャ - oraclecopyright © 2014 oracle and/or its...

Documents