SQL Server 2000 コマンドラインツール

bcp	データコピー
console	データベースバックアップ ／ 復元時のメッセージ表示
dtsrun	DTS パッケージの実行
dtswiz	DTS インポート ／ エクスポートウィザードの起動
isql	SQL Server 6.5 レベルのコマンドライン操作
isqlw	クエリアナライザの起動
itwiz	インデックスチューニングウィザードの起動
makepipe	名前付きパイプの整合性チェック （※）
odbccmpt	ODBC アプリケーションの互換性オプションの有効化 ／ 無効化
odbcping	ODBC データソースの整合性、クライアントの接続性検査 （※）
osql	コマンドライン操作
readpipe	名前付きパイプの整合性チェック （※）
scm	SQL Server 2000 サービスの作成、変更、開始、停止
sqlagent	SQL Server エージェントの起動
sqldiag	各種診断情報の収集
sqlmaint	データベースの保守支援 （トランザクションログバックアップ、インデックス再構築等）
sqlservr	SQL Server サービスの起動
sqlftwiz	フルテキストインデックス作成ウィザードの起動
vswitch	アクティブ SQL Server の切り替え

（※）は既定でインストールされない
	→	CD Drive¥x86¥Binn

更新可能な分散パーティションビューの要件

・	ビューの中で複数回参照されるテーブルがない
・	ビューを構成する SELECT 文の選択リスト内に、複数回参照される列がない
・	ビューを構成する各 SELECT 文の選択リストはすべて同じ順序、同じ型（データ型、精度、スケール、collation）である
・	各テーブルの CHECK 制約のキーレンジは重複しない
・	パーティション化列には、DEFAULT、TIMESTAMP、IDENTITY 属性は定義できない
・	ビューに WITH CHECK トリガ、または INSTEAD OF トリガは定義できない
・	パーティション化列は更新できない
	→	この列が分散パーティション間をデータが移動しないことを保証
		明示的な移動を行うには DELETE + INSERT の操作が必要

分散パーティションビューのクエリ処理

・	クエリプロセッサはデータがどのように共存するかを CHECK 制約により理解
	−	クエリオプティマイザは条件句から検索対照のテーブルを判断
	−	メンバテーブルに CHECK 制約があることにより実現
・	CHECK 制約がない場合は、すべてのメンバーテーブルが検索対象
・	プランはデータがパーティション間にどのように分散するかを踏まえて生成
・	パーティションはコンパイル時には考慮されず、実行時に必要に応じて考慮
	→	不必要な処理が実行されないことを保証

分散パーティションビューの実装手順

1.	メンバテーブルの作成
	−	各サーバーに水平分割されたテーブルを作成
		※ メンバテーブルは同一の論理設計
2.	リンクサーバーの設定
	−	分散パーティションビューを介した分散クエリを実行するための設定
3.	分散パーティションビューの作成
	−	UNION を使用して複数テーブルを結合
※	SQL Server 同士のみで実装可

分散パーティションビューの概要

	−	テーブルを水平分割 ⇔ 垂直分割ビュー
	−	SQL Server 2000 よりサポート
・	スケールアウト
	−	大きなテーブルを複数のサーバー上の小さなメンバテーブルに分割
	−	処理の負荷を複数サーバーに分散
・	可用性に悪影響
・	ビューを介して分散した複数のサイトに存在するテーブルに対する INSERT、UPDATE、DELETE を透過的に実行
		→ クライアントからは1つのサーバーのように見える
		→ アプリケーションはデータのある場所を意識しない
	−	クラスタのすべてのノードは共通の分散パーティションビューを持つ
・	分散パーティションビューの更新には INSTEAD OF トリガを使用
・	SQL Server 2000 Enterprise Edition のみ

レプリケーションにおけるログ配布

レプリケーションはスイッチ後自動的に新しいプライマリサーバーを使用

高可用性レポーティングサーバー

・	スタンバイサーバーをレポーティングとして使用、プライマリサーバーは次回のレポーティングデータベースを準備
・	予定日の動作
	−	プライマリはスタンバイにバックアップ、新規接続を処理
	−	既存の接続切断後、スタンバイはロールフォワード、リカバリ
	−	スタンバイは更新

ログバックアップにおけるフェールバック

・	データベースのリストアは不要　→ NORECOVERY または STANDBY
・	配布先サーバーでとられたログバックアップは元ソースサーバーで適用
・	計画されたフェールオーバーに役立つ
・	完全には自動化されない
	→ 新しいソースサーバーでログ配布のセットアップを実行する必要あり

ログ配布設計

・	プライマリサーバーとスタンバイサーバーのサブネットは別にする
・	プライマリサーバーとスタンバイサーバーは別配線から電源供給

サーバーの役割（ロール）変更

・	監視サーバー、または配布先サーバーで実行
・	新しいソースサーバーでピックアップされた配布先サーバーは継続
・	監視サーバーはクリティカルなコンポーネント
	→	フォールトトレラントにする
	→	監視サーバーがダウンしている場合は配布先サーバーで役割の変更を行う
・	手順
	1.	ログインをコピーする DTS パッケージの作成
		−	DTSデザイナのログイン転送タスクを使用して sysxlogin のバックアップをコピー
		※	データベースユーザーは自動的にコピーされるがログインアカウントは手動コピーが必要
	2.	ロール変更の実行 → 手動操作
		(1)	sp_change_primary_role 'データベース名', final_state=3
			→ 現プライマリサーバーで実行
			最後のバックアップを行い、プライマリサーバーを読み取り専用にする
			※ final_state … データベース復旧状態
			1 RECOVERY 2 NO RECOVERY 3 STANDBY
		(2)	sp_change_secondary_role 'データベース名' → 現セカンダリサーバーで実行
			最後のバックアップログのコピー、復元を行い、セカンダリサーバーを変更可にする
			※ 計画的に実行する場合は (1) → (2) と実行
			障害発生時等は (2) のみ実行
			‥sp_change_monitor_role → 監視サーバー上で実行
			役割変更通知確認、情報更新
			‥sp_resolve_logins → 変更後の新プライマリサーバーで実行
			データベースユーザーとログインアカウントの対応関係の確認、更新
・	ロール変更後のクライアントの接続性
	※	切り替えはクライアントから見て自然に行われるべき
		→	クライアント側に切り替えを確認させる何らかの仕組みが必要
	A.	ODBC DSN を使用してアプリケーションを再指定 → ODBC 接続を複数作っておく
	B.	ネットワーク負荷分散 （NLB） を使用して変更されたサーバー名を選択
		※	障害発生時、クライアント接続は自動切換え、SQL Server はログ配布で手動切り替え
	C.	セカンダリサーバーの名前とIPアドレスをプライマリサーバーと同じに変更（要再起動）
		※	SQL Server が仮想サーバーとして構成されている場合は不可能 → 要クラスタ再インストール
	D.	新しいサーバーを指定するよう DNS を再構成 → 要キャッシュクリア
	※	A. か B. が簡単？

ログ配布の構成

	〔0〕 データベースをプライマリからセカンダリへバックアップ／復元
		※ 通常オフラインで実行
	プライマリサーバー （プロダクション） データベースログファイル （*.ldf）                                        ↓〔1〕 定期的にバックアップ （既定で15分間隔） → 低コスト トランザクションログバックアップ                                                                  ↓〔2〕 ネットワーク経由で定期的にコピー （既定で 15 分間隔）                                   ↓　※ セカンダリ側が実行 セカンダリサーバー バックアップファイルのコピー                                        ↓〔3〕 復元適用 → 同じデータベース内容になる データベースログファイル （*.ldf）

・	いずれのイベントでも SQL Server エージェントサービスが必要
	→	サービスアカウントはプライマリ／セカンダリサーバーの両方で適切な権限を持たせる
・	必須フォルダ
	プライマリサーバー内 ログバックアップ先フォルダ （A）   → セカンダリからアクセス可能な共有フォルダとして構成 セカンダリサーバー内 ログコピー先フォルダ （B）
	※	プライマリ／セカンダリ切り替え時や相互配布時には双方に A、B が必須 （フォルダが2つずつ必要）
・	バックアップ + コピーの時間差は既定で最大 30 分（15 分 + 15 分）
	※	ログ配布時にセカンダリ側で復旧完了状態を STANDBY に設定することが可能
		→ データ分析等で利用価値あり
・	ログファイル名はタイムスタンプを含めてひとつずつ異なる名前が付けられる

ログ配布の自動化

・	データベース保守計画によりセットアップが容易
	−	データベース保守計画ウィザードを使って1つのデータベースログ配布動作をまとめて設定
	⇒	［データベースの選択］画面で［トランザクションログを他の SQL Server に配布 （ログ配布）］オプションを有効にする
	−	［配布先データベースの追加］
		‥	配布先サーバーとして指定できるサーバーは Enterprise Manager に登録されたサーバー
		［出力先データベース］ ［データベースの新規作成と追加］ 手順〔0〕を最初に行う ［既存データベースを使用 （初期化なし）］ 手順〔0〕を行わない → 手動実行 「データベース読込状態」 ［復旧モード以外］ データベース使用不可 （NORECOVERY） ［スタンバイモード］ 読み取り専用 （STANDBY） → データ分析等で使用可 ［データベースのユーザーを終了する］ 有効 データベースにアクセスしているアプリケーションを自動切断 → データ分析等での使用には不向き？ 無効 データベースアクセスが存在するとき、復元作業は待ち状態になる → ログ配布が中断 ［データベースがプライマリロールを想定することを許可する］ 有効 フェールオーバー時の役割変更引き受け先として指定 → ログバックアップ（配置）先共有フォルダを指定
	−	ウィザードで設定できる項目
		バックアップスケジュール 手順 1. 既定 15 分 コピー／読み込みの頻度 手順〔2〕〜〔3〕 既定 15 分 読み込みの遅延 手順〔1〕から〔2〕に移る間隔 既定 0 分 → ログを即座に復元 ログ配布のしきい値 同期間隔のしきい値（しきい値を超える時間経つと警告）等   監視サーバーの設定
	−	ログ配布設定ユーザーは sysadmin ロールのメンバー
	−	一度に1つのデータベースのみ設定可 → 複数データベース選択時はオプション無効
	※	保守計画ウィザードは大規模環境だと融通が利かない？
・	モニタにより管理が容易
	−	状態を追跡
	−	リソースサーバー／配布先サーバー間の役割変更が容易
	−	Enterprise Manager からリモート管理
	※	リソースサーバー／配布先サーバーとは別に監視サーバーを設置
		−	SQL Server 2000 が入っているサーバーであればどれでも可 → 通常はセカンダリサーバー
・	柔軟性

ログ配布の概要

・	ウォームスタンバイソリューション
・	プライマリサーバーと別個にセカンダリ（バックアップ）サーバーを待機、障害発生等でプライマリサーバーが利用できなくなったときにセカンダリサーバーへ切り替えて稼動
・	プライマリサーバーのトランザクションログを自動バックアップ、セカンダリサーバーへ適用 （リストアを自動実行） → 自動更新
	※	データベース復旧モデルは完全モデル
・	定期的にログバックアップとネットワークコピーを行う
・	プライマリサーバーからのトランザクションバックアップをセカンダリサーバーに適用
	→	一般的に 1 〜 15 分間隔でスケジューリング
・	スペックがあれば物理的距離に依存しない
・	スタンバイサーバーの数に制限なし （NLB 使用時は最大 32）
・	サーバーのリモートバックアップに使える
・	スタンバイサーバーは読み取り専用で利用可能 → サーバーの負荷分散、データ分析等に使用可
	※	ログ復元時は読み取り不可
・	相互配布も可能
・	データベース単位で配布 → 分割されたデータや一部変更データの配布は不可
		→ レプリケーションで実現
・	トランザクションログにロギングされたすべてのスキーマとデータ変更が適用
・	システムデータベースおよびユーザーはログ配布不可
・	ログ配布先はディスクのみ → テープへのバックアップオプションは利用不可
・	手動障害検出、手動フェールオーバー
	※	SQL Server 自体には自動障害検出機能なし → サードパーティ製品
	→	より可用性を求める場合はクラスタリングが最適
・	SQL Server 2000 Enterprise Edition のみ
	※	ウィザードによる設定の可否を指す
		手動での構築であれば SQL Server 7.0 （全エディション）/2000 Standard Edition でも運用可
・	サーバーライセンスは2つ以上必要

フェールオーバークラスタリング構成時の考慮点

・	MS DTC のクラスタ対応
	−	SQL Server インストール前にクラスタを設定、各ノード上でクラスタウィザード（Comclust.exe）を実行
・	レプリケーションにクラスタファイル共有を使用する場合
	−	スナップショットフォルダとして MSCS クラスタ共有ファイルを使用
・	セキュリティ
	−	ドメインアカウントが必要 ＝ Active Directry ドメイン環境が必須
・	CPU
	−	ノード間で CPU の数を合わせる必要はない　ただし数が異なる場合はパフォーマンスに影響
・	メモリ
	−	4GB 以上のとき（AWE API 使用時 → 未使用時とメモリ管理方法が異なる）
		‥	ノード間で物理メモリ容量を合わせる
		‥	全インスタンスの max server memory 設定合計値を全仮想サーバーの物理メモリの最小サイズよりも小さくする
		※	AWE 未使用時（4GB 以下のとき）はノード間で容量が異なっていても可

フェールオーバークラスタリングの実装

・	Windows クラスタが構成されているサーバー上で SQL Server をクラスタにインストール
	−	SQL Server インストールウィザード上で「仮想サーバー」を選択
		※	Windows クラスタが構成されていないと選択できない
		※	通常にインストールするとクラスタ外にインストール
		※	仮想サーバー名も登録 → インストール後は変更不可
		※	クラスタサーバーは1台でもインストール可
・	クォーラムディスクには SQL Server を入れないことを推奨
	−	プログラムはローカルディスクへインストール （二重化）
	−	データファイル（システムデータベース、ユーザーデータベース）は共有ディスクへインストール
		（非二重化）
・	ディスク管理およびネットワークは OS が管理

アプリケーション設計時の考慮点

・	クラスタ認識アプリケーションの作成
・	クライアントは障害時に一度切断後すぐに再接続　→ アプリケーション側にも障害認識対策が必要
	→	同じサーバー／ IP アドレスに接続
・	残りのクラスタメンバが障害を検地しフェールオーバーを行っている間はユーザー接続不可
・	フェールオーバー時のクライアントへの通知手段の考慮
	−	フェールオーバーはクライアントにはネットワーク障害と同じように見える
		→	アプリケーション側でカスタムメッセージの表示、再接続を試みる等の設定が必要

フェールオーバー構成

・	アクティブ − パッシブ構成
	−	プライマリノードの SQL Server 1 つのみが動作、セカンダリノードはフェールオーバーまではアイドル状態 （利用不可）
	−	仮想サーバーは1つのみ
	−	アプリケーションライセンスは1つで済む
・	アクティブ − アクティブ構成
	−	SQL Server はクラスタの両サーバーで同時動作
	−	仮想サーバーは2つ
	−	お互いがそれぞれ独立 （ロードバランシングやデータ共有はなし）
	−	それぞれにお互いのグループをフェールオーバーする能力が必要
	−	3本以上のディスクが必要
	−	フェールオーバー時に多少パフォーマンス低下
	−	アプリケーションライセンスは2つ必要
・	ハイブリッド構成
	−	アクティブ − パッシブ構成を基本に、クラスタ外でスタンバイを必要としないサービスを提供
		例）	クラスタ上で本番用 SQL Server を稼動
			クラスタ外でテスト用または開発用の SQL Server を稼動
			→ フェールオーバー時は停止
・	4ノードクラスタ
	−	アクティブ − アクティブ − アクティブ − アクティブ
	−	Windows 2000 Datacenter Server + SQL Server 2000 Enterprise Edition

フェールオーバー機能の強化点

・	SQL Server Setup により双方のサーバーに同時インストール／アンインストール
	※	SQL Server 7.0 では別インストール
	※	要同時再起動
・	サービスパックは直接仮想サーバーに適用
・	すべてのノードに SQL Server のツールと実行可能ファイルのローカルコピーを配置
	※	SQL Server 7.0 ではプログラムも共有ドライブに配置
・	セットアップを再実行すると、フェールオーバークラスタリングの構成を更新できる
		例）クラスタ上の SQL Server の再インストール等
・	フェールオーバーとフェールバックがクラスタ内の任意のノード間で行われる
	※	フェールバック：障害復旧後にフェールオーバー前のノードに戻すこと
		→ Windows クラスタのデフォルトでは禁止
・	マルチ IP アドレスサポート
・	Windows 2000 Datacenter Server （4 ノードクラスタ） をサポート
	※	SQL Server 7.0 までは 2 ノードまでサポート
・	クラスタ内でのフルテキスト検索可
・	ノードの追加／削除が容易
・	サーバーのハードウェア構成を考慮（ バックアップデバイスの有無等）

フェールオーバー時の動作

・	OS チェック
	−	ノードと仮想サーバーの可用性を内部ネットワーク内でハードビートチェック （障害感知）
・	SQL Server チェック
	−	LooksAlive チェックが 5 秒おきに動作 （サービス動作確認）
	−	OS （クラスタサービス） による IsAlive チェックが SELECT @@SERVERNAME クエリを1分おきに実行
	※	間隔時間設定可能
		⇒ クラスタアドミニストレータ → SQL Server のプロパティ
・	他のノードへのフェールオーバー
	−	Windows クラスタが自ノードを再起動、問題があれば他ノードへのフェールオーバーを試行
	−	SQL Server サービスを開始
	−	master データベースをオンラインにする
	−	自動復旧プロセスが動作
	−	クライアントアプリケーションは要再接続

フェールオーバークラスタリングの概要

※	以下 SQL Server 2000 におけるフェールオーバークラスタリング
	←	SQL Server 7.0 ではクラスタ管理 GUI ツールが不十分
・	Microsoft Cluster Server 1.0 上に構成
	−	Windows NT Server 4.0 Enterprise Edition
			（Clustering Services：MSCS を使用、最大 2 ノード）
	−	Windows 2000 Advanced Server（最大 2 ノード）／Datacenter Server（同 4 ノード）
	−	Windows Server 2003 Enterprise Edition／Datacenter Edition（ともに最大 8 ノード）
・	ハードウェア互換リスト （HCL） のクラスタカテゴリにあるハードウェアが必要
	→	ベンダサポートの共有 HDD … SCSI またはファイバーチャネル接続
・	SQL Server 2000 Enterprise Edition でサポート
	−	自動的にインストールされている MSCS を検出
		→	セットアップとは別の「クラスタウィザード」の実行は不要
・	ホットスタンバイソリューション
・	高可用性のためのソリューション
	−	冗長システム
	−	共有ディスク型クラスタ
			最低 2 台、最大 4 台で 1 台に実装
	−	障害回復にかかる時間は数秒
	−	自動障害検出、自動フェールオーバー
	−	クライアントアプリケーションへの影響は最小限
・	Windows クラスタサーバー上に構築
	−	ディスクは全サーバーに接続
	−	アプリケーションおよび論理ドライブなどのリソースは結合されてリソースグループを構成、1つのノードに割り当て
		※	1リソースグループごとに1つの仮想サーバーを構成
		※	プライマリノード：既定でリソースがアクセスされるノード
・	共有ディスク内に SQL Server データベースを構築 → 仮想サーバーに構成
	−	フェールオーバークラスタウィザードを使用して構成
	−	通常はどちらか一方のノードが保有
	−	一方のノードに SQL Server を構築すれば、もう一方のノードにも構築 ← 内部ネットワークを経由
	−	ノードの切り離しも SQL Server から可能 → セットアップオプション
	※	サーバーの二重化によりサーバーの可用性は向上
		ただしデータベースは二重化されないため、データベースの可用性は向上しない
		→	データベースの二重化にはハードウェア RAID を利用
・	サーバー／トランザクションリカバリは自動
	−	データとトランザクションログファイルはフェールオーバー
	−	障害からのリカバリは、通常のサーバーの再起動と同じように見える