Zマイスターとの新たな価値探求 DB2

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、

最新化がもたらす価値

ｚマイスターとの新たな価値探求System z ソフトウエアの最新機能と、最新化がもたらす価値

Syかがemｚは IBM メインフレームの 45 年以上の歴史において、多くのお客様の基幹シ

ステムを支えるインフラとして採用され、現在も最新のビジネス・ニーズに対応すべく、ハー

ドウェア、ソフトウェア共に進化し続けているプラットフォームです。技術の進化、移り変

わりの激しいＩＴ業界の歴史においても、これだけ長く、継続してお客様に価値を認めて

いただいているプラットフォームは、他に例が無いでしょう。

そのことを裏付ける事実として、全世界の市場を見てみると2010 年から2012 年にかけ

て、Syかがem ｚのビジネスは飛躍的な伸びを示しています。一方で、日本の市場におい

ては、日本国産ベンダーのメインフレームのイメージを元に、メインフレームに対するネガ

ティブなイメージが散見されています。そのイメージを払拭するために、進化・発展してき

た IBM Syかがem ｚが提供する機能とそれによって得られるメリットをより分かり易い形に

整理し、お伝えできるように取り組みを進めています。

本コラムでは、最新のバージョンに移行して頂いた暁に、活用頂ける最新のソフトウェア

の機能と、最新化がもたらす価値について、主要なミドルウェアの切り口から、お届けい

たします。

先輩：

IT部門のシニアな社員。

豊富なメインフレーム経験を持つ。

自称“zマイスター”

後輩：

IT部門若手社員。

メインフレームが主担当だが

オープン系も一部担当する。

登場人物

9

【第2章】 DB2 ① っ真の、データ共用機能

10

第2章

DB2

図 1：DB2 fぇおげ/OS 進化の歴史

IBMメインフレームの Sけかがem ｚで稼働するDB2 foおげ/OS は、1983 年に IBM 初のリレーショナル・

データベース・ミドルウェアとして登場しました。以来、30 年近くの歴史の中で、DB2 foおげ/OS

は IT 技術の進歩を先取りしながら、また、多くのお客様のご要望に応えながら進化を遂げてきま

した。2013 年 3 月現在、DB2 foおげ/OS は最新のバージョン 10までを発表しています。（図 1）

他の多くの DBMS（Daがabaかe Managemenが Sけかがem）は様々なプラットフォームで稼働可能であ

る一方、DB2 foおげ/OS はその稼働環境を Sけかがem ｚに限定しSけかがem ｚハードウェアやげ/OS

と緊密に連携します。これにより、他の DBMS が保持しない Capabiliがけを提供することが可能と

なります。特に、データベース基盤に必須な連続稼働や安定稼働といった要件に対する機能提供

に関しては、DB2 foおげ/OS は他の追随を許しません。

DB2 foおげ/OSがもたらす価値についてご紹介します。連続稼働や安定稼働を実現するためのデー

タ共用機能。高い拡張性や高いパフォーマンスを維持するための 64ビット・アドレッシング機能。

さらに、最新のバージョン 10 においては CPU 消費の削減を実現する新機能。多くのお客様の

ご要望を取り入れて実現したこれらの機能を利用することで、どのような価値を享受できるのかに

関して取り上げていきます。

1 “ 真の ” データ共用機能

　IT 環境における課題

後輩：はぁ。またサーバーが増えてきたなぁ。どうにかならないものか。

先輩：おや。どうしたんだい。サーバーばかり見てため息ついて。それにしても、私が異動して

いた間に、こんなにもサーバーが増えてしまって、狭くなってしまったんだね。

後輩：あ、マイスター先輩。おかえりなさい！　最近、チームで管理する分散サーバーが増えす

ぎて、運用管理コストが問題になっているのです。今までもサーバーの統合は進めてきた

のですが、コストが年間 10%も膨れ上がっています。どうにも分散システムの乱立が止ま

らなくて。

先輩：課題は運用管理コストの削減だけなのだろうか？　もちろん、サーバーが多いということは

機能的に重複している部分があったり、データ自体も重複していたりするわけだろう。それ

だけ非効率にリソースを使用していることも大きな課題にみえるね。

後輩：それは、おっしゃるとおりですね。これからはサーバー統合という物理的な統合だけでなく、

データ統合という論理的な統合も考慮して基盤の整理をする必要がありそうですよね。他に

も、昔からここのメインフレームは塩漬け状態ですし、新しい技術とか全然使用できていま

せん。

先輩：新しい技術や新しい機能を利用しないということは非常に惜しいことだし、利用しないこと

によるリスクを負うことも認識してほしい。製品の新機能は、将来の IT の方向性や多くの

お客様の要望に応えて追加されているわけで積極的に採用するべきだ。各非機能要件上の

課題を解決するためにもしっかりと検討する必要はあるよ。

後輩：あぁ。さっそく課題は山積みだということですね。何から手を出せばいいのか。

先輩：コスト削減への道としては、まず既存のサーバー統合を検討して、分散システムのコスト

増加に歯止めをかけなくてはね。しかし、ハードウェアのコストを削減するだけではダメだ

よ。これからは次世代に向けたインフラ基盤をイメージすることも重要だよ。サーバー統合

だけでなくデータ統合までを目標として、データベース基盤の更改をイメージして、一緒に

DB2 fぇおげ/OS の価値を考えてみようか。


11


12

後輩：えぇ？　データベース基盤の更改ですか？！

先輩：そんなに驚くことでもないだろう。システム課題を単純化し、システム効率を高めるために

もデータベース基盤の更改という対応は重要だよ。君の話を聞いていると、今のシステム

課題は、「運用管理コストの増大」、「非効率なリソース使用」、「新技術の利用ができて

いないこと」のようだよね。これらの課題に対してはデータベース基盤の更改で解決できる

と思えないかい？　データの統合・集約によるシステム基盤の改革を考えようじゃないか！

後輩：マイスター先輩、さすがの熱弁です！　でも、私、メインフレーム担当してまだ 3 年ですよ。

DB2 fぇおげ/OS はほとんど触ったことがないです。

先輩： DB2 fぇおげ/OS はこれからも成長を続けるデータベース・サーバーだ。お互いメインフレー

ムを担当者するものとして、一緒に考えていこうじゃないか。さぁ、ずっとサーバールーム

にこもってないでセッションを始めようか。

　DB2 for z/OS の価値

