SQL Server 入門

Microsoft
SQL Server 入門
日本マイクロソフト株式会社
Cloud Application Business Unit
北川剛

Database
データを
多数のユーザーが
共有利用するために
１つにまとめた集合体
2(c) 2014, Microsoft Corporation Japan. All Rights Reserved.

Database
Management
System
データを管理する・保護する
アクセス制御を行う
障害復旧の仕組みを提供する

Relational
Database
データが表形式で表現される
複数の表を関連付けた処理がで
きる

Relational
Database
Management
System
リレーショナルデータベースを
管理するシステム

SQL Server
データを企業内で共有利用するた
めに必要な
 記憶域
 管理機能
を提供するソフトウェア

SQL Server の歴史
第一世代：1994～1998
 SQL Server 4.2 / 6.0 / 6.5
Sybase 社から技術提供を受け開発
Windows NT Server で稼働
 ページロック
第二世代：1998～2005
 SQL Server 7 / 2000
アーキテクチャを刷新
 行ロックの導入
 SQLOS の採用
 Analysis Services / ETL の提供開始
第三世代：2005～
 SQL Server 2005 / 2008 / 2008 R2
IA32 から x64 への移行
NUMA アーキテクチャの拡張
クエリ並列処理機能の強化
動的管理ビューによる内部動作の可視化
 SQL Server 2012
列ストア（カラムナ）の実装（Read Only）
高可用性機能の刷新（AlwaysOn）
 SQL Server 2014
インメモリ OLTP（メモリ最適化テーブル）
メモリ最適化列ストアの実装（更新可能）
バッファプール拡張

リソース管理
 メモリ管理
 プロセッサ

リソース管理 – SQL Server のメモリ管理
(c) 2014, Microsoft Corporation Japan. All Rights Reserved. 9
 SQL Server 7.0 より動的・自動チューニング
メモリを実装
 SQL Server と OS のメモリロードにより、メモ
リは時間とともに増減
 メモリ領域を固定するには
max server memory = min server memory
に設定
 バッファプール
 以下に 8KB 単位で連続領域を割当てる
 バッファキャッシュ
 プロシージャキャッシュ
 クエリワークスペース
 ロック
 その他（接続, オプティマイザ, ユーティリティなど）
 8KB より大きな領域の割り当ては OS の機能を直
接使用
 バッファプールの最大値は起動時計算され確保
 物理メモリサイズに応じて決定
 最大サーバーメモリは動的な変更が可能
 起動時に “min server memory” を獲得する
MemToLeave 領域
スレッドスタック
オペレーティングシステム
64-bit メモリレイアウト
SQLServer
その他
ロック
クエリワークスペース
プロシージャキャッシュ
バッファキャッシュ
バッファプール

リソース管理 – SQL Server のメモリ管理
 スレッドスタック
 スレッドあたり 512KB
 sp_configure ‘max worker threads’ で設定
 スレッド用アドレス空間はバッファプールがあ
けて残している領域
 サーバーは少ない数のスレッドで開始
 スレッドとスタックはオンデマンドで割当てられる
 MemToLeave 領域
 拡張プロシージャ, .dll ファイル, 分散クエリに
よって参照される OLE DB プロバイダ、Transact-
SQL ステートメントで参照される OLE オート
メーションオブジェクト等のアイテムを読み込
むために SQL Server によって使用される領域
 規定値は 256MB
 最大サーバーメモリを下げても確保されるメモ
リ量に変更はない
 MemToLeave を制御するには、起動パラメータ
に –g を付加して使用
MemToLeave 領域
スレッドスタック
オペレーティングシステム
64-bit メモリレイアウト
SQLServer
その他
ロック

リソース管理 – メモリサイズの設定
 SQL Server Management Studio (SSMS)
> オブジェクトエクスプローラー
> インスタンス名
> プロパティ
> メモリ
一度コミットされると解放されないサイズ
バッファプールサイズの指定

リソース管理 – MAX Degree Of Parallelism
 並列プラン実行で使用されるプロセッサ数の制限
 インスタンスレベルの既定値は 0
 使用できるすべてのプロセッサを利用する
 DWH へのデータロードなど単一のバッチ処理を実行す
る場合には 0 が有効
 クライアントからの複数接続が存在する OLTP 処理で
は 8 以下を推奨
 インスタンスレベルの既定値の設定変更
MAX Degree Of Parallelism の設定
sp_configure ‘show advanced options’, 1
GO
RECONFIGURE WITH OVERRIDE
GO
sp_configure ‘max degree of parallelism’, 8
GO
RECONFIGURE WITH OVERRIDE
GO
 クエリレベルの設定
 ステートメントに MAXDOP クエリヒントを記述

リソース管理 – ワーカースレッド
 ワーカースレッド
 SQL Server の論理的なスレッド
 Windows スレッドまたはファイバのいずれかと 1 : 1 で
マップされる
 サーバー構成オプション max worker threads でスレッ
ド数を指定できる
 既定ワーカースレッドの最大値
