2 - サーバー コンポーネントの移行

Oracle 2 SQL Server 移行ガイド
2 - サーバー コンポーネントの移行
目次
1. 本ガイドの目的と前提条件 ....................................................................... 5
2. セキュリティ オブジェクト ...................................................................... 6
2.1 認証設定の移行 .......................................................................................................... 6
2.1.1 Oracle の認証設定 ........................................................................................... 6
2.1.2 SQL Server の認証設定 .................................................................................... 7
2.2 アクセス権限設定の移行 ............................................................................................... 8
2.2.1 Oracle のアクセス権限設定 ............................................................................... 8
2.2.2 SQL Server のアクセス権限設定 .......................................................................10
2.3 ネットワークポートの移行 ...........................................................................................12
2.3.1 Oracle のネットワークポート設定 ......................................................................12
2.3.2 SQL Server のネットワークポート設定 ...............................................................12
2.4 暗号化設定の移行 ......................................................................................................13
2.4.1 Oracle の暗号化設定 .......................................................................................13
2.4.2 SQL Server の暗号化設定 .................................................................................14
2.4.3 暗号化移行の注意点 ........................................................................................16
3. サーバー構成オプション ........................................................................ 17
3.1 初期化パラメータの移行 ..............................................................................................17
3.1.1 Oracle の初期化パラメータ設定.........................................................................17
3.1.2 SQL Server の初期化パラメータ設定 ..................................................................19
4. ストレージ オブジェクト ...................................................................... 22
4.1 ファイル構成 ............................................................................................................22
4.1.1 Oracle のファイル構成 ....................................................................................22
4.1.2 SQL Server ファイル構成 ................................................................................23
4.2 読取り専用表領域の移行 ..............................................................................................25
4.2.1 Oracle の読取り専用表領域 ..............................................................................25
4.2.2 SQL Server の読取専用ファイルグループ ............................................................25
4.3 自動拡張設定の移行....................................................................................................26
4.3.1 Oracle の自動拡張設定 ....................................................................................26
4.3.2 SQL Server の自動拡張設定 .............................................................................26
5. 文字コードと並べ替え ........................................................................... 27
5.1 文字コードと並べ替えの移行 ........................................................................................27
5.1.1 Oracle の文字コードと並べ替え.........................................................................27
2
5.1.2 SQL Server の文字コードと並べ替え ..................................................................27
6. データベース リンク ............................................................................ 29
6.1 データベース リンクの移行 .........................................................................................29
6.1.1 Oracle のデータベースリンク ...........................................................................29
6.1.2 SQL Server のリンク サーバー .........................................................................30
7. 監査.................................................................................................. 32
7.1 監査方法の移行 .........................................................................................................32
7.1.1 Oracle の監査方法 ..........................................................................................32
7.1.2 SQL Server の監査方法 ...................................................................................33
7.2 監査データの配置場所の移行 ........................................................................................38
7.2.1 Oracle の監査データの配置場所.........................................................................38
7.2.2 SQL Server の監査データの配置場所 ..................................................................38
8. レプリケーション ................................................................................ 40
8.1 単一マスタ レプリケーション環境の移行 (マテリアライズド ビュー レプリケーション) ...........40
8.1.1 Oracle の単一マスタ レプリケーション ..............................................................40
8.1.2 SQL Server のトランザクションレプリケーション ................................................40
8.2 マルチマスター レプリケーション環境の移行 ..................................................................41
8.2.1 Oracle のマルチマスター レプリケーション .........................................................41
8.2.2 SQL Server の マージレプリケーション .............................................................42
9. 高可用性 ............................................................................................ 43
9.1 遠隔サイト リカバリー ...............................................................................................43
9.1.1 Oracle DataGuard ..........................................................................................43
9.1.2 SQL Server ログ配布とデータベース ミラーリングと AlwaysOn .............................44
10. トレース .......................................................................................... 48
10.1 トレースの移行 .......................................................................................................48
10.1.1 Oracle のトレース ........................................................................................48
10.1.2 SQL Server のトレース .................................................................................49
11. 接続方法の移行 ................................................................................. 52
11.1 接続方法の移行 .......................................................................................................52
11.1.1 Oracle の接続方法 ........................................................................................52
11.1.2 SQL Server スレッド モデルの設定 .................................................................53
3
[注意事項]
このドキュメントに記載されている情報 (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 であること及び上記の注意事項を明示しなければなりません。
4
1. 本ガイドの目的と前提条件
目的
本ガイドでは、Oracle を用いて構築されたデータベースシステムを、SQL Server 環境へ移行する際の考慮点、
特にサーバー コンポーネント移行時の考慮点についてまとめています。
前提条件
本ガイドで対象とする SQL Server 及び Oracle のバージョンは以下の通りです。
SQL Server

SQL Server 2012
Oracle


Oracle Database 10g R2
Oracle Database 11g
5
2. セキュリティ オブジェクト
2.1 認証設定の移行
2.1.1 Oracle の認証設定
Oracle の認証設定は大きく分けて OS 認証とパスワード ファイル認証の 2 つがあります。OS 認証はパス
ワード ファイル認証より優先されます。
2.1.1.1 OS 認証
OS 認証では、OS のユーザー アカウントを OSDBA と OSOPER という OS グループに追加することでデ
ータベース管理者として認証する接続方式です。OSDBA とは、UNIX は dba、Windows は ORA_DBA であ
り、OSOPER は UNIX 系は oper、Windows は ORA_OPER というグループ名になります。
認証情報は OS 側で管理されており、OS から認証を受けたユーザーはユーザー名やパスワードを指定せず
に Oracle にログインすることができるようになります。
OS 認証を使用する場合、初期化パラメータ REMOTE_LOGIN_PASSWORDFILE を NONE に設定します。
2.1.1.2 パスワード ファイル認証
パスワード ファイル認証では、パスワードファイルを使用してユーザーを認証します。パスワード ファイ
ルは Password File Utility を使用して作成します。パスワード ファイルの作成コマンドは以下になります。
ORAPWD FILE = <パスワードファイル名> ENTRIES=<最大ユーザーアカウント数>;
パスワードファイル認証を使用する場合、初期化パラメータ REMOTE_LOGIN_PASSWORDFILE を EXCLUSIVE
に設定します。また、REMOTE_LOGIN_PASSWORDFILE を SHARED にすることで複数のインスタンスでパス
ワード ファイルを共有することができます。
6
2.1.2 SQL Server の認証設定
SQL Server の認証設定は、Windows 認証モードと混合認証モードの 2 通りから選択します。Windows 認証
モードでは Windows ログインによる認証が可能です。また混合認証モードでは、Windows ログインによる
認証と SQL Server ログインによる認証の両方が可能です。認証設定は SQL Server のセットアップ時(イン
ストール時)に「認証モード」画面で選択します。セットアップ後に認証モードを変更するには、SQL Server
Management Studio のオブジェクト エクスプローラからサーバーのプロパティによって変更することがで
きます。
2.1.2.1 Windows 認証モード
Windows ログインを使用した認証のみ可能なモードです。セットアップ時において、管理者権限 (sysadmin
サーバーロール) を持つ Windows ログインを登録します。
Windows ログインはローカル コンピュータもしくは SQL Server が属する Active Directory 内に定義され
ます。これらのログインは SQL Server によって管理されず、Windows が提供する SID (Security Identifier)
によって一意に識別されます。
Windows ログインは次の DDL によって SQL Server インスタンスに登録されます。
CREATE LOGIN [<ドメイン名>¥<アカウント名>] FROM WINDOWS WITH
DEFAULT_DATABASE = <データベース名>
Windows ローカルログインの場合はドメイン名がローカル マシン名になります。
SQL Server に登録された Windows ログインは次のクエリで照会することができます。
SELECT * FROM master.sys.server_principals WHERE TYPE = 'U'
2.1.2.2 混合認証モード
Windows ログインによる認証と SQL Server ログインによる認証の両方が可能です。セットアップ時におい
て、管理者権限 (sysadmin サーバーロール) を持つ Windows ログイン、および SQL Server ログインで管
理者権限 (sysadmin サーバーロール) をもつ sa のパスワードを登録します。
SQL ログインは、特定の SQL Server インスタンス上でのみ意味があるセキュリティ プリンシパルです。
Windows ログインと同様に SID によって一意に識別されますが、ここでの SID は Windows の SID と異
なり SQL Server インスタンスが生成した 16 バイト GUID になります。
SQL ログインは次の DDL によって登録されます。
CREATE LOGIN SQL ログイン名 WITH password = '<パスワード>',
DEFAULT_DATABASE = <データベース名>
7
SQL Server に登録された SQL ログインは次のクエリで照会することができます。
SELECT * FROM
master.sys.server_principals WHERE TYPE = 'S'
2.2 アクセス権限設定の移行
2.2.1 Oracle のアクセス権限設定
Oracle のアクセス権限は、システム権限とオブジェクト権限の 2 種類があります。
システム権限はデータベース システムに対する操作を制御する為の権限で、オブジェクト権限は、オブジェ
クトへのアクセスを制御する権限です。
以下、代表的なシステム権限になります。
システム権限
説明
ALTER SESSION
セッションの変更
CREATE DATABASE LINK
データベースリンクの作成
CREATE PROCEDURE
ストアド・プロシージャの作成
CREATE SEQUENCE
シーケンス オブジェクトの作成
CREATE SESSION
インスタンスに対する接続
CREATE SYNONYM
シノニムの作成
CREATE TABLE
テーブルの作成
CREATE TRIGGER
トリガーの作成
CREATE USER
クラスタの作成
CREATE VIEW
ビューの作成
UNLIMITED TABLESPACE
無制限に表領域を使用可能
SELECT ANY TABLE
全てのテーブルの検索許可
SYSDBA
データベースの起動・停止、バックアップ・リカバリなどの管理捜査を実行
データベースがオープンしてない時にアクセス可能
SYSOPER
データベースの起動・停止、基本的なリカバリなど。データベースの作成は
不可。
システム権限の詳細は Oracle のマニュアル「Oracle Database SQL リファレンス」をご参照ください。
※Oracle には多くの権限が定義されており、ユーザーごとの権限管理が難しい為、権限をまとめたロールを
作成し、ユーザーに付与することが多く、Oracle で定義されたロールを使用することが多くあります。
8
ロール
説明
SESSION
以下のシステム権限が付与されています。
CREATE SESSION
RESOURCE
以下のシステム権限が付与されています。
CREATE CLUSTER
CREATE INDEXTYPE
CREATE OPERATOR
CREATE PROCEDURE
CREATE SEQUENCE
CREATE TABLE
CREATE TRIGGER
CREATE TYPE
DBA
全てのシステム権限
また、主なオブジェクト権限の種類は以下になります。
オブジェクト権限
説明
ALTER
表や順序を変更する権限
DELETE
表のデータを削除する権限
EXECUTE
プロシージャやパッケージを実行する
INDEX
表に索引を作成する権限
INSERT
表にデータを挿入する権限
REFERENCES
参照整合性制約を作成する権限
SELECT
表やビューを検索する権限
UPDATE
表のデータを更新する権限
9
2.2.2 SQL Server のアクセス権限設定
SQL Server のアクセス権限は、ログインとデータベース ユーザーの 2 種類のセキュリティプリンシパルに
対して設定します。ログインにはサーバー レベルの権限を、データベース ユーザーにはデータベース レベ
ルの権限を設定します。
ログインとユーザー
2.2.2.1 サーバー レベルの権限
サーバーに関連した権限としてビルトインの固定サーバーロールが 9 個用意されており、必要に応じてこれ
らの固定サーバーロールをログインへ与えます。ログインには既定で Public サーバーロールが与えられます。
固定サーバーロール
固定サーバーロール
説明
sysadmin
サーバーに対するすべての操作を実行できる。
serveradmin
サーバー全体の構成オプションの変更や、サーバーのシャットダウンをする。
setupadmin
リンクサーバーを追加および削除できる。
ログインとログインのプロパティを管理する。このメンバは、サーバーレベルの
securityadmin
権限を許可、拒否、および禁止できる。また、データベース レベルの権限も許可、
拒否、および禁止できる。また、SQL Server ログインのパスワードをリセットで
きる。
processadmin
SQL Server のインスタンス内で実行中のプロセスを終了できる。
dbcreator
任意のデータベースを作成、変更、削除、および復元できる。
diskadmin
ディスクファイルを管理する。
bulkadmin
BULK INSERT ステートメントを実行できる。
public
サーバーに接続できるが、サーバーレベルの操作に対する権限はない。
10
例えば、ログインに sysadmin サーバーロールを与えるには、次の T-SQL コマンドを実行します。
sp_addsrvrolemember <ログイン名>,sysadmin
GO
2.2.2.2 データベースレベルの権限
データベースに関連した権限としてビルトインの固定データベースロールが 10 個用意されており、必要に
応じてこれらの固定データベースロールをユーザーへ与えます。ユーザーには既定で Public データベース
ロールが与えられます。
固定データベースロール
固定データベースロール
説
明
db_owner
データベースでのすべての構成作業とメンテナンス作業を実行でき、データベース
を削除することもできる。
db_accessadmin
Windows のユーザ、グループ、および SQL Server ログインへのアクセス権の追加
または削除を行う。
db_datareader
全てのユーザテーブルから全データを読み出す。
db_datawriter
全てのユーザテーブルのデータの追加、削除、および変更を行う。
db_ddladmin
データベース内のあらゆるデータ定義言語(DDL)コマンドを実行する。
db_securityadmin
ロールのメンバシップを変更し、権限を管理できる。このロールにプリンシパルを
追加すると、特権が意図せず昇格されることがある。
db_backupoperator
データベースをバックアップする。
db_denydatareader
データベース内のユーザ テーブルにある全てのデータの読み取りを拒否する。
db_denydatawriter
全てのユーザテーブルまたはビュー内にあるデータの追加、変更、および削除を拒
否する。
Public
データベースに接続できるが、データベースオブジェクトへのアクセス権限はない
例えばユーザーに対して db_datareader 権限と db_datawriter 権限を与えるには、次の T-SQL コマンド を
実行します。
USE <データベース名>
GO
sp_addrolemember db_datareader, <データベースユーザ名>
GO
11
sp_addrolemember db_datawriter, <データベースユーザ名>
GO
Oracle のオブジェクト権限に対応する権限を個別に制御することができます。
詳しくは「GRANT (オブジェクトの権限の許可) (Transact-SQL)」を参照してください。
2.3 ネットワークポートの移行
2.3.1 Oracle のネットワークポート設定
Oracle は、クライアントと Oracle 間の通信を Oracle Net とリスナーというコンポーネントを使用して接
続を確立します。
Oracle Net は、クライアントとサーバー両方に必要で主な役割はクライアントと Oracle 間のデータ転送や
OS やプロトコルの差異を吸収することです。
リスナーは、クライアントからの接続要求をサーバー側で待機するコンポーネントで、常に特定のポートを
監視して、クライアントから接続要求が来たらクライアントとサーバープロセス (ディスパッチャ プロセス)
間の接続を確立します。リスナーを使用した接続手順は以下になります。
2.3.2 SQL Server のネットワークポート設定
クライアントまたはアプリケーションが SQL Server へアクセスするために、既定のインスタンス (デフォル
トインスタンス) に対する接続では TCP 1433 が使用されます。このポート番号 1433 は設定により変更す
ることができます。また名前つきインスタンスに接続するためのポート番号は、既定で動的に決定されます。
この動的ポート番号は、設定により静的 (固定) に変更することができます。
動的ポート番号では、ログインのための情報を取得するため、クライアント ライブラリーはデータベースサ
ーバーの UDP 1434 に対しリクエストパケットを送信します。UDP 1434 では SQL Browser と呼ばれるリ
スナー サービスが待機しており、クライアントがアクセスしたいインスタンスのポート番号を返します。
12
動的ポートに対するアクセス
2.4 暗号化設定の移行
2.4.1 Oracle の暗号化設定
Oracle の暗号化には以下があります。
１．暗号化ツールキット (カラムレベルの暗号化)
２．TDE (透過的なデータの暗号化)
2.4.1.1 暗号化ツールキット (カラムレベル暗号化)
DBMS_OBFUSCATION_TOOLKIT や DBMS_CRYPTO パッケージを使用することでカラム レベルで暗号化す
ることができます。これらのパッケージを使用する場合、データ挿入時に暗号化してデータ参照時に複合化
するなどアプリケーション側で対応する必要があります。
2.4.1.1.1
DBMS_OBFUSCATION_TOOLKIT
DBMS_OBFUSCATION_TOOLKIT では、DES や 3DES、MD5 などの暗号化が可能で、VARCHAR2 と RAW 型
の項目に対して暗号化することができます。
2.4.1.1.2
DBMS_CRYPTO (Oracle10g 以降)
DBMS_CRYPTO では、AES や RC4、MD4 や SHA-1 などの方式が利用可能です。暗号化可能なデータ型は
RAW 型や CLOB 型、BLOB 型で VARCHAR2 型は含まれていません。この為、VARCHAR2 型を暗号化する
場合、UTL_RAW パッケージを使用します。
2.4.1.2 TDE (透過的なデータの暗号化)
Oracle10gR2 から採用された TDE はアプリケーションの改修をせずに特定の列に対する暗号化を行うこと
ができます。特定の列に対してのみ暗号化を行う為、暗号化を使用した時のパフォーマンス劣化を最小限に
抑えることができます。
13
テーブル作成時に TDE を作成する方法は以下になります。
CREATE TABLE <テーブル名>( <カラム名> <データ型> ENCRYPT USING <アルゴリズム> );
2.4.1.3 表領域の暗号化
Oracle11g から表領域単位で暗号化することができます。
CREATE TABLESPACE <表領域名> DATAFILE <データファイル名> SIZE <サイズ> ENCRYPTION
USING <アルゴリズム> DEFAULT STORAGE(ENCRYPT);
2.4.2 SQL Server の暗号化設定
SQL Server の暗号化には次の 2 種類があります。
1) カラムレベル暗号化
2) 透過的データ暗号化
カラムレベル暗号化はテーブルのカラムレベルで暗号化を行います。透過的データ暗号化ではデータベース
レベルで暗号化が行われます。
2.4.2.1 カラムレベル暗号化
カラムレベル暗号化では、次の T-SQL 関数を用いてデータの暗号化と復号化を実行します。
テーブル上でデータが自動的に暗号化されるわけではありません。したがってテーブルに対して直接 INSERT,
UPDATE を行うと暗号化されていないデータが書き込まれます。
暗号化に用いる T-SQL 関数
復号化に用いる T-SQL 関数
説明
ENCRYPTBYKEY
DECRYPTBYKEY
対称キーによる暗号化と復号化
DES、TRIPLE_DES、TRIPLE_DES_3KEY、RC2、RC4、
RC4_128、DESX、AES_128、AES_192、AES_256
ENCRYPTBYCERT
DECRYPTBYCERT
証明書による暗号化と復号化
ENCRYPTBYASYMKEY
DECRYPTBYASYMKEY
非対称キーによる暗号化と復号化
RSA_512、RSA_1024、RSA_2048
ENCRYPTBYPASSPHRASE
DECRYPTBYPASSPHRASE
パスワードによる暗号化と復号化
暗号化可能なデータ型は char、varchar、nchar、nvarchar の文字列型です。また暗号化されたデータは
varbinary (最大 8,000 バイト) になります。
パフォーマンスの観点から対称キーによる暗号化／復号化を利用します。また一度に暗号化するカラム数が
少ないほどパフォーマンスへの影響が小さくなります。
データを暗号化してインサートするステートメントの例は次の通りです。この例では、あらかじめ定義され
14
た対称化キー ProwerKey によって文字列「テスト」が暗号化されます。
INSERT INTO t1 VALUES(1, encryptByKey(Key_GUID('PowerKey'),'テスト'),'ABC')
2.4.2.2 透過的データ暗号化 (TDE)
透過的データ暗号化では、アプリケーションの変更なしにデータベース全体を暗号化します。
データベースそのものを暗号化するため、証明書がないとデータベースをリストアすることができません。
データベースの復元(あるいはアタッチ)には証明書が必要となるので、バックアップファイルのみが流出して
も不正にリストアされてしまうことがありません。データベースを暗号化したままの状態でバックアップ リ
ストアができます。
透過的データ暗号化では、データべースの読取権限のあるユーザーは、パスワードや暗号化キーの情報を知
らなくてもデータベース内のレコードを参照することができます。透過的データ暗号化を有効にすることで
tempdb も暗号化されます。
透過的データ暗号化を有効にするには、次の手順に従ってデータベースを暗号化します。
1) データベース マスターキーを作成する
USE master
GO
CREATE MASTER KEY
ENCRYPTION BY PASSWORD = '<パスワード>'
GO
2) 証明書を作成する
USE master
GO
CREATE CERTIFICATE
<証明書名> WITH SUBJECT = '<subject>'
GO
3) データベース暗号化キーを作成する
USE <データベース名>
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE <証明署名>
GO
15
暗号化には次のアルゴリズムを利用することができます。
AES_128, AES_192, AES_256, TRIPLE_DES_3KEY
4) データベースを暗号化する
USE master
GO
ALTER DATABASE <データベース名> SET ENCRYPTION ON
GO
5) データ暗号化の状態を確認するには、次の DMV クエリーを実行します。
SELECT DB_NAME(database_id), encryption_state,
percent_complete
FROM sys.dm_database_encryption_keys
2.4.3 暗号化移行の注意点
カラムレベル暗号化において、SQL Server では文字列型の列が暗号化の対象となることに注意してください。
16
3. サーバー構成オプション
3.1 初期化パラメータの移行
3.1.1 Oracle の初期化パラメータ設定
3.1.1.1 Oracle の初期化オプションパラメータ
Oracle では、環境にあった状態にする為、インストール時に初期化パラメータの値を変更します。特に以下
パラメータについては各環境毎に設定することが多く、SQL Server でも同等の設定を引き継ぐ際は考慮が必
要と言えます。
初期化パラメータ
意味
PROCESSES
PROCESSES は Oracle に同時に接続できる OS のユーザー・プロセ
スの最大数を指定する。このパラメータの値には、すべてのバックグ
ラウンド・プロセスを考慮して設定する必要がある。
SESSIONS
SESSIONS はシステムに作成できるセッションの最大数を指定する。
このパラメータの値には、同時ユーザーの推定最大値に、バックグラ
ウンド・プロセスの数を加え、さらに再帰セッションの約 10% を加
えた値を明示的に設定しておく必要がある。
TRANSACTIONS
TRANSACTIONS は同時トランザクションの最大数を指定する。デフ
ォルト値は SESSIONS に 1.1 倍した値が格納される。
SGA_MAX _SIZE(Oracle10g 以降)
SGA_MAX_SIZE は SGA の最大サイズを指定する。SGA のサイズは物
理メモリの 2/3 が推奨されている。
SGA_TARGET(Oracle10g 以降)
SGA_TARGET は以下 SGA コンポーネントの合計サイズを指定する。
デフォルトでは 0 (使用しない)。
・バッファ・キャッシュ(DB_CACHE_SIZE)
・共有プール(SHARED_POOL_SIZE)
・ラージ・プール(LARGE_POOL_SIZE)
・Java プール(JAVA_POOL_SIZE)
・Streams プール(STREAMS_POOL_SIZE)
PGA_AGGREGATE_TARGET(Oracle9i 以降)
PGA_AGGREGATE_TARGET はサーバー・プロセス毎に使用する PGA
メモリの合計サイズを指定する。PGA は SQL の情報やソート デー
タなどを格納する領域で、サイズは 10MB、または SGA サイズの 20%
のいずれか大きい方がデフォルトとして設定されている。
LOCK_SGA
LOCK_SGA は SGA 全体を物理メモリ内にロックする場合に指定す
る。デフォルトは FALSE。
17
UNDO_RETENTION(Oracle9i 以降)
UNDO_RETENTION は UNDO データの最低保存時間(秒) を指定す
る。処理時間の長い SQL が実行される環境では最大処理時間より大
きめの値をセットする。
CURSOR_SHARING
CURSOR_SHARING は同じカーソルを共有する場合に指定する。デフ
ォルトは EXACT。
FORCE：リテラル値が異なっても、その他が同じ SQL 文であればカ
ーソルが共有される。
SIMILAR：リテラル値が異なっても、その他が同じ SQL 文であれば(実
行計画は除く)カーソルが共有される。
EXACT：同一の場合のみカーソルが共有される。
OPTIMIZER_DYNAMIC_SAMPLING(Oracle9i
以降)
OPTIMIZER_DYNAMIC_SAMPLING は SQL 実行時にオプティマイザ
が動的に統計情報を取得するかどうかを設定する。サンプリングレベ
ルは 0 から 10 まで設定可能だが、基本的には 0 から 2 の間で設
定することが多い。
0：動的サンプリングしない。
1：以下の条件に該当する表を動的にサンプリングする。
・分析されていない表が問合せに少なくとも 1 つある
・この分析されていない表が、別の表と結合、または副問合せかマー
ジ不可能ビューにある
・この分析されていない表に索引がない
・この分析されていない表に、動的サンプリングでサンプリングする
(予定)のブロックの数よりも多いブロックがある
2：全ての分析されていない表をサンプリングする。
18
3.1.2 SQL Server の初期化パラメータ設定
3.1.2.1 SQL Server のサーバー構成オプション パラメータ
SQL Server は自律チューニングを基本としているため、多くのパラメータは既定の設定を変更しませんが、
次のパラメータ設定は変更を検討してください。
サーバー構成オプション
サーバーオプション
意味
max server memory
バッファープールが使用するメモリ最大値を指定する。
設定値＝[搭載物理メモリ]－[max worker threads]×[スレッドスタックサイズ]－
[OS とアプリケーションが使用する物理メモリ量]。
ここで、スレッドスタックサイズは x86  512KB、X64  2MB、IA64 4MB。OS
とアプリケーションが使用する物理メモリ量は 2～5GB 程度確保して調整する。
min server memory
バッファープールが使用するメモリ最小値を指定する。専用データベースサーバー
では、このパラメータを既定(0)のまま利用して問題ありません。
fill factor
インデックス作成時の初期充填率の既定値を指定する。fill factor の既定値は
0(100%)であるため、更新系システムでは 70%~80% に設定する。
設定値の変更には sp_configure システムストアドプロシージャを用いるか、SQL Server Management Studio
の GUI から変更します。
次の例は sp_configure システム ストアドプロシージャによって max server memory を 11GB に設定しま
す。
EXEC sp_configure 'max server memory',
11264
3.1.2.2 SQL Server のデータベース オプション パラメータ
SQL Server は自律チューニングを基本としているため、多くのデータベース パラメータは既定の設定を変
更しませんが、次のパラメータ設定については、意味を理解して使用するか、変更を検討してください。
データベース オプション
サーバーオプション
意味
データベースファイルの自動拡
SQL Server のデータファイルとログファイルは、必要に応じて自動的に拡張す
張
る。この設定は既定で 1MB (データファイル)や 10% (ログファイル) となってい
る。拡張サイズを大きくしたり、閑散時間帯に手動で拡張する。ファイル自動拡
張時はパフォーマンスに影響を与えるので注意する。
復旧モデル
障害時に障害直前の状態まで復旧するには完全復旧モデルを使用する。既定は完
全復旧モデル。
19
データベースファイルの空き領域を自動で圧縮する。既定は FALSE (圧縮しな
自動圧縮
い)。この設定は通常変更しない。
統計情報の自動作成
コストベースオプティマイザが使用する統計情報を自動で作成する。既定は
TRUE (自動作成する)。この設定は通常変更しない。
統計情報の自動更新
コストベースオプティマイザが使用する統計情報を自動で更新する。既定は
TRUE (自動更新する)。この設定は通常変更しない。
統計情報の非同期更新
統計情報の自動更新時に、クエリーが統計情報更新中も待機しないように非同期
に行う。既定は FALSE (非同期更新しない＝クエリーは待機する)。この設定を
TRUE に変更するよう検討する。
設定の変更には ALTER DATABASE ステートメントを用いるか、SQL Server Management Studio の GUI から
変更します。
次の例は ALTER DATABASE コマンドによって統計情報の非同期更新を TRUE に設定しています。
ALTER DATABASE <データベース名> SET AUTO_UPDATE_STATISTICS_ASYNC ON
3.1.2.3 Oracle の初期設定パラメータとの対比
次の表は、Oracle で指定することが多い初期設定パラメータが、SQL Server のどの設定に対応するかについ
て比較しています。
Oracle と SQL Server のパラメータ
Oracle のパラメータ
対応する SQL Server のパラ
考慮点
メータ
PROCESSES
max worker threads
SQL Server はスレッドモデルを採用しており、SQL
Server プロセス内のスレッド数はプロセッサ数で
決められる。この値を max worker threads で変更
することができる。
SESSIONS
user connections
既定で無制限に接続できる。通常変更しない。
TRANSACTIONS
n/a
対応するパラメータはない。
CURSOR_SHARING
n/a
T-SQL の sp_executesql システムストアド プロシ
ージャ、ADO.NET の SqlParameter クラス、ODBC
の SQLBindParameter 関数などによってステート
メントがパラメター化されていれば再利用される。
OPTIMIZER_DYNAMIC_SAMP
LING
統計情報の自動作成と自動更新
LOCK_SGA
SQL Server サービスアカウント
Oracle と SQL Server の両者のパラメタ－は厳密
には意味が異なる。
20
SQL Server は左の設定でバッファープールをペー
を、Windows ローカルセキュリ
ジ固定する。
ティーポリシーの「メモリ内のペ
ージロック」ポリシーに登録する
UNDO_RETENTION
n/a
Tempdb ファイルを使いきるまで
21
4. ストレージ オブジェクト
4.1 ファイル構成
4.1.1 Oracle のファイル構成
Oracle はメモリとプロセスからなる Oracle インスタンスと、データファイルなどのデータベースから構成
されます。
データベースは、データファイル、制御ファイル、REDO ログファイルと、REDO ログファイルなどで構成
されています。
ファイル名
データファイル
説明
Oracle のデータは表領域と呼ばれる論理的領域に格納されるが、この表領域を構成してい
る物理的なファイルのことをデータファイルと呼ぶ。
制御ファイルには、データファイルや REDO ログファイルの名前や配置先やカレントのロ
制御ファイル
グ順序番号、バックアップに関する情報などデータベースの正常動作に欠かせない情報が格
納されている。
REDO ログファイル
REDO ログファイルにはリカバリ時に必要なデータベースの変更情報が格納されている。
アーカイブ ログファ
REDO ログファイルが一杯になった時に REDO ログファイルの情報をアーカイブ ログフ
イル
ァイルに格納される。
また、表領域は １ つ以上のデータファイルで構成されており、その表領域上に作成されたテーブルに実際
のデータが格納されていきます。また、表領域にはユーザーのデータを格納するユーザー用の表領域の他に、
Oracle が稼働する為に使用される情報を格納した表領域があります。それぞれの役割は以下の通りとなりま
す。
22
表領域名
説明
データベース作成時に必ず作成される表領域。この表領域にはデータディクショナリの情報や
SYSTEM 表領域
パッケージなどの情報が格納されている。SYSTEM 表領域にはデータベースを管理する為の情
報が格納される為、ユーザーが作成するオブジェクトを作成してはいけない。
SYSTEM 表領域の補助的な表領域で Enterprise Manager のリポジトリや OracleTEXT、
SYSAUX 表領域
ジョブスケジューラなどの情報を格納する領域で、SYSTEM 表領域同様データベース作成時に
必ず作成される表領域。
UNDO 表領域
TEMP 表領域
ロールバック情報を格納している表領域で、トランザクション実行時にロールバック情報が格
納される。UNDO 表領域にはユーザーが作成するオブジェクトを格納することができない。
メモリ上でソートできない場合に一時的に使用される表領域。ユーザーが作成するオブジェク
トを格納することができない。
4.1.2 SQL Server ファイル構成
4.1.2.1 SQL Server を構成するファイル
SQL Server はシステムデータベースとユーザーデータベースから構成されます。
システムデータベースは、インスタンス全体の管理情報を格納する master データベース、SQL Server Agent
ジョブを管理する msdb データベース、ユーザー データベースを作成するときのテンプレートとなる
model データベース、一時テーブルやソート領域として利用される temodb データベースから構成されま
す。各々のデータベ－スはトランザクション ログファイルを持ちます。
23
SQL Server を構成するファイル
ユーザー データベースは SQL Server 内のデータベース数の合計として 32,767 個まで作成することができ、
各々のデータベースがトランザクション ログファイルを持ちます。各々のデータベースは複数のデータファ
イルを構成することができます。
4.1.2.2 SQL Server のトランザクション ログファイル
SQL Server のデータベース ログはトランザクション ログと呼ばれ、トランザクション ログファイルは単
一の物理ファイルが循環利用されます。複数のトランザクション ログファイルを構成することは可能ですが、
冗長構成のために複数ファイルを構成することができないため、通常 1 つしか割り振りません。
4.1.2.3 SQL Server のファイルグループ
ファイルグループはデータベース ファイルをグループ化する論理オブジェクトです。ひとつのユーザー デ
ータベースに複数のファイルグループを定義することができ、ひとつのファイルグループに複数のデータベ
ース ファイルを定義することができます。
ユーザー データベースを作成すると、プライマリー ファイルグループと呼ばれる既定のファイルグループ
が一つ作成されます。通常、ファイルグループはプライマリー ファイルグループのみで問題ありませんが、
読取専用ファイルグループや、ファイルグループ単位のバックアップ リストアといった運用上の要件によっ
て、追加のファイルグループを作成します。
24
ファイルグループ
4.2 読取り専用表領域の移行
4.2.1 Oracle の読取り専用表領域
Oracle は表領域を読取専用に変更することができます。読取り専用表領域は静的なファイルとしてバックア
ップ対象から外したい場合や CD-ROM のようなメディアに保存しておく場合などに使用されます。
読取り専用表領域に変更するには以下を実行します。
ALTER TABLESPACE <表領域名> READ_ONLY
表領域が読取専用かどうかを確認するには、次のステートメントを実行します。
SELECT tablespace_name,status FROM dba_tablespaces WHERE tablespace_name='<
表領域名>'
4.2.2 SQL Server の読取専用ファイルグループ
SQL Server はデータベース レベルで読取専用にすることができます。
ALTER DATABASE <データベース名> SET READ_ONLY
データベースが読取専用かどうかを確認するには、次のステートメントを実行します。
SELECT database_id,name,is_read_only FROM sys.databases WHERE name=N'<デー
タベース名>'
またファイルグループ レベルでも読取専用にすることができます。
ファイルグループ単位に読取専用に設定するには、次の ALTER DATABASE コマンドを使用します。
25
ALTER DATABASE <データベース名> MODIFY FILEGROUP <ファイルグループ名> READ_ONLY
ファイルグループが読取専用であることを確認するには、次のステートメントを実行します。
SELECT file_id,name,is_read_only FROM sys.database_files
4.3 自動拡張設定の移行
4.3.1 Oracle の自動拡張設定
Oracle では表領域が不足した際に領域を自動拡張するように設定することができます。デフォルトでは自動
拡張しない設定になっており、最大値に達した場合エラーになります。
自動拡張の表領域を作成する場合、AUTOEXTEND を ON に指定します。また、拡張時のサイズは NEXT に
設定し、最大値は MAXSIZE に設定できます。
CREATE TABLESPACE <表領域名> DATAFILE <データファイル名> SIZE <サイズ> AUTOEXTEND
ON NEXT <サイズ> MAXSIZE UNLIMITED;
また、REDO ログファイルや制御ファイルなどのファイルは拡張することはありませんが、アーカイブ ログ
モードの場合、REDO ログファイルが LOG SWITCH した際にアーカイブ ログファイルが作成される為、ア
ーカイブ ログファイルが作成され続けて領域不足にならないようメンテナンスする必要があります。
4.3.2 SQL Server の自動拡張設定
SQL Server のデータベース ファイルおよびトランザクション ログファイルは、既定で自動拡張されます。
既定の拡張サイズは、データベース ファイルが 1MB、トランザクション ログファイルが 10% です。
仮に自動拡張が発生したとしても頻繁に拡張動作が起きないよう、200MB などの値に変更するようにします。
データファイルの拡張は、ローカル セキュリティー ポリシーのユーザー権利「ボリューム保守タスクを実
行」ポリシーへ SQL Server サービス アカウントを登録することで、ファイル拡張に要する時間をゼロにす
ることができます。
トランザクション ログファイルの拡張に対しては、このような回避策がないため、拡張が発生しないように
トランザクション ログバックアップの実行間隔を調整します。
26
5. 文字コードと並べ替え
5.1 文字コードと並べ替えの移行
5.1.1 Oracle の文字コードと並べ替え
Oracle はデータベース内で保持する文字コードをキャラクタセットに指定します。このキャラクタセットは
データベース作成時に指定し、その後で変更することはできません。
また、クライアント側では、NLS_LANG という環境変数を指定することでキャラクタセットで定義した文字
コードを別の文字コードに変換することができます。
日本語環境で使用されることが多い文字コードは以下となります。
SJIS (JA16SJISTILDE)
EUC (JA16EUCTILDE)
UTF8 (AL32UTF8)
Windows 及び SQL Server 環境では通常 SJIS が使用されている為、SQL Server へのデータ移行時には
NLS_LANG を SJIS に指定してデータを出力することで文字化けの問題を回避することができます。
5.1.1.1 Oracle の言語データのソート
Oracle の言語データのソート順は、NLS_SORT パラメータで指定します。
・バイナリでソート (デフォルト) する場合
BINARY
・大文字小文字、全角半角、ひらがなカタカナの区別をしないソートにする場合
ソート名の末尾に ’_CI’
・アクセントを区別しないソートにする場合
ソート名の末尾に ’_AI’
5.1.2 SQL Server の文字コードと並べ替え
5.1.2.1 SQL Server の文字コード
SQL Server は Unicode として UCS-2 エンコードを用いています。BULK INSERT や bcp ユーティリティー
を用いて SQL Server へ UTF-8 テキストを送信すると、SQL Server で UCS-2 に暗黙的に変換しますが、文
字化けを起こすことがあります。事前にアプリケーションで変換しておくようにします。
参考技術情報 “Description of storing UTF-8 data in SQL Server”
27
5.1.2.2 SQL Server の並べ替え
SQL Server の並べ替え規則は照合順序と呼ばれます。照合順序については「01 データベースオブジェクト」
を参照してください。
28
6. データベース リンク
6.1 データベース リンクの移行
6.1.1 Oracle のデータベースリンク
データベース・リンクは、ある Oracle から別の Oracle を透過的に参照することができる機能です。データ
ベース・リンクは一方向であり、例えば A に B を参照するデータベース・リンクを作成した場合、A から
B のデータを参照することは可能ですが、B から A のデータを参照することはできません。
接続先のOracle
(DBSVR01)
参照先のOracle
(DBSVR02)
データベース・リンク
（一方向）
SELECT *
FROM EMP@DBSVR02
データベース・リンクを使用することで、別環境への SELECT、INSERT、UPDATE を実行することができま
す。また、データベース・リンクはプライベート、パブリック、グローバルの 3 種類があり、それぞれ以下
のような特徴があります。

