日本アイ・ビー・エム株式会社 ソフトウェア事業 IMテクニカル・セールス ICP ITアーキテクト 岡口 純子

Presentation on theme: "日本アイ・ビー・エム株式会社 ソフトウェア事業 IMテクニカル・セールス ICP ITアーキテクト 岡口 純子"— Presentation transcript:

1 日本アイ・ビー・エム株式会社 ソフトウェア事業 IMテクニカル・セールス ICP ITアーキテクト 岡口 純子
DB2 V9.5 最新技術情報 日本アイ・ビー・エム株式会社 ソフトウェア事業　IMテクニカル・セールス ICP ITアーキテクト　岡口　純子

2 Agenda 進化したワークロード管理 コンプライアンスの為のセキュリティー強化 これらを支えるアーキテクチャー変更
V9.5でのワークロード管理 コンプライアンスの為のセキュリティー強化 これらを支えるアーキテクチャー変更

3 進化したワークロード管理 とモニタリング

4 効率的なダイニングバー経営を目指して ２F ３F 受付 店長 フロア 予約客２F 予約客３F 予約の有無・人数など客層
予約のお客様の名前を確認。　満席時は待ってもらう 人数・客層に応じた席を判断 お客様 受付 グラスが空いたら、注文を聞く 予約なし カップル カウンター 飲み放題客は、呼ばれるまで行かない？2時間で宴会終了 予約なし 団体 個室 予約に応じて席を案内 注文・客層に応じたサービスレベル提供 予約客２F ２F ３F 予約客３F 店長 VIP Room 上客の突然の来店 予約の有無・人数など客層 フロア 特別なサービス

5 DB2 V9.5における新しいワークロード管理 Workload Service Class DB2 アプリケーションからの要求
各ワークロードが処理されるサービスクラスを定義 エージェントに割り当てられるCPUの優先順位、プリフェッチ要求の処理優先度の設定可能 各サービスクラスに対して様々な閾値を定義可能 予測した結果、閾値を超えるワークロードのSubclass変更 各接続は、事前定義の「ワークロード」に分類ユーザーIDで識別 DB2 アプリケーションからの要求 Superclass 1 Workload A Work Action Set Work Class Subclass A Workload B Work Class Subclass B Superclass 2 活動情報 Workload C Default User Class 各ワークロード、サービスクラスにおける稼動情報 実行時の統計情報 実行SQL、入力値 閾値を超えたときの情報 Default workload Default System Class システムによる要求 AIX WLM との連携可能 Workload Service Class

6 V9.5のワークロード管理では 予測とモニターを組み合わせた安定的な実行環境を提供
活動中のワークをモニターするための負荷の軽く、粒度の細かいモニター方法を実現 よりよいリソース管理 明示的にワーク間のリソースを配置 (CPU プライオリティー) 過度の、予想外のリソース消費を制限する(高負荷のクエリーのコントロール) よりよいリクエスト管理 ビジネス・プライオリティーベースのワーク管理 ワークのパフォーマンスのトラッキング エンドツエンドのワークロード管理ソリューション ①　ワークロードを分類 ②　実行環境を提供 ③　分類に応じた活動モニター 6

7 DB2 V9.5のWLMでどんなことが出来る？ 使用例 アプリケーション毎に優先順位の制御 “暴走”クエリーの制御 並列度の制御
“オンラインを優先させて、バッチ処理同時実行によるレスポンス低下を抑えたい” “月末の契約処理を優先させたい” “暴走”クエリーの制御 “あらかじめコストの高いSQLステートメントは停止したい” “モニタリング機能を使って、実行時間の長いSQLステートメントを特定したい” 並列度の制御 “事前に定義した接続数を超えると、キューに待機させたい” “部門ごとに重いクエリーは同時に一つだけにしたい” DB2 Thresholds can be used to control the behaviour of recognized activities. An activity is either recognized by DB2 WLM or unrecognized. A recognized activity participates fully in the new WLM capabilities while unrecognized activities only participate in basic service class mapping when they begin execution. Recognized activities in Viper 2: DML, DDL, CALL SQL statements, and LOAD utility. Unrecognized activities will become recognized in future releases as dictated by customer requirements.

