DBA & Developer Day 2016 ダウンロード資料

しばちょう先生の特別講義！！

ストレージ管理のベストプラクティス

～ASMからExadataまで～

日本オラクル株式会社

クラウド・テクノロジー事業統括

Database & Exadata プロダクトマネジメント本部

応用技術部 ディレクター

•

以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するも

のです。また、情報提供を唯一の目的とするものであり、いかなる契約

にも組み込むことはできません。以下の事項は、マテリアルやコード、

機能を提供することをコミットメント（確約）するものではないため、

購買決定を行う際の判断材料になさらないで下さい。オラクル製品に関

して記載されている機能の開発、リリースおよび時期については、弊社

の裁量により決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。

文中の社名、商品名等は各社の商標または登録商標である場合があります。

“しばちょう” こと、柴田長（しばた つかさ）です。

Oracle Technology Networkで、ほぼ毎月連載中

「しばちょう先生の試して納得！DBAへの道」

http://www.oracle.com/technetwork/jp/database/articles/shibacho/index.html

本日の内容

なぜ、ストレージ設計が必要なのか

Oracle Automatic Storage Management

ASMの最新機能紹介

ExadataにおけるASM構成

まとめ

1

2

3

4

5

本日の内容

なぜ、ストレージ設計が必要なのか

Oracle Automatic Storage Management

ASMの最新機能紹介

ExadataにおけるASM構成

まとめ

1

2

3

4

5

データベース時間（処理時間）とは？

CPUボトルネック

I/Oボトルネック

わんこそば理論

そばがお椀に盛られなければ食べられない

= データが無ければ、CPU処理はできない

http://www.atmarkit.co.jp/ait/articles/1606/01/news007.html

食べる人が増えると？

Oracle Databaseのアーキテクチャ

ストレージ・アクセスが必要な主な処理

•

SQL実行時に、Server Processによ

るData Blockの読込み/書出し

–

Buffer Cache上にBlockが存在しない時

–

Direct Path Read（Table Full Scan）

–

Direct Path Insert（APPEND ヒント等）

•

DBWRによるDirty Blockの書出し

•

LGWRによるRedo Recordの書出し

•

その他の処理

–

アーカイブ・ログ生成

–

Flashback Logの書出し

DB Server

SGA

Storage

Buffer Cache

PMON

LGWR

SP SP SP

PGA

SMON

Others

Log

Buffer

CR Block

Current Block

Undo Block

Consistent Reads

Parallel Query

SP

DBWn

SP SP

Buffer

Cache Hit

ストレージ性能が充分ではない場合

性能劣化の例は?

# Case

待機イベントの例

性能劣化の事象

1 Data Blockの

読込み遅延

db file sequential read

_{db file scattered read}

direct path read

SQL処理時間の劣化する

データが届かない為、

_{CPUリソースも活用出来ない状況}

2 Dirty Blockの

書出し遅延

free buffer waits

DBWRによるDirty Blockの書出しは、トランザクションとは非同期のため、この書出し

が遅延すること自体は直接的に

_{SQL処理時間へは影響しない。しかし、Dirty Blockが}

Buffer Cache上に増加することで、他のSQL処理で使用したいBlockをキャッシュし切

れなくなるため、

_{free buffer waits待機イベントが発生し、最終的にはユーザーのSQL}

処理時間の劣化につながる可能性有り

3 Redo Recordの

書出し遅延

log file sync

log buffer space

Commitのレスポンス・タイムが遅延する。最悪、書き出されていないRedo Recordが

Log Buffer内に滞留することで、Log Bufferの空きスペースが枯渇し、新たなRedo

Recordを生成する処理を実行できず待機する可能性有り

【注意ポイント！】

Oracle® Databaseパフォーマンス・チューニング・ガイド

パフォーマンス・チューニング

•

処理量を減らす

–

Index, Partitioning, Compression, Exadata Smart Scan/Storage Index …

•

高速化

–

Database In-Memory, Flash Device, InfiniBand, Exafusion, …

•

並列化

–

Parallel Query, Multi-Core, RAC,

ASM

, …

基本的な考え方

時間↓ = 処理量↓ / （速度 * 並列度）↑

複数ディスク上へのデータベースの配置の課題

容量ベースで設計すると、Hot Spotが生まれる？

•

業務要件の複雑化やアプリ改修の短期化により、

データベースのオブジェクト単位で個別最適化を目指す運用は難しい

総ディスク割り当て容量

使用量（データ量）

Hot Sport?

!?

表

A

表

B

索引

TEMP

データへの

アクセス頻度

Hot Sportを回避する為のRAWデバイス構成例

目的はストライピングによるI/O性能の向上

しかし、管理性は？

従来のRAWデバイス構成の課題

•

表領域が非常に細かく分割されている

–

空き領域が表領域毎に独立している為、

無駄な空き領域が増大

–

監視対象（表領域）が多く、頻繁に領域不足に陥り、

運用工数が増大

–

データ・ファイル数が多く、

SQLの性能劣化

や

ミス・オペレーションを誘発

–

管理レイヤー数が多い為、運用オペレーションの

複雑化

•

データベース管理者とストレージ管理者の間での調整作業の難しさ

•

データ・ファイル追加時に、既存データをリバランスしていない

–

空き領域が新規ボリュームにのみ存在する為、新たにINSERTされるレコード

がそのボリュームに集中することで、

ボトルネックが発生し易い

–

既存レコードは既存ボリューム内に格納されている為、

性能改善効果は無し

運用の複雑化

従来のRAWデバイス構成の課題

•

領域不足/性能劣化の改善の為、ディスク追加

•

Hot Sport回避のためには、既存データの再配置が必要

ディスク追加時に必要なオペレーション

最新データが入っている

1本のみにアクセスが集中

Hot Sport?

データ退避

ディスク追加後、

RAIDグループ再構成

データロード後、

アクセスが均等化

こんなデータベース用のストレージがあったらいいな

•

全てのデバイスにデータが

均等に配置

されるような仕組み

–

データベースのパフォーマンス・チューニングで、

どのデータファイル（RAWデバイス）がボトルネックなのか？を特定する必

要が無くなる

•

容量やIOPSが不足した場合、新規デバイスを追加したら、