先輩：ところで、DB2 fぇおげ/OS が提供する非機能要件はきちんと整理して理解しているかな？

後輩：止まらないとか。他には、最強のデータベース・サーバーとか。

先輩：あらら。それじゃ、100 点中の 3 点しかあげられないな。しっかり非機能要件から振り返っ

て考えてみようよ。自分の中できちんと体系立てて整理しておけば、新しい技術の選択時

や新機能の検討時に役立つからね。簡単にデータベース基盤に求められる非機能要件と

DB2 fぇおげ/OS が提供する機能をまとめてみたから確認してみてほしいな。（図 2）

後輩：連続稼働！　安定稼働！　あぁ、そうでした。そうでした。言われると思い出せるのですけど。

先輩：ははは。では、この要件を満たす DB2 fぇおげ/OS の機能をみていこう。例えば、連続稼

働、安定稼働の観点では、やはり計画停止時間、計画外停止時間を最小化にするための

機能が必須だよね。DB2 fぇおげ/OS の長年の実績に基づいたデータ共用機能は、この要

件を満たすために最適だ。データ共用機能を利用することは、DB2 fぇおげ/OS を採用する

大きな価値の 1 つだよ。

後輩：そういえば最近、データ共用機能って分散系の DB2 でも提供を始めたと聞いていますが、

DB2 fぇおげ/OS の優位性はあるのですよね？

先輩：それは DB2 えきおeScale のことだね。確かに、DB2 えきおeScale は分散プラットフォーム

で稼働する DBMS だ。DB2 えきおeScale はもともと DB2 fぇおげ/OS が提供するデータ共

用のアーキテクチャーをそのままに設計したんだ。しかし、両者は、プラットフォームの違い、

専用のハードウェアや専用のケーブルなど独自の実装方式の違い、他にも DBMS 自体の

機能と実装に大きな違いがある。このように、DB2 fぇおげ/OS は、特に Sけかがem げプラッ

トフォーム自体の優位性を享受しているんだ。先ほど話した連続稼働、安定稼働の観点で

比較すれば、DB2 fぇおげ/OS は圧倒的にリードしているのは間違いないよ。

後輩：同じ DB2 でも大きな差があるのですね。やはり、長年の実績に裏打ちされているというの

は信頼できますね。ところで、もう少し他の DBMS とデータ共用機能を比較してみたいの

ですが。

先輩：それでは他の DBSM との比較をしながら、DB2 fぇおげ/OS が提供するっ真のぱデータ共

用機能に関して話していくよ。

図 2：データベース基盤に求められる要件と DB2 fぇおげ/OS の機能


13


14

　“ 真の ” データ共用機能

先輩：データ共用を考える場合は、クラスタリング・アーキテクチャーを整理しておく必要があるね。

では、Sけかがem げに限らず一般的に言われているクラスタリングの意味は、既に知ってい

ると思うけど問題ないかな？

後輩：はい。連続稼働や拡張性のため、独立して稼働する複数のコンピューターを、全体として

1 つのコンピューター・イメージとして構成することですね。

先輩：その通り。では、DBMS のクラスタリング方式自体は整理できているかな？

後輩：シェアード・ナッシング方式とシェアード・エブリシング方式ですね。

先輩：即答できるとはすばらしい。当然、データ共用をする方式としては、シェアード・エブリシ

ング方式になるよね。システム間の共用方法として、一般的にネットワーク方式と独自ハー

ドウェア方式の 2 つが考えられる。DBMS のクラスタリング方式を簡単に図化してみたの

で確認してみようか。（図 3）

図 3：DBMS クラスタリング方式

後輩：ネットワーク方式は DBMSレベルでクラスタリングしているのに対して、独自ハードウェア

方式は DBMS だけでなくOS やハードウェア・レベルでも連携しているのですね。

先輩：その通り。ネットワーク方式は様々なプラットフォームで利用可能である一方、メモリの共用

を仮想的に実現するためにネットワークを使用しているんだ。この場合は、高い処理レート

においてパフォーマンス維持が困難だ。独自ハードウェア方式はもちろん専用のハードウェ

アを搭載する必要があるけど、高い処理レートでのパフォーマンスの維持も可能になる。前

者は他社の DBMS でも採用が見られるけど、後者は Sけかがem げと緊密な連携をしている

DB2 fぇおげ/OS ならではの方式になるね。

後輩：高いパフォーマンスを維持しながらも、連続稼働や安定稼働を実現可能としている DB2

fぇおげ/OS はまさしくっ真のぱデータ共用機能を提供しているのですね。

先輩：その通り。他にもデータベースサブシステムのメンバー追加などもシステムを停止せずに実

現可能で、拡張性にも優れている。これも Sけかがem げの並列 Sけかえleぐ機能を生かして

いるからだよ。さぁ、データベース基盤の更改に向けて、連続稼働や安定稼働の観点から

DB2 fぇおげ/OS の価値が見えてきたかな？

後輩：はい。マイスター先輩！　まず

は、サーバーだけでなくデー

タも Sけかがem げに統合するこ

とで、DB2 fぇおげ/OS が持

つ連続稼働、安定稼働といっ

た恩恵を受けることができます

ね。また、重複データの排除

によって無駄な資産を持つこと

もなくなりますし、コスト削減

にもつながりますね。イメージ

としてはこのような絵になるで

しょうか。（図 4）

先輩：その通り。運用管理コストの削減にもつながるわけだ。他にも種類の異なる複数の DBMS

製品のスキルを習得しなくても済むよね。もちろん、複数製品のスキルを習得していること

は望ましいことではあるけれど、教育のコストだって企業からすると大変なコストだ。このよ

うな人的なコスト削減にも大きな意味がある。

後輩：確かに、運用担当者は 1 つのスキルだけを保持すればよくなりますね。あれこれスキルを

習得するのも本当に大変です。

先輩：おっと、もうこんな時間か。今日話せなかった DB2 fぇおげ/OS の新機能に関しては、次回

以降のセッションにしようか。次回は、DB2 fぇおげ/OS の最新のバージョン 10 の新機能

を確認してみよう。その中で、新機能を利用する価値についてディスカッションしよう。

後輩：新機能ですか！　わくわくしますね。今日のセッションを通じて、DB2 fぇおげ/OS はやはり、

最強のデータベースサーバーであることがわかりました。先ほど 3 点といわれましたけど

