2005年09月09日

旧バージョンとの相違点

ステートメントの変更
  DUMP (SQL Server 6.5 以前) → BACKUP (SQL Server 7.0 以降)
オンラインバックアップ中のトランザクションもバックアップセットに含まれる (SQL Server 7.0 以降)
差分バックアップ (SQL Server 7.0 以降) ← テーブル単位のバックアップ (SQL Server 6.5 以前)
障害発生直前までの復旧可能 (SQL Server 7.0 以降) → NO_TRUNCATE オプションの使用
SAN のサポート (SQL Server 2000 以降 ※ SQL Server 7.0 でもサポートしていたが完全ではない)
  VDI (Virtual Device Interface)サポート
テーブルバックアップ機能なし (SQL Server 7.0 以降)
データベースの移行が容易 (SQL Server 7.0 以降)
  自動アップグレード機能で SQL Server 7.0 → SQL Server 2000 への移行が可能 (逆は不可)
master データベースの再構築に rebuildm.exe を使用 (SQL Server 7.0 以降)
ログ配布によるスタンバイサーバーの構築 (SQL Server 2000 以降)
クラスタ構成 → 可用性の追求
posted by w@ko at 19:36|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップの保存場所

ハードディスクファイル (ローカルまたはリモート)
テープ (ローカルのみ。Windows 98 では未サポート)
名前付きパイプ → サードパーティ製ソフトで利用
posted by w@ko at 19:35|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップ実行権限

sysadmin 固定サーバーロールメンバ
db_owner 固定データベースロールメンバ
db_backupoperator 固定データベースロールメンバ
posted by w@ko at 19:34|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップ計画

○ システムデータベース
master データベース変更後
  データベースの作成/削除/属性の変更
      CREATE DATABASEDROP DATABASEALTER DATABASE ステートメント
  サーバーの追加/削除
      sp_addserversp_dropserversp_addlinkedserver システムストアドプロシージャ
  カスタムエラーメッセージの追加
      sp_addmessage システムストアドプロシージャ
msdb データベースの変更後
  SQL Server エージェントが使用する情報の変更
    (ジョブ、警告、オペレータの作成/削除/変更)
model データベースの変更後
  master/msdb データベース再構築後は model データベースに対する変更も失われる

○ ユーザーデータベース
データベース作成後
インデックス作成/再構築後
  ※ インデックスの再構築はフルデータベースバックアップの復元よりも時間がかかる場合あり
トランザクションログ削除後
ログに記録されない操作実行後

○ データベースの使用用途によるバックアップ頻度
更新系 頻繁にバックアップを行う
検索系 バックアップ頻度が少なくても構わない
posted by w@ko at 19:28|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップの種類

完全バックアップ
差分バックアップ
トランザクションログバックアップ
ファイル/ファイルグループバックアップ
ファイル/ファイルグループ差分バックアップ
運用時には必ずトランザクションログバックアップをジョブに含める
  → ログ切り捨てを行うため

○ データベースファイル/ファイルグループバックアップ
大規模データベース環境(VLDB)でバックアップに要する時間が限られている場合などに実行
指定のデータベースを論理ファイル/ファイルグループ単位でバックアップ
  FILE または FILEGROUP オプションで指定
      BACKUP DATABASE データベース名 [{FILE = ファイル名|FILEGROUP = ファイルグループ名}] TO...
トランザクションログバックアップが必須
  復元するファイルとデータベースの残りの部分との一貫性を保つため
    破損したファイルに関するログをすべてバックアップ↓
バックアップ時間の短縮 ⇔ 復元に時間がかかる
インデックスは複数データベースファイル(ファイルグループ)一式を1つのユニットとしてバックアップが必要
  復元時にはインデックスを再作成するため、元テーブルを含む全データベースファイルも復元が必要
設計に注意 → バックアップ順序
  あまり推奨されない
【参照】 SQL Server 2000 Books Online 「バックアップ ファイルの使用」
                                                           「ファイルとファイル グループ バックアップ、復元」
