2005年10月19日

スタンバイソリューションの組み合わせ

フェールオーバークラスタリング + ログ配布
  フェールオーバーでサーバーの可用性を高め、ログ配布でデータの可用性を高める
  最高の可用性を実現
 
フェールオーバークラスタリング + レプリケーション
  複数の Web サイトにレプリケーションでデータを配布、元データのサーバーをフェールオーバーで守る
 
ネットワーク負荷分散 + ログ配布
  ネットワーク負荷分散によりログ配布しているサーバーにユーザー要求を切り替え
posted by w@ko at 18:22|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

スタンバイオプション実現ソリューション

ホットスタンバイ フェールオーバークラスタリング
ウォームスタンバイ データベースの復元 ログ配布
データベースの複製 トランザクションレプリケーション
posted by w@ko at 18:22|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

スタンバイオプション比較

ホットスタンバイ
プライマリサーバーのデータのコピーをセカンダリノードに保持
セカンダリノードが、トランザクションに整合性があるプライマリサーバーのデータの完全コピーを提供
コミット済みのトランザクションは障害復旧後もコミット
障害検出とフェールオーバーは自動的に行われる ← 管理者の手を介さない
 
ウォームスタンバイ
プライマリサーバーのデータのコピーをセカンダリノードに保持
データがプライマリノードとセカンダリノードの両方に同時コミット、または非コミット
  時間的遅延が存在、整合性は完全ではない
障害検出とフェールオーバーは非自動的
  管理者が手動で行う、またはサードパーティ製品を使用して実現
 
コールドスタンバイ
データを復元できるサーバーを別途用意
適切な OS、ソフトウェア、バックアップが必要
時間的遅延が大きくなる可能性あり
posted by w@ko at 18:21|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

可用性の最大化

プレゼンテーション層
  Windows アプリケーション、Web ベースアプリケーション
  Web ファーム ← Microsoft Application Center が提供する負荷分散 (NLB/CLB) を享受
 
ビジネス層
  コンポーネント負荷分散 (CLB) ← AC
  キューコンポーネント ← MSMQ
 
データ層
  RAID
  レプリケーション
  フェールオーバークラスタリング
  スタンバイサーバー ← ログ配布
posted by w@ko at 18:21|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

可用性とスケーラビリティ

スケールアップ (同時ユーザー要求数を増やす → 可用性の向上なし)
  RAM 増設
  マルチプロセシング
 
スケールアウト (負荷分散 → 可用性向上)
  レプリケーション
  読み取り専用スタンバイサーバー ← ログ配布
  連合サーバー (分散パーティションビュー使用:可用性に悪影響)
posted by w@ko at 18:20|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

可用性要件の決定

稼働時間
  営業時間のみ or 常時
 
接続性要件
  オンライン or オフライン
 
密結合と疎結合
  同期 or 非同期 → MSMQ (Microsoft Message Quere Server) の利用など
posted by w@ko at 18:20|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

データ配布の考慮事項

○ データ配布方法の比較
レプリケーション
  転送元データベースから別サーバーの転送先データベースに最新のデータを複製
  サイトの自律性サポート
  サイトのオフライン状態可 → スケーラビリティ向上
分散トランザクション (2 フェーズコミット使用、MS DTC で実現)
  分散トランザクションに含まれる全サーバー間でデータを同期
  サーバーごとの自律性なし
  全サーバーが常時オンラインである必要あり → スケーラビリティ低下

○ データ配布方法の決定要因
タイミング/遅延
サイトの自律性
トランザクションの一貫性

○ データ配布方法の選択


 
 
 
 
 
 
 
 
 

(低自律性、遅延時間小)
・分散トランザクション
・即時更新/キュー更新サブスクライバを許可するトランザクションレプリケーション
  − レプリケーション+分散トランザクション
・トランザクションレプリケーション
・即時更新/キュー更新サブスクライバを許可するスナップショットレプリケーション
  − データレプリケーションは定期的
・スナップショットレプリケーション
・マージレプリケーション
  − トランザクションの順序は維持されない
(高自律性、遅延時間多)
即時更新サブスクライバ
  サブスクライバ側は 2 フェーズコミットによりパブリッシャを更新
  他のサイトはパブリッシャから更新結果を受け取り
  データの競合なし ← DTC が各サイトのデータを自動的に更新
キュー更新サブスクライバ
  サブスクライバが更新データをキューに格納
  トランザクションはパブリッシャ側で非同期更新