自動的に再配置

される仕組みがあるといいな。

–

RAIDグループの再構成やデータの入れ直しが必要無くなる

–

オブジェクト単位で容量やIOPS要件を整理する必要がなくなる

•

さらに、

低コスト

で組みたいが、

高い可用性

は維持したい

高性能、管理容易性、高可用性

本日の内容

なぜ、ストレージ設計が必要なのか

Oracle Automatic Storage Management

ASMの最新機能紹介

ExadataにおけるASM構成

まとめ

1

2

3

4

5

Oracle によるストレージ仮想化

•

Oracle Database 10g より提供されている、

ディスク構成の仮想化技術

–

Oracleデータベースに対してボリューム・マネー

ジャ兼ファイルシステム

•

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

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

•

複数ディスク・アレイにまたがってディスクを仮想化、

ディスク追加/削除時にデータを透過的に再配分

–

エディション(EE/SE)に関係なく、シングル環境、

クラスタ環境共に使用可

–

11g Release2より、ASMクラスタファイルシステム

が実装

Oracle ASMの基本思想

•

「全てのDiskの均等利用を目的に、データをストライプして全ての

Disk上に分散配置し、ミラーリングも行う」という設計手法

–

I/O性能の確保：全てのDiskのI/O帯域をフル活用

–

可用性を確保：ミラーリングの採用

–

設計の簡素化：物理的なDisk構成を隠蔽し、特別な設計は不要

Stripe And Mirror Everything (S. A. M. E)

ストライピング

ミラーリング

RAWデバイス構成とASM構成の比較

Oracle Automatic Storage Management

•

ストライピング

–

ASMディスク・グループ内の全ディスクでストライピングし、高性能を維持

•

ミラーリング

–

ファイルタイプに応じて、Oracleレベルでのミラーリング(2重化/3重化/ミ

ラー無し)を実装することで、ディスク障害に対する可用性の担保

•

動的リバランシング

–

ディスクの追加/削除時に自動的に既存データを自動再配置

容量やIOPS不足時に、ディスクを追加するだけでストレージ拡張を実現

3つの全体最適化機能

Oracle ASMによるストライピング

•

ASM Diskgroupに含まれる全てのASM Diskに対して、

ASM File（Data File）をFile Extent(Allocation Unit:=AU)単位に

分割して配置

ASM File（データファイル）の分散配置例

ASM Diskgroup

1

2

3

4

1

2

3

4

Disk

Disk

Disk

Disk

5

6

7

8

5

6

7

8

ASM File(Data File)

Oracle ASMによるストライピング

•

ASMのストライピングは、データファイル（ASM File）単位で均等化

•

RAIDのストライピングは、データファイル（ASM File）を認識不可

–

ハードディスク・レベルで、偏り（Hot Sport）が生まれてしまう可能性有り

RAIDとの違い

RAIDグループ

ASM Diskgroup

ASM Disk#2

ASM Disk#1

A C

E G

B D F H

DataFile#1

A B C D E F G H

I J K L M N O P

DataFile#2

I

K

M

O

J

L

N

P

_G

A

_H

B

C

_K

_M

D

_O

E

_J

I

_N

F

_P

L

Oracle ASMによるミラーリング

•

異なる障害グループに属するASM Disk間で保持

–

通常、リソース(電源等)を共有している単位(筐体/コントローラー)で設定

–

例えば、障害グループBのDisk障害が発生しても、ASMファイルへアクセス可

全てのASM DiskがPrimaryであり、Mirrorも保持

ASM Diskgroup

障害グループA

1

4

2

3

障害グループB

3

1

4

2

1

2

3

4

ASMファイル(Normal)

Primary Extent

Secondary Extent

Disk

Disk

【しばちょう先生の試して納得！DBAへの道】

第34回 ASMのミラーリングによるデータ保護(1)

～障害グループと冗長性の回復～

Disk

Disk

Oracle ASMによるミラーリング

•

Normal / High Redundancy（2重化、3重化）で構成されている場合

–

読み取り処理時に I/Oエラーを検知した場合

•

Oracle Clientに対して透過的（ORAエラーは戻らない）

•

サーバー・プロセスは、ミラー側から読み取ることで

処理継続

–

サーバー・プロセスは、不良ブロックの修復をASMへ依頼し、ASMが

自動修復

–

書き込み処理時に I/Oエラーを検知した場合

•

Oracle Clientに対して透過的（ORAエラーは戻らない）

•

I/Oエラーが発生しても、一つでも成功していればサーバープロセスは処理継続

–

書込み失敗をASMへ通知し、ASMが障害Diskが

自動でオフライン化

•

一時的な障害の場合、

高速ミラー再同期

により生存Disk側から必要最小限の差分データを同期

•

復旧できない場合、ASM Diskgroupから切り離し（

自動リバランス

が発生）

Oracle Clientに透過的、自動的に破損ブロックを修復

【参考】ディスクの同時二重障害を考慮した構成案

RAID1+0 × Normal vs. RAID0 × High の比較

•

ASMのHigh Redundancy（トリプル・ミラー）が効率的

–

Inifinibandを搭載したExadataであれば、よりメリットが出てくる

RAID1+0 ×

Normal

RAID0 × High

Read時にアクセスされるDisk数

6本

12本

Write時のFC帯域を流れるデータ量

2倍

3倍

Write時のストレージ内のI/O量

4倍

3倍

RAID1+0 × Normal vs. RAID0 × High

RAID1+0 × Normal vs. RAID0 × High

RAID1+0 × Normal vs. RAID0 × High

Oracle ASMのリバランス（自動データ再配置）

•

ASM Diskを追加／削除（故障）した際、データの再配置を実施

–

メタデータ（配置状況）を元に、

ASM File単位で

全てのDiskに均等配置され

るように、

最小限のExtent（AU）の移動

で実現

–

多重度（リバランス強度）の設定や計画実行で、業務影響を制御可能

データベース無停止でリバランスが可能

+

Add

-Drop

REBALANCE

ASMによるデータの分散配置

Data File単位で各ASM Diskに対し均等にFile Extent(AU)を割り当て

TBS

Data File

TBS

Data File

CREATE TABLESPACE

TBS

DATAFILE

’+DATA’

SIZE 1G ;