posted by w@ko at 19:27|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

テープデバイスへのバックアップ

バックアップにはローカルテープドライブのみ使用可
SQL Server データと非 SQL Server データを同一テープ上にバックアップ可
  → NTBACKUP とのデータ共存可
テープオプション
 
UNLOAD (既定) バックアップ完了後に自動テープ巻き戻し、ドライブからアンロード
NOUNLOAD テープ巻き戻しおよびアンロードを行わない
BLOCKSIZE FORMATSKIPINIT オプション使用時の物理ブロックサイズをバイト単位で変更
FORMAT バックアップで使用する全ボリューム上の全ヘッダーおよびバックアップを上書き
SKIP テープデバイス上の既存の ANSI テープラベル(書き込み権限/有効期限情報)を無視
NOSKIP (既定) ANSI テープラベルを読み取る
RESTART 中断されたバックアップ操作を中断された時点からバックアップ再開
posted by w@ko at 19:26|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップコマンド

○BACKUP DATABASE コマンド

 
BACKUP DATABASE データベース名 TO メディアの種類 [WITH [FORMAT][[,] {INIT|NOINIT}]
  《フル》 BACKUP DATABASE データベース名 TO DISK='ファイルパス' 〔→ディスク〕
    BACKUP DATABASE データベース名 TO TAPE='¥¥.¥テープ名' 〔→テープ〕
  《差分》                                                                                 ...WITH DIFFERENTIAL
  《ログ》 BACKUP LOG データベース名 TO DISK='ファイルパス'
    ※ 既定でバックアップ時にログ切り捨て
        ログを残す場合は WITH NO_TRANCATE オプションを付ける

○ INIT/NOINIT オプション
バックアップファイル上書き/追加オプション
既定で NOINIT (追加)
INIT (上書き)を指定してもヘッダー情報は残る → 上書きできるかどうかの確認に使用
バックアップ操作が失敗してデータが上書きされない場合
  バックアップデバイス上に指定した EXPIREDATE オプション(上書き禁止期間)が期限切れになっていない
  NAME オプションに指定したバックアップセット名パラメータがバックアップデバイスのセット名に一致しない
  以前に名前を付けたバックアップセットの1メンバーに上書きを試みた

○ FORMAT オプション
バックアップファイルの内容上書き、以前のバックアップセットの切り離しに使用
バックアップ操作に使用されているすべてのファイルに新しいメディアヘッダを書き込み
既存メディアおよびバックアップファイルの内容の両方を上書き
posted by w@ko at 19:23|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップファイル

○ パーマネントバックアップファイル (バックアップデバイス)
バックアップ操作前に作成
バックアップファイルの再利用、バックアップ作業の自動化に必要
バックアップ設定時に物理的位置に左右されない
Enterprise Manager または sp_addumpdevice システムストアドプロシージャで作成
  sp_addumpdevice [{'DISK'|'TAPE'|'PIPE'}], 'デバイス名', 'ファイルパス'
  バックアップファイルの論理名および物理名を指定する必要あり
  master..sysdevices システムテーブル内に論理名および物理名を作成
  1つのデータベースに最大 64 個のバックアップファイルを作成可

○ 一時バックアップファイル
BACUP DATABASE ステートメントで作成 → 既存バックアップファイルを指定する必要なし
バックアップファイルを再利用しない場合等
Enterprise Manager で作成
  メディアの種類(ディスク/テープ/名前付きパイプ)を指定
  完全パスおよびファイル名を指定
○ 複数バックアップファイルの使用 (バックアップセット)
一度に複数のバックアップファイルにストライプ化してバックアップされる
バックアップ実行時間の短縮
BACKUP DATABASE...TO...WITH MEDIANAME=メディアセット名
  MEDIANAME オプションで名前をつけたあとは別のバックアップ操作で再利用可
  メディアセット名は最大 128 文字
  1回のバックアップ操作で使用されるすべてのデバイスは同じメディア種類である必要あり
  パーマネントバックアップファイルと一時バックアップファイルの組み合わせ可
  ファイルをバックアップセットのメンバーとして定義すると、常にメンバーファイルと一緒に使用する必要あり
  ファイルを再フォーマットしない限りバックアップセットの1メンバーのみをバックアップ操作に使用不可
  バックアップセットの1メンバーを再フォーマットすると他のメンバーに含まれているデータは無効になる
 
 
複数バックアップファイルを使用する場合はファイルを作成したデバイスを識別する ID を各バックアップファイルに指定
posted by w@ko at 18:49|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップファイルサイズ

データベースファイルサイズ = バックアップファイルサイズとはならない
  データ復元時(特に完全バックアップ)に容量に注意!
  (対策)
    → バックアップ前にファイルサイズを確認しておく
    → バックアップ前にデータベースを(切り捨て +)圧縮をかけておく
posted by w@ko at 18:48|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

オンラインバックアップ中に制限される操作

データベースの作成および変更 (CREATE DATABASEALTER DATABASE
データベースの自動拡張操作
インデックスの作成
データベースの圧縮
ログに記録されない操作
  トランザクションログ切り捨て操作
        BACKUP LOG WITH TRUNCATE_ONLYBACKUP LOG WITH NO_LOG ステートメント
  テキスト列内のデータ変更操作
        WRITETEXTUPDATETEXT ステートメント
    WITH LOG オプションを指定すればログに記録
  パーマネントテーブル作成操作
        SELECT...INTO/BULKCOPY
posted by w@ko at 18:48|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

オンラインバックアップ時の動作

元のファイルの場所を記録
バックアッププロセス中に発生するデータベースアクティビティをキャプチャ
  チェックポイントを実行し、LSN(ログシーケンス番号)を記録
  ディスクを直接読み取り、バックアップメディアにすべてのデータを書き込み
  バックアッププロセス中に書き込まれたすべてのトランザクションログレコードを書き込み
オンラインバックアップ中はパフォーマンスの低下が見られる (約 10%)
  タイミングに注意
posted by w@ko at 18:47|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

バックアップに含まれる情報

スキーマおよびファイル構造
データ
トランザクションログの一部 (バックアッププロセスが起動してからのデータベースアクティビティを含む)
posted by w@ko at 18:46|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

マルチサーバージョブの自動化

1つのマスタサーバー(MSX)と1つ以上の対象サーバー(TSX)で構成
 
マスタサーバーはジョブを対象サーバーに自動配布、対象サーバーからイベントを受け取る
 
複数サーバーを論理的な事業単位にグループ化
 
複数サーバーを1か所から集中管理
 
マスタサーバーの定義
  対象サーバー上に配布するジョブの定義、スケジュール、管理
  Windows NT/2000 コンピュータ
  Enterprise Manager または sp_msx_enlist システムストアドプロシージャで定義
   
 
Enterprise Manager → SQL Server エージェントの右クリック → [マルチサーバーの管理] → [マスタサーバーの設定] → [マスタサーバー設定ウィザード]
 
 
定義済みマスタサーバー情報はマスターサーバーの msdb..systargetservers システムテーブルに格納
 
 
各対象サーバー用 SQL Server ログインアカウントおよびパスワードは自動作成、アカウントには _msx_probe という接尾語が付加
    マスタサーバーから対象サーバーへジョブをダウンロードできるように msdb データベースにアクセス
    このアカウントのパスワードを変更すると対象サーバーがマスタサーバーにアクセスできなくなる
      → 対象サーバーの再登録が必要
  ウィザードでマスタサーバーおよび全対象サーバーに MSXOperator を作成
  イベントの転送先サーバーとして構成
   
 
データベース作成機能を実行しない場合、イベントの管理負荷はデータベースアプリケーションパフォーマンスに影響なし
 
対象サーバーの定義
  Enterprise Manager または sp_msx_enlist システムストアドプロシージャで定義
   
 
Enterprise Manager → SQL Server エージェントの右クリック → [マルチサーバーの管理] → [対象サーバーの設定] → [対象サーバー設定ウィザード]
  定義済み対象サーバー情報は msdb..systargetservers システムテーブルに格納
  1つのマスタサーバーにのみ割り当て可
    現在のマスタサーバーから登録解除されるまで別マスタサーバーのメンバーに登録不可
  マスタサーバーと同一 Windows ドメインまたは信頼されている Windows ドメイン内にある必要あり
 
SQL Server 7.0 サーバーは SQL Server 2000 サーバーの名前付きインスタンスを処理不可
 
マルチサーバージョブ処理の手順
  1.
 
マスタサーバーが msdb..sysdownloadlist システムテーブルのダウンロードリストにある対象サーバーのためにジョブを通知
  2.
 
対象サーバーはマスタサーバーと定期的に接続、ダウンロードするためのジョブが通知されていることを確認、ジョブをダウンロード
  3. 対象サーバーはジョブ完了後、ジョブ結果ステータスをマスタサーバーにアップロード
  ジョブ内のパスおよび構文は全対象サーバー上で同一である必要あり
 
マスタサーバーにジョブ定義およびスケジュールのマスタコピーを格納
  対象サーバーでジョブ定義の変更不可 → マスタサーバーのみで実行可
  Enterprise Manager はダウンロードリストに必要な命令を自動通知
 
マスタサーバーは対象サーバーからのジョブ結果情報を msdb..sysjobservers システムテーブルに記録
  各対象サーバーのローカル msdb..sysjobhistory システムテーブルのジョブヒストリ情報
posted by w@ko at 18:46|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

ジョブのトラブルシューティング

○ SQL Server 自動化
SQL Server エージェントの起動確認
ジョブ、スケジュール、警告、オペレータの有効確認
プロキシアカウントの有効確認 ← sysadmin メンバー以外のユーザーがオブジェクトの所有者の場合
エラーログの確認
  SQL Server エージェントエラーログ
    SQL Server エージェントサービスの再起動のたびに新しいエラーログを作成
    最大9個のエラーログを保存、表示可
      ⇒ Enterprise Manager → SQL Server エージェントを右クリック → [エラーログの表示]
      → ¥Program Files¥Microsoft SQL Server¥Mssql¥Log フォルダ内のログファイル
    エラーがログに記録された場合に net send コマンドでエラーを送信する設定可
      ⇒ Enterprise Manager → SQL Server エージェントのプロパティ → [全般]タブ
  Windows アプリケーションログのサイズ確認
  SQL Server エラーログ
ヒストリの確認
  ジョブヒストリの最大行数の確認
メールクライアントの正常動作確認

○ 警告
警告処理のバックログ
  アプリケーションログエラーの大量書き込みで警告応答に遅延発生(グローバルリソース不足)
  警告数が SQL Server エージェントの警告処理速度を超えた場合にバックログ作成
  警告を一時的に無効にする
  各警告間の応答時間を増やす
  グローバルリソース問題を解消
  アプリケーションログの削除
  警告を発生させないエラーを設定 → レジストリで設定
posted by w@ko at 18:45|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

警告

○ 警告プロセス
1. 警告発生の元となるイベントの発生
2. イベントが Windows アプリケーションログに書き込まれる
3. Windows アプリケーションログがイベントが発生したことを SQL Server エージェントに通知
4.
 
SQL Server エージェントがキャッシュされている msdb..sysalerts システムテーブル内に定義されている警告とエラーを比較
5. SQL Server エージェントが警告に応答
  − msdb..sysnotifications システムテーブルを確認して電子メールメッセージを送信
  − msdb..sysoperators システムテーブルを確認して通知を送信するオペレータを特定

○ アプリケーションログへのイベント書き込み
SQL Server エージェントサービス開始時にイベントビューアサービスに登録
SQL Server がアプリケーションログに書き込むイベント
  − 重大度レベル 19 〜 25 の SQL Server エラー
  sp_addmessage または sp_aletrmessage システムストアドプロシージャで定義されたエラー
  RAISERROR WITH LOG ステートメントの実行
  xp_logevent 拡張ストアドプロシージャ実行
アプリケーションログに SQL Server のイベントが書き込まれると SQL Server エージェントに通知

○ SQL Server エラーに応答する警告の作成
エラーに応答する警告作成時はエラー番号またはエラーレベルを指定
  1イベントで1警告を発生
Enterprise Manager または sp_add_alert システムストアドプロシージャで警告を作成可
定義済み警告は msdb..sysalerts システムテーブルに格納 → キャッシュ管理
エラー番号での警告の定義
  Windows アプリケーションログにエラー番号を書き込む必要あり
 
 
master..message システムテーブルに格納されている任意のエラー番号(システム定義警告)およびユーザー定義エラー番号で警告を定義
  1つのエラー番号で複数の警告を定義可
    ※ 各警告は特定の1データベースのみもしくは全データベースで適用
  全データベースに適用する警告作成時はエラーメッセージの内容が適切かどうか確認
  エラー番号に特定のエラーメッセージテキストを定義可
エラー重大度レベルでの警告の定義
  重大度レベル 19 〜 25 のエラーはアプリケーションログに自動的に書き込み
  重大度レベル 20 〜 25 は致命的エラー → 通知するオペレータを定義する必要あり
  定義済み警告を使用する場合、通知するオペレータの指定および「Demo:...」文字を削除してから使用
  全データベースまたは特定データベースに警告作成可
  重大度レベルに特定のエラーメッセージテキストを定義可
  重大度レベル 18 以上のエラーは電子メールエイリアス全体に警告を送信するようにする
指定した重大度レベル以上の未処理イベントメッセージおよび全未処理イベントメッセージを転送可
  Enterprise Manager → SQL Server エージェントのプロパティ → [詳細設定]タブ

○ ユーザー定義エラーに応答する警告の作成
エラーメッセージの作成
  Enterprise Manager または sp_addmessage システムストアドプロシージャで作成
    ⇒ Enterprise Manager → サーバーのプロパティ → [すべてのタスク] → [SQL Server メッセージの管理]
    sp_addmessage エラー番号, エラーレベル, 'メッセージ'
  ユーザー定義エラー番号は 50000 より大きく設定
    ← 50000 より小さいエラー番号は定義済み SQL Server エラーで予約済み
  ユーザー定義エラーはすべて master..sysmessage システムテーブルに格納
  エラーメッセージには特定の詳細情報をキャプチャするパラメータを含めることが可
  エラーメッセージは設定中に選択した言語で表示 → 多言語のメッセージも作成可
  警告を発生させるメッセージの場合はアプリケーションログにエラーメッセージを書き込む必要あり
データベースアプリケーションからのエラー発生
  RAISERROR ステートメントの実行 → ストアドプロシージャやトリガで実行
        RAISERROR (エラー番号, エラーレベル, 状態)
  パラメータの変数を宣言

○ パフォーマンス条件警告
Windows パフォーマンスモニタで定義した SQL Server パフォーマンス条件に対応する警告
設定されたしきい値を超えた場合に警告発生
作成可能なオブジェクト
  Access Methods
  Buffer Manager
  Cache Manager
  Databases
  Locks
  SQL Statistics
パフォーマンスデータは1分間に数回の定期的提供のため、警告発行に遅延発生
  応答時間遅延を少なく設定する
  パフォーマンス条件のしきい値を変更する

○ 緊急時のオペレータ指定
定義されているオペレータに警告通知を行えなかった場合のために指定
  警告の応答で問題の通知方法による通知が定義されている場合
  問題の通知方法のオペレータがすべて非番の場合
  緊急時のオペレータが定義される場合
  SQL Server エージェントのメールセッションが開始している場合
Enterprise Manager → SQL Server エージェントのプロパティ → [警告システム]タブで設定
緊急のオペレータ指定時の考慮点
  オペレータ情報はキャッシュに格納 → msdb データベースへの接続にかかわらずオペレータに警告通知
  オペレータは1つのみ定義可
  オペレータ作成後、割り当てられたオペレータ削除は不可
posted by w@ko at 18:44|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

ジョブ

○ ジョブの作成
Enterprise Manager または sp_add_job システムストアドプロシージャで作成可
定義済みジョブは msdb..sysjobs システムテーブルに格納 → キャッシュ管理
ジョブが有効なことを確認
  ジョブはデフォルトで有効
  無効な場合、スケジュールどおりのジョブ実行不可
    ※ 警告に応答した場合、Enterprise Manager からジョブを手動起動した場合は実行可
ジョブ実行の所有者を確認 → 既定でログインアカウント
ジョブの実行場所の確認 … ローカルサーバー上もしくはリモートサーバー上
ジョブカテゴリの作成
ジョブのコアセットの定義にはデータベース保守計画を使用すると便利

○ ジョブの権限
所有者が sysadmin ロールのメンバでない場合、ジョブを実行する権限があるか確認
  Transact-SQL → どのユーザーでも実行可
  OS コマンドおよび ActiveX スクリプトジョブ
      sysadmin ロールメンバー → SQL Server サービスアカウント権限で実行
      sysadmin ロールメンバー以外 → 権限を確認
      ‥ 既定で実行不可、ただし管理者が実行権限を与えることが可能 … プロキシアカウント
      ‥ プロキシアカウントの定義
          ⇒ Enterprise Manager → [SQL Server エージェント]のプロパティ → [ジョブシステム]タブ
          ⇒ xp_sqlagent_proxy_account システムストアドプロシージャ
      ‥ Administrators ローカルグループのメンバーでも実行可
          → エージェントがプロキシアカウントにアクセス

○ ジョブステップの定義
Enterprise Manager または sp_add_jobstep システムストアドプロシージャで定義可
定義済みジョブステップは msdb..sysjobsteps システムテーブルに格納
ジョブステップの定義で使用できる実行タイプ(1ステップにつき1実行タイプのみ指定可)
  Transact-SQL ステートメント
    使用するデータベースを特定
    ジョブステップに必要な変数およびパラメータを含める
    ジョブステップの結果セットを出力ファイルに送信可
      → エラー検出のため 次回のジョブステップの入力値としては使用不可
  OS コマンド
    .exe、.bat、.cmd、.com 拡張子
    コマンドが成功したことを示すプロセス終了コードを識別
    [コマンド]欄に起動するプログラムのフルパス名を入力
      → SQL Serverエージェントがプログラムソースを見つけるために必要
  ActiveX スクリプト言語
    ジョブステップが書かれたスクリプト言語の識別(VBScript、Jscript 等)
    ActiveX スクリプトの作成
      → SQLActiveScriptHost オブジェクトを使用してジョブステップのヒストリ出力、オブジェクトの作成が可能
  レプリケーション

○ ジョブスケジュール
Enterprise Manager または sp_add_jobschedule システムストアドプロシージャで設定可
定義済みジョブスケジュールは msdb..sysjobschedule システムテーブルに格納
ジョブは定義されているスケジュールおよび警告の応答によって実行
マルチサーバー環境の場合、対象サーバー上で実行ジョブの定義可

 
SQL Server エージェントサービスアカウントが Administrators ローカルグループのメンバーでない場合はスケジュールの種類として「CPU のアイドル時」を選択できない
複数スケジュール設定可

○ 通知先オペレータの作成
Enterprise Manager または sp_add_operator システムストアドプロシージャで設定可
定義済みオペレータは msdb..sysoperator システムテーブルに格納
  → 最新通知日時も記録

 
電子メール通知の場合は電子メールエイリアスでグループを使用して2人以上に通知し、潜在的問題に対応できるようにする

○ ジョブヒストリ
msdb..sysjobhistory システムテーブルにジョブヒストリを格納
Enterprise Manager でジョブ右クリック→[ジョブヒストリの表示]で参照可

 
Enterprise Manager の SQL Server エージェントサービスのプロパティ→[ジョブシステム]タブでジョブヒストリサイズの上限設定可
  最大サイズに達するとジョブヒストリは自動的に上書き (sysjobhistory テーブルから削除)
  既定のジョブヒストリログ最大サイズ:1,000行
  既定の各ジョブのジョブヒストリ最大行数:100行
  Transact-SQL 実行中にエージェントサービスが停止すると実行中のジョブステップ情報がヒストリに記録
    → エージェントがサービスを停止する前にジョブが完了するまでの待ち時間を設定可(秒単位)
posted by w@ko at 18:44|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

SQL Server 電子メール送受信システムの種類

SQLAgentMail
  SQL Server エージェントサービスが実行
  サーバーからジョブの成否および警告の通知を送信
  サーバー起動時にメールセッション開始を試みる
 
SQL Mail
  SQL Server サービスが実行
  xp_sendmail 拡張ストアドプロシージャ実行時にメール送信
  SQL Mail アカウントの受信トレイから入ってくる電子メールを処理、結果セットを差出人に返信
  SQL Mail 起動時にメールセッション開始を試みる
  SQL Server 起動時に SQL Mail 自動起動の設定可
 
共通設定項目
  MAPI-1 に準拠したメッセージングサーバーを使用 → Exchange Server
  SQL Server が動作するコンピュータで電子メールクライアントを設定 → Outlook
  SQL Server サービスおよび SQL Server エージェントサービスはドメインユーザーログオンアカウントを使用
  メッセージングサーバーとの接続に使用する各メールアカウントプロファイルを設定
    ※ 両方のサービスで同じアカウントを使用する場合はメールプロファイルの設定は1つで済む
  各メールセッションの使用メールプロファイルは Enterprise Manager で指定
posted by w@ko at 18:44|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

2005年08月11日

SQL Server エージェントサービス

サービスの起動にはログインアカウントが sysadmin ロールのメンバーである必要あり
 
ローカルシステムアカウント
  アクセスはローカルコンピュータのみ → ネットワークリソースへのアクセス不可
 
ドメインユーザーアカウント
  ネットワークリソースにアクセス可
  電子メールシステムと通信するために必要
posted by w@ko at 19:18|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

監査

C2 セキュリティ監査 … 米国政府評価基準に基づくセキュリティ保証を満たす
 
有効にすると、サーバー上の全アクションとアクセス許可状況を追跡、ログファイルを作成
  sp_configure 'c2 audit mode', 1
 
監査記録は SQL プロファイラで確認
 
ログファイルが格納されたドライブの空き領域が不足すると、SQL Server は停止
  ログバックアップ後ログファイルを削除
 
 
既定で C:¥Program Files¥Microsoft SQL Server¥MSSQL($インスタンス名)¥DATA ディレクトリにログファイル作成
  ログファイルサイズが 200MB の上限に達すると、監査は新しいファイルを作成
posted by w@ko at 19:17|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

ファイアウォールセキュリティ

SQL Server 既定の TCP/IP ポート番号は 1433
  レジストリキーで設定変更可
 
名前付きインスタンスは起動時に動的にポート割り当て
 
 
プロキシ使用時は SQL Server ネットワークユーティリティを使用して割り当てられたポートを上書きし、そのインスタンス固有のポートを割り当てる必要あり
 
 
COM+ 使用時は COM+ プロトコルがクライアントとの接続ネゴシエーションに使用するために有効なポート範囲とポート 135 が有効である必要あり
posted by w@ko at 19:16|  ・SQL Server ノート | このブログの読者になる | 更新情報をチェックする

広告


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

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

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


×

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