” Oracle Database Summit 2009 11g R2 & Exadata V2 登場! in 東京 クラウド時代に向けて、データベースの新たな価値の発見”

プロとしてのOracleアーキテクチャ入門 Oracle現場主義

今日は、ザ・プリンスパークタワー東京 で開かれた
” Oracle Database Summit 2009 11g R2 & Exadata V2 登場! in 東京 クラウド時代に向けて、データベースの新たな価値の発見” に参加してきました

私は以下の3つのセッションに参加しました。

• 13:30 - 14:30 B-1 ：Oracle Database 11g R2 次世代グリッド技術解説
• 14:45 - 15:45 B-2 ：In-Memory Parallel Query によるパフォーマンス高速化技術解説
• 16:00 - 17:00 B-3 ：Oracle Database 11g R2 高可用性技術

(所感) 3つのセッションを通して

• 同僚が今回の目玉である Exadata のセッションをとっていたので、
  私はあえて、裏セッションをとっていたからだと思うのですが、
  話題的に目新しさはなく、クラウドやマルチコアを意識したOracle 既存機能の改善報告をされた
  といった印象でした。
• 私が受講した中では、唯一、
  最後の B-3 で話のあったエディションには新しさを感じました。
  Oracle さんには無停止でのシステム改変を実現するような機能を
  どんどん拡充していってもらいたいなと思います。
  

以下、私が受けた各セッションのメモを載せておきますので、
ご参考ください。

受講メモ： B-1 クラウド時代に向けて大規模なインフラ集約でコスト削減を実現す Oracle Database 11g R2次世代グリッド技術解説

• ここでの目玉は、サーバグループ、ポリシーベース管理

# グリッド技術の進化
      o 単一サービス基盤
            + データベースグリッド
                  # データセンターグリッド
                        * キーポイント
                              o ~ ポリシーベース管理
                              o インフラ全体の最適化
                  # データセンター
                        * ITの資産をあつめて置く場所
                  # 1つのRAC環境でグリッドと読んでいたものをデータセンター全体に広げる
            + 複数のアプリケーションがデータベースインフラを共有
# ポリシーベース管理の概要
      o ポリシーベース管理
            + Oracle Application Clusters の新しい概念
            + サーバプール
                  # 論理的なグループ
            + サーバの割り当て
                  # Oracle Clusterware が自動的に実施
                  # サーバプールでグループ化
                        * RACデータベース
                        * アプリケーション
                  # ポリシーに従う
                        * 最少数
                        * 最大数
                        * 重要度
            + 従来のシステム管理との差異
                  # 専用サーバという考えを排除
                  # Oracle Clusterware 配下にすべてのサーバを集約
                  # サーバの割り当ては Oracle Clusterware が自動管理
            + サーバ障害字の挙動
                  # 空きサーバを自動的に割り当てる
                        * サーバプールに連動
                              o RACインスタンスも再配置
            + キャパシティ管理
                  # サービス拡張
                        * ポリシーの変更だけでよい
                              o RACのノード数が増加
            + システム管理者の役割
                  # ビジネス用件にしたがってポリシーを定めるだけ
                        * サーバ数
                        * 重要度
# サーバープール
      o Oracle Clusterware 配下
      o 排他的
      o 1つのサーバは1つのサーバプールのみ属することができる
      o 属性
            + 最少数
            + 最大数
            + 重要度
      o 管理コマンド
            + srvctl
                  # 作成
                  # 削除
                  # 変更
                  # 状態確認
      o 組み込みサーバプール
            + Oracle Clusterware をインストールしたときにデフォルトで作成されるサーバプール
                  # Genericサーバプール
                  # Free サーバプール
                        * 空きサーバとして確保しておくサーバ群
      o 種類
            + Genericサーバプール
            + ユーザ定義サーバプール
                  # srvctl でユーザが作成したもの
            + Free サーバプール
            + ユーザ定義サーバプールとFreeサーバプールとの間でサーバの動的な割り当てが行われる