posted by w@ko at 18:18|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

2005年10月06日

分散データの必要性

データをユーザーの近くに配置
サイトの自律性
OLTP と OLAP アプリケーションとの分離
競合の削減
posted by w@ko at 19:22|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

スタンバイソリューションとしてのトランザクションレプリケーション

本来は可用性目的ではなく分散利用目的のためのスケールアウトソリューション
  フェールオーバークラスタリングとログ配布の検討後
 
ウォームスタンバイソリューション
スタンバイサーバー ≠ プライマリサーバー
一部ユーザースキーマとシステムデータは複製されない
データのトランザクションが最新ではない可能性あり
マージレプリケーションはトランザクションに整合性(参照整合性等)なし
スタンバイサーバーでは変更も可 → 整合性はアプリケーションで調整
データ分割(テーブル単位でのコピー)が可能
手動障害検出、手動フェールオーバー
定期的に終了しないでデータに対してアクセス可
  データ分析にはログ配布より向いている
ユーザーからはシームレスにアクセスしているかのように感じられる
レプリケーション先は SQL Server 以外のデータベースでも可 (ただしパフォーマンスは低下)
posted by w@ko at 19:21|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

テーブルの水平分割

データベース内の各テーブルを水平分割して複数のサイトに配置
  パーティション … 分割されたデータの単位
 
テーブルを対称的に分割できる場合に最も効果的に働く
  関連するデータが同じメンバーサーバーに配置される場合
  データがメンバーサーバー間で一様に分割される場合
 
 
なるべくクエリ結果の多くのデータをローカルサーバーに配置するようにし、他のサーバー上にあるデータの要求を最小限にする
 
CHECK 制約を使用してパーティションの整合性を定義、適用
posted by w@ko at 19:21|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

物理レプリケーションモデル

集中パブリッシャ
集中サブスクライバ/マルチパブリッシャ
  − データに対して水平フィルタをかけることが可能 → テーブルの水平分割
マルチサブスクライバ/マルチパブリッシャ
posted by w@ko at 19:20|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

レプリケーションの種類

  → レプリケーション対象データのログエントリをディストリビューションデータベースにコピー
スナップショットレプリケーション
  テーブル単位でデータをレプリケート
  データの更新頻度が高くない環境
  サブスクライバで読み取り専用データが必要な環境
  長い遅延が許容できる環境
  サブスクライバでサイト自律性が必要な環境
  スナップショットエージェント → スナップショット実行
      スナップショット更新頻度を設定
  ディストリビューションエージェント → スナップショットをサブスクライバに適用
      スナップショットをサブスクライバに適用する頻度を設定
  即時更新とキュー更新をサポート
 
トランザクションレプリケーション
  トランザクションログ単位でデータをレプリケート
  ログリーダーエージェント
   
  ディストリビューションエージェント → レプリケートされたトランザクションをサブスクライバに適用
  データ変更を最小の遅延で受け取る必要がある環境
  即時更新とキュー更新をサポート
 
マージレプリケーション
  マージエージェント → 競合発生時に競合回避モジュールを起動
    既定の回避モジュールでは優先順位に基づいた解決を行う
    カスタム回避モジュールでは、競合解決のための特定データまたはビジネス上の意志決定ルールを実装
      ストアドプロシージャまたは COM オブジェクトとして構築
    Microsoft レプリケーション競合表示モジュールで競合の表示可
  サブスクライバが逐一更新したデータをパブリッシャ/他サブスクライバに伝達する必要のある環境
  サブスクライバがオフラインでデータ更新、同期を行う環境
 
 
データが複数のサイトで更新されても(フィルタリングやユーザーアプリケーションの使用を通して)競合は少ないと予想される環境

○ マージレプリケーション使用時の考慮事項
スキーマの変更
  レプリケートされるテーブル内の行ごとに識別用の一意な列を作成
  データ追跡、効率的同期、競合検出、解決、レポートのためにいくつかのシステムテーブルを作成
  各行の変更を追跡するトリガをパブリッシャおよびサブスクライバのテーブル上に作成
    テーブル上の変更をキャプチャ、変更をマージシステムテーブルに記録
    マージレプリケーショントリガはアプリケーション定義トリガに干渉しない
競合の解決
  行に対するすべての更新を追跡
    MSmerge_contents テーブルの lineage 列が行変更ヒストリを保持
    競合の検出は行レベルまたは列レベルで実行
 
 