ALTER TABLESPACE

TBS

RESIZE 2G ;

(1) 表領域の作成

(2) 表領域の拡張

File Extent（AU）

TBS

Data File

ALTER DISKGROUP

DATA

ADD DISK

'/dev/sde1‘

;

(3) 新規Diskの追加（リバランス）

ASMによるデータの分散配置

リバランス処理の2つのフェーズ

•

リバランス・フェーズ

–

ASM File（= Data File）単位で、各ASM Diskの

利用率を均等

に分散し直す

–

追加Diskへ移動するFile Extentは、全てのASM Fileが対象

•

コンパクション・フェーズ

–

リバランス・フェーズでFile Extentが追加Diskへ移動することで、

既存Diskでは歯抜け状態になるが、コンパクション処理でその状態を解消

•

ASM Disk毎に、後方に位置するFile Extent（AU）から順番に前方の空きスペースへ移動

【しばちょう先生の試して納得！DBAへの道】

Add Disk時の各デバイスのI/O量（時系列）

Oracle ASMリバランスの進捗確認

–

PASS：12.1~追加された列で、コンパクション・フェーズに対応。

•

従来はOPERATION列でコンパクション未対応のため、V$ASM_OPERATIONでリバランス・

フェーズが完了しても、内部的にコンパクション・フェーズが動いていて待たされていた。

–

SOFAR : 完了した処理量

–

EST_WORK：完了までに処理すべき処理量

EST_MINUTES：完了までの残り見積り時間（分）

ASMインスタンスのV$ASM_OPERATIONビュー

SQL> SELECT PASS, STATE, SOFAR, EST_WORK, EST_MINUTES

2 FROM V$ASM_OPERATION;

PASS STATE SOFAR EST_WORK EST_MINUTES

--- - --- ---

---RESYNC DONE 0 0 0

REBALANCE RUN 1658 4813 2

COMPACT WAIT 0 0 0

リバランス強度の設定

Grid Infrastructure 11.2.0.2以降

•

リバランス強度の設定可能範囲が0~1024へ（以前は、0~11）

–

ARB0プロセス（クラスタで1つのみ起動）が同時に発行する非同期I/Oの数

•

ストレージのI/O性能に応じた適切な値を設定すること

–

リバランス強度の設定箇所

•

ASM_POWER_LIMITS初期化パラメータ < リバランス実行するALTER DISKGROUP文

–

事前準備：

対象のASM DiskgroupのCOMPATIBILITY.ASM属性を11.2.0.2以上

•

デフォルト値は、ASM Diskgroupを作成する方法に依存するので注意

–

例えば、Oracle ASM 12cでは、12.1がASMCA使用時のCOMPATIBLE.ASM属性のデフォルト設定

SQL CREATE DISKGROUP文とASMCMD mkdgコマンドを使用する場合のデフォルト設定は10.1

Fast Mirror Resync（高速ミラー再同期）

一時的なディスク障害の復旧を高速化 (11g Release 1~)

•

本機能が実装される以前の課題

–

ストレージ・メンテナンスや一時的な I/O 障害（ディスク・パス障害や電源障

害等）にも関わらず、対象ディスクの削除+自動リバランスが行われてしまう

•

復旧後に、ディスク追加 + 再度リバランスを実行する必要有り

•

本機能により、上記課題を解決

–

指定期間（デフォルト3.6時間）は、障害ディスクをOFFLINE状態（

自動削除

を保留

）で保ち、復旧後にOFFLINE中に書き込まれるはずであった

差分データ

のみをミラーデータを使用して高速同期

•

指定期間が経過しても復旧しない場合は、対象ディスクの削除+自動リバランス

【しばちょう先生の試して納得！DBAへの道】

第35回 ASMのミラーリングによるデータ保護(2) ～高速ミラー再同期～

Fast Mirror Resync（高速ミラー再同期）

•

ASM Diskgroup単位で事前設定が可能

–

設定値は、V$ASM_ATTRIBUTEビューから確認

•

ディスク障害を検出後にカウントダウンを開始

–

V$ASM_DISKビューのREPAIR_TIMER列で確認

disk_repair_time属性の設定、障害発生時のカウントダウン値の確認

alter diskgroup <ASM Diskgroup Name>

set attribute 'disk_repair_time' = '24h';

GROUP_NUM DISK_NUM HEADER_S STATE PATH NAME FAI TOTAL FREE REPAIR_TIMER

--- --- --- --- --- --- --- --- ----

---3 0 MEMBER NORMAL /dev/sdj1 DGN_D1 FG1 1019 5---37 0

3 1 MEMBER NORMAL /dev/sdk1 DGN_D2 FG1 1019 537 0

Fast Mirror Resync（高速ミラー再同期）

•

前頁の設定方法は、あくまで事前定義の扱い

–

ディスク障害が発生した後に実行しても、

まさにカウントダウンをし始めた値に反映されない

•

ディスク障害発生後、当初のdisk_repair_time属性の値が小さ過ぎ

たので、Drop Diskまでの時間を追加する方法（上書き）

障害発生後に、ディスク削除までの時間を引き延ばす方法

alter diskgroup <ASM Diskgroup Name>

offline disks <ASM Disk Name> drop after 24h ;

alter diskgroup <ASM Diskgroup Name>

Oracle ASMの構成例

Simple is the BEST

Oracle ASMによる運用管理の簡素化

•

オペレーションの簡素化

–

表領域拡張やDisk追加の手順が簡素化し、運用オペミスの

リスクが減少

•

管理対象オブジェクトの削減

–

ASM Diskgroupの容量内で表領域を自由に拡張可能であり、従来のVolume

やRAWデバイス（データファイル）を

意識する必要なし

–

ストライピングでI/Oが均等化することで、表領域を細かく分割してI/O競合

を回避する必要なし。

表領域の総数を大幅に削減可能

•

データ再配置の工数不要

–

Disk追加時に自動的に既存データの再配置（リバランシング）を実施

従来構成の課題を解決

ASMによるデータベースの物理設計の簡易化

Storage

ASM Diskgroup

ASM Diskgroup

【参考】 データベース統合とASM Diskgroup

同一Oracle Clusterware上のOracle Databaseは、同一のASM Diskgroup

