oracle 2 sql server 移行ガイドデータベースオブ...

Oracle 2 SQL Server 移行ガイド

1 - データベースオブジェクト移行とデータ移行

2

目次

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

2. 前提条件 ................................................................................................ 4

3. データベースオブジェクトの移行 ................................................................ 5

3.1 SQL Server のネーミングルール ............................................................................. 5

3.2 言語ソートパラメータ (照合順序) の移行 ................................................................ 6

3.3 スキーマの移行 .................................................................................................... 7

3.4 データ型の移行 .................................................................................................... 7

3.5 表 (テーブル) の移行 ............................................................................................ 9

3.6 索引 (ンデックス) の移行 .................................................................................. 11

3.7 ビューの移行 ...................................................................................................... 13

3.8 シノニムの移行 ................................................................................................... 13

3.9 順序の移行 ......................................................................................................... 13

3.10 ストゕドプロシージャの移行 .................................................................................. 16

3.11 ユーザー定義関数の移行........................................................................................ 17

3.12 DML トリガーの移行 ........................................................................................... 17

3.13 Oracle Package の移行 ........................................................................................ 19

3.14 エラーハンドリングの移行 ..................................................................................... 20

3.15 カーソルの移行 ................................................................................................... 21

3.16 トランザクション ................................................................................................ 22

3.17 自律型トランザクション........................................................................................ 22

4. クエリの移行 ........................................................................................ 24

4.1 SQL 全般 .......................................................................................................... 24

4.2 基本的な SQL 構文 ............................................................................................. 28

4.3 関数 ................................................................................................................. 32

4.4 ORACLE 特有の機能を含んだ SQL ......................................................................... 36

5. データの移行 ........................................................................................ 43

5.1 移行方式概要 ...................................................................................................... 43

5.2 直接データ移行 ................................................................................................... 44

5.3 間接データ移行 ................................................................................................... 45

5.4 Integration Service による直接データ移行 .............................................................. 45

5.4.1 パッケージの作成 ............................................................................................. 45

5.4.2 データ移行時の注意点 ....................................................................................... 48

3

[注意事項]

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

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

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

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

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

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

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

手段を含みます。

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

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

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

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

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

ん。

© 2010 Microsoft Corporation. All rights reserved.

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

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

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

[追記]

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

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

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

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

4

1. 本ガイドの目的

本ガドでは、Oracle を用いて構築されたデータベースシステムを、SQL Server 環境へ移行する際の考慮

点、特にデータベースオブジェクトとデータベースデータの移行時の考慮点についてまとめています。

2. 前提条件

本ガドで対象とする SQL Server 及び Oracle のバージョンは以下の通りです。

SQL Server

SQL Server 2005

SQL Server 2008

Oracle

Oracle Database 10g R2

Oracle Database 11g

5

3. データベースオブジェクトの移行

3.1 SQL Server のネーミングルール

SQL Server の識別子 (データベース名、テーブル名、列名等) は以下のルールに従う必要があり、規則に

従わない場合は識別子を ”” (ダブルクォート) あるいは [] (ブラケット) で囲む必要があります。なお、変

数名およびストゕドプロシージャのパラメータ名は、必ず標準識別子の規則に従う必要があります。

最初の文字が次のいずれかである必要があります。

Unicode 規格 3.2 で定義されている文字。Unicode の文字定義には、各国言語の文字の他に、

ラテン文字 a ～ z と A ～ Z も含まれます。

