Null

Size: px

Start display at page:

Download "Null"

よしおこうだ
5 years ago
Views:

1 Oracle Database Technology Night ~ 集え! オラクルの力 ( チカラ ) ~ 高可用性と高拡張性を両立する Oracle RAC ~ 改めて基礎からシンプルに理解する ~ 日本オラクル株式会社クラウドテクノロジー事業統括 Cloud Platform ソリューション本部 Database ソリューション部佐々木亨 Copyright 2017, Oracle and/or its affiliates. All rights reserved.

2 以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリースおよび時期については弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社関連会社の米国及びその他の国における登録商標です文中の社名商品名等は各社の商標または登録商標である場合があります

3 お伝えしたい内容 RAC を利用することで高可用性と拡張性が得られる RAC もシングルインスタンスも基本的な考え方は同じ 3

Oracle Real Application Clusters (RAC) とは複数ノードで構成する共有ディスク / 共有キャッシュ型のデータベース全ノードが全データに直接アクセス可能 Cache Fusion Technologyでキャッシュデータの一貫性を維持主な特徴可用性

4 Oracle Real Application Clusters (RAC) とは複数ノードで構成する共有ディスク / 共有キャッシュ型のデータベース全ノードが全データに直接アクセス可能 Cache Fusion Technologyでキャッシュデータの一貫性を維持主な特徴可用性サーバー障害時にも残りのサーバーで業務を継続可能拡張性負荷の増減に応じた処理性能の最適化が可能投資コストリソースの有効活用により最適な投資コストを実現サーバー障害時にも残りのサーバーで業務継続可能 Active Active Active 全サーバーが Active( 稼働 ) となりリソースを有効活用処理量の増加に合わせて拡張可能 4

5 RAC に必要な H/W & S/W 構成パブリックネットワーククライアントとの通信を行うネットワーク Oracle Database インターコネクトネットワークノード間通信を行うネットワーク Database ノード RAC を構成するデータベースサーバー Oracle Automatic Storage Management Oracle Clusterware 共有ストレージ Grid Infrastructure データベースファイルを配置する全ノードからアクセス可能なストレージ 5

6 拡張性 6

7 RAC による高拡張性の実現サーバー追加によるスケーラビリティの向上必要に応じてサーバを追加し処理能力の拡張が可能必要に応じて追加稼働サーバー待機サーバー処理能力の増減に応じて H/W をリプレイス HA 構成入れかえ RAC 買いたし 7

8 サーバー追加で処理能力は本当に向上するのか? Oracle GRID Center での検証結果の例 ( 検索処理中心更新含むトランザクション 10%) 1=>16 ノードで倍シングルインスタンスにおけるチューニングと同じ考え方に基づきチューニングを実施することでリニアにスケールした 8

9 RAC のデータアクセスシングルインスタンスと同じように低速なディスクアクセスを減らすという考え方で動作キャッシュヒットした場合キャッシュのデータを使用 SQL 発行キャッシュミスした場合シングルインスタンスの場合ディスクから読み込む RAC の場合 ( 存在すれば ) 他ノードのキャッシュから受け取るディスクから読み込む SGA Buffer Cache Server Process SGA Buffer Cache 9

Cache Fusion の動作ディスクから読み込み他ノードから受け取る SQL 発行該当ブロックの Resource Master Instance 1 GRD SQL 発行該当ブロックの Resource Master Instance 1 GRD 1. request Buffer Cache 1. request Buffer Cache 2. ping Server 2.

10 Cache Fusion の動作ディスクから読み込み他ノードから受け取る SQL 発行該当ブロックの Resource Master Instance 1 GRD SQL 発行該当ブロックの Resource Master Instance 1 GRD 1. request Buffer Cache 1. request Buffer Cache 2. ping Server 2. grant Process Instance 2 Process Instance 2 Holder Instance 3 GRD GRD GRD Server 4. assume Buffer Cache Buffer Cache Requester Buffer Cache 3. read Requester 3. transfer DBブロックAを必要とするインスタンス (Requester) Aのリソースマスターであるインスタンス (Resource Master) Aの最新イメージを保持しているインスタンス (Holder) 10