を利用可能

DB Server

Oracle Clusterware

Single DB(a)

SGA

Single DB(b)

SGA

DB Server

RAC DB(c)-1

SGA

RAC DB(d)-1

SGA

DB Server

RAC DB(c)-2

SGA

RAC DB(d)-2

SGA

Oracle Clusterware

Single Databases

RAC Databases

マウント不可

Single DB(A)のDatafiles

Single DB(b)のDatafiles

DB毎の

領域制限は？

RAC DB(c)のDatafiles

RAC DB(d)のDatafiles

ASMに最適なストレージ構成

Oracle Automatic Storage

Management に対して、

ストレージ側のLogica lUnit

（=ASM Disk）の最適な構

成方法について、幾つかポイ

ントをご紹介します。

ハードディスク・ドライブの性能特性

内周よりも外周の方がI/O性能が高い

•

一般的に、デバイスの先頭が外周

=> ASM Diskの先頭が外周

•

一般的に、

ハードディスクの外周から切り出すと言われているので、

先に切り出したLogical Unitの方が性能が高い

–

例）先に切り出したLogical Unit#1の方がディスクの外周に配置される為、

性能を比較すると、Logical Unit#1 > Logical Unit#2

Logical Unit#2

Logical Unit#1

RAIDグループからの切り出す順番と配置

HDDの同一RAIDグループから切り出したLUを

同一ASM Diskgroupへ組み込むのは？

•

ディスクの外周と内周を行ったり来たりすることで、

シークによる待機時間の比率が高まる為に好ましくない

Logical Unit#2

Logical Unit#1

RAIDグループ

ASM Diskgroup

ASM Disk#2

ASM Disk#1

A C E G

B D F H

ASM File

A B C D E F G H

Table Full Scan

A

C

E

G

B

D F

H

ASM Diskgroupに所属するASM DiskへのI/O特性

•

ASMは、各ASM Diskの使用率を「均等化」する

–

サイズが異なるASM DiskでASM Diskgroupを構成した場合、

サイズが大きなASM Diskへ、より多くのデータが格納される



アクセス量にも偏りが生じてしまう！

使用率

50%

_使用率

50%

ASM

Diskgroup

使用率

50%

使用率

50%

ASM

Diskgroup

均等配置 = 均等アクセス

ASM Disk

サイズ

×

○

追加HDDの容量が現行より大きい場合

•

パフォーマンス最適化の観点から、追加ハードディスクから切り出すLogical

Unit（ASM Disk）のサイズは

現行のASM Diskと統一

すること

–

容量が勿体ないのは理解できますが、性能劣化（偏り発生）の可能性を避けるべきです

•

余っている領域も、別のLUとして切り出して、別のASM Diskgroupを構成可能

–

但し、バックアップや古いデータの格納領域のように、

日中業務の負荷ピーク時間帯にアクセスが少ない用途として活用すべし

50%

50%

ASM Diskgroup

50%

50%

50%

50%

NGな例

現行HDDで運用、新規でSSDの追加が決定したら

•

データベース全体をSSD上に移設できる容量の場合

–

ASM Diskgroupを丸ごと移行

•

一部のデータしか移動できない場合

–

SSDのみで構成されるASM Diskgroupを作成し、次のどちらかの方法で活用

1.

特定のオブジェクトや表領域をSSD上に配置



AWRレポートを元に、手動でチューニング

第40回 AWRレポートを読むステップ2:アクセス数が多い表領域とセグメント

2.

Database Smart Flash Cacheの活用

【参考】 新規デバイス上へのデータ移行方法例

第

47回 [Oracle Database 12c] オンライン・データファイルの移動

Level

完全無停止での移行方法

一時停止やオフラインを伴う移動方法

Table

表のオンライン再定義

[12.1] オンラインでのパーティション移動

Datapump Export /Import

表、パーティションの移動（

alter table move文）

Pluggable Database

Unplug & Plug

Tablespace / Datafile [12.1] オンライン・データファイルの移動

（

alter database move datafile文）

オフライン・データの移動

（

alter tablespace rename datafile文）

トランスポータブル表領域

RMAN COPY + SWITCH DATAFILEコマンド

Database

オフライン・データファイルの移動

（

alter database rename datafile文）

RMAN COPY+SWITCH DATABASEコマンド

RMAN Duplicateコマンド

【参考】 システム無停止で、ストレージ筐体の入替

•

http://www.oracle.com/jp/gridcenter/partner/nssol/wp-storage-mig-grid-nsso-289788-ja.pdf

しばちょう流 Oracle ASMにおけるストレージ設計指針

2016年10月版

1.

一つのRAID Groupは、一つ or 二つ+αのLogical Unitを切り出す



各RAID Groupから切り出した順序毎にASM Diskgroupで束ねる



可能な限り多くのLUを一つのASM Diskgroupで束ねる

2.

各ASM Diskgroupに含めるASM Disk(LU)は同一の性能 &サイズ



デバイス・タイプ（HDDやSSD）に応じて、別ASM Diskgroupを構成

3.

RAIDグループと冗長構成パターン例



二重障害対応構成は「RAID無し or RAID0」 × ASM3重化

•

各ASM Diskgroupへ含めるASM Disk（LU）のサイズは統一

•

DataFileは+DATAへのみ格納、負荷ピーク時間帯にシーク時間を極小化（+FRAはバックアップ）

•

RAID設定が必須なストレージの場合、最小限の本数で組んだRAID0のRAIDグループを複数作成

Failure Group#2

Failure Group#3

Failure Group#1

ASM Diskgroup構成例

RAIDミラー無し + ASM三重化

Disk Enclosure#1

LU#2

LU#1

LU#4

LU#3

Disk Enclosure#2 Disk Enclosure#3

+DATA

Diskgroup

+FRA

Diskgroup

・・・

・・・

・・・

・・・

・・・

・・・

・・・

・・・

RAIDグループを構成する場合は、後々の

HDDの追加購入単位も考慮しておきましょう

本日の内容

なぜ、ストレージ設計が必要なのか

Oracle Automatic Storage Management

ASMの最新機能紹介

ExadataにおけるASM構成

まとめ

1

2

3

4

5

主なASM関連機能の拡張

•

2.7.1 Oracle ASMの拡張