最大スレッド数の指定
プロセッサコアの数 32-bit 64-bit
4 個以下 256 512
8個 288 576
16個 352 704
32個 480 960
64個 736 1,472
128個 4,224 4,480
256個 8,320 8,576
※設定後は SQL Server の再起動が必要
32-bit 環境では 1,024 を最大値とすることを推奨

 アプリやユーザー単位でリソース配分が可能
 ワークロードを分類
 アプリケーションやユーザーを基準に分類
 リソース利用率を制限
 最大メモリ使用率
 最大 CPU 使用率
 最大 I/O 帯域利用率
 許容するタイムアウト値
 要求の最大数
 ワークロードとリソースプールのマッピング
 N : 1 の関係
 ワークロードに対しては重要度（優先度）の
設定も可能
 Low, Medium（既定）, High
リソース管理 – リソースガバナー

記憶域管理
 システムデータベース
 データベースファイルとファイル
グループ
 ページとエクステント
 ファイルのディスク配置

システムデータベース
 制御情報は全てシステムデータベースに格納
 システムデータベース
 master データベース
SQL Server のインスタンスレベルのシステム情
報が格納されているデータベース
 resource データベース
SQL Server のシステムオブジェクトが格納され
ている読み取り専用データベース
 msdb データベース
警告やジョブスケジュールの設定などエージェ
ントにより使用されるデータベース
 model データベース
ユーザーデータベース作成時のテンプレートと
なるデータベース
 tempdb データベース
一時オブジェクトや作業領域として使用される
データベース
 バックアップ対象のシステムデータベース
 master, msdb, model
 バックアップ対象外のシステムデータベース
 Tempdb
インスタンス起動時に再構築されるためバック
アップは対象外
 resource
SQL Server のシステムオブジェクト定義が格納
されており、読み取り専用のデータベースのた
めバックアップは対象外

データベースファイルとファイルグループ
 データベースファイル
 プライマリデータファイル (.mdf)
 各データベースには１つのプライマリデー
タファイルがある
 データベースの起動情報、他のデータファ
イルへのポインタ情報が格納される
 セカンダリデータファイル (.ndf)
 プライマリデータファイル以外のすべての
データファイル
 使用は任意
 トランザクションログファイル (.ldf)
 データベースの復旧に使用するすべてのログ
情報が格納される
 １つのデータベースには最低１つのログ
ファイルが必要
プライマリデータベースファイル
トランザクションログファイル

データベースファイルとファイルグループ
 ファイルグループ
 データベースファイルを論理的にグルー
プ化
 ユーザーテーブルやインデックスの作成
先としてファイルグループを指定するこ
とが可能
 ファイルグループには３種類が存在
 プライマリ
プライマリデータファイルと他のファイル
グループに割り当てられていないデータファ
イルが含まれる
 ユーザー定義
 トランザクションログファイルはファイ
ルグループに含まれない
プライマリ

ページとエクステント
 ページ
 データストレージの基本単位
 １ページのサイズは 8 KB
 １ページは１つのオブジェクトにより占有
 エクステント
 論理的に連続する８つのページで構成
 テーブルやインデックスに領域を割当て
る基本単位
 単一エクステント
 単一のオブジェクトが占有
対象のオブジェクトのデータ総量が 64 KB
以上の場合
 混合エクステント
 複数のオブジェクトにより共有
対象オブジェクトのデータ総量が 64 KB 未満
の場合
 最大８オブジェクトで共有
データベース
.mdf / .ndf
ログファイル
.ldf
エクステント (64 KB)
連続する 8 ページ
ページ (8 KB)
最大行サイズ 8060 bytes

ファイルのディスク配置
~データベースのファイル配置 ~
 I/O 特性
 データファイル
 Random : OLTP
 Sequential : Bulk Insert, Read Ahead,
Backup / Restore
 トランザクションログ
 Sequential
 tempdb の用途
 一時オブジェクトや作業領域として使用される
 ソート領域, 一時テーブル, テーブル変数
 静的カーソル、キーセットカーソル
etc…
 CPU と同数のファイルを作成する
 tempdb のパフォーマンス最適化
http://technet.microsoft.com/ja-jp/library/ms175527.aspx
データベースアクセス頻度詳細
システムデータベース
master, msdb, model
データファイル低サーバー構成の変更、ログインの追加、ジョブの管理・実行といった限ら
れた用途でアクセスされるため高速なディスクへ配置する必要はないログファイル低
tempdb データファイル高可能な限り専用のディスクに配置
データファイルは CPU の数と同等数作成するログファイル高
ユーザーデータベースデータファイル高専用のディスクに配置
ログファイル高専用のディスクに配置

ファイルのディスク配置
~ RAID 構成例 ~
 ファイル区分ごとに異なるディスクドライブ
を割当てる
 RAID 0, 5, 1+0 はディスクスピンドル数が増
加するとパフォーマンスが向上する
 ファイルの特性、ディスクの信頼性・速度・
コストのバランスによって構成
ファイル区分 RAID 0 RAID 1 RAID 5 RAID 0+1
システム (Windows, SQL Server のバイナリ等) ○
ページングファイル △ ○
バックアップファイル △ ○
データファイル ○ ○ ◎
トランザクションログファイル ○ ◎
tempdb データベース △ ○ ○ ◎
SQL Server システムデータベース ○
高速なフラッシュメモリストレージ