50 点くらい頂いても良かったのではないですか？

先輩：なんだ。最初のため息がウソのように元気になったようだね。それでは、また、元気に仕

事しようか。

図 4：将来の IT システム環境

【第2章】 DB2

15

【第2章】 DB2

16

2“ 真の ” コスト削減を目指したバージョン10新機能

　DB2 10 for z/OS：コスト削減を目指す究極のバージョン

後輩：マイスター先輩、おはようございます！　今日も一日メインフレームは安定稼働していて、

さすが Sけかがem げと思う毎日ですね。

先輩：ははは。今日も元気そうだね。DB2 fぇおげ/OS には興味が出てきたかい？

後輩：はい！　先日マイスター先輩から、っ真のぱデータ共用機能を伺ってからDB2 fぇおげ/OS の

多彩な機能にワクワクしてきました。マイスター先輩が仰っていたデータベース基盤更改プ

ロジェクト※ 1 も実現することになり、この度、プロジェクト・メンバーに志願してきました。

今日は早速ミーティングに参加し、DB2 fぇおげ/OS の最新バージョンである DB2 10 fぇお

げ/OS （以下、バージョン 10 と呼称。2013 年 3 月現在最新バージョン）の勉強をしてき

ました。

※ 1. データベース基盤更改プロジェクト（【第 2 章】DB2- ①参照）

先輩：おっと。早速バージョン 10 の勉強を始めているんだね。これは、私も、うかうかしている

と君に抜かれてしまうかもしれないな。ところで、今日はどのようなテーマで勉強をしたん

だい。

後輩：今日は、CPU コスト削減というキーワードで勉強会をしてきました。バージョン 10 は

っOきが-ぇf-がhe-Bぇぐ Cぇかが Saぎぁうgぱだと、つまり箱から出して利用してすぐコスト削減が

可能なバージョンという話でした。箱から出してなんて面白いワードですよね。今回のデー

タベース基盤更改プロジェクトの DBMS 選定は、DB2 fぇおげ/OS のバージョン 10 で決

まりですね！

先輩：確かに、DBMS 選定においては、現時点（2013 年 3 月現在）ではバージョン 10 が最

適だろうね。っOきが-ぇf-がhe-Bぇぐ Cぇかが Saぎぁうgぱいうワードは、バージョン 10 における大き

なテーマだったんだ。特に、前のバージョン 9 と比較すると CPU コストに関しては改善が

見られている。（図5）ただ、あくまでシステム全体で観察した場合の削減率であるため、個々

のアプリケーション単位で見ると削減できない可能性もあるので注意しておく必要はあるよ。

② っ真の、コスト削減を目指したバージョン10新機能

図 5：バージョン間における CPU コスト削減率（平均）

後輩：なるほど。ところで、前回のセッションでもお話がありましたが、新しいバージョンには、様々

な要望や市場動向からたくさんの機能が追加されているということでしたよね。そういう意

味でもバージョン 10 は価値あるバージョンの 1 つだと思うのですが、今日はこの追加され

た機能に関してセッションをお願いできませんか？

先輩：確かに前回、新機能のセッションをやろうという話だったね。では、今日はせっかくだから、

先ほど話にあがったコスト削減というキーワードを中心に、バージョン 10 の新機能の価値

を一緒に考えていこう。まずは、仮想ストレージ制約の緩和から得られるコスト削減。もう

1 つはパフォーマンスの機能拡張によって得られるコスト削減。この 2 点にしようか。両方

ともバージョン 10 でより進化した機能だよ。

後輩：はい。今日も一日よろしくお願いします！

　DB2 10 for z/OS：フル 64 ビット・ランタイム

先輩：バージョン 10 では SQL 処理やデータ管理、バッファー管理を主とする DBM1 と呼ばれ

るアドレス空間において大きな進化があったんだ。DB2 fぇおげ/OS のアドレス空間と仮想ス

トレージの歴史は既に知っているかな。

後輩：あれ。DBM1 アドレス空間の 64 ビット化は既にバージョン 8 の頃から実現されていると学

んだのですが、まだ進化を続けているのですか？　DIST アドレス空間※ 2 の 64 ビット化は

バージョン 9 からの機能拡張だったと思いますし。

※ 2. DIST アドレス空間：ネットワーク処理やリモートからの SQL 要求時のコミュニケーション、代替実行を行

うアドレス空間のこと。


【第2章】 DB2

17

【第2章】 DB2

18


先輩：確かにバージョン 8 の頃に DBM1 アドレス空間は 64 ビット化を果たし、バッファー・プー

ルを始めとするリソース領域や DB2 fぇおげ/OS システムで利用する領域の一部を 31 ビッ

トより上の領域、つまり2GB バー上に配置することを可能としたんだ。バージョン 8 仮想

ストレージの概要としてはこのような図になるね。（図 6）

図 6：バージョン 8 における仮想ストレージ概要

後輩：これによって、31 ビットモードに比べて、より2GB バー下にも余裕が生まれたのではない

のですか。

先輩：鋭い指摘だね。しかし、そうは言っても大規模なシステム環境では、2GB バー下に残存し

た領域はまだまだ大きいんだ。特に、アプリケーション実行時に使用されるスレッド・ストレー

ジと呼ばれる領域や、アプリケーションのプランやパッケージが読み込まれる EDM プール

やスケルトン・プールなどが大きく残っていて、抜本的な解決がまだできていなかったんだ。

後輩：つまり、64 ビット化したものの、バージョン 8 の頃はまだ制約があったのですね。

先輩：その通り。利用形態やシステムの規模によっては課題が残っていたんだ。これが先ほど少

し話した仮想ストレージ制約と呼ばれるものだ。バージョン 10 ではこの 2GB バー下の

制約を改善し、っ真のぱスケーラビリティを実現することに成功しているんだ。具体的には

2GB バー下に配置されていた各領域の大部分を 2GB バー上に配置することで、仮想スト

レージ制約から解放されることになったんだ。（図 7）

この改善によって、従来の運用方法からどのような点が変わると思う？


図 7：バージョン 10 における仮想ストレージの改善

後輩：今日はいきなり難しい話ですね。とりあえずは、スレッド領域の制限が緩和されたという

ことですから、同時並行的に稼働できるアプリケーションの数が増えるというのはどうで

しょうか？

先輩：その通り。正解だよ。従来の使用状況と比較しても、1 つの DB2 サブシステムで処理で