11 RAC における考慮ポイントアプリケーションデータベース設計ノード追加によって増えた CPU にデータを供給する I/O 性能の向上は RAC ノード追加と併せて検討すべきアプリケーションやデータベース設計はチューニングにおいて考慮すべき点チューニングポイントの例 1. キャッシュヒット率を改善 2. ブロックへのアクセスを分散させる 3. 不要なノード間通信を発生させない上記はシングルインスタンスでも同様に重要なチューニングポイントシングルインスタンスのチューニングポイントはRACでも同じように通用する 11

12 1. キャッシュヒット率を改善 SQL が実行されるローカルノード上のメモリに必要なデータがあればそのデータブロックを利用メモリ ( 高速 ) へのアクセスで完結 Disk I/O( 低速 ) は起こらないローカルノード上のはひとまず置いておいてまずはデータベース全体でのキャッシュヒット率改善を目指す OLTP システムにおける Full Scan を避ける Buffer Cache を適切なサイズにする Oracle Database のデータ圧縮機能を使う SGA Buffer Cache SQL 発行 Server Process SGA Buffer Cache 上記のチューニングはシングルインスタンスと同じ便宜上 2Node 構成の図を使います 12

2. ブロックへのアクセスを分散させる同一索引ブロックへのアクセスが集中する悪い例 Right Growing Index シーケンスから取得した単調増加する一意の値を INSERT する処理 ( 例 : 注文番号を INSERT) プライマリキーの索引の特定のリーフブロックに更新が集中する状況同時実行数が増えれば RAC に限らず発生する良くない状況 SQL> create table

13 2. ブロックへのアクセスを分散させる同一索引ブロックへのアクセスが集中する悪い例 Right Growing Index シーケンスから取得した単調増加する一意の値を INSERT する処理 ( 例 : 注文番号を INSERT) プライマリキーの索引の特定のリーフブロックに更新が集中する状況同時実行数が増えれば RAC に限らず発生する良くない状況 SQL> create table orders ( orderid number, customerid number, orderdate date, : constraint orders_pk primary key (orderid) ) SQL> insert into orders values ( seq1.nextval,xxx,xxxxx,); SQL> commit; プライマリキーの索引 INSERT INSERT INSERT INSERT 13

14 2. ブロックへのアクセスを分散させる同一索引ブロックへのアクセスが集中する悪い例特定のリーフブロックのノード間の転送が頻発する他ノードのブロックの持つ転送を待つ部分が出てくる SQL> create sequence seq1 ; SQL> insert into orders values ( seq1.nextval,..); Buffer Cache Buffer Cache INSERT 12 INSERT 13 INSERT 14 INSERT 11 INSERT 15 INSERT 16 14

