◆ユーザーの課題◆写真フィルムやイメージング関連サービスを提供している富士写真フイルムは，データ・ウエアハウス・システムのSAP BWを使って経営情報を分析している。しかし，システムの利用率向上とデータ量の増加に伴い，繁忙時の負荷にシステムが耐えられなくなり，度々ダウンしていた。
◆選んだ解決策◆SAP BWに使っているWindows NTサーバーを，Windows Server 2003が動作する64ビット機に置き換えて，高速化とメモリー空間の拡大を目指した。
◆結果と評価◆検索要求が集中した場合でも安定稼働できるようになった。同時に，高速化によって複雑な検索要求が実行可能になった。データベースに経営情報を追加する夜間バッチ処理の時間も2～3割削減できた。
| ||
|
富士写真フイルムは経営情報を分析するために，データ・ウエアハウス・システムの「SAP Business Information Warehouse（SAP BW）」を利用している。利用部門は経営企画部，経営層から支店，営業所まで幅広い。SAP BWの導入前は，定期的に作成していたレポートや，必要に応じてシステム部（現在の富士フイルムコンピューターシステム）に作成してもらったレポートに頼っていたが，SAP BWの導入によってそのときの経営状況を正確かつタイムリなデータを使って把握できるようになった。
ただ，導入後時間がたつにつれて，蓄積されたデータ容量が増大したり，ユーザーの利用頻度が増したりするなどの理由からSAP BWの利用率が徐々に高まり，システムに負荷がかかるようになってきた。その結果，システム・ダウンが度々発生する事態に陥ってしまった。原因は，SAP BWが利用しているデータベース管理システムが，利用可能なメモリー容量の限界に達してしまったことである。
そこで富士写真フイルムは，より広範なメモリー空間が利用できる64ビット・システムに移行することにした。
旧システムはWindows NT Server 4.0，Enterprise EditionとOracle8i Enterprise Edition Release 8.1.7.4，SAP BW 2.0Bの組み合わせ。これを，64ビット版のWindows Server 2003， Enterprise EditionとMicrosoft SQL Server 2000 Enterprise Edition（64-bit），SAP BW 3.1Cという新システムに移行した。
その際，利用しているユーザーには支障をきたさないよう，いっぺんに新システムに切り替えるのではなく，旧システムと新システムを並行稼働させ，新システムの動作を検証しながら徐々に移行する手順を踏んだ。2003年11月4日に旧システムと新システムの並行稼働を開始し，同年12月15日に全面移行を完了させた（図1[拡大表示]）。
新システムの導入後には，アクセスが集中しても安定稼働を続けられ，高速化によって旧システムのときよりも複雑な検索要求が実行可能になるという副産物的なメリットも生まれた。それまで複雑な検索は分割して実行する必要があったが，それを1回にまとめて実行できるようになった。また，基幹系システムから経営情報を抽出して，SAP BWのデータベースに追加する夜間バッチ処理の時間も，2～3割短縮できた。
高負荷に耐えられずシステムがダウン, 一番使いたいときに使えない状況に
SAP BWはERP（統合業務パッケージ）のSAP R/3用に開発されたデータ・ウエアハウス・システムである。OLAP（オンライン・アナリティカル・プロセッシング）ツールと組み合わせて，売り上げ分析や在庫分析などの各種分析，報告書の作成を可能にする。SAP R/3のデータを基にデータ・ウエアハウス用のデータを作成する。富士写真フイルムは，かねてから先進的ユーザーとしてシステム構築に積極的に取り組んでいる。2000年に財務や管理会計など基幹系業務の処理にSAP R/3を導入。翌2001年にはSAP BWの稼働を開始し，現在では全社でSAP R/3のデータを利用可能にしている。
富士写真フイルムは，SAP R/3とSAP BWによるデータ・ウエアハウスを，次のように運用している。まず日々の売り上げデータや在庫データ，各種伝票がSAP R/3に随時入力される。これらのデータは夜間のバッチ処理によって集計され，SAP BWへと転送される。SAP BWでは製品別，地域別などの視点で売上高や在庫量を集計した複数のデータ・キューブが作成され，多次元解析を可能としている。SAP BW上のデータを参照するには，各部署からOLAPツールを使ってアクセスする。
ここで問題になるのは，各部署の複雑な検索要求がSAP BWに大量に集中することである。様々な部署から異なるニーズに基づいたデータ・アクセスが発生し，アクセス対象になるデータは必ずしも同じではない。そのため，2002年ころから，年度始めなどの特に処理が集中する時期に障害が発生するようになってしまった。前述したように，データベース管理システムが利用可能なメモリー容量の限界に達してダウンしてしまったのだ。最も忙しく，最も利用したいときに限って利用できないという状況に陥ってしまった。その後も繁忙時にシステムがダウンすることが度々あった。
64ビットWindowsシステム構築のため4社を巻き込んだプロジェクトを結成
こうした折，2002年末にNECから64ビット版のWindowsシステムを使ったソリューションの提案を受けた。しかし当時，64ビットのWindowsシステムは未知の部分が非常に多く，不安要素は多かった。稼働実績などはなく，ましてやデータベースやデータ・ウエアハウスの構築例などない。全くゼロからのスタートとなった。
こうした状況では，ハードウエア・メーカーだけでOSやアプリケーションも含んだシステム全体を構築するのは困難である。そこでNECに加え，マイクロソフト，アプリケーション・ソフト・ベンダーであるSAPジャパン，さらにはCPUメーカーであるインテルの4社連合によるプロジェクト・チームが発足した。それぞれの企業のコンサルタントを迎えて，システム構築へ向けてチームを作った。こうして2003年4月，業界のビッグ・ネームをそろえた64ビット・システムへの移行プロジェクトがスタートした。
機能の検証は2003年2月から3月にかけて既に実施していた。実稼働に向けて必要な機能を実現できることは確認済みだ。それでも移行作業は困難なものだった。
ユーザーが支障をきたさないよう並行稼働の環境を作り上げる
今回のシステム移行において最も重視していたのが，移行作業によってユーザーの業務を妨げないことであった。しかし，この部分が最も困難だったという。
一方，異なる製品へのデータベースの移行を含む，初めてのプラットフォームでの移行処理，アプリケーションのバージョンアップは，考えていたよりはスムーズに進んだ。
OSとデータベース管理システム，アプリケーションのすべてを変更しつつ，しかもユーザーの作業に影響を与えないことを考え，具体的な移行作業は以下のように段階的かつ慎重に進めた（図2[拡大表示]）。
作業に使ったサーバーは全部で10台。SAP R/3の開発サーバーと移行サーバー，本稼働しているサーバーの3台。これに加え，SAP BWの新サーバーと旧サーバー，それぞれに対して開発機と移行機，本稼働機の3台ずつの計6台。さらにデータベース移行のための専用機として，既に本稼働しているSAP BWと同じ構成を採るコピー・マシンを1台使った。
最初の作業は，データベース管理システムをOracleからSQL Serverに変更することである。本稼働しているSAP BWマシンとは別に用意した暫定環境用サーバーでSQL Serverを動かし，本稼働SAP BWマシンの内容を新しいサーバーに転送した。このサーバーを暫定BW開発機とする。このマシンでは32ビット版のWindows 2000 ServerとSAP BW2.0を稼働させており，OSとデータベース管理システム以外は旧環境と同じである。
次に従来のSAP BW開発機から，新システムで新たに必要となるオブジェクトを暫定BW開発機に送る。これが完了したら，SAP R/3開発機から暫定BW開発機にデータを送る。
続いてデータベース管理システムをSQL Serverに変更して，SAP BWもバージョンアップする。そしてようやくOSの変更に取りかかる。暫定BW開発機を64ビット版のWindows Server 2003が動作する64ビット機へとリプレースする。
テスト機および本稼働機についても，開発機と同様に，まず32ビット版のWindows 2000 Server上で環境を構築して，データを移行してからOSを含めて64ビット機にバージョンアップするという順序で移行を進めた。
64ビット・システムを稼働させた後も，すべてのユーザーを一気に新サーバーに移行させなかった。一部のユーザーから徐々に新システムに移行させ，1カ月余りの間，旧システムと新システムを並列稼働させてテストを繰り返した。新サーバーに移行したユーザーで不都合がないことを確認した後，全ユーザーのアクセス先を新サーバーに切り替えて移行作業を完了した。
