Oracle Database Technology Night #40 後半 Oracle Automatic Storage Management 日本オラクル株式会社 日下部明 2020/11/19

Safe harbor statement 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明するものです。また、情報提供を唯一の目的とする ものであり、いかなる契約にも組み込むことはできません。以下の事項は、マテリアルやコード、機能を提供することを確約 するものではないため、購買決定を行う際の判断材料になさらないで下さい。 オラクル製品に関して記載されている機能の開発、リリース、時期及び価格については、弊社の裁量により決定され、変 更される可能性があります。 Copyright © 2020, Oracle and/or its affiliates 2

Oracle Automatic Storage Management

デバイス・ ファイル Oracle Database専用のクラスタ・ボリューム・マネージャ兼クラスタ・ファイルシステム Oracle Automatic Storage Management Copyright © 2020, Oracle and/or its affiliates 4 ファイル構造 Oracle構造 POSIXファイルシステム ボリューム・マネージャ ファイルシステム 表、索引 表領域 ファイル ASM ASM 表、索引 表領域 ボリューム・マネージャ ファイルシステム ファイル 管理者から見た操作の階層はどちらもディレクトリ・ツリーとファイルで同じ RAIDとは異なる実装で • ストレージ・デバイスの障害に対処可能 • データ破損を検出すると自動修復

Oracleインスタンスからはディレクトリ・ツリーとファイルの構造が見える SQL> select name from v$datafile order by name desc; NAME ----------------------------------------------- +DATA/RAC19A/DATAFILE/users.305.1054225731 +DATA/RAC19A/DATAFILE/undotbs3.304.1054225721 +DATA/RAC19A/DATAFILE/undotbs2.303.1054225711 +DATA/RAC19A/DATAFILE/undotbs1.299.1054225675 +DATA/RAC19A/DATAFILE/system.295.1054225589 +DATA/RAC19A/DATAFILE/sysaux.297.1054225639 : ASMはクラスタ・ボリューム・マネージャ兼クラスタ・ファイルシステム Copyright © 2020, Oracle and/or its affiliates 5 ＋DATA RAC19A DATAFILE users..... undotbs..... ....

OS付属のファイルシステム操作コマンド群(cd, lsなど)ではASMにはアクセスできない。 ファイルシステム操作コマンドに似せてつくられたasmcmdで操作可能。 ASMはOracle Database専用のファイルシステム Copyright © 2020, Oracle and/or its affiliates 6 $ asmcmd ASMCMD> cd DATA ASMCMD> ls ASM/ RAC19A/ _MGMTDB/ orapwasm orapwasm_backup ptvm30-cluster/ なざわざわざファイルシステムを再設計したのか

ファイルシステム

性能面で問題を抱えていた(21世紀のファイルシステムでは実装済み) 。 • ジャーナリング • エクステント • サイズ制限 • 非同期I/O • ダイレクトI/O これらの問題を回避するためにOracle Databaseはファイルシステムを使わずrawデバイス構成を取る場合があった。 • Oracle Databaseのデータベース・ファイルは固定長で構成可能 商用Unixマシンの最大の用途はデータベース・サーバー • マルチ・プロセッサ(1コア/ソケットのマルチ・ソケット・マシン) • 早期の64bit化(2GB or 4GBを超えるアドレッシング) • 論理ボリューム・マネージャ(LVM)ソフトウェアの発達 20世紀のファイルシステム事情 Copyright © 2020, Oracle and/or its affiliates 8

rawデバイスとはキャラクタ・デバイス・ファイルのこと rawデバイス構成とは、データベースを構成するファイルをキャラクタ・デバイス・ファイルで構成すること • 1パーティションをあらわすデバイス・ファイルを1つのファイルとみなす • ディスク・パーティションはサイズ指定した多くのパーティション作成が難しいので商用Unixでは論理ボリューム・マ ネージャ(Logical Volume Manager: LVM)が早くから発達した Oracle Databaseのデータベースを構成するファイルは固定長で構成可能 • 制御ファイル • オンラインREDOログ・ファイル • データファイル rawデバイス Copyright © 2020, Oracle and/or its affiliates 9 character device block device filesystem アクセス粒度 バッファリング ブロック・デバイス(cookedデバイス) ブロック あり キャラクタ・デバイス(rawデバイス) 1 byte なし ファイルシステムはブロック・デバイスの上に作成する 階 層