seq1 cache 1000 ; SQL> insert into orders values ( seq1.nextval,.

15 2. ブロックへのアクセスを分散させるシーケンスのキャッシュを増やすシーケンスのキャッシュを増やすことで各ノードからの INSERT 処理が別のリーフブロックに分散されるシーケンスから取得してキャッシュしている値 Buffer Cache SQL> create sequence seq1 cache 1000 ; SQL> insert into orders values ( seq1.nextval,..); Buffer Cache INSERT 12 INSERT 13 INSERT 14 INSERT 1012 INSERT 1013 INSERT

2. ブロックへのアクセスを分散させるパーティショニングプライマリキーの索引をパーティション化アクセス対象のリーフブロックを全体で分散可能シングルインスタンスにおいても有効なチューニング Buffer Cache SQL> create table orders (... ) partition by hash (orderid).

16 2. ブロックへのアクセスを分散させるパーティショニングプライマリキーの索引をパーティション化アクセス対象のリーフブロックを全体で分散可能シングルインスタンスにおいても有効なチューニング Buffer Cache SQL> create table orders (... ) partition by hash (orderid)... SQL> create index xxx local ハッシュパーティション化 Buffer Cache ハッシュ関数ハッシュ関数 INSERT 12 INSERT 13 INSERT 14 f(x) Partition1 Partition3 Partition2 Partition2 Partition3 Partition1 f(x) INSERT 11 INSERT 15 INSERT 16 16

17 2. ブロックへのアクセスを分散させる逆キー索引プライマリキーの索引を逆キー索引化 ( 逆ビット順に格納 ) 大小関係が変化し連続したキーでも異なるブロックに挿入され易くなるシングルインスタンスでも有効なチューニング索引を使った範囲検索ができなくなる点には注意 Buffer Cache SQL> create index pk_orders on orders (orderid) reverse; Buffer Cache 例 12 = (2 進 ) ( 逆 Bit 順 ) = 48 INSERT 12 INSERT 13 INSERT 14 INSERT 11 INSERT 15 INSERT 16 例 11 = (2 進 ) ( 逆 bit 順 ) =

2. ブロックへのアクセスを分散させるアプリケーションパーティショニング異なるノードから別のブロックにアクセスするようアプリケーションで制御 ( アプリケーションロジック的に可能な場合のみ ) レンジリストパーティションなどと組合せると効果的 Buffer Cache 東日本在住の人の処理西日本在住の人の処理 SQL> create table orders (.

18 2. ブロックへのアクセスを分散させるアプリケーションパーティショニング異なるノードから別のブロックにアクセスするようアプリケーションで制御 ( アプリケーションロジック的に可能な場合のみ ) レンジリストパーティションなどと組合せると効果的 Buffer Cache 東日本在住の人の処理西日本在住の人の処理 SQL> create table orders (... ) partition by list (region) partition order_west( 東京, 神奈川,.), order_east ( 大阪, 兵庫,.), Buffer Cache INSERT ( 東京,12) INSERT ( 千葉,13) INSERT ( 神奈川,14) INSERT ( 大阪,11) INSERT ( 京都,15) INSERT ( 兵庫,16) 18

19 3. 余分な処理を起こさない読み取り専用のデータは Read-Only 表領域に配置読み取り専用の表領域中のテーブルについては Disk からの読み取りは Global Cache Operation を伴わない余分な通信によるオーバーヘッドを抑えることができる Instance 1 GRD Buffer Cache 1. request 2. grant Instance 2 Instance 1 GRD GRD Buffer Cache Buffer Cache Instance 2 GRD Buffer Cache 3. read 1. read Read-Write 表領域 Read-Only 表領域 19

20 3. 余分な処理を起こさない Read-Mostly Locking 99% は Read 処理だけど 1% は Write 処理というオブジェクト (Read-Mostly) については Read-Only にはできない Read-Mostly であるオブジェクトについてはマスターに問い合わせることなく直接ディスクから読み出す Read-Only オブジェクトは自動で判断される Instance 1 GRD Buffer Cache Instance 2 GRD Buffer Cache 1. read マスターに問合せることなく直接ディスクから読む Read-Mostly オブジェクト 20

21 拡張性の検証ハードウェア構成内蔵 L2SW DB サーバ 16 台内蔵 L2SW 内蔵 L2SW 内蔵 L2SW FCSW スイッチ : Catalyst2960G DB サーバー (1 台あたり ) クライアント (1 台あたり ) 本体 : Express5800/B120a-d (N ) CPU: インテル Xeon プロセッサー X5550 4Core * 2 スレッド * 2CPU メモリ :48GB 本体 : ECOCENTER(NE ) CPU: 8Core メモリ :16GB DNS サーバストレージ本体 : istorage S4900 キャッシュメモリ : 100GB AP サーバ 16 台ストレージ :istorage S

22 検証に用いたアプリケーション Web ショッピングサイトを模したアプリケーション 1. ユーザーサインオン 2. 商品検索 3. 商品選択 SELECT... FROM account, profile, signon, bannerdata... SELECT... FROM category... SELECT... FROM product... SELECT... FROM item, product 在庫数チェック SELECT... FROM inventory 注文 ( SELECT ordernum.nextval FROM dual ) INSERT INTO orders... INSERT INTO orderstatus... INSERT INTO lineitem... UPDATE inventory... COMMIT TX1 ( 更新あり ) 更新処理 1. ユーザーサインオン 2. 商品検索 3. 商品選択 SELECT... FROM account, profile, signon, bannerdata... SELECT... FROM category... SELECT... FROM product... SELECT... FROM item, product 在庫数チェック SELECT... FROM inventory... TX2 ( 検索のみ ) TX1 と TX2 をそれぞれ 1 トランザクションとするアプリケーションパーティショニングは実施しない商品検索は平均 100 件程度がヒットする 22

23 チューニング内容使用したチューニングポイントの例キャッシュヒット率を改善ブロックへのアクセスを分散させるシーケンスのキャッシュパーティショニング逆キー索引余分な処理を起こさない読み取り専用のテーブルを Read-Only Read Mostly Lock 23

24 検証結果 Tx1:Tx2=1:9 Tx1:Tx2=5:5 1=>16 ノードで倍 1=>16 ノードで倍 24

25 可用性 25

26 RAC の高可用性サーバー障害時の継続稼働に必要な機能 1. 障害検知各サーバー内のプロセス死活監視クラスタ内メンバーの死活監視 2. 障害サーバー切り離しクラスタノードメンバーシップ管理 RAC リソース再構成インスタンスリカバリ 3. 生存サーバーへの接続サービス名を用いた RAC データベースへの接続接続時のフェイルオーバーと仮想 IP アドレス FAN イベントと FCF 26

27 RAC が障害検知のために実施している監視 2. インスタンスメンバーシップの監視 4. インスタンス内での相互監視 Database Instance Database Instance Database Instance ASM Instance ASM Instance ASM Instance 5.Oracle Clusterware によるリソースの監視 Oracle Clusterware Oracle Clusterware Oracle Clusterware 1. クラスタノードメンバーシップの監視 3.Oracle Clusterware 内での相互監視 27

28 RAC を構成するプロセス群 Oracle Clusterware と Oracle Database Oracle Database スタック Oracle Clusterware スタック RAC 関連プロセス (LMON, LMS, LMD, LCK, LMHB) CRS エージェント Oracle Clusterware プロセス (CSS/ CRSなど ) OHAS エージェント Oracle High Availability Services (OHAS) 28

29 クラスタノードのメンバーシップ管理 Cluster Synchronization Services (CSS) によるクラスタノードの異常検知各ノードの CSS がクラスタノード構成の一貫性に責任を持つ相互に生存監視を実施し異常ノードを切り離す異常ノードが勝手に協調せずに IO するのを防ぐ (IO Fencing) CSS は 2 種類のハートビートをして互いを監視するネットワークハートビート (1 秒毎 ) タイムアウト misscount=30 ディスクハートビート IP IP IP CSS CSS CSS Node#1 Node#2 Node#3 ネットワークとディスク双方に対してハートビートが一定時間途絶えた場合相手はノード停止したと判断可能投票ディスク 29

30 クラスタノードのメンバーシップ管理排除ノードの決定ノード間の通信にのみ問題がある場合それぞれのノードが協調せず動作してデータの一貫性を損なわないように対処するスプリットブレイン解決投票ディスクを介して生き残るサブクラスタを調停する自分から見えるノードを投票する所属するノード数が最も多いサブクラスタを残す所属するノード数が同一の場合はノード番号が最小のノードを含むサブクラスタを残す IP IP IP CSS CSS CSS Node#1 Node#2 Node#3 2,3 1 2,3 投票ディスク 30

31 クラスタノードのメンバーシップ管理排除ノードの決定 Server Weight-Based Node Eviction (12.2~) クラスタ内のノードに対する負荷を考慮して重みづけする具体的にはクラスタウェアの管理リソース ( データベースサービス ) にフラグ (css_crtical というリソース属性 ) を付ける同数のサブクラスタに分離された場合は次の基準で判断される重みづけの大きいノードを残す Public 障害の発生していないノードを残す右の例だと 12.1まで : Node#1 が残る ( 若番を残すポリシー ) 12.2から : Node#2 が残る ( 重みづけにより ) Node#1 Critical Node#2 31

32 クラスタノードのメンバーシップ管理排除ノードの停止排除ノードに対して停止命令を送る系統は 3 種類 A) ネットワークハートビート経由 B) ディスクハートビート経由 ( 投票ディスク中の KILL ブロック ) 命令を受けると ACK を返して自分で停止 OS 再起動 Grid Infrastructure の再起動 ( ~) 停止命令を出したマスターに ACK が返り次第クラスタメンバーの再構成を実施 IP IP IP CSS CSS CSS Node#1 Node#2 Node#3 投票ディスク 32