# RACデータベースの構成
      o 構成タイプ
            + 管理者管理
                  # Genericサーバプール
                  # 従来のスタイル
                  # RACを構成するサーバを選択して構築
            + ポリシー管理
                  # ポリシーベース管理
                  # RACを構成するカーディナリティを指定して構築
      o DBCA
            + 構成タイプを選択する画面が新規追加
            + サービスの作成
                  # 管理者管理
                        * 従来どおり
                  # ポリシー管理
                        * UNIFORM
                              o RACの全員スタンスでサービスを利用可能
                        * SINGLETON
                              o RACインす案スのいずれか1つでサービスを利用
      o サーバプールとDBの関係
            + Genericサーバプール
                  # 管理者管理RACデータベース
            + ユーザ定義＆Freeサーバプール
                  # ポリシー管理RACデータベース
      o RAC One Note
            + EE のオプション
                  # 11gR2
            + サードパーティ製のクラスタウェアの使用にかかるコスト削減
            + 構成
                  # 管理者管理 RAC データベースとして作成
                        * Genericサーバプール
                  # Oracle提供のスクリプトを実行
                        * FO可能な設定への変更
            + OMotion
                  # ダウンタイムなしでのサーバ移行
                  # Oracleからの提供スクリプト
                        * 1次的に2ノードRACの状態になる
                  # 検証
                        * OMotion実行時のサーバ負荷の測定
                              o DBセッション数
                                    + OMotionの実行前後でセッションが徐々に移行される
                              o スループットの変化
                                    + 実行中に劣化しないことを確認
      o インスタンスケージング
            + リソース制御
            + インスタンスごとのCPU使用率制御
            + 管理オーバヘッドが低い
            + CPU_COUNT
                  # 100% つかわなくてもリソースの割り当てが可能
# RACへの接続方法
      o SCANを使用する
            + RAC 11g R2 から
            + SCAN名、ポート番号、サービス名で接続
                  # 接続設定の手間が低減
                  # ポリシーベース管理に対応した接続
            + SCANの構成
                  # 3個のIPアドレスを用意する必要がある
                        * DNS
                        * GNS
                  # SCANの名前解決で3つのIPアドレスがかえてくる
                        * 返ってくるIPアドレス、DNSラウンドロビン
                  # クラスタ用インフラストラクチャ
                        * Grid
                  # CRSリソース
                        * 3個のSCAN用のVIPとリスナー用が作成される
                  # Clientサイド
                        * 接続時FO
                        * クライアントサイドロードバランシング
                  # Serverサイド
                        * サーバサイドロードバランシング
      o 接続方法
            + tnsnames.ora
                  # HOST に SCAN 名
            + 簡易接続ネーミングメソッド
                  # 10gから導入された機能
                  # tnsnames.ora の構成が不要
      o 従来との比較
            + SCANリスナーがいったん接続をうけてから VIP リスナーへつなげる
            + 中継の役割
      o クラスタ構成のネットワーク要件
            + 必要となるIPアドレス
                  # パブリックIP
                  # 仮想IP
                  # プライベートIP
                  # SCAN IP
            + VIPとSCAN VIP の要件
                  # 未使用のIPアドレス
                  # パブリックインターフェースと同じサブネット上にあること
                  # クラスタ内ですべて同じNIC名を使用すること
            + 少なくとも各サーバマシンに2枚のNICが必要

受講メモ： B-2 マルチコア・大容量メモリを最大限活用する先進のパラレル処理“In-Memory Parallel Query”によるパフォーマンス高速化技術解説

• ここでの目玉は、In-Memory Parallel Query

# 11g R2 開発のテーマ
      o Lowering IT Costs
            + より高い
                  # SLAの実現
                        * 冗長性
                        * 可用性
            + 単なるコスト削減ではない
            + OTNにホワイトペーパー

# DWH環境の課題と機能強化のポイント
      o 課題
            + DWHが有効に活用できていない
                  # 導入はしている
                  # Why？
                        * 検索パフォーマンスが悪い
                              o + - Why
                                    + Disk IO
                                          # スタースキーマ
                                          # 複数の表の結合、sort
                                          # 期間を軸とした大量データへのアクセス
                                          # 分析する対象の増加
                              o チューニング方法
                                    + パラレルクエリ
                                          # 1つのクエリを複数に分割
                                                * QC
                                                      o 指揮者
                                                * QS
                                                      o 実施者：データアクセス
                                          # ユーザの側は意識する必要がない
                                          # IO集約的な処理に有効
                                                * 実行時間の長いクエリ
                                                * 大量データロード