ゕンダースコゕ (_)、ゕットマーク (@)、または番号記号 (#)。

SQL Server では、識別子の先頭にある一定の記号には特別な意味があります。ゕットマークで始

まる識別子はローカル変数またはローカルパラメータを表します。番号記号(#)で始まる識別子は

一時テーブルまたは一時プロシージャを表します。2 つの番号記号 (##) で始まる識別子は、グ

ローバルな一時オブジェクトを表します。

一部の Transact-SQL 関数の名前は、2 つのゕットマーク (@@) から始まります。これらの関

数との混同を避けるために、@@ から始まる名前は使用しないでください。

先頭以外では、次の文字を使用できます。

Unicode 規格 3.2 で定義されている文字

Basic Latin スクリプトまたはその他の各国スクリプトの 10 進数

ゕットマーク、ドル記号 ($)、番号記号、またはゕンダースコゕ

Transact-SQL 予約語を識別子として使用することはできません。SQL Server では予約語は

大文字、小文字共に予約されています。

スペース ([]や””が必要) および特殊文字は使用できません。

Transact-SQL 予約語を識別子として使用することはできません。SQL Server の予約語は、

大文字、小文字共に予約されています。

埋め込み型スペースおよび特殊文字は使用できません。

補助文字は使用できません。

6

3.2 言語ソートパラメータ (照合順序) の移行

分類 Oracle SQL Server 備考

言語ソート・パラメータ(照

合順序)

NLS_SORT

(デフォルトは BINARY)

照合順序

(日本語デフォルトは

Japanese_CI_AS)

NLS_COMP

(デフォルトは BINARY)

Oracle の言語ソート・パラメータがデフォルト (BINARY) の場合は、SQL Server の照合順序は、

バナリ (コードポント) (_BIN2) を指定します。

SQL Server の照合順序の並べ替え順序で選択可能な項目は以下の通り。

① バナリ (_BIN)

バナリ並び替え順では、大文字小文字とゕクセントが区別される

各文字に定義されているビットパターンに基づいて、SQL Server テーブルのデータの並べ替

えおよび比較が行われる

Unicode データは最初の文字が WCHAR として比較された後、続いてバト単位の比較が行

われる

② バナリ (コードポント) BIN2 (_BIN2)

バナリ並び替え順では、大文字小文字とゕクセントが区別される

各文字に定義されているビットパターンに基づいて、SQL Server テーブルのデータの並べ替

えおよび比較が行われる

Unicode データの Unicode コードポントに基づいて、SQL Server テーブル内のデータ

が並べ替えられ、比較される

非 Unicode データの場合、バナリ並べ替えと同じ比較が行われる

③ 大文字小文字を区別する (_CS)

大文字と小文字が区別される。このオプションを選択した場合、最初に小文字、その後で大文

字が並べ替えられる

このオプションを選択しない場合は、大文字と小文字を同じものとして並べ替えが行われる

④ ゕクセントを区別する (_AS)

ゕクセントのある文字とゕクセントのない文字が区別される。たとえば、“a” と “ấ” は等しく

ない

このオプションを選択しない場合、ゕクセントのある文字とゕクセントのない文字が同じもの

と見なされ、並べ替えが行われる

⑤ かなを区別する (_KS)

日本語のひらがな文字とカタカナ文字が区別される

このオプションを選択しない場合は、ひらがなとカタカナを同じものと見なして並べ替えが行

われる

⑥ 文字幅を区別する (_WS)

同一文字の 1 バト表現と 2 バト表現が区別される

7

このオプションを選択しない場合は、同一文字の 1 バト表現と 2 バト表現を同じものと

見なして、並べ替えが行われる

3.3 スキーマの移行

Oracle スキーマの移行には 2 つの方式があります。

1) Oracle スキーマを SQL Server データベースへ対応づけます。Oracle で複数のスキーマを定義して

いる場合、SQL Server に複数のデータベースを作成します。それぞれのデータベースでは Oracle ス

キーマを dbo に変換します。

2) Oracle スキーマを SQL Server スキーマに対応づけます。Oracle のスキーマが相互に関連づけられ

ている場合、この方式を用います。

3.4 データ型の移行

Oracle で使用頻度の高いデータ型と対応する SQL Server のデータ型は以下の通りです。


数値型 NUMBER(p,s)

p⇒1～38

s⇒-84～127

両方指定しなければ最大

精度

p のみ指定の場合 s=0

numeric(p,s)

p⇒1～38

s⇒0～p

p と s のデフォルト値は、p=18、

s=0

NUMBER(18,0)

～

NUMBER(10,0)

bigint

-2^63

(-9,223,372,036,854,775,808)

～2^63-1

(9,223,372,036,854,775,807)

NUMBER(9,0)

～

NUMBER(5,0)

int

-2^31 (-2,147,483,648)

～2^31-1 (2,147,483,647)

NUMBER(4,0)

～

NUMBER(3,0)

smallint

-2^15 (-32,768)

～2^15-1 (32,767)

NUMBER(2,0) tinyint

0～255

NUMBER(1,0) bit

1 または 0

取りうる値が 1 もしくは 0

であることが決まっている

場合のみ bit を使用する

8

文字型 CHAR(n)

n は文字数かバト

2000 バトまで

char(n)

VARCHAR2(n)

n は文字数かバト

4000 バトまで

varchar(n)

NCHAR(n)

n は文字数

2000 バトまで

nchar(n)

NVARCHAR2(n)

n は文字数

4000 バトまで

nvarchar(n)

日時型 DATE

紀元前 4712 年 1 月 1 日～

紀元 9999 年 12 月 31 日

秒まで

TIMESTAMP(n)

紀元前 4712 年 1 月 1 日～

紀元 9999 年 12 月 31 日

小数点以下 9 桁秒まで

datetime

1753 年 1 月 1 日～

9999 年 12 月 31 日


8 バト

datetime2(n)

1 年 1 月 1 日～

9999 年 12 月 31 日


有効桁数が 3 未満の場合 6 バト

有効桁数が 3 および 4 の場合は 7

バト

それ以上では 8 バト

smalldatetime

1900 年 1 月 1 日～

2079 年 6 月 6 日まで

精度秒まで

4 バト

バナリ型 RAW(n)

n は 2000 (バト) まで

binary(n)

ラージオブジェ

クト (LOB) 型

CLOB

Oracle 標準ブロックサ

ズ×(4G-1) バト

varchar(max)

NCLOB


ズ×(4G-1) バト

nvarchar(max)

BLOB


ズ×(4G-1) バト

varbinary(max)

フゔル参照型 BFILE

4GB

直接対応するデータ型はなし

FILESTREAM を用いて近い機能

Oracle：データベース外に保

存された大きなバナリフ

9

を実現することは可能ゔルへのロケーターを保

存

LONG 型 LONG

2GB-1 バト

varchar(max)

LONG RAW

2GB-1 バト

varbinary(max)

3.5 表 (テーブル) の移行

Oracle で使用頻度の高い表と対応する SQL Server のテーブルは以下の通りです。


表 (テーブル) 表ヒープテーブル

または

クラスタ化テーブル

SQL Server ではクラスタ化

ンデックスを作成してクラ

スタ化テーブルとすることが

一般的

索引構成表クラスタ化テーブル

パーテゖション表パーテゖションテーブル SQL Server ではハッシュパ

ーテゖションおよびリストパ

ーテゖションは対応していな

い

クラスタ表対応なし

外部表リンクサーバーやデータの

ンポートで移行

Oracle では、通常の表のデータはヒープ構造に並び替えられずに保存されます。

SQL Server ではテーブルに設定されるいずれかのンデックスをクラスタ化ンデックスとし、ン

デックスのリーフノードにデータを格納することが一般的です。このため索引構成表に加え通常の表に

ついてもクラスタ化テーブルに移行します。

クラスタ化テーブルのイメージ

10

表に設定されているどの索引をクラスタ化ンデックスに移行すべきかについては『3.6.索引 (ンデ

ックス) の移行』をご参照下さい。

Oracle では表の作成時に格納先の表領域を指定しますが、SQL Server のクラスタ化テーブルではク

ラスタ化ンデックスのリーフノードに行が格納されるため、クラスタ化ンデックスの格納先が行の

格納先となります。行を特定のフゔルグループに格納する必要がある場合はクラスタ化ンデックス

の格納先を指定することで間接的に指定します。

Oracle、SQL Server ともに、テーブル作成時に DEFAULT キーワードを使用して列のデフォルト値

を設定できます。デフォルト値に現在の日付を用いる場合の記述方法が異なるので注意が必要です。

CREATE TABLE 文の例 (Oracle)

CREATE TABLE customer

(

id CHAR(3) PRIMARY KEY,

name VARCHAR2(30) NOT NULL,

address VARCHAR2(50),

regdate DATE DEFAULT SYSDATE

) TABLESPACE tablespace1

「TABLESPACE」を用いてテーブルの格納先の表領域を指定しています。

SYSDATE を使用して、INSERT 時点の日時をデフォルト値に指定しています。

CREATE TABLE 文の例 (SQL Server)

CREATE TABLE customer

(

id char(3) NOT NULL,

name varchar(30) NOT NULL,

address varchar(50),

regdate datetime DEFAULT getdate(),

PRIMARY KEY CLUSTERED

(

id ASC

)ON [PRIMARY] --クラスタ化ンデックスの格納先フゔルグループを指定しています。

) ON [PRIMARY] --テーブルの格納先フゔルグループを指定しています。

「PRIMARY KEY」の後に続く「CLUSTERED」で主キーのンデックスをクラスタ化することを指

定しています。

「ON」を用いテーブル本体、クラスタ化ンデックスの格納先のフゔルグループを指定しています。

11

getdate() を使用して、INSERT 時点の日時をデフォルト値に指定しています。

3.6 索引 (インデックス) の移行

Oracle で使用頻度の高い索引と対応する SQL Server のンデックスは以下の通りです。


索引

(ンデックス)

索引

非クラスタ化ンデックス

または

クラスタ化ンデックス

クラスタ化ンデックス

1 テーブルに 1 つ

非クラスタ化ンデックス

SQL Server 2005

1 テーブルに 249

SQL Server 2008

1 テーブルに 999

キー列の最大バト数

900 バト

昇順、降順ともに対応

SQL Server はキー圧縮に対応

していない

コンポジット索引

キー列

32 列まで指定可能

複合ンデックス

キー列

16 列まで指定可能

キー列の最大バト数

900 バト

キー列の合計最大バト

900 バト

索引構成表クラスタ化ンデックス

パーテゖション索引パーテゖションンデックス SQL Server ではハッシュパー

テゖションおよびリストパーテ

ゖションは対応していない

ビットマップ索引対応なし

逆キー索引対応なし

関数索引対応なし

全文検索 Oracle Text フルテキストンデックス

SQL Server では、キー列及びキー列の合計サズが 900 バトを超えている列は、ンデックスの

キーとすることができません。

900 バトを超える列にンデックスを設定する方法としては、計算列及び計算列へのンデックス

追加を用いたハッシュンデックスの使用が考えられます。なお、ハッシュンデックスは等値比較

(=を用いた比較) のみ有効なンデックスとなります。

12

ハッシュインデックスの作成例 (SQL Server)

--Procut テーブルへ長い文字列が格納されている Name 列のハッシュ値を格納する列を追加します。

--CHECKSUM 関数はパラメータで指定された値に基づくハッシュ値を返します。

ALTER TABLE Production.Product

ADD cs_Pname AS CHECKSUM(Name);

--ハッシュ値が格納されている cs_Pname 列にンデックスを設定し、ハッシュンデックスを作成します。

CREATE INDEX Pname_index ON Production.Product (cs_Pname);

ハッシュインデックスを用いるクエリ例 (SQL Server)

--Procut テーブルへ長い文字列が格納されている Name 列のハッシュ値を格納する列を追加します。

--CHECKSUM 関数はパラメータで指定された値に基づくハッシュ値を返します。

SELECT *

FROM Production.Product

WHERE cs_Pname=CHECKSUM(N'Bearing Ball') --ハッシュ値を検索条件に追加

AND Name = N'Bearing Ball'; --ハッシュ値で発生する可能性のあるシノニム

--に対応するため、実際の値についての

--検索条件の指定も必要です。

一意キーは Oracle では複数の行に NULL を格納できますが、SQL Server では NULL は 1 行のみ

しか格納できません。ゕプリケーションの対応が必要です。

SQL Server で全文検索を行うには、フルテキスト検索機能を使用します。フルテキスト検索を使用す

るためには、SQL Server の導入時にデータベースエンジンのサブコンポーネントである「フルテキ

スト検索」を導入し、「SQL Full-text Filter Daemon Launcher」サービスを起動しておきます。

フルテキストカタログを作成し、フルテキストンデックスを作成することで全文検索が可能となり

ます。

13

3.7 ビューの移行

Oracle で使用頻度の高いビューと対応する SQL Server のビューは以下の通りです。


ビュービュー標準のビュー

マテリゕラズドビューンデックス付きビューマテリゕラズドビューは、

SSMA では通常のテーブルに

変換される

リフレッシュタミングなど、

運用面での差異あり

SQL Server ではビューの属性に READ ONLY を指定することはできません。

3.8 シノニムの移行


シノニムシノニムシノニム SSMA では、パブリックシノ

ニムは sysdb データベース

に通常のシノニムとして登録

される

パブリックシノニムシノニム

Oracle のパブリックシノニムを SQL Server に移行する場合は注意が必要です。SQL Server のシノ

ニムは必ずスキーマ内に格納する必要があります。

3.9 順序の移行


その他順序欠番が許される場合

テーブルの IDENTITY プロパテゖ

欠番が許されない場合

独自の採番処理を実装

DENTITY プロパテゖで INSERT

に伴うロックの取得前に採番

処理が行われるため、 INSERT

文が実行された順序に採番処

理が行われないことがありま

す。INSERT 文が実行された順に

採番処理を行う必要がある場

合は欠番が許されない場合と

同様に独自に採番処理を実装

する必要があります。

Oracle の順序はデータベース内のオブジェクトとして作成されます。

テーブル内で行の一意性を保つために順序を使用している場合は、IDENTITY プロパテゖを使用して

以下のように書き換えることができます。

14

順序の例 (Oracle)

CREATE SEQUENCE sequence1

START WITH 1 INCREMENT BY 1;

CREATE TABLE table1

(

col1 NUMBER DEFAULT sequence1.NEXTVAL,

col2 ……

);

INSERT INTO table1 (col2, ……) VALUES (……);

もしくは

INSERT INTO table1 VALUES (sequence1.NEXTVAL,……);

IDENTITY プロパティの例 (SQL Server)

CREATE TABLE table1

(

col1 int IDENTITY(1,1),

col2 ……

);

INSERT INTO table1 (col2,……) VALUES (……);

もしくは

INSERT INTO table1 VALUES (……)

順序の移行に IDENTITY プロパテゖを使用する場合、次の点に注意が必要です。

Oracle では MAXVALUE を指定して順序の最大値を指定できますが、SQL Server では

IDENTITY プロパテゖが設定されたデータの型の最大値が最大となります。

SQL Server の IDENTITY は、テーブルに対して 1 つだけ作成ができます。Oracle のように複

数のテーブルから同じ順序を使用することはできません。この場合、採番用のテーブルを作成する

などの仕組みの構築が必要となります。

Oracle の順序にある CYCLE、ORDER の指定はできません。

Oracle の順序、SQL Server の IDENTITY プロパテゖの両方で、最終的にロールバックされたトラ

ンザクションで生成された順序番号はスキップされ、欠番が発生します。欠番が許されない処理の場合

は独自に採番処理を実装する必要があります。以下に SQL Server での採番処理の実装例を記述します。

15

採番処理に用いるテーブルの作成及び行の追加 (SQL Server)

CREATE TABLE tblTable

(

Col1 int PRIMARY KEY,

Col2 int

)

INSERT INTO tblTable

VALUES(1,1)

採番処理の例 (SQL Server、ストアドプロシージャを用いた例)

CREATE PROCEDURE upSequence

(

Prm1 int OUTPUT --OUTPUT パラメータを用い採番された値を呼び出し元に返します。

)

AS

--ストゕドプロシージャの実行中、「n 件処理されました。」というメッセージの出力を停止します。

SET NOCOUNT ON

BEGIN TRAN --トランザクションを開始します。

--現在の値を採番テーブルから取得し、Prm1 に格納します。

SELECT Prm1=Col2

FROM tblTable WITH(UPDLOCK) –他のトランザクションによる変更を前提とした参照及び変更を禁止。

WHERE Col1=1

--加算した値を採番テーブルに格納します。

UPDATE tblTable SET Col2=Prm1+1 WHERE Col1=1

COMMIT --トランザクションを COMMIT します。

--n 件処理されました。」というメッセージの出力を開始します。

SET NOCOUNT OFF

16

3.10 ストアドプロシージャの移行

SQL Server のストゕドプロシージャは、サブプログラムをネストすることはできません。Oracle 環境での

ストゕドプロシージャがネストされたサブプログラムを持つ場合、単一のストゕドプロシージャに展開する

か、外部のストゕドプロシージャをコールする必要があります。

Oracle の例

create procedure Proc1 is

procedure DeptSales(dept_id int) is

lv_sales int;

begin

select sales into lv_sales from departmentsales where id = dept_id;

end DeptSales;

begin

DeptSales(100);

end Proc1;

SQL Server で外部のストアドプロシージャをコールする例

CREATE PROCEDURE Proc1$DeptSales

@dept_id int

AS

declare @lv_sales int

Select @lv_sales = sales From departmentsales Where id = @dept_id

RETURN

GO

CREATE PROCEDURE Proc1

AS

Execute Proc1$DeptSales 100

RETURN

GO

17

3.11 ユーザー定義関数の移行

Oracle ユーザー定義関数を移行するうえで注意する点は次のとおりです。

SQL Server ユーザー定義関数は DML ステートメントを記述できない

SQL Server ユーザー定義関数はストゕドプロシージャをコールできない

SQL Server ユーザー定義関数はトランザクション制御ステートメントを記述できない

SSMA による移行では、ユーザー定義関数内に記述された拡張ストゕドプロシージャが、上述項目の動作が

可能なユーザーストゕドプロシージャをコールする構造に変換されます。

SSMA を利用しない移行では、ユーザー定義関数を、上述項目を含まないユーザー定義関数と、上述項目を

含むストゕドプロシージャに分ける必要があります。

3.12 DML トリガーの移行

一般的に Oracle トリガーが行レベルのトリガーであるのに対して、SQL Server のトリガーはステートメ

ントレベルのトリガーのみとなります。

テーブルレベルのトリガーは SQL Server の AFTER トリガーと同様に扱うことができます。

CREATE TRIGGER [ schema. ]trigger ON <table>

AFTER <UPDATE |INSERT | DELETE>

AS

/* beginning of trigger implementation */

SET NOCOUNT ON

------------------------------------------------------------------------

/* Oracle-trigger implementation: begin */

BEGIN

-- UPDATE OF CLAUSE FOR TRIGGER FOR UPDATE EVENT

-- (UPDATE OF COLUMN[, COLUMN] ... ])