OSによって事情が異なる Solarisなどの商用Unix ストレージを認識するとキャラクタ・デバイス・ファイルとブロック・デバイス・ファイルの両方が生成される。 /dev/rdsk/c3t19d7s4 キャラクタ・デバイス・ファイル /dev/dsk/c3t19d7s4 ブロック・デバイス・ファイル Linux ストレージを認識してもブロック・デバイス・ファイルしか作成されない。 /dev/sdc1 rawデバイスは管理者がブロック・デバイス・ファイルと対応付けて作成しなければならない。 /dev/raw/raw1 Linux 2.6でrawデバイスは非推奨となり、その代わりにブロック・デバイス・ファイルをダイレクトI/O(バッファリングなし)すると いう代替策が提示された。 Oracle Database 10g Release 2でそれに対応した。 rawデバイス・ファイル Copyright © 2020, Oracle and/or its affiliates 10

性能面で問題を抱えていた(21世紀のファイルシステムでは実装済み) 。 • ジャーナリング • エクステント • サイズ制限 • 非同期I/O • ダイレクトI/O 20世紀のファイルシステム事情 Copyright © 2020, Oracle and/or its affiliates 11

ファイルの管理情報ブロック(i node)からデータ本体のブ ロックへポインタがある。 新規ファイル作成やファイル・サイズ拡張などのファイルシス テムの構造変化を伴う処理の途中でOSクラッシュが発生 すると、無効なポインタやブロックが発生する。 ファイルシステムのマウント時にファイルシステムの検査 (fsck)を行って、ポインタとブロックの関係を修復する必要 がある。 ジャーナリングがないと、ファイルシステムの全i nodeと全ブ ロックの対応関係を検査する必要が出る。 ファイルシステムの構造とファイルシステム検査 Copyright © 2020, Oracle and/or its affiliates 12 i node ブロック ファイル・サイズ拡張などの ファイルシステムの変化を伴う処理 i node ブロック 無効なポインタやブロックが 発生する 途中で OSクラッシュ

ファイルシステム構造の変更をトランザクションにする ファイルの管理情報ブロック(i node)からデータ本体のブ ロックへポインタがある。 ファイルシステムの構造変化を記録するジャーナル領域 (OracleでいうところのREDOログ)があり、構造変化操作 は「トランザクション」として記録される。 OSクラッシュ後の再マウント時のファイルシステム検査 (fsck)はジャーナル領域に記録されている未完了操作だ け処理すればよい。 ジャーナリング Copyright © 2020, Oracle and/or its affiliates 13 i node ブロック ファイル・サイズ拡張などの ファイルシステムの変化を伴う処理 ジャーナル領域

フェイルオーバー時にファイルシステムの再マウントが発生する アクティブ・スタンバイ型クラスタ Copyright © 2020, Oracle and/or its affiliates 14 共有ストレージ ノード1 ノード2 OS Cluster filesystem DBMS OS Cluster filesystem DBMS ノード2でファイルシステムをマウントするとき、ノード1でクリーン にアンマウントされていなかったのでファイルシステム検査 (fsck)が必要になる。 ジャーナリングがないと数十分以上かかることもあった。 (2) ファイルシステムのマウント (3) DBMS起動 (1) DBMSが稼働していたノード1で障害発生 (4) リカバリ処理 filesystem

物理デバイス上である程度連続した領域を確保する ファイルシステムはファイルを「ブロック」に分割している • i nodeブロックからブロックへのポインタがある。 • ある程度連続した領域(エクステント)を確保し、ブロッ クを連続配置する。 • シーケンシャル・アクセスでスループットを上げる効果が ある。 Oracle Databaseの構造にもエクステントがある • 1つのセグメントは複数のエクステントで構成されている。 • 1つのオブジェクトのデータ・ブロックは物理デバイス上で ある程度連続配置されている。 エクステント Copyright © 2020, Oracle and/or its affiliates 15 エクステント ブロック Hard disk

32bitアドレッシングの上限は2^32=4GB 32bitアーキテクチャのファイルシステムの1ファイルの最大サ イズ制限が小さい場合があった(2GBなど) 表領域(TABLESPACE)という抽象階層を導入 複数のファイルで1つの表領域を構成可能 Oracle Databaseの表領域サイズ制限 スモール・ファイル表領域 1ファイルあたりデータ・ブロック4M個 データ・ブロック・サイズが8KBの場合 8KB×4M=32GB 1表領域のファイル数は1K本 32GB×1K=32TB ファイル・サイズ制限 Copyright © 2020, Oracle and/or its affiliates 16 表領域 (TABLESPACE) データファイル (データ・ブロックの集合) ストレージの抽象化 表や索引の格納場所の 指定は表領域 CREATE TABLE ... TABLESPACE ... ;