8 サービスクラス毎のワークロード管理が可能
ワークロードのモニタリング DB2 Performance Expert　V3.1システム概要画面 KPI サービスクラス毎のワークロード管理が可能 それぞれのKPIに対してドリルダウンし、詳細を参照可能 それぞれのKPIに対して、対応策、Tipsなどの情報を参照可能

9 サービスクラス単位のワークロードのモニタリング

10 コンプライアンスの為の セキュリティー強化

11 DB2監査機能の機能拡張 監査対象のより詳細な指定が可能に オーディットパフォーマンスの向上
ユーザ、グループ、ロールの認証IDのリストを指定可能 特定な表オブジェクトを指定可能 信頼されるコンテキスト（後述）による監査も可能 オーディットパフォーマンスの向上 静的、動的SQLステートメントのより詳細な監査記録 コンパイル環境とSQLテキストを含み、オプションで入力データ値も含めることが可能 監査記録保持方法の改善 最大ファイル・サイズと保管場所の変更 DB2 for z/OSとの互換性の向上 11

12 DB2監査機能（db2audit）の新機能 要件 設定 対象 実行SQLを記録したい EXECUTE category TABLE
特定テーブルの 実行SQLを記録したい EXECUTE　category TABLE 特定権限の 管理者の操作を記録したい SYSADMIN category SYSADM権限 特定ユーザーの 表へのアクセスを記録したい CHECKING category USER 特定ロールの ユーザ認証を記録したい ROLE VALIDATE category

13 DB2監査機能（db2audit）の利用方法
① 取得データの決定 ポリシー作成：create audit policy オブジェクトとの紐付け：audit ② 監査機能の開始と停止 db2audit start / stop コマンド ③ 監査レコードの抽出 監査バッファーのフラッシュ、 db2audit flush コマンド 監査ログのアーカイブ db2audit archive 監査レコードの抽出、db2audit extract コマンド create audit policy SYSCAT.AUDITPOLICY audit SYSCAT.AUDITUSE db2audit start DB DB APPL audit buffer db2audit.log DB db2audit stop db2audit archive db2audit extract ASCII File 分析はユーザー tableなど

14 DB2 Audit management Expert
監査結果のレポート

15 Trusted Contextによるユーザー特定と監査
監査機能の向上 これまでは・・・ TRUSTED CONTEXTを使用すると・・・ すべて APPLUSERによる接続 アプリケーションサーバー DBサーバー TABLE A APP USER 人事 APP USER TABLE B 開発 誰がどの表にアクセスしたか監査可能 TRUSTED CONNECTION アプリケーションサーバー DBサーバー TABLE A APP USER 人事 人事 APP USER 開発 TABLE B 適切なアクセス権限 開発 SWITCH TRUSTED CONNECTION

16 これらを支える アーキテクチャー変更

17 V9.1までのアーキテクチャー プロセスモデル UNIX、Linux プラットフォームのDB2では、インスタンスやデータベースにおいて、DB2の作業を行うEDU（Engine Dispatcher Unit）は、インスタンス・ユーザーをオーナーとするプロセス群で構成 Process/Thread Organization UDB Client Library Common Client Per-instance Shared Mem & Semaphores, TCPIP, Named Pipes,… Per-application Log Disks Idle Agent Pool Logging Subsystem UDB Server Per-database Instance Level Idle, pooled agent or subagent Listeners db2agent (idle) db2tcpcm db2agent db2ipccm Coordinator Agents Database Level Write Log Requests db2agntp db2agntp Subagents EDUとは、DB2の作業を行う単位 Victim Notifications Async IO Prefetch Requests Active Idle Prefetchers Buffer Pool(s) Log Buffer db2pfchr Deadlock Detector db2loggr Page Cleaners Health Monitor db2loggw Parallel, Big-block, Read Requests db2dlock db2pclnr db2acd Parallel, Page Write Requests Data Disks FMP db2fmp