IF (UPDATE(<COLUMN>) OR UPDATE((<COLUMN>) ...)

BEGIN

<TRIGGER_BODY>

END

END

/* Oracle-trigger implementation: end */

------------------------------------------------------------------------

/* end of trigger implementation */

:NEW や:OLD 変数は、INSERTED や DELETED テーブルに格納されます。行レベルのトリガー移行はカ

ーソルを利用する必要があります。次の例では AFTER INSERT トリガーの移行を示します。

CREATE TRIGGER [ schema. ]trigger ON <table>

AFTER INSERT

AS

/* beginning of trigger implementation */

18

SET NOCOUNT ON

/* column variables declaration */

DECLARE

/* declare variables to store column values.

if trigger has no references to :OLD or :NEW

records then define the only uniqueidentifier type variable

to store ROWID column value */

@column_new_value$0 uniqueidentifier

/* trigger has NO references to :OLD or :NEW* or has explicit reference to ROWID/

/* trigger has references to :OLD or :NEW*/

@column_new_value$X <COLUMN_X_TYPE>,

@column_new_value$Y <COLUMN_Y_TYPE>,

...

@column_old_value$A <COLUMN_A_TYPE>,

@column_old_value$B <COLUMN_B_TYPE>

...

/* iterate for each for from inserted/updated table(s) */

DECLARE ForEachInsertedRowTriggerCursor CURSOR LOCAL FORWARD_ONLY READ_ONLY

FOR

/* trigger has NO references to :OLD or :NEW*/

SELECT ROWID FROM inserted

/* trigger has references to :OLD or :NEW* or has explicit reference to ROWID/

SELECT [ROWID], <COLUMN_X_NAME>,<COLUMN_Y_NAME> .. FROM inserted

OPEN ForEachInsertedRowTriggerCursor

FETCH NEXT FROM ForEachInsertedRowTriggerCursor INTO

/* trigger has NO references to :OLD or :NEW* or has explicit reference to

ROWID /

@column_new_value$0

/* trigger has references to :NEW*/

@column_new_value$X

@column_new_value$Y

...

WHILE @@fetch_status = 0

BEGIN

------------------------------------------------------------------------

/* Oracle-trigger implementation: begin */

19

BEGIN

IF <WHILE_CLAUSE>

BEGIN

<TRIGGER_BODY>

END

END

/* Oracle-trigger implementation: end */

------------------------------------------------------------------------

FETCH NEXT FROM ForEachInsertedRowTriggerCursor INTO

/* trigger has NO references to :NEW or has explicit reference to ROWID */

@column_new_value$0

/* trigger has references to :NEW*/

@column_new_value$X, @column_new_value$Y ...

END

CLOSE ForEachInsertedRowTriggerCursor

DEALLOCATE ForEachInsertedRowTriggerCursor

/* end of trigger implementation */

3.13 Oracle Package の移行

Oracle Package では、変数、型、ストゕドプロシージャ、ユーザー定義関数をカプセル化して利用するこ

とができます。SQL Server の移行では、Package のそれぞれのオブジェクトを個別に定義します。

20

3.14 エラーハンドリングの移行

Oracle の EXCEPTION は、SQL Server では TRY~CATCH へ移行します。

Oracle のエラーハンドリングの例

declare

myexception exception;

BEGIN

…

IF <condition> THEN

RAISE myexception;

END IF;

…

EXCEPTION

WHEN myexception THEN

<Statements>

END

SQL Server のエラーハンドリングの例

BEGIN TRY

…

IF <condition>

RAISERROR (‘myexception’, 16, 1)

…

END TRY

BEGIN CATCH

IF ERROR_MESSAGE() = ‘myexception’

BEGIN

<Statements>

END

ELSE

<rest_of_handler code>

END CATCH

21

3.15 カーソルの移行

カーソルで使用する多くのパラメタは単純移行が可能ですが、一部の機能はコーデゖングでカバーすること

になります。

操作 Oracle SQL Server

Declaring a

cursor

CURSOR cursor_name

[(cursor_parameter(s))]

IS select_statement;

DECLARE cursor_name CURSOR

[LOCAL | GLOBAL]

[FORWARD_ONLY | SCROLL]

[STATIC | KEYSET | DYNAMIC |

FAST_FORWARD]

[READ_ONLY | SCROLL_LOCKS |

OPTIMISTIC]

[TYPE_WARNING]

FOR select_statement

[FOR UPDATE [OF column_name [,…n]]]

Ref cursor

type

definition

TYPE type_name IS REF CURSOR

[RETURN

{ {db_table_name | cursor_name |

cursor_variable_name} % ROWTYPE

| record_name % TYPE

| record_type_name

| ref_cursor_type_name}];

Removes a REF cursor definition and

converts it to a variable declaration

as follows:

cursor_variable_declaration ::=

cursor_variable_name type_name;

Convert to:

@cursor_variable_name CURSOR;

Opening a

cursor

OPEN cursor_name

[(cursor_parameter(s))];

OPEN cursor_name

Cursor

attributes

{ cursor_name

| cursor_variable_name

| :host_cursor_variable_name}

% {FOUND | ISOPEN | NOTFOUND | ROWCOUNT}

次のような変数・関数への移行

@@FETCH_STATUS

CURSOR_STATUS()

SQL cursors SQL %

{FOUND | ISOPEN | NOTFOUND | ROWCOUNT

| BULK_ROWCOUNT(index) |

BULK_EXCEPTIONS(index).{ERROR_INDEX |

ERROR_CODE}}

次のようなコードへの移行

FOUND: Converts to (@@ROWCOUNT > 0)

NOTFOUND: Converts to (@@ROWCOUNT = 0)

ISOPEN: Converts to any condition that

is always false, for example (1=2)

ROWCOUNT: Converts to @@ROWCOUNT. For

example:

Oracle

IF SQL%FOUND THEN …;

MSSQL

IF @@ROWCOUNT > 0 …

Fetching

from cursor

FETCH cursor_name INTO variable(s) FETCH [[NEXT | PRIOR | FIRST | LAST |

ABSOLUTE {n | @nvar} | RELATIVE {n |

@nvar}]

FROM] cursor_name

[INTO @variable(s)]

Update

fetched row

UPDATE table_name

SET statement(s)…

WHERE CURRENT OF cursor_name;

UPDATE table_name

SET statement(s)…

WHERE CURRENT OF cursor_name

Delete

fetched row

DELETE FROM table_name

WHERE CURRENT OF cursor_name;

DELETE FROM table_name

WHERE CURRENT OF cursor_name

Closing

cursor

CLOSE cursor_name; CLOSE cursor_name

22

Remove

cursor data

structures

N/A DEALLOCATE cursor_name

OPEN … FOR

cursors

OPEN {cursor_variable_name

| :host_cursor_variable_name}

FOR dynamic_string [using_clause]

次のようなコードへの移行

DECLARE

@auxiliary_cursor_definition_sql$N

NVARCHAR(max),

@auxiliary_exec_param$N

NVARCHAR(max)

IF (cursor_status('variable',

N'<cursor_variable_name>') > -2)

DEALLOCATE

<cursor_variable_name>

SET @auxiliary_exec_param$N =

'[@auxiliary_paramN <datatype>

[OUTPUT],] … @auxiliary_tmp_cursor$N