受信データ値と現在のデータ値を評価、データ競合時は割り当てられた優先順位に基づいて競合解決を行う
  データ値は同期が発生したときだけ他のサイトにレプリケート
    同期は分単位/日単位/週単位で実行
  トリガをカスタマイズして独自競合解決方法も定義可

○ 即時更新とキュー更新
即時更新 … 変更をパブリッシャに即時反映
キュー更新 … 変更はキューに登録、パブリッシャに反映 → オフラインでもデータ更新可
  事前にパブリケーション(レプリケーションの単位)に対し以下のオプションを設定
    パブリッシャ側の変更を保持
    サブスクライバ側の変更を保持
    サブスクリプション(レプリケーション定義順序)を再初期化
posted by w@ko at 19:20|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

レプリケーションエージェント

  それぞれカスタマイズ可能な SQL Server エージェントジョブとして実装
 
スナップショットエージェント
  ディストリビュータの SQL Server エージェント下で実行
  初期スナップショットを準備し、ディストリビュータのディストリビューションデータベースに格納
 
ディストリビューションエージェント
  プッシュサブスクリプションではディストリビュータ、プルサブスクリプションではサブスクライバで実行
  スナップショット/トランザクションレプリケーションで使用
  ディストリビューションデータベースに保持されたデータをサブスクライバへ移動
 
ログリーダーエージェント
  トランザクションレプリケーションで使用
 
 
レプリケートするトランザクションを検索、パブリッシャ上のトランザクションログからディストリビュータ上のディストリビューションデータベースへデータをコピー
  各ディストリビューションデータベースで独自のログリーダーエージェントを保持
 
マージエージェント
  マージレプリケーションで使用
  サブスクライバに初期スナップショットを適用、その後の増分データの変更を移動、一致させる
  データ競合発生時に競合回避を行う
  プッシュサブスクリプションではディストリビュータ、プルサブスクリプションではサブスクライバで実行
  双方向マージでは複数サイトからの変更のマージを行う
 
キューリーダーエージェント
  キューからメッセージを受け取り、適切なパブリケーションに適用
 
 
キュー更新オプションを設定した(またはキュー更新をフェールオーバーとする即時更新)レプリケーションで使用
  ディストリビュータで実行されるマルチスレッドエージェント
  1つのインスタンスのみ → 所定のディストリビュータ用全パブリッシャ/パブリケーションに対応
 

 
Enterprise Manager → [レプリケーションモニタ] → [その他のエージェント]で表示されるクリーンアップエージェントでレプリケーションの保守を行う
posted by w@ko at 19:20|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

サブスクリプションの方法

プッシュサブスクリプション
  サブスクリプションはパブリッシャで定義
  各パブリケーションに対して複数のサブスクリプションを1回で設定可 → 管理の集中化
  変更発生時に変更内容をサブスクライバへ即時送信する必要のあるアプリケーションで使用する場合
  高いセキュリティを必要とする場合
  ディストリビュータに負荷がかかってもパフォーマンスに影響しない場合
 
プルサブスクリプション
  サブスクライバがサブスクリプションを開始
 
 
サブスクライバがサブスクリプションとして登録されているか匿名サブスクリプションが許可されている場合に有効
 
 
異種 OLE DB 対応サブスクライバの場合はディストリビューションコントロールのあるアプリケーションを作成する必要あり
  サブスクライバのシステム管理者またはデータベース所有者が受信パブリケーションとスケジュールを決定
  セキュリティが低い場合 (Web 環境等)
  多数のサブスクライバをサポートする場合
posted by w@ko at 19:19|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

インデックスの並列作成処理

インデックス作成時、キー値のスキャンとソートに並列マルチスレッドオペレーションを使用可

 
実行に使用するスレッドの数は、SELECT、UPDATE、INSERT 等その他の Transact-SQL 実行時と同じアルゴリズムを使用して決定
【参照】 SQL Server 2000 Books Online 「並列操作によるインデックス作成」
posted by w@ko at 19:19|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

チェックサムインデックス

CHECKSUM 関数 → チェックサムインデックス作成時に使用 (キー値とは別)
  ハッシュ値を計算
 
CHECKSUM 列上にインデックスを作成
 
大きなサイズの値を持つ列に直接インデックスを作成するよりも効果的
    小さな値として構成 → 領域消費を抑え、検索が効率化