領域管理  インデックス

インデックス
 B ツリー構造でデータページと同じく 8KB のインデックスページに格納
 B ツリーの最上位はルートノード、最下層はリーフノード、その間は中間ノード
 インデックスのタイプ
 クラスタ化インデックス
 リーフノードにはデータ自体が格納されるため、インデックスをリーフノードまでスキャンするとデータを
取り出すことが可能
 データはクラスタ化インデックスキーの順序で格納される
 上記の理由により、テーブルにクラスタ化インデックスは１つしか作成できない
 クラスタ化インデックスは一意
 重複するデータを持つ列にクラスタ化インデックスを作成すると、内部的に 4bytes の uniqueifier を追加し一意性を確保
 非クラスタ化インデックス
 一行のデータを検索する場合は効果的
 リーフノードにはブックマークが格納
 ブックマークには以下の２種類がある
 テーブルにクラスタ化インデックスが存在する場合、クラスタ化インデックスキー
 テーブルがヒープの場合、行識別子（RID）
 非クラスタ化インデックスは１つのテーブルに最大 249 個まで作成可能

クラスタ化インデックスの検索
Akhtar
…
Martin
Page 140 - Root
Akhtar
Ganio
…
Page 141
Martin
Smith
…
Page 145
Akhtar
Barr
…
Page 100
2334
5678
…
…
…
…
Ganio
Hail
…
Page 110
7678
8078
…
…
…
…
Martin
Ota
…
Page 120
8755
4035
…
…
…
…
Smith
Smith
…
Page 130
1434
5778
…
…
…
…
リーフノード
クラスタ化インデックス

非クラスタ化インデックス
非クラスタ化インデックスの検索
クラスタ化インデックスが存在するテーブルの場合
Barr
Nash
Kim
Barr
Cox
…
Adam
Ariette
…
…
…
…
Kim
Kobara
…
Shane
Linda
…
…
…
…
Nash
Nagata
…
Mike
Namie
…
…
…
…
Aaron
Jose
…
Aaron
Deana
…
Aaron
Adam
…
Con
Barr
…
Deana
Don
…
Daum
Half
…
Jose
Nina
…
Jose
Namie
…
Lugo
Nagata
…
リーフノード
（ブックマーク）

非クラスタ化インデックス
非クラスタ化インデックスの検索
クラスタ化インデックスが存在しないテーブルの場合
Akhtar
…
Martin
Akhtar
Ganio
…
Akhtar
Barr
…
4:706:01
4:705:03
…
Ganio
Don
…
4:709:01
4:709:04
…
Martin
Smith
…
Martin
Matey
…
4:708:01
4:706:04
…
ヒープ
リーフノード
Page 12 - Root
Page 28Page 37
Smith
Smith
…
4:706:03
4:708:04
…
Page 41 Page 51 Page 61 Page 71
01
02
03
Conn
Funk
White
…
…
…
…
… …
… … …
Page 704
01
02
03
Rudd
White
Barr
…
…
…
…
… …
… … …
Page 705
01
02
03
Anktar
Funk
Smith
04
…
…
…
… Matey
… … …
Page 706
01
02
03
Smith
Ota
Jones
…
…
…
…
… …
… … …
Page 707
01
02
03
Martin
Phua
Jones
04
…
…
…
… Smith
… … …
Page 708
File ID #4

断片化
 内部断片化
 使用しているデータ領域の内部に空白があり、結果として本来必要としている量よりも多くの領域を消費し
ている状態
 ページ分割やデータの削除によりページ内部で空白が発生
空き
ページ
 外部断片化
 領域の物理的順序が論理的順序と一致していない状態
3 1 4 2
ページ
（1）（2）（3）（4）

断片化の解消
 内部断片化の解消
 データベースの圧縮
 DBCC SHRINKDATABASE ステートメント
 インデックスの再編成
 ALTER INDEX REORGANIZE ステートメント
 インデックスの再構築
 ALTER INDEX REBUILD ステートメント
 外部断片化の解消
 インデックスの再編成
 インデックスの再構築
 インデックス再編成と再構築の判断
 avg_fragmentation_in_percent 値が 30% 未満の場合、インデックスの再編成
 avg_fragmentation_in_percent 値が 30% 以上の場合、インデックスの再構築

インデックス再編成
 ALTER INDEX … REORGANIZE
 DBCC INDEXDEFRAG のすべての機能を持つ
 インデックスの再編成は常にオンラインで実行
 データは常に利用可能
 リーフページの物理順序をリーフノードでの左から右への論理順序と一致させる
 インデックスのリーフレベルの断片化を解消
 全ての作業がトランザクションログに記録される
 LOB データの圧縮
3 1 4 2
（1）（2）（3）（4）
1 2 3 4
（1）（2）（3）（4）

インデックス再構築
 ALTER INDEX … REBUIKD
 DROP_EXISTING 句を指定した CREATE INDEX
 オンライン / オフラインでのインデックス再構築
 ONLINE / OFFLINE 句を指定
 ONLINE 句を指定した場合、対象となるテーブルへのデータの追加・更新・削除が可能
 対象
 FILLFACTOR のリセットを指定
 インデックスのリーフレベルのデータ格納率の再設定が可能
 MAXDOP で並列処理の程度を制御
 インデックス作成処理を並列化