I/Oを複数発行する場合のスループットを上げることが可能に 同期I/O I/Oを発行すると書き込み完了まで返ってこない 非同期I/O 複数のI/Oを発行し、後で完了通知を確認する 非同期I/O (Asynchronous I/O) Copyright © 2020, Oracle and/or its affiliates 17 Oracleプロセス OS Oracleプロセス OS

Copyright © 2020, Oracle and/or its affiliates 18 OracleインスタンスのSystem Global Area (SGA)自体が巨大なライト・バッファになっている Oracle Databaseアーキテクチャ REDOログ・バッファ オンラインREDOログ・ファイル LGWR oracle oracle Oracleサーバー・プロセス ログ・ライター・プロセス データベース・バッファ・キャッシュ DBWn データベース・ライター・プロセス データファイル SGA oracle Oracleサーバー・プロセス によるSQL処理はメモリを 更新 バックグラウンド・プロセスが ファイルに永続化 OS

どちらも同じDRAM上の領域 Oracle SGAとOSページ・キャッシュ Write時 Copyright © 2020, Oracle and/or its affiliates 19 Oracle SGA OSページ・キャッシュ oracle DRAM Oracleサーバー・プロセス LGWR 同じデータを同じDRAM上にキャッシュしてしまう オンラインREDOログ・ファイル

OSページ・キャッシュをバイパス ダイレクトI/O (Direct I/O) Write時 Copyright © 2020, Oracle and/or its affiliates 20 Oracle SGA OSページ・キャッシュ oracle DRAM Oracleサーバー・プロセス LGWR バックグラウンド・プロセスによるストレージへの永続化 は最短時間で行ってほしい オンラインREDOログ・ファイル

どちらも同じDRAM上の領域 Oracle SGAとOSページ・キャッシュ Read時 Copyright © 2020, Oracle and/or its affiliates 21 Oracle SGA OSページ・キャッシュ oracle DRAM Oracleサーバー・プロセス 同じデータを同じDRAM上にキャッシュしてしまう データファイル

OSページ・キャッシュをバイパス ダイレクトI/O (Direct I/O) Read時 Copyright © 2020, Oracle and/or its affiliates 22 Oracle SGA OSページ・キャッシュ oracle DRAM Oracleサーバー・プロセス OSページ・キャッシュに使われるはずだったメモリ容量をデー タベース・バッファ・キャッシュに振り分けてI/O回数を減らす ※「ダイレクトIOを設定しただけでデータベースが高速になる」ではない データファイル

ASM(rawデバイス)とファイルシステムで設定が異なる 2つの初期化パラメータで制御 DISK_ASYNC_IO • 非同期I/Oの制御 FILESYSTEMIO_OPTIONS • ファイルシステムでのI/O方法の制御 • ファイルシステムだとデフォルトではダイレクトI/Oも非同 期I/Oも無効 ダイレクトI/Oと非同期I/Oの設定 Copyright © 2020, Oracle and/or its affiliates 23 DISK_ASYNC_IO true (デフォルト) 非同期I/Oが有効 false 非同期I/Oが無効 FILESYSTEMIO_OPTIONS ダイレクトI/O 非同期I/O none (デフォルト) N N directio Y N asynch N Y setall Y Y

20世紀のファイルシステムが持っていなかった機能を実装した。 • ジャーナリング • エクステント • サイズ制限 • 非同期I/O • ダイレクトI/O 性能面でのrawデバイス構成のメリットが薄れていき、rawデバイス構成を取る理由がなくなっていった。 • root権限でLVMでのrawデバイス・ファイル作成 → DBMSでファイル名指定、は煩わしい。 • WindowsとLinuxのエンタープライズIT界での普及 • rawデバイスってなんですか？という人もかなりいる 21世紀のファイルシステム事情 Copyright © 2020, Oracle and/or its affiliates 24 ファイルシステムの性能課題は改善したが、データベースのストレージ運用についてはまだまだ課題が残っていた

データベースのストレージ運用

データベースの格納データは増えていく 表領域のサイズを拡大したい ファイルシステムやrawデバイスでのデータベース運用 (ASM以前のスモール・ファイル表領域での運用) 1. ストレージ・デバイスをOSに認識させる 2. (root権限で論理ボリュームを切り出す) 3. ALTER TABLESPACE ... ADD で追加 データベースのストレージ運用 Copyright © 2020, Oracle and/or its affiliates 26 表領域 (TABLESPACE) データファイル (データ・ブロックの集合) 表や索引の格納場所の 指定は表領域 ストレージの抽象化 表領域にデータファイル追加 CREATE TABLE ... TABLESPACE ... ;

