2005年10月27日

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
posted by w@ko at 18:26|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

2005年10月24日

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

ビューの中で複数回参照されるテーブルがない
ビューを構成する SELECT 文の選択リスト内に、複数回参照される列がない

 
ビューを構成する各 SELECT 文の選択リストはすべて同じ順序、同じ型(データ型、精度、スケール、collation)である
各テーブルの CHECK 制約のキーレンジは重複しない
パーティション化列には、DEFAULT、TIMESTAMP、IDENTITY 属性は定義できない
ビューに WITH CHECK トリガ、または INSTEAD OF トリガは定義できない
パーティション化列は更新できない
  この列が分散パーティション間をデータが移動しないことを保証
      明示的な移動を行うには DELETE + INSERT の操作が必要
posted by w@ko at 18:57|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

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

クエリプロセッサはデータがどのように共存するかを CHECK 制約により理解
  クエリオプティマイザは条件句から検索対照のテーブルを判断
  メンバテーブルに CHECK 制約があることにより実現
CHECK 制約がない場合は、すべてのメンバーテーブルが検索対象
プランはデータがパーティション間にどのように分散するかを踏まえて生成
パーティションはコンパイル時には考慮されず、実行時に必要に応じて考慮
  不必要な処理が実行されないことを保証
posted by w@ko at 18:56|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

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

1. メンバテーブルの作成
  各サーバーに水平分割されたテーブルを作成
    ※ メンバテーブルは同一の論理設計
 
2. リンクサーバーの設定
  分散パーティションビューを介した分散クエリを実行するための設定
 
3. 分散パーティションビューの作成
  UNION を使用して複数テーブルを結合
 
SQL Server 同士のみで実装可
posted by w@ko at 18:56|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

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

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

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

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

posted by w@ko at 18:55|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

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


 
スタンバイサーバーをレポーティングとして使用、プライマリサーバーは次回のレポーティングデータベースを準備
予定日の動作
  プライマリはスタンバイにバックアップ、新規接続を処理
  既存の接続切断後、スタンバイはロールフォワード、リカバリ
  スタンバイは更新
posted by w@ko at 18:54|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

2005年10月20日

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

データベースのリストアは不要 → NORECOVERY または STANDBY
配布先サーバーでとられたログバックアップは元ソースサーバーで適用
計画されたフェールオーバーに役立つ
完全には自動化されない
  → 新しいソースサーバーでログ配布のセットアップを実行する必要あり
posted by w@ko at 19:28|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

ログ配布設計

プライマリサーバーとスタンバイサーバーのサブネットは別にする
プライマリサーバーとスタンバイサーバーは別配線から電源供給
posted by w@ko at 19:27|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

サーバーの役割(ロール)変更

監視サーバー、または配布先サーバーで実行
 
新しいソースサーバーでピックアップされた配布先サーバーは継続
 
監視サーバーはクリティカルなコンポーネント
  フォールトトレラントにする
  監視サーバーがダウンしている場合は配布先サーバーで役割の変更を行う
 
手順
  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. が簡単?
posted by w@ko at 19:27|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

ログ配布の構成

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

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

ログ配布の自動化

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

ログ配布の概要

ウォームスタンバイソリューション

 
プライマリサーバーと別個にセカンダリ(バックアップ)サーバーを待機、障害発生等でプライマリサーバーが利用できなくなったときにセカンダリサーバーへ切り替えて稼動

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

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

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

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

Windows クラスタが構成されているサーバー上で SQL Server をクラスタにインストール
  SQL Server インストールウィザード上で「仮想サーバー」を選択
    Windows クラスタが構成されていないと選択できない
    通常にインストールするとクラスタ外にインストール
    仮想サーバー名も登録 → インストール後は変更不可
    クラスタサーバーは1台でもインストール可
 
クォーラムディスクには SQL Server を入れないことを推奨
  プログラムはローカルディスクへインストール (二重化)
  データファイル(システムデータベース、ユーザーデータベース)は共有ディスクへインストール
      (非二重化)
 
ディスク管理およびネットワークは OS が管理
posted by w@ko at 19:25|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

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

クラスタ認識アプリケーションの作成
 
クライアントは障害時に一度切断後すぐに再接続 → アプリケーション側にも障害認識対策が必要
  同じサーバー/ IP アドレスに接続
 
残りのクラスタメンバが障害を検地しフェールオーバーを行っている間はユーザー接続不可
 
フェールオーバー時のクライアントへの通知手段の考慮
  フェールオーバーはクライアントにはネットワーク障害と同じように見える
    アプリケーション側でカスタムメッセージの表示、再接続を試みる等の設定が必要
posted by w@ko at 19:24|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

フェールオーバー構成

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

2005年10月19日

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

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 ノードまでサポート
 
クラスタ内でのフルテキスト検索可
 
ノードの追加/削除が容易
 
サーバーのハードウェア構成を考慮( バックアップデバイスの有無等)
posted by w@ko at 18:24|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

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

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

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

以下 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 を利用
 
サーバー/トランザクションリカバリは自動
  データとトランザクションログファイルはフェールオーバー
  障害からのリカバリは、通常のサーバーの再起動と同じように見える
posted by w@ko at 18:23|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

広告


この広告は60日以上更新がないブログに表示がされております。

以下のいずれかの方法で非表示にすることが可能です。

・記事の投稿、編集をおこなう
・マイブログの【設定】 > 【広告設定】 より、「60日間更新が無い場合」 の 「広告を表示しない」にチェックを入れて保存する。


×

この広告は1年以上新しい記事の投稿がないブログに表示されております。