USE <database_name>
GO
ALTER INDEX ALL ON <table_name>.<colum_name>
REBUILD WITH (FILLFACTOR = 80, ONLINE = ON);
GO
構文

オンラインインデックス再構築時の
トランザクション処理
 ロック発生タイミングとトランザクションの関係
時間
共有（S）ロックスキーマ修正（SCM_M）ロック
インテント共有
（IS）ロック
インデックス操作
準備フェーズ
インデックス操作
終了フェーズ
インデックス
ビルドフェーズ
“dual-update path” が発生
tx1 tx2 tx3
個別のトランザクションとして実行
 dual-update path
 ユーザーからの処理により発生したトランザクションは
ソース / ターゲット双方のインデックスに対して追加・更新・削除を行う
オリジナル
インデックス
新しい
インデックス
dual-update path

ID Name
1001 Aoki
1002 Ito
1005 Yamada
1008 Nakata
1010 Saito
ID Name
1001 Aoki
1002 Ito
1005 Yamada
1008 Nakata
1010 Saito
ページ分割
 ページ分割
 50-50 ページ分割
 ページが完全に埋まっている状態で間にデータが挿入
 ページ内の 50% を新しい空ページへ移動
 100-0 ページ分割
 INSERT されるデータのキー値が増加するシナリオであれば新たなページのアロケーションのみ
ID Name
1001 Aoki
1002 Ito
1005 Yamada
1008 Nakata
1010 Saito
ID Name
5012 Aoki
5015 Ito
5016 Yamada
5017 Nakata
5019 Saito
Page 100 Page 199
INSERT
ID Name
1001 Aoki
1002 Ito
1003 Suzuki
ID Name
1005 Yamada
1008 Nakata
1010 Saito
Page 200
クラスタ化インデックス / 50-50 ページ分割
INSERT
Page 100~199

データ管理
データ保護
 データ参照・変更
 行のバージョン管理に基づく分離
レベル
 チェックポイント
 自動復旧

データの参照
~ SELECT ~
 バッファプールが不足すると物理 IO が発生
SQL Server
ログキャッシュ
SELECT …
FROM …
WHERE …
tempdb
データファイル (.mdf)
ログファイル (.ldf)
SELECT …
FROM …
WHERE …
1. SELECT 文を実行
2. プロシージャキャッシュにキャッシュ
3. ディスクから読み取り
連続する領域に
割り付けられていれ
ばシーケンシャル
I/Oが可能
4. 並べ替えや結合処理、
一時オブジェクト等
5.
6. 結果
…
…
…
高速なフラッシュメモリストレージを利用した
バッファプール拡張

データの更新
~ UPDATE, INSERT, DELETE ~
 変更履歴は先行書き込みされる
 バッファキャッシュの更新データはチェックポイント時に一括で書き込まれる
SQL Server
ログキャッシュ
SELECT …
INSERT …
UPDATE …
tempdb
データファイル (.mdf)
ログファイル (.ldf)
INSERT …
UPDATE …
1. SQL 文を実行
2. プロシージャキャッシュにキャッシュ
5. チェックポイント時に一括でディスク
書き込み
Random I/O
3. バッファキャッシュ内変更
INSERT …
UPDATE …
4. 先行書き込み
201 INSERT …
202 UPDATE …
Sequential
I/O

行のバージョン管理に基づく分離レベル
ANSI/ISO SQL92 が定義する
トランザクション分離レベル
SQL Server 2005 以降
Uncommitted Read ○
Read Committed
○ ロック方式
○ 行のバージョン管理
Repeatable Read ○
Serializable ○
Snapshot ○ 行のバージョン管理
分離性
安全性
パフォー
マンス
同時
実行性
低高高
高低低
 行のバージョン管理に基づく分離レベルを使用した場合、読み取り操作でのロックが排除され、
読み取りの同時実行性が向上
 SQL Server 2005 以降で、行のバージョン管理を使用する 2 つのトランザクション分離レベルを導入
 “更新前データ” は tempdb に格納される
参考資料: tempdb に使用するディスク領域の計画
http://msdn.microsoft.com/ja-jp/library/ms345368.aspx

行のバージョン管理に基づく分離レベルの比較
テーブル test の b 列の値を 100 から 200 に更新中に検索した場合
行のバージョン管理を伴う READ COMMITTED 分離
ALTER DATABASE <db_name> SET READ_COMMITTED_SNAPSHOT ON
行のバージョン管理を伴う READ COMMITTED 分離
ALTER DATABASE <db_name> SET ALLOW_SNAPSHOT_ISOLATION ON
トランザクション A
BEGIN TRANSACTION
UPDATE test SET b = 200
COMMIT
トランザクション B
BEGIN TRANSACTION
SELECT b FROM test
SELECT b FROM test
更新前データ 100 が返される
更新後データ 200 が返される
他のユーザーからの更新
時間
ステートメント（文）レベルの一貫性の保証
トランザクションレベルの一貫性の保証
SQL 文実行前にコミットした
データが返る
トランザクション内で
値が変わる可能性あり
トランザクション A
BEGIN TRANSACTION
UPDATE test SET b = 200
COMMIT
トランザクション B
SET TRANSACTION ISOLATION LEVEL SNAPSHOT
BEGIN TRANSACTION
SELECT b FROM test
SELECT b FROM test
更新前データ 100 が返される
更新後データ 100 が返される
他のユーザーからの更新
時間
同一トランザクションでは
同じ値が返る