cursor OUTPUT'

3.16 トランザクション

Oracle のトランザクションモデルでは、INSERT、UPDATE、DELETE あるいはその他の DML が実行され

た時、自動的にトランザクションが開始されます。ゕプリケーションは COMMIT を明示的に実行する必要

があります。

SQL Server では、利用する API によって異なりますが、Transact-SQL では自動コミットが既定となって

います。Oracle と同じトランザクションモデルを利用するには、暗黙的トランザクションを設定する必要が

あります。

暗黙的トランザクションの設定

SET IMPLICIT_TRANSACTIONS ON

3.17 自律型トランザクション

SQL Server には Oracle の自律型トランザクションに該当する機能は存在しません。

Oracle で AUTONOMOUS_TRANSACTION が設定されているオブジェクトは、SQL Server に移行するに

あたり複数のオブジェクトに分割し、それぞれ別のトランザクションとして呼び出す必要があります。

TRY~CATCH の CATCH ブロックの中で、エラー処理としてオブジェクトを変更しなければならない場合

は、新たにトランザクションを開始する必要があります。

BEGIN TRAN

BEGIN TRY

-- エラー発生

END try

BEGIN CATCH

ROLLBACK -- ロールバック

23

BEGIN TRAN

-- エラー処理

COMMIT

END CATCH

IF @@TRANCOUNT > 0 COMMIT

24

4. クエリの移行

4.1 SQL 全般

ここでは SQL で頻繁に利用される、以下の点についての違いを説明します。

コメント

ヒント句の記述

結合処理

演算子

結論から述べると ORACLE と SQL Server での違いは殆どありません。

一部演算子で異なる動作があるものの、ORACLE で記述した内容と SQL Server での記述方法は殆ど同じ

です。以下に例を挙げて ORACLE と SQL Server の違いを見ていきます。

分類 Oracle SQL Server

コメントの記述単一行コメント、範囲コメントの記述は、SQL

Server と同じです。

単一行コメント (例) -- 改行までコメント

範囲コメント (例) /* ここからここまで */

結合ヒント /*+ <ヒント句> */ のように記述します。

結合ヒントは「USE_NL、USE_HASH、

USE_MERGE、DRIVING_SITE」があります。

<使用例>

SELECT /*+ USE_HASH(B) */

*

FROM

TBL_A A

INNER JOIN TBL_B B

ON A.PK = B.PK

テーブルの結合ヒントは ORACLE と同様

「LOOP|HASH|MERGE|REMOTE」の 4 種類ありま

す。

下線部に結合ヒント

(LOOP|HASH|MERGE|REMOTE)を記述します。

<使用例>

SELECT

*

FROM

TBL_A A

INNER HASH JOIN TBL_B B

ON A.PK = B.PK

※ORACLE の DRIVING_SITE ヒントは、SQL

Server の REMOTE に相当します。

クエリヒント SQL 文の先頭に記述します。

SELECT、INSERT、UPDATE、DELETE 句の

直後に記述します。

<使用例>

SELECT /*+ ORDERED */

*

FROM

SQL 文の最後に OPTION 句を使用して記述し

ます。

<使用例>

SELECT

*

FROM

TBL_A A

25

TBL_A A


ON A.PK = B.PK

INNER HASH JOIN TBL_C C

ON A.PK = C.PK

代表的なヒント句には以下があります。

CHOOSE

RULE

FIRST_ROWS

ALL_ROWS

INDEX

INDEX_DESC

ORDERED

APPEND


ON A.PK = B.PK

INNER HASH JOIN TBL_C C

ON A.PK = C.PK

OPTION

(FORCE ORDER)

代表的なヒント句には以下があります。

MAXDOP

FAST n

READPAST

ROWLOCK

UPDLOCK

TABLOCK

テーブルヒントテーブル名の直後に記述します。

SELECT

*

FROM

TBL_A FOR UPDATE NOWAIT

ORACLE と同様、テーブル名の直後に記述します。

SELECT

*

FROM

TBL_A WITH(NOWAIT, UPDLOCK)

結合の種類テーブルの結合には以下の種類があります。

INNER JOIN

LEFT JOIN

RIGHT JOIN

FULL JOIN

CROSS JOIN

ORACLE と同様、以下の結合の種類があります。

INNER JOIN

LEFT JOIN

RIGHT JOIN

FULL JOIN

CROSS JOIN

結合方法構文は次のとおりです

<使用例>

SELECT

*

FROM

TBL_A A

LEFT JOIN TBL_B B

ON A.PK = B.PK

構文は Oracle と同じです

<使用例>

SELECT

*

FROM

TBL_A A

LEFT JOIN TBL_B B

ON A.PK = B.PK

算術演算子 + (加算)

- (減算)

* (乗算)

/ (除算)

+ (加算)

- (減算)

* (乗算)

/ (除算)

% (剰余)

<使用例>

SELECT 12 % 5 AS MEMO -- 結果は 2

文字列連結演算子 || (又は関数(CONCAT)を使用します)

<使用例>

+

<使用例>

26

SELECT

'1' || '2' AS MEMO

FROM

DUAL -- 結果は '12' (文字列連結)

SELECT

1.5 ||'0.5' AS MEMO

FROM

DUAL -- 結果は '1.50.5' (文字列連

結)

NULL を含む文字列連結では、NULL は長さゼ

ロの文字列(空文字)として扱われます。

<(例)NULL の文字列連結>

SELECT '1' || NULL AS MEMO

FROM DUAL

MEMO

-------

1

SELECT '1' + '2' AS MEMO -- 結果は

'12'(文字)

SELECT 1.5 + '0.5' AS MEMO -- 結果は 2.0

(数値)

参考: 以下の場合はエラーになります。

SELECT 1 + '0.5' AS MEMO

-- '0.5'をデータ型 int に変換できません

これは、最初に指定している 1 の数値が、SQL

Server 内部では整数型 (小数を使用しないデー

タ型)として処理されるため、そこに 0.5 を加算

するとみなされエラーとなります。文字列連結も

加算も同じ演算子「+」を使用するので、データ型

を適切に指定する必要があります。

SQL Server では NULL を含む文字列連結の結

果は NULLL となります。

<(例)NULL の文字列連結>

SELECT '1' + NULL AS MEMO

MEMO

-------

NULL

NULL を含む可能性のある文字列を連結する場合

は、ISNULL 関数を使用して、以下のように変更

します。

SELECT '1' + ISNULL(NULL,'') AS MEMO

代入演算子 = =

<使用例>

SET @VAL_X = 1 + 2

論理演算子以下の演算子を使用できます。

ALL

AND

ANY

BETWEEN

EXISTS

IN

LIKE

NOT

ORACLE と同じ演算子を使用できます。

ALL

AND

ANY

BETWEEN

EXISTS

IN

LIKE

NOT

27

OR

SOME

<ANY の使用例>

SELECT

*

FROM

TBL_A

WHERE

BONUS >= ANY (1000, 2000)

OR

SOME

但し、ORACLE と以下の点が異なります。

SQL Server で SOME、ANY を使用する場合はサ

ブクエリとして記述します。

ORACLE で左記のように ANY、SOME を記述して

いる場合は、その中をサブクエリの記述に変更し

ます。

<(例)ANY の記述を変更>

SELECT

*

FROM

TBL_A

WHERE

BONUS >= ANY ( SELECT 1000 AS BUNUS

UNION ALL

SELECT 2000 AS BUNUS

)

集合演算子 UNION

UNION ALL

INTERSECT

MINUS

<使用例>

SELECT * FROM TBL_A

MINUS

SELECT * FROM TBL_B

UNION

UNION ALL

INTERSECT

EXCEPT (ORACLE の MINUS に相当)

<使用例>

SELECT * FROM TBL_A

EXCEPT

SELECT * FROM TBL_B

比較演算子 = (等しい)

> (より大きい)

< (より小さい)

>= (以上)

<= (以下)

<> (等しくない)

!= (等しくない)

^= (等しくない)

= (等しい)

> (より大きい)

< (より小さい)

>= (以上)

<= (以下)

<> (等しくない)

!= (等しくない。ISO 標準外)

!< (より小さくない。ISO 標準外)

!> (より大きくない。ISO 標準外)

その他の演算子 (+) (外部結合で使用)

PRIOR (階層問い合わせで使用)

外部結合演算子(+)は LEFT JOIN、RIGHT JOIN

で記述します。

階層問い合わせ用の演算子(PRIOR)は、使用する

必要はありません。SQL SERVER での階層問い合

わせは CTE(共通テーブル式) を使用した再帰ク

エリとして実装するので、特別な演算子は使用し

ません。

28

ビット演算子 <ORACLE 10g 以降>

& (論理積)

| (論理和)

~ (否定)