# In Memory Parallel Query
      o パラレルクエリの高速化の実現
            + HWの進化
                  # アーキテクチャの変更
                        * Oracle7
                              o ダイレクトパスリード
                                    + メモリ上にキャッシュしない
                                    + メモリ：小
                                          # データの再利用性が低い
                                    + CPU：シングルコア
                        * 11gR2
                              o HWの恩恵を享受できるアーキテクチャに変更
                                    + インメモリパラレルクエリ
                              o メモリ：大
                              o CPU：高速、マルチコア
                              o ディスクの性能向上
                                    + 大容量
                                    + 回転数はあまり向上していない
            + メモリ上にキャッシュされたデータにアクセスできるようにした。
                  # 複数のユーザで共有できる
                  # メモリやCPUリソースを有効活用
            + 特徴
                  # 複数インスタンスのSGAを利用できる
                        * RAC
                  # 複数インスタンスにセグメントを分割できる
            + メリットとオーバヘッド
                  # データをいったんメモリにキャッシュするためのオーバヘッド
                        * その後アクセスされるデータに対しては高速
                              o 再利用される内容であればあるほど恩恵を享受できる
            + データサイズと高速化の関係
                  # より大量のデータがキャッシュされていればより効率がよくなる
                  # 有効な範囲がある
                        * バッファキャッシュの80％
                              o なぜ80％か？
                                    + キャッシュアウトが頻繁に起こらないようにするため
            + RACとの組み合わせ
                  # SGAの領域を増やすことによってキャッシュできる有効範囲を増やすことができる
                        * サーバプールの拡張
                        * バッファキャッシュのサイズを増やす
            + Oracle Advanced Complession
                  # OLTP表圧縮との組み合わせ
                        * Oracle独自の圧縮アルゴリズム
                              o Zip等とはことなる
                              o 圧縮された状態のままバッファキャッシュに読み込み可能
                        * セグメントサイズが閾値を大幅に下回る
                              o より大量のデータをキャッシュできるようになる
      o ~ 自動パラレル度設定
      o ~ パラレルステートメントキューイング
# 検証結果
      o NEC
            + 従来と比較して5〜6倍高速
            + データ圧縮との組み合わせ結果
            + ことなる範囲のデータを参照した場合
                  # 短期間を見るユーザ：多
                        * IOが発生しない
                        * キャッシュされるため
                  # 長期間を見るユーザ：少
                        * IOをほぼ占有
      o + - NSSOL
            + サーバプールと Inmemory-Parallel-Query
                  # 従来構成から、サーバプール構成に移行
                  # In-memory Parallel Query を使えるようにするとどうなるかを試した
                  # 目的あいまい
                        * メモリのサイズがたりないというなら単純にメモリを増強してどうなるかを試したほうがいいのではないか？
# その他の新機能
      o + - 自動パラレル度設定
            + 従来、クエリのパラレル度をクエリの特性にあわせて設定しなければならなかった
            + Oracleが最適なパラレル度を自動設定するようになった
                  # DBAの負荷低減
      o + - パラレルステートメントキューイング
            + 従来の課題
                  # 大量のパラレルクエリ
                        * リソース：メモリの不足
                              o 一部のパラレルクエリのパラレル度をさげる
                              o パラレルクエリの実行時間に大きな差
            + パラレルクエリをキューイング
                  # FIFO
                  # リソースマネージャの機能を応用
            + メリット
                  # パラレルクエリの多重実行によるレスポンス悪化を軽減
                  # クエリの特性にあわせたパラレル度で実行可能
            + デメリット
                  # 1つ1つのクエリタイムとしては遅くなる
                        * トータルでのコストの最適化を考えている
# Summary

受講メモ： B-3 アプリケーションのノンストップ運用を実現するOracle Database 11g R2 高可用性技術

• ここでの目玉は、エディションベースの再定義、Data Guard、Advanced Complession Option

# Oracle DB と高可用性要件
      o 企業を取り巻く環境
            + ミッションクリティカルに限らず24×365の可動を求められる
                  # アプリケーションの実装をいかに柔軟に行うか
                  # コンプライアンス
      o 高可用性にもとめられる要素
            + 継続的稼動
            + 迅速な復旧
            + 迅速なエラー検出
            + 信頼性
      o Oracleの高可用性ソリューション
            + 計画外停止
                  # システム障害
                  # データ障害
            + 計画停止
                  # システム変更
                  # データ変更
                  # アプリケーション変更
                        * ~ エディションベースの再定義