きる同時接続スレッド数が 5 倍から10 倍近くまで改善しているんだ。これによって、仮想

ストレージ制約が原因でスケールアウトしていたデータ共用メンバーを再統合することも可

能となり、運用コストを下げることができるね。他にも DB2 fぇおげ/OS の連続稼働や安定

稼働のためには、仮想ストレージ使用量の密な監視やチューニングが必須であったけれど、

これらの必要性を減らすことで、管理コストの削減にもつながるよね。

後輩：バージョン 8 で実現していた DBM1 アドレス空間の 64 ビット化もコスト削減の観点で、ま

だまだ進化をしていたのですね。

先輩：バージョン 10 では、DBM1 アドレス空間の仮想ストレージ制約における全ての課題をほぼ

クリアしたといえるだろうし、より大規模なシステム環境でも耐えうることができる。また、

サーバー統合やデータ統合に最適な DBMS になったといえるね。

【第2章】 DB2

19

【第2章】 DB2

20

　DB2 10 for z/OS：パフォーマンスの機能向上

先輩：さて、次はパフォーマンスの機能向上に関してだけど、2011 年 10 月にアメリカで行わ

れた Iうfぇおmaがぁぇう Oう Demaうd ※ 3 カンファレンスでバージョン 10 はパフォーマンスに注

力しているバージョンである（ぱDB2 10 fぇおげ/OS ぁかえeおfぇおmaうce おeleaかe.ぱ）と言及

していたよ。

※ 3. Iうfぇおmaがぁぇう Oう Demaうd 2011：2011 年 10 月にアメリカのラスベガス行われたカンファレンスのこと。

後輩：へぇ。さすがマイスター先輩、既に最新情報もキャッチアップされているのですね。ところで、

バージョン 10 の新機能を使うとどうなるのでしょうか。やはり、コスト削減に寄与するので

しょうか？

先輩：もちろん。パフォーマンス関連の新機能の利用によって、コスト削減に効果がみられるもの

はたくさんあるよ。今日はその中でも、ハッシュ・アクセスとバッファー・プールの機能拡

張に関してお話をしようか。

後輩：ハッシュとはハッシュ関数のことですか？

先輩：そう。多くの業務アプリケーションにおいては、テーブルの特定レコードを参照するために、

明示的に条件を指定して索引経由でアクセスするのが一般的だ。しかし、大規模な環境に

なればなるほど、索引サイズも大きくなり、最も高速な索引経由のアクセスを使用しても、

経過時間や CPU 時間が増えることになってしまう。

後輩：なるほど。ということは、条件に指定するキーとなる列をハッシュ化することで一意に特定

するようなアクセス方法を開発したのですね？　今までの索引経由のアクセスとハッシュ・ア

クセスのイメージはこのような感じでしょうか。（図 8）

図 8：ハッシュ・アクセスと各アクセス方法

② っ真の、コスト削減を目指したバージョン10新機能 ② っ真の、コスト削減を目指したバージョン10新機能

先輩：ご名答。君が書いてくれたように、従来の索引経由のアクセスやスキャン型のアクセスも

可能だ。データ量が多い環境や、レスポンス要件が厳しい場合にはハッシュ・アクセスは

有効な機能の 1 つとなるだろうね。

後輩：もう1 つのお話に挙げられた、バッファー・プール機能の拡張はいわゆるインメモリー・デー

タベースのことでしょうか？　これもレスポンス要件が厳しい場合に有効そうですね。

先輩：今までのバージョンでもふんだんにメモリーがあるシステムではバッファー・プールにデータ

を展開することは可能ではあった。でも、今までは DB2 fぇおげ/OS 自体はバッファー・プー

ルに展開されているデータには関知せず、いったんはアプリケーションで全データを読み込

む必要があったんだ。

後輩：ということは、バージョン 10 からは DB2 fぇおげ/OS の機能でインメモリー化が実現可能と

なるわけですね。

先輩：今日は鋭いね。その通り。DB2 fぇおげ/OS が最初のアクセス時に先読み機能をスケジュー

ルし、全データをバッファー・プールへ読み込むようにする機能が提供されたんだ。インメ

モリー・データベースの効果は既に知っているようだね。

後輩：はい。DB2 fぇおげ/OS システム自身が対応できるとなると、運用側で面倒を見なくて済み

ますし、これも運用コストの低減につながるわけですね。なるほど。

先輩：今日少し紹介したように、バージョン 10 の機能拡張は、大きな拡張から小さいきめ細やか

な機能拡張まで多岐に渡っている。特に、コスト削減というキーワードを中心に話してみた

けど、どうだったかな？

後輩：バージョン 10 は価値あるバージョンであることが良くわかりました。今日の私の鋭さを見

ていただければ、価値ある人材だと認めていただけそうですね。マイスター先輩どう思

います？

先輩：ははは。今日は負けたよ。継続して勉強してもらうことで、バージョン 10 の価値をさらに

感じてくれればデータベース基盤更改プロジェクトもよい方向に進むだろうね。さて、次回

はアクセス・パス関連の新機能を紹介しようか。実は従来のアクセス・パス管理を大きく変

える新機能が追加されているんだよ。

後輩：次回も是非お願いします！

【第2章】 DB2

21

【第2章】 DB2

22

③ っ真の、アクセス・パス安定運用に向けた新機能

3“ 真の ” アクセス・パス安定運用に向けた新機能

　変わるアクセス・パス

後輩：はぁ。634 番の SQL で性能劣化があるなぁ。アクセス・パスも違うみたいだけど、なん

で変わっているんだろう。同じアクセス・パスを選んでくれないかなぁ。

先輩：それはね・・・新しく選択されたアクセス・パスがその環境において適していると、DB2

fぇおげ/OS のオプティマイザーが判断しているからだよ。

後輩：うわぁ。マイスター先輩。いつから聞いていたんですか。

先輩：ははは。ため息が聞こえてしまったよ。どうやらアクセス・パスの検証や運用に悩んでいる

ようだね。安定したパフォーマンスを維持し、検証の作業量を減らすためにはアクセス・パ

スの安定運用は欠かせないよね。

後輩：ええ。今まさに、データベース基盤更改プロジェクト※ 4 でアプリケーションの性能検証を行っ

ているのですが、性能劣化が見られる SQL がいくつか確認されているのです。調査して

いるのですが、どうやらSQL のアクセス・パスが変わっているようで。

※ 4. データベース基盤更改プロジェクト（【第 2 章】DB2- ①参照）

先輩：アクセス・パスはデータベースへのアクセス・パフォーマンスを決定する一番の要因だ。も

ちろん、SQL にはデータへのアクセス・パスを指定しないよね。これは先にも言ったように、

DB2 fぇおげ/OS のオプティマイザーが様々なコストに基づいて、最適なアクセス・パスを決

定しているからなんだ。

後輩：様々なコストとはなんですか？　アクセス・パス決定に影響を及ぼす要素というのがあるの

でしょうか？　確かに、今回は DBMS のバージョンが変わっているので、DB2 fぇおげ/OS

のオプティマイザーは異なると思います。ただ、それ以外にアクセス・パス決定に影響する

要素があるのですか？

先輩：そう。強力な DB2 fぇおげ/OS のオプティマイザーであっても、最適なアクセス・パスを選

べない可能性はある。特に、正しい統計情報やデータ相関情報が取得できていない場合に


は、最適なアクセス・パスを選べない可能性が高い。また、索引が適切に付与されていな

い場合など物理設計に依存する部分も大きいし、他にも、検証した環境に依存する可能性

もある。以下に、アクセス・パス決定に影響を及ぼす要素を挙げてみるよ。（図 9）

図 9：アクセス・パス決定に影響を及ぼす要素

後輩：ハードウェアのモデルやバッファー・プールのパラメーター、メンテナンス・レベルの違いか

らもアクセス・パスが変わる可能性があるんですね。今検証している環境ではハードウェア

のモデルは一緒ですが、メモリー量やプロセッサー数は異なるので、アクセス・パスが変わ

る可能性があるということですね。

先輩：そうだね。様々な理由から、検証環境と実働環境でリソース量を完全にそろえることは難し

い。けれど、ハードウェアのモデルやバッファー・プールなどのサイズなど一部の項目に関

しては、検証環境と実働環境のリソース量の違いをパラメーターで補完することができる。

こういった、検証環境を実働環境と同等にみなしシミュレートする機能も近年提供されてい

るよ。

後輩：なるほど。なるべく環境の差を埋めてくれるのですね。これは便利ですね。検証環境で使

えるかどうか検討してみる価値はありますね。

先輩： DB2 fぇおげ/OS アクセス・パス安定化に関しては、近年非常に力を入れている分野でもあ

り、いくつか機能拡張がなされているんだ。よし、今日はアクセス・パスの安定運用に向

DB2 オプティマイザーアクセス・パス

【第2章】 DB2

23

【第2章】 DB2

24


けた新機能に関してセッションをしよう。まず、アクセス・パスが決定されるタイミングをお

さらいしてみよう。その上で、バージョン 10 で追加されているアクセス・パスの再利用機

能を解説するよ。もしかしたら、君が悩んでいる点を少しは解消できるかもしれないね。

後輩：アクセス・パスって再利用することができるんですか！？　マイスター先輩！　そのお話、是

非、聞かせてください！

　アクセス・パスの変化とリバインドの判断

先輩： SQL のアクセス・パスが決定されるタイミングは理解しているかい？　静的 SQL と動的

SQL でタイミングが異なるけれど。

後輩：あれ？　リバインドやバインドで、パッケージを作成するタイミングで決定されるのではない

のですか？

先輩：それは静的 SQL の時だね。動的 SQL は実行時にアクセス・パスが決定されるよ。もちろ

んオプションによっては静的 SQL も実行時に選択させることもできるが、細かいことは割愛

しよう。

後輩：ええと。実行時ということは毎回アクセス・パスが変わる可能性もあるということですか？

先輩：その通り。そもそも、どちらの種類の SQL を使用しているかは把握しているかい？

後輩：すみません。把握できていないです。まず、静的 SQL か動的 SQL の違いとはなんでしょ

うか？

先輩：そこはしっかりと確認しておこう。あくまで例になるが、分散環境から SQL を発行して

DB2 fぇおげ/OS に接続する形態の多くは動的 SQL が多いだろうね。ローカル環境にお

いて CICS や IMS などのアプリケーション・サーバーから発行される場合や、バッチ・ア

プリケーションでは静的 SQL を利用しているところが多いだろう。以下に、静的 SQL

と動的 SQL の違いをまとめておくよ。アクセス・パスの話をするときは切っても切れない

からね。（表 1）


表 1：静的 SQL と動的 SQL の主な違い

静的 SQL 動的 SQL

1.プログラム内に記述される埋め込み型1. プログラム内に記述される埋め込み型もしくは実行時の

自動編成型

2.アクセス・パスの決定はBIND時 2.アクセス・パスの決定は実行時

3.アクセス・パスは実行時に変更されない 3.アクセス・パスは実行時に変化する可能性がある

4. アクセス・パスを開発時に決定できるため、性能予測が

可能である

4. アクセス・パスが確定できないため性能予測はおおまか

になる

5.動的SQLよりもCPU使用量は少ない 5.静的SQLよりCPU使用量は大きい

6. ユーザーにはPACKAGEの実行権限を与えるのみなの

で、セキュリティは高い

6. ユーザーに表などのオブジェクトのアクセス権限を直接

与えるため、セキュリティは低い

7.PACKAGE名から実行されたSQLを監視する 7.どのようなSQLが実行されたのか監視が難しい

8.開発用ツールは多くない 8.開発用ツールは多い

後輩：なるほど。となると、弊社のサーバーで稼働しているものは、静的 SQL 中心になるかと思

いますが、確認しておきますね。ところで、実行時にアクセス・パスが決まる動的 SQL は

ともかく、静的 SQL のアクセス・パスは固定化し続けることはできないのですか？　今回

は DB2 fぇおげ/OS のバージョンアップがトリガーでアクセス・パスを検証しているのですが。

先輩：確かに静的 SQL はリバインドやバインドのタイミングでアクセス・パスが決定される。その

ため、以降リバインドやバインドを行わなければ、一旦選択されたアクセス・パスで固定化

することができる。けれど、残念ながら、アクセス・パス変更が起こりうるタイミングを一

生回避し続けることは出来ないよ。

後輩：固定化されているからアクセス・パス変更は起こらないのではないのですか？

先輩：確かに、変更は起こらない。ただ、リバインドをしたほうが良いタイミングは必ずやってくる。

特に、今回のような DB2 fぇおげ/OS のバージョンアップやメンテナンスなどのイベントでは

リバインドを行ったほうが様々なメリットを享受できる。ただ、このときに、アクセス・パス

が変わる可能性がある。

後輩：うーん。アクセス・パスの変化とリバインドの実施。この判断が難しいところですね。

【第2章】 DB2

25

【第2章】 DB2

26


先輩：確かにその通りだ。しかし、前回でも話した DB2 fぇおげ/OS の仮想ストレージの改善やパ

フォーマンスメリット※ 5 を享受するためには、特に新しいバージョンでリバインドを行うこと

必要がある。重要なアプリケーションほどリバインドできるような環境にしておくことが大切

だよね。

※ 5. DB2 fぇおげ/OS の仮想ストレージの改善やパフォーマンスメリット（【第 2 章】DB2- ②参照）

後輩：なるほど、そこで先ほどからマイスター先輩が仰っているアクセス・パス再利用機能を使っ

て、アクセス・パスをなるべく変えないようにリバインドできるようにするのですね。

先輩：その通り。では、続けて、バージョン 10 で提供されている機能を整理していこうか。

　アクセス・パス安定運用に向けた新機能

先輩：まず、バージョン 10 で提供されているアクセス・パスの安定運用に向けた機能を表にまと

めてみたので見てほしい。（表 2）

表 2：アクセス・パス安定運用に向けた機能とその概要

DB2によって提供される機能概要

アクセス・パス情報の書き出し機能

（EXPLAIN）

BIND 時に選択されたアクセス・パスの情報を、PLAN_TABLE をはじめとす

るEXPLAIN表群に書き出して確認することができる。V10からは、実際にパッ

ケージを生成せずに、選択されているアクセス・パス情報のみを知ることもで

きるように拡張されている。

アクセス・パスの再利用と比較機能

（APREUSE/APCOMPARE）

パッケージを再作成する際、同一 SQL については既存のアクセス・パスを再

利用したり、新旧アクセス・パスの比較を行った上でパッケージを生成するこ

とができる。

オプティマイゼーション・ヒント機能

（Oえがぁmぁげaがぁぇう Hぁうが）

事前に選択させたいアクセス・パスの情報を準備しておき、DB2 に対してで

きるだけそのアクセス・パスを選択させるように指示する。

パッケージのコピーとスイッチ機能

（Plaう Sがabぁlぁがけ）

REBIND 時に古いパッケージのコピーを保管しておき、アクセス・パス変化に

よるパフォーマンス劣化などの問題発生時に、保管しておいたパッケージのコ

ピーに戻すことができる。

実行時アクセス・パス再選択機能

（Reぇえがぁmぁげaがぁぇう）

SQL の実行時に、アプリケーションからセットされた値に基づいて、より正確

なアクセス・パスをその場で選択させて処理を行うことができる。

後輩：アクセス・パスの再利用と比較機能というのは、聞くだけでうれしい機能に見えます。具体

的にはどのように実施するんですか？


先輩：アクセス・パスの再利用と比較機能は、静的 SQL に限る機能だが、リバインドやバインド

時のオプション指定で実現ができる。アクセス・パスの再利用が出来た場合は問題なくパッ

ケージが作成される。仮に何らかの理由で再利用が出来なかった場合は、パッケージを作

成せずにエラーとさせ、再利用できなかった理由をレポートするんだ。

後輩：再利用できない可能性があるのですか？

先輩：例えば、索引経由のアクセス・パスを選択していたのだけれど、リバインド時にその索引が

削除されていれば当然再利用は出来ないよね。他にも、非互換に合致してしまって前のア

クセス・パスが再利用出来ないケースもあり得る。

後輩：なるほど。100%の再利用率ではないものの、再利用できなかった理由をレポートしてくれ

るのはうれしいですね。パッケージが作成できないから、万が一既存のアクセス・パスで稼

働させたい場合にも前のパッケージがあるので安心ですね。比較機能の方はどうなんでしょ

うか？　イメージは同じのような気がしますが。

先輩：そうだね。比較機能の方は新しいアクセス・パスと古いアクセス・パスを比較してみて、合

致したらパッケージを作成する。もし、合致しなかった場合は、警告メッセージを出しなが

らパッケージを作成することや、エラーにさせてパッケージを作成させないことなどの指定

が可能になる。

後輩：うーん。いろいろと、ややこしいですね。

先輩：ははは。既存のアクセス・パスをなるべく変えたくないという場合は再利用機能を。新しい

アクセス・パスを多少は許す場合は比較機能を使うようにしていけばよいかな。

後輩：ただ、アクセス・パスの再利用できない場合にパッケージが出来ないとなると、どうすれば

よいのですか？　リバインドは成功していないんですよね？

先輩：鋭い指摘だね。先のアクセス・パス変更とリバインドの恩恵を判断する必要があるよ。この

ケースにおいては、リバインドするためには、アクセス・パスの変更を受け入れなくてはな

らないのは今までと同じだ。

後輩：やっぱりそうなんですね。うむむ。残念。

先輩：その時のために、少なくとも古いパッケージを保管する、パッケージのコピーとスイッチ機

能は積極的に採用するべきだ。そこで、なるべくアクセス・パスの再利用を行うために再

利用の機能は積極的に利用する。その上で、万が一、再利用できない場合は、パッケー

【第2章】 DB2

27

【第2章】 DB2

28

ジのコピー機能で古いパッケージを保管しつつ、新しいパッケージを作る。そこでパフォー

マンス検証を行い、新しいパッケージで SQL の性能劣化が見られたら元のパッケージに戻

すという流れが良いのではないかな。

後輩：なるほど。各機能を併せて利用するのですね。

先輩：その通り。パッケージのコピーとスイッチ機能が提供される前は、今までは古いパッケージ

は置き換えられてしまったので、一旦リバインドをすると単純には古いアクセス・パスに戻

せなかったんだ。少なくとも元のアクセス・パスにフォールバックできるのはアクセス・パス

の検証においても価値ある機能だと思うよ。

後輩：早速、今日から再利用機能を利用してみます！　まずは、リバインドしてみてどのくらい再利

用できる確認してみますね。その上で、パッケージのコピー機能も採用してみるように検討

してみます。

先輩：新機能の価値を理解してもらえてうれしいよ。ただ、前提条件はちゃんとマニュアルで確認

するように。そういえば、最近、私のセッションに頼りすぎていないかい？

後輩：あ、ばれましたか。マイスター先輩の解説がわかりやすくて、ついつい頼ってしまうんですよ。

先輩：ははは。それはうれしいけど DB2 fぇおげ/OS の勉強会も継続してもらって、新機能をどん

どんスタディしていってほしいな。もうすっかりデータベース担当者の顔になってきているし、

そろそろ私がいなくなっても安心かな。

後輩：マイスター先輩。そんな恐ろしい冗談言わないで下さいよ！


4 System z との “ 真の ” シナジー効果

　DB2 for z/OS と System z のシナジー

先輩：おはよう！　Sけかがem げのセミナーに参加してきたんだって？

後輩：おはようございます！　マイスター先輩！ここのところ DB2 fぇおげ/OS を中心に勉強を進めて

いたのですが、Sけかがem げも並行して勉強するために、IBM のセミナーに参加してきました。

先輩：おお。成長著しくて非常に頼もしいな。前も言ったと思うけれど DB2 fぇおげ/OS は Sけかがem

げとは切っても切れない関係にある。Sけかがem げの機能を勉強することや価値を知ることは、

DB2 fぇおげ/OSを深く理解するためにも必要なことだ。もう既に理解できていると思うけど、

DB2 fぇおげ/OSと他 DBMS の設計思想の違いを簡単にまとめておくよ。（図 10）

図 10：DB2 fぇおげ/OS と他 DBMS の設計思想

後輩：ありがとうございます！　この設計思想の違いこそが、以前お話してくださったし真のしデー

タ共用機能などにつながるのですよね。今回、セミナーに出席してみて、これ以上進化し

ているコンピューターは Sけかがem げ以外になく、Sけかがem げのテクノロジーの進化を改め

て感じました。近年は、超大規模なデータベースを扱うための支援機構も非常に充実して

きているようですね。

④ Sけかがem げとのっ真の、シナジー効果

【第2章】 DB2

29

【第2章】 DB2

30


先輩：そうだね。データ共用機能は Sけかがem ｚの Sけかえleぐ機能を利用している話はしたよね。

他にも、Sけかがem げの64ビットアーキテクチャーを利用したDB2 fぇおげ/OSの仮想ストレー

ジの話もしたね。もちろん機能の提供だけにとどまらず、Sけかがem げへサーバーを統合し、

データ統合もできるサーバーとして、アプライアンスや専用のハードウェアも提供している

んだ。

後輩：そういえば、DB2 fぇおげ/OS と Sけかがem げのシナジー効果って言葉を良く聞くようになりま

した。DB2 fぇおげ/OS と Sけかがem げを使えば、両者のメリットを最大限に生かすことが可

能なのですよね？

先輩：その通り。Sけかがem げと DB2 fぇおげ/OS を採用し、既存のメインフレーム資産をそのまま

に様々なテクノロジーを透過的に利用するんだ。アプリケーションやデータがそのままとい

うことが重要で、これもDB2 fぇおげ/OS と Sけかがem げを採用する価値になるよね。

後輩：もしよければ、今日は DB2 fぇおげ/OS に役立つ Sけかがem げのテクノロジーに関してセッショ

ンを開いて頂けませんか？

先輩：お。いいね。超大規模なデータベースを扱うために効果的なものをいくつか紹介しよう。で

もセミナーで勉強してきたみたいだし繰り返しになるかもよ。君もすっかりスキルが付いてき

ているみたいだし。

後輩：そんなことないですよ。今日もお願いします！

　System z ハードウェアと連携した新技術

先輩：さっそくだけど、Sけかがem げの専用エンジンって知っているかい？　データベース処理専用

エンジンというのがあるんだけど。

後輩：データベース処理専用エンジンですか？ Lぁうきぐとかを動かすために必要なエンジンとかは

聞いたことがありますけど。

先輩：それはIFL（Iうがegおaがed Facぁlぁがけ fぇお Lぁうきぐ）だね。それとは別のエンジンで、標準プロセッ

サーとは異なる、げIIP（げ Iうがegおaがed Iうfぇおmaがぁぇう Pおぇceかかぇお）と呼ばれるものも出荷

されている。DB2 fぇおげ/OS で利用されるワークロードにおいて効果があるんだ。他にも

データベース処理専用エンジンではないけれど、Sけかがem げ上で稼働するJaぎaアプリケー

ションを効率的に実行するためのげAAP（げ Aええlぁcaがぁぇう Aかかぁかが Pおぇceかかぇお）と呼ばれ

るものも出荷されているよ。


後輩：標準プロセッサーとの違いがちょっと判らないのですが、DB2 fぇおげ/OS で利用されるワー

クロードではげIIP が利用されるのですか？

先輩：標準プロセッサーで処理されていた DB2 fぇおげ/OS の処理の一部を自動で振り替えること

が可能となるんだ。これによって、標準プロセッサーにかかっている負荷を軽減させること

が可能となり、より多くの処理を受け付けられるようになる。げIIP を利用するに当たって、

既存アプリケーションの修正や変更は不要だ。これによって CPU コストの節減につなげる

ことができる。

後輩：処理の一部を振り替えるということですが、どのような処理というのは決まっているので

すか？

先輩：げIIP へ振り替え可能な処理は決まっているよ。そもそもバージョン 8 からげIIP の利用が可

能なんだけど、バージョンを経るごとに適用可能な処理分野を広げているんだ。絵でバージョ

ンごとの差をまとめてみたよ。（図 11）

図 11：げIIP 振り替え対象処理の拡大

後輩：すごく拡張しているのですね。TCP/IP 経由の DRDA ※ 6 リクエストやユーティリティー処

理も振り替え可能ならば適用範囲も大きいですね。専用エンジンの利用というのも DB2

fぇおげ/OS と Sけかがem げならではの技術ということになるんですね。他にもハードウェア関

連で連携している技術はありますか？

【第2章】 DB2

31

【第2章】 DB2

32

※ 6. DRDA （Dぁかがおぁbきがed Relaがぁぇうal Daがabaかe Aおchぁがecがきおe）

　　 DRDA とは、ロケーション的に分散配置されるアプリケーションおよびリレーショナルデータベースの間の

コミュニケーションを可能にするためのアーキテクチャーのことをさす。

先輩：そうだね。最近出荷されたアプライアンスである

IBM DB2 Aうalけがぁcか Acceleおaがぇおというのもあるよ。

後輩：アプライアンスですか。どういった処理に対して特化しているのですか？

先輩： IBM Neがeげげaって知っているかな。データ・ウェアハウス専用のアプライアンスで、超大

規模で複雑な参照 SQL を高速化する製品なんだ。IBM Neがeげげa は分散系の製品である

ものの、Aうalけがぁcか Acceleおaがぇおは Neがeげげa アーキテクチャーを採用し、Sけかがem げと

DB2 fぇおげ/OS で利用できるようにしているんだ。

後輩：なるほど、複雑な SQL を高速に処理するのに特化した製品なのですね。

先輩：これもアプリケーションの変更は一切不要で DB2 fぇおげ/OS のオプティマイザーが自動で

判断してくれるんだ。こんな感じになるよ。（図12）

図 12：Aうalけがぁcか Acceleおaがぇおを利用したクエリー処理フロー


先輩：それに加え通常、DBMS のチューニングに関しては、索引を付与したり、物理設計を変

更したり、アクセス・パスの検証を行ったりするよね。これらのチューニング対応の簡素

化が可能になる。データベース運用のコスト削減にも効果がでるよ。ただ、Aうalけがぁcか

Acceleおaがぇおはあくまでバッチで利用するような超大規模で複雑な SQLで効果が発揮され

るもので、オンライン・アプリケーションのような単純 SQL では効果が見られない。ただ・・

後輩：ただ、それは DB2 fぇおげ/OS が適切なアクセス・パスをもって処理するわけですね。

先輩：ご名答。アプライアンスだから特別な導入や設定なども不要で手間がかからないのはメリッ

トではあるよね。

後輩：なるほどなぁ。げIIP もAうalけがぁcか Acceleおaがぇおも細かい設定しないで済むところは一緒な

んですね。DB2 fぇおげ/OS のワークロードの特定処理に対して様々な価値を享受できるの

ですね。

先輩：少し製品の紹介になってしまったので、DB2 fぇおげ/OS バージョン 10 で利用できる

Sけかがem げとの連携機能を紹介しようか。

　System z のラージページ

先輩： Sけかがem げの記憶域に関しては説明不要かな？　仮想ストレージと実ストレージ間のアドレ

ス変換のために利用するアドレス変換テーブルというのは知っているかな？

後輩：はい。動的アドレス変換機構のことですよね。記憶域の勉強はちゃんとしておきました。

こんな感じですよね。（図13）

図 13：仮想アドレスと実アドレスの変換


【第2章】 DB2

33

【第2章】 DB2

34


先輩：動的アドレス変換を高速に行うために、キャッシュしておく特別なテーブルがあって、これを

TLB（Tおaうかlaがe Lぇぇkaかぁde Bきfeお）というんだ。TLB 内のキャッシュにヒットすればア

ドレス変換は高速に行えるが、当然ヒットしなければ処理効率が落ちる。近年、64 ビット

アドレッシングのサポートなど Sけかがem げで利用するメモリーサイズは増大している一方で、

TLB のカバーする範囲がメモリーサイズに比べて相対的に小さくなっているんだ。これに

よって何が起きると思う？

後輩：難しいですね。キャッシュ・ミスが多発する可能性が多くなるのですかね。

先輩：そう。アプリケーションはキャッシュ・ミスによるコスト増に加え、パフォーマンスへの悪影

響をこうむる可能性もあるんだ。これに対して Sけかがem げでは、1MB の大きなページをサ

ポートするようになった。これにより、TLB のエントリー一つで大きな範囲のアドレス変換

を行うことができるようになったんだよ。

後輩：そもそも、TLB を増やすということはできないのですか？

先輩：いい指摘だね。Sけかがem げ 10 では TLB は 512 エントリーあるんだけど、ハードウェア・

スペースの限界やアクセス時間の最小化を目的としてエントリー数を増やさないなどの背景

があったんだ。

後輩：なるほど。これによって DB2 fぇおげ/OS にはどのようなメリットがあるのですか？

先輩：大容量のバッファー・プールを搭載している環境や、GETPAGE の発生レートが高く、同

時ユーザー数が多い環境でパフォーマンス・メリットを享受できるね。

後輩：これもアプリケーションの変更とかは不要なのですよね？

先輩：うん。げ/OS の設定を変更し、DB2 fぇおげ/OS からはバッファー・プールの設定を変える

だけで利用可能となる。


　また会う日まで

先輩：さて、まだまだあるけれど、今日はこの辺までにしようか。

後輩：はい！　今日もありがとうございました！　いやぁ、マイスター先輩の奥の深さをホント感

じますよ。またお願いしますね。

先輩：あぁ。そういえば、今月末に部署を異動することになったんだ。

後輩：えっ！　そんな！　急になんですか！　まだ教わっていないことがたくさんあります！

先輩：いつか伝えようと思っていたんだけど、もうすっかりDB2 fぇおげ/OS を扱える人に成長して

いるみたいだから安心して伝え忘れていたんだ。すまないね。

後輩：ショックです。けど、マイスター先輩、いつかまた戻ってきてくださいよ。

先輩：もちろん戻れたらもどってくるよ。でも、DB2 fぇおげ/OS のマイスターは君が受け継いでい

いと思っているよ。将来的には DB2 fぇおげ/OS だけでなく、Sけかがem げの世界における第

一人者になってくれよな！

後輩：はい！　今まで本当にありがとうございました！　また、一緒にお仕事させてください。

185

IBM、IBM ロゴ、ibm.com、AIX、CICS、CICSPlex、DB2、IMS、InfoSphere、NetVeiw、pureScale、RAA、

RACF、Rational、Rational Team Concert、SPSS、System z、Tivoli、WebSphere、z/OS およびｚSecure は、

世界の多くの国で登録された International Business Machines Corporation の商標です。他の製品名および

サービス名等は、それぞれ IBM または各社の商標である場合があります。現時点での IBM の商標リストについては、

www.ibm.com/legal/copytrade.shtml をご覧ください。

● 掲載された情報は 2013 年 3 月現在のものです。事前の予告なく変更する場合があります。

● 製品、サービスなどの詳細については、弊社もしくは IBM ビジネスパートナーの営業担当員にご相談ください。

● 本事例中に記載の肩書や数値、固有名詞は掲載当時のものであり、変更されている可能性があることをご了承ください。

Software

Zマイスターとの新たな価値探求 DB2