^ (排他的論理和)

※9i 以前のバージョンにはビット演算子は

ありません。

以下のビット演算子が使用できます。

& (論理積)

| (論理和)

~ (否定)

^ (排他的論理和)

4.2 基本的な SQL 構文

SQL Server は、ANSI SQL 92 に準拠しており ORACLE と同じように SELECT、INSERT、UPDATE、

DELETE を使用することができます。SELECT や INSERT でテーブルを結合した操作を行う場合、ORACLE

も SQL Server も同じです。但し、テーブルを結合しながら UPDATE、DELETE を行う場合は、記述方法

が異なります。以下にこの違いを説明します。


テーブルを

結合して

UPDATE

UPDATE (

SELECT

T1.ITEM AS ITM1,

T2.ITEM AS ITM2

FROM

TBL1 T1

LEFT JOIN TBL2 T2

ON T1.ITEM = T2.ITEM

WHERE

T2.ITEM IS NULL

) HOGE

SET ITM1 = '無し'

UPDATE TBL1

SET

ITEM = '無し'

FROM

TBL1 T1

LEFT JOIN TBL2 T2


WHERE

T2.ITEM IS NULL

SQL Server では、更新対象となるテーブルを

UPDATE 句の直後、FROM 句の中の 2 箇所に記述

します(下線部)。

テーブルを

結合して

DELETE

DELETE FROM TBL1 Tx

WHERE

Tx.ITEM IN (SELECT

T1.ITEM

FROM

TBL1 T1

LEFT JOIN TBL2 T2


WHERE

T2.ITEM IS NULL

)

DELETE TBL1

FROM

TBL1 T1

LEFT JOIN TBL2 T2


WHERE

T2.ITEM IS NULL

UPDATE の時と同様、削除対象となるテーブルを 2

箇所に記述します(下線部)。

29

SELECT 句を使用してその結果をもとに、テーブルを作成することがあります。

ORACLE では CREATE TABLE XXX AS SELECT ～を使用しますが、SQL Server では SELECT 句だけ

を使用します。以下にこの違いを記述します (注: 実行には CREATE TABLE 権限が必要です)。


SELECT 結

果をもとに

テーブルを

作成

--テーブル定義とデータをコピー

CREATE TABLE <<テーブル名_BKUP>>

AS

SELECT * FROM テーブル名

--テーブル定義だけをコピー

CREATE TABLE <<テーブル名_BKUP>>

AS

SELECT * FROM テーブル名

WHERE 1=0

--テーブル定義とデータをコピー

SELECT *

INTO <<テーブル名_BKUP>>

FROM テーブル名

--テーブル定義だけをコピー

SELECT *

INTO <<テーブル名_BKUP>>

FROM テーブル名

WHERE 1=0

ORACLE には DUAL 表 (ダミー表) がありますが、SQL Server にはダミー表はありません。

DUAL 表を使用した SELECT 句を記述する場合は以下のように記述します。


ダミー表を

使用した

SELECT

SELECT

123 AS MEMO

FROM

DUAL

※ORACLE では SELECT 構文に従って記述する必

要があるため、上記のようにダミー表を使用して

SELECT を行います。

左記の ORACLE と同じ SELECT を記述する場合

は、以下のように記述します。

SELECT 123 AS MEMO

--「FROM DUAL」の記述は不要です。

<使用例 1> SQL SERVER の関数の実行結果を調

べる

SELECT REPLACE('ABC','B','★') AS MEMO

<使用例 2> 一時的なデータを作成/利用する場合

SELECT

*

FROM

(SELECT '01 月' AS TSUKI

UNION ALL SELECT '02 月' AS TSUKI

30

/* : */

UNION ALL SELECT '12 月' AS TSUKI

) TMP

SELECT 句で NULL を含んだデータを並び替えることがあります。

ORACLE と SQL Server では NULL を含むデータの並び順に違いがあります。

以下で ORACLE で NULL を含むデータの並び順と、SQL Server での並び順、および対応方法を説明しま

す。


NULL の並

び順

NULL のデータの並び順は、SELECT 結果の最後に

なります。

<例: NULL は最後に取得される>

SELECT

*

FROM

(SELECT '0001' AS ITEM FROM DUAL

UNION ALL SELECT '0002' AS ITEM FROM DUAL

UNION ALL SELECT '0003' AS ITEM FROM DUAL

UNION ALL SELECT NULL AS ITEM FROM DUAL

) TMP

ORDER BY

ITEM

ITEM

--------------

0001

0002

0003

(NULL) ←ORACLE ではココ

SQL SERVER では NULL のデータは、SELECT

結果の最初に並びます。

<例: ORACLE と同じ SQL を記述した場合>

SELECT

*

FROM

(SELECT '0001' AS ITEM

UNION ALL SELECT '0002' AS ITEM

UNION ALL SELECT '0003' AS ITEM

UNION ALL SELECT NULL AS ITEM

) TMP

ORDER BY

ITEM

ITEM

--------------

NULL ←SQL SERVER ではココ

0001

0002

0003

<対応方法(ORDER BY 句を修正する)>

SELECT

: (途中省略)

ORDER BY

-- ITEM

-- ↓これで ORACLE と同じ並び順になりま

す

CASE WHEN ITEM IS NULL THEN '9999' ELSE

ITEM END

31

空白を含む文字列を比較(*1) する場合は以下の点に気をつける必要があります。

(*1 … DECODE 関数や CASE 関数、WHERE 句など)


空白を含む

文字列の比

較

以下の結果は「不一致」が取得されます。

SELECT

CASE WHEN CHAR1 = CHAR2 THEN '一致' ELSE

'不一致' END AS MEMO

FROM

(SELECT

'ABC' AS CHAR1, -- これは CHAR 型

CAST('ABC ' AS VARCHAR(10)) AS

CHAR2 -- VARCHAR 型(最後空白)

FROM

DUAL

) TMP

ORACLE では「空白埋め比較セマンテゖクスおよび

非空白埋め比較セマンテゖクス」というデータ型

を比較するルールがあります。簡単にいうと、次

の例のように CHAR 型どうしでの文字列比較は

「文字列の短い方に、文字列が長い方と同じ長さ

になるまで空白を付加し、その後で文字列の比較

を行うというものです」。

<例: 結果が「一致」になるケース>

SELECT



FROM

(SELECT


CAST('ABC ' AS CHAR(10)) AS CHAR2

-- これも CHAR 型(最後空白)

FROM

DUAL

) TMP

以下の結果は「一致」が取得されます。

SELECT



FROM

(SELECT


CAST('ABC ' AS VARCHAR(10)) AS CHAR2

-- VARCHAR 型(最後空白)

) TMP

※ORACLE の VARCHAR や VARCHAR2 型など、可変

長文字列型の最後に空白が含まれる場合、ORACLE

と SQL Server での空白を含む文字列の判断方法

の違いに注意する必要があります。

ORACLE でも SQL Server でも SQL 文の中で定数を記述することがあります。

定数が指定された場合、ORACLE と SQL Server が自動的にデータ型を割り当てますが、自動的に割り当

てられた内部データ型が何になるかを以下で説明します。

32


定数を指定

した時の内

部データ型

SQL 文で定数を指定した場合の内部データ型は以

下となります。

1 … NUMBER

1.0 … NUMBER

1.00 … NUMBER

'A' … CHAR(1)

'AB' … CHAR(2)

REPLACE('ABC','B','') … VARCHAR2(2)

CAST('A' AS CHAR(4)) … CHAR(4)

SQL Server で ORACLE と同じ定数を指定した場

合の内部データ型は以下となります。

1 … int --★整数型

1.0 … numeric(2, 1)

1.00 … numeric(3, 2)

'A' … VARCHAR(1) --★ORACLE は CHAR 型

'AB' … VARCHAR(2) -- ★ORACLE は CHAR 型

REPLACE('ABC','B','') … VARCHAR(8000)

–-★

CAST('A' AS CHAR(4)) … CHAR(4) --◎

ORACLE と比較しても、基本的に内部データ型に大

きな違いはありませんが、★の箇所のような違いが

あります。

定数を指定した場合、厳密なデータ型とならなけれ

ばならない場合は、◎のように CAST 関数を使用し

て明示的なデータ型を指定します。

4.3 関数

ORACLE で利用頻度が高いと思われる関数を挙げ、SQL Server でその関数と同じことを行う場合、どのよ

うに記述するかを以下に説明します。

ORACLE 関数 Oracle SQL Server

ADD_MONTHS SELECT --3 ヶ月後を取得

ADD_MONTHS('2009/12/01', 3) AS

MEMO

FROM

DUAL

SELECT --3 ヶ月後を取得(注: 時分秒まで取得)

DATEADD(month, 3, '2009/12/01')

CASE SELECT

CASE

WHEN 1 = 1 THEN 'True'

ELSE 'False'

END AS MEMO

FROM

DUAL

SELECT

CASE

WHEN 1 = 1 THEN 'True'

ELSE 'False'

END AS MEMO

33

CEIL SELECT

CEIL(VAL) AS MEMO

FROM

DUAL

SELECT

CEILING(VAL) AS MEMO

DECODE SELECT

DECODE( SEX,

'1', '男',

'2', '女',

'不明'

) AS SEIBETSU

FROM

TBL_DANJO

CASE 関数に変更します。

SELECT

CASE SEX

WHEN '1' THEN '男'

WHEN '2' THEN '女'

ELSE '不明'

END AS SEIBETSU

FROM

TBL_DANJO

ORACLE の DECODE 関数は短絡評価(真となる条

件に一致したら、それ以降の条件判断は行わない)

ですが、CASE 関数は短絡評価ではありません。短

