Db 友の会第1回 sql server 勉強会資料

第1回 SQL Server 勉強会いちから勉強。 SQL Serverの基本構成 / データ書き込み / バックアップの動作について

本日の Agenda

1. SQL Serverの基本構成

2. データ書き込みの基本動作

3. バックアップの基本動作

この 3 点についてデモを交えながらお話させていただきます。

2010/11/6 DB友の会勉強会資料 2

本日のデモ環境 SQL Server デモ環境

Hyper-V 上のゲスト OS CPU : 4Core

Memory : 2GB

Windows Server 2008 R2 Datacenter Edition SQL Server 2008 R2 Datacenter Edition x64 + CU4

物理環境 (Hyper-V のホスト環境) ThinkPad x201i

CPU : Intel Core i3 M330 (2.13 GHz 4Core)

Memory : 4GB

HD : 250 GB

Windows Server 2008 R2 Datacenter Edition SP1 RC

物理環境 (x201i)

仮想環境 (SQL Server デモ環境)


1.SQL Server の基本構成


このセクションの内容


1. SQL Server のインスタンスの基本構成

2. SQL Server のデータベースエンジンのサービスの基本構成

3. SQL Server の接続の基本動作

SQL Server の基本的な構成

SQL Server はマルチインスタンス / マルチデータベース環境で構築することができます。

マルチインスタンス

一つのサーバー内に複数のインスタンス (SQL Server のサービス) を作成することができます。

マルチデータベース

一つのインスタンスの中に複数のデータベースを作成することができます。


インスタンス B インスタンス A

マルチインスタンス / マルチデータベース構成概要図

サーバー


ユーザーデータベース

A システム用 DB #1

A システム用 DB #2

B システム用 DB #1


C システム用 DB #1



master

システムデータベース

model

msdb

tempdb

Resource master


model

msdb

tempdb

Resource

システムデータベースの役割


データベース名役割

master SQL Server システムのシステムレベルの情報がすべて記録されます。記録される情報には、ログオンアカウント、エンドポイント、リンクサーバー、システム構成設定など、インスタンス全体のメタデータが含まれます。 master データベースが使用できないと、SQL Server を開始できません。

model SQL Server のインスタンスに作成するすべてのデータベースのテンプレートとして使用されるデータベースです。 tempdb は SQL Server が起動するたびに作成されるので、model データベースが常に SQL Server システムに存在する必要があります。

msdb 警告やジョブのスケジュール設定のために SQL Server エージェントによって使用されます。また、その他の Service Broker やデータベースメールなどの機能でも使用されます。

tempdb SQL Server のインスタンスに接続しているすべてのユーザーが使用できるグローバルリソースであり、以下のものを保持するために使用されます。 • グローバルまたはローカルな一時テーブル、一時ストアドプロシージャ、テーブル変数、カーソルなど、明示的に作成された一時的なユーザーオブジェクト。

• スプールまたは並べ替えのために中間結果を格納するための作業テーブルなど、SQL Server データベースエンジンが作成する内部オブジェクト。

• 行のバージョン管理。

Resource • 読み取り専用のデータベースで、SQL Server に含まれるすべてのシステムオブジェクトがこれに格納されます。

• SQL Server システムオブジェクト (sys.objects など) は、物理的には Resource データベースに保存されていますが、論理的にはすべてのデータベースの sys スキーマ内にあるように扱われます。

インスタンスの種類インスタンスには以下の 2 種類があります。

既定のインスタンス

サーバー内で一つのみ作成できるインスタンス接続時には <サーバー名> で接続が可能

名前付きインスタンス

サーバー内で複数作成ができるインスタンス接続時には <サーバー名¥インスタンス名> で接続が可能

インスタンスの構成ひとつの既定のインスタンスひとつの名前付きインスタンスひとつの既定のインスタンス + 複数の名前付きインスタンス複数の名前付きインスタンス


既定のインスタンスと名前付きインスタンスの違い


項目既定のインスタンス名前付きインスタンス

接続時の指定サーバー名サーバー名¥インスタンス名

初期サービスポート 1433 (TCP) 動的ポート (TCP)

専用管理者接続 (DAC) ポート (*) 1434 (TCP) 動的ポート (TCP)

※専用管理者接続 (Dedicated admin connection : DAC) 実行中のサーバーにアクセスして、診断関数や Transact-SQL ステートメントを実行したり、サーバー上の問題のトラブルシューティングを行ったりすることができます。このことは、サーバーがロックされていたり、異常状態で実行されたりしていて、SQL Server データベースエンジン接続に応答していない場合も同じです [VISIBLE ONLINE (DAC)] という状態のスケジューラーが専用管理者接続用のスケジューラーになります。 (sys.dm_os_schedulers/sys.dm_os_schedulers 動的管理ビューから確認可能)