18 V9.5でのアーキテクチャー スレッドモデル V9.5からは、 UNIX、Linux プラットフォームにおいて、従来のようなプロセス・モデルではなく、db2syscプロセスが 1つ存在し、残りのEDUは db2syscプロセス配下にスレッドとして存在するアーキテクチャーに変更 Process/Thread Organization UDB Client Library Data Disks Common Client Subagents UDB Server Listeners Coordinator Agents Prefetchers Page Cleaners Per-instance Shared Mem & Semaphores, TCPIP, Named Pipes,… Per-application Log Disks Idle Agent Pool Logging Subsystem Per-database Instance Level Idle, pooled agent or subagent db2agent (idle) db2tcpcm db2agent db2ipccm V9.5からは、点線枠で囲まれた部分は、1つのプロセスとなる。各EDUは、スレッドとして存在して、 db2syscプロセスに紐づく。 Database Level Write Log Requests db2agntp db2agntp Victim Notifications Async IO Prefetch Requests Active Idle Buffer Pool(s) Log Buffer db2pfchr Deadlock Detector db2loggr db2loggw Parallel, Big-block, Read Requests Health Monitor db2dlock db2pclnr db2acd Parallel, Page Write Requests FMP db2fmp

19 スレッドモデルのメリット(1/2) モニターや監査の為の負荷軽減！ （軽いモニターを実現） パフォーマンスの向上 リソースの節約
スレッド間での情報引渡しは、プロセス間でのやり取りに比べれば、一般的に速い。 リソースの節約 EDUがプロセスだった際には、個別のプロセスで保持していた管理情報を、db2syscプロセスが持つメモリー空間で共有するので、情報の二重持ちがなくなる。 DB2の作業を行う複数EDUで情報を重複して持つことがなくなる。 スレッドでは、db2syscプロセスが持つメモリー空間上の情報を共有可能。 V9.1までは、EDUがプロセスとして存在していたので、個々にメモリー空間の割り当てを受け、処理に必要な情報を持っていた。 ファイル・ハンドル情報など。 EDU間で処理情報の引渡しを行う際に発生するオーバーヘッドが、プロセス間で行う場合に比べて少なくなる。 　アドレス・スペースのスイッチが不要。キャッシュあふれもない。 モニターや監査の為の負荷軽減！ （軽いモニターを実現）

20 スレッドモデルのメリット(2/2) メモリー管理の容易 自己チューニングメモリー（STMM）の機能拡張
インスタンス全体で消費されるメモリー量の把握が、従来より容易になる。 AUTOMATICに設定、動的に変更可能な構成パラメーターが増える。 エージェント間で情報が共有されるため、アプリケーション・グループ共用メモリーが不要になる。 自己チューニングメモリー（STMM）の機能拡張 アプリケーションも含めたメモリー管理を実現 V9.1までは、AIX、WindowsのみDATABASE_MEMORYのAUTOMATICが設定可能 V9.5では、Linux, Solaris, HP-UXにおいても、DATABASE_MEMORYが固定から、AUTOMATICの設定が可能。 [単純化されたマルチスレッド化アーキテクチャーにより総所有コスト (TCO) が減っている]

21 進化した自己チューニング・メモリー管理(STMM)
DB2 9.5 DB2が自動的にメモリー・チューニングを実施 管理者がメモリー・チューニングを実施する必要なし 予期しないワークロードを検知し、タイムリーにチューニング 対象がデータベース共用メモリーからアプリケーションが使うメモリーまで拡大 オペレーティング・システムのメモリ管理 V9.1までは共用メモリーまで管理 INSTANCE MEMORY DATABASE MEMORY APPLICATION 　 MEMORY Sorts & Hash Joins Buffer Pool 1 Buffer Pool 2 管理・調整対象が拡大 APPL 1 Lock List APPL 2 Package Cache

22 まとめ コンプライアンスを遵守した 安定したパフォーマンスの インフラを提供 より進化したワークロード管理
ワークロード別の優先順位・リソース制御 ワークロードを予測した事前制御 軽いモニターによる実行中のワークロード管理・制御 Design StudioによるWLM定義 Performance Expertによるモニタリング コンプライアンスの為のセキュリティー強化 きめ細かな指定による詳細な監査を実現 DB2 Audit management Expertによる監査レポート DB2 Encryption Expertによるコンテナー、バックアップの暗号化を実現 スレッドモデルへのアーキテクチャー変更 軽いモニター、軽い監査の負荷軽減 パフォーマンス向上 STMMによる容易なメモリーチューニング