チェックポイント
 ダーティページをディスクに書き込む
 バッファキャッシュ上で変更されたページ（ダー
ティページ）をディスクにフラッシュする動作
 チェックポイントレコードがログファイルに書き込
まれる
 発生するタイミング
 CHECKPOINT コマンドを発行した場合
 データベースファイルを追加する ALTER DATABASE
ステートメントが実行された場合
 ログ使用量が 70% に達した場合（単純復旧モデル）
 ログのアクティブ部分が Recovery Interval サーバー
構成オプションの指定時間内にサーバーが復旧でき
るサイズを超えている場合
 Recovery Interval のデフォルトは 0 （自動設定）
 Recovery Interval が 0 の場合 1 分間隔で CHECKPOINT を実行
 シャットダウンする場合
 SHUTDOWN WITH NOWAIT コマンドの場合はチェックポイントが
起動しない

自動復旧
 インスタンスの起動時に自動的に行われる
時間
利用可能
障害発生
インスタンス
起動
Transaction 1
Transaction 2
A → B C → D G → H COMMIT
E → F
トランザクション
ログファイル
101 Tran1 A -> B
102 Tran1 C -> D
103 Tran2 E -> F
104 Tran1 G -> H
105 Tran1 COMMIT
LSN
ログレコード毎に
振られる連番
COMMIT 時にはロ
グバッファに存在
する更新情報がす
べて書き込まれる
ロールフォワードロールバック利用可能
Tran1 A -> B
Tran1 C -> D
Tran2 E -> F
Tran1 G -> H
Tran1 COMMIT
Tran2 ROLLBACK
E → F を取り消す
※ 不完全なトランザクションを
ロールバック
トランザクションログファイルを
読んでデータファイルに適用する

障害復旧
 バックアップ
 復元（リストア）
 運用例

障害復旧
 バックアップ
 完全バックアップ（フルバックアップ）
 差分バックアップ
 トランザクションログバックアップ
 トランザクションログの切り捨て
 復旧モデル
 一括ログ復旧モデル
 復旧モデルの変更
 部分バックアップ
 バックアップ履歴の確認
 不要なバックアップ履歴の削除
 バックアップデバイスの確認
 復元（リストア）
 データベースの復元操作
 復旧状態の選択
 運用例
 バックアップ運用例
 ディスク障害時のデータベース復元
 元の場所に復元できない場合
 オンライン復元
 ページ単位の検証
 ページ単位の復元
 バックアップを他のインスタンスで復元
 デタッチ・アタッチ
 master データベースのバックアップ取得タイミング
 msdb データベースのバックアップ取得タイミング
 model データベースのバックアップ取得タイミング

バックアップ – 完全バックアップ
 全ての情報を含む、データベース全体のバッ
クアップ
 バックアップ完了時点までの情報を持つ
 用途
 復元処理のベースライン
 データベースの復元、移動
 特徴
 作成されるバックアップファイルのサイズは、デー
タ容量とほぼ同一サイズ（データが含まれているエ
クステント＋バックアップ開始から終了までのロ
グ）
 トランザクションログの切り捨ては行われない
ログ
バックアップセット
バックアップ開始
01:00
バックアップ終了
02:00
MinLSN
MinLSN
データの入っているエ
クステントのみをバッ
クアップする
オンラインバックアッ
プ中のトランザクショ
ンログ
バックアップ終了時点
の状態を再現できる

バックアップ – 差分バックアップ
 最後の完全バックアップ以降に変更されたエ
クステントのみをバックアップ
 差分バックアップ完了時点の情報を持つ
 用途
 バックアップおよび復元に要する時間の短縮
 頻繁に変更が発生するデータベースや巨大なデータ
ベースを対象とする
 特徴
 完全バックアップよりもファイルサイズが小さい
 バックアップの時間は変更されたデータ量に比例す
る
 復元時は、最新の完全バックアップに続けて、最新
の差分バックアップを適用
ログ
01:00
01:10
MinLSN
MinLSN
完全バックアップ後に
変更されたエクステン
トのみ
差分バックアップ中に
発生したトランザク
ションログ
バックアップ終了時点
の状態を再現できる

バックアップ –
トランザクションログバックアップ
 トランザクションログ（変更履歴）のみをバックアップ
 データファイルのバックアップは取得しない
 特徴
 バックアップファイルは非常に小さい
 バックアップ時間はトランザクション量に依存するが、完全・差分
バックアップに比べ短時間
 トランザクションログバックアップが取得された後、自動的にトラ
ンザクションログファイルが切り捨てられる
 トランザクションログファイルの切り捨てが行われないとトランザクションログ
ファイルは拡張を続ける
 トランザクションログファイルの切り捨てを行っても、物理的にファイルが縮小する