33 クラスタノードのメンバーシップ管理排除ノードの停止 C) IPMI ( 対応 H/W であれば使用可 11.2 ~) BMC(Baseboard Management Controller) を経由してサーバーを停止再起動 BMC は OS とは独立してサーバーを管理障害ノードの OS が異常ケースでも OS を介さないため確実にサーバーを停止可能 Oracle Oracle Oracle OS OS OS BMC BMC BMC IPMI による停止命令が完了するタイミングは H/W 依存 ( どの状態をサーバーの停止と捉えるか ) IPMI 経由での停止命令 BMC 用の LAN 33

34 インスタンスメンバーシップ管理 LMON によるハートビート各ノードの LMON がメンバーシップを監視インスタンスや回線障害の検知時にはメンバーシップ解決を行う 2 種類のハートビートを行っているネットワークハートビート cluster_interconnect で指定されたネットワーク ( からは通常 HAIP) 一定時間ハートビートがない場合はタイムアウトしメンバーシップの解決が行われるディスクハートビート ( 制御ファイル ) HAIP HAIP HAIP LMON LMON LMON Node#1 Node#2 Node#3 制御ファイル 34

35 インスタンスメンバーシップ管理排除インスタンスの決定 :IMR(Instance Membership Recovery) LMON のハートビートは通常 CSS によるハートビートと同一のネットワークを通して行われるその場合は CSS が先に障害を検知解決する通常ネットワーク障害で LMON のハートビートがタイムアウトするケースはないハートビートにより異常を検知した場合は制御ファイルを用いて生き残りインスタンスの解決を行う IMR(Instance Membership Recovery) HAIP HAIP HAIP LMON LMON LMON Node#1 Node#2 Node#3 制御ファイル 35