表領域の作成 ASM以前のデータベースのストレージ運用 Copyright © 2020, Oracle and/or its affiliates 27 表領域 (TABLESPACE) データファイル ストレージの抽象化 (1) ストレージ・アレイ側で作成した複数ストレー ジ・デバイスを束ねた物理ボリューム(RAIDグ ループ等の名称) (2) 物理ボリュームからLVMで切り出した論理ボ リューム・ファイル(rawデバイス)またはファイル システム用のディスク・パーティション Volume 1 Volume m

データベースの格納データは増えていく ASM以前のデータベースのストレージ運用 Copyright © 2020, Oracle and/or its affiliates 28 Volume 1 Volume m 表領域 (TABLESPACE) データファイル ストレージの抽象化 Volume n Volume z (3) ストレージ・デバイスを増設して物理ボリューム追加 (4) 論理ボリュームからデータ ファイルを表領域に追加

新しく格納されたデータへのアクセスが集中する傾向がある データのアクセス頻度の傾向 Copyright © 2020, Oracle and/or its affiliates 29 ストレージ・デバイスを増設してボリュームを追加し ていくと、最近のデータを格納しているストレージ・ デバイスへのアクセスが偏る 時間 アクセス頻度 Volume 1 Volume 2 Volume 3 Volume n ハード・ディスク・ドライブ1台の性能はかなり低い • small I/O 100 IOPS • large I/O 100MB/s

1. ストレージを追加して表領域にデータファイルを追加し ていくと、新しいストレージにアクセスが集中する 2. データをいったんエクスポート(論理バックアップ)してスト レージを空にしてボリューム再構成 この間データにはアクセスできない 3. データをロードしなおすと各ストレージ・デバイスへのア クセスが均等になる 人力リバランス運用は実質的に無理 Copyright © 2020, Oracle and/or its affiliates 30

Automatic Storage Management (ASM)

rawデバイスの性能 + ファイルシステムの管理容易性 + データベースでのストレージ運用 1999年 • ASMの計画が承認されスタートした。 • まだOracle8iのころ。 2001年 • Oracle9i Release 1 • RACを実装 • rawデバイス構成 2003年 • Oracle Database 10g Release 1 • Oracle ClusterwareとASMを実装 2008年 • Oracle Exadata Database Machine • ストレージがOracle Databaseの処理をアシスト • Oracle Database 11g Release 1 2009年 • Oracle Database 11g Release 2 • Oracle ClusterwareとASMが統合されてOracle Grid Infrastructureに データベースのストレージ運用を改善したい Copyright © 2020, Oracle and/or its affiliates 32

rawデバイスの性能 + ファイルシステムの管理容易性 + データベースでのストレージ運用 21世紀のファイルシステムが持つ機能を実装 • ジャーナリング • エクステント • サイズ制限 • 非同期I/O • ダイレクトI/O データベースでのストレージ運用を改善したい • 増え続けるデータを前提にしたストレージ性能最大化 • 障害対策 ASM Copyright © 2020, Oracle and/or its affiliates 33

どのファイルへのアクセスもストレージの性能を最大限引き出す ファイルを分割し、すべてのストレージ・デバイスに均等に分散する。 ストレージ・デバイスが増減しても、再配置して均等を維持する。 ASMのファイル配置コンセプト1 Copyright © 2020, Oracle and/or its affiliates 34 ASM上のファイル extent extent extent ASMエクステント

どのファイルも冗長化して障害に対処する ファイルを分割しミラーを用意する。 ミラーは異なる障害グループ(FAILGROUP)のストレージ・デバイスに配置する。 ストレージ・デバイスが増減しても、再配置して冗長構成を維持する。 ASMのファイル配置コンセプト2 Copyright © 2020, Oracle and/or its affiliates 35 ASM上のファイル extent extent extent FAILGROUP 1 FAILGROUP 2 FAILGROUP 3 FAILGROUP n プライマリ・エクステント セカンダリ・エクステント セカンダリ・エクステント FAILGROUP ≒ 1つのストレージ筐体 ASMエクステント