プライベート：データベース・リンクの所有者がアクセスすることができる

パブリック：全てのユーザーがアクセスすることができる

グローバル：各データベースからネットワーク内の他のすべてのデータベースへ Oracle Names で
自動的に作成されます。
データベース・リンクは以下コマンドにて作成することができます。
CREATE DATABASE LINK <データベース・リンク名> CONNECT TO <接続ユーザー名> IDENTIFIED
BY <パスワード> USING <ネットサービス名>
また、リモート オブジェクトにアクセスするには、リモート データベース内でそのオブジェクトへのアク
セス権を付与する必要があります。
29
6.1.2 SQL Server のリンク サーバー
異なる SQL Server インスタンスのデータベースに対してクエリーを実行する場合、対象とする
SQL Server がリンク サーバーとして登録されている必要があります。
リンク サーバー
リンク サーバーを設定するには、SQL Server Management Studio を利用するか、sp_addlinkedserver と
sp_addlinkedsrvlogin システム ストアド プロシージャを用いて登録します。
Management Studio を用いたリンクサーバーの登録
30
リンクサーバーで用いるログインの設定
リンク サーバーを登録する際には、リンク サーバーに対してログインするセキュリティー コンテキストを
設定する必要があります。Windows 統合認証を用いているログインが、「ログインの現在のセキュリティー
コンテキストを使用する」を用いてリンク サーバーへアクセスする場合には、別途 KerberOS 認証を有効に
する必要があります。これを回避するためには、「このセキュリティー コンテキストを使用する」を用い、
リンク サーバーに対するログインに SQL Server 認証を用います。
リンク サーバーでの権限は、ログインに用いたセキュリティー コンテキストの権限が用いられます。
31
7. 監査
7.1 監査方法の移行
7.1.1 Oracle の監査方法
Oracle の監査には次の 4 つの方法があります。
1) 必須監査
2) 標準監査
3) ファイングレイン監査
4) DBA 監査
7.1.1.1 必須監査
必須監査では、Oracle に対する基本的な操作情報のログを取得しています。具体的には以下になります。
１．OS 監査
インスタンス起動・停止
管理者権限による接続
２．リスナー ログ
リスナーの起動・停止
リスナー経由での接続、及び接続エラー
Oracle では、これらの情報の取得は必須であり、無効にすることはできません。
7.1.1.2 標準監査
標準監査とは、管理者以外の一般ユーザーによるオブジェクトに対する操作、権限付与、DB 構成の変更な
どの監査証跡を取得します。標準監査の種類として、以下があります。
1. 文監査
一般的な SQL の捜査に対して監査を行います。文監査では特定のユーザーもしくは全ユーザーを対象に
監査を実施することができます。
2. 権限監査
DB ユーザー毎に割り当てられている権限に対して監査を行います。権限監査では特定のユーザーもしく
は全ユーザーを対象に監査を実施することができます。
32
3. オブジェクト監査
表や文のタイプに対して操作する SQL を実行した時に監査を行います。オブジェクト監査では全ユーザ
ーを対象に監査を実施します。
標準監査を行う場合、初期化パラメータの AUDIT_TRAIL を OS/DB/XML のいずれかに設定します。デフォ
ルトでは NONE になっています。また、Oracle10g 以降では監査機能が拡張され、SQL 文全体を取得する
ことが可能になっています。SQL 文全体を取得する場合は AUDIT_TRAIL を DB ,EXTENDED/XML,EXTENDED
のいずれかに設定します。
7.1.1.3 ファイングレイン監査
ファイングレイン監査では、オブジェクトの列や行に対する細かな監査を行うことができます。また、ファ
イングレイン監査で検出した処理に対するアクションを指定することができます。これにより、特定の列に
対してアクセスがあった場合メールで通知するようなこともできます。
ファイングレイン監査を使用する場合、DBA_FGA.ADD_POLICY プロシージャを使用して監査対象を定義しま
す。
設定を解除する場合は、DBA_FGA.DROP_POLICY プロシージャを使用します。
7.1.1.4 DBA 監査
DBA 監査とは SYSDBA/SYSOPER 権限を使っておこなった全ての操作ログを取得します。DBA 監査で取得さ
れたログはデータベースではなく OS のログ内に出力されます。
DBA 監査を行う場合、初期化パラメータの AUDIT_SYS_OPERATION を TRUE に設定します。デフォルトで
は無効になっています。
7.1.2 SQL Server の監査方法
SQL Server の監査には次の 2 つの方法があります。
1) C2 監査
2) SQL Server 監査
7.1.2.1 C2 監査
C2 監査は SQL トレースで取得できるトレースイベントから、C2 監査を満たす項目を取得する仕組みです。
C2 監査という用語については、SQL Server 2005 の機能紹介になりますが、
「SQL Server 2005 機能紹介」を
参照してください。SQL トレースについては、後続のトピック「トレース」を参照してください。
C2 監査を有効にするには、SQL Server Management Studio のインスタンスのプロパティで C2 監査を有効
にします。*1
33
C2 監査を有効にする
*1 sp_configure システムストアドプロシージャを用いる方法もあります。
C2 監査で取得されるトレースイベントは、SQL トレースの [セキュリティ監査イベントカテゴリ] イベント
から、Audit Broker Conversation イベント、および Audit Broker Login イベントのふたつを除いた全てのイ
ベントです。
セキュリティ監査イベントカテゴリについては「セキュリティ監査イベントカテゴリ」を参照してください。
7.1.2.2 SQL Server 監査
SQL Server 監査によって、サーバーおよびデータベースの操作証跡を保存することができます。
サーバー監査を設定するには次の手順に従います。
1) サーバー監査を構成する
サーバー監査の構成では、監査情報の保存先やファイルサイズなどを指定します。
SQL Server Management Studio のオブジェクト エクスプローラから、セキュリティ オブジェクトの [監査]
を右クリックして設定画面を起動します。
34
サーバー監査の作成
2) サーバー監査の仕様を構成する
サーバー監査の仕様では、サーバー監査の監査項目を指定します。
SQL Server Management Studio のオブジェクト エクスプローラから、セキュリティ オブジェクトの [サー
バー監査の仕様] を右クリックして作成画面を起動します。[監査] には、1) で構成した監査名を指定します。
サーバー監査の仕様の作成
35
3) データベース監査の仕様を構成する
データベース監査の仕様では、データベース監査の監査項目を指定します。
「データベース監査の仕様」で設定する監査項目の多くは、前述「サーバー監査の仕様」内のデータベース
監査項目として設定することができます。
「サーバー監査の仕様」によるデータベース監査項目の設定は、SQL
Server インスタンスの全てのデータベースに対して監査を実行します。特定のデータベースで監査を実行す
る場合には、「サーバー監査の仕様」では構成せずに、
「データベース監査の仕様」で構成します。逆に全て
のデータベースで監査すれば要件を満たす場合には、
「データベース監査の仕様」を構成する必要はありませ
ん。
データベース監査を設定するには、SQL Server Management Studio のオブジェクト エクスプローラから、
データベース オブジェクト内のセキュリティ オブジェクトを選択し、
「データベース監査の仕様」を右クリ
ックして設定画面を起動します。
データベース監査の仕様の作成
7.1.2.3 SQL Server 監査の対象
1) サーバー監査の仕様
下表はサーバー監査の仕様で構成できるアクション グループの一覧です。各々のアクショングループの意味
については、「SQL Server 監査のアクショングループとアクション」を参照してください。
サーバー監査の対象
サーバー監査の仕様で構成するアクショングループ
APPLICATION_ROLE_CHANGE_PASSWORD_GROUP
LOGIN_CHANGE_PASSWORD_GROUP
AUDIT_CHANGE_GROUP
LOGOUT_GROUP
BACKUP_RESTORE_GROUP
SCHEMA_OBJECT_ACCESS_GROUP
36
BROKER_LOGIN_GROUP
SCHEMA_OBJECT_CHANGE_GROUP
DATABASE_CHANGE_GROUP
SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP
DATABASE_LOGOUT_GROUP
SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP
DATABASE_MIRRORING_LOGIN_GROUP
SERVER_OBJECT_CHANGE_GROUP
DATABASE_OBJECT_ACCESS_GROUP
SERVER_OBJECT_OWNERSHIP_CHANGE_GROUP
DATABASE_OBJECT_CHANGE_GROUP
SERVER_OBJECT_PERMISSION_CHANGE_GROUP
DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP
SERVER_OPERATION_GROUP
DATABASE_OBJECT_PERMISSION_CHANGE_GROUP
SERVER_PERMISSION_CHANGE_GROUP
DATABASE_OPERATION_GROUP
SERVER_PRINCIPAL_CHANGE_GROUP
DATABASE_OWNERSHIP_CHANGE_GROUP
SERVER_PRINCIPAL_IMPERSONATION_GROUP
DATABASE_PERMISSION_CHANGE_GROUP
SERVER_ROLE_MEMBER_CHANGE_GROUP
DATABASE_PRINCIPAL_CHANGE_GROUP
SERVER_STATE_CHANGE_GROUP
DATABASE_PRINCIPAL_IMPERSONATION_GROUP
SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP
DATABASE_ROLE_MEMBER_CHANGE_GROUP
SUCCESSFUL_LOGIN_GROUP
DBCC_GROUP
TRACE_CHANGE_GROUP
FAILED_DATABASE_AUTHENTICATION_GROUP
USER_CHANGE_PASSWORD_GROUP
FAILED_LOGIN_GROUP
USER_DEFINED_AUDIT_GROUP
FULLTEXT_GROUP
2) データベース監査の仕様
下表はデータベース監査の仕様で構成できるアクション グループの一覧です。各々のアクション グループ
の意味については、「SQL Server 監査のアクショングループとアクション」を参照してください。
データベース監査の対象
データベース監査の仕様で構成するアクショングループ
データベース監査の仕様で構成する
監査のアクション
DATABASE_CHANGE_GROUP
SELECT
DATABASE_OBJECT_ACCESS_GROUP
UPDATE
DATABASE_OBJECT_CHANGE_GROUP
INSERT
DATABASE_OBJECT_OWNERSHIP_CHANGE_GROUP
DELETE
DATABASE_OBJECT_PERMISSION_CHANGE_GROUP
EXECUTE
DATABASE_OPERATION_GROUP
RECEIVE
DATABASE_OWNERSHIP_CHANGE_GROUP
REFERENCES
DATABASE_PERMISSION_CHANGE_GROUP
DATABASE_PRINCIPAL_CHANGE_GROUP
DATABASE_PRINCIPAL_IMPERSONATION_GROUP
DATABASE_ROLE_MEMBER_CHANGE_GROUP
37
SCHEMA_OBJECT_ACCESS_GROUP
SCHEMA_OBJECT_CHANGE_GROUP
SCHEMA_OBJECT_OWNERSHIP_CHANGE_GROUP
SCHEMA_OBJECT_PERMISSION_CHANGE_GROUP
7.2 監査データの配置場所の移行
7.2.1 Oracle の監査データの配置場所
7.2.1.1 必須監査の配置場所
必須監査の監査ログ出力先は、初期化パラメータの AUDIT_FILE_DEST に指定した配置場所に出力されます。
また、リスナーのログはデフォルトで $ORACLE_HOME/network/log/listener_<リスナー名>.log になります。
変更する場合、listener.ora の LOG_DIRECTORY_<リスナー名> に出力先を指定します。
7.2.1.2 標準監査の配置場所
標準監査の監査ログ出力先は、AUDIT_TRAIL に設定により異なります。DB を指定した場合、SYS.aud$ テー
ブルに格納されます。また、格納されたデータは DBA_AUDIT_TRAIL ビューで参照することができます。OS
の場合、初期化パラメータの AUDIT_FILE_DEST に指定した場所に OS ファイルとしてログが出力されます
(Windows の場合はイベントログ)。XML を指定した場合、初期化パラメータの AUDIT_FILE_DEST に指定し
た配置場所に XML ファイルとして出力されます。NONE を指定した場合、監査ログは取得されません(デフ
ォルト)。
7.2.1.3 ファイングレイン監査の配置場所
ファイングレイン監査の監査ログ出力先は、SYS.FGA_LOG$ テーブルに格納されます。また、格納されたデ
ータは DBA_FGA_AUDIT_TRAIL ビューで参照することができます。
7.2.1.4 DBA 監査の配置場所
DBA 監査の監査ログ出力先は、初期化パラメータの AUDIT_FILE_DEST に指定した場所に出力されます。
7.2.2 SQL Server の監査データの配置場所
7.2.2.1 C2 監査データの配置場所
トレース ファイルはインストール フォルダの ¥Data フォルダに保存され、
audittrace<yyyymmdhhmmss>_n.trc のようなネーミングで 200MB 毎に新しいファイルが生成されます。な
お、このフォルダは変更することができません。
ユーザが開始する SQL トレースと異なり、C2 監査の場合はトレース ファイルを保存するディスク領域が
フルになると、SQL Server インスタンスは自動的にシャットダウンします。
38
7.2.2.2 SQL Server 監査データの配置場所
SQL Server 監査の監査データは、監査を構成する際にファイルパスを指定することができます。また最大フ
ァイルサイズを指定し、監査データが最大ファイルサイズに達したときロールオーバーするよう指定できま
す。
監査データをファイルではなく Windows イベントログへ保管することもできます。
監査データの出力先の指定
39
8. レプリケーション
8.1 単一マスタ レプリケーション環境の移行 (マテリアライズド ビュー レプリケーション)
8.1.1 Oracle の単一マスタ レプリケーション
単一マスタ レプリケーションは、マテリアライズド ビューを使用してテーブルなどのオブジェクトのレプ
リカを作成することができます。以下は単一マスタ レプリケーションの概略図です。
単一マスタレプリケーションの概略図
Oracle の単一マスタ レプリケーションは、レプリカサイトにマスター サイトを参照する為の DB リンクと、
マテリアライズド ビューという実体を持つビューを使用した構成で実現することができます。
マスタ― サイトとの同期は、マテリアライズド ビューをリフレッシュを実行し、レプリカサイトへの更新
は Oracle のジョブ スケジューラを使用して定期的に実行することもできます。
また、マテリアライズド ビューへは通常更新処理をすることができませんが、マテリアライズド ビューを
更新可能に変更することもできる為、障害発生時にはレプリカ サイトをマスタ サイトとして稼働させるこ
とも可能です。
8.1.2 SQL Server のトランザクションレプリケーション
トランザクションレプリケーションは、データベース オブジェクトをレプリケーション先の SQL Server イ
ンスタンスへ複製します。レプリケーション可能なデータベース オブジェクトには、テーブル、テーブルの
サブセット、インデックス付きビュー、ストアド プロシージャなどがあります。
下図はトランザクション レプリケーションの仕組みの概略図です。データベース オブジェクトを配信する
SQL Server インスタンスをパブリッシャと呼びます。これに対してレプリケーション先となる SQL Server イ
ンスタンスはサブ スクライバと呼ばれます。ディストリビュータは、レプリケーションの対象となるデータ
ベース オブジェクト(アーティクルと呼びます)を、サブ スクライバへ配信する役目をします。ディストリビ
ュータは独立した SQL Server インスタンスに設定することもできますが、パブリッシャと同一の SQL
Server インスタンスに構成する方式がよく用いられます。またマージ エージェントをディストリビュータ
で実行する方式をプッシュ型、サブ スクライバで実行する方式をプル型と呼びます。
40
トランザクションレプリケーション（プッシュ型）
パブリッシャ
サブスクライバ
アーティクル
アーティクル
ログリーダ
エージェント
ディストリビュータ
エージェント
スナップショット
エージェント
ディストリビュータ
トランザクションレプリケーションの仕組み
スナップショット エージェントは、パブリッシュされたアーティクルの初期スナップショットを取得します。
取得されたスナップショットは、ディストリビュータ エージェントによってサブ スクライバへ配信されま
す。
ログリーダエージェントは、パブリッシャのトランザクションログファイルから、パブリッシュされたアー
ティクルの変更情報を読み出します。変更情報はログレコードではなく、ストアドプロシージャを用るレプ
リケーションコマンドとしてディストリビューション データベースに格納されます。ディストリビュータ
エージェントは、ディストリビューション データベースのレプリケーション コマンドを取り出し、これを
実行することで、サブ スクライバ へ レプリケーションデータを配信します。各エージェントは SQL Server
Agent のジョブとして実行されます。
8.2 マルチマスター レプリケーション環境の移行
8.2.1 Oracle のマルチマスター レプリケーション
マルチマスター レプリケーションは、複数のマスター サイトから構成されており、どのマスター サイトへ
も更新することができ、更新データはその他のマスター サイトに伝播されます。
また、サイトへの更新時、他サイトへのデータ反映は同期もしくは非同期で行うことができます (デフォル
トは非同期)。
41
8.2.2 SQL Server の マージレプリケーション
マージ レプリケーションは、アーティクルをサブ スクライバへ複製します。またサブ スクライバで発生し
た変更情報を、パブリッシャや他のサブ スクライバへ伝搬させます。サブ スクライバ毎にアーティクル内
で複製するデータをフィルタすることもできます。
下図はマージ レプリケーションの仕組みの概略図です。パブリッシャ、サブ スクライバ、アーティクル、
ディストリビュータという用語はトランザクションレプリケーションと同じ意味で用いられます。
ディストリビュータは独立した SQL Server インスタンスに設定することもできますが、パブリッシャと同一
の SQL Server インスタンスに構成する方式がよく用いられます。またマージエージェントをディストリビュ
ータで実行する方式をプッシュ型、サブ スクライバで実行する方式をプル型と呼びます。
マージレプリケーション（プッシュ型）
パブリッシャ
サブスクライバ
アーティクル
アーティクル
マージエージェント
スナップショット
エージェント
ディストリビュータ
マージレプリケーション
スナップショットエージェントは、パブリッシュされたアーティクルの初期スナップショットを取得します。
取得されたスナップショットは、マージエージェントによってサブ スクライバへ配信されます。
パブリッシュされたアーティクルの変更情報は、テーブル トリガーを利用して変更情報をトラッキングする
システムテーブルへ保管されます。この変更情報はマージ エージェントによって定期的に取得され、パブリ
ッシャとその他のサブ スクライバへ配信されます。各エージェントは SQL Server Agent のジョブとして実
行されます。
42
9. 高可用性
9.1 遠隔サイト リカバリー
9.1.1 Oracle DataGuard
Oracle の DataGuard は、通常時に使用されるプライマリ データベースと障害時に切り替わるスタンバイデ
ータベースで構成されており、プライマリ データベースへの更新処理で作成された REDO ログがスタンバ
イ データベースに自動で転送されます。そして、プライマリ データベースに障害が発生した時にスタンバ
イ データベースに切り替えることで処理を継続させることができます。
DataGuard にはフィジカル スタンバイとロジカル スタンバイの 2 種類があります。フィジカル スタンバ
イはデータブロックの配置まで同一化し、ロジカル スタンバイは REDO データを SQL 文に変換してから
スタンバイ側を更新します。また、スタンバイ データベースは参照用 DB として使用することができます。
フィジカル スタンバイの場合、スタンバイ側のデータベースを読み取り専用で OPEN する必要があります
(ロジカル スタンバイでは常時参照することができます)。
さらに、生成された REDO ログをスタンバイ側への適用は、同期、非同期を選択することができます。同期
転送の場合、LGWR がスタンバイ側に REODO ログ情報を適用する為、データのロスがなくなりますが、
REDO 適用によるパフォーマンスが劣化してしまいます。これに対して、非同期転送では、LGWR とは別の
プロセス (LNS) が転送する為、パフォーマンスへの影響はほとんどありませんが、障害時にデータをロスす
る可能性があります。
43
9.1.2 SQL Server ログ配布とデータベース ミラーリングと AlwaysOn
9.1.2.1 SQL Server ログ配布
SQL Server ログ配布は、データセンターとリモートセンターの 2 つの SQL Server インスタンス間でデータベ
ースを同一に保ちます。始めにデータセンターで取得したデータベース バックアップをリモートセンターに
リストアすることでリモートセンターのデータベースを初期化し、データセンターで継続的に取得されるト
ランザクション ログバックアップをリモートセンターでリストアします。SQL Server ではこの仕組を、バ
ックアップ、コピー、リストア、アラートの 4 つの SQL Server Agent ジョブとして実装し、ログ配布と呼
んでいます。
ログ配布の構成
データセンター
リモートセンター
リストアジョブ
ログバックアップ
ファイル
プライマリ
データベース
コピー
ログバックアップ
フォルダ
（ファイル共有）
コピージョブフォルダ
プライマリサイト
セカンダリ
データベース
セカンダリサイト
監視サーバ
アラートジョブ
ログ配布の構成
通常セカンダリ データベースはリストア中の状態になっており、データベースを参照・更新することはでき
ません。しかしログ配布設定時にスタンバイ モードを指定すると、セカンダリ データベースは仕掛中の全
トランザクションを一時的にロールバックして読み取り専用状態になります。これによりレポーティング業
務などの処理がセカンダリ データベースで実行可能になります。
SQL Server Management Studio によってログ配布を構成すると、バックアップ、コピー、リストアジョブの
ジョブの間隔は既定で 15 分に設定されます。この実行間隔は変更することができます。
各々のジョブは相互に関連なくて実行されるため、バックアップ ジョブとコピー ジョブの間隔を 15 分に
設定することは、プライマリセンタの被災時において、最大で 30 分近くのログを消失する可能性を意味し
ます。
44
9.1.2.2 SQL Server データベース ミラーリング
データベース ミラーリングでは、ログを転送する方法が、バックアップ ファイルの転送ではなくてログブ
ロックの転送になり、その仕組みが SQL Server エンジンの機能として提供されます。また転送されたログ
を随時フォワード リカバリする処理 (Redo 処理) には、データベース再始動の機能が利用され、ログの適
用処理が継続されます。
データベースミラーリング
ログ番号
ログ番号
ログ番号
更新情報
更新情報
更新情報
プリンシパル
ミラー
随時フォワードリカバリが実行される
ログはバックアップファイルではなく、
ログレコード（ログブロック）
として送信される
ログ配布と同様、初期化として
データベースバックアップのリストアが必要
（取得済みのログバックアップがあれば、これもリストアする）
データベース ミラーリング
ログの転送をトランザクションと同期して実施するか、あるいは非同期に実施するかによって、データベー
ス ミラーリングには、高い安全性モード (SAFETY オプション FULL) と、高パフォーマンス モード(SAFETY
オプション OFF) の 2 つが用意されています。高い安全性モードでは、ログはトランザクションと同期的に
送信されます。また高パフォーマンス モードでは、ログはトランザクションと非同期的に送信されます。
45
9.1.2.3 AlwaysOn Availability Group
AlwaysOn Availability Group は、Windows Server フェールオーバー クラスタリングと、SQL Server のデー
タベース ミラーリングのメリットを組み合わせた機能*1 で、最大 4 台のセカンダリに対して複製処理を行
えます (従来バージョンでは 1 台のセカンダリに対応)。データベースの複製を 4 つ保持できることにより、
障害、オペレーション ミス、自然災害などによってデータを損失してしまうリスクを軽減できます。
遠隔地に配置したセカンダリに非同期モードでデータベースを複製できます。災害対策 (ディザスタ リカバ
リ) を 1 つのウィザードで構成できるため、シンプル、かつ低コストで耐災害性を高めたシステムを構築で
きます。
*1 SQL Server 2012 Enterprise Edition から提供
AlwaysOn Availability Group
プライマリとセカンダリに 1 つの仮想サーバー名でアクセスできるため、フェールオーバー時やフェールバ
ック時にアプリケーションの接続先を変更する必要がありません。また、インスタンスの設定や機能に依存
しない Contained Database により、フェールーバー後にログイン アカウントや照合順序を修復する必要が
ありません。クライアントからの透過的なアクセスと Contained Database によって、より迅速なフェール
オーバーが可能になり、ダウンタイムを大幅に短縮できます。
遠隔地に配置したセカンダリに非同期モードでデータベースを複製できます。災害対策 (ディザスタ リカバ
リ) を 1 つのウィザードで構成できるため、シンプル、かつ低コストで耐災害性を高めたシステムを構築で
きます。
アクティブ セカンダリに対して、リアルタイムで読み取り操作を行えると共に、完全バックアップやログ バ
ックアップを行えます。データの参照やバックアップから開発環境を構築する際にも、プライマリに対する
46
操作が不要になるため、運用データベースの負荷を減らすことができます。また、アプリケーション側で負
荷分散を制御する必要がなく、AlwaysOn Availability Group が接続形態に応じて接続先をフォワーディング
するため、負荷分散のメリットを容易に得られます。
47
10. トレース
10.1 トレースの移行
10.1.1 Oracle のトレース
Oracle では、データベース上で実行されている SQL 文の処理時間や待機時間、物理/論理読み込みブロック
数、SQL の実行計画などを取得することができます。
SQL トレースは、データベース単位、セッション単位で取得することができます。また、セッション単位は、
現行のセッションに対して取得するものと、特定のセッションに対して設定する方法の 2 種類があります。
SQL トレースの取得方法は以下の通りです。
データベース単位の SQL トレース取得方法
ALTER SYSTEM SET SQL_TRACE=TRUE;
現行のセッションで実行する SQL のトレース取得方法
ALTER SESSION SET
SQL_TRACE=TRUE;
<取得したい SQL 実行>;
特定のセッションで実行されている SQL のトレース取得方法
EXECUTE DBMS_SYSTEM.SET_SQL_TRACE_IN_SESSION(<SID>,<SERIAL#>,TRUE);
上記により、USER_DUMP_DEST 配下に .trc という拡張子のトレースファイルが出力されます。このトレー
スファイルを tkprof で整形することで SQL トレースの情報を見やすくすることができます。
TKPROF <トレースファイル名> <出力ファイル名>
以下、TKPROF 整形後のトレース情報です。
select 1
from
sys.cdc_change_tables$ where source_schema_name = :1 and source_table_name
= :2 and bitand(mvl_flag, 128)=128
call
count
cpu
elapsed
disk
query
current
rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
48
Parse
1
0.00
0.03
0
0
0
0
Execute
1
0.00
0.00
0
0
0
0
Fetch
1
0.00
0.00
1
3
0
0
------- ------ -------- ---------- ---------- ---------- ---------- ---------total
3
0.00
0.04
1
3
0
0
Misses in library cache during parse: 0
Optimizer mode: CHOOSE
Parsing user id: SYS
Rows
(recursive depth: 1)
Row Source Operation
------- --------------------------------------------------0 TABLE ACCESS FULL CDC_CHANGE_TABLES$ (cr=3 pr=1 pw=0 time=4747 us)
Elapsed times include waiting on following events:
Event waited on
Times
---------------------------------------db file sequential read
Max. Wait Total Waited
Waited ---------1
0.00
-----------0.00
10.1.2 SQL Server のトレース
SQL Server で実行されているクエリ ステートメントやクエリプラン、エラー情報を、SQL トレースのイベ
ントとして記録することができます。プロファイラという呼称が一般的ですが、プロファイラがクライアン
トで起動する GUI ベースのフォアグラウンド ツールを指すのに対して、SQL トレースは、SQL Server イン
スタンスが稼動するサーバー ローカルで実行されるバックグラウンド トレースと言うことができます。取
得できるイベントやデータ列は両者に差異はありません。取得したトレースファイルはプロファイラ GUI ツ
ールでオープンすることができます。
SQL トレースはシステム ストアドプロシージャを用いて設定することができますが、大変複雑なため、プ
ロファイラの GUI ツールによってイベントやフィルターを定義しておき、SQL トレーススクリプトを自動
生成させるようにします
SQL トレース スクリプトの自動生成
49
下のスクリプトは自動生成した SQL トレース定義の先頭部分です。赤下線の部分は生成後修正が必要な部
分を示しています。

@maxfilesize は適切なファイルサイズ (例；200MB) を指定します。

sp_trace_create の第 2 引数 (@options) を 2 に設定することで、ファイルサイズが @maxfilesize の値
に達したときに次のファイルを作成することを指定します。
sp_trace_create の第 3 引数 (@tracefile) にパス名を含むファイル名を指定します。ファイル名には自動的
に拡張子「.trc」が追加されますので、拡張子は必要ありません。パフォーマンスの観点からネットワークド
ライブを指定しないようにします。
SQL トレース スクリプトのカスタマイズ
/****************************************************/
/* Created by: SQL Server 2008 Profiler
*/
/* Date: 2009/11/28 19:57:14
*/
/****************************************************/
-- Create a Queue
declare @rc int
declare @TraceID int
declare @maxfilesize bigint
set @maxfilesize = 200
------
Please replace the text InsertFileNameHere, with an appropriate
filename prefixed by a path, e.g., c:¥MyFolder¥MyTrace. The .trc extension
will be appended to the filename automatically. If you are writing from
remote server to local drive, please use UNC path and make sure server has
write access to your network share
exec @rc = sp_trace_create @TraceID output, 2, N'C:¥TraceLog¥TraceData',
@maxfilesize, NULL
if (@rc != 0) goto error
(以下略)
SQL トレース スクリプトを実行すると、トレース定義がサーバーに登録されます。登録時に結果として表
示される TraceID を元に、SQL トレースの動作を設定します。
sp_trace_setstatus @TraceID,1・・・トレースの実行、データの採取開始
sp_trace_setstatus @TraceID,0・・・トレースの停止
sp_trace_setstatus @TraceID,2・・・トレース定義の削除
50
また、現在システムに登録されている SQL トレースの状況を確認する場合は、fn_trace_getinfo 関数を利用
します。
SQL トレースで取得できるイベントについては、
「SQL Server イベントクラスの参照」を参照してください。
51
11. 接続方法の移行
11.1 接続方法の移行
11.1.1 Oracle の接続方法
Oracle は、クライアントからの接続方法として専用サーバー接続と共有サーバー接続があります。
専用サーバー接続は、ユーザーからの接続要求があるとサーバープロセスが起動する接続方法です。ユーザ
ープロセスに対してサーバープロセスが 1 対 1 に対応する為、セッション数が多い環境などでは CPU や
メモリリソースを多く必要とします。
これに対して、共有サーバー接続はサーバー プロセスが複数のユーザープロセスからの要求を受け付ける接
続方法です。ユーザーからの要求があると、ディスパッチャ プロセスがユーザー プロセスとの接続を確立
します。そして、ディスパッチャ プロセスからサーバー プロセスに処理が渡され処理されます。セッショ
ン数が多く専用サーバー接続で CPU やメモリ リソースを多く使用してしまうような環境に有効な接続方
法です。
ディスパッチャやサーバー プロセス数などの設定は以下初期化パラメータにて指定することができます。
初期化パラメータ
説明
SHARED_SERVERS
共有サーバー プロセスの初期起動数を指定します。
MAX_SHARED_SERVER
共有サーバー プロセスの最大起動数を指定します。
仮想サーキットの最大数を指定します
CIRCUITS
※仮想サーキット：ディスパッチャと共有サーバープロセスを使用した接続の
こと
SHARED_SERVER_SESSIONS
共有サーバー接続を行うセッションの最大数を指定します。
DISPATCHERS
ディスパッチャ プロセスの初期起動数を指定します。
MAX_DISPATCHERS
ディスパッチャ プロセスの最大起動数を指定します。
52
11.1.2 SQL Server スレッド モデルの設定
SQL Server は単一プロセスとして稼働します。ユーザー クエリーはプロセス内のワーカスレッドが処理し
ます。
ワーカスレッドは SQL Server 起動時に生成され、負荷に応じて max worker threads サーバー オプション
で指定した数まで増加します。この設定は既定で自動となっており、生成されるワーカスレッドの最大値は
次の表のようになっています。
生成されるワーカスレッドの最大値
Number of CPUs
32-bit サーバー
64-bit サーバー
4 以下
256
512
8 以下
288
576
16 以下
352
704
32 以下
480
960
64 以下
736
1472
128 以下
4224
4480
256
8320
8576
max worker thread オプションを指定する場合は、32bit では最大でも 1024、64bit では同じく 2048 を限
度とします。これはスレッドあたりのスタック メモリ領域 (*1) の増加による影響が無視できないためです。
同じ理由でこれを変更する場合はメモリが逼迫しないか慎重なテストを実施するようにします。
SQL OSスケジューラ
Task
Scheduler
クエリリクエスト
Task
CPU 1
Scheduler
Scheduler
Worker
CPU 2
Scheduler
Worker
Worker
Worker
Worker
Worker
CPU 0
Worker
CPU 3
SQL OSノード
ワーカスレッド
プール
SQL OS とワーカスレッドの概念図
*1
32-bit: 512KB; X64: 2MB; IA64: 4MB
以上
53