36 障害検知後の動作 DB 層の障害かサーバー層での障害かを分けて考えることが重要出力されるログも異なる (DB のアラートログかクラスタウェアのログか ) RAC データベースインスタンスの異常検知排除インスタンスの決定排除インスタンスの停止リソースの再構成インスタンスリカバリ Oracle Clusterware クラスタノードの異常検知排除ノードの決定排除ノードの停止クラスタノードの再構成一連の処理が自動で行われる時間 36

37 その他の監視ノード内での監視については本日のセミナーでは割愛最終的にはノード停止インスタンス再起動プロセス再起動などの対処が行われる対処後の動作は前頁の通り各監視内容については下記資料を参照ください Oracle DBA & Developer Days 2012 Oracle Real Application Clusters/ Oracle Clusterware の高可用性機能 37

38 データブロックの自動リカバリインスタンスリカバリ障害が発生したインスタンスのキャッシュ上にしか存在しなかったデータブロックは生存する他インスタンスが自動的にリカバリを実施正常インスタンスが障害インスタンスの REDO ログを読み込み自動リカバリ障害インスタンスの再起動を待つ必要はない Down Active Active Active REDO REDO REDO DATA 38

39 ダーティバッファ量インスタンスリカバリに要する時間 FAST_START_MTTR_TARGET パラメータリカバリ時間はインスタンス障害発生時のダーティバッファの量に依存するバッファキャッシュ上のデータとデータファイル上のデータの差ダーティバッファは DBWR によって定期的に書き出されている ( ファストスタートチェックポイント ) 障害ポイント最大リカバリ量 fast_start_mttr_target=10 fast_start_mttr_target=5 時間リカバリ目標時間をパラメータ FAST_START_MTTR_TARGET に設定することで上記動作を自動制御可能 39

40 クラスタデータベースへの接続求められること障害ノードをクラスタから除外する動作をしていてもアプリケーションから正常なサーバーに接続を切り替えなければシステムとして動作しない RAC に対する接続に求められることと提供する RAC の機能 1. RAC 側のノード数を意識せずに接続が可能なこと SERVICE_NAME と SCAN 2. 正常ノードとの間で接続が確立されること接続時フェイルオーバー 3. 障害ノードとの間の無効な接続が破棄されること FANイベントとFCF 40

41 Oracle Database への接続 $ sqlplus username/password@tns_alias lsnr servicea tns_alias= (DESCRIPTION = (ADDRESS =(PROTOCOL=TCP)(HOST=hostname)(PORT=port)) (CONNECT_DATA = (SERVICE_NAME = servicea )) ) Instance Oracle クライアントはホスト名ポート番号サービス名を指定してリスナーに接続リクエストを送る 41