Stripe And Mirror Everything (S.A.M.E.) ファイルを分割し、 • すべてのストレージ・デバイスに均等に分散する ⇒Stripe • ミラーは異なる障害グループ(FAILGROUP)のストレージ・デバイスに配置する ⇒Mirror そしてストレージ・デバイスが増減してもリバランスすることでStripeとMirrorを維持する ASMのファイル配置コンセプト Copyright © 2020, Oracle and/or its affiliates 36 1 2 3 4 3 6 1 7 5 6 7 8 4 2 8 5 異なるデバイスに ミラーリング すべてのデバイスにストライピング プライマリ・エクステント ASM上のファイル extent extent extent セカンダリ・エクステント ASMエクステント

ストレージ・デバイスが増減してもStripe And Mirror Everything (S.A.M.E.)を維持する ストレージ・デバイスが故障して使用できなくなったらASMディスク・グループから削除 ⇒エクステントを失うので既存ストレージ・デバイスにエクステントを追加して冗長性(2重化および3重化)を回復 ASMディスク・グループにストレージ・デバイスを追加 ⇒既存ストレージ・デバイスのエクステントを追加ストレージ・デバイスに移し替えてストライプ性能向上 リバランスはオンラインで行われる 動的リバランス Copyright © 2020, Oracle and/or its affiliates 37 異なるデバイスに ミラーリング すべてのデバイスにストライピング 削除 追加

Copyright © 2020, Oracle and/or its affiliates 38 ASMファイルの破損が検出されるとセカンダリ・エクステントから読み取って処理継続および自動修復 ファイルの破損検出と自動修復 oracle Oracleサーバー・プロセス SGA 1. プライマリ・エクステントの 破損を検出した 2. セカンダリ・エクステントから読 み取りエラーを返さず処理継続 1 2 3 3 1 1 プライマリ・ エクステント セカンダリ・ エクステント 3. 正常エクステントのデータで 破損個所を修復 ASMディスク・グループ

エクステントの概念で物理ストレージ上にある程度連続配置 ASMアロケーション・ユニット(Allocation Unit: AU)がASMディスク上で割り当てられる最小単位。 ASMディスク・グループ作成時に指定する(デフォルト4MB) ASMエクステントはASMアロケーション・ユニットの集合。 1エクステントに含まれるAUの個数は最初は1でファイル・サイズが大きくなると増えていく。 ASMエクステントとアロケーション・ユニット Copyright © 2020, Oracle and/or its affiliates 39 ASM上のファイル extent extent ASMエクステント AU extent AU AU AU AU AU AU AU AU AU 1 2 3 3 1 1 異なるデバイスに ミラーリング すべてのデバイスにストライピング 8 5

ストレージ・デバイス(デバイス・ファイル)の集合を定義する Oracle Grid Infrastructure 19cのインストーラ 1つ目のASMディスク・グループを作成する画面 冗長性 - ASM AUのミラーを持つか • 高(HIGH) 3重化(推奨) • 標準(NORMAL) 2重化 割り当て単位サイズ - ASM Allocation Unitのサイズ • デフォルトは4MB 1つのASMディスクは1つのデバイス・ファイル • どの障害グループに属するか ASMディスク・グループの作成 Copyright © 2020, Oracle and/or its affiliates 40 FAILGROUP 1 FAILGROUP 2 ASMディスク・グループ AU

Exadata Database Machine ASMのコンセプトを正しく実装 Copyright © 2020, Oracle and/or its affiliates 41 Storage 1 Storage 2 Storage 3 Database Server 1 Database Server 2 Flash Memory x4 HDD x12 FAILGROUP switch switch Storage n Database Server n ストレージ筐体は2RUサイズのIntel Xeonサーバー • HDD 12台 → ASMディスク12本に見える • Flash Memory 4枚(キャッシュ) • Persistent Memory 12枚(キャッシュ, X8M~) 1つのストレージ筐体が1つのASM障害グループ • ミラーは異なるストレージ筐体に格納される • ストレージ筐体ごと停止してもシステム継続 ネットワーク総帯域の増加 RACでスケール・アウト ASMでスケール・アウト