わけではない
 トランザクションログファイルの縮小方法
 トランザクションログファイルの切り捨て処理を実行
 データベースまたはファイルの圧縮処理を実行
DBCC SHRINK DATABASE or DBCC SHRINKFILE
ログ
MinLSN
MinLSN
トランザクションログ
（変更履歴）をバック
アップ
バックアップ終了後に
の切り捨てを実行

バックアップ –
トランザクションログの切り捨て
 トランザクションログが切り捨てられるタイミング
 完全・一括復旧モデル使用時はトランザクションログのバックアップ実行後
 単純復旧モデル使用時はチェックポイント時
 MinLSN より古いトランザクションログが切り捨てられる
 切り捨てにより物理ファイルが縮小することはない
 長時間実行しているトランザクションに注意
LSN
99
…
…
LSN
100
Begin
Tran1
LSN
101
Check
Point
LSN
102
Update
Tran1
LSN
103
Begin
Tran2
LSN
104
Update
Tran2
LSN
105
Commit
Tran1
LSN
106
Check
Point
LSN
107
Update
Tran2
LSN
108
…
…
LSN
109
…
…
LSN
110
…
…
LSN
111
…
…
LSN
112
…
…
LSN
113
…
…
LSN
100
Begin
Tran1
LSN
101
Check
Point
LSN
102
Update
Tran1
LSN
103
Begin
Tran2
LSN
104
Update
Tran2
LSN
105
Commit
Tran1
LSN
106
Check
Point
LSN
107
Update
Tran2
LSN
108
…
…
LSN
109
…
…
LSN
110
…
…
LSN
111
…
…
LSN
112
…
…
LSN
113
…
…
MinLSN
非アクティブ（再利用可能）
トランザクションログバックアップ MinLSN

バックアップ – 復旧モデル
 完全復旧モデル（Full）
 トランザクションログファイルの障害時以外は、障害直前の COMMIT 時点まで復旧可能
 指定した特定の日時まで復旧可能（ポイントインタイムリカバリ）
 単純復旧モデル（Simple）
 トランザクションログをチェックポイント時に自動的に切り捨てる
 データベースバックアップ時点への復元のみ
 一括ログ復旧モデル（Bulk-Logged）
 一括操作のパフォーマンスを向上させる復旧モデル（大量データ INSERT / インデックス作成など）
 一括操作を行っていない場合は「完全復旧モデル」と動作は同じ
 一括操作を行った場合は障害直前のバックアップ終了時点まで復旧可能だが、ポイントインタイムリカバリ
は不可
バックアップの種類と復旧モデル
復旧モデル
バックアップの種類
データベース完全データベース差分トランザクションログ
完全必須任意必須
一括ログ必須任意必須
単純必須任意不可

一括ログ復旧モデル
 一括操作以外の動作は完全復旧モデルと同様
 一括操作のトランザクションログは最小限
 一括操作： SELECT INTO, Bulk INSERT, BCP, WRITETEXT, etc…
 トランザクションログファイルには一括操作が行われたという情報と領域の拡張情報などしか書き込まない
 トランザクションログのバックアップは以下の 2STEP になる
 一括操作による変更エクステントをバックアップ
 通常のトランザクションログのバックアップ
 トランザクションログのバックアップ時にはデータファイルにアクセスできることが前提条件
データ
ファイル
トランザクションログのバックアップ
ログ
一括操作による変更
一括操作によって変更された後のエクステントが
コピーされるので
ポイントインタイムリストア
ができなくなる

バックアップ – 復旧モデルの変更
完全完全一括ログ
復旧モデルの切り替え
完全 → 一括ログ
復旧モデルの切り替え
一括ログ → 完全
のバックアップ
のバックアップ
一括処理の実行
1 2 3
4
メリット
 最新の状態への復旧
 任意の時点まで復旧
 最後のログのバックアップが
可能
メリット
 高速な一括処理
デメリット
 一括処理を行うと
 任意の時点までの復旧が不可
 データファイルにアクセスできない
状態ではトランザクションログの
バックアップができない

バックアップ – 部分バックアップ
 データベースの一部分（ファイルグループ / ファイル）単位のバックアップが可能
データベース
プライマリファイルグループ
ユーザー定義
ファイルグループ A
ユーザー定義
ファイルグループ B
Read Only
プライマリファイルと読み書き可能なファイルグループ
のみバックアップ
ファイル / ファイルグループ単位でバックアップ
PrimaryFile & FileGroup A Backup
FileGroup B Backup
BACKUP DATABASE <database_name> READ_WRITE_FILEGROUPS
[<Filegroup_List>, …] TO <backup_device>
BACKUP DATABASE <database_name>
[<Filegroup_List>, …] TO <backup_device>
Available

バックアップ – バックアップ履歴の確認
 SQL Server Management Studio
 復元元データベースをセットすると自動的に選択される
 msdb に記録された履歴情報の表示
SELECT
type,
name,
description,
first_lsn,
last_lsn,
backup_finish_date,
compressed_backup_size,
physical_device_name,
logical_device_name
FROM msdb.dbo.backupset as s
JOIN msdb.dbo.backupmediafamily as m
ON s.media_set_id = m.media_set_id
WHERE database_name = ‘<database_name>'
ORDER BY 1
※情報が確認されても実際にバックアップが存在するとは限らない