42 データベースサービスの構成サービスはアプリやワークロードの単位に相当する論理的なグループ (DESCRIPTION = (ADDRESS_LIST= (ADDRESS = (PROTOCOL = TCP)(HOST = VIP1)(PORT = port)) (ADDRESS = (PROTOCOL = TCP)(HOST = VIP2)(PORT = port)) (ADDRESS = (PROTOCOL = TCP)(HOST = VIP3)(PORT = port)) (CONNECT_DATA = (SERVICE_NAME = servicec )))) リスナーは指定されたサービスがどのインスタンスで利用可能かを把握 Service servicec has 1 instance. Instance Instance3, status READY lsnr lsnr lsnr クライアントは接続先はサービスに対して接続 RAC のノード数起動しているか停止しているかも意識不要 Instance1 serviceb servicea Instance2 servicec Instance3 42

43 Oracle リスナーが担う 2 つの役割図は便宜上 SCAN_LSNR 1 つだが複数起動する 1. 接続リクエストのリダイレクト 2. Oracle インスタンスとセッション確立 Oracle RAC 11g Release 1 まですべてのリスナーが 2つの役割を担う Oracle RAC 11g Release 2 から 2 つの役割を異なるリスナーが担うリダイレクトの役割を SCAN リスナーが担う scan_lsnr lsnr lsnr lsnr lsnr lsnr lsnr serviceb servicec serviceb servicec Instance1 servicea Instance2 Instance3 Instance1 servicea Instance2 Instance3 43

44 SCAN(Single Client Access Name) を用いた接続図は便宜上 SCAN_LSNR 1 つだが複数起動する (DESCRIPTION = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST= scanname)(port = port)) (CONNECT_DATA = (SERVICE_NAME = servicec )))) SCAN 名の名前解決 (scanname) SCAN VIP (1,3,2) scan_lsnr DNS サーバ SCAN 名 : scanname SCAN VIP1: XX.XX.XX.101 SCAN VIP2: XX.XX.XX.102 SCAN VIP3: XX.XX.XX.103 scan_lsnr 接続リクエストを送る先を意識する必要がない lsnr lsnr lsnr ノードが増えた場合に ADDRESS リストにアドレスを追加する必要がない serviceb servicea servicec Instance1 Instance2 Instance3 44

45 接続リクエストが正常なノードに割り振られる (DESCRIPTION = (ADDRESS_LIST= (ADDRESS=(PROTOCOL=TCP)(HOST= scanname)(port = port)) (CONNECT_DATA = (SERVICE_NAME = servicec )))) SCAN 名の名前解決 (scanname) SCAN VIP (3,1,2) DNS サーバ SCAN 名 : scanname SCAN VIP1: XX.XX.XX.101 SCAN VIP2: XX.XX.XX.102 SCAN VIP3: XX.XX.XX.103 接続確立に失敗した場合エラーを返さずに自動でアドレスリスト内の別の接続先へ試行 scan_lsnr lsnr scan_lsnr lsnr lsnr 最初のリスナー ( リスナー 1) への接続に失敗すると別のリスナー ( 例えばリスナー 2) にフェイルオーバーする Instance1 serviceb servicea Instance2 servicec Instance3 接続時フェイルオーバーと呼ぶ 45

不要な接続を破棄する Fast Connection Failover(FCF) コネクションプールを利用している場合障害ノードとの間で確立している無効な接続を能動的にすべて破棄する機能 SQL 結果待機中のコネクションにエラーを返すノード障害発生後コネクションプール内に残っている

46 不要な接続を破棄する Fast Connection Failover(FCF) コネクションプールを利用している場合障害ノードとの間で確立している無効な接続を能動的にすべて破棄する機能 SQL 結果待機中のコネクションにエラーを返すノード障害発生後コネクションプール内に残っている障害ノードにつながるコネクションを能動的に破棄する機能コネクションプールから無効なコネクションを取ってしまうのを防ぐ接続時フェイルオーバーによって新規接続は障害ノードに行かない lsnr Instance1 FAN イベント lsnr lsnr serviceb servicec servicea Instance2 Instance3 46