1台のストレージ筐体に12台のHDD SQL> select group_number,disk_number,failgroup,name from v$asm_disk order by group_number,disk_number; GROUP_NUMBER DISK_NUMBER FAILGROUP NAME ------------ ----------- -------------- ---------------------------- 1 0 FUJICEL01 DATAC1_CD_00_FUJICEL01 1 1 FUJICEL01 DATAC1_CD_01_FUJICEL01 1 2 FUJICEL01 DATAC1_CD_02_FUJICEL01 1 3 FUJICEL01 DATAC1_CD_03_FUJICEL01 1 4 FUJICEL01 DATAC1_CD_04_FUJICEL01 1 5 FUJICEL01 DATAC1_CD_05_FUJICEL01 1 6 FUJICEL01 DATAC1_CD_06_FUJICEL01 1 7 FUJICEL01 DATAC1_CD_07_FUJICEL01 1 8 FUJICEL01 DATAC1_CD_08_FUJICEL01 1 9 FUJICEL01 DATAC1_CD_09_FUJICEL01 1 10 FUJICEL01 DATAC1_CD_10_FUJICEL01 1 11 FUJICEL01 DATAC1_CD_11_FUJICEL01 1 12 FUJICEL02 DATAC1_CD_00_FUJICEL02 1 13 FUJICEL02 DATAC1_CD_01_FUJICEL02 : : : : ExadataのASMディスク構成 Copyright © 2020, Oracle and/or its affiliates 42 1つのFAILGROUPに12個のストレージ・デバイス • 1ストレージ筐体あたりHDDが12台だから • RAIDを使わずにASMで冗長化している FAILGROUP: FUJICEL01

デバイス・ ファイル Oracle Database専用のクラスタ・ボリューム・マネージャ兼クラスタ・ファイルシステム Oracle Automatic Storage Management Copyright © 2020, Oracle and/or its affiliates 43 ファイル構造 Oracle構造 POSIXファイルシステム ボリューム・マネージャ ファイルシステム 表、索引 表領域 ファイル ASM ASM 表、索引 表領域 ボリューム・マネージャ ファイルシステム ファイル 管理者から見た操作の階層はどちらもディレクトリ・ツリーとファイルで同じ ただし、実装はかなり異なる

デバイス・ ファイル 役割はアドレス変換 ファイルシステムとボリューム・マネージャ Copyright © 2020, Oracle and/or its affiliates 44 ファイル構造 Oracle構造 ボリューム・マネージャ ファイルシステム 表、索引 表領域 ファイル oracle ユーザー空間プロセス ファイル上のアドレスを指定して read/write ストレージ・デバイス ファイルシステムのファイル LVMのデバイス・ファイル ユーザー空間プロセスが指定したファイル上のアドレスを ストレージ・デバイスのアドレスに変換 ファイルシステムでの管理者から見た概念 ファイルシステムの実装 ディレクトリ・ツリーとファイル ファイルのアドレスをストレージのアドレスに変換

OSデバイス・ファイル OracleインスタンスがASMインスタンスにI/Oリクエストを発行する、のではない ASMの誤ったアーキテクチャ概念 Copyright © 2020, Oracle and/or its affiliates 45 デバイス・ ファイル ファイル構造 Oracle構造 ASM 表、索引 表領域 ボリューム・マネージャ ファイルシステム ファイル Oracleインスタンス ASMインスタンス アドレス変換マップ ASMでの管理者から見た概念 ASMの誤った実装概念 ディレクトリ・ツリーとファイル POSIXファイルシステムの場合と同じ こうではない

OSデバイス・ファイル Oracleインスタンスがデバイス・ファイルに直接I/Oリクエストを発行 ASMアーキテクチャ Copyright © 2020, Oracle and/or its affiliates 46 デバイス・ ファイル ファイル構造 Oracle構造 ASM 表、索引 表領域 ボリューム・マネージャ ファイルシステム ファイル Oracle インスタンス ASM インスタンス アドレス変換 マップ アドレス変換 マップ 1. ASMインスタンスはASM ファイルとデバイス・ファイル の変換マップをメンテナンス 2. Oracleインスタンスはアド レス変換マップをキャッシュ 3. Oracleインスタンスのプロセスがデバイス・ ファイルに直接I/Oを発行 ASMでの管理者から見た概念 ASMの実装 ディレクトリ・ツリーとファイル POSIXファイルシステムの場合と同じ

Oracleインスタンスのプロセスがデバイス・ファイルに直接I/Oリクエストを発行 Oracleインスタンスはアドレス変換マップをSGAにキャッシュ Copyright © 2020, Oracle and/or its affiliates 47 oracle oracle 共有メモリ領域 (System Global Area) 変換 マップ 変換 マップ LGWR 変換 マップ DBWn 変換 マップ OSデバイス・ファイル ASM インスタンス アドレス変換 マップ Oracleインスタンス プロセス