# アプリケーションの視点からの高可用性
      o ポイント
            + オブジェクト
                  # エディションでDB内のバージョニング
            + 表
                  # エディションビューで表を仮想化
                  # クロスエディショントリガーで新旧アプリケーションのデータ整合性を担保
      o 課題
            + サービスをとめたくない
            + データベースに対する変更が多い
            + 変更前のトランザクションを変更後にもすべて反映する必要がある
            + 平行稼動をする場合は、変更前後の両方に反映する必要がある
      o エディション
            + DB内のオブジェクトを仮想的にバージョニング
                  # アップグレード前後のアプリケーション共存
                  # アプリケーションダウンタイムの最小化
                  # セッション単位でエディションを変更可
            + エディション化の手順例
                  # ユーザをエディション使用可能に変更
                  # プロシジャの作成
                  # プロシジャの実行
                  # エディションを作成する
                  # エディション化されたオブジェクトを改変
            + エディション化可能なオブジェクト
                  # シノニム
                  # ビュー
                  # ライブラリ
                  # すべての PL/SQL オブジェクト
                        * Package
                        * Procedurre
                        * Function
                        * Non-crossedition Trigger
                        * Object Type
                        * + - テーブルはエディション化できない
                              o データを2重に格納しなければならない
                              o 非効率
            + エディションビュー
            + クロスエディショントリガー
                  # フォワード
                        * 変更前アプリケーションからの変更を反映
                  # リバース
                        * 変更後アプリケーションからの変更を反映
# DB視点からの高可用性
      o + - 可用性の方法
            + DIsk
                  # ASM
            + サーバ層
                  # RAC
            + 高可用性だけではなく性能を追従させるのが強み
      o + - Oracle Data Guard
            + 特徴
                  # 可用性に特化
                        * DBに関連するすべてを2重化する
                  # REDO転送によるデータ保護
                  # ダウンタイムの短縮
                        * 計画停止・計画外停止の切り替え
                  # スタンバイを活用可能
                        * レポーティング
                        * テスト
                  # フェイルオーバー
                        * 障害時
                  # スイッチオーバー
                        * 計画停止
                              o メンテナンス
                              o Oracleアップグレード
            + 2種類のスタンバイデータベース
                  # フィジカルスタンバイ
                        * リカバリの仕組み
                              o 最近はこちらを強化
                  # ロジカルスタンバイ
                        * SQLベース
                              o DBはつねにオープン
            + ポイント
                  # 高精度名レポーティング
                        * Active DataGuard
                              o 従来：Redo適用中は参照できなかった
                                    + Redoをいったん停止して、参照する
                              o Redoを適用しながら参照可能
                                    + 11gR1から提供
                                    + データの鮮度に関してもアプリケーションに知らせることができるようになった
                              o 活用
                                    + バッチ系の処理
                                          # 集計
                                          # レポート
                                    + リアルタイム性の高いデータ分析
                                          # Redoがおいついていたら実行可能
                                                * 追いついてなければエラーを返す
                                                      o つくりこみになるが、スタンバイがだめならプライマリに問い合わせるようにする
                                                * 明示的に同期することもできる
                  # ダウンタイムの短縮
                        * ブロックメディアリカバリ
                              o Active DataGuard
                                    + 破損ブロックを自動的に修復
                                    + スタンバイ側に正しいブロックがあれば、そのブロックを置き換えて修復する
                                    + アプリケーションからは障害に気づかない
                        * Oracleのデータブロックが破損した場合をダウンと定義
                  # 高品質なデータの保護
                        * メモリ間の通信でRedoを転送
                              o 低帯域・低コスト
                              o Disk IO を必要としない
                              o 論理破損をスタンバイに転送しない
                        * 機能強化
                              o Redo転送の強化
                                    + プライマリでのRedo書き込みと同時にスタンバイへのRedo転送を開始する
                              o Redoの圧縮
                                    + Advanced Complession Opetion
                                    + メリット
                                          # データ保護の強化
                                                * 遠隔地への転送にかかる時間を低減する
                                                * 遠隔地への帯域が小さかった場合に効果
                                          # ネットワークコストの削減
                                                * 帯域が足りていても必要な帯域を抑えることができる
                                                * 通信事業との間でかわすランニングコストを低減できる
      o Oracle GRID Center
            + 検証結果
                  # データ保護
                  # Redo転送による性能オーバヘッド
                  # 圧縮性能
# ファイルシステムデータの保護
      o DBFS
            + Oracleの表領域をFileSystemとしてマウントできるようにした
                  # 現状はLinux限定
            + Data Guard との組み合わせで File System もミラーリングできるということがある