47 データベース構成と計画停止時間の目安 Single HA RAC RAC + DG HA RAC RAC RAC 適用対象データベース Grid Infrastructure (OCW/ASM) パッチの種類 BP/PSU/CPU RAC Rolling 可否 Yes DB 停止後適用 ( 数分 ~ 数十分 ) フェイルオーバーで交互適用 ( 数分 x 2 回 ) PSR No DB 停止後適用 ( 数十分 ~ 数時間 ) BP/PSU/CPU PSR Yes Yes OS - Yes DB 停止後適用 ( 数分 ~ 数十分 ) DB 停止後適用 ( 数十分 DB 停止後適用 ( 数分 ~ 数時間 ) フェイルオーバーで交互適用 ( 数分 x 2 回 ) フェイルオーバーで交互適用 ( 数分 x 2 回 ) フェイルオーバーで交互適用 ( 数分 x 2 回 ) DG RAC ローリング適用 ( ゼロ ) スイッチオーバーで交互適用 (5 分未満 x 2 回 ) RAC ローリング適用 ( ゼロ ) RAC ローリング適用 ( ゼロ ) RAC ローリング適用 ( ゼロ ) 47

48 段階的な接続切り替えがポイント 1) 通常動作 2) サービスの移動 ( 正常移動 ) lsnr Inst1 servicea lsnr Inst2 新規物理接続は Inst2 へサービス強制移動をすると既存セッションが強制切断トランザクションロールバック再接続して再実行が必要になる lsnr Inst1 lsnr servicea Inst2 3) DB インスタンス正常停止 4) 縮退運転 ( サービス移動済みのため ) OS やクラスタを停止すると misscount やクラスタ再構成が発生するので OS 停止が必要な場合でも先に DB を停止正常停止すればインスタンスリカバリは発生しない RAC Reconfiguration の間は待機 lsnr Inst1 lsnr servicea Inst2 トランザクションが終了したセッションは Inst2へ再接続 lsnr 次のトランザクションからInst2で実行される Inst1 lsnr servicea Inst2 48

49 RAC リソース再構成前ページの手順だとアプリケーションの停止は RAC リソース再構成の間 RAC リソース再構成は次に依存 GCS リソース ( バッファキャッシュのサイズ ) GES リソース ( 獲得されているエンキューの数など ) 大きなバッファキャッシュを持つシステムに対しては MOS Document ID のチューニング ( パラメータにチューニングとパッチ適用 ) の効果は期待できるお客様環境を模したあるテストでは RAC リソース再構成時間が約 20% 短縮された 49

50 まとめ RAC を利用することで高可用性と拡張性が得られる RAC もシングルインスタンスも基本的な考え方は同じ 50

51 参考資料 Oracle DBA & Developer Days 2011 実はシンプル!RAC チューニングの考え方 Oracle DBA & Developer Days 2011 実践!! 高可用性システム構築 ~RAC 基本編 ~ Oracle DBA & Developer Days 2012 Oracle Real Application Clusters/ Oracle Clusterware の高可用性機能 Oracle DBA & Developer Days 2011 解説!Oracle RAC への接続ロードバランスと接続フェイルオーバー Core Tech Seminar Database 12c Release 2 RAC Stack 51

52 以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さいオラクル製品に関して記載されている機能の開発リリースおよび時期については弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社関連会社の米国及びその他の国における登録商標です文中の社名商品名等は各社の商標または登録商標である場合があります

53 みなさまの投稿をお待ちしております Twitter #OracleTechNight

54 Oracle Digital はオラクル製品の導入をご検討いただく際の総合窓口電話とインターネットによるダイレクトなコニュニケーションでどんなお問い合わせにもすばやく対応しますもちろん無償どんなことでもご相談ください 54

55 55

56 56

以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらな

以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらな実はシンプル!RAC チューニングの考え方日本オラクル株式会社基盤技術部シニアエンジニア佐々木亨以下の事項は弊社の一般的な製品の方向性に関する概要を説明するものですまた情報提供を唯一の目的とするものでありいかなる契約にも組み込むことはできません以下の事項はマテリアルやコード機能を提供することをコミットメント ( 確約 ) するものではないため購買決定を行う際の判断材料になさらないで下さい