posted by w@ko at 19:18|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

インデックス付きビュー

SQL Server 2000 (Enterprise Edition) 以降のみ ← SQL Server 7.0 以前はインデックスはテーブルにのみ使用
ビュー:結合、集計、またはその組み合わせを含む
            SELECT ステートメントに名前をつけたもの。名前を指定することで参照可 → 実体なし
ビューにインデックスを作成することで、ビューの結果セットが物理的にデータベースに保存
    → 実体を持つ
テーブルインデックスと同様自動保守
オプティマイザは、ビューが直接クエリの中で参照されていなくてもビュー上のインデックスの使用を考慮
インデックスが参照できるのはベーステーブルのみ → 他ビューは参照不可

○ インデックスビュー作成のガイドライン
効果的な場合
  意思決定支援システム(検索系)
  大きなテーブルの結合、集計
  クエリの繰り返しパターン
    ‥同列セット集計の繰り返し
    ‥同テーブルの同キーの結合の繰り返し
非効果的な場合
  書き込みが頻繁な OLTP (オンライントランザクション処理)
  重い更新処理を伴うデータベース
  結合により元テーブルより結果セット行数が多くなるビュー
  異なる値を多く含むキーの集計

○ ビュー作成要件
ビューとデータベースをバインド → ベーステーブルの変更、削除を防止
  CREATE VIEW ... WITH SCHEMABINDING オプション
テーブルとユーザー定義関数は名前の参照に所有者名が必須
インデックス列の関数は決定的な関数
 
決定的関数 特定の入力値セットで呼び出されるたびに常に同じ結果を返す ABS、DATEADD、SQRT 等
非決定的関数 呼び出されるたびに異なる結果を返す GETDATE、NEWID、DATENAME 等
GROUP BY 句が指定されている場合、ビューの選択リストに集計式を含められない
GROUP BY 句が指定されている場合、ビューの選択リストに COUNT_BIG(*) が含まれている必要あり
  COUNT(*) ではエラーとなる
  COUNT_BIG 関数 … bigint に対応した集計関数

○ インデックス作成要件
複数インデックスを作成可、ただし最初に一意なクラスタ化インデックスを作成する必要あり
  CREATE UNIQUE CLUSTERD INDEX...
SET オプションの条件
  ON でなければならないオプション
    ANSI_NULLS
    ANSI_PADDING
    ANSI_WARNINGS
    ARITHABORT
    CONCAT_NULL
    YIELDS_NULL
    QUOTED_IDENTIFIERS
  OFF でならなければならないオプション
    NUMERIC_ROUNDABORT
  DBCC USEROPTIONS ステートメントで確認可
【参照】 SQL Server 2000 Books Online 「インデックス付きのビューの作成」
インデックス付きビューの作成の可否は OBJECTPROPERTY 関数の IsIndexable プロパティで確認可
  SELECT OBJECTPROPERTY (オブジェクトID, 'IsIndexable') → 1 が返ってくれば作成可
posted by w@ko at 19:18|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

2005年10月05日

インデックスの削除


 
主キー制約と UNIQUE 制約の指定によって自動作成されたインデックスは DROP INDEX ステートメントで削除不可
  → 先に制約を削除する必要あり
posted by w@ko at 18:27|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

インデックス使用前の確認

クエリアナライザでクエリ実行プランを確認
インデックスが使用されない原因を考える
クエリオプティマイザヒントの使用
  クエリ処理に使用するインデックスを指定
    ‥テーブルヒント
    ‥結合ヒント
    ‥クエリヒント
  統計情報の更新やインデックスの再作成、オプティマイザの強化等に使用 (SQL Server 7.0 以降)
  SELECT ... FROM テーブル名 WITH ヒント
  通常はクエリオプティマイザで最適化 → あまり使わない

○ インデックス使用時の参考基準
統計情報(クエリオプティマイザ)から自動参照
オプティマイザヒントでの手動定義を参照
posted by w@ko at 18:27|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

インデックスによるクエリのカバー

検索引数の使用
 
適切な検索引数の作成
  クエリ内で WHERE 句を指定
  WHERE 句が行の数を制限することを確認
  クエリ内で参照されるすべてのテーブルに対して式が存在することを確認
  ワイルドカードを先頭に使用しない
 
式の単純化
posted by w@ko at 18:26|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

広告


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

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

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


×

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