表1●SQL Server 2005の主な新機能/強化点
表1●SQL Server 2005の主な新機能/強化点
[画像のクリックで拡大表示]
図1●SQL Server 2000/2005がダーティー・リードを防止する方法<BR>SQL Server 2000では,読み込み対象行の値が確定するまで読み込みを待機する。SQL Server 2005のRead Committed with snapshotでは,変更前の値をすぐに返すため,待機する必要がない。
図1●SQL Server 2000/2005がダーティー・リードを防止する方法<BR>SQL Server 2000では,読み込み対象行の値が確定するまで読み込みを待機する。SQL Server 2005のRead Committed with snapshotでは,変更前の値をすぐに返すため,待機する必要がない。
[画像のクリックで拡大表示]
図2●SQL Server 2005のRead Committed with snapshotの仕組み&lt;BR&gt;変更前の行の内容をテンポラリ領域に保存しておき,コミット前に読む必要が生じたときはそこから読み込むようにする。行を変更する際にバージョン番号を割り当てることで,各トランザクションがどのデータを読み込むべきかを管理する。
図2●SQL Server 2005のRead Committed with snapshotの仕組み<BR>変更前の行の内容をテンポラリ領域に保存しておき,コミット前に読む必要が生じたときはそこから読み込むようにする。行を変更する際にバージョン番号を割り当てることで,各トランザクションがどのデータを読み込むべきかを管理する。
[画像のクリックで拡大表示]
図3●名古屋銀行の移行前のシステム構成&lt;BR&gt;勘定系システムから1カ月ごとに取得したデータをOracleデータベースに格納し,マーケティング支援などの各システム(すべてSQL Server 7.0)はそこから必要に応じてデータを取得していた。OracleとSQL Serverの間のデータ交換にはサード・パーティ製のETLツールを,データ分析には統計解析ソフトSASやデータウエアハウス構築ソフトSagentを使用していた。図ではWebアプリケーション・サーバー(IIS)などは省略している。
図3●名古屋銀行の移行前のシステム構成<BR>勘定系システムから1カ月ごとに取得したデータをOracleデータベースに格納し,マーケティング支援などの各システム(すべてSQL Server 7.0)はそこから必要に応じてデータを取得していた。OracleとSQL Serverの間のデータ交換にはサード・パーティ製のETLツールを,データ分析には統計解析ソフトSASやデータウエアハウス構築ソフトSagentを使用していた。図ではWebアプリケーション・サーバー(IIS)などは省略している。
[画像のクリックで拡大表示]
写真1●今回のシステム移行を担当した名古屋銀行の方々(後列左端が山本 信勝次長)
写真1●今回のシステム移行を担当した名古屋銀行の方々(後列左端が山本 信勝次長)
[画像のクリックで拡大表示]
図4●名古屋銀行の移行後のシステム構成&lt;BR&gt;データベース・サーバーをSQL Server 2005に統一し,SQL Serverが標準装備するAnalysis ServicesやIntegration Servicesなどを利用するように変更。ETLツールやSASなどが不要になり,運用コストを大幅に削減できた。図3と同様,Webアプリケーション・サーバーなどは省略している。
図4●名古屋銀行の移行後のシステム構成<BR>データベース・サーバーをSQL Server 2005に統一し,SQL Serverが標準装備するAnalysis ServicesやIntegration Servicesなどを利用するように変更。ETLツールやSASなどが不要になり,運用コストを大幅に削減できた。図3と同様,Webアプリケーション・サーバーなどは省略している。
[画像のクリックで拡大表示]

 マイクロソフトは11月17日,リレーショナル・データベース管理システム(RDBMS)の新版「SQL Server 2005」を発表した。完成予定日は12月15日で,MSDN(Microsoft Developer Network)のサイトで会員に即日提供する。パッケージの出荷とボリューム・ライセンス販売の開始は,2006年2月初めになる見込みだ。

 新版での主要な新機能/強化点は表1[拡大表示]の通り。まず目に付くのは,データベース・ミラーリングやフェイル・オーバー・クラスタリングなど,可用性を高める機能が強化されたこと。新機能の目玉の一つとされているミラーリングは,本稼働系サーバーのデータを待機系サーバーに常時コピーし,本稼働系サーバーに障害が発生した際に切り替える機能である。クラスタリングと違ってハードウエア構成に制限がなく,待機系用にSQL Serverのライセンスを別途購入する必要もないため,低コストで可用性を向上できる。

 ただし,当初出荷される製品版では,ミラーリングの正式サポートは見送られた。起動時オプションなどでトレース・フラグ1400をオンにすれば機能自体は有効になるものの,テスト用という位置付けだ。ミラーリング機能の正式版は,2006年上半期に無償配布する予定という。

 このほか新版では,データ分析用のAnalysis Services,レポート出力用のReporting Services,データ交換用のIntegration Servicesといった各種コンポーネントも大幅に強化した。例えばAnalysis Servicesでは,,(1)データ・マイニング用アルゴリズムをこれまでの2種類から7種類に増やす,(2)多次元キューブをキャッシュするなどしてデータのリアルタイム性を高める——といった機能強化を図った。これにより,SQL Server 2005のデータ分析機能やレポート出力機能は,サード・パーティが単体で販売する製品と比べても遜色ないレベルに達している。マイクロソフトは,こうしたサード・パーティ製品を別途購入する必要がなくなることで,システム全体の構築/運用コストを大幅に削減できるとしている。

新分離レベルで同時実行性を向上

 高可用性やビジネス・インテリジェンス機能を強化する一方で,RDBMS自体の性能向上も図っている。中でも注目すべきなのが,「Read Committed with snapshot」と「Snapshot」という2種類の分離レベルを新たに用意したことだ。

 分離レベルは,複数のクライアントが並行してトランザクションを実行するような場合に,各トランザクションが互いに影響を及ぼし合うのをどの程度許可するかを設定するものである。

 例えば,クライアントAがトランザクションの途中で,ある行の内容を変更した後,コミットする前にクライアントBがその行を読み込んだとしよう。もし,Aがその後にトランザクションをロールバックした場合,Bは結果的に「誤った」データを読み込んでしまったことになる(ダーティ・リードと呼ぶ)。これを防ぐには,データを読み込む際にコミット済みのデータだけを読み込むようにする必要がある。

 こうした現象がどこまで問題になるかはアプリケーションによって異なるため,SQL Server 2000は4種類の分離レベルを用意していた。SQL Server 2000のデフォルトの分離レベルでは,ダーティ・リードを防ぐために,トランザクションの途中で行を変更した場合には行の内容が確定する(コミットもしくはロールバックする)まで排他ロックを掛けてほかのトランザクションの読み込みを待機させる(図1[拡大表示])。しかし,このやり方では,変更する側のトランザクションが長時間にわたるような場合に処理性能が大幅に低下するという問題がある。そこで,SQL Server 2005が新たに用意したRead Committed with snapshot分離レベルでは,変更前の行の内容(以前にコミットされた内容)を返すようにした。これにより,Aがコミットするのを待つことなく,Bが処理を進められるようになる。またSnapshot分離レベルでは,Aがコミットした後でも,Bのトランザクションが終了するまでは変更前の値を返す。これによって,トランザクション中の読み取り一貫性などを保証している。

 SQL Server 2005のRead Committed with snapshot分離レベルとSnapshot分離レベルの動作の仕組みを図2[拡大表示]に示す。クライアントAが行の変更を試みると,SQL Server 2005は変更前の行の内容をテンポラリ領域に保存した上で実際に行を変更する。以後,クライアントAがトランザクションをコミットする前に別のクライアントBが同じ行を読み込もうとした場合,SQL Server 2005はこのテンポラリ領域に保存した内容を返す。変更されていない行を読み込む場合は元のテーブルの内容をそのまま返せば済むため,テンポラリ領域を圧迫することはない。

 こうした動作は読み込み主体の処理の高速化が期待できる一方で,更新処理が大半を占める場合にはかえって遅くなる可能性もある。更新のたびにテンポラリ領域に保存するなどの余計な処理が必要になるからだ。このため,SQL Server 2005でもデフォルトの分離レベルはSQL Server 2000と同じである。分離レベルを変更してもアプリケーションに手を加える必要はないので,両方試して高速な方を選択すればよい。

製品候補版で実運用を開始

 既にSQL Server 2005で実運用を開始したシステムもある。名古屋銀行は,マイクロソフトが製品出荷前にベータ版などを提供し,システム構築を支援する「Technology Adoption Program(TAP)」に参加。同行の情報系システムの基盤となるデータベースとして機能していたUNIXサーバー上のOracle 7データベースを,Windowsサーバー+SQL Server 2005にリプレースした。同行はSQL Server 2005の正式発表前の10月31日に,TAPに参加した企業だけに配布された製品候補版を使用して実運用を開始している。「9月から新旧両システムを試験的に並行稼働させており,月末のホスト連携処理でも問題が発生しなかったので,製品候補版での実運用にも特に不安は感じなかった」(事務システム部次長の山本 信勝氏)という。

 1999年に構築した同行の情報系システム基盤は,富士通製メインフレームで稼働する勘定系システムから口座データなどを取得し,Oracleデータベースに蓄積するというもの(図3[拡大表示])。マーケティング支援などの各システムは,このOracleデータベースから必要なデータを抽出してSQL Server 7.0に格納し,データ分析などの処理を行っていた。OracleとSQL Serverのデータ交換には,サード・パーティ製のETL(データの抽出,加工,流し込み)ツールを利用。分析用には,別に統計解析ソフトSASやデータウエアハウス構築ソフトSagentなどを導入した。

 しかし,このシステムは当初の目論見と違ってあまり有効には活用されていなかったという。同行はASP(Active Server Pages)を利用したイントラネット・システムを独自開発するなど,Windows環境における開発/運用スキルには自信があったものの,OracleやUNIXに詳しい情報システム部員は少数だった。このため,システムを変更するたびにSIベンダーに依頼する必要があり,こまめにシステムをアップデートしにくいという問題があった。加えて,Oracleに慣れたシステム部員が少ないために,SIベンダーに毎月運用支援費用を支払う必要があった点にも不満を感じていたという。

 そこで,今回のシステム移行では,行内で有効活用できるようにすることを目標に,NEC製のサーバー(Xeon MP×4,8G~16Gバイトのメモリーを搭載)5台にSQL Server 2005を導入(写真1[拡大表示],図4[拡大表示])。データ交換とデータ分析にはSQL Server 2005が標準で備えるIntegration ServicesとAnalysis Servicesを利用するようにした。これにより,SASやETLツールのサポート/メンテナンス費用やSIベンダーに支払っていた運用支援費などが不要になり,年間の運用コストを7割も削減できたとしている。