Comments
Description
Transcript
DB2 V8でのセールスポイント
® IBM Software Group 3. DB2 ＵＤＢ V8.2になったらどう変わる？ IBM Software Group | DB2 Information Management Software アプリケーションや設計を変更せずに、バージョンアップした場合の メリットを抜粋してまとめました。 2 IBM Software Group | DB2 Information Management Software V8になったらどう変わる？（V6,V7ユーザー共通） 運用編 運用の為の、計画停止が少なくなります。 オンラインユーティリティーが増え、各種パラメーターの動的が変更が出来るようになりましたの で、サービス停止時間が減ります。 例）オンラインLOAD、オンライン再編成、バッファープールの動的変更 LOADの同時実行ができるようになります。 LOADのロックの単位が表スペースから表単位になったので、同じ表スペースに存在する表に 対してもLOADを同時実行することが可能です。 IMPORTの同時実行が出来るようになります。 IMPORTのロックの単位が表単位ではなくなったので、同じ表に対して複数IMPORT処理を同 時実行することが可能です。 ユーティリティーの資源制御が出来るようになります。 スロットリングユーティリティーによってRunstatsやバックアップなどのユーティリティー実行時の 優先順位・資源制御を行うことが可能です。 db2diag.logのフォーマットが見やすくなります。 db2diagコマンドの提供 ログの管理が便利になります。 ログを含んだバックアップ機能やRecoveryコマンドの提供。ログマネージャーによるログ管理。 3 IBM Software Group | DB2 Information Management Software パフォーマンスチューニング編 "V7でチューニング時の課題点 ? メモリー・チューニング "３２BitではSharedMemoryの制約 ? AIX 1.75GB ? ＨＰ １ＧＢ ? SUN ３．３５ＧＢ "物理メモリーがあってもバッファー プールサイズを大きくしたり、分割 するには限界あった。 ? GUIツールは64ビットインスタンスでは 使用不可 "Java,Windowsなどのクライアント は32ビットしかサポートがなく、64ビ ットインスタンスに接続できない為 "V8での改良点 ? ６４ビットフルサポート "SharedMemoryからの開放 "32ビットクライアントからのアクセス 柔軟なバッファープールサイズ、個数 などメモリーチューニングの柔軟性 どんなインスタンスでもGUIツールの 利用が可能 4 IBM Software Group | DB2 Information Management Software "V7でチューニング時の課題点 ? パフォーマンス構成ウィザードやINDEX アドバイザーの効果、適用範囲 "入力条件不足により精度・効果が 上がらないケースがあった "V8での改良点 ? 構成アドバイザーの精度向上 ? 統合デザインアドバイザーの範囲 拡大 エキスパートによるチューニング と遜色のない効果が得られる ? スナップショット結果の見方にW/Lがか かる ? アクティビティーモニターによるグラフィカル 表示 ? snapshot関数の提供による定型化 ? イベントモニター結果の見方にW/Lが かかる ? 結果を表に出力が可能 ? パフォーマンスエキスパートによるイベント モニターのグラフィカル表示 分析作業の生産性向上 5 IBM Software Group | DB2 Information Management Software V７．２でどう変わる？（V6ユーザー用） バックアップの選択肢が増えます 増分バックアップ • フルバックアップに加え、前回取得バックアップからも差分更新分のみのバックアップが可能 ⇒更新量が少ないシステムでは、 − バックアップ時間の短縮 − バックアップテープ本数の削減 SAN対応DISKのバックアップ（ESS FlashCopyなど）にも対応 • • バックアップ時間の大幅短縮 災害対策へも対応が可能に ARCHIVE LOGコマンドサポート • • アクティブログをスィッチしてアーカイブログに切り替えるコマンドが提供 ARCHIVE LOGコマンドまでの完全なログファイル一式を取得可能に 6 IBM Software Group | DB2 Information Management Software タイプ2 索引とは 概要 V8で新規に作成する索引は新しいタイプの索引（TYPE2索引）となる V8で実装される新機能、オンライン再編成・オンラインロード・MDCの前提となる V7以前の索引(TYPE1索引）からのコンバージョンは索引の再編成で行う 索引のある表へのDELETE操作 DELETE対象の索引は擬似削除(Pseudo-Delete)状態におかれる "Deleted"のマーキングがされるのみで、物理的な削除はおこなわれない 例 ： 下記の表に対して次のようなSQLを発行 • • • • 1．Delete from tab1 where 列１ = 3 （未コミット） 2. 列１の値3にはPseudo-Deleteのマークがつけられる 3. Insert into tab1 values (2,Peach) 4. 列１の値5にNWロックをかけ、Insertは実行される 表 索引 Pseudo-Delete 列１ 列１ 列２ 0 0 Red 1 1 Blue 3 3 Green 5 5 Black 7 7 Yellow 10 10 White 2 Peach NWロック 7 IBM Software Group | DB2 Information Management Software 運用の考慮点 索引の再編成の必要性 DELETE対象の索引は擬似削除(Pseudo-Delete)状態におかれる “Deleted”のマーキングがされるのみで、物理的な削除はおこなわれない つまり、再編成を行わないと物理的に解放されない。 表の再編成の時に索引の再編成までは行わないので索引の再編成の 運用スケジュールを設計する 8