Oracleプロセスが複数のデバイス・ファイルに非同期I/OかつダイレクトI/Oを並行に発行 非同期I/OかつダイレクトI/O Copyright © 2020, Oracle and/or its affiliates 48 LGWR 1 2 3 3 1 1 プライマリ・エクステント セカンダリ・エクステント 1. 非同期I/Oで複数ストレージ・ デバイスに並行でwrite発行 2. write完了確認 LGnn ログ・ライター・ プロセス セカンダリ・エクステント 3重化ASMディスク・グループ ⇒ 3つのデバイスにwriteが発生

ASMディスク・ヘッダーにジャーナル領域がある ASMのファイルシステムが構造変化する操作はジャーナル 領域に記録されトランザクションとして扱われる。 • 新規ファイル作成 • ファイル拡張 • リバランス • ... 処理中にASMインスタンスがクラッシュしてもジャーナル領 域に残っている処理だけ継続またはリカバリすればよい。 RAC構成では残りの正常ノードのASMインスタンスによる 速やかな継続またはリカバリ処理が可能。 ジャーナリング・ファイルシステム Copyright © 2020, Oracle and/or its affiliates 49 ジャーナル領域 ASMディスク ASM インスタンス ASM インスタンス Clusterware Clusterware ノード1 ノード2

Oracle Database 10g Release 1でASMとともにビッグ・ファイル表領域を導入 スモール・ファイル表領域 1ファイルあたり最大データ・ブロック数は4M個 1表領域の最大ファイル数は1K本 データ・ブロック・サイズが8KBの場合 1ファイルの最大サイズ 8KB×4M個=32GB 1表領域の最大サイズ 32GB×1K本=32TB Oracle Databaseのデータベース全体でのデータファイル 本数合計の上限は65533 ビッグ・ファイル表領域(ASM導入と同時の10g~) 1ファイルあたり最大データ・ブロック数は4G個 1表領域の最大ファイル数は1本 データ・ブロック・サイズが8KBの場合 1ファイルの最大サイズ 8KB×4G個=32TB 1表領域の最大サイズ 32TB×1本=32TB ASMは巨大なストレージ・プールが構成可能、かつエクス テントのミラーの自動修復ができることを前提に巨大なファ イルで表領域を構成できるようにした。 ファイルサイズ制限 Copyright © 2020, Oracle and/or its affiliates 50 1表領域あたりの最大データブロック数はどちらも4G個

Oracle Grid Infrastructure Oracle Grid Infrastructure Oracle Clusterware + Oracle Automatic Storage Management Oracle Automatic Storage Management(ASM)は Oracle Database専用のクラスタ・ボリューム・マネージャ 兼クラスタ・ファイルシステムの階層で、これの管理を行う ASMインスタンスはOracleインスタンスを改造して作られ た。 Oracle Database 11g Release 1までは、Oracle DatabaseのORACLE_HOMEからASMインスタンスを構 成していた。 Oracle Database 11g Release 2でOracle ClusterwareとASMが1つにパッケージングされOracle Grid Infrastructureとなった。 Oracleリスナー(tnslsnr)もOracle Grid Infrastructure に移された。 51 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted ASM Clusterware Oracle Database Oracle Oracle Clusterware Clusterware Oracle Database Oracle ASM 11g Release 1まで 11g Release 2以降 tnslsnr tnslsnr tnslsnr

Oracle Grid Infrastructure Oracle Clusterware + Oracle Automatic Storage Management インストールするソフトウェアの名前はOracle Grid Infrastructure 機能階層としてはOracle ClusterwareとOracle Automatic Storage Management Oracle Database 19cのマニュアル https://docs.oracle.com/cd/F19136_01/books.html • Grid Infrastructureインストレーションおよびアップグレード・ガイド for platform • Clusterware管理およびデプロイメント・ガイド • Automatic Storage Management管理者ガイド 52 Copyright © 2020, Oracle and/or its affiliates | Confidential: Internal/Restricted/Highly Restricted Oracle Grid Infrastructure ASM Clusterware tnslsnr

プロセスから見たレイテンシー 一般的なストレージのI/Oレイテンシー Copyright © 2020, Oracle and/or its affiliates 53 LGWR ログ・ライター・プロセス NVMe Flash Memory proc HBA HBA ストレージ処理プロセス NVMe Flash Memory 同一サーバー内のNVMe Flash Memoryでは約100μ秒 ネットワーク接続ストレージの NVMe Flash Memoryでは約 200μ秒

Persistent MemoryへのRDMAアクセス Exadata X8MのI/Oレイテンシー Copyright © 2020, Oracle and/or its affiliates 54 ログ・ライター・プロセス proc ストレージ処理プロセス NVMe Flash Memory Persistent Memory Persistent MemoryへのRDMA では約20μ秒 HBA HBA LGWR ストレージ処理プロセスのコンテ キスト・スイッチが発生しない ネットワーク接続ストレージの NVMe Flash Memoryでは約 200μ秒

ストレージにPersistent Memory (PMEM)を追加 データベース・サーバーからストレージ・サーバーのPMEMにRemote Direct Memory Accessする 低レイテンシー・デバイス+ストレージ側ソフトウェアのコンテキスト・スイッチ削減 Oracle Database 19c以降で以下の用途がPMEM+RDMAの低レイテンシー・アクセスが可能 • データ・ブロックのキャッシュ読み取り • オンラインREDOログ・ファイルの書き込み Exadata X8M Copyright © 2020, Oracle and/or its affiliates 55 ※ストレージ・サーバーは最低3台から デバイス High Capacity Model Extreme Flash Model PMEM 128GB×12=1.5TB 128GB×12=1.5TB Flash Memory 6.4TB×4=25.6TB 6.4TB×8=51.2TB Hard Disk 14TB×12=168TB - ストレージ・サーバー1台あたりのストレージ・デバイス

Oracleプロセスが複数のデバイス・ファイルに非同期I/OかつダイレクトI/Oを並行に発行 ASM多重化書き込み Copyright © 2020, Oracle and/or its affiliates 56 oracle LGWR 1 2 3 3 1 1 プライマリ・エクステント セカンダリ・エクステント 1. COMMIT発行 BG待機イベント log file parallel write 5. CPUスケジューリング待ち FG待機イベント log file sync 6. COMMIT完了 2. 非同期I/Oで複数ストレージ・ デバイスに並行でwrite発行 3. write完了確認 4. write完了通知 LGnn Oracleサーバー・ プロセス ログ・ライター・ プロセス セカンダリ・エクステント

ASM3重化(ストレージ・サーバー3台へのWrite 3か所)でのプロセスから見たレイテンシー PMEM無効 (Flash Memoryへのアクセス) PMEM有効 (PMEMへのRDMAアクセス + Flash Memoryからの読み取り) Exadata X8MでのOLTP処理例 Copyright © 2020, Oracle and/or its affiliates 57 待機イベント 1回あたりの平均時間 処理スループット log file parallel write LGWRの書き込み完了待ち 469.90μ秒 11,394 Commit/s cell single block physical read 1データ・ブロックの読み取り 459.98μ秒 49,848 Physical Read Blocks/s 54,102 Physical Write Blocks/s 待機イベント 1回あたりの平均時間 処理スループット log file parallel write LGWRの書き込み完了待ち 53.49μ秒 12,647 Commit/s cell single block physical read 1データ・ブロックの読み取り 60.47μ秒 (PMEM + Flashの平均値) 54,550 Physical Read Blocks/s 64,732 Physical Write Blocks/s 10k Commit/s, 100k Blocks/sの高IO負荷でも待機時間が約1/8に減る

rawデバイスの性能 + ファイルシステムの管理容易性 + データベースでのストレージ運用 21世紀のファイルシステムが持つ機能を実装 • ジャーナリング • エクステント • サイズ制限 • 非同期I/O • ダイレクトI/O データベースでのストレージ運用を改善したい • 増え続けるデータを前提にしたストレージ性能最大化 • 障害対策 ASM Copyright © 2020, Oracle and/or its affiliates 58 Stripe And Mirror Everything + 動的リバランス 筐体を区別したミラー + ファイル破損の自動修復

ファイル破損を検出できるからその対処機能を実装可能 ファイル破損検出 • データ・ブロックの検査設定 • オンラインREDOログ・ファイルと制御ファイル • チェックサム • ファイル多重化 データベースの過去の状態にアクセスしたい • Flashback 検出したファイル破損に対処する機能群 • Recovery Manager (RMAN) • バックアップおよびリストア・リカバリ • ファイル破損を検査しながらコピー • Data Guard • ブロック構造まで同じになるレプリケーション • 受信したREDOログを検査 • Active Data Guard • 自動ブロック・メディア・リカバリ • Automatic Storage Management (ASM) • ファイル破損の自動修復 Oracle Databaseのデータ・プロテクション Copyright © 2020, Oracle and/or its affiliates 59

Thank you Copyright © 2020, Oracle and/or its affiliates 60

No content

Our mission is to help people see data in new ways, discover insights, unlock endless possibilities.