- sys.dm_os_memorys-

- sys.dm_os_schedulers -

SQL Server のサービスの構成

SQL Server は以下のサービスで構成されます。データベースエンジンのコアコンポーネントのサービス

のみ記載しています。

サービスの単位サービス名内容

インスタンス単位

SQL Server (<インスタンス名>) SQL Server データベースエンジンのコアサービス

SQL Server Agent (<インスタンス名>) SQL Server のジョブを起動するサービス

共有サービス SQL Server Browser SQL Server の接続情報 (インスタンス名に対してのポート番号) をクライアントに返すサービス




SQL Server のサービスの構成概要図

サーバー

SQL Server (インスタンス A) Port 1433 (TCP)

SQL Server Agent

(インスタンス A)

SQL Server Browser Port 1434 (UDP)



SQL Server (インスタンス B) Port 動的ポート (TCP)

SQL Server Agent

(インスタンス B)


専用管理者接続 (DAC) Port 1434 (TCP)

専用管理者接続 (DAC) Port 動的ポート (TCP)

既定のインスタンスのポート番号の確認


SQL Server のポート

構成マネージャーから確認

DAC のポート

ログファイルから確認

名前付きインスタンスのポート番号の確認


SQL Server のポート

構成マネージャーから確認

DAC のポート

ログファイルから確認

SQL Browser サービスの役割


既定のインスタンス接続時の概要

SQL Server 1433 (TCP) クライアント

①サーバー名で接続

②Port 1433 (TCP) で接続

③接続完了

SQL Browser サービスの役割


名前付きインスタンス接続時の概要

SQL Server 動的ポート (TCP) クライアント

①サーバー名¥インスタンス名で接続

②SQL Browse サービス (1434 (UDP)) にインスタンスの情報を問い合わせ

③SQL Browser サービスがインスタンスの情報を回答

④回答された接続情報で SQL Server に接続

⑤接続完了

接続先の SQL Server のポート番号を明示的に指定すれば SQL Browser サービスが

停止していてもインスタンスに接続することが可能です。

既定のインスタンスのポート番号を変更すると？


サーバー名で接続をしようとした場合は Port 1433 (TCP) で接続を試行します。

既定のインスタンスが 1433 以外で実行されている場合は、接続時にポート番号を明記する必要があります。 SQL Browser を使用して解決してくれたような記憶もあったの

ですが、検証したところ解決できませんでした。

参考) 名前付きインスタンスにサーバー名だけで接続


サーバー名だけで接続をした場合、Port 1433 (TCP) で接続を試行します。

そのため、名前付きインスタンスに 1433 を固定で割り当てるとサーバー名だけで接続をすることが可能です。

SQL Browser の接続情報を確認


ネットワークキャプチャソフトで SQL Browser サービスとネットワークパケットを確認してみます。

ネットワークキャプチャに使用したソフト


Microsoft Network Monitor 3.4

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=983b941d-06cb-4658-b7f6-3088333d062f&displaylang=ja











2.データ書き込みの基本動作




5 種類の操作の基本確認 1. SELECT

2. INSERT

3. DELETE

4. UPDATE

5. TRUNCATE TABLE

この 5 種類の操作を複数の情報から確認してみます。

概要レベルで記載しているため詳細に見ていくとさらに細かな動作が行われています。あらかじめご了承ください。

SELECT の基本動作


クライアント

SQL Server ①SELECT ～

データベースメモリ

データファイル (mdf)

ログファイル (ldf)

②データファイルからデータを読み込み

②’メモリにデータをロード

③クライアントに結果を返す

SELECT 時の各種状態


データバッファキャッシュ

ディスク I/O

DATA：データ行 (BLOB を除く)

TEXT_MIX： LOB (ラージオブジェクト)

INDEX：インデックスのエントリ

IAM： Index Allocation Map エクステントを結びつけるために使用されるページ

PFS： Page Free Space ページの空き容量を管理

DIFF_MAP (DCM)：最後の BACKUP DATABASE ステートメント以降に変更されたエクステント

SELECT の基本動作 (ソートあり)


クライアント

SQL Server ①SELECT ～ ORDER BY ～




②データファイルからデータを読み込み

③クライアントに結果を返す

tempdb

②’’中間結果を書き込み

②’メモリにデータをロード


ディスク I/O

SELECT 時 (ソートあり) の各種状態


tempdb が拡張できないと


メッセージ1105、レベル17、状態2、行1

