Oracle White Paper

Transcription

1 オラクル ホワイトペーパー 2010 年 2 月 上での Server Hardware Sponsored by Copyright 2010 NS Solutions and Oracle, All Rights Reserved.

2 はじめに 新日鉄ソリューションズ株式会社 ( 以降 NSSOL) は 1991 年の米国オラクル社と新日本製鐵株式会社による戦略的提携関係締結以来 長年にわたり強力なパートナー関係を礎として オラクル製品を活用したビジネスに取り組んできました 継続される戦略的なビジネス展開の中で 2006 年 11 月 日本オラクル株式会社 ( 以降 日本オラクル ) は NSSOL をはじめとするグリッド戦略パートナー各社と協業体制を確立し 企業のシステム基盤の最適化を実現する次世代のビジネス ソリューションを構築するため 先鋭の技術を集結した Oracle GRID Center 1 を開設しました NSSOL はその開設に賛同し Oracle GRID Center にて共同で技術検証を行っています 本ホワイトペーパーは Oracle GRID Center の趣旨にご賛同頂いたデル株式会社 インテル株式会社 シスコシステムズ合同会社からのハードウェア ソフトウェアのご提供 及び技術者によるご支援などの多大なるご協力の下で実施したものです ここに デル株式会社 インテル株式会社 シスコシステムズ合同会社 ならびにご協力頂いた技術者に謝意を表します 1 Oracle GRID Center は多くの技術レポートを公開しています Oracle GRID Center ( 1

3 概要... 3 In-Memory Parallel Query... 3 Oracle Real Application Clusters... 6 検証環境... 8 サーバー プールを活用したIn-Memory PQの実行... 9 まとめ

4 概要 Oracle Database 11g Release 2( 以降 Oracle Database 11g R2) では SQL の Parallel 実行機能が大幅に拡張されました 従来から SQL の Parallel 実行は大容量データを高速に分析する Data Warehouse( 以降 DWH) や月次や日次で実施されるバッチ処理において サーバーの CPU リソースやストレージのディスク性能を 100% 引き出すことで 高速処理を実現してきました しかし 近年の急速に発展 変化し続けるビジネス環境においては 如何に早期に業務改善や経営判断ができるのかが鍵となる為 企業資産である大容量データをより早く分析する必要性が増してきています また CPU 性能の向上はめざましく 2CPU ソケットの PC サーバーでも大容量の物理メモリを搭載可能となり十分な処理性能を得ることも可能となってきました 一方で ストレージ性能も向上してはいますが 1 本あたりのディスク サイズの大容量化に伴って性能ベースではなく容量ベースでディスク本数を設計する傾向が強まり ストレージの性能限界が SQL の性能限界となり CPU リソースを使いきれていないケースが増えてきています この差を埋めるべく Oracle Database 11g R2 では SQL の Parallel 実行を簡素化 かつ高速化する機能が拡張されています それらの新機能の 1 つである In-Memory PQ は 大容量の物理メモリ上にキャッシュされた大容量のデータを高速に並列処理することで 先に述べた課題を解決することが可能な機能です 本文書では Oracle GRID Center において日本オラクルと NSSOL で共同検証した In-Memory PQ を採用することで得られる Oracle Database 11g R2 での検索処理の性能向上についてご紹介します 大容量のデータを扱う従来の Parallel Query( 以降 PQ) では データベース バッファ キャッシュ ( 以降 バッファ キャッシュ ) を経由しないでディスクから直接読み込む Direct Path Read でデータにアクセスしていました もちろん ディスクから読み込むよりもメモリ ( バッファ キャッシュ ) から読み込んだ方が高速です しかし 一昔前は大容量の物理メモリは非常に高価であり サーバーに搭載可能な物理メモリも少ないことから 大規模な表データを全てキャッシュさせる為には データベース インスタンスのバッファ キャッシュのサイズが不十分な環境がほとんどでした もしそのような環境で 通常の数件の小さなデータを扱うクエリと同様にバッファ キャッシュ経由でデータへアクセスした場合 ディスクから読み込んでバッファ キャッシュにキャッシュしても 次々とディスクから読み込まれる別のデータによって追い出されるため キャッシュの再利用が期待できません さらに 再利用できないデータのためのキャッシュ管理のオーバーヘッドが クエリのレスポンス タイムを劣化させます このような理由から Oracle Database に 3

5 おける大容量データを扱う PQ では Direct Path Read でデータにアクセスする最適化された方式を採用していました しかしながら 2009 年夏に販売が開始されたインテル社の CPU( インテル Xeon プロセッサー E5540 (2.53GHz)) を搭載したデル社のサーバー (DELL PowerEdge R710) では 1CPU ソケットあたり最大 72GB もの物理メモリが搭載可能となりました 大容量データをバッファ キャッシュ上にキャッシュすることが可能なエントリー モデルのサーバーが登場してきたことから PQ でもバッファ キャッシュ上のデータを利用できる Oracle Database 11g R2 の新機能 In-Memory PQ を適用し易い環境が整ってきました 図 1 Direct Path Read と In-Memory PQ In-Memory PQ は バッファ キャッシュ上にキャッシュされたデータ ( 表や索引等のデータベース セグメント ) を使用する PQ であり ストレージ性能の限界を排除した SQL の高速処理を実現します もちろん 対象のデータがキャッシュされていない状態の場合は ディスクからバッファ キャッシュ上にキャッシュするオーバーヘッドが発生する為 従来の Direct Path Read での処理よりもレスポンス タイムが劣化する可能性があります また バッファ キャッシュのサイズの約 80% よりも大きなデータを扱う場合は SQL の実行計画作成時に Direct Path Read の PQ が実行されるようデータベースの内部で自動判別されます 4

6 図 2 In-Memory PQ の適用判断フロー In-Memory PQ の設定は 初期化パラメータ PARALLEL_DEGREE_POLICY=AUTO( デフォルトは MANUAL) を設定することでアプリケーションの変更無しに適用することが可能です また Oracle Real Application Clusters( 以降 Oracle RAC) 環境においては 複数インスタンスのバッファ キャッシュを仮想的な 1 つのバッファ キャッシュとして扱います そして 複数インスタンスにデータ ( 表が索引等のデータベース セグメント ) を分散してキャッシュするアーキテクチャを採用していることから Oracle RAC のノードを追加することでより大きなセグメントをキャッシュすることが可能となります 図 3 RAC のノード数と In-Memory PQ 5

7 Oracle Real Application Clusters は複数のサーバーやストレージを仮想的に 1 つのハードウェア リソースとして利用可能とし 高拡張性や高可用性 容易な運用管理を実現する Oracle 独自のテクノロジーであり Oracle9i Database R1 でリリースされて以来 進化し続けてきています Oracle RAC 11g R2 は Oracle Grid Infrastructure と組み合わせて使用します この Oracle Grid Infrastructure は クラスタ構成の監視を行う Oracle Clusterware とストレージ管理を行う Oracle Automatic Storage Management が統合したものであり 従来よりも広範囲でのハードウェア リソースの最適化を提供します 実際には サーバー プールと呼ばれるサーバーを仮想化する機能によって RAC と物理サーバーの関係を排除し システムをまたがったハードウェア リソースの最適化が可能になります 図 4 サーバー プールによるノード数の最適化の例 図 4 で示した通り Oracle RAC を構成するノード数はサーバー プールに割り当てられたサーバー数に連動します サーバー プールの構成変更は非常に柔軟であり srvctl コマンドや Oracle Enterprise Manager による画面操作により容易に複数のサーバー プール間でサーバー数を調整することが可能です 例えば サーバー プールを拡張する場合 対象サーバー プール上で稼働している Oracle RAC データベースに影響することなくインスタンスが自動的に追加されます 逆に縮小する場合は 対象サーバー プール上で稼働していた RAC データベース内の縮小分の任意のインスタンスを停止する必要はありますが その他のインスタンスは影響なく稼働し続けます この Oracle RAC 11g R2 で実装されたサーバー プールを活用することで バッファ キャッシュの合計サイズを In-Memory PQ が実行可能なサイズまで一時的に増加させることを目的とした 6

8 Oracle RAC のノード数変更が可能となります 例えば 日中のオンライン トランザクションの処理に割り当てているノード数では 夜間の大量データを集計するバッチ処理で In-Memory PQ が使用可能なバッファ キャッシュのサイズを満たしていない場合 バッチ処理のタイミングだけサーバー プールを調整してノード数を増加させることで In-Memory PQ が使用可能になり 高速なバッチ処理を実現します 7

9 検証環境 本検証で使用したシステム全体の構成は以下の通りです インテル Xeon プロセッサー E5540 (2.53GHz) を搭載した DELL PowerEdge R710 上に Oracle Database 11g Release 2 をインストールし 4Gbps の Fibre Channel( 以降 FC)4 本で接続された EMC CX4-240 上にデータベースを配置しました データベース サーバー : 台 インテルプロセッサー ( ) コア数 : ストレージ : コントローラ 各 あたりプロセッサー ( インテル プロセッサー コア数 : ) ( 各 あたり ) ( 各あたり ) 8

10 サーバー プールを活用した の実行 日中のオンライン トランザクションの処理に対し 2 ノードを割り当てていますが 夜間の大量データを集計するバッチ処理で In-Memory PQ が使用可能なバッファ キャッシュのサイズを満たしていない環境を想定します この環境において サーバー プールを活用して一時的に ( バッチ処理のタイミングだけ )2 ノードから 3 ノードへノード数を増加させることで In-Memory PQ が使用可能になるシナリオを検証します はじめに 4 ノードの Grid Infrastructure 環境に 2 つの Oracle RAC データベース ( 各 2 ノード ) が構築されている統合データベース環境を作成します 図サーバー プールの構成変更による の実行 サーバー プールの構成を変更するには srvctl コマンドを実行するか Oracle Enterprise Manager から作業を実施します 以下は srvctl コマンドの例です $ ### srvpool2 のノード数を縮小 (2 ノード 1 ノード ) $ srvctl stop instance d dbname n nodename $ srvctl modify srvpool g srvpool2 u 1 $ srvctl status srvpool -g srvpool2 サーバー プール名 : srvpool2 アクティブ サーバー数 : 1 $ ### srvpool1 のノード数を拡張 (2 ノード 3 ノード ) $ srvctl modify srvpool g srvpool1 u 3 $ srvctl status srvpool -g srvpool1 サーバー プール名 : srvpool1 アクティブ サーバー数 : 3 9

11 srvctl stop instance では デフォルトでデータベース インスタンスの shutdown immediate が実行さ れます 実行中のトランザクションの完了までを保証したい場合は Transactional モードで Shutdown(-o オプションで t を指定 ) してください また Oracle Enterprise Manager を使用したサーバー プールの構成変更手順は 次の通りです Oracle Enterprise Manager へログイン後 右上の クラスタ タブを押下 管理 タブの サーバー プールの管理 を選択 縮小対象のサーバー プールを選択し 編集 ボタンを押下 10

12 縮小後の最大サイズ ( ノード数 ) を指定し 発行 ボタンを押下 拡張するサーバー プールを選択し 編集 ボタンを押下 縮小時と同様に 拡張後の最大サイズ ( ノード数 ) を変更し 構成変更完了 11

13 以下は 2 ノードの場合に実行される従来の Direct Path Read による PQ と 3 ノードの場合に実行 される In-Memory PQ の全表検索 SQL のレスポンス タイムの測定結果 ( 相対値 ) です 図 6 In-Memory PQ の効果 今回の検証で使用したシンプルな SQL では サーバー プールの構成変更でノード数を増やすことで In-Memory PQ が実行され 約 10 倍以上の検索性能が向上することが確認できました また 対象の Oracle RAC データベースのバッファ キャッシュの合計サイズを増加させることで In- Memory PQ が実行されるようになったことから 検索対象セグメントが各インスタンスのバッファ キャッシュ上に分散してキャッシュされることも証明されました ただし 表データを読み込む処理以外の部分がボトルネックとなる傾向のある Join 数や Group By で指定するカラム数が多いような複雑な SQL では In-Memory PQ による大幅な性能向上を得られにくい可能性があります また In-Memory PQ はバッファ キャッシュ上に検索対象セグメントがキャッシュされていることが前提となる為 この性能はサーバー プールの構成変更後 (2 ノード 3 ノード ) に 一度バッファ キャッシュ上にキャッシュさせた後の SQL 実行において得られる値です キャッシュされていない際の SQL 実行ではバッファ キャッシュにキャッシュするオーバーヘッドが発生する為 2 ノードでの従来 Direct Path Read よりも処理時間が長くなる傾向があります 12

14 まとめ 本検証より Oracle Real Application Clusters 上における In-Memory Parallel Query の有効性を証明することができました Oracle RAC 11g R2 のサーバー プールを活用して複数のデータベース システムを統合することにより 8 ノードや 16 ノードといった大規模な Oracle RAC 環境を構築することが可能となります このサーバー プールにより 従来では難しかったデータベース間でのノード拡張 / 縮小作業が非常に容易になり 負荷状況に合わせた柔軟なリソース分配が可能となることから 各データベースのピークを想定したサーバー台数の合計よりも少ない台数 ( 低コスト ) での構築が可能となります さらに このサーバー プールを活用して一時的にノード拡張することで Oracle RAC データベースのバッファ キャッシュの合計サイズを増加し 通常運用時のノード数では全体をキャッシュすることが不可能であった大規模なセグメントにおける In-Memory PQ の実行が可能となります 従来 PQ では Direct Path Read( ディスク上のデータを直接読み込む ) で大容量データにアクセスするためディスク I/O がボトルネックになりがちでしたが In-Memory PQ を利用することによりディスク I/O を極小化し SQL の高速化が実現できます In-Memory PQ は バッファ キャッシュ上にキャッシュされたデータを扱う特性上 同一セグメントを何度も繰り返し検索するような処理 (1 つのファクト表から複数のマテリアライズド ビューを作成する等 ) において 圧倒的なパフォーマンスを発揮すると考えます 13

15 共著者 矢木覚田中涼一 は 新日鉄ソリューションズ株式会社の登録商標です ロゴは 新日鉄ソリューションズ株式会社の登録商標です その他本文記載の会社名及び製品名は それぞれ各社の商標又は登録商標です 新日鉄ソリューションズ株式会社 東京都中央区新川二丁目 デル株式会社 神奈川県川崎市幸区堀川町 ソリッドスクエア東館 番地 ロゴは 米国の商標または登録商標です その他の社名および製品名は各社の商標または登録商標です インテル ロゴ は アメリカ合衆国およびその他の国におけるの商標です インテル株式会社 東京都千代田区丸の内国際ビル階 上での年月著者柴田長共著者日下部明谷川信朗日本オラクル株式会社東京都港区北青山オラクル青山センター 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は その内容に誤りがないことを保証するものではなく また 口頭による明示的保証や法律による黙示的保証を含め 商品性ないし特定目的適合性に関する黙示的保証および条件などのいかなる保証および条件も提供するものではありません オラクルは本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません は米国およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です