oracle migration assessment 移行事例解説. 現行システム使用状況..... 7 4.3....

Oracle Migration Assessment

移行事例解説

2

目次

1. 本ガイドの目的 ................................................................................................................. 5

2. 前提条件 ............................................................................................................................ 5

3. 当社 OMA 概要 ............................................................................................................... 6

4. 当社 OMA における評価概要 ......................................................................................... 7

4.1. 現行データベース棚卸 ..................................................................................................................................................... 7

4.2. 現行システム使用状況 ..................................................................................................................................................... 7

4.3. 移行可用性 ............................................................................................................................................................................ 7

4.4. 移行可用性 8 観点概要 .................................................................................................................................................. 9

4.4.1. オブジェクト ................................................................................................................................................................ 10

4.4.2. ストアドプロシージャ............................................................................................................................................ 10

4.4.3. システム構成 ................................................................................................................................................................ 11

4.4.4. Oracle 機能 ................................................................................................................................................................... 11

4.4.5. 運用 ................................................................................................................................................................................... 11

4.4.6. アプリケーション SQL ............................................................................................................................................. 12

4.4.7. パフォーマンス ............................................................................................................................................................ 12

4.4.8. コスト .............................................................................................................................................................................. 13

5. 事例解説 .......................................................................................................................... 14

5.1. 事例システム概要 ............................................................................................................................................................ 14

5.2. システム利用規模 ............................................................................................................................................................ 14

5.3. OMA 実施背景.................................................................................................................................................................. 15

5.4. システム移行判断の経緯 .............................................................................................................................................. 16

5.4.1. データベース移行難易度 ......................................................................................................................................... 17

5.4.2. アプリケーション SQL・パフォーマンス ........................................................................................................ 18

5.4.3. 移行コスト ..................................................................................................................................................................... 18

5.4.4. 移行後のランニングコスト .................................................................................................................................. 19

5.4.5. システム移行に向けて .............................................................................................................................................. 20

5.5. システム移行のポイント .............................................................................................................................................. 22

5.5.1. データアクセスプロバイダの移行 .................................................................................................................... 22

5.5.2. バインド変数の変更 .................................................................................................................................................. 23

5.5.3. SQL 文の変換 ............................................................................................................................................................... 24

5.5.4. SQL Server 予約語対応 ............................................................................................................................................. 25

5.5.5. Oracle - SQL Server 機能移行 ................................................................................................................................ 27

5.5.6. データ移行 ..................................................................................................................................................................... 28

5.6. 今後の展望 .......................................................................................................................................................................... 29

6. その他の移行事例 ........................................................................................................... 30

6.1. システム概要 ..................................................................................................................................................................... 31

6.2. システムの現状 ................................................................................................................................................................. 31

3

6.3. システム移行の背景・新システム構築の目的 .................................................................................................... 32

6.4. システムパフォーマンスの確保 .............................................................................................................................. 32

6.5. SQL Server – Oracle の連携技術 Oracle Gateway .............................................................................................. 33

6.6. RDBMS の選択 –Oracle → Next?? – ...................................................................................................................... 34

6.7. 今後の展望 .......................................................................................................................................................................... 35

7. 移行検討中事例 ............................................................................................................... 37

7.1. 概要 ........................................................................................................................................................................................ 37

7.2. 課題整理 .............................................................................................................................................................................. 37

7.3. 評価内容 .............................................................................................................................................................................. 37

7.4. 今後の展望 .......................................................................................................................................................................... 39

8. その他の主なポイント .................................................................................................... 40

8.1. 単純移行コスト ................................................................................................................................................................. 40

8.2. アプリケーション SQL .................................................................................................................................................. 41

8.3. パフォーマンス ................................................................................................................................................................. 41

9. まとめ .............................................................................................................................. 43

4

[注意事項]

このドキュメントに記載されている情報 (URL 等の Web サイトに関する情報を含む) は、将来予告なしに変更することがあります。

このドキュメントは情報提供のみを目的としており、明示または黙示に関わらず、これらの情報及び情報を使用した結果についてマイ

クロソフトはいかなる責任も負わないものとします。また、このドキュメントに記載された内容は作成日時点の情報に基づくものです。

お客様がこのドキュメント及び本製品を使用した結果については、すべてお客様が負うものとします。このドキュメントのご利用にあ

たっては、お客様ご自身の責任において、適用されるすべての著作権関連法規に従う必要があります。このドキュメントのいかなる部

分も、特に記載のない限り、米国 Microsoft Corporation の書面による許諾を受けることなく、その目的を問わず、どのような形態で

あっても、複製または譲渡することは禁じられています。ここでいう形態とは、複写や記録など、電子的な、または物理的なすべての

手段を含みます。

マイクロソフトは、このドキュメントの内容に関し、特許権、特許出願、商標権、著作権、またはその他の知的財産権を有する場合が

あります。別途マイクロソフトのライセンス契約に明示されない限り、このドキュメントはこれらの特許権、商標権、著作権、または

その他の知的財産権に関する権利をお客様に許諾するものではありません。

特に記載されていない場合、このソフトウェアおよび関連するドキュメントで使用している会社、組織、製品、ドメイン名、電子メー

ルアドレス、ロゴ、人物、出来事などの名称は架空のものです。実在する会社名、組織名、商品名、個人名などとは一切関係ありませ

ん。

© 2013 Microsoft Corporation. All rights reserved.

Microsoft、Windows、MSDN、SQL Server、Visual Basic、Visual C++、Visual C#、Visual Studio は、米国 Microsoft Corporation

またはその関係会社の米国およびその他の国における登録商標または商標です。

記載されている会社名、製品名には、各社の商標も含まれます。

[追記]

お客様は、引用元を明記し、かつ、記載内容を変更しない場合に限り、このドキュメントの一部を引用することができます。但し、こ

のドキュメントからの引用部分とその他の部分を明確に区別しなければなりません。

お客様は、このドキュメントを改変せずに複製する場合に限り、かかる複製物を、無償で、頒布することができます。但し、その場合

は、著作権者は Microsoft Corporation であること及び上記の注意事項を明示しなければなりません。

5

1. 本ガイドの目的

本書は、日本マイクロソフト株式会社と協業し、当社 ( 株式会社システムコンサルタント、以下 KSC ) が、

コンサルティングメニューとしてお客様へ提供している Oracle Migration Assessment ( 以下、OMA ) の概

要と、OMA の利用後、実際に移行を行ったお客様の対象システムについての移行事例をまとめています。

2. 前提条件

本書で解説対象とするお客様システムの開発言語、SQL Server 、および、Oracle のバージョンは以下の通

りです。

開発言語

VB.Net

SQL Server

SQL Server 2008 R2

Oracle

Oracle Database 10g R2

6

3. 当社 OMA 概要

昨今の経済状況に伴い、IT 予算削減の意識が高まる中において、年々増加傾向にあるソフトウェアの保守

コストは、IT 予算を圧迫してきています。

このような状況下において、保守コスト削減のため、Microsoft® SQL Server® (以下、SQL Server) への移行

を検討されるお客様が増えてきています。

そこで当社は、Oracle Database (以下、Oracle) をご利用のお客様を対象に、SQL Server へ移行した際のコ

スト削減額を算出するアセスメントサービスを提供しています。

実際にどのように移行するのか？

その移行コストは？

ビジネスロジックは全て移行できるの？書き換え工数は？

という、お客様の懸念や疑問に対し、明確な回答をレポートとして受け取ることができる｢移行検証サービ

ス｣、です。実際に移行を検討した際に発生する問題の解決を目標としています。

具体的には、データベースを調査・分析し、客観的なアセスメントを行います。｢移行方法｣、｢移行難易度

(移行コスト)｣、｢移行後のコスト削減額｣、について具体的な数値をもって、移行の評価結果を提示します。

7

4. 当社 OMA における評価概要

ここでは、移行難易度の判定や移行後のパフォーマンス、および、コスト削減効果の可視化が行える、

OMA の評価ポイントについて整理を行います。

4.1. 現行データベース棚卸

運用中のシステムで稼働しているデータベース (Oracle) に関する情報を収集し、インスタンス情報を整理

します。

事業拡大に伴うシステム拡張を重ね、開発ベンダーも複数社におよび、複雑なシステムとなってしまってい

る上、担当者も変わってしまい、オブジェクトについても、プロシージャについても全てを把握しているス

タッフがいないお客様へも対応します。

4.2. 現行システム使用状況

現行システムの使用状況を、3 つの観点 (｢運用｣、｢性能｣、｢コスト｣) で分析し、Oracle を使用する中での

課題を洗い出し、SQL Server へ移行した場合の解決策を提示します。データベースを Oracle から SQL

Server へ移行した場合、課題が解決可能かどうかを探ります。

現行システム使用状況についての、OMA 評価観点を次の表に示します。

カテゴリ Oracle での課題 SQL Server での

課題解決方法

評価基準

運用 ○ ○ 課題数、課題の重大度

性能 ○ ○

コスト ○ ○

4.3. 移行可用性

評価対象のデータベース (Oracle) を、8 つの観点(｢オブジェクト｣、｢ストアドプロシージャ｣、｢システム

構成｣、｢Oracle 機能｣、｢運用｣、｢アプリケーション SQL｣、｢パフォーマンス｣、｢コスト｣) から、

データベース移行難易度、アプリケーション移行難易度、移行コスト、移行後のランニングコストについ

ての可視化を行います。

移行可用性についての、OMA 評価観点を次の表に示します。

カテゴリ DB 移行

難易度

アプリケーショ

ン移行難易度

移行コスト移行後のラン

ニングコスト

評価基準

オブジェクト ○ ○ SSMA 自動変換率

ストアドプロシ

ージャ

○ ○

システム構成 ○ Oracle 利用機能に対する、SQL

Server での代替機能の実現性 Oracle 機能 ○

運用 ○

8

アプリケーション

SQL

○ SSMA 自動変換不可パターン数

パフォーマンス ○ パフォーマンス・ボトルネック

SQL の発生有無

コスト ○ SQL Server へ移行した場合の投

資回収点

9

4.4. 移行可用性 8 観点概要

データベース移行難易度、アプリケーション移行難易度、移行コスト、移行後のランニングコストと

いったコスト評価の可視化を行うため、8 観点の概要について説明します。

データベース移行難易度では、移行支援ツール SQL Server Migration Assistant for Oracle (以下、SSMA) を利

用し、SSMA から出力される Oracle から SQL Server へ移行する場合の自動変換率、移行コストを精査し

て評価を行います。

SSMA では、Oracle 8 以降の Oracle から SQL Server への移行プロセスにおいて、データベースオブジェ

クトと、PL/SQL コードの変換を自動で行うことが可能となります。

アプリケーション移行難易度では、メモリ上に残っている SQL 取得し、SQL Server 対応への SQL 移行難易

度、パフォーマンス観点での移行難易度を判定します。

コスト評価では、データベースの単純移行コストを含めた運用コスト比較、サポート費用を、SQL Server と

Oracle で比較し、総合的なコスト評価を行います。

10

4.4.1. オブジェクト

Oracle のデータベースに作成されているオブジェクト類 (ストアドプロシージャを除く) を対象に評価を

行います。

オブジェクトについての、評価カテゴリと概要を次の表に示します。

評価カテゴリ概要

DB 移行難易度 SSMA を利用し、Oracle データベースに作成されているオブジェクト類 (ストアド

プロシージャを除く) から、SQL Server へ変換した場合の移行難易度判定、および、

自動変換率を算出します。

移行コスト SSMA の機能 (Create Report) で出力された Oracle データベースに作成されてい

るオブジェクト類 (ストアドプロシージャを除く) に対して、自動変換が行えなか

ったものの内容、移行時の対応方法、対応工数の妥当性を検討し、移行コストの算

出を行います。

4.4.2. ストアドプロシージャ

Oracle のデータベースに作成されているストアドプロシージャを対象に評価を行います。

ストアドプロシージャについての、評価カテゴリと概要を次の表に示します。


DB 移行難易度 SSMA を利用し、Oracle データベースに作成されているストアドプロシージャか

ら、SQL Server へ変換した場合の移行難易度判定、および、自動変換率を算出しま

す。

移行コスト SSMA の機能 (Create Report) で出力された Oracle データベースに作成されてい

るストアドプロシージャに対して、自動変換が行えなかったものの内容、移行時の

対応方法、対応工数の妥当性を検討し、移行コストの算出を行います。

11

4.4.3. システム構成

アセスメント対象となる、運用中の Oracle で利用している Oracle のシステム構成機能を対象に評価を行

います。

システム構成についての、評価カテゴリと概要を次の表に示します。


DB 移行難易度アセスメント対象となる、現在運用中の Oracle で利用しているシステム構成機能に

対して、SQL Server での同等、代替機能の実現性を検討し、評価を行います。

4.4.4. Oracle 機能

アセスメント対象となる、運用中の Oracle で利用している Oracle の独自機能を対象に評価を行います。

Oracle 機能についての、評価カテゴリと概要を次の表に示します。


DB 移行難易度アセスメント対象となる、現在運用中の Oracle で利用している Oracle 独自機能に

対して、SQL Server での同等、代替機能の実現性を検討し、評価を行います。

4.4.5. 運用

アセスメント対象となる、運用中の Oracle で利用している Oracle の運用機能を対象に評価を行います。

運用についての、評価カテゴリと概要を次の表に示します。


DB 移行難易度 Oracle で利用している Oracle 運用機能に対して、SQL Server での同等、代替機

能の実現性を検討し、評価を行います。

12

4.4.6. アプリケーション SQL

KSC 独自ツールで、アセスメント対象となる Oracle の動的情報を収集し、アプリケーションから発行され

ている SQL 文を対象に評価を行います。

アプリケーション SQL についての、評価カテゴリと概要を次の表に示します。


アプリケーション移行難易

度

SSMA を利用し、アプリケーションから発行される Oracle 対応の SQL 文を、SQL

Server 対応の SQL 文へ変換した場合の、自動変換が行えなかったパターンを洗い

出し、変換パターンの量感、変換パターンの難易度を評価します。

4.4.7. パフォーマンス

KSC 独自ツールで、アセスメント対象となる Oracle の動的情報を収集し、アプリケーションから発行され

ている SQL 文のパフォーマンス・ボトルネックの発生有無を対象に評価を行います。

パフォーマンスについての、評価カテゴリと概要を次の表に示します。


アプリケーション移行難易

度

アプリケーションから発行されている SQL 文の CPU リソース使用状況、ディスク

I/O 、実行回数などを調査し、パフォーマンス・ボトルネックとなる SQL 文の調査

を行います。

パフォーマンス・ボトルネックとなる SQL 文の発生有無を評価します。

13

4.4.8. コスト

Oracle の保守料金と SQL Server の導入、保守料金を対象に評価を行います。

コストについての、評価カテゴリと概要を次の表に示します。


移行後のランニングコス

ト

現行使用している Oracle の保守料金と、SQL Server の新規導入、運用を実施した

場合の保守料金を比較します。

導入予定のサーバ構成や統廃合を含めた、お客様のご希望の環境を確認し、必要ラ

イセンス数を算出し、対象のお客様の Select Level での参考価格で投資回収点を評

価します。

14

5. 事例解説

ここでは、卸売・小売業・飲料業のお客様で、当社 OMA サービスを利用し、実際に Oracle から SQL

Server へシステム移行を行った事例の解説を行います。

5.1. 事例システム概要

海外 60 か国、120 拠点で利用されている販売/在庫情報を集約、分析する、海外現地法人、および、代理

店向けの販売管理システムを構築。またそれらに加え海外市場向け基幹系システムからのデータを蓄積、分

析する海外市場向け情報系システムを、Oracle Database 10g と BusinessObjects によって構築、活用して

きました。

一方で、SQL Server をデータベースに使った国内市場向け情報系システム稼働しており、国内と海外で異

なるプラットフォームのデータベースを持つ情報系システムの併存運用を行っていました。

今回 OMA では、海外現地法人、および、代理店向けの販売管理システムで稼働していた Oracle をアセス

メント対象としました。

5.2. システム利用規模

アセスメント対象とした Oracle を利用しているシステムの利用規模は、以下の通りとなります。

海外市場向けシステム：世界 60 か国 120 拠点で展開

国内市場向けシステム：全国 200 ユーザーが利用

OMA で評価を行う前のシステム構成を下の図に示します。

15

5.3. OMA 実施背景

評価対象とする Oracle の情報を収集し、現在運用中の業務システムに対する運用面や利用用途の確認を行

い、お客様の抱える課題を、以下の通り整理しました。

お客様の抱える課題

サーバの仮想化、集約時のコスト

現在稼働中の業務システムの移行費用、工数

業務システムの確実な移行

移行後のシステムパフォーマンス

移行後のランニングコスト

OMA 実施前までは、海外と国内の市場特性に合わせて、それぞれ別々の商品を供給する必要がありました。

しかし、市場のグローバル化が進み、世界共通仕様の商品の増加に伴い、地球規模での情報収集、分析が可

能な統合情報インフラを構築する必要に迫られました。

また、企業全体として、効率的な IT システムの整備、情報化計画が示され、IT の共有化と標準化によって

ビジネス全体の効率化、コスト削減を今まで以上に促進していくことが決定されました。

この決定により、かねてから推し進めていた仮想化、クラウド化の実現に向けて大きな拍車がかかり、複数

データベース製品を比較検討した結果、Oracle か SQL Server のどちらかを統合データベースとして採用す

る結論に至りました。

Oracle を採用した場合、既に多くのシステムを Oracle で構築していたため、大規模なシステム改修の実施

を行わずに済ませられる反面、仮想化、クラウド化がコスト的に実現が困難であることが判明しました。一

方で、SQL Server を採用した場合、仮想化にも適したライセンス体系と既に導入が完了していた Active

Directory との親和性の高さ、BI ツールが標準で提供されている点が、コスト面、機能面で文献上問題ない

ことを確認しました。

しかし、Oracle 上で現在稼働中の複数 IT システムの移行費用、工数、アプリケーションの継承、外部シス

テムとの連携、移行後のパフォーマンスに懸念があり、経営者層に上申するためには、具体的な数値に基づ

16

く技術、予算面での裏付けが必要でした。

また、大きな課題として、業務システムの確実な移行があり、OMA の基本メニューに加えて、外部システ

ムも含めたアプリケーションとの連携、期待値通りのパフォーマンスが出ているかを見ることが可能な独自

の検証サービスを提供している、当社の OMA がお客様のニーズにマッチしたため、移行難易度判定、移

行後のパフォーマンス、および、コスト削減効果の可視化をご依頼いただきました。

5.4. システム移行判断の経緯

海外販売管理システムのデータベースである Oracle を対象に OMA を実施し、以下のポイントで評価結果

の報告を行いました。

OMA 評価ポイント

データベース移行難易度

アプリケーション SQL・パフォーマンス

移行コスト

移行後のランニングコスト

お客様が抱える現状の課題に対する解決方法を OMA で提示し、マイグレーションプランの策定、および、

システム全体の移行コストを算出しました。特に、業務システムの確実な移行に対しては、高い課題意識を

持っており、OMA 実施後に、マイグレーションプランの策定とシステム全体の移行コストの見積もりを

行い、システム移行に向けての準備が進められていきました。

マイグレーションプランの策定では、以下のポイントを整理し、課題がクリアとなりました。

マイグレーションプランのポイント

｢仮想化｣、実現(案)

外部システムとの連携による業務効率化

システム全体の移行作業タスクの明確化

データベース移行タスク

17

業務システム移行タスク

システム全体の移行コスト

OMA の結果を基に、マイグレーションプランを社内に上申、予算化を行い、システム移行実施となりまし

た。

OMA を実施した結果、お客様がシステム移行の評価としたポイントを説明します。

5.4.1. データベース移行難易度

OMA を実施した結果、SSMA を利用したデータベースオブジェクトの変換率は 100% であり、また、

Oracle で PL/SQL ( ストアドプロシージャ ) はシステムとして利用していませんでした。

また、Real Application Cluster や Oracle Active Data Guard 、Oracle Partitioning といった、高可用性やス

ケーラビリティを実現する機能の使用もなかったため、移行難易度は｢容易に移行が可能｣、との評価をしま

した。

お客様の懸念、不安の一つであった、データベース移行については、上記評価によって解消することが出来

ました。

◆カテゴリ別評価

カテゴリ評価コメント

オブジェクト 5 Oracle 特有のオブジェクトは見られず、容易に SQL Server への移行が可能です。

18

オブジェクト変換情報

オブジェクト種類オブジェクト数変換率(%) 自動変換率(%)

全体 - -

100.00

Tables 104 100.00

Indexes 52 100.00

Sequences 3 100.00

Synonyms 9 100.00

Procedures 0 -

Functions 0 -

Packages 0 -

5.4.2. アプリケーション SQL・パフォーマンス

大きな課題の一つとなっていた、アプリケーションの確実な移行については、KSC 独自ツールで情報収集

を行い、アプリケーションから発行されている SQL 文と、パフォーマンスについての評価を行いました。

アプリケーション SQL については、SSMA で自動変換ができなかった SQL 文が 4 パターンであり、パタ

ーン数の少なさから、アプリケーション全体の SQL Server 化対応についての調査を行っても、変更箇所が

少ないであろうと、お客様が容易に予測することが出来ました。

パフォーマンスについては、約 10,000 本の SQL の中で、パフォーマンス・ボトルネックとなっていた

SQL が僅かに 1 本しか存在しませんでした。

並列で稼働するバッチ処理の中で、該当 SQL 文の実行回数を課題として挙げましたが、1 つの処理として

見たときのパフォーマンスに問題はなく、移行に向け、大きく問題視されることはありませんでした。

◆カテゴリ別評価

カテゴリ評価コメント

SQL 3 メモリ上から取得した一部の SQL 文については、手動による修正が必要です。

変換必要 SQL

分類 SQL 修正箇

所

コメント

バインド変数 1,558 バインド変数の記述方法が違うため、手動による修正が必要です。

ROWNUM 5 ROWNUM のある SQL 文は、SQL Server では対応していないため、手動による修

正が必要です。

日付関数 5 TO_DATE 関数で、海外時刻を設定する 3 個目のパラメータは、SQL Server では対

応していないため、手動による修正が必要です。

文字列操作 14 Oracle の SUBSTR 関数と SQL Serve の SUBSTRING 関数は、それぞれ異なる結果

となる可能性があります。

5.4.3. 移行コスト

データベース移行が安全に実施可能であることが分かり、データベース移行コストの算出を行いました。

データベースマイグレーションプランの｢データベース移行｣、の主な作業内容として、DB 環境構築、DB

19

リソース移行、データ移行、検証、ドキュメンテーションの修正があります。

当社では、SSMA を利用することで、DB 環境構築、DB リソース移行、データ移行作業のコストを大幅に削

減することが可能であると評価しました。また、検証フェーズにおいて、SQL Server と Oracle を並行稼働

で検証を行い、データの整合性を見極めていくことをお客様と合意できたため、移行プロジェクト全体のコ

ストに対し、データベース移行が占めるコストを大きく圧縮することが出来ました。

5.4.4. 移行後のランニングコスト

OMA では、アセスメント対象となった Oracle と SQL Server が対応するエディションでの導入費と運用

費のコストシミュレーションを行いました。

Oracle の継続運用に必要なサポート料と、SQL Server の導入費、運用費、および、データベース移行に必

要なコストを算出、比較し、早期に投資回収が可能であることが実証されました。

導入費用と、5 年間 Oracle と SQL Server を運用した場合のサポート費用比較を以下に示します。

20

【導入・サポート費用比較】

Oracle は、オープン価格、SQL Server は、お客様が該当する Select Level A での参考価格で試算して

います。

Oracle のサポート契約更新時の調整率は、本稿作成時点の 2% で試算しています。

5.4.5. システム移行に向けて

データベース移行が容易に可能であるとの評価、移行コスト、SQL Server の導入・運用コストのシミュレ

ーションを行ったことで、移行のコスト面・作業面におけるボリューム感、移行後のベストプラクティス

として、仮想化による SQL Server マルチインスタンス方式での移行後環境の構築を提案しました。お客様

は、システムを仮想環境への移行を前提に検討を行っており、サーバの仮想化による統合で、ハードウェア

や運用に関するコスト削減、仮想化によるシステム拡張性、および、BCP/DR の観点でも、災害対策、耐障

害性を期待していたためとなります。

移行前の環境において、Oracle では、別々の物理サーバで運用を行っており、データの書き出しによる相互

の I/F 連携が非常に煩雑でした。しかし、OMA 実施後に策定した、マイグレーションプランに則り、仮想

環境上で SQL Server をマルチインスタンス方式で稼働し、シームレスな連携を提案し、且つ、移行案件と

しては非常に短期間で SQL Server の移行を完了しました。

21

本事例では、Oracle で稼働していた海外情報系 DB を、SQL Server へと移行し、以下の改善を実現しま

した。

※他システム (国内情報系 DB)は、他社ベンダーにより、SQL Server2008 R2 への移行プロジェクトが、

既に進んでいました。

DB Server の仮想化運用

海外情報系 DB と国内情報系 DB を、情報系 DB として統合。シームレスなデータ連携

DB、BI ツールのコスト削減

現在の運用で、Oracle との並行稼働を実施し、移行の精度、性能の検証を行っています。

検証完了後には、Oracle を廃止し、SQL Server のみでの運用を予定しています。

22

5.5. システム移行のポイント

ここでは、マイグレーションプランに沿って、Oracle から SQL Server へ移行した際の手順や変換ルール

を説明します。

5.5.1. データアクセスプロバイダの移行

Oracle から SQL Server へデータベースエンジンを移行するに当たり、VB.NET で開発されているプログラ

ムソース内のデータアクセスプロバイダを、｢Oracle.DataAccess.Client｣、から｢System.Data.OleDb｣、へと

変更を行いました。

分類 Oracle SQL Server

Import

Oracle.DataAccess.Client System.Data.OleDb

Import

Oracle.DataAccess.Types

DataAdapter

OracleDataAdapter OldDbDataAdapter

Connection

OracleConnection OleDbConnection

DataReader

OracleDataReader OleDbDataReader

DbType

OracleDbType OleDbType

プログラムソース内のデータアクセスプロバイダを、Oracle のネイティブプロバイダから、OLEDB

プロバイダへと変更を行いました。

OLEDB 接続プロバイダへの変換手順は、以下の通りとなります。

① VB.Net 内に記述されている、｢Import｣、句をコメントアウトします。

② Oracle のネイティブプロバイダをコメントアウトすることで、対応に必要なソースコードが、

Visual Studio 内でビルドエラーとなるため、OLEDB プロバイダ対応のソースコードへと変換を行

います。

③ 全てソースコードを修正し終えたら、再ビルドを行い、動作確認を行います。

バインド変数として、パラメータ設定を行っているプログラムソースの属性変換を行います。

以下の表にある、Oracle データ属性は、OLEDB のデータ属性に対応しないものもあるため、シス

テム移行時のデータ属性変換を以下の通り行いました。


日付

OracleDbType.Date OledbType.Date

文字列

OracleDbType.Char OleDbType.Char

OracleDbType.NChar OleDbType.WChar

OracleDbType.Varchar2 OleDbType.Varchar

23

OracleDbType.NVarchar2 OleDbType.WVarchar

数値 OracleDbType.Int32 OleDbType.Decimal

OracleDbType.Int64 OleDbType.BigInt

OleDbType.Integer

5.5.2. バインド変数の変更

Oracle から SQL Server へデータベースエンジンを移行するに当たり、VB.NET で開発されているプログラ

ムソース内のデータアクセスプロバイダを、｢Oracle.DataAccess.Client｣、から｢System.Data.OleDb｣、へと

変更を行いました。

データアクセスプロバイダの変更に伴う、バインド変数の定義方法の違いを、次の表に示します。


バインド変数 :[バインド変数] ?

データアクセスプロバイダの変更に伴う、プログラムソース内で記述されている動的 SQL 文について

は、バインド変数の定義変更が必要となります。

Oracle.DataAccess.Client では、｢:[バインド変数]｣、のように、コロン + 変数名の形でバインド変数の

定義を行いますが、System.Data.OleDb では、｢?｣、( クエスチョン )でバインド変数の定義を行います。

OleDb では、｢?｣、でバインド変数を指定するため、[バインド変数]のように、バインド変数名を指

定することはできません。

プログラムソース内で、｢?｣、の数だけ、バインドする値を設定する必要があります。

データベースエンジン内では、最初の｢?｣、から順番に解析を行います。

プログラムソース内での、バインド変数の定義変更方法のサンプルを示します。

バインド変数の定義変更の例(変更前)

Dim sSql As System.Text.Stringbuilder

With sSql

.Append(“ AND “)

.Append(“A.D_CODE = :D_CODE “)

dbCommand.Parameters.Add(“D_CODE”, OracleDbType.Varchar2)

dbCommand.Parameters(“D_CODE”).Value = Me.D_Code

End With

24

バインド変数の定義変更の例(変更後)

Dim sSql As System.Text.Stringbuilder

With sSql

.Append(“ AND “)

.Append(“A.D_CODE = ? “)

dbCommand.Parameters.Add(“D_CODE”, OleDbType.Varchar)

dbCommand.Parameters(“D_CODE”).Value = Me.D_Code

End With

バインド変数の定義変更を行ったプログラムソースについては、次の点に注意が必要となります。

データアクセスプロバイダが正しく設定されていることを確認します。

例) ｢OracleDbType.[データ型]｣、→｢OleDbType.[データ型]｣、となっていることを確認します。

※｢OleDbType｣、以外のデータアクセスプロバイダへ変換を行っても、Visual Studio 内でビルドエラーが

発生しない場合があるため注意が必要です。また、異なるデータアクセスプロバイダが設定されている

場合、処理性能(パフォーマンス)に大きな影響を与える場合があるため、注意が必要となります。

処理を実行し、SQL 文が正しく実行されることを確認します。

5.5.3. SQL 文の変換

事例におけるシステム移行で、使用頻度の高かった Oracle の関数、機能に対応する SQL Server の関数、

機能は以下の通りとなります。

分類 Oracle SQL Server 備考

日付

TO_CHAR(col1, ‘YYYY/MM/DD’ )

CONVERT(CHAR(10), col1, 111)

TO_CHAR(col1, ‘YYYY/MM’ )


TO_CHAR(col1, ‘YYYYMMDD’ )


TO_CHAR(col1, ‘YYYYMM’ )


文字列日付型

変換

TO_DATE(col1, ‘YYYY/MM/DD’) CONVERT( DATE | DATETIME, col1)

バインド変数のパラメ

ータとして設定する場

合、引数に｢?｣、を設定

する。

CONVERT( DATE | DATETIME, ?)

NULL 判定 NVL(col1, ‘Fmt’ ) ISNULL(col1, ‘Fmt’ ) NULL を ‘Fmt’ に変換

する。

分岐条件 DECODE CASE

空白除去

TRIM( col1 ) LTRIM( RTRIM( col1 ) )

25

文字列連結

|| (パイプ) + (プラス演算子)

文字列切出

SUBSTR( col1, m, n ) SUBSTRING( col1, m, n ) 挙動が違う場合がある

ため、検証が必要

SQL Server 非

対応列

ROWNUM ROW_NUMBER() OVER() SELECT 句として、列値

を取得する場合

TOP nnn WHERE 句として、取得

行数を絞る場合、SELECT

句に追加

バインド変数 :[バインド変数] ?

5.5.4. SQL Server 予約語対応

SQL Server の予約語については、プログラムソース内で｢"｣、( ダブルクォート )で囲む必要があります。

対応が必要な SQL Server の予約語は以下の通りです。

予約語一覧

@@IDENTITY ADD ALL

ALTER AND ANY

AS ASC AUTHORIZATION

AVG BACKUP BEGIN

BETWEEN BREAK BROWSE

BULK BY CASCADE

CASE CHECK CHECKPOINT

CLOSE CLUSTERED COALESCE

COLLATE COLUMN COMMIT

COMPUTE CONSTRAINT CONTAINS

CONTAINSTABLE CONTINUE CONVERT

COUNT CREATE CROSS

CURRENT CURRENT_DATE CURRENT_TIME

CURRENT_TIMESTAMP CURRENT_USER CURSOR

DATABASE DATABASEPASSWORD DATEADD

DATEDIFF DATENAME DATEPART

DBCC DEALLOCATE DECLARE

DEFAULT DELETE DENY

DESC DISK DISTINCT

DISTRIBUTED DOUBLE DROP

DUMP ELSE ENCRYPTION

END ERRLVL ESCAPE

EXCEPT EXEC EXECUTE

EXISTS EXIT EXPRESSION

FETCH FILE FILLFACTOR

FOR FOREIGN FREETEXT

FREETEXTTABLE FROM FULL

FUNCTION GOTO GRANT

GROUP HAVING HOLDLOCK

IDENTITY IDENTITY_INSERT IDENTITYCOL

IF IN INDEX

INNER INSERT INTERSECT

INTO IS JOIN

KEY KILL LEFT

LIKE LINENO LOAD

MAX MIN NATIONAL

NOCHECK NONCLUSTERED NOT

26

NULL NULLIF OF

OFF OFFSETS ON

OPEN OPENDATASOURCE OPENQUERY

OPENROWSET OPENXML OPTION

OR ORDER OUTER

OVER PERCENT PLAN

PRECISION PRIMARY PRINT

PROC PROCEDURE PUBLIC

RAISERROR READ READTEXT

RECONFIGURE REFERENCES REPLICATION

RESTORE RESTRICT RETURN

REVOKE RIGHT ROLLBACK

ROWCOUNT ROWGUIDCOL RULE

SAVE SCHEMA SELECT

SESSION_USER SET SETUSER

SHUTDOWN SOME STATISTICS

SUM SYSTEM_USER TABLE

TEXTSIZE THEN TO

TOP TRAN TRANSACTION

TRIGGER TRUNCATE TSEQUAL

UNION UNIQUE UPDATE

UPDATETEXT USE USER

VALUES VARYING VIEW

WAITFOR WHEN WHERE

WHILE WITH WRITETEXT

アプリケーション内で動的 SQL 文を生成、発行している場合には、特に、SQL 文を生成する文字列の

中で、SQL Server の予約語が入っていないかを確認し、｢"｣、( ダブルクォート )で囲む必要があります。

予約語対応の例(変換前)

Private Const sSQLText As String = _

“SELECT “ & _

“REF, ITEM_TYPE, BRAND, “ & _

“DSTA_DY, DEND_DY, CASE, “ & _

予約語対応の例(変換後)

Private Const sSQLText As String = _

“SELECT “ & _

“REF, ITEM_TYPE, BRAND, “ & _

“DSTA_DY, DEND_DY, “ & _

“””CASE”” , “ & _

SQL Server 予約語対応を行った SQL 文については、次の注意点が必要です。

SQL Server Management Studio でクエリを実行し、エラーとならないことを確認する。

Oracle で同一処理を行った結果が、同じであることを確認する。

27

5.5.5. Oracle - SQL Server 機能移行

SQL Server 2012 と Oracle 11g の Enterprise Edition での機能対比を以下に示します。

カテゴリ主な機能 SQL Server Oracle 備考

システム構

成

高可用性 AlwaysOn Oracle Data Guard Redo Apply

AlwaysOn Active Secondery

Oracle Active Data Guard Oracle Enterprise オプショ

ン

Database Snapshot Oracle Data Guard Snapshot Standby

AlwaysOn Log Stream Compression

Oracle Data Guard Network Compression

Oracle Enterprise オプショ

ン

スケーラビ

リティ

※ Oracle Real Application Clusters SQL Azure TSO(Transparent

Scale Out)にて対応

Resource Governor Automatic Workload Management

In-memory OLTP TimesTen In-memory database cache

SQL Server と Oracle Database とは、その設計思想やアーキテクチャが異なるため、完全に同じ機能が存在

しない場合があります。Oracle から、SQL Server へ移行を検討する際には、移行方式、処理方式の再検討が

必要となる機能もあります。

Real Application Clusters については、遠隔地においても共有ディスクなし(シェアードナッシング)

で、迅速な自動フェールオーバーを実現可能な、SQL Server 2012 AlwaysOn で代替することが可能

です。


Oracle 機

能

セキュリ

ティ

Transparent Database Encryption

Oracle Advanced Security Oracle Enterprise オプション

Label Security Toolkit (Codeplex)

Oracle Label Security SQL Server 全エディション

サポート/Oracle Enterprise

オプション

Partitioning Oracle Partitioning Oracle Enterprise オプショ

ン

※ Function-based index

Bulk operations Parallel Data Pump Export Import




Function-based index は、Oracle と SQL Server の索引(INDEX)におけるアーキテクチャが異なる

ため、該当オブジェクトの実行計画を取得し、SQL 文に対し、最適な索引を作成することを検討

する必要があります。

28


運用開発プラッ

トフォーム

T-SQL

PL/SQL

SQL Server Data Tools SQL Developer

Sqlcmd

SQL*Plus

管理 SSMA Oracle Configuration Management Pack

Oracle Enterprise オプショ

ン

Activity Monitor

Oracle Diagnostic Pack Oracle Enterprise オプショ

ン

Database Tuning Advisor

Oracle Tuning Pack Oracle Enterprise オプショ

ン

ネットワー

キング

Connection Pooling Connection Pooling

コンテンツ

管理

Full Text

Oracle Text

※ File Table




File Table は、Bulk insert 機能を利用することで、代替することが可能です。

5.5.6. データ移行

Oracle から SQL Server へのデータ移行は、SSMA の｢ Data Migration ｣、機能を利用し、直接データ移行

方式を採用しました。

Oracle から SQL Server へのデータ移行は、Input となる対象のテーブルにのみ行い、Oracle と同一処理を

実行した結果、Output となるテーブルに作成されたデータが同じであることを、システム運用と並行して

行っています。

Oracle から SQL Server へデータ移行を行った際の注意点を次に示します。

OS の違いや文字コードの違いなど移行前後の環境によって文字化けが発生することがあるため、

データ移行前には、環境に合わせて文字化けする文字の洗い出しが必要になります。

Oracle の NUMBER 型は桁指定なしでテーブルを作成することが可能です。事前にデータ内容を洗

い出し、移行先の SQL Server で、全てのデータが問題なく収まるように、適切なテーブル定義を

指定するようにします。

NULL の扱いは、Oracle と SQL Server でソート結果の違いや、データ比較の違いとして現れるた

め注意が必要です。

Oracle では、空文字と NULL を同じ値として扱うため、クエリ内で｢IS NULL｣、句の結果に差異が

出るといった影響があります。 NULL を意識する必要があるデータ移行には、注意が必要です。

29

5.6. 今後の展望

今後の方向性について、お客様は｢企業全体の方向性として、仮想化をさらに推し進めていくこと。それも

各事業会社が小さな仮想化を行うのでなく、グループ全体を包括する大きな仮想化がテーマになります｣、

と展望を語ります。そして、現在行っている、Oracle との並行稼働の結果、SQL Server への移行が完了し、

マルチインスタンス方式におけるシームレスなシステム連携がスムーズに動き出せば、Windows Azure へ

の取り組みも開始される予定となっています。

また、費用面についても、今回のシステム移行で、保守費用だけでも半分近くとなり、グループ企業全体で

は数千万円規模の圧縮効果が出ていくと見積もっています。加えて BCP/DR という面からは、物理サーバ

から仮想環境への移行で耐障害性が大幅にアップできる点も注目されます。

Windows Azure の新機能である、IaaS 機能による運用提案も行っており、運用面に関しては予算化も進ん

でいます。

今回の SQL Server への移行が完了してシステム連携がうまく動き出せば、お客様の IT 戦略は更に新しい未

来に向けて、着実に加速していきます。

30

6. その他の移行事例

ここでは、上記解説とは別のお客様のシステムの移行事例を説明します。

製造業のお客様で、Oracle から SQL Server への移行を行ったことで、データ量の増大を見込み、拡張性と

可用性を確保し、システムパフォーマンスを大幅に向上、コストダウンも併せて実現しました。

31

6.1. システム概要

お客様が顧客企業に対して提供する委託業務(各種 DM をはじめ請求/支払明細書といった、年間数十億通

以上の宛先毎に内容の異なる製品を製造・出荷するサービス)のトレーサビリティ状況を、1 通単位、ピン

ポイントで照会でき、抜取や再発行の指示ができる WEB システム。この WEB システムで、委託業務の信

頼性を高めることでビジネスの拡大に役立てています。また、SQL Server と Oracle の連携を事前に確認し、

問題がないことを明確に示した上で顧客企業との連携テスト、本格稼働を開始しました。

6.2. システムの現状

お客様が構築した Oracle でのフロントエンド系システムで、稼働年数を重ねるごとに抱えていった課題は、

以下の通りとなります。


ビジネス拡大に伴うデータ量の増大

顧客対応力の強化

運用コスト増加の懸念

フロントエンド系システムは、初期の扱い量を想定して設計・構築されましたが、委託業務の拡大に伴うデ

ータ扱い量の増加により、システムのパフォーマンスに課題発生の可能性が予見されました。また、大量の

データ扱い量が見込まれる新たな顧客企業のニーズに応えるためには、旧システムの改修・チューニングで

32

は限界があり、新たなアーキテクチャによるシステムへのリプレイスと、これまでに顧客企業から要望のあ

った機能の新規追加が必要であると判断されました。

Oracle の継続利用を想定した場合、EE、および、各種オプション利用が必須となり、莫大なコストが必要

となることが予測されました。

6.3. システム移行の背景・新システム構築の目的

お客様は、大量データでも高レスポンス検索を実現可能となる顧客満足度の向上が見込める設計、拡張が容

易なシステムを構成し、業務拡大時のコスト増加対策、高いユーザビリティの確保と問題発生時の迅速な調

査と原因究明が可能な構成、連携している他システムが改修となった場合でも影響を受けないシステムでの

構築、といったポイントでのフロントエンド系システムの移行を決定しました。

当社では、データベースコンサルの知見を基に、SQL Server 移行に当たっての技術検証と、日本マイクロ

ソフト社大手町テクノロジーセンターでの実地検証を経て、システムのマイグレーションを行い、旧システ

ムに比べ大きくパフォーマンスを改善したシステムとしてリリースしました。

フロントエンド系システム再構築の提案のポイントは、以下の通りとなります。

新システム再構築ポイント

大量データの高レスポンス検索を達成し、お客様の満足度を向上させる

拡張性の容易なシステム構成とし、業務拡大時のコスト増大を防ぐ

連携している他システムの改修が発生しても、可能な限り影響の受けないシステムを構築する

高いユーザビリティの確保

高レスポンスを実現するための DBMS の選択と DB 構造設計、方式設計を行い、可用性と拡張性にも対応

しました。柔軟で安定したデータモデルの構築、変更を見越した処理方式を考慮し、高機能で、メンテナン

スにも優れた開発フレームワークを利用した新システムを構築しました。

6.4. システムパフォーマンスの確保

新システムのパフォーマンス目標性能を以下の通り設定し、当社では、日本マイクロソフト社大手町テクノ

ロジーセンターでの SQL Server パフォーマンス検証を実施しました。

新システム目標性能

企業数 100 社

物件数 200 物件

同時接続(セッション)数 1,000 名

1 社当たり最大データ件数 1 億件( 2 年間保持)

利用時間 9:00～18：00(営業日)

件数結果の表示は、概ね 5 秒以内を目標とする

将来的なオーダー増加に備え、容易にスケールアウト可能な構成とする

33

大手町テクノロジーセンターで検証した H/W 構成を以下の図に示します。

旧システムのテーブル構造を見直し、SQL Serve r の設定、および、INDEX の最適化を行い、1 億 5 千万件

と 7 億 5 千万件を含む 10 テーブルを結合した抽出で、キャッシュヒットの場合、1 秒以内、キャッシ

ュされていない場合でも、2 秒前後のパフォーマンスを実現し、｢結果表示 5 秒以内｣、という性能目標を

大幅に達成しました。

6.5. SQL Server – Oracle の連携技術 Oracle Gateway

フロントエンド系システムの SQL Server 化を実現した場合、問題となったのは、バックオフィス系システ

ムとの DB 連携でした。

Oracle では、DB Link を利用したシステム連携を行っていましたが、システム移行前に、当社 DB 技術コ

ンサルティングチームにより、連携技術の事前確認を行い、ほぼリアルタイムでのデータベース連携が可能

となりました。

このデータベース連携技術の入念な事前確認で、以下の技術を利用することでフロントエンド系システムと

バックオフィス系のシステムでのデータベースが、安全で確実に連携可能であることを実証しました。

SQL Server から Oracle 参照 ⇒ Link Server を利用した OPENQUERY 関数の使用

Oracle から SQL Server 参照 ⇒ Oracle Gateway を使用

34

6.6. RDBMS の選択 –Oracle → Next?? –

システム性能検証を行い、RDBMS が SQL Server でも、パフォーマンスの確保が可能であること、バック

オフィス系システムの Oracle と、フロントエンド系システムの SQL Server とで DB 連携が実現可能であ

ることを実証しました。

システム検索の検索性能、システム可用性、拡張性のそれぞれを、Oracle と SQL Server で比較した結果、

初期費用を抑えつつ、拡張性の高いシステム構築が可能な SQL Server を御採用されました。

Oracle SQL Server

検索性能テーブル・パーティションテーブル・パーティション

システム可用性 Real Application Clusters(RAC) Microsoft Failover Cluster Service(MSFC)

システム拡張性 RAC ノードとストレージ追加によるスケー

ルアウト方式

ユーザ毎にパーティション分割で対応し、性能

限界点(CPU、データ容量)に達した場合は、サ

ーバ単位で増設するスケールアウト方式

フロントエンド系システムバックオフィス系システム

35


お客様では、今後も処理量が増大することを踏まえ、パフォーマンス低下を回避するために、バックオフィ

ス系のシステムについても、新システムへの移行の検討を始めています。バックオフィス系システムの更な

る処理効率改善と、拡張性の向上を目的として、現在利用している Oracle から、SQL Server への移行を計

画しています。そこでは、フロントエンド系システムの SQL Server 導入の経験を踏まえて、SQL Server を

候補に 2012 年度中には新システムへの移行へと着手する見込みです。また、Oracle から、SQL Server へと

安全で確実にデータベース連携が可能であることが実証されたため、複数 Oracle を利用し、それぞれが密

接にシステム連携している構成のシステムにおいても、今回の経験を通して、技術面において SQL Server

へと確実に移行が可能であることを実証しました。OMA を併用することで、Oracle の単独移行はもちろん

のこと、Oracle から SQL Server への段階的な移行を安心して計画することが出来ます。

新システムで、SQL Server の最大の導入効果は、検索パフォーマンスが大幅に向上したことです。1 件あ

たりの検索速度向上はもちろんのこと、連携している他システムのデータ取り込みに時間がかかり、他シス

テム側で処理が完了しているにもかかわらず、データの反映が遅延するという問題がなくなり、顧客企業へ

提供する情報の即時性が高まりました。

また、検索速度の低下や切り分けが難しいトラブルの解消と併せて、業務拡大時のコスト増大を防ぐために

も、SQL Server へ移行する目的をお客様にご理解いただきました。将来的にはシステムのクラウド化など、

より低コストで冗長性の高いシステム運用を図っていくことを検討しています。

37

7. 移行検討中事例

ここでは、OMA を実際に利用し、お客様が現在保有する Oracle 資産の統合方法、および、コスト削減の

実現に向けて行った OMA の事例を説明します。

7.1. 概要

2014 年度に、サーバ切替となり、今後、災害/障害対策を考慮し、業務システムのクラウド化も検討してい

るお客様の OMA を実施しました。

複数拠点で運用している Oracle の運用コストの可視化、削減額の提示を求められ、基本サービスである、

アセスメントに加え、複数拠点で運用中の業務システムの DB サーバの統合(案)、および、Oracle と SQL

Server の連携方式を提案しました。

現在、SQL Server 2012 の導入、システム移行を前向きに検討いただいています。

7.2. 課題整理

複数の業務システムが、Oracle の DB Link によって連携し、Oracle のサポート費用削減を検討中のお客様

の OMA 実施に当たり、課題の整理が必要となります。

評価対象とする Oracle インスタンスの選定と、複数拠点で運用中の業務システムの確認を行い、各業務シ

ステムの開発言語、利用 RDBMS の確認、Oracle の利用用途についての確認、整理を行い、その後、現状

の各業務システム間の連携方式についての確認を行った結果、お客様が抱える課題を、以下の通り整理しま

した。


パッケージ利用を含む、多様な言語で開発されたシステム管理性の煩雑化

業務ごと、個別最適化された、複数物理サーバの肥大化

システムの老朽化、複数物理サーバによる、運用リスクの増大

複数物理サーバがそれぞれ保有する Oracle の運用コストの増大

7.3. 評価内容

お客様が抱える、現状の課題に対する解決方法の提案という視点での評価では、SQL Server が持つ、ライ

センス体系や仮想化を含めたソリューションのメリットを十分に活用しきれないと判断しました。各業務シ

ステム間の連携方式から、現在運用中であるシステムの本来あるべき姿を整理していった結果、以下のポイ

ントを評価し、SQL Server 導入時の効果を整理しました。

評価ポイント

システムの現状とコストリスクの可視化

導入・運用保守コストの可視化

データベースサーバ集約・統合の可視化

38

Oracle と、SQL Server との連携方式の可視化

SQL Server 導入時の効果

複数物理サーバの統合による TCO(Total Cost Ownership) 削減

現状システムを、Oracle で 5 年間継続利用した場合と比較し、数千万円のコスト削減

SQL Server 2012 AlwaysOn での運用で、無停止・高可用性確保、ミッションクリティカルな業務を

IT がバックアップ

オンプレミスと Windows Azure SQL Database の可能性と、複数拠点にまたがる、災害・障害対策

を見据えたデータ保護

39


お客様は、さまざまな業務からの要求に基づき、個別最適により物理サーバの増設、業務システムの構築を

行っていましたが、サーバ台数が増えれば増えるほどトラブルの発生確率が高まり、その対応に追われてい

る状況でした。業務システム、サーバが老朽化していくにつれ、運用リスクはますます増大することとなり

ます。

これらの業務システムの中には、ミッションクリティカルな業務を担っているものもあり、仮にシステム

ダウンを起こした場合、ビジネス上の損害を招く恐れがあります。また、事業拡大に伴い、扱うデータ量も

増大していく傾向にありました。

OMA を実施した結果、データベースサーバ統合と、SQL Server 導入におけるコストメリットを実感して

いただき、また、Oracle と SQL Server の連携方式が確立されていることで、データベース移行に向け、予

算を作りながら段階的な実施が計画していけるという安心感を持っていただくことが出来ました。現在、

2014 年度のサーバ切替に向けた準備として、予算確保、および、データベースの SQL Server 移行を前向

きに検討しています。

40

8. その他の主なポイント

ここでは、当社が実施した OMA 評価結果の中から、特筆すべき内容を記載します。

8.1. 単純移行コスト

OMA 評価対象データベース情報

構成：Oracle Real Application Clusters(RAC)

テーブル数：156

索引数：154

プロシージャ数：5

システム規模：全国 300 ユーザ

上記は、業務システムで利用している Oracle となります。Oracle からの単純移行コストが 3 日弱と算出

されました。Oracle RAC 機能を利用し、可用性向上を実現しているシステムですが、Oarcle 独自機能を利

用しておらず、また、オブジェクトなどの修正箇所が極めて少ないため、データベース移行工数としては、

非常に些少な結果となりました。

OMA 評価対象データベース情報

構成：SINGLE インスタンス(パッケージ利用)

テーブル数：509

索引数：382

プロシージャ数：309

導入実績：全国約 100 社

上記は、パッケージシステムで利用している Oracle となります。Oracle からの単純移行コストが 7 か月

強と算出されました。SINGLE インスタンス構成となっていますが、プロシージャの修正箇所が非常に多く、

データベース移行工数としては、非常に膨大な結果となりました。

上記二つの構成を比較した結果、必ずしも SINGLE インスタンス、RAC といった構成が、単純移行コスト

に直接影響を与えるものではなく、Oracle 独自機能を利用している割合や、データベース構造の複雑度合

によって、単純移行コストの差が大きく変わってきます。Oracle に対して必要となる移行コストは、より

単純な構成、データベース構造で実装されているかがポイントとなります。

41

8.2. アプリケーション SQL

アプリケーション SQL 評価対象情報

SQL 取得期間：約 1 か月

評価 SQL 本数：約 11,000 本

修正パターン数： 4 パターン

約 11,000 本の SQL を SSMA で評価した結果、Oracle 独自関数や独自機能が利用されておらず、些少な

修正に留まりました。

アプリケーション SQL 評価対象情報

SQL 取得期間：約 5 時間

評価 SQL 本数：約 5,000 本

修正パターン数：20 パターン

約 5,000 本の SQL を SSMA で評価した結果、Oracle 独自関数や独自機能の利用が多く、膨大な修正とな

りました。

上記二つの SQL を比較した結果、SQL の本数に関わらず、Oracle 独自関数や独自機能を多用するシステ

ムが構築されている場合、SQL の修正ボリュームが大きく変わってきます。業務システムの移行は、単純

なデータベース構成/ SQL 文で実装されているかがポイントとなります。

8.3. パフォーマンス

パフォーマンス評価対象情報

SQL 取得期間：約 2 か月

取得 SQL 本数：約 14,000 本

チューニング検討 SQL 本数： 26 本(内、ボトルネックの高い SQL が 6 本)

チューニングの検討が必要な SQL 26 本は、CPU 使用率を 90% 以上も消費し、データベースサーバに対

し、高い負荷を掛けています。パフォーマンス・ボトルネックの主な原因は、以下の通りとなります。

分類原因推奨対応方法

CPU 使用率過多実行回数に対する、CPU 使用率過多処理方式/ SQL の見直し

実行回数が異常に多い処理方式の見直し

同一形式 SQL バインド変数定義がされていない、類似 SQL 文の

多用

SQL の見直し、バインド変数の定義

索引定義 1 実行での取得行数に対する、処理を行った論理

ブロックが異常に多い

テーブルに対する索引定義の見直し

アプリケーション待機更新系 SQL 文の同時実行による、アプリケーショ

ンのロック待機時間過多

処理方式、同時アクセス運用について

の見直し

42

SQL に関しては、移行前に問題が潜在していたのか、SQL Server 移行後に問題が発生したかの切り分けを

明確にする必要があります。

SQL Server へ移行を実施する前に、パフォーマンス・ボトルネックとなる SQL を Oracle 上で分析/チュー

ニングが必要となります。また、SQL Server 移行後も継続的なチューニングを推奨します。

43

9. まとめ

現在、お客様が業務システムのデータベース領域で抱えているコスト面、運用面、構築手法における問題・

課題の整理と、それらに対する解決策を明確にすることが OMA の目的となります。

OMA を利用するお客様が抱える課題の多くは、以下の通りとなります。

お客様の抱える課題・不安要素

データベース移行に必要となる工数(コスト)

業務システムの移行に必要となる工数(コスト)

データベース移行後の運用工数(コスト)

SQL Server 移行後の処理性能

他システム(Oracle)連携

サーバ統合・仮想化

移行可用性評価、コスト評価に加え、業務システムの移行評価やサーバ集約・統合の評価、現行データベー

スの棚卸、現行システムの使用状況の確認も行えるため、移行事例に見られるようなシステム移行へ踏み切

ることが可能となります。また、他システムで Oracle を利用している場合、SQL Server との連携において

も、技術面での課題は解消しているため、安心して移行を行うことが可能となります。

OMA により、業務システムで行うべき処理、データベースで行うべき処理の切り分けが可能となり、デー

タベース本来の在り方が見えてきています。お客様のニーズに対応していく取り組みが OMA の付加価値

となり、SQL Server 導入・システム移行をより前向きにご検討いただく契機となっています。

5 章にある、卸売・小売業・飲料業のお客様の事例では、OMA を実施したことで、移行プロジェクトの全

体的なコストのボリューム感、マイグレーションプランを把握した上で、一番大きな課題となっていた確

実な業務システムの移行を実施し、現在は Oracle とのへ移行稼働による最終検証を行っています。データ

ベースが、Oracle から、SQL Server 2008 R2 へと統一されたことで、アーキテクチャの保守性やユーザビ

リティも一新され、情報ツールとしての機動性が向上しました。国内と海外のデータベースにおいて、同一

プラットフォームによる稼働で、完全にシームレスな情報連携が実現しました。同一ツールでのデータ参照

が可能となったことで業務効率がアップし、今後、運用保守作業の自動化が期待されています。

6 章にある、製造業のお客様の事例では、年間 1 億数千万件を取り扱う大規模案件での運用も始まってい

ます。特に最近では、顧客企業が、コア業務に集中するために、自社の社内帳票も含め、全てアウトソーシ

ングしたいという案件が増えてきています。また、新システムを既に利用している顧客企業からは高い評価

を得ています。その裏には、DBMS を Oracle から SQL Server への移行があり、その最大の導入効果は、

パフォーマンスが大幅に向上したことにあります。また、複数のデータベースが絡んでいて、一度に SQL

Server へと移行が難しいケースでも、Oracle と SQL Server を連携させて、段階的な移行が可能となりま

す。

44

7 章にある、移行検討中事例に見られるような、業務拡大時のコスト増大を防ぐためにも、企業内に分散し

ている各種サーバを、仮想化などのテクノロジを利用してハイスペックなハードウェアに統合する｢サーバ

統合｣、は、コンプライアンス強化やコスト削減のメリットから、現在非常に多くの企業が検討しているテ

ーマとなります。しかし、統合後のシステムリソースの競合やパフォーマンス低下など、大きな問題も懸

念されます。Oracle で問題解消を実現しようとした場合、別料金オプションの購入が必要となりますが、

SQL Server は、システムリソースの適切なコントロールを実現する機能(リソースガバナー）やパフォーマ

ンス低下のボトルネックをグラフィカルに把握できるレポート機能(パフォーマンスデータコレクション）

などを標準装備しています。

サーバ統合の大きなメリットの 1 つは、コストの削減です。こうしたサーバ統合のコストシミュレーショ

ン結果を受け取れるのも、当社 OMA を利用するメリットとなります。

今後も、Oracle からの移行可用性評価、コスト評価に留まらず、高付加価値(お客様のニーズに対応する)の

OMA を実施し、SQL Server 導入・移行に向けた施策を展開が必要となっています。

以上

oracle migration assessment 移行事例解説. 現行システム使用状況..... 7 4.3....

Documents