絡評価を利用した DECODE 関数を CASE 関数に変

更する場合は注意が必要です。

REPLACE SELECT

REPLACE('ABC','B','★') AS MEMO

FROM

DUAL

SELECT

REPLACE('ABC','B','★') AS MEMO

LENGTHB SELECT

LENGTHB('あいう') AS MEMO

FROM

DUAL

SELECT

DATALENGTH('あいう') AS MEMO

LENGTH SELECT

LENGTH('あいう') AS MEMO

FROM

DUAL

SELECT

LEN('あいう') AS MEMO

TRIM

LTRIM

RTRIM

SELECT -- TRIM で前後の空白を除去

TRIM(' あいう ') AS MEMO

FROM

DUAL

SELECT --LTRIM と RTRIM で前後の空白を除去

RTRIM(LTRIM(' あいう ')) AS MEMO

FROM

DUAL

ROUND SELECT --小数第一位を丸める

ROUND( 123.45 , 1 ) --結果は 123.5

SELECT --小数第一位を丸める

ROUND( 123.45 , 1 ) --結果は 123.50

34

FROM

DUAL

SUBSTR SELECT --結果は「うえ」

SUBSTR('あいうえお', 3, 2) AS MEMO

FROM

DUAL

SELECT --結果は「うえ」

SUBSTRING('あいうえお', 3, 2) AS MEMO

LPAD

RPAD

SELECT --左側をゼロパデゖングする

LPAD('123' , 5 , '0') AS MEMO

FROM

DUAL

SELECT --左側をゼロパデゖングする

RIGHT('00000' + '123' , 5) AS MEMO

※'00000' + '123' の結果「'00000123'」の右

から 5 文字を取り出す。取り出される結果は

「'00123'」。

TRUNC SELECT --千の位で切捨て。結果は「12000」

TRUNC(12345, -3) AS MEMO

FROM

DUAL

該当関数なし。以下の対応方法で実装可能。

SELECT --結果は 12000

CAST(12789 / 1000 AS INT) * 1000 AS MEMO

※ROUND 関数を以下のように使用すると結果が

「13000」になるため、CAST を使用して千の位で

切り捨てを行っている。

SELECT --結果は 13000

ROUND(12789, -3) AS MEMO

NVL SELECT

NVL(NULL,'NULL です') AS MEMO

FROM

DUAL

SELECT

ISNULL(NULL,'NULL です') AS MEMO

TO_CHAR SELECT

TO_CHAR(10) AS MEMO

FROM

DUAL

SELECT --どちらも可能

CONVERT(CHAR, 10) AS MEMO,

CAST(10 AS CHAR) AS MEMO2

MOD SELECT

MOD(12, 5) AS MEMO -- 結果は 2

FROM

DUAL

SELECT 12 % 5 AS MEMO -- 結果は 2

GREATEST SELECT --結果は「9」

GREATEST( 1, 2, 3, 5, 9 ) AS MEMO


SQLCLR を使用して GREATEST 関数と同等の

35

FROM

DUAL

I/F を持つストゕドフゔンクションを作成し、SQL

文からこれを呼び出す。

LEAST SELECT --結果は「1」

LEAST( 1, 2, 3, 5, 9 ) AS MEMO

FROM

DUAL


SQLCLRを使用して LEAST関数と同等のI/Fを持

つストゕドフゔンクションを作成し、SQL 文からこ

れを呼び出す。

SYSDATE --結果は「2009/12/09 19:00:00」

SELECT

SYSDATE AS MEMO

FROM

DUAL

--結果は「2009-12-09 19:42:00.593」

SELECT

GETDATE() AS MEMO

36

4.4 ORACLE 特有の機能を含んだ SQL

ORACLE を使用する際によく利用されると思われる ORACLE 固有の機能を、SQL Server でどのように実

装するかを以下に示します。


一時表 ORACLE には以下 2 通りの一時表がありま

す。

(1) セッション内で有効な一時表

CREATE GLOBAL TEMPORARY TABLE

<<TMP_テーブル名>>

(列名 1 データ型〃

列名 2 データ型,

:

)

ON COMMIT PRESERVE ROWS

(2) トランザクション内で有効な一時表

CREATE GLOBAL TEMPORARY TABLE

<<TMP_テーブル名>>

(列名 1 データ型〃

列名 2 データ型,

:

SQL Server に移行する場合は、以下の方法で対応

します。

(1) セッション内で有効な一時表(ローカル一時テ

ーブル)

<使用例> 一時テーブルを作成する

SELECT

*

INTO

#<<TMP_テーブル名>> --先頭に # を付ける

FROM

<<テーブル名>>

又は明示的に CREATE TABLE することもできま

す。

CREATE TABLE #<<TMP_テーブル名>>(

列名 1 , 列名 2 ...

)

注意：ORACLE の場合、セッション終了時に一時表

の「データだけがクリゕ」されますが、SQL SERVER

の場合は、#TMP_テーブル名の「テーブル定義その

ものが DROP される」という違いがあります。

(2) トランザクション内で有効な一時表

ORACLE のトランザクション内で有効な一時表

(CREATE GLOBAL TEMPORARY TABLE .. ON

COMMIT DELETE ROWS)に相当する機能は SQL

Server の標準機能にはありません。上記のように

ローカル一時テーブルを作成し、ゕプリ側でトラン

37

)

ON COMMIT PRESERVE ROWS

ザクションを COMMIT した後、ローカル一時テー

ブルを TRUNCATE する方法で対応します。

(3) グローバル一時テーブル

SQL SERVER 固有の機能です。ORACLE には無い機

能です。##<TMP_テーブル> のように、テーブル名

の先頭に ## を付与します。(1) のローカル一時テ

ーブルと同じ方法で作成できます。ローカル一時テ

ーブルとの違いは「複数のセッションから利用でき

る」という点です(複数のゕプリから共有メモリを

参照するというメージに近いです)。全てのセッ

ションから参照されなくなると自動的にテーブルが

クリゕ(削除)されます。

自律型トランザ

クション

ゕプリケーションのトランザクション内で、

そのトランザクションとは独立したトランザ

クション処理を行うことができます。

利用用途として例を挙げると、ゕプリケーシ

ョンの監査ログをゕプリの正常/異常終了に

関係なく、監査ログテーブルに出力する場合

などがあります。

ORACLE では以下のように使用します。

/*「自立型トランザクション(例: ログ出力)

のプロシージャを作成。ゕプリのトランザク

ション内から呼び出す */

CREATE OR REPLACE PROCEDURE

xxx.WriteLOG(

pECODE IN NUMBER,

pEMSG IN VARCHAR2

)

IS

PRAGMA AUTONOMOUS_TRANSACTION;

--自律型トランザクション

SQL SERVER には標準機能として自律型トランザ

クションに相当する機能は存在しません。SQL

Server には Oracle の自律型トランザクション

に該当する機能は存在しません。

<対応方法>

Oracle で自律型トランザクションが設定されてい

るオブジェクトは、SQL Server に移行するにあた

り複数のオブジェクトに分割し、それぞれ別のトラ

ンザクションとして呼び出す必要があります。

CREATE PROCEDURE xxx.WriteLOG

@pECODE int,@pEMSG nvarchar(50)

AS

BEGIN TRANSACTION;

INSERT INTO LOGTBL VALUES (@pECODE,

@pEMSG);

COMMIT;

GO

38

BEGIN

INSERT INTO LOGTBL VALUES (pECODE,

pEMSG);

COMMIT;

END;

--ゕプリから上記プロシージャを呼び出す。

CREATE OR REPLACE PROCEDURE

xxx.Application_XYZ

IS

BEGIN

EXECUTE IMMEDIATE 'INSERT INTO

BAD_TABLE VALUES (NULL)';

--エラーが発生、EXCEPTION へジャンプ。

COMMIT;

EXCEPTION

WHEN OTHERS THEN

