sql server 2012...
TRANSCRIPT
SQL Server 2012 徹底検証シリーズ
ユーザーベネフィットを追求した
Oracle Database & Java から SQL Server & Java へのマイグレーション
Published．2013 年 6 月 17 日
2
© 2013 Microsoft Corporation. All rights reserved.
本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoft は絶えず変化する市場に対
応しなければならないため、ここに記載した情報に対していかなる責務を負うものではなく、提示された情報の信憑性については保証
できません。
本評価ガイドは情報提供のみを目的としています。Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものでは
ありません。
すべての当該著作権法を遵守することはユーザーの責務です。Microsoft 書面による明確な許可なく、本書の如何なる部分についても、
転載や検索システムへの格納または挿入を行うことは、どのような形式または手段 (電子的、機械的、複写、レコーディング、その他) 、
および目的であっても禁じられています。これらは著作権保護された権利を制限するものではありません。
Microsoft は、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoft
から書面によるライセンス契約が明確に供給される場合を除いて、本書の提供はこれらの特許、商標、著作権、またはその他の知的財
産へのライセンスを与えるものではありません。
Microsoft、Windows、MSDN、Visual Studio、SQL Server は、米国および (または) その他の国において、Microsoft Corporation の登録商標
または商標です。
その他記載されている実際の社名および製品名は、各社の商標です。
Microsoft Corporation ・ One Microsoft Way ・ Redmond、 WA 98052-6399 ・ US
3
目次
第 1章 現状のシステムまたはビジネスの問題点 ........................................................ 5
1.1 現状のシステム .................................................................................................... 5
第 2章 RFP (Request for Proposal：提案依頼書) ................................................. 6
2.1 RFP (提案依頼書) の内容 ....................................................................................... 6
2.1.1 リプレースに関する必須要件 ............................................................................. 6
第 3章 RFP に対する SQL Server 2012 のソリューション ..................................... 7
3.1. Oracle Database から SQL Server 2012 への移行作業 ............................................. 7
第 4章 ソリューションの検証 (移行検証) ............................................................... 9
4.1 検証環境 ............................................................................................................. 9
4.2 検証対象のアプリケーション .................................................................................. 10
4.3 Oracle Database から SQL Server 2012 への移行検証 ............................................. 11
4.3.1 Oracle Database から SQL Server への移行検証結果 .......................................... 11
4.3.1.1 データベース オブジェクトの移行検証結果 ................................................... 11
4.3.1.2 データの移行検証結果 .............................................................................. 14
4.3.1.3 アプリケーションの移行 (Java アプリケーション) 検証結果 ............................ 14
4.3.1.4 アプリケーションの移行 (バッチ アプリケーション) 検証結果 ......................... 15
第 5章 ソリューション検証 (パフォーマンス検証) .................................................. 18
5.1 Web アプリケーションのパフォーマンス検証 ............................................................ 18
5.2 バッチ アプリケーションのパフォーマンス検証 ......................................................... 24
第 6章 まとめ ................................................................................................. 31
付録 A ソリューション内にある技術解説 (移行手順) ............................................... 33
A.1 移行前の SSMA 設定 ........................................................................................... 33
A.2 データベース オブジェクトの移行手順 ..................................................................... 38
A.2.1 評価レポートの作成 ...................................................................................... 38
A.2.2 データベース オブジェクトの移行 ................................................................... 42
A.3 データの移行 ..................................................................................................... 48
A.3.1 データの移行 ................................................................................................ 48
A.3.2 データ件数のチェック .................................................................................... 52
A.3.3 データのチェック .......................................................................................... 53
A.4 Java アプリケーションの移行 ................................................................................ 59
A.4.1 接続設定の移行 ............................................................................................. 59
4
A.4.2 Java アプリケーションの移行 .......................................................................... 61
A.5 バッチ アプリケーションの移行.............................................................................. 67
A.5.1 Korn シェルスクリプトの移行.......................................................................... 67
付録 B データベース移行 Tips 集 ....................................................................... 72
B.1 データベース移行 Tips ......................................................................................... 72
5
第 1章 現状のシステムまたはビジネスの問題点
1.1 現状のシステム
ある架空のユーザー企業「X 社」では、メーカーとして小売業者に対するインセンティブを精
算するシステムを導入しています。この精算システムは、データベースに Oracle Database 、
アプリケーションは Java を使用して開発されており、運用から数年が経過し、ハードウェアの
リプレースを翌年に控えている状況です。
「X 社」ではリプレース時のコスト、及びリプレース後の運用コストをできるだけ抑えたいと考
えています。
6
第 2章 RFP (Request for Proposal：提案依頼書)
「X 社」から依頼を受けた「RFP」 (Request for Proposal：提案依頼書) の内容は、次のとおり
です。
2.1 RFP (提案依頼書) の内容
「X 社」からの RFP (提案依頼書) では、以下に関して、具体的な実現手段を求められていま
す。
ハードウェア老朽化に伴うシステム更改
今後 5 年間の運用コストの削減
2.1.1 リプレースに関する必須要件
リプレースの際には、以下の項目を満たしていることが必須要件となります。
現行のシステムと同等の機能を有すること
現行のシステムを目標値として同等かそれ以上の性能が得られること
リプレース後 5 年間の運用コストを現行以下に抑えること
7
第 3章 RFP に対する SQL Server 2012 のソリューション
「X 社」からの RFP (提案依頼書) に対して、「A 社」では SQL Server 2012 でのソリューショ
ン (具体的な解決策) を検討しています。
3.1. Oracle Database から SQL Server 2012 への移行作業
「A 社」が検討している Oracle Database から SQL Server への移行ソリューションをまとめ
ると、次のようになります。
(1) データベース オブジェクトの移行
データベース オブジェクトは、Microsoft SQL Server Migration Assistant (SSMA) を使用して自
動変換します。SSMA を使用することで、Oracle Database 固有のプログラミング言語である
PL/SQL も SQL Server のプログラミング言語である Transact-SQL に自動変換することができ
ます。
(2) データの移行
Oracle Database に格納されているデータを、SSMA を使用して SQL Server に移行します。
(3) アプリケーションの移行
このシステムでは、Web アプリケーションとバッチ アプリケーションが稼働しており、今回
はそれぞれのアプリケーションの中のいくつかの機能をピックアップして移行検証を実施して
います。
8
Web アプリケーション
当該環境の Web アプリケーションは、Java を使用しています。
Java のソースは以下を変換しています。
1. 接続設定を変更
2. Java で実行されている SQL 文を SSMA で自動変換 (ロジックについては変更しな
い)
バッチ アプリケーション
当該環境のバッチ アプリケーションは、Korn シェルスクリプト内で SQL スクリプトを実行
しています。Korn シェルスクリプトは Windows PowerShell に手動で変換し、SQL スクリプ
トは SSMA を使用してソースを変換します。
(4) パフォーマンステスト・SQL Server への最適化
移行後のアプリケーションを実行し、問題が発生した処理を最適化します。SSMA で自動変換
したままだと Oracle Database のデータベース オブジェクトをそのまま SQL Server に移行し
ていることになり、移行後のアプリケーションのパフォーマンスに問題が発生してしまうケー
スがあります。このような場合、移行後に SQL Server の環境に合わせた形で最適化を実施す
る必要があります。
9
第 4章 ソリューションの検証 (移行検証)
この章では、SQL Server 2012 を使用したソリューションの有効性を確認する為、移行検証を実
施し、その結果を記載しています。
4.1 検証環境
検証に利用した環境の構成は、次の通りです。
検証環境のソフトウェアは次の通りです。
サーバー ソフトウェア 詳細
DB サーバー (Oracle Database )
OS Windows Server 2012
Database Oracle Database 11g Enterprise Edition 11.2
Shell Windows PowerShell 3.0
DB サーバー (SQL Server)
OS Windows Server 2012
Database SQL Server 2012 Enterprise Edition
SSMA SSMA for Oracle 5.2 Extension Pack
Oracle Client Oracle Database 11gR2 Client 11.2
Shell Windows PowerShell 3.0
AP サーバー
OS CentOS6.3
HTTP Server Apache HTTP Server 2.2.23
Servlet
Container
Apache Tomcat 6.0.36
JDK Java SE Development Kit 6 Update 37
JDBC Driver Microsoft JDBC Driver 4.0 for SQL Server
負荷クライアント
OS Windows 7
JDK Java SE Development Kit 6 Update 37
Test Tool Apache JMeter 2.8
SSMA用クライアント
SSMA SSMA for Oracle v5.2
Oracle Client Oracle Database 11gR2 Client 11.2
SSMS SQL Server Management Studio 2012
10
検証環境のハードウェアは次の通りです。
サーバー ハードウェア 詳細
DB サーバー (Oracle Database )
CPU Xeon (R) CPU W5560 @ 2.80GHz 2.80GHz クアッドコア 2
セット
メモリ 36GB
ストレージ 146GB × 15,000 回転 × 8 本
DB サーバー (SQL Server)
CPU Xeon (R) CPU W5560 @ 2.80GHz 2.80GHz クアッドコア 2
セット
メモリ 36GB
ストレージ 146GB × 15,000 回転 × 8 本
AP サーバー
CPU Xeon (R) CPU W5560 @ 2.80GHz 2.80GHz クアッドコア 2
セット
メモリ 8GB
ストレージ 250GB × 7,200 回転
クライアント CPU Xeon (R) CPU W3540 @ 2.93GHz 2.93GHz クアッドコア
メモリ 8GB
4.2 検証対象のアプリケーション
本章で検証するアプリケーションは、Web アプリケーションとバッチ アプリケーションの以
下機能について検証を実施しています。
Web アプリケーション
契約情報照会/修正機能
一般的な一覧検索・照会画面～会社間の基本的な契約情報を更新する機能。
更新処理では 1 件毎の UPDATE を複数テーブルに対して実行。
開発言語として Java を使用。
O/R マッピング フレームワークとして iBATIS を使用。
11
バッチ アプリケーション
販売実績集計機能 (2 本)
販売実績データ登録処理
蓄積された販売実績データを、販売日別に集計する機能。
データマート作成処理
集計された販売実績を、契約単位別に展開する機能。
バッチ開発言語として Korn シェルスクリプトを使用。
4.3 Oracle Database から SQL Server 2012 への移行検証
Oracle Database から SQL Server への移行については、以下の項目を検証しました。
4.3.1.1 データベース オブジェクトの移行
4.3.1.2 データの移行
4.3.1.3 アプリケーションの移行 (Web アプリケーション)
4.3.1.4 アプリケーションの移行 (バッチ アプリケーション)
4.3.1 Oracle Database から SQL Server への移行検証結果
Oracle Database から SQL Server 2012 への移行検証の結果は、次のようになりました。
検証項目 章番号 結果
データベース オブジェクト 4.3.1.1 ○
データ 4.3.1.2 ◎
アプリケーション (Web アプリケーション) 4.3.1.3 ○
アプリケーション (バッチ アプリケーション) 4.3.1.4 ○
◎: 移行可能 (変更不要) ○: 移行可能 ×: 移行不可能
移行時に注意が必要な事項は各項に記載しております。
4.3.1.1 データベース オブジェクトの移行検証結果
ここでは、Oracle Database から SQL Server 2012 へのデータベース オブジェクトの移行検証
結果について説明します。
12
(1) 移行方法
Oracle Database のテーブルや PL/SQL などのデータベース オブジェクトは、Microsoft SQL
Server Migration Assistant for Oracle (SSMA) を利用して移行を行います。移行手順の詳細につ
いては、付録 A の A.2 に記載しています。
Microsoft SQL Server Migration Assistant for Oracle (SSMA)
SQL Server Migration Assistant for Oracle (SSMA) は、Oracle Database から SQL Server への移
行を支援するツールで、テーブルやインデックスなどの定義はもちろん、パッケージやプロシ
ージャなどの PL/SQL も SQL Server の Transact-SQL に変換し SQL Server に適用することが
可能です。
また、変換後に作成される評価レポートで、SSMA で変換できない箇所のチェックや、移行作
業にかかる作業ボリュームも確認することができます。
さらに、SSMA Extension Pack と呼ばれる拡張パッケージをインストールすることにより、
SQL Server にはない Oracle Database の関数や機能などがエミュレートした関数として生成さ
れ、SSMA で変換した時に自動で適用されるようになります。
SSMA は、マイクロソフトのホームページからダウンロードすることができます。2013 年 4
月時点では、SQL Server 2012 に対応した v5.2 が最新になります。
http://www.microsoft.com/en-us/download/details.aspx?id=28766
SSMA のインストール手順については、「Oracle から SQL Server 2012 への移行ガイド」の補
足に記載がありますので、そちらをご参照下さい。
(2) 移行結果
SSMA で変換した結果は以下の通りです。
オブジェクト
オブジェクト種類 オブジェクト
数
エラー発生
オブジェクト
数
チェック対象
構文数
変換不可
構文数
手動
修正時間
自動
変換率
Tables 260 1 2956 0 0.0 100.0%-
Indexes 48 1 48 1 0.5 97.91%
Sequences 2 0 2 0 0.0 100.0%
Views 7 5 441 322 8.4 26.98%
Synonyms 0 0 0 0 - -
合計 317 7 3447 323 8.9 90.62%
13
PL/SQL
オブジェクト種類 オブジェ
クト数
エラー発生
オブジェクト数
チェック対象
構文数
変換不可
構文数
手動
修正時間
自動
変換率
packages 44 40
325 14 12.1 95.69%
packaged-
functions
19 0
packaged-
procedures
149 124
packaged-
subtypes
2 0
packaged-
types
8 0
private-
packaged-functions
3 0
private-
packaged-procedures
141 27
合計 366 191 325 14 12.1 95.69%
ほとんどのオブジェクトについては SSMA を使用して自動変換することができましたが、
PL/SQL やインデックス等、一部のオブジェクトについては手動で移行を実施しています。
(3) 移行の留意点
SSMA で変換できないオブジェクトについては、移行時に手動で変換する必要があります。今
回の検証では、以下のようなケースを手動で修正しています。
PL/SQL
自動変換できない関数の使用と対処方法
TO_MULTI_BYTE 関数：ユーザー定義関数の作成で対処
REGEXP_REPLACE 関数：ユーザー定義関数の作成で対処
TO_TIMESTAMP 関数：CONVERT 関数で代用することで対処
インデックス
一部のインデックスが SSMA 上で認識されずエラーとしてもレポートに出力されない
実際のインデックス数は 236 個ですが、今回の検証では 188 個のインデックスが
SSMA で認識されませんでした。この為、SSMA を使用して SQL Server に移行する
時は、Oracle Database と SQL Server のオブジェクトの件数を比較し、チェックす
る必要があります。
また、リストパーティションなど、SQL Server にはない機能を使用している環境の場合、SQL
Server への移行時に対処方法を予め検討しておく必要があります。
14
データベース オブジェクト移行時の Tips については、付録 B の B.1 にまとめていますので
ご参照下さい。
4.3.1.2 データの移行検証結果
ここでは、Oracle Database から SQL Server 2012 へのデータの移行検証結果について説明し
ます。
(1) 移行方法
Oracle Database のデータを、SSMA を利用して移行を行います。移行手順については、
付録 A の A.3 に記載しています。
(2) 移行結果
SSMA を使用することで問題なくデータを移行することができました。
以下は、今回の検証で移行したテーブルのうち、最大データ保有テーブルを SSMA で移行し
た時の処理時間になります。
データ件数 列数 データサイズ 処理時間
最大データ保有テーブル 100,440,981 件 12 列 5.8GB 50 分 38 秒
(3) 移行の留意点
今回の検証では発生しませんでしたが、SSMA を使用して大量データを移行する場合、Session
Timeout が発生するケースがあります。このような場合は SQL Server Integration Services
(SSIS) 等、SSMA とは別のツールを使用してデータを移行する必要があります。
SSIS については、以下をご参照下さい。
http://msdn.microsoft.com/ja-jp/library/ms141134.aspx
4.3.1.3 アプリケーションの移行 (Java アプリケーション) 検証結果
ここでは、Oracle Database から SQL Server 2012 への Java アプリケーションの移行検証結
果について説明します。
15
(1) 移行方法
Java のソースから SQL 文が記述された箇所を抽出し、SSMA を使用してその SQL 文を SQL
Server の構文に変換します。移行手順については、付録 A の A.4 に記載しています。
(2) 移行結果
接続設定の変更と、SQL 文を修正することで、正常に動作することが確認できました。
(3) 移行の留意点
今回の環境では iBATIS を使用しており、SQL 文は XML ファイルに記載されている為、SQL
文の抽出は比較的容易ですが、環境によっては SQL 文がソースに直接記載されていることが
あります。このような環境では SQL 文の抽出や修正に時間がかかることがあります。
また、動的に SQL 文を組み替えるような処理もありませんでしたが、このような処理がある
場合、動的に作成された SQL 文が SQL Server で動作するかどうかを検証する必要がありま
す。
Oracle Database 固有の Java クラスを使用している環境の場合、同等のクラスの作成が必要
なケースがあります。
4.3.1.4 アプリケーションの移行 (バッチ アプリケーション) 検証結果
ここでは、Oracle Database から SQL Server 2012 へのバッチ アプリケーションの移行検証結
果について説明します。
(1) 移行方法
Korn シェルスクリプトを Windows PowerShell のコマンドに変換します。変換は、ロジック
の変更は行わず Korn シェルスクリプトのコマンドを Windows PowerShell のコマンドに変換
します (Korn シェルスクリプトと Windows PowerShell の対応については、付録 A の A.5 に
記載) 。Korn シェルスクリプト内で実行されている SQL スクリプトは、アプリケーションの
移行 (Web アプリケーション) と同様、SSMA を使用して SQL 文を変換します。自動で変換
できないものについては手動で変換します。
移行が正常におこなわれたかどうかは、バッチ アプリケーションで出力されるログから、同
一処理が同一の処理順序で実行されていること、出力されるログが同様に出力されていること
を確認します。
16
現行環境の販売実績データ登録処理バッチのログ
新環境の販売実績データ登録処理バッチのログ
※上記画面の SQL Server のログには、処理中にオブジェクトのリネームを行っている時の
警告メッセージが表示されていますが、処理自体は同様のステップで実行されています
また、バッチ アプリケーション実行時に作成されたデータについても、リンク サーバーを
使用して Oracle Database と SQL Server に接続し、データを比較して確認します。データの
比較方法については、付録 A の A.3.3 をご参照下さい。
(2) 移行結果の確認
Korn シェルスクリプトのコマンドを Windows PowerShell のコマンドに書き換え、SQL 文を
修正することで、正常に動作することが確認できました。
17
(3) 移行の留意点
バッチ アプリケーションの多くは、シェルスクリプト内で SQL スクリプトを実行し、その
エラーコードを取得するような処理である為、SQL スクリプトが変換できれば移行自体は比較
的容易です。ただし、バッチ アプリケーションは大量データを扱う処理が実行されるので、
パフォーマンスに問題が発生したり、処理が複雑だったりする傾向があります。この為、実際
の移行時は早い段階で移行を実施し検証することをお勧めします。
18
第 5章 ソリューション検証 (パフォーマンス検証)
この章では、移行したアプリケーションのパフォーマンス結果について説明します。具体的に
は、次の検証を行いました。
5.1 Web アプリケーションのパフォーマンス検証
5.2 バッチ アプリケーションのパフォーマンス検証
5.1 Web アプリケーションのパフォーマンス検証
ここでは、Web アプリケーションのパフォーマンス検証結果について説明します。
(1) 検証概要
Web アプリケーション内で実行される処理は以下の通りです。
Web アプリケーション 処理 処理の詳細
契約情報照会/修正機能 ログイン画面 ログイン画面の表示
ログインボタン ログインボタン押下
修正アンカー 修正アンカー押下
一覧表示ボタン 修正対象の一覧画面表示
番号アンカー 修正対象の番号アンカー押下
修正ボタン 修正ボタン押下
今回のテストでは、システムへのログインから、修正対象のデータを表示し、修正するまでの
処理で実行されるクエリを抽出し、Apache JMeter で実行しています。
また、検証パターンとして、性能テストと負荷テストを実施しています。
性能テスト
平均的なユーザー数、リクエスト数を想定したテストです。今回は 10 分間で 600 回の画面操
作が行われたことを想定しています ( 1 台の検証用 PC から 600 回実行) 。
19
負荷テスト
最大ユーザー数、リクエスト数を想定したテストです。今回は 10 分間で 4,800 回の画面操作
が行われたことを想定しています (4 台の検証用 PC から 1 台当たり 1,200 回実行) 。
パフォーマンス計測方法
パフォーマンスの計測方法は、次のとおりです。
各テストケースは 1 回とし、テスト実施前に ミドルウェアの再起動を実施
Apache JMeter によるテストを 10 分間実行 (初回のリクエストはクラスのロード、
JSP コンパイル等で時間がかかる場合があることを考慮)
20
Apache JMeter を 10 分間実行し、その処理時間を計測
Apache JMeter には、一般的なユーザーの画面操作を設定
クライアントからのリクエストは、Web/AP サーバーに対して実施
(2) 検証結果
上段は、性能テストの結果で、下段は負荷テストの結果になります。値は現行環境の処理時間
を 100 とした場合の相対値です。
性能テスト結果
負荷テスト結果
負荷テスト結果 (上記グラフから現行環境と最適化した新環境のみ抜粋)
0
100
200
300
400
合計 ログイン画面 ログインボタン 修正アンカー 一覧表示ボタン 番号アンカー 修正ボタン
現行環境
新環境(最適化前)
新環境(最適化後)
0
5000
10000
合計 ログイン画面 ログインボタン 修正アンカー 一覧表示ボタン 番号アンカー 修正ボタン
現行環境
新環境(最適化前)
新環境(最適化後)
0
100
200
300
400
合計 ログイン画面 ログインボタン 修正アンカー 一覧表示ボタン 番号アンカー 修正ボタン
現行環境
新環境(最適化後)
21
グラフは、現行環境と、最適化をする前の新環境 (最適化前) 、最適化後の新環境 (最適化後)
で実行した結果です。
結果、最適化前の新環境ではほとんどの処理で現行環境の目標値と大きな差がありましたが、
最適化を実施したことにより現行環境の目標値とほぼ同程度になり、画面上からはほとんど差
がない状態で動作することを確認できました。
(3) 最適化
今回の検証で実施した最適化の施策について以下で説明します。
１．接続設定の変更
selectMethod プロパティ消去
当該環境では、selectMethod=cursor が指定されていました。これにより、わずかな行数
しか取得しないような処理でもカーソルが作成によるオーバーヘッドが発生していまし
た。selectMethod=direct に変更することで、カーソル作成時のオーバーヘッドを回避さ
れ、パフォーマンスも改善されました。
sendStringParametersAsUnicode を false に変更
このパラメータは Prepared Statement の文字列パラメータを Unicode とするかどうかを
指定するパラメータで、true にすると SQL Server に Unicode で送信されます (デフォル
ト) 。今回は、このパラメータが指定されていなかった為、暗黙的な型変換が発生してし
まい、パフォーマンスに影響を与えていました。sendStringParametersAsUnicode=false に
することで暗黙的な型変換の発生が回避され、パフォーマンスも改善されました。
url=“jdbc:sqlserver://…;
selectMethod=cursor“
url=“jdbc:sqlserver://…;
sendStringParametersAsUnicode=false;
selectMethod=direct“
22
２．SSMA でエミュレートされた関数の修正
SQL Server で存在しない関数やパッケージが、移行前のアプリケーション内部で使用され
ている場合でも、SSMAExtentionPack をインストールしていると Oracle Database の関数
やパッケージを SSMA の自動変換時にエミュレート関数として実装することができま
す。ただし、このエミュレートされた関数によっては、パフォーマンスが低下するケース
がある為、ここではこのエミュレート関数を極力使用しないような改修を実施していま
す。
今回実施した例を以下に記載します。
Oracle Database の SQL 文
SQL Server の SQL 文 (SSMA による自動変換)
SSMA による関数の中では、値を取得する SELECT 文が実行されてしまう為、このテーブ
ルのデータ抽出件数が多い場合、パフォーマンスに大きく影響してしまいます。
今回の場合は、変数を使用せず固定文字列 (’TEST_USER’) を指定することで回避していま
す。
SELECT
COL1,
COL2,
COL3,
PKG1.USERNAME –パッケージで定義された変数
FROM
TABLE1
SELECT
COL1,
COL2,
COL3,
sysdb.ssma_oracle.get_pv_varchar('USER', 'DBO', ' PKG1', 'USERNAME')
FROM
TABLE1
23
SQL Server の SQL 文 (手動変換)
補足
SQL 文のエラー修正
SSMA での変換の時に、IN を使用した以下のような SQL 文でエラーが発生していまし
た。
エラーが発生していた SQL 文
これは、SQL Server では IN の中に複数のカラムを指定できない為に発生しています。
この為、このような SQL 文を使用している場合、EXISTS や JOIN を使用した SQL 文に
予め変更しておく必要があります。
SELECT
COL1
FROM
TABLE1
WHERE
(COL1, COL2) IN
(
SELECT
COL1, COL2
FROM
TABLE2
);
SELECT
COL1,
COL2,
COL3,
‘TEST_USER’
FROM
TABLE1
24
EXISTS を使用した修正案 JOIN を使用した修正案
5.2 バッチ アプリケーションのパフォーマンス検証
ここでは、バッチ アプリケーションのパフォーマンス検証結果について説明します。
(1) 検証概要
バッチ アプリケーションの処理の流れは以下の通りです。
SELECT
COL1
FROM
TABLE1
WHERE EXISTS ( SELECT 1
FROM
TABLE2
WHERE
TABLE2.COL1 = TABLE1.COL1
AND TABLE2.COL2 = TABLE1.COL2)
SELECT DISTINCT
TABLE1.COL1
FROM
TABLE1
INNER JOIN TABLE2
ON TABLE2.COL1 = TABLE1.COL1
AND TABLE2.COL2 = TABLE1.COL2
25
バッチ アプリケーション内で実行される処理は以下の通りです。
バッチ アプリケーション 処理 処理の詳細
販売実績データ登録処理 登録処理 テーブルにレコードを登録する処理
インデックス作成処理 インデックスを作成する処理
その他の処理 Drop Index 処理
Truncate 処理
Rename table 処理
Rename Index 処理
Comment 処理
データマート作成処理 登録処理 テーブルにレコードを登録する処理
インデックス作成処理 インデックスを作成する処理
その他の処理 Drop Index 処理
Truncate 処理
使用したテーブルのデータ及び圧縮設定は以下の通りです。
バッチ アプリケーション 登録するデータの件数 登録するデータのデータ長
販売実績データ登録処理 100,440,981 件 131Bytes
データマート作成処理 200,881,962 件 142Bytes
圧縮設定 テーブル INPUTテーブル OUTPUTテーブル
現行環境 販売実績データ 圧縮 圧縮
データマート 圧縮 非圧縮
新環境 販売実績データ 圧縮 圧縮
データマート 圧縮 非圧縮
パフォーマンス計測方法
パフォーマンスの計測方法は、次の通りです。
各テストケースは 1 回とし、テスト実施前に ミドルウェアの再起動を実施
現行環境を Windows 上に構築している為、Korn シェルスクリプトを
Windows PowerShell に書き換えて実行
バッチ アプリケーションの実行時のログから処理時間を測定
26
(2) 検証結果
上段は、販売実績データ登録処理のテストの結果で、下段はデータマート作成処理の結果にな
ります。値は現行環境の処理時間を 100 とした場合の相対値です。
販売実績データ登録処理
データマート作成処理
グラフは、現行環境と、SQL Server に合わせた最適化をする前の新環境 (最適化前) 、最適化
後の新環境 (最適化後) で実行した結果になります。
結果、最適化前の新環境ではほとんどの処理で現行環境の目標値と差がありましたが、SQL
Server に合わせた最適化を実施したことにより販売実績処理では現行環境の目標値とほぼ同程
度となり、データマート作成処理では目標値を上回ることが確認できました。
0
50
100
150
200
合計処理時間 登録処理時間 索引作成処理時間 その他処理時間
現行環境
新環境(最適化前)
新環境(最適化後)
0
50
100
150
200
合計処理時間 登録処理時間 索引作成処理時間 その他処理時間
現行環境
新環境(最適化前)
新環境(最適化後)
27
(3) 最適化
今回のバッチ アプリケーションで実施した最適化は以下の通りです。
No 設定 説明
１ max degree of Parallelism の値変更 並列処理設定
２ ファイルサイズの拡張 初期ファイルサイズ設定
３ 復旧モデルの変更 トランザクションログの復旧モデル設定
４ INSERT 文のチューニング 登録時のトランザクションログ非出力設定
５ SORT_IN_TEMPDB オプションの変更 インデックス作成時のデータソート場所変更設定
６ インデックスの構成順序変更 インデックスを構成している列の順序を変更
７ ボリュームの保守タスクを実行の設定 プロセスを使用して物理メモリにデータを保持で
きるアカウントを設定
８ メモリ内のページのロックの設定 プロセスを使用して物理メモリにデータを保持で
きるアカウントを設定
９ リソースガバナーの変更 SQL Server のワークロードとシステム リソース
の消費を管理設定
1. Max Degree Of Parallelism の値変更
Max Degree Of Parallelism (MAXDOP) は、複数のプロセッサまたは CPU が搭載されているコ
ンピュータ上で SQL Server 2012 を実行する時に、１ つのステートメントを並列処理させる
場合の最大の並列度を指定するパラメータです。この値を 0 にすると最大限の並列処理が実
行されます (デフォルトは 0) 。
本環境では、構築時に Web アプリケーションの特性を考慮して MAXDOP を 4 に設定して
いました。この為、パラメータを 0 に変更して処理を実行した所、登録処理、インデックス
作成処理が高速化することを確認しました。
MAXDOP は、今回の環境では 0 にすることで高速化しましたが、アプリケーションやサーバ
ー環境に依存する為、アプリケーションの特性およびサーバーに搭載されている CPU コアの
数に合わせた値に設定することをお勧めします。
ポイント：MAXDOP を 0 に設定すると、サーバーに搭載されている CPU コアの数に応じ
て、最大 64 並列での処理が実行されます。サーバーに 65 個以上の CPU コアが搭載されて
いる場合には、明示的にその数を指定することにより、64 並列以上の並列度での処理が可能と
なります。
28
2. ファイルサイズの拡張
本検証では、大量データの登録処理によりデータファイルが拡張している為、データファイル
の初期サイズを大きく設定した後に処理を実行しました。
これにより、登録処理の処理速度が高速化することを確認しました。
3. 復旧モデルの変更
復旧モデルとは、SQL Server におけるトランザクションログの内部動作を指定するもので、
この値を変更することによりトランザクションログへの書き込み量に影響があります。
今回は、完全モデルから一括ログモデルに変更して INSERT 文を実行しました。
これにより、登録処理の処理速度が高速化することを確認しました。
・完全 (Full) モデル
完全モデルは、トランザクションログへすべての処理履歴を完全に記録するモデルです。
このモデルでは、障害発生時に障害が発生した直前までデータを復旧することができ、
また、時刻を指定した復旧も可能で、ほとんどの環境で最適なモデルです。
・一括ログ (Bulk Logged) モデル
一括ログ モデルは、一括操作 (インデックスの作成や再構築、bcp コマンド、BULK
INSERT ステートメント、SELECT INTO、INSERT INTO など) のパフォーマンスを向上する
ために、トランザクションログへ記録する情報を最小限に抑えるモデルです。
しかし、ログへ記録される情報が少なく、障害発生時に一部の操作の復旧ができない可能
性があります。また、このモデルでは、時刻を指定した復旧もできません。障害復旧より
も一括操作のパフォーマンス向上を重視したい場合には、このモデルの使用が適していま
す。
・単純 (Simple) モデル
チェックポイントが完了するごとに、現在実行されているトランザクションを除いて、
トランザクションログを切り捨てます。これによって、トランザクションログの使用領域
を最小に抑えて、ログの肥大化を防ぐモデルです。
29
4. INSERT 文のチューニング
INSERT 文に WITH (TABLOCK) を指定してテーブルに対してロックを取得することで、行毎の
ロック取得時間を短縮することができます。
これにより、登録処理内の INSERT 文の処理時間が大幅に高速化することを確認しました。
5. SORT_IN_TEMPDB オプションの変更
このオプションを指定することで、インデックス作成時に使用する中間の並べ替え結果の格納
場所として tempdb が使用されるようになります。Tempdb がユーザーデータベースとは異な
るディスクに配置されている場合、インデックス作成処理を高速化することが可能です。
これにより、インデックス作成処理時間が高速化することを確認しました。
6. インデックスの構成順序変更
チューニング前のインデックスでは、列１ のカーディナリティが低く、値の種類が 1 種類
しか存在していなかった為、インデックス作成処理がパラレル化していませんでした。
この為、インデックスの構成をカーディナリティの高い項目から作成して、パラレルに処理さ
れるようチューニングしています。
例)
チューニング前
インデックスの構成 (列１、列２、列３、列４、列５、列６)
チューニング後
インデックスの構成 (列２、列３、列６、列１、列４、列５)
これにより、販売実績データ登録処理、データマート作成処理ともに処理を高速化することを
確認しました。
30
7. ボリュームの保守タスクを実行の設定
SQL Server のサービス アカウントに対してボリュームの保守タスクを実行権限を付与するこ
とにより、データファイル内の必要な領域を 0 で満たす操作を行わずに使用中のディスク領域
を再要求するようになります。
8. メモリ内のページのロックの設定
メモリ内のページのロックは、物理メモリにデータを保持できるアカウントを指定すること
で、ディスク上の仮想メモリへのデータのページングを防止します。SQL Server の実行ユーザ
ーが、メモリの連続領域を確保することが可能になります。
9. リソースガバナーの変更
リソースガバナーとは、CPU 使用率やメモリ割り当てなどの OS リソースを調整する機能で
す。今回は、使用できるメモリの量を 50% 増加させています。
31
第 6章 まとめ
この実証プロジェクトを通して、次のことを確認することができました。
RFP 要件に対するまとめ
Oracle Database から SQL Server 2012 への移行にあたって、Oracle Database の
オブジェクトの移行、Java アプリケーションの移行、バッチ アプリケーションの移行、
データ移行について検証を実施し、以下の項目を満たしていることを確認することができ
ました。
・現行のシステムと同等の機能
・現行のシステムを目標値とした同等かそれ以上の性能
運用コストについては今回の検証では記載しておりませんが、「A 社」が「X 社」向けに
算出した SQL Server 2012 への移行工数とライセンスコスト、5 年間のランニングコスト
を、Oracle Database を利用し続けた場合とで比較した結果、SQL Server 2012 へ移行する
ことでコスト削減が可能であることを確認できました。
但し、この結果は全ての環境に適用できるわけではなく、実際の移行時には必ず移行の
評価をすることをお勧め致します。
データベース移行結果に関するまとめ
今回の検証では、SSMA を使用することでほとんどのデータベース オブジェクトを
SQL Server 2012 のオブジェクトに自動で変換することができました。
Oracle Database のデータについては、SSMA を使用することで SQL Server 2012 に移行
できることができました。
Java アプリケーションは、接続設定と SQL 文を修正することで、SQL Server 2012 で
問題なく動作することを確認できました。
32
バッチ アプリケーションは、Korn シェルスクリプトと SQL スクリプトを修正すること
で、SQL Server 2012 で問題なく動作することを確認できました。
パフォーマンス検証結果に関するまとめ
今回のパフォーマンス検証結果では、Web アプリケーション、バッチ アプリケーション
共に、新環境への最適化を実施することにより、現行環境と同等の性能を確保することが
できることを確認できました。
33
付録 A ソリューション内にある技術解説 (移行手順)
この章では、第 4 章で説明した SQL Server 2012 でのソリューションの技術について、具体的
な実装手順を説明します。以下の操作手順を説明します。
A.1 移行前の SSMA 設定
A.2 データベース オブジェクトの移行手順
A.3 データの移行手順
A.4 Java アプリケーションの移行手順
A.5 Korn シェルスクリプトの移行手順
A.1 移行前の SSMA 設定
移行作業を実施する前に SSMA の設定を実施します。
１．SSMA 起動
SSMA を起動します。
[スタートスクリーン] - [SQL Server Migration Assistant for Oracle] をクリックします。
34
２．新規プロジェクト作成
新規プロジェクトを作成します。
[File] - [NewProject] をクリックすると、[New Project] ダイアログが表示されるので、必要な
情報を入力して [OK] ボタンをクリックします。
No 名称 説明 設定値 備考
1 Name 作業 Project 名称 任意の名称を設定
2 Location 作業 Project ディレクトリ 任意のディレクトリを設定
3 Migrate To 移行対象 SQL Server バージョン [SQL Server 2012] ドロップダウンから選択
35
３．Oracle Database への接続
移行対象の Oracle Database に接続します。
[Connect to Oracle] をクリックすると、[Connect to Oracle] ダイアログが表示されるので、必
要な情報を入力して [Connect] ボタンをクリックします。
No 名称 説明 設定値 備考
1 Provider Oracle 接続ドライバ [Oracle Client Provider] ドロップダウンから選択
2 Mode Oracle 接続モード [Standard Mode] ドロップダウンから選択
3 Server name サーバーHOST 名称 Oracle サーバーの HOST 名称 IP アドレスでも接続可能
4 Server Port ポート番号 Oracle 接続ポート番号 デフォルト：1521
5 Oracle SID Oracle サービス ID Oracle インスタンス ID Oracle サービス名称でも接続可能
6 User name Oracle ユーザー名 Oracle ユーザー名称 移行対象の Oracle ユーザー名称
7 Password Oracle パスワード Oracle パスワード 移行対象の Oracle パスワード
36
４．データ属性設定
移行後のアプリケーションのパフォーマンスを考慮し、SQL Server に変換後のデータ属性の桁
数を指定します。Oracle Database で使用していない属性については、SSMA による移行作業
に影響がないため、データ属性設定は不要です。
例)
char (max) ：char (2000) と設定
varchar (max) ：varchar (4000) と設定
number (max) ：float (38) と設定
[Tools] - [ProjectSettings] をクリックすると、[Project Settings] ダイアログが表示されるので、
修正したいデータ属性を選択し [Edit…] をクリックします。
37
変換する属性と桁数を指定して [OK] をクリックします。変換後、[TypeMapping] をクリック
して指定した値が正常に反映されていることを確認します。
38
A.2 データベース オブジェクトの移行手順
データベース オブジェクトは SSMA を使用して以下のような手順で移行します。
A.1.1 評価レポートの作成
A.1.2 データベース オブジェクトの移行
A.2.1 評価レポートの作成
SSMA の設定が完了したら、移行評価レポートを作成して移行対象の Oracle Database を移行
した場合の評価を実施します。
移行評価レポート
移行評価レポート、Oracle Database から SQL Server に DB オブジェクトを変換した時の自
動変換率を評価することができます。
１．レポート出力
自動変換したいスキーマを選択します。オブジェクト単位で選択したい場合は、自動変換した
いオブジェクトのみ選択します。
39
スキーマ選択後、[Create Report] をクリックします。
変換エラーとなる可能性のあるオブジェクト (ステータスが INVALID のオブジェクト等) が
警告されることがあります。
レポート作成が正常に完了すると、レポートのサマリー画面が表示されます。
No 名称 説明
１ 自動変換率 変換対象構文数と、変換不可構文数、自動変換率を表示
２ オブジェクト毎変換数 SSMA が認識したオブジェクト数と、変換を行えなかったオブジェクト数
を表示
３ エラー数 SSMA 自動変換時のエラー数
1 2
3 4 5
6
7
40
４ 警告数 SSMA 自動変換時の警告数
５ 修正工数 (時間) エラー数、警告数を対応した場合の、修正工数
６ エラー、警告詳細 SSMA 自動変換時のエラー、警告の詳細
７ アセスメントレポート物理パ
ス
ダイアログ表示と同時に作成される、HTML 版アセスメントレポートの物
理パス
自動変換率内の ALL の変換率 (Converted) が 100% でない場合、手動で修正を行う必要があ
ります。
２．エラー箇所確認
自動変換されなかったオブジェクトを選択し、エラー箇所を確認します。
自動変換されなかったオブジェクト (赤い×印が付いている箇所) を選択し、エラー箇所を確
認し、修正可能な場合 Oracle Database のソースを修正します。
例えば、上記オブジェクトの場合、NOLLOGING オプションがあることにより自動変換されな
い為、この箇所をコメントアウトして保存 (Ctrl + S) します。
本修正は SSMA 上のソースを修正しており、Oracle Database 上のソースには反映されませ
ん。
41
保存されると、画面にメッセージが表示されます [Packaged object was changed]。
３．レポート再出力
自動変換されなかったオブジェクトを修正した場合、再度レポートを作成します。
–
42
自動変換率内の ALL の変換率 (Converted) を確認します。100% でない場合、SQL Server の
ソースを手動で修正する必要があります。
A.2.2 データベース オブジェクトの移行
評価レポートで SSMA による自動変換の状況を把握した後に、実際に SQL Server にオブジェ
クトを移行します。
１．SQL Server に接続
オブジェクトを移行する SQL Server に接続します。
43
[Connect to SQLServer] ボタンをクリックして SQL Server への接続情報を入力します。
No 名称 説明 設定値 備考
1 Server name サーバーHOST 名称 SQL Server サーバーの
HOST 名称
IP アドレスでも接続可能
2 Server Port ポート番号 SQL Server 接続ポート番号 初期値：default
3 Database データベース名 SQL Server 接続データベー
ス名
4 Authentication 接続方法 SQL Server 接続方法 選択：Windows Authentication
SQL Server Authentication
5 User name SQL Server ユーザー名 SQL Server ユーザー名 移行対象の SQL Server ユーザー名称
6 Password SQL Server パスワード SQL Server パスワード 移行対象の SQL Server パスワード
SQL Server に接続すると、[SQL Server Metadata Explorer] にスキーマ情報が表示されます。
44
２．オブジェクトの移行
移行したいスキーマを [Oracle Metadata Explorer] から選択します。
選択したスキーマ上で右クリックして、[ConvetScheme] を選択します。
ConvertScheme は SSMA の内部処理であり、移行先の SQL Server にオブジェクトが作成さ
れるわけではありません。
45
選択後、変換エラーとなる可能性のあるオブジェクト (例えば、PL/SQL のオブジェクトのス
テータスが INVALID のものなど) がある場合、警告が表示されます。
移行が完了すると、Output 画面に移行結果が出力されます。エラーがないことを確認しま
す。
３．同期処理
移行対象オブジェクトを SQL Server に反映させます。
[SQL Server Metadata Explorer] で、移行対象となる DB を右クリックし [Syncronyzed] を選
択します。
46
同期させるオブジェクトの選択画面ですべてのオブジェクトを選択して [OK] をクリックしま
す。
４．オブジェクト移行確認
SQL Server Management Studio (SSMS) を使用してオブジェクトが適切に移行されたかどうか
を確認します。
47
SSMS 起動後、sys.Tables、sys.Indexes か らテーブルの一覧を取得し、結果を任意のファイル
に保存します。
SQL 文
SELECT name FROM sys.Tables ORDER BY name
SELECT name FROM sys.Indexes ORDER BY name
Oracle Database の情報は、user_objects からテーブルの一覧を取得します。
SQL 文
SELECT object_name FROM user_objects ORDER BY object_name
Excel 等でテーブル名を比較します。
Excel の IF 関数、EXACT 関数を使用して、Oracle Database のテーブルが SQL Server に存在
していることを確認します。
例)
IF (EXACT (範囲) ,”〇”,”×”)
48
補足
今回使用した SSMA のバージョンでは、パーティションや圧縮オプションを使用している場
合、テーブルとしては移行されますがこれらの機能については移行されず、SSMA のレポート
でもエラーや警告などが出力されないことがあります。
この為、このような機能を使用している場合、移行時に考慮が必要です。
A.3 データの移行
Oracle Database のデータは SSMA を使用して以下のような手順で移行します。
A.3.1 データの移行
A.3.2 データ件数のチェック
A.3.3 データのチェック
A.3.1 データの移行
SSMA を使用してデータを移行します。
１．移行対象のテーブルを選択
データ移行対象となるテーブルを選択します。全てのテーブルを移行する場合、[Tables] を選
択します。
49
２．データ移行開始
選択後、[Tables] で右クリックを実行し、[Migrate Data] を選択して移行を開始します。
移行中は Output 画面にデータ移行の状況が表示されます。移行の進捗状況は、下部のプログ
レスバーで確認することができます。
３．データ移行の確認
移行完了後、移行結果が表示されるので、From 列と To 列に全てのテーブルが表示されている
ことと、Total Rows と Migrated Rows に移行対象テーブルのデータが全て移行されているこ
とを確認します。
1 2 3 4 5 6 7
50
No 名称 説明 備考 確認ポイント
1 Status 移行成否アイコン 情報、警告、エラーをアイコ
ンが表示される
2 From Oracle 移行元テー
ブル
Oracle の移行元テーブルが
表示される
移行対象テーブルが全て処理されて
いること
3 To SQLServer 移行先
テーブル
SQL Server の移行先テーブ
ルが表示される
移行対象テーブルが全て処理されて
いること
4 Total Rows 移行対象行数 Oracle テーブルの移行元デ
ータ件数が表示される
Oracle 移行元テーブルの件数と一致
していること
5 Migrated Rows 移行成功行数 SQL Server の移行成功デー
タ件数が表示される
Oracle 移行元テーブルの件数と一致
していること
6 Success Rate データ移行成功率 移行成功行数 / 移行対象行
数 (%) が表示される
データ移行成功率が 100％であること
データ移行成功率が 100％でないテー
ブルの特定
7 Duration データ移行時間 データ移行処理にかかった
時間が表示される
エラーが発生すると、エラー画面が表示されます。エラーになったオブジェクトを特定し定義
等を確認して、エラー原因を調査します。
今回の環境では、外部表でエラーが発生しており、移行対象外と判断し除外しています。
51
４．データ移行結果の確認
SSMA 上でデータが移行されていることを確認します。
確認したいテーブルを選択した後、[Data] タブをクリックすると、該当テーブルのデータが表
示されるので、正常にデータが移行されていることを確認します。
52
A.3.2 データ件数のチェック
Oracle Database、SQL Server のデータ件数を確認します。
１．移行対象テーブルの件数を確認
Oracle Database 、SQL Server の両環境にログインし、データ件数を確認します。確認コマン
ドはそれぞれ以下になります。
Oracle Database
SELECT ‘SELECT ’ || ‘’‘’ || object_name || ‘’‘’ || ‘ ,COUNT (1) FROM ’ ||
object_name || ‘ UNION ALL’ FROM user_objects WHERE object_type = ‘TABLE’
ORDER BY object_name;
SQL Server
SELECT ‘SELECT ’ + ‘’‘’+ name + ‘’‘’ +‘ ,COUNT (1) FROM ’+ name + ‘ UNION ALL’
FROM sys.tables ORDER BY name
出力された結果を Oracle Database 、SQL Server それぞれで実行します。実行時に出力された
SQL の最後の UNION ALL は削除して下さい。
53
A.3.3 データのチェック
リンク サーバーを使用して、格納されたデータ自体を確認します。
１．リンク サーバーのオプションを変更
[サーバーオブジェクト] - [リンク サーバー] - [プロバイダー] - [OraOLEDB.Oracle] を右クリッ
クしてプロパティを選択します。
リンク サーバーのオプションを変更したい場合は、プロバイダー オプションの有効化をチェ
ックします。
今回の検証では、以下を有効にしています。
入れ子になったクエリ
InProcess 許可
’Like’ 演算子をサポートします
54
補足
接続時にエラーが発生する場合、InProcess 許可の設定が必須となる場合があります。
２．リンク サーバーの設定
リンク サーバーを設定します。
サーバーオブジェクト – リンク サーバーを右クリックして、新しいリンク サーバーを選択
してリンク サーバーの設定をします。
No 名称 説明 設定値 備考
1 プロバイダー OLE DB データ ソースを選択
します
Oracle Provider
for OLE DB リスト ボックスから 選択します
2 製品名 OLE DB データ ソースの製品
名を入力します
任意の名称を設
定
例：oracle
3 データソース OLE DB プロバイダーで解釈
されるデータ ソースの名前
Oracle の接続記
述子
Tnsnames.ora で指定した文字列
55
４．セキュリティを設定
セキュリティを選択し、Oracle ユーザーとパスワードを入力します。
５．サーバーオプションの設定
必要に応じて、サーバー オプションを設定します。
今回の検証では、デフォルト値を使用します。
56
６．リンク サーバーの接続テスト １
設定後、リンク サーバーの接続テストを実施します。
テストに成功すると、以下のようなメッセージが表示されます。
57
７．リンク サーバーの接続テスト ２
OPENQUERY を使用して Oracle Database のテーブルが参照可能かどうかを確認します。
上記のようなエラーが発生する場合、InProcess 許可の指定が不足している可能性がありま
す。
８．データ比較
Oracle Database と SQL Server のテーブルを比較します。
58
クエリは、OPENQUERY と NOT EXISTS を使用して比較を行い、Oracle Database から
SQL Server を確認するものと、SQL Server から Oracle Database を確認します。
本クエリは全データをチェックする為、データサイズにより処理に時間がかかることがありま
す。本環境の場合、レコード長 91Bytes のデータを 100,440,981 件チェックした時の処理時
間は 1 時間 21 分 51 秒でした。
SQL Server を基準に Oracle Database と比較
Oracle Database を基準に SQL Server と比較
SELECT
S.COL01
,S.COL02
,S.COL03
FROM
dbo.TABLE_A S
WHERE
NOT EXISTS
(SELECT 1 FROM OPENQUERY (ORACLESVR,
'SELECT
COL01
,COL02
,COL03
FROM
dps.TABLE_A') AS O
WHERE
ISNULL(S.COL01,'')=ISNULL(O.COL01,'')
AND ISNULL(S.COL02,'')=ISNULL(O.COL02,'')
AND ISNULL(S.COL03,'')=ISNULL(O.COL03,'')
);
SELECT
O.COL01
,O.COL02
,O.COL03
FROM
(SELECT * FROM OPENQUERY(ORACLESVR,
'SELECT
COL01
,COL02
,COL03
FROM
dps.TABLE_A')) AS O
WHERE NOT EXISTS
(SELECT 1 FROM dbo.TABLE_A S
WHERE
ISNULL(S.COL01,'')=ISNULL(O.COL01,'')
AND ISNULL(S.COL02,'')=ISNULL(O.COL02,'')
AND ISNULL(S.COL03,'')=ISNULL(O.COL03,'')
);
59
A.4 Java アプリケーションの移行
データベースにアクセスする Java アプリケーションを Oracle Database から SQL Server
2012 に移行します。
A.4.1 接続設定の移行
Java から SQL Server に接続するための設定を変更します。本書では、JNDI を使用して
Oracle Database に接続している為、JNDI リソースの変更を行います。
JNDI の主な変更箇所は以下の通りとなります。
現状 (Oracle Database ) 移行後 (SQL Server)
<Context
path=“/test“
reloadable="true"
docBase=“D:¥test”
workDir=“D:¥work" >
<Resource
name=“jdbc/test"
auth="Container"
type="javax.sql.DataSource"
driverClassName="oracle.jdbc.
driver.OracleDriver"
url=“jdbc:oracle:thin:@IP アド
レス:ポート:SID"
username=“test"
password=“test" />
</Context>
<Context
path=“/test“
reloadable="true"
docBase=“D:¥test”
workDir=“D:¥work" >
<Resource
name=“jdbc/test"
auth="Container"
type="javax.sql.DataSource"
driverClassName="com.microsoft.sqlserv
er.jdbc.SQLServerDriver“
url=“jdbc:sqlserver://[serverName[¥ins
tanceName][:portNumber]];databaseName=
データベース名;
sendStringParametersAsUnicode=false"
username=“test"
password=“test" />
</Context>
driverClassName に “com.microsoft.sqlserver.jdbc.SQLServerDriver“ を指定
url に jdbc:sqlserver://[serverName[¥instanceName][:portNumber]][;property=value
[;property=value]] を指定
url の databaseName プロパティにデータベース名を指定
url の sendStringParametersAsUnicode プロパティに false を指定
<Resource> タグのプロパティは以下の通りです。
60
要素 内容
Name JNDI リソースの名前を指定。指定された名前は java:comp/env の相対パスとして参照される。
Auth リソースマネージャに接続する主体を指定する。Java アプリが接続する場合は「Application」
と、Java アプリを代表して Tomcat コンテナが接続する場合は「Container」と指定する。
Type JNDI リソースのクラス型、インタフェース型を指定する。
driverClassName JDBC ドライバの Java クラスを指定。SQL Server の場合は、
com.microsoft.sqlserver.jdbc.SQLServerDriver になる。
url JDBC 接続のための JDBC 準拠の URL を指定。
Username データベースに接続するためのユーザーID を指定。
Password データベースに接続するためのパスワードを指定。
<Resource> タグの url プロパティは以下の通りです。
要素 内容
jdbc:sqlserver:// サブプロトコルであり定数
serverName 接続先のサーバーのアドレス。
接続先のサーバーのアドレスには DNS または IP アドレスを指定する
instanceName serverName 上にある接続先のインスタンス
portNumber serverName 上にある接続先のポート。既定では 1433
property 接続プロパティオプション。詳細については以下のサイトを参照
http://technet.microsoft.com/ja-jp/library/ms378988.aspx
接続 URL の主なプロパティ
プロパティ 種類 説明
databaseName String 接続するデータベース名。 指定しない場合は、既定のデータベースへの接続が確立
される
sendStringParamet
ers AsUnicode Boolean
false に設定すると、文字データに対して準備されたパラメータを Unicode ではなく
ASCII で送信し、Unicode ではない文字データのインデックス参照のパフォーマンス
が向上する
61
A.4.2 Java アプリケーションの移行
Java アプリケーションを移行します。本書では、iBATIS を使用している為、XML ファイルに
記載されている SQL 文を修正します。
１．ソースから SQL 文を抽出
ソースの SQL 部分をテキストエディターにコピーします。
iBATIS では、SQL 文は XML ファイルに記載されている為、ここにある SQL 文を修正しま
す。SQL 文自体がソース内に埋め込まれている場合は、SELECT、INSERT などでソース内を検
索して抽出する必要があります。
iBATIS のタグはコメントアウトし、パラメータは仮の値を指定します。
仮の値を指定した項目が文字列や日付の場合、シングルクォートで囲む必要があります。
62
２．SSMA の起動
SSMA を起動します。SSMA の起動や設定などは、A.1 を参照してください。
３．SSMA を使用した SQL 文の変換
SSMA を使用して、抽出した SQL 文を変換します。
該当スキーマの Statements を右クリックし、[Add Statement] を選択します。
63
４．評価レポートの作成
Statements 配下に作成された [Statement #N] を選択後、右側の SQL 欄に QL 文を記述し、
[Create Report] をクリックします。
SQL 文の変更を反映するかどうかの確認画面が表示されますので、[Yes] をクリックします。
64
５．評価レポートの確認
評価レポートに変換された SQL Server の SQL 文が作成されます。この時点で、エラーが発
生した場合、エラー内容を確認し SQL 文を修正します。エラー箇所が修正できない場合は、
手動で SQL 文を修正する必要があります。
変換後の SQL 文を SSMS で実行し、エラーが発生しないことを確認します。
65
６．ソースに SQL 文反映
変換した SQL 文をソースに反映します。
66
７．パラメータ箇所の復元
指定した仮の値を削除し、コメントアウトしたタグとパラメータを元に戻します。
67
A.5 バッチ アプリケーションの移行
Korn シェルスクリプトの処理を、Windows PowerShell に移行します。
A.5.1 Korn シェルスクリプトの移行
Korn シェルスクリプトから SQL * Plus で Call する SQL スクリプトを Oracle Database から
SQL Server に移行します。
１．SQL*Plus コマンドの変換
SQL*Plus ユーティリティのコマンドを、SQL Server の SQLCMD へ変換します。
Oracle Database SQL Server 対応 備考
SET feedback OFF SET NOCOUNT ON フィードバック
Spool <filename> append SQLCMD –o <filename> Windows PowerShell
へ記述を移行
スプールデータ出力、SQLCMD
実行時に –o オプション指定
WHENEVER OSERROR EXIT 1
ROLLBACK
SQLCMD -b Windows PowerShell
へ記述を移行
SQLCMD 実行時に –b オプショ
ン指定。
-b：SQLCMD 実行時エラー取得 WHENEVER SQLERROR EXIT
1 ROLLBACK
２．DB 接続関数の変換
Oracle Database の SQL*Plus を、SQL Server の SQLCMD へ変換します。
No 機能 Korn シェルスクリプト Windows Powershell
1 DB 接続 Sqlplus sqlcmd
2 パラメータ受渡方法 Sqlplus 起動時、パラメータ (配列変数) を
指定する
Sqlcmd 起動時、-v オプションで指定す
る
ソース変換例
Korn シェルスクリプト
$rc = sqlplus -s $ORACLE_UID/$ORACLE_PWD@ORACLE_HOST
'@$SQL_FILE_DIR/$SQL_FILE_NAME $LOG_FILE_DIR/$LOG_FILE_NAME $SQL_PARAM
68
Windows PowerShell
sqlcmd -S $SQLSVR_SVR -d $SQLSVR_DB -E -b -h -l -i
$SQL_FILE_DIR/$SQL_FILE_NAME -o $LOG_FILE_DIR/$SQL_LOG_NAME -v
$SQL_PARAM
代表的な SQL*Plus オプション
コマンド コマンド内容
-s サイレントモードで実行
`@<filename> 実行するスクリプトファイルを指定
代表的な SQLCMD オプション
コマンド コマンド内容
-S インスタンス名 (サーバー名)
-d データベース名
-U ログイン ID
-P パスワード
-e SQLServer 認証の代わりに Windows 認証接続を行う。
-b スクリプトエラー取得
-i 入力ファイル
-o 出力ファイル
別のセッションが同一名でファイルを作成していた場合は、上書き
-v パラメータ 指定
69
３．SQL 文の変換
SQL スクリプト内の SQL 文を変換します。SQL 文の変換方法については、A.4.2 Java アプリ
ケーションの移行を参照して下さい。
当該環境で変換した箇所は以下の通りです。
機能 Oracle Database SQL Server 備考
日付 TO_CHAR (SYSDATE,
‘YYYY/MM/DD’)
CONVERT (VARCHAR,getdate () ,120)
表の切り捨て
(TRUNCATE)
Truncate Table &1; DECLARE @p1 VARCHAR (30) , @sSQL
VARCHAR (256) ;
SET @p1=$ (p1) ;
SET @sSQL=‘TRUNCATE TABLE ’ + @p1 +
‘;’;
EXECUTE sp_executesql @sSQL;
T-SQL で動的 SQL
に変換し、機能を
実現
オブジェクト
名変更
ALTER TABLE
<tablename> RENAME
TO <newtablename>;
EXEC sp_rename N’<tablename>’,
N’newtablename>, ‘Object’;
オブジェクト
コメント
COMMENT ON TABLE
<tablename> IS
<comment>;
EXEC sys.sp_updateextendedproperty
@name = ‘MS_SSMA_SOURCE’,
@value = ‘<comment>’,
@level0type=N'SCHEMA',
@level0name=N'dbo',
@level1type=N'TABLE',
@level1name=N‘<tablename>‘;
T-SQL で、
sp_updateextende
dproperty を実行
仮想表 FROM DUAL FROM DUAL を削除
70
シェルコード修正例
Korn シェルスクリプト
Windows PowerShell
71
４．シェル変換
Korn シェルスクリプトを Windows PowerShell に変換します。
機能 Korn シェルスクリプト Windows PowerShell 備考
拡張子 *.ksh *.ps1
シェル起動 $BATCH_DIR/XXX.ksh . $BATCH_DIR/XXX.ps1 文頭に「.」 (ドット) を追記
ファイル確認 ! –e
$FILE_DIR/$FILE_NAM
E
Test-Path
$SQL_FILE_DIR/$SQL_FILE_N
AME
Test-Pathコマンドレットの戻値が
$false の場合、存在なし
ファイル削除
rm –f
$FILE_DIR/$FILE_NAM
E
Remove-Item
$FILE_DIR/$FILE_NAME Korn シェルスクリプトの「-f」オ
プション (強制削除 ) について
は、注意が必要
/dev/null -recurse
ログ出力
tee
$LOG_DIR/LOG_NAME
Out-File –file
$LOG_DIR/LOG_NAME
tee –a
$LOG_DIR/LOG_NAME
Out-File –file
$LOG_DIR/LOG_NAME -append 追記オプション
Out-File –file
$LOG_DIR/LOG_NAME-
encoding default
文字化け防止オプション
日付
date
+'%Y/%m/%d %H:%M:%S
'
Get-Date -format
"yyyy/MM/dd HH:mm:ss" -format オプションで日付書式を
指定する
条件分岐 If [ ] then
…
fi
If ( ) {
…
}
条件式
$A –e $B $A –eq $B イコール
$A ! –e $B $A –ne $B ノットイコール
繰返処理
while [ $3 ]
do
…
done
while ( $3 )
{
…
}
SQL コマンド
起動時パラメ
ータ作成方法
while [ $3 ]
do
SQL_PARAM
[ $cnt ] = $3
shift
( ( cnt = $cnt +
1 ) )
done
$ArgCnt = 2
while ( $ArgCnt –lt
$Args.Length )
{
$str = “p” + $cnt –as
[String]
$SQL_PARAM += $str +
“=‘” + $Args[$ArgCnt] +
“’”
$ArgCnt +=1
$cnt+=1
if ($Args[$ArgCnt] –ne
$null) {
$SQL_PARAM += “ “
}
Korn シェルスクリプトは配列変
数、Windows PowerShell では、文
字列変数に
シェル起動引
数
$1 $Args[0] Index が 1 つづれることに注意
定数定義 export $CONST =
“XXXXX”
$CONST = “XXXX”
72
付録 B データベース移行 Tips 集
B.1 データベース移行 Tips
SSMA による自動変換ができないケースとその対応策を以下にまとめています。ご参照下さ
い。
No シチュエーション 原因 主な対応策
1 大文字小文字で区別さ
れた同一名テーブルの
移行
テーブル名に大文字小文字の区別が存在しないため 状況に応じて適切な対策を
行う
2 Transact-SQLでファイル
操作ができない
デフォルトでファイル操作が許可されていないため 強制パラメータ設定を行う
3 SSMA 自動変換 O2SS0013:
「EXECUTE IMMEDIATE」が SQL Server の標準機能
として対応していないため
EXECUTE、又は EXEC に修
正を行う
4
O2SS0083:
オブジェクトが参照できないため
オブジェクトを参照可能な
状態に変更を行う
5
O2SS0113:
@@FETCH_STATUS が直前の cursor の FETCH 状態を
保持しているため
適切な形式に変更を行う
6
O2SS0356:
PL/SQLの中に桁数を指定していない型が存在するた
め
SSMA で適切なデータ属性
設定を行う
7
O2SS0425:
日付計算処理が DATEADD 関数に変換されるため
適切な関数に修正を行う
8 SSMA 変換でエミュレート関数に変換されるため 適切な値に修正を行う
9 関数変換 SSMA による変換のできない関数を使用しているた
め
手動で修正する
以上