–

2.7.1.1 Oracle Flex ASM

–

2.7.1.2 ディスク・グループでのOracle ASMの共有パスワード・ファイル

–

2.7.1.3 Oracle ASMリバランスの拡張

–

2.7.1.4 Oracle ASMディスク再同期化の拡張

–

2.7.1.5 Oracle ASM chown、chgrp、chmodおよびオープン・ファイルの…

–

2.7.1.6 Oracle ASMでのALTER DISKGROUP REPLACE USERのサポート

–

2.7.1.7 Enterprise ManagerでのOracle ASM機能のサポート

–

2.7.1.8 WindowsでのOracle ASMファイル・アクセス制御

–

2.7.1.9 個別パッチに関するOracle Grid Infrastructureのローリング移行

ASM DiskgroupのCOMPATIBLE属性と機能

Oracle® Automatic Storage Management管理者ガイド 12cリリース1

使用可能なディスク・グループ機能

COMPATIBLE.

ASM

COMPATIBLE.

RDBMS

COMPATIBLE.

ADVM

より大きなAUサイズ(32または64MB)のサポート

>= 11.1

>= 11.1

該当なし

V$ASM_ATTRIBUTEビューに表示される属性

>= 11.1

該当なし

該当なし

高速ミラー再同期

>= 11.1

>= 11.1

該当なし

可変サイズのエクステント

>= 11.1

>= 11.1

該当なし

Exadataストレージ

>= 11.1.0.7

>= 11.1.0.7

該当なし

インテリジェント・データ配置

>= 11.2

>= 11.2

該当なし

ディスク・グループに格納されるOCRおよび投票ファイル >= 11.2

該当なし

該当なし

デフォルト値以外に設定されるセクター・サイズ

>= 11.2

>= 11.2

該当なし

ディスク・グループに格納されるOracle ASM SPFILE

>= 11.2

該当なし

該当なし

Oracle ASMファイル・アクセス制御

>= 11.2

>= 11.2

該当なし

最大値が1024のASM_POWER_LIMIT

>= 11.2.0.2

該当なし

該当なし

ディスク・グループのコンテンツ・タイプ

>= 11.2.0.3

該当なし

該当なし

ディスク・グループのレプリケーション・ステータス

>= 12.1

該当なし

該当なし

ディスク・グループでの共有パスワード・ファイルの管理 >= 12.1

該当なし

該当なし

[12.1] Oracle Flex ASM

•

ASMインスタンスをDBインスタンスが稼働するサーバーと

分離

–

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

–

クラスタ全体でデフォルトで3つのASMインスタンスが起動

–

ASMによるリソース(メモリー、CPU、ネットワークなど)使用量を低減

–

障害ポイントの削減

•

ASMインスタンスの障害発生時、DBインスタンスは別の生存ASM

インスタンスへ接続をフェイル・オーバーして処理継続可能

–

ASMインスタンスへの依存性が緩まり、DBサービスの可用性が向上

ASMインスタンスの柔軟な構成による可用性の向上

[12.1] Oracle Flex ASM

ASMインスタンス障害発生時の挙動

•

従来のASM構成（左図）では、ASMインスタンスが障害でDownした場合、

同一Node上のDBインスタンスもDownする仕様

•

Flex ASM構成（右図）では、別Node上のASMインスタンスへ再接続が可能

ASM

ASM

ASM

ASM

DB

_A

DB

_A

DB

_B

DB

_B

ASM

ASM

DB

_A

DB

_A

DB

_B

DB

_B

ASM

DB

_B

ASM

DB

_B

[12.1] Oracle ASMリバランスの拡張（1）

REPLACE DISKコマンドで、効率的なディスク交換

•

ディスク交換後の操作を一つのコマンドで実施可能

–

交換するディスクの DROP 操作は不要 (OFFLINE 操作は必要)

•

以前のリリースでは、ディスク交換に伴い、2度のリバランスを実行する必要あり

–

交換するディスクをDROP+冗長性回復の為のリバランスを実行した後、

新ディスクを追加+再リバランスする必要があった

–

交換するディスクには、新しいディスクを元のディスクと同じ名前で追加され、

元のディスクと同じ障害グループに割り当てられる。

SQL>

ALTER DISKGROUP DATA REPLACE DISK DATA_0001 with '/dev/sdz';

【しばちょう先生の試して納得！DBAへの道】

[12.1] Oracle ASMリバランスの拡張（2）

優先順位と同時処理

•

リバランス処理を

重要なファイルから順

に実施

–

制御ファイルや REDO ログ・ファイルなどを優先してリバランス処理を実施

–

以前のリリースまでは、file 番号順に実施されていた

•

複数のディスク・グループのリバランス処理の並列実行

–

リバランス処理が完了するまでの時間を短縮

–

以前のリリースまでは、リバランス処理はシリアルに行われた

–

複数のディスク・グループに対して同時にリバランス処理がリクエストされた場合は、

後からリクエストされた処理はキューで待機

•

リバランス処理時に、内部的にエクステントの論理チェックするように設定可能

–

破損を検知した場合、ミラーされているデータから自動で修正

–

CONTENT.CHECK ディスク・グループ属性で設定

[12.1] Oracle ASMリバランスの拡張（3）

Explain Workコマンドで、リバランスの詳細な見積もり

•

リバランス処理の作業量を見積もることが可能

–

EXPLAIN WORK コマンドを使用して work plan を生成

–

work plan は STATEMENT_ID で識別される

•

見積もった 作業量を V$ASM_ESTIMATE ビューから確認

SQL> EXPLAIN WORK SET STATEMENT_ID='Drop DATA_0001'

2 FOR ALTER DISKGROUP DATA DROP DISK DATA_0001;

Explained.

SQL> SELECT EST_WORK FROM V$ASM_ESTIMATE

2 WHERE STATEMENT_ID='Drop DATA_0001';

EST_WORK

---[12.1] Oracle ASMディスク再同期化の拡張

POWER 句の指定による高速ミラー再同期処理の高速化

•

ASM Diskgroupの高速ミラー再同期の処理に割り当てるリソース量

をPOWER 句により任意に設定することが可能

–

従来バージョンまでは、常に「1」

で固定

–

12.1以降、POWER 句で 1 から 1024 まで指定可能

•

指定しない場合は、ASM_POWER_LIMITパラメータの値

–

対象ASM Diskgroup内でOFFLINEなASM Diskを全てOnline化

–

対象ASM Diskgroup内の特定のASM DiskをOnline化

alter diskgroup <ASM Diskgroup Name> online all power <n>;

【参考】高速ミラー再同期のPOWER値の動的変更

•

実行中のResync処理の強度を変更したい場合は？

–

○ alter diskgroup

rebalance

power <n> ; を上書き実行で変更可能

–

× alter diskgroup

online disk

power <n>; を上書き実行では変更不可

通常のリバランス処理のPOWER値の変更方法と同じ

SQL>

alter diskgroup DATA_H online disk DATA_H_CD_09_JOJOC01 power 14;

alter diskgroup DATA_H online disk DATA_H_CD_09_JOJOC01 power 14

*

ERROR at line 1:

ORA-15032: not all alterations performed

[12.1] Oracle ASMのディスク修正

•

Normal、またはHigh RedundancyのASM Diskgroupにおいて、

論理データの破損をチェックして自動的に修復する機能

–

データベースのWorkloadでは読み取られる可能性が少ないデータやASMのミ

ラーデータを検査することによって、可用性および信頼性が向上

–

本番システムでの通常のI/Oへの影響を最小限に抑える仕組み有り

–

実行単位：ASM Diskgroup、ASM Disk、ASM File

SQL> ALTER DISKGROUP data SCRUB POWER LOW;

SQL> ALTER DISKGROUP data SCRUB DISK DATA_0005 REPAIR POWER HIGH FORCE;

SQL> ALTER DISKGROUP data SCRUB FILE

[12.1] Oracle ASMのディスク修正

•

REPAIR

–

検出した破損を自動的に修復。指定しない場合は、破損チェックのみを実行

•

POWER

–

AUTO/LOW/HIGH/MAXの4種類。指定しない場合はAUTO

•

WAIT

–

指定した場合はコマンド実行完了後まで待機

–

修正プロセスの実行中は、V$ASM_OPERATIONビューにて確認可能

•

FORCE

システムのI/O負荷が高い場合でも強制的にコマンド実行させる

各種オプションの動作

【おまけ】ディスクの削除解除（11.1~）

•

対象のASM Diskgroup内のASM Diskに対して、保留中の削除操作

を全て取り消すことが可能

–

以下のASM Diskは対象外

•

ディスクの削除操作（削除に伴う冗長性回復の為のリバランス）が完了している

•

ASM Diskgroupの削除に伴い削除されたASM Disk

•

FORCE句を使用してDrop Diskが実行されたASM Disk

–

使用上の注意点

•

削除に伴う冗長性回復の為のリバランスをPOWER=0で停止させている状況で、

このUNDROP DISKSコマンドを実行した場合、コマンドは正常に実行される。

•

ただし、V$ASM_OPERARIONビューには、リバランス処理がPOWER=0で残っているの

で、POWER=1以上でのリバランスを再実行すれば消える

12.2

Oracle Automatic

[12.2] Oracle ASM Flex Disk Groups

•

ASMの冗長性は、Diskgroupレベルで設定



冗長性毎にASM Diskgroupを作成しなければな

らず、

容量設計が必要

？



冗長性を変更するには、Diskgroupの

再作成

•

複数データベースで一つのASM Diskgroupを

共有する場合、各データベースの使用量制限

を設けることができない



データベース毎に、ASM Diskgroupを作成しな

ければならず、

容量設計が必要

？

従来のASM Diskgroupの課題

Pre-12.2 diskgroup Organization

Diskgroup

DB3 : File 1

DB2 : File 2

DB1 : File 3

DB3 : File 3

DB2 : File 1

DB1 : File 1

DB1 : File 2

DB2 : File 3

DB3 : File 2

DB2 : File 4

[12.2] Oracle ASM Flex Disk Groups

•

新しいTYPEのASM Diskgroup

–

従来のRedundancy（External/Normal/High）に、

「FLEX」という新しい設定が追加

–

File Group/Quota Groupがサポートされる

•

File Group毎に冗長性を設定可能

•

Quota Group毎に使用量制限が可能

•

使用条件

–

COMPATIBLE.ASMとCOMPATIBLE.RDBMSを

12.2以上に設定する必要あり

データベースのストレージ管理を、より柔軟かつ高可用に

12.2 Flex Diskgroup Organization

Flex Diskgroup

DB1

File 1

File 2

File 3

DB2

File 1

File 2

File 3

File 4

DB3

File 1

File 2

File 3

File Group

Quota

Group

[12.2] Oracle ASM Flex Disk Groups

•

作成

•

移行(Normal RedundancyのDiskgroupをFlexへ)

作成と移行

create diskgroup <ASM Diskgroup Name>

FLEX REDUDANCY

disk '/dev/sdj1', '/dev/sdk1', '/dev/sdl1', '/dev/sdm1'

attribute

'COMPATIBLE.ASM' = '12.2',

'COMPATIBLE.RDBMS' = '12.2'

;

alter diskgroup <ASM Diskgroup Name> mount restricted ;

[12.2] Oracle ASM Flex Disk Groups

•

冗長度、ストライピング粒度、リバランス強度等の設定の管理単位で、

データベースやPDBに紐づけて作成

–

動的にファイル冗長度（HIGH  MIRRORUNPROTECTED）の変更可

–

作成例

–

変更例

Oracle ASM File Groups

SQL> alter diskgroup flexdg

add filegroup

FG_ORCL database orcl;

SQL> alter diskgroup flexdg modify filegroup FG_ORCL

set 'datafile.redundancy' = 'HIGH';

[12.2] Oracle ASM Flex Disk Groups

•

変更前の状態確認

Redundancyの変更（MIRROR  HIGH）

ASMCMD [+FLEXDG/orcl] > lsfg -G FLEXDG --filegroup FG_ORCL

File Group Disk Group Property Value File Type

FG_ORCL FLEXDG PRIORITY MEDIUM

FG_ORCL FLEXDG STRIPING COARSE

FG_ORCL FLEXDG REDUNDANCY HIGH CONTROLFILE

FG_ORCL FLEXDG STRIPING FINE CONTROLFILE

FG_ORCL FLEXDG REDUNDANCY

MIRROR

DATAFILE

FG_ORCL FLEXDG REDUNDANCY

MIRROR

ONLINELOG

FG_ORCL FLEXDG REDUNDANCY

MIRROR

ARCHIVELOG

FG_ORCL FLEXDG REDUNDANCY

MIRROR

TEMPFILE

FG_ORCL FLEXDG REDUNDANCY

MIRROR

PARAMETERFILE

...

[12.2] Oracle ASM Flex Disk Groups

•

変更の実行と確認

Redundancyの変更（MIRROR  HIGH）

SQL> alter diskgroup FLEXDG modify filegroup FG_ORCL

set 'redundancy'='

high

';

File Group Disk Group Property Value File Type

...

FG_ORCL FLEXDG REDUNDANCY HIGH CONTROLFILE

FG_ORCL FLEXDG STRIPING FINE CONTROLFILE

FG_ORCL FLEXDG REDUNDANCY

HIGH

DATAFILE

FG_ORCL FLEXDG REDUNDANCY

HIGH

ONLINELOG

FG_ORCL FLEXDG REDUNDANCY

HIGH

ARCHIVELOG

FG_ORCL FLEXDG REDUNDANCY

HIGH

TEMPFILE

FG_ORCL FLEXDG REDUNDANCY

HIGH

PARAMETERFILE

[12.2] Oracle ASM Flex Disk Groups

•

Oracle ASM File Groupsの領域割り当てを制御する設定

–

複数のFile Groupを一つのQuota Groupに紐づける事も可能

–

任意のFlex Diskgroupに対して、新規Quota Groupの作成例

–

作成したQuota Groupを確認

Quota Groups for Oracle ASM File Groups

ASMCMD [+] > lsqg -G FLEXDG

Quotagroup_Num Quotagroup_Name Incarnation Used_Quota_MB

Quota_Limit_MB

1 GENERIC 1 6512 0

2 QG_TEST01 1 0 1024

[12.2] Oracle ASM Flex Disk Groups

–

任意のFile Groupに対して、作成したQuota Groupを紐づけ

–

この後、FLEXDGディスクグループ上に作成した表に対してInsert 処理を繰

り返すと、表領域が自動拡張でASM Diskgroupとして空き領域があるにも関

わらず、次のORAエラーが発生

–

使用量の確認するとQuotaの上限

Quota Groups for Oracle ASM File Groups（つづき）

SQL> alter diskgroup FLEXDG modify filegroup FG_TEST_DB02

set 'quota_group'

='qg_test01';

ORA-01653

: 表SCOTT.TBLCを128(表領域USERS)で拡張できません

ASMCMD [+] > lsqg -G FLEXDG

Quotagroup_Num Quotagroup_Name Incarnation Used_Quota_MB

Quota_Limit_MB

1 GENERIC 1 6512 0

[12.2] Oracle ASM Flex Disk Groups

•

よりASMの基本思想S.A.M.Eに近づく拡張

–

S.A.M.E:=「全てのDiskの均等利用を目的に、

データをストライプして全てのDisk上に分散配置

し、ミラーリングも行う」という設計手法

–

より多くのデバイスで一つのプール化が可能とな

り、ストレージの使用効率の改善を実現できる

•

複数Diskgroupによる空き領域の分断からの解放

•

IO要求をより多くのデバイスへ均等化

•

可用性要件（冗長度）への柔軟な対応

データベースのストレージ管理を、より柔軟かつ高可用に

12.2 Flex Diskgroup Organization

Flex Diskgroup

DB1

File 1

File 2

File 3

DB2

File 1

File 2

File 3

File 4

DB3

File 1

File 2

File 3

File Group

Quota

Group

リファレンス

•

Automatic Storage Management Administrator's Guide

–

http://docs.oracle.com/database/122/OSTMG/toc.htm

•

4 Administering Oracle ASM Disk Groups

–

Managing Flex Disk Groups

•

About Oracle ASM Flex Disk Groups

•

About Oracle ASM File Groups

•

About Oracle ASM File Group Properties

•

About Quota Groups for Oracle ASM File Groups

本日の内容

なぜ、ストレージ設計が必要なのか

Oracle Automatic Storage Management

ASMの最新機能紹介

ExadataにおけるASM構成

まとめ

1

2

3

4

5

柔軟なシステム構成、スケールアウトを実現

Oracle Exadata

Half

_Full

Eighth

_Quarter

•

2 台のDatabase Serverと3台のStorage Serverからスタート

-

必要な分だけDatabase ServerもしくはStorage Serverを追加

旧世代のマシンも新世代のサーバーで拡張可能

Oracle Exadata

•

一般的な構成

一般的な構成とExadata構成の差異

•

Oracle Exadataの構成

IA Server

IA Server

SAN Storage

(Fiber Channel)

Linux

Clusterware

Linux

Oracle S/W

Oracle S/W

Real Application Clusters

Storage

Controller/Cache

Database

Oracle Linux

Exadata S/W

IA Server

IA Server

Oracle Linux

Oracle Linux

Oracle S/W

Oracle S/W

Real Application Clusters

Cell Server

(IA Server)

Database

ストレージにServerを採用することでDBクラスタとの間で

互いに連携し補完する機能が実装可能になった

Oracle Exadataがスケーラブルな一つの理由

•

複数のCell ServerをInfiniBand Networkで接続し、

ASMのテクノロジーで大量デバイスの性能を完全に引き出せるから

–

しかも、事前最適化済みのストレージ構成

InfiniBand

マルチコア

・

複数ノードのマルチコアを使用

した並列処理を実行

・全てのディスクにデータを分散

・DBサーバーの性能を活かす

並列ディスクI/O処理

Real Application Clusters

Exadata X6

-

DB I/O性能に革新をもたらした

301 GB/sec

分析スループット

560

万

8K OLTP Read IOPS

520

万

8K OLTP Write IOPS

240

万

IOPS

時に

250 us I/O

レイテンシ

ラックを追加すれば更に拡張可能

汎用のオールフラッシュ・ストレージを大きく越えた

Exadata X6の第二進化形態

Exadata

DB Servers

Exadata Smart Storage

InfiniBand

CPU

PCIe NVMe

Flash

クエリ

オフロード

ストレージ帯域

300GB/sec

DBメモリ帯域

800GB/sec

•

最新のFlash、PCIe NVMe、

InfiniBandを

ソフトウェア技術群

で事前チューニング済み

(Smart Scan/HCC/ExaFusion、等)

•

メモリレベル

の帯域幅をもつ

データベース・ストレージ

は

市場で

Oracle Exadata

だけ

•

Oracle Database 12c R2 では

更なるインメモリ＋フラッシュ技

術の進化を計画

※ソフトウェア・アップデートで入手可能

業務を変える驚異的なパフォーマンスを実現

検索処理

1時間30分

1分(Exadata)

バッチ処理

2時間

7分(Exadata)

検索処理:某DWH製品との比較

4分

6秒(Exadata)

明細からのアドホック分析（EUC）

20分

30秒(Exadata)

データロード処理

30時間

1時間(Exadata)

データサマリ処理

10時間

10分(Exadata)



ノンチューニングで大幅なパフォーマンス向上



朝までに終わらないバッチ処理が、余裕で終わるようになった



従来不可能だった明細データからのアドホック分析が数～数十秒で完了



明細からの集計が高速になり、集計バッチ処理が不要になった



パフォーマンスの問題で実現できなかったリアルタイム連携が可能になった

バッチ処理：取引データを一定の条件で加工/集計

4時間

10分(Exadata)

店舗別/商品別 売上動向検索

30時間

21分(Exadata)

NTT docomo : MoBills (Mobile Billing System)

Benefits

Business Objectives

•

6600万顧客に対するリアルタ

イム・ビリング基盤

• 新サービスの追加やトラ

フィック量の増加に耐えうる

高い性能と拡張性、可用性

• コスト削減

Solution

•

Oracle Exadata X4-2 : 30ラック

リアルタイム計算

課金処理の高速化

10倍の性能向上

約

300万

SQL /sec

データセンターの

スペース削減

350ラック



30ラック

導入コスト

削減

旧システム比

約

_4分の1

MoBillsは、『+d』の実現に向けた取り組みを推進する基幹システムと

してきわめて重要な位置づけにあります。『Oracle Exadata』は非常に

安定して稼動しており、期待どおりの性能を発揮しています。今後も

『Oracle Exadata』を活用することで、さらなる優位性を確立していきた

いと思います。

- 株式会社NTTドコモ 情報システム部 料金システム担当 担当部長 嶌村友希氏

高可用性

Oracle MAA

Pre-Exadata

•

High-end Server & storage :

350 racks

•

Storage Mirror Backup

•

Storage Mirror Replication

•

Oracle 9i Database Release 2

運用コスト

削減

旧システム比

約

_2分の1

Exadata MAA

•

Exadata X4-2 :

30 racks

[= 1 racks * 5 sets

* 3(Primary + 2 Standby) * 2 System]

•

Local & Remote Data Guard Standby

Oracle Exadata – Database Machine

•

一本のデバイスを最低3つのパーティションに分割。ASM側でのみミラーリング。

•

DataFileは+DATAへのみ格納、その他（+RECOはバックアップ、+DBFSは作業領域）

Failure Group#2

Failure Group#n

Failure Group#1

Oracle Exadata

事前定義済みのASM構成例

Cell Server#1

disk#2

disk#1

Cell Server#2

Cell Server#n

+DBFS

_・・・

_・・・

_・・・

・・・

・・・

+RECO

_・・・

_・・・

_・・・

+DATA

_・・・

_・・・

_・・・

disk#3

Exadata特有な機能

ASM関連

•

Cell Server間でのデータ転送

–

DB Serverを経由せず、Cell Server間だけでデータを移動する事が可能

–

これにより、InfiniBandネットワークを通じた転送量を従来の二分の一に抑え、

データベースサーバーのメモリ使用量も抑えることが可能

•

コンパクション処理の省略

–

リバランス処理時間の短縮とDiskに対する負荷軽減（アプリへの影響軽減）

•

パートナリング・アルゴリズムの最適化

–

Exadata Storage Server Software 11.2.3.3.0以降、ASM Appliance Modeが導入され、

ASM Diskgroup内のASM Diskのパートナリングのアルゴリズムが最適化

–

これにより、ASM Diskが削除された際の冗長性回復の高速化を実現

•

H/W構成が決まっているExadataだからこそ有効化可能なテクノロジー

本日の内容

なぜ、ストレージ設計が必要なのか

Oracle Automatic Storage Management

ASMの最新機能紹介

ExadataにおけるASM構成

まとめ

1

2

3

4

5

まとめ

•

Simple is the BEST

–

ASMを使用すれば、

I/O性能を最大限に引き出しつつ、容易な管理性を両立可能

•

最新バージョンでは柔軟性が強化され、

ASMの基本思想S.A.M.Eをより体現するものに進化

–

S.A.M.E:=「全てのDiskの均等利用を目的に、データをストライプして全て

のDisk上に分散配置し、ミラーリングも行う」という設計手法

Oracle ASMの構成例

Simple is the BEST

しばちょう先生の試して納得！DBAへの道

本資料に関連する記事一覧

•

Automatic Storage Management

–

第30回 ASMディスク・グループの作成と使用量の確認

–

第31回 ASMのストライピングとリバランスによるI/O性能の向上

–

第33回 ASMのリバランスの動作

–

第34回 ASMのミラーリングによるデータ保護(1) ～障害グループと冗長性の回復～

–

第35回 ASMのミラーリングによるデータ保護(2) ～高速ミラー再同期～

–

第49回 [Oracle Database 12c] ASMディスク・グループ内のディスクの置換

•

I/Oボトルネックのチューニング手法

–

第39回 AWRレポートを読むステップ1:バッファキャッシュ関連の待機イベントと統計情報

–

第40回 AWRレポートを読むステップ2:アクセス数が多い表領域とセグメント

•

データの移動方法

–

第41回 [Oracle Database 12c] オンラインでのパーティション移動

–

第47回 [Oracle Database 12c] オンライン・データファイルの移動

第45回 Recovery ManagerのSWITCHコマンドでリストア時間ゼロ