バックアップ – 不要なバックアップ履歴の削除
 sp_delete_backuphiroty / sp_delete_databasebackup_history を使用して
不要なバックアップ履歴を削除可能
EXEC sp_delete_backuphistory ‘<date>’
※msdb データベースのバックアップ履歴のみが削除される
EXEC sp_delete_database_backuphistory ‘<database_name>’

バックアップ – バックアップデバイスの確認
ステートメント内容
RESTORE VERIFYONLY
バックアップセットが完全で、ボリュームが読み取り可能であることを
確認
RESTORE LABELONLY メディアヘッダ情報を含む結果セットを返す
RESTORE HEADERONLY
バックアップデバイス上にあるすべてのバックアップセットについて、
すべてのバックアップヘッダ情報（データベース名やバックアップの種
類など）を含む結果セットを返す
RESTORE FILELISTONLY
バックアップセットに保存されているデータファイルとログファイルの
一覧を含んだ結果セットを返す
RESTORE HEADERONLY
FROM {DISK | TAPE} = ‘<backup_device_name>’
構文

復元 – データベースの復元操作
> データベース
> データベースの復元
復元元
データベースの選択
の選択

復元 – データベースの復元操作
復元場所の指定復旧状態の選択

復元 – 復旧状態の選択
 RESTORE WITH NORECOVERY
 最新のバックアップを除くすべてのバックアップで指定
 復旧プロセスを実行するまでデータベースは使用不可
 未コミットのトランザクションをロールバックしない
 引き続き差分やログのバックアップを適用可能
 RESTORE WITH RECOVERY
 復元すべき最新のバックアップでのみ指定
 未コミットのトランザクションをロールバックする
 適用後、データベースは使用可能
 RESTORE WITH STANDBY
 データベースの読み取りが可能
 引き続き差分やログのバックアップを適用可能
 UNDO ファイルを使用し復旧操作を取り消すことが可能

運用例 – バックアップ運用例
土 23:00 09:00… 火 23:00 09:00… 金 23:00 …
完全バックアップ差分
バックアップ
差分
バックアップ
ログバックアップ
 土曜日 23:00 にフルバックアップを取得
 平日業務時間中 3 時間おき（09:00 / 12:00 / 15:00 / 18:00）に
トランザクションログバックアップを取得
 平日 23:00 に差分バックアップを取得
 システムデータベースのバックアップは適宜取得

運用例 – ディスク障害時のデータベース復元
時間
完全バックアップ
差分
バックアップ
障害発生
カレントトランザク
ションログのバック
アップを取得
1
最後のログバックアップ
(Tail-log Backup)
※ データファイルが破損していて
も取得可能
完全バックアップを復元
2
最新の
差分バックアップを復元
3
差分バックアップ以降の
バックアップを復元
4
障害発生後取得した
バックアップを復元
5

運用例 – ディスク障害時のデータベース復元
 最新のトランザクションログバックアップを取得（NO_TRUNCATE オプション）
BACKUP LOG <database_name>
TO <backup_device_name>, …
WITH NORECOVERY, NO_TRUNCATE
 完全バックアップからデータベースを復元（NORECOVERY オプション）
RESTORE DATABASE <database_name>
FROM <backup_device_name>
WITH NORECOVERY
 差分バックアップからデータベースを復元（NORECOVERY オプション）
WITH NORECOVERY
 ログの復元（NORECOVERY オプション）
RESTORE LOG <database_name>
WITH NORECOVERY
 最新のログの復元と復旧
RESTORE LOG <database_name>
WITH RECOVERY

運用例 – 元の場所に復元できない場合
 MOVE TO 句を指定し別の場所に復元できる
 データベース名の変更も可能
FROM {DISK | TAPE} = <backup_device_name>
WITH
MOVE <file_name1> TO <new_file_name1>,
MOVE <file_name2> TO <new_file_name2>,
RECOVERY
構文

運用例 – オンライン復元
 プライマリファイルグループがオンラインかつ使用可能な状態の場合、ファイル復元、ページ
復元をオンラインで実行可能
データベース
プライマリファイルグループ
ユーザー定義
ファイルグループ A
ユーザー定義
ファイルグループ B
a1
Read Only
Available
障害
発生
※ 障害が発生していないファイル・ファイルグ
ループへはアクセス可能
手順オペレーション
1 ファイル a1 をオンライン復元
RESTORE DATABASE adb FILE=‘a1’
FROM backup WITH NORECOVERY
※ ファイル a1 は復元状態になり、ファイルグループ A はオフライン
になる
2 トランザクションログをバックアップ
BACKUP LOG adb TO log_backupN WITH COPY_ONLY
※ 通常のバックアップの順序には影響しない、コピーのみのバック
アップを行う。COPY_ONLY を指定した場合、データベースの全体
的なバックアップと復元の手順に影響はない。
3 ファイル a1 を復旧
RESTORE LOG adb FROM log_backup WITH NORECOVERY
:
RESTORE LOG adb FROM log_backupN WITH RECOVERY

運用例 – ページ単位の検証
ページ確認の設定
> データベース
> プロパティ