データベース'tempdb' にオブジェクト'dbo.SORT temporary run storage: 140737490190336' の領域を割り当てられませんでした。'PRIMARY' ファイルグループがいっぱいです。不要なファイルの削除、ファイルグループ内のオブジェクトの削除、ファイルグループへの新しいファイルの追加、またはファイルグループの既存のファイルの自動拡張の設定のいずれかを行ってディスク領域を作成してください。

大量のメモリを搭載していても、tempdb のディスクサイズが枯渇するとソート等の処理は完了しません。

INSERT の基本動作


クライアント

SQL Server ①INSERT INTO ～




②INSERT データをログに先行書き込み

③メモリにINSERTデータをロード

(ダーティーページ)

⑤チェックポイント発生時ダーティーページを

データファイルに書き込み

④クライアントからみて処理完了

ダーティーページ：物理書き込みが行われていないキャッシュ上のデータ

チェックポイント：キャッシュ上のダーティーページをディスク上のデータにフラッシュ

INSERT 時の各種状態



トランザクションログ

DELETE の基本動作


クライアント

SQL Server ①DELETE FROM～




③DELETE データをログに先行書き込み

②削除対象を検索しダーティーページ

としてマーク

④DELETE 対象を非実在 (ゴースト)レコードとして

マーク

⑤クライアントからみて処理完了

⑥バックグラウンドのクリーンアップタスク

(GhostCleanup Task)で非実在レコードを削除

DELETE 時の各種状態




UPDATE の基本動作


クライアント

SQL Server ①UPDATE～




②UPDATE データをログに先行書き込み

③メモリにデータをロードし UPDATE (ダーティーページ)

⑤チェックポイント発生時ダーティーページを

データファイルに書き込み

④クライアントからみて処理完了

DisplaySwitch.exe



UPDATE 時の各種状態


TRUNCATE TABLE の基本動作


クライアント

SQL Server ①TRUNCATE TABLE～




③TRUNCATE データをログに先行書き込み

(ビットマップの更新)

②対象テーブルの割り当て情報を取得

④テーブルのページを割り当て解除

⑤クライアントからみて処理完了

TRUNCATE 時の各種状態




データ書き込みの基本動作を確認


ソート時のディスク / メモリの動作と UPDATE 時のデータ書き込みの動作をのぞいてみます。

3.バックアップの基本動作




3 種類のバックアップの説明

ページとエクステント

差分バックアップについて

バックアップの種類


バックアップの動作は大きく分けて 3 種類

1. 完全バックアップ

2. 差分バックアップ

3. トランザクションログバックアップ

SQL Server のバックアップ / リストアの基本は上記 3 種類のバックアップと 3 種類の復旧モデル (単純 / 完全 / 一括ログ) の組み合わせで考えていきます。

今回は 3 種類のバックアップについて。リストアと復旧モデルは別の機会に。

各バックアップの内容


バックアップの種類バックアップの特徴

完全バックアップ特定のデータベース、またはファイルグループやファイルのデータがすべて含まれます。さらに、データを復旧するために必要なログも含まれます。

差分バックアップ差分バックアップは、最後に行ったデータの完全バックアップに基づきます。差分バックアップには、差分ベースの作成以降に変更されたデータのみが含まれます。復元時には、完全バックアップを先に復元し、続いて最新の差分バックアップを復元します。時間の経過と共にデータベースが更新されるにつれて、差分バックアップに含まれるデータ量が増えます。

トランザクションログバックアップ

完全復旧モデルまたは一括ログ復旧モデルでは、通常のトランザクションログバックアップ (ログバックアップ) が必要になります。各ログバックアップは、バックアップを作成したときにアクティブだったトランザクションログ部分に対応します。また、ログバックアップには、以前のログバックアップ時にバックアップされなかったすべてのログレコードも含まれます。完全復旧モデル、および場合によっては一括ログ復旧モデルでは、ログチェーンが途切れていなければデータベースを任意の時点に復元できます。トランザクションログは、通常のログバックアップ後に毎回切り捨てられます。

初回バックアップ前後の動作について


初回完全バックアップ前後でトランザクションログの蓄積状況が違うようです。

初回完全バックアップ前

トランザクションログのバックアップをしないでもある程度トランザクションログが切り捨てられている。

初回完全バックアップ時にトランザクションログの切り捨てがされる。

初回完全バックアップ後

トランザクションログのバックアップを取得しないとトランザクションログが蓄積され続ける。

完全バックアップを取得してもトランザクションログが切り捨てられない。

完全バックアップ

バックアップイメージ


差分バックアップ

データベース


トランザクションログバックアップ


※ 上図は取得種類のイメージ図のため、各ファイルを対象として記載しています。

3 種類のバックアップを利用した基本設定例


日月火水木金土

0:00

完全バックアップ

0:00


0:00


0:00


0:00


0:00


0:00


1時間毎

ログバックアップ

1時間毎


1時間毎


1時間毎


1時間毎


1時間毎


1時間毎


参考) リストア概要


1. 完全バックアップ単体でリストア可能 (mdf / ndf / ldf ファイルを復元) バックアップ取得時点までのデータをリストアすること

が可能

2. 差分バックアップ単体でリストア不可差分バックアップ取得前の完全バックアップと組み合わ

せてリストアをするバックアップ取得時点までのデータをリストアすること

が可能

3. トランザクションログバックアップ単体でリストア不可

参考) リストアの基本手順


1. 最新の完全バックアップをリストア

2. 最新の差分バックアップをリストア ※ 差分バックアップは前回の完全バックアップからの差分

になりますので、複数の差分バックアップがあっても、最新の差分バックアップをリストアすれば、それまでのデータはリストアされます。

3. 最新の差分バックアップ以降のトランザクションログバックアップをリストア

※ 最新の差分バックアップ以降の変更をロールフォワードします。

ページとエクステント


差分バックアップは変更されたエクステントが取得されます。 DCM (差分変更マップ : Differential Changed Map)

BCM (括変更マップ : Bulk Changed Map)

変更されたエクステントの追跡には上記 2 種類のビットマップが使用されていますが今回は用語の紹介まで。

ページ SQL Server のデータストレージの基本単位

データ /インデックス /テキスト / イメージ / GAM / DCM / BCM / IAM …

SQL Server では、ページのサイズは 8 KB になります。通常の最大行サイズは 8,060 バイト

BLOB や ROW_OVERFLOW は置いときます…。

エクステントエクステントは、物理的に連続する 8 ページをまとめたもので、ページを効率的

に管理するために使用されます。すべてのページは、エクステントに格納されます。

1 エクステント = 8 ページ = 64 KB 単一エクステントと混合エクステントという種類があるのですが、今回は用語の紹介まで。

ページとエクステントの概要図


ページエクステント

ページヘッダー

テーブル 1 データ行 1



テーブル 1 ページ 1








参考) 混合エクステント





テーブル 1 インデックス 1

テーブル1 インデックス 2

テーブル 2 インデックス1



※ 前のページは単一エクステントの概要図になります

差分バックアップについて


差分バックアップは更新があったエクステントが取得されます。

DCM によって取得対象が管理されています。 DCM はエクステントのビットマップ情報を管理しているため、エクステント内のページに変更があった場合は、変更されていないページの情報も取得対象となります。

前回の完全バックアップ取得からテーブルの変更が大きくなると、取得対象も多くなるため完全バックアップを取得しないとバックアップファイルも大きくなります。

この動作は完全バックアップを取得しないと DCM がクリアされないためです。

差分バックアップの取得対象


ページ 1 エクステント

ページヘッダー











テーブル 1 ページ 8 データ行 3 を更新

差分バックアップの取得対象はページ 1 が含まれるエクステント全体

バックアップの基本動作を確認


バックアップ前後のログの蓄積と差分バックアップの動作を確認してみます。

某都市伝説をご存知でしょうか？？


以下抜粋

Kさんはタクシーを飛ばし、さっそくサーバールームで調査を開始する。原因はデータベース・サーバーが障害で停止していた。大至急データベースを復旧させシステムを再始動させなければならないが、この時、Kさんの顔が青ざめる。障害時の復旧をおこなうためのログファイルが肥大化し、ディスクが一杯になっていた。「しまった!気付かないうちにこんなにログが肥大化しているなんて...」さらに最悪なことにそのログファイルが壊れていた。データベース・サーバー停止の原因はこれである。

ログファイルが壊れるとデータの復旧ができない。毎日夜中にバックアップを取っていたが、データはバックアップした状態、すなわち昨日の夜の時点に戻ってしまう。ユーザーがショッピングサイト上で行っていた直近の購入情報が損失してしまうのだ。

なるほど、ログファイルが壊れるとデータの復旧ができないデータベースがあるんですね。

時間があった時の追加デモ


ログファイルを壊してデータ復旧に挑戦

まとめ


SQL Server 2005 以降は各種情報を見るための手段が提供されているため、何かアクションを起こした際にどのような挙動が発生しているのかを確認しやすくなっています。

今回のセッションの内容で SQL Server にさらに興味を持っていただけると幸いです。

Documents

Db 友の会 第1回 sql server 勉強会資料

Db 友の会第1回 sql server 勉強会資料