[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura

Oracle -> SQL Serverシステム移行の勘所
～Oracle開発経験者が戸惑うポイント～
株式会社インサイトテクノロジー
コンサルティング事業部
中村範夫
Copyright © 201４ Insight Technology, Inc. All Rights Reserved.

2
自己紹介
• 中村範夫（なかむらのりお）
• （株）インサイトテクノロジーコンサルティング事業部所属
• 大阪で１０年以上システム開発に従事した後に、現職に
• よく扱うDBは、Oracle、SQL Server、MySQL
• 最近はOracleのシステムをSQL Serverで再構築という案件
に従事することが多いです

3
Agenda
1. システム移行の概要
2. Oracle開発経験者が意識して欲しい違い
3. よくある開発トラブルシューティング
4. その他開発でよく聞かれること
5. まとめ

4
システム移行概要
1. データベースオブジェクトの移行（SSMA）
2. データの移行（SSMA）
3. アプリケーションの移行
• アプリケーションのビジネスロジック部分を自動変換（SSMA）
• SSMAで変換できない部分を手動で変換
• 一般的なシステム移行の流れ（Webアプリケーションの場合）
• SSMAが大半を担う

5
• SQL Server Migration Assistant（SSMA）とは？
SSMA は、Oracle データベースから SQL Server へのアプリケーション移行の自動化に役立つツールセットです。SSMA を利用することで、データベース
の変換を迅速、簡単、および正確に行うことが可能になり、SQL Server への移行に関する時間、コスト、およびリスクが大幅に軽減されます。
• SSMAを利用するメリット
SSMA を利用することで、下記の項目のようなデータベースの移行に必要な作業のほとんどを自動化することが可能です。
・データベースのアセスメント
・スキーマとデータの移行
・ビジネスロジックの変換
・移行の確認
http://msdn.microsoft.com/ja-jp/sqlserver/gg639007.aspx より
• どれだけ自動で移行でき、どれだけ手動での移行が必要かを、見積もるためにも、
まずはSSMAで移行検証を
• 一般的なシステムではおよそ80%～90%以上が自動で移行可能で、手動で変換が必要な
大半はPL/SQLのストアドプログラム

6
• PL/SQLの手動変換をいかに効率的に行うかが鍵
• SSMAで変換できなかった部分をT-SQLで手動で変換するよりも
PL/SQL側で変換できる形に修正する方が効率的なことが多々ある
【参考】Oracle から SQL Server 2008 への移行ガイド
http://download.microsoft.com/download/3/4/7/34710CC0-5B7D-499B-B39A-50ED31F6A500/MigrateOracletoSQLServer2008.docx

7
Oracle開発経験者が意識して欲しい違い
• デフォルトのトランザクションの分離レベルはどちらも、
「Read committed」だが Oracle には読み取り一貫性がある
• PL/SQLとT-SQLの違い
– PL/SQLは手続き型言語としての歴史が古く完成度が高い
– PL/SQLはカーソルの構文、コレクション型が豊富
– T-SQLは例外処理として 2012以降 THROWが使用可能となった
• その他インデックスが使用できるSQLの条件等はだいたい同じ
• Oracleのパラレルクエリと同様SQL Serverの並列クエリも強力

8
よくある開発トラブルシューティング（１）
• ［問題］デッドロックが多発する
– オンライン画面（Web）のシステムテストでデッドロックが多発する
• ［原因］テーブルスキャンによるロック待ちにより
デッドロックが発生
• ［対策］条件列に対してインデックスを付与、又は
「Read Committed Snapshot」分離レベルを採用

9
• ［解説］
t1テーブル
a b
1 AA
2 BB
Oracle（PL/SQL）でよくあるソースコード
SELECT * FROM t1 WHERE a = 2 FOR UPDATE
UPDATE t1 SET b = ‘BBB' WHERE a = 2
SQL Server用に変換
SELECT * FROM t1 WITH (ROWLOCK, UPDLOCK) WHERE a = 2
UPDATE t1 SET b = ‘BBB' WHERE a = 2
【ポイント】
更新条件のa列には主キー、
インデックスなし

10
• ［解説］
トランザクション [１] a b トランザクション [２]
SELECT * FROM t1 WITH (ROWLOCK, UPDLOCK)
WHERE a = 2
1 AA
SELECT * FROM t1 WITH (ROWLOCK, UPDLOCK)
WHERE a = 1
2 BB
UPDATE t1 SET b = 'BBB' WHERE a = 2 UPDATE t1 SET b = 'AAA' WHERE a = 1
1)先頭から探す
2)1件目を発見し、排他ロックを獲得
3)他にもないか探す
4)２行目で [1] の排他ロックにより待ちが発生
1)先頭から探す
2)1行目で２の排他ロックを発見
↓
デッドロック検知！！
① ②
③

11
DEMO：
テーブルスキャンによるロック待ちによりデッドロックが発生

12
よくある開発トラブルシューティング（２）
• ［問題］オンライン画面（Java Webアプリ）が遅い
– 自由検索画面の検索処理がOracleに比べてかなり遅い
• ［原因］Prepared Statement の文字列パラメータが Unicode
で送信されたため VARCHAR 列に対するインデックスが使えない
sendStringParametersAsUnicode = false
• ［対策］接続時に以下の設定を追記

13
よくある開発トラブルシューティング（２）
DEMO：
暗黙の型変換によりインデックスが使えない例

14
よくある開発トラブルシューティング（３）
• ［問題］バッチ処理の性能が思った程でない
• ［対策］定数取得の処理をアプリケーション側で行うことで
SQLが並列クエリになるよう修正
• ［原因］SQL で定数取得のユーザー定義関数を使用しているため
並列クエリで処理されていない

15
• ［解説］
並列クエリ処理（SQL Serverオンラインブックより）
http://technet.microsoft.com/ja-jp/library/ms178065(v=sql.105).aspx

16
• ［解説］EMP表を７５０万件に増幅し検証
並列クエリにならないパターン
SELECT COUNT(*)
FROM EMP2
WHERE JOB = dbo.USER_FUNC('SALESMAN')
並列クエリになるパターン
SELECT COUNT(*)
FROM EMP2
WHERE JOB = 'SALESMAN'
組み込み関数（GETDATE()やCONVERT等）は問題なく並列クエリになる

17
DEMO：
並列クエリになるパターンとならないパターン例

18
その他よく聞かれること（１）
• ファイル入出力はどうすればいいの？
– OracleにはSQL*Loader、UTL_FILEパッケージの機能がある
• SQL Server にも bcpユーティリティ、BULK INSERT、
OPENROWSETによる「INSERT～SELECT」がある
– ファイル入力では上記いずれの方法でも利用できる
– ファイル出力ではbcp
– OPENROWSETは非常に高性能で利用範囲が広い

19
その他よく聞かれること（２）
• bcpの出力が入力に比べて遅いけど？（CSVファイル）
大規模テーブルをCSVファイルに出力する場合、
bcp ユーティリティでは、カンマ付与をSQLで
記述する queryout 方式の方が高速
bcp Test.dbo.EMP out EMP.csv -c -t, -T
↓
bcp "SELECT empno + ',' + ename + ',' ・・・FROM Test.dbo.EMP" queryout EMP.csv -c -T

21
その他よく聞かれること（３）
• Oracleの階層問合せ（connect by）は使えないの？
• 標準SQLの共通テーブル式（CTE）を使った再帰クエリが使える

22
その他よく聞かれること（３）
• 共通テーブル式サンプル（emp表を階層問合せする有名なやつ）

23
その他よく聞かれること（４）
• とりあえずサーバーの設定はどうすればいいの？
• 最低限やっておくべきSQL Serverの設定
– メモリの適切な割当てとページロック設定
– 並列処理の最大限度（MAXDOP）の設定
-> OLTPではCPUコア数の1/4 （目安）
– tempdb のファイル分割 -> CPUコア数分（目安）
【参考】熊澤さんの検証資料
http://download.microsoft.com/download/F/1/0/F10BC023-9396-4D67-BAC9-7C43AE954BF4/Intel_WP_Xeon7500_SQL2008R2.pdf

24
まとめ
• SSMAを利用してシステム移行コストを見積もり
– システム移行コストは PL/SQL の変換が鍵
– PL/SQL側を一括修正することで変換コスト削減に貢献
• アーキテクチャの違いを理解した上での方式設計が重要
– トランザクションの分離レベル・ロック制御
– JDBC接続では [sendStringParametersAsUnicode] の設定に注意
– SQL Serverの並列クエリは強力なので上手に利用

25Copyright © 201４ Insight Technology, Inc. All Rights Reserved.
無断転載を禁ず
この文書はあくまでも参考資料であり、掲載されている情報は予告なしに変更されることがあります。
株式会社インサイトテクノロジーは本書の内容に関していかなる保証もしません。また、本書の内容に関連し
たいかなる損害についても責任を負いかねます。
本書で使用している製品やサービス名の名称は、各社の商標または登録商標です。

[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a [B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura

Semelhante a [B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura (20)

Mais de Insight Technology, Inc.

Mais de Insight Technology, Inc. (20)

Último

Último (9)

[B24] Oracle から SQL Server システム移行の勘所 by Norio Nakamura