運用例 – ページ単位の検証
 電源障害などによって生じる I/O エラーの検知
 データページにチェックサムを追加
 全てのページヘッダにチェックサム値を含む
 書き込み時にチェックサム計算
 読み取り時に検出
 違いが見つかった場合、エラーを返す
 823：CRC エラー
 824：論理エラー
 829：Restore Pending 状態
 破損ページ情報はシステムテーブルに格納される
 msdb.suspect_pages テーブル
 Tron-Page-Detection より詳細な検証が可能
 ページ破損の影響
 破損したページにアクセスできなくなるが、その他のページへのアクセスは可能（ただし、ブートページな
どの特殊なページ破損の場合は影響範囲が大きくなる）
 ページ単位での復元
 オフラインであれば全エディションで可能
 オンラインでページ復元ができるのは Enterprise のみ

運用例 – ページ単位の復元
 ページ単位のエラーを修復
 破損ページを指定
PAGE=‘File#:Page#[,…]’
FROM DISK=<backup_device_name>
構文
 最新のログを取得して、ページ復元後、
ログの復元と復旧が必要
破損ページを指定

運用例 – バックアップを他のインスタンスで復元
 ユーザーデータベースのバックアップだけが存在
 バックアップファイルを他のインスタンスで復元・復旧することも可能
master msdb model tempdb master msdb model tempdb
User DB User DB
バックアップ
ファイル
バックアップ復元・復旧

運用例 – デタッチ・アタッチ
 データベースのデータファイルおよびトランザクションログファイル（.mdf / .ldf）は、
デタッチして SQL Server の同一または別のインスタンスに再度アタッチすることが可能
 32-bit 環境と 64-bit 環境の間でも機能
master msdb model tempdb master msdb model tempdb
User DB User DB
.mdf .ldf .mdf .ldf
デタッチアタッチ
コピー

運用例 –
master データベースのバックアップ取得タイミング
 下記の操作を行ったタイミングでバックアップを取得する
 データベースの作成・削除
 データファイルの追加・削除
 ログインの追加または他のログインセキュリティに関連した操作
 サーバー構成の設定を変更（インスタンスのパラメータ）
 バックアップデバイスの作成や削除
 リンクサーバーの追加やリモートログインなどの分散クエリ
およびリモートプロシージャコール用サーバーの設定
 master データベースは完全バックアップのみ

運用例 –
msdb データベースのバックアップ取得タイミング
 ジョブの作成および変更
 SSIS（SQL Server Integration Services）パッケージの SQL Server インスタンスへの格納
 オンラインのバックアップと復元の履歴のメンテナンス
 レプリケーション設定の変更

運用例 –
model データベースのバックアップ取得タイミング
 起動時に毎回作成される tempdb データベースとユーザーデータベースを作成する際の
テンプレートとなるデータベース
 定義内容
 データファイルとトランザクションログファイルのデータベースサイズや初期構成値
 データベースオプション
 照合順序・コードページ
 復旧モデル
 その他データベースオプション
 テンプレートを変更した際
model データベース自身を更新したタイミングでバックアップを取得

特徴
Windows Platform 上で稼働
All-in-One Platform
Single Source

Better Together with Windows
Windows Platform に最適化
 OS が認識できる CPU リソースをフル活用
 OS が認識できるメモリをフル活用
 NUMA 対応（スケールアップ型）
 Active Directory (AD) に統合された
ユーザー管理
FUJITSU Server PRIMEQUEST
2800E
Max 8CPU/120Cores, 12TB Memory
NEC Express5800/A1080a
A1080a-E
Max 8CPU/80Cores, 2TB Memory
HP ProLiant DL580 Gen8
728544-291
Max 4CPU/60Cores, 3TB (6TB) Memory

SQL Server は All-in-One プラットフォーム
RDBMS
Engine
Relational Database
Analysis
Services
Business Intelligence
Platform
Integration
Services
ETL (Extract, Transform
and Load) Tool
Reporting
Services
Web Reporting
 大規模 OLTP
 大規模 DWH
 高可用性
 分析用インメモリ DB
 多次元キューブ
 データマイニング
 データ統合
 マスターデータ管理
 データクレンジング
 表現力豊かなレポート
 定期配信
 地図（Bing Map）とも連携

Single Source for all size of System
大規模から小規模まで
Edition Max # of CPU Max Memory Size Max Database Size
Enterprise OS Max OS Max 524 PB
Business Intelligence 4 CPU or 16 Cores 128 GB 524 PB
Standard 4 CPU or 16 Cores 128 GB 524 PB
Express 1 CPU or 4 Cores 1 GB 10 GB
SQL Server 2014 の各エディションがサポートする機能
http://msdn.microsoft.com/ja-jp/library/cc645993.aspx

SQL Server 2014
データ処理に必要な機能群を
すべて包含した “All-in-One” プラットフォーム。
最新の SQL Server 2014 を利用して、ビジネスを
加速させませんか？
詳細については、SQL Server の概要ページをご覧ください
http://www.microsoft.com/ja-jp/server-cloud/products/sql-server/

SQL Server 入門

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (8)

Similar to SQL Server 入門

Similar to SQL Server 入門 (20)

SQL Server 入門

Editor's Notes