DBMS_OUTPUT.PUT_LINE('エラー発

生:' || SQLCODE || ':' || SQLERRM);

--ゕプリとは異なるトランザクション

で処理されるため、

--WriteLOG で INSERT された内容

はロールバックされない。

WriteLOG(SQLCODE, 'INSERT

ERROR');

ROLLBACK;

END;

CREATE PROCEDURE xxx.Application_XYZ

AS

BEGIN TRANSACTION

BEGIN TRY

--エラーが発生、EXCEPTION へジャンプ。

END TRY

BEGIN CATCH

ROLLBACK

EXEC WriteLOG 1,N'ERROR OCCURED'

END CATCH

IF @@TRANCOUNT>0 COMMIT

GO

正規表現 <ORACLE 10g 以降>

以下の正規表現 (関数) が使用できます。

REGEXP_LIKE 関数

REGEXP_REPLACE 関数

REGEXP_INSTR 関数

REGEXP_SUBSTR 関数

SQL Server では、大きく分けて 2 つの対応方法

があります。

(1) LIKE を使用する

SQL SERVER では、比較的単純なパターンマッチン

グであれば LIKE を使用したパターンマッチング

が行えます(後述)。

(2) SQLCLR として実装する。

正規表現の全ての機能を使用する場合は、SQL

SERVER の機能である SQLCLR を使用して「正規

表現の機能を実装したストゕドプロシージャを作

39

成」することができます。これを利用することで

SQL 文から正規表現の機能を使用することができ

ます(正規表現以外にも様々な処理を SQLCLR と

して作成できます)

LIKE を使用したパターンマッチング

SQL SERVER では一般的な LIKE 演算子で使用

される % や _(ｱﾝﾀﾞｰｽｺｱ) 以外に正規表現の文字

集合( [] )に類似したパターンマッチングが行え

ます。

<記述方法>

xxx LIKE '[abc]zz%' -- azz、bzz、czz で

始まる文字列にマッチ

xxx LIKE '[^x]%' -- x 以外の文字で始ま

る文字列にマッチ

<使用例>

SELECT

* -- 抽出結果は 3 件(斉藤, 佐藤, 獅子

籐)

FROM

--------------------

(SELECT '斉藤' AS Name -- 斉

藤

UNION ALL SELECT '佐藤' AS Name -- 佐

藤

UNION ALL SELECT '獅子籐' AS Name -- 獅

子籐

UNION ALL SELECT '本田' AS Name

) TMP

WHERE

Name LIKE '%[^田]'

フラッシュバッ

ククエリ

過去のある時点のデータを取得できます。

操作ミスなど、データを誤って削除した場合、

標準機能でこれに該当する機能はありませんが、こ

れに類似する機能として「変更データキャプチャ」

40

削除される前のデータを取得できるので、こ

れを使用してデータを復旧する場合などに使

用されます。

<例>

今から 5 分前に TBL_A のデータを誤って

全て削除してしまった。削除前のデータを復

旧するために、今から 10 分前の TBL_A の

データ (状態) を取得する。

SELECT * FROM TBL_A

AS OF timestamp (

systimestamp - interval '10'

minute)

機能があります。

変更データキャプチャは、SQL Server のテーブ

ルに対して適用された挿入、更新、削除の各操作を

記録・保存します。この機能を使用する際は、事前

にこの機能を有効化しておく必要があります。

マルチレコード

ンサート

ORACLE では INSERT ALL～、 INSERT

FIRST～を使用して複数のテーブルへ

INSERT できます。

<例 1> 定数をもとに複数レコードを同一テ

ーブルへ INSERT する。

INSERT ALL

INTO TBL_A(aa, bb) values(1, 2)

INTO TBL_A(aa, bb) values(3, 4)

SELECT * FROM DUAL --これはダミー

表

<例 2>あるテーブルの値を判断、条件により

複数テーブルへ INSERT

INSERT ALL

WHEN EMP_TBL.SEX = '1' then

INTO TBL_01

WHEN EMP_TBL.SEX = '2' then

INTO TBL_02

SELECT * FROM EMP_TBL

ORACLE では INSERT ALL～、INSERT FIRST～

を使用して複数のテーブルへ INSERT できます。

<例 1> 定数をもとに複数レコードを同一テーブル

へ INSERT する。

INSERT

INTO TBL_A(aa, bb) Values (1,2), (3,4)

ORACLE のように 1 つの SQL 文で複数のテーブ

ルへ INSERT する機能はありません。

これを行う場合は、INSERT するテーブル単位に

INSERT 文を使用します。

INSERT INTO TBL_01

SELECT * FROM WHEN EMP_TBL.SEX = '1'

INSERT INTO TBL_02

SELECT * FROM WHEN EMP_TBL.SEX = '2'

ROUNUM --最初に降順にデータを並び替えてから

SELECT

ROW_NUMBER() OVER(ORDER BY PK DESC) AS

41

--ROWNUM で順序を付与する。

SELECT

ROWNUM AS SEQNO,

TMP_TBL.*

FROM

(SELECT

TMP_TBL.*

FROM

(SELECT 'AAA' AS PK

UNION ALL SELECT 'BBB' AS PK

FROM DUAL

UNION ALL SELECT 'CCC' AS PK

FROM DUAL

) TMP_TBL

ORDER BY

PK DESC

) TMP

SEQNO,

TMP_TBL.*

FROM

(SELECT 'AAA' AS PK

UNION ALL SELECT 'BBB' AS PK

UNION ALL SELECT 'CCC' AS PK

) TMP_TBL

ROWNUM PK

-------------------- ----

1 CCC

2 BBB

3 AAA

ROWID データ行の位置を特定する内部形式の値を取

得する機能です。

データ行の位置を特定できるため、ROWID を

使用して UPDATE を行うことができます。

SQL Server ではこれに該当する標準機能はあり

ません。テーブルを作成する際に ROWID という名

前のデータ項目を IDENTITY 型などでテーブル

項目として定義する方法が考えられます。

データベースリ

ンク

オラクルでは以下のようにデータベースリン

クを作成します。

CREAT DATABASE LINK HokkaidoSV

CONNECT TO USR01

IDENTIFIED BY PASSWORD

USING 'ORACLE_SERVER'

データベースリンクを使用する場合

SELECT * FROM USR01.TBL_A@HokkaidoSV

SQL Server ではリンクサーバーと呼ばれる機

能が

ORACLE のリンクサーバーに相当します。以下のよ

うに作成します。

EXEC sp_addlinkedserver

'HokkaidoSV',

N'SQL Server'

USING 'ORACLE_SERVER'

データベースリンクを使用する場合

SELECT * FROM

HokkaidoSV.USR01.dbo.TBL_A

和暦変換 --和暦日付を取得する

SELECT

TO_CHAR(SYSDATE,'eeyy/mm/dd',

'nls_calendar = ''Japanese

Imperial'''

) AS MEMO

SQL Server には標準機能で和暦変換機能はあり

ません。

SQL CLR、又は SQL Server のストゕドフゔンク

ション (関数) を利用して和暦変換関数を作成

して対応する必要があります。

mailto:USR01.TBL_A@HokkaidoSV

42

FROM

DUAL

ランダム値ストゕドパッケージを呼び出してランダム値

を取得します。

SELECT

DBMS_RANDOM.RANDOM() AS MEMO

FROM

DUAL

RAND 関数を使用してランダム値を生成できます。

SELECT

RAND() AS MEMO

MERGE 文既に更新対象のデータが存在する場合は

UPDATE と、存在しない場合は INSERT を

行います。

MERGE INTO TBL_A A

USING TBL_B B

ON (A.PK = B.PK)

WHEN MATCHED THEN

UPDATE SET A.ITEM = 'UPD'

WHEN NOT MATCHED THEN

INSERT (ITEM) VALUES ('INS')

SQL Server でも MERGE 文を使用できます。

MERGE INTO TBL_A A

USING TBL_B B

ON (A.PK = B.PK)

WHEN MATCHED THEN

UPDATE SET A.ITEM = 'UPD'

WHEN NOT MATCHED THEN

INSERT (ITEM) VALUES ('INS')

動的 SQL ネテゖブの動的 SQL 実行は以下で行いま

す。

DECLARE

BEGIN

EXECUTE IMMEDIATE 'DROP TABLE

TBL_A';

END;

※他に DBMS_SQL パッケージを使用した

動的 SQL の実行が可能です。

ORACLE のネテゖブ実行に相当する機能は以下

となります。

EXEC (' DROP TABLE TBL_A ')

※他に sp_executesql を使用した動的 SQLの実

行も可能です(ORACLE の DBMS_SQL パッケージ

に相当します)。

フゔル入出力 ORACLE では UTL_FILE パッケージを使

用して、フゔルの入出力を行うことができ

ます。

ORALCE の左記の機能について、SQL Server 標

準機能ではサポートされている機能はありません。

しかし、SQLCLR を使用してユーザーがフゔル出

力機能を作成することで対応することができます。

43

5. データの移行

5.1 移行方式概要

Oracle から SQL Server へデータを移行する方式は、大別して、直接データ移行とフゔルを経由する間

接データ移行の、2 つの方式が考えられます。

データ移行元、先の両サーバーが同時に使用できない、WAN を経由する、ネットワークセグメントが異な

り直接やり取りができないなどネットワークを介さないでデータを移行したい場合は、間接データ移行を行

います。両サーバーが利用でき、ネットワーク経由でデータが移動できる場合は、直接データ移行を行いま

す。

Oracle から SQL Server へデータを移行する場合、その多くはサーバーリプレースやシステム更改時に同

一拠点・LAN 内で移行が行われるため、主に直接データ移行が使われます。

1) 直接データ移行

2) 間接データ移行

直接/間接データ移行のメリットデメリット

直接データ移行間接データ移行

メリッ

ト

・ Oracle から SQL Server へ直接データを移行

できるため、間接データ移行と比較すると IO

を抑えることができる

・ TOTAL の作業時間を抑えることができる

・エクスポート、ンポートいずれかの作業を行

っているデータベースが稼働していれば作業

は行える

・外部媒体にデータを移し搬送するなど、ネット

ワークを介さないデータの移動手段がとれる

・ Oracle クラゕントを移行先サーバーにン

ストールする必要がない

デメリ

ット

・両データベースがダウンしているとデータが

移行できない

・データ量が多くなると、ネットワークに対する

負荷が高くなるため、作業時間やデータの送信

量などを調整する必要がある

・ Oracle クラゕントを移行先サーバーにン

ストールする必要がある

・エクスポート時のフゔル出力、ンポート時

のフゔルからの入力を行う分、直接データ移

行と比較すると IO が多くなる

・ TOTAL の作業時間が長くなりがち

44

5.2 直接データ移行

データを直接移行する場合は、次に記載する 4 つの方式が考えられます。

これらは要件に合わせて各移行方式を選択することになりますが、一般的には、データ移行は継続した運用

ではないことや本番環境へ一時的に設定を行うことはさせないこと、データ変換の柔軟性、開発期間と工数

などを考慮して、Integration Service パッケージ (IS パッケージ) による移行を選択することになります。

業務要件に沿った複雑なデータ変換を性能面も考慮しながら移行する場合は、高コストとなっても独自ゕプ

リケーションを作成して対応する場合があります。

1) Integration Service パッケージによる直接データ移行

2) 独自ゕプリケーションを作成する直接データ移行

3) Oracle をパブリッシャをとしたレプリケーションを利用する直接データ移行

4) リンクサーバーなど分散クエリを利用する直接データ移行

直接データ移行各方式の特徴

方式１方式２方式３方式４

データ型やデータ内

容の変換

IS パッケージのデー

タフロータスク内で

指定可能

ゕプリケーションの

作りで自由変換

フゖルタをかける際

にクエリで行える範

囲で可能

クエリ実行時にクエ

リで行える範囲で可

能

ワークフローを考慮

したデータ移行

IS パッケージ内で定

義可能

ゕプリケーションの

作りで自由に定義

不可能クエリの順番程度で

あればバッチ内で指

定可能

実行方式パッケージをジョブ

管理ツールから実行

ゕプリケーションを

ジョブ管理ツールか

ら実行

レプリケーション設

定

クエリを発行するバ

ッチを作成し、ジョブ

管理ツールから実行

エラーハンドリング IS パッケージログゕプリケーションの

作りで自由記録

レプリケーションモ

ニタのエラー

コマンドエラーをテ

キスト出力

データ移行後に発生

した差分の吸収、ま

たは連続データ移行

データの制止点やロ

ック制御の問題があ

るため困難



るため困難

連続して差分データ

を転送できるため容

易



るため困難

移行時のサービス停

止

データの差分を発生

させないために必要

データの差分を発生


不要データの差分を発生


設定の追加

不要不要レプリケーション設

定を作成、移行後は削

除

リンクを設定、移行後

は削除

開発の容易さ、工数 IS パッケージの開発

となるため、多少の期

間と工数が必要とな

る

専用ツールの開発と

なるため、それなりの

期間と工数が必要と

なる

設定のみとなるため、

容易でかつ少ない工

数で実装可能

クエリ実行用のバッ

チを作成するため、容

易でかつ少ない工数

で実装可能

45

5.3 間接データ移行

間接データ移行はエクスポート元とンポート先でフゔルを利用した以下の流れで作業を行います。

データ移行を行う際に、移行先サーバーに追加の Oracle クラゕントソフトをンストールできないなど

の要件がある場合、フゔルの代わりに一時的に両ソフトが入った移行用サーバーを立てることを検討する

場合がありますが、この方法は直接データ移行、間接データ移行、両移行方式のデメリットが発生する上に

追加サーバーを用意するコストが発生するため、推奨しません。

① PL/SQL や exp コマンド、サードベンダー殿ツール、Integration Service などを使用し、データを

フゔルへエクスポート

② テキストフゔル、EXCEL、Access などエクスポートされたフゔルを移行元サーバーから移行先サ

ーバーへコピー、必要に応じてデータ変換

③ BCP/BulkInsert/Integration Service などを使用し、フゔルからデータをンポート

5.4 Integration Service による直接データ移行

SQL Server に付属の Integration Service を利用することで、Oracle に直接接続を行い、クエリを発行し

てデータを取得することができます。また、Integration Service ではデータフローを定義することで、デ

ータ移行に伴うデータの変換も同時に行い、変換されたデータを直接 SQL Server に投入することも可能で

す。

5.4.1 パッケージの作成

① Oracle への接続

Integration Service で Oracle に接続するには、移行先のサーバーに Oracle クラゕントをンストー

ルし、「ネテゖブ OLE DB」に含まれる「Oracle Provider for OLE DB」または「Microsoft OLE DB Provider

for Oracle」プロバダを利用します。プロバダについては、接続する Oracle のバージョンや移行先とな

る SQL Server のエデゖション (x86/x64/IA64) によりサポート範囲が異なりますので、各環境でサポー

トされているバージョンを確認したうえで選択します。なお、「Microsoft OLE DB Provider for Oracle」に

は 64bit 版は存在しません。

「OLE DB ソース」コンポーネントで Oracle に接続するには、事前にローカルネットサービス名の設定を

行っておく必要があります。ローカルネットサービス名で設定したホスト名を「サーバー名」欄に入力しま

す。

46

図 5.4.1-① Oracle への接続設定例

SQL Server でテスト済みの OLE DB プロバダ

http://msdn.microsoft.com/ja-jp/library/ms187072.aspx

② SQL Server への接続

出力先として SQL Server を指定する際は、「ネテゖブ OLE DB」に含まれる「SQL Server Native Client」

プロバダを指定します。

図 5.4.1-② SQL Server への接続設定例

「ネテゖブ OLE DB\Oracle

Provider for OLE DB」を選択

ローカルネットサービス名で設定した

名前を指定

移行する全てのデータが参照可能なユ

ーザー名とパスワードを利用

「ネテゖブ OLE DB\SQL Server

Native Client 10.0」を選択

・サーバー名\ンスタンス名を指定

・別名を設定している場合は、設定可能

・通常は移行先サーバーでパッケージを

実行させるため、ローカルサーバーのン

スタンスを指定することになる

・通常は Windows 認証を利用して管

理者権限を持つユーザーで実行させる

・ SQL 認証を利用している場合は、パ

ッケージを本番環境にコピーした際に

パスワードを再設定する移行先のユーザーデータベースを指定

http://msdn.microsoft.com/ja-jp/library/ms187072.aspx

47

③ 単純移行

データを移行するテーブル構造が Oracle と SQL Server で同じ場合は、データソースと変換先を直接つな

ぐことで、相互のテーブル間で単純にデータを移行することが可能です。この場合は、テーブルごとに「OLE

DB ソース」コンポーネントを作成し、対になる「OLE DB 変換先」を指定し、直接接続を繋げ、項目を合

わせます。

この方法を使用する場合は、項目の順番変更や項目を削るなど、クエリで指定できる変更程度であればデー

タ変換が可能となります。

図 5.4.1-③ データの単純変換例

④ データ変換を伴う移行

Oracle と SQL Server のテーブルに構造的な違いがある場合、データ型やデータ内容に変換の必要がある

場合、データフロータスク内の変換コンポーネントを利用することで、データ変換が行えます。また、「スク

リプトコンポーネント」を利用することで、定義されている変換以外の変換も可能となります。

図 5.4.1-④ データフローで利用できる各種変換コンポーネント

48

⑤ インポート・エクスポートウィザード

Management Studio のンポート・エクスポートウゖザードを使用することでも、データ移行用の IS パ

ッケージを作成することも可能です。

ンポート・エクスポートウゖザードを使用すると、SQL Server にテーブルが作成されていない場合、デ

ータ移行前にテーブルを作成します。ただし、このテーブル定義は、SQL Server に適したデータ型で定義

されていないことや、データ変換が正常に行われないケースではエラーが発生することがあるので、極力テ

ーブルを事前に作成し、データのみ移動するようにします。

図 5.4.1-⑤ ンポート・エクスポートウゖザードで作成されたパッケージ例

5.4.2 データ移行時の注意点

Oracle から SQL Server へデータを移行する際の代表的な注意点を次に示します。

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

ータ移行前には環境に合わせて文字化けする文字を洗い出しておきます。

Oracle の NUMBER 型は桁を指定しないでテーブルを作成することができます。このようなデータ型

があると移行先の SQL Server のテーブルでデータ型が定義できません。事前にデータ内容を洗い出

し、全てのデータが問題なく収まるよう適切なデータ型を指定するようにします。

Oracle の NUMBER 型を SQL Server にそのまま変換しようとすると、Decimal 型を指定する必要

があります。しかし、数値データを Decimal 型で全て定義すると、データサズや性能面で好ましく

ない結果を生みます。数値データのデータタプは SQL Server 側で見直しておく必要があります。

データベースオプションの違いに注意します。NULL の扱いは特に Oracle と SQL Server でソート

結果の違いや比較の違いとして現れてきます。

親子の関連付けがあるテーブルは、親から子と言った順でデータを投入します。物理的に外部制約を設

定する必要がある場合は、データ移行後全てのチェックが終了した後に設定することを検討します。

トランザクションログの排出量、バックゕップ、バッチサズのバランスが崩れるとトランザクション

ログフゔルの使用率がフルとなり、処理がエラーとなります。エラー時や再実行、性能などを考慮し

て、データ移行中はリカバリモデルを「シンプル」や「一括ログ」に変更することを検討しておきます。

複数テーブルへのデータ移行を並行して実行する場合は、CPU 負荷やログの排出量が想定以上になら

49

ないよう注意します。

データ移行の性能を考慮して、ンデックスを残したまま移行するか、一度削除してから移行し、デー

タが全て投入できた段階で再度ンデックスを作成するかを検討します。なお、ンデックスを残して

データを移行した場合は、データ移行後にンデックスの再構築または再構成と統計情報の更新を忘れ

ずに行います。

IS パッケージでデータ変換を行う場合は、作りにより性能が大きく異なります。ワークフローやデー

タ変換が複雑になるとその分処理が遅くなりますので、極力シンプルなデータ移行となるようパッケー

ジを作成します。

IS パッケージは SQL Server 側のデータベースサーバーで実行します。IS パッケージの実行を第三

のサーバーで行えるよう、第三のサーバーに Integration Service をンストールすると、追加ラ

センスが必要となります。また、第三のサーバーで Integration Service を実行すると、データは移

行元から第三のサーバーを経由して移行先へ流れるため、不要な IO を発生させることとなります。

UNIQUE 制約、一意キーの列に複数の NULL データを格納することはできません。(Oracle では可能)

NULL データが複数ある場合は、制約の解除や、NULL 値に対する一意性のある値の設定などを検討

する必要があります。

Oracle では空文字列と NULL を同じ値として扱います。IS NULL の結果に差異が出るなどの影響が

ありますので、NULL を意識する必要がある移行には注意が必要です。

以上

oracle 2 sql server 移行ガイド データベースオブ...

Documents

oracle 2 sql server 移行ガイドデータベースオブ...