Microsoft SQL Server 2005 Beta 2 ‐ SQL Server エージェントの新機能
このページはアーカイブです。記載されている内容は情報提供のみを目的としており、ページ内のリンクは有効でない可能性がありますが、これらの情報についてマイクロソフトはいかなる責任も負わないものとします。 |
公開日: 2005年1月5日
Rob Walters
概要 : このドキュメントでは、Microsoft® SQL Server™ 2005 Beta 2 に実装されている SQL Server エージェントのスケジューリング サービスについて、新機能の概要を説明します。
トピック
はじめに
まとめ
はじめに
このドキュメントでは、Microsoft® SQL Server™ 2005 Beta 2 に実装されている SQL Server エージェントの機能について、主な変更内容を説明します。この説明を参考に、本リリースの新機能をすぐに利用できます。このドキュメントに記載されているトピックの詳細については、「SQL Server Books Online」を参照してください。
セキュリティの向上
SQL Server の初回インストール時、SQL Server エージェントのジョブを表示、変更、作成、実行するための権限を付与されているのは、システム管理者 (sysadmin) ロールのみです。システム管理者のロールを割り当てられているユーザーだけが、SQL オブジェクト エクスプローラのエージェント ノードを使用できます。SQL Server エージェントに対する権限を付与するには、msdb データベースの新たな 2 つのデータベース ロールのいずれかに、ユーザーを追加する必要があります。
msdb データベースの新しいロール
SQL Server 2005 の SQL Server エージェントでは、msdb データベースに新しく 2 つのロールが追加されました。
SQLAgentUserRole SQLAgentUserRole ロールに追加されたユーザーは、SQL Server 2000 と同様に SQL Server エージェントを使用できます。これらのユーザーは、ジョブの作成と管理 (自分が作成したジョブについてのみ) を行うことができます。
MaintenanceUserRole MaintenanceUserRole ロールのメンバであるユーザーは、db_dtsadmin と SQLAgentUserRole ユーザー ロールのメンバでもあります。このロールは、SQL Server 2005 に含まれる新しい保守計画機能で使用されます。
複数のプロキシ アカウント
SQL Server 2000 では、ユーザーがジョブ ステップとして DTS パッケージを実行するときに、sysadmin は SQL Server エージェントのプロキシ アカウントを有効にする必要がありました。有効にしたアカウントを使用して、SQL Server エージェントのユーザーは自由に特定のサブシステム (CmdExec など) のジョブ ステップを作成し、実行することができました。SQL Server 2005 では、SQL Server エージェントで複数のプロキシ アカウントを使用することによって、このセキュリティ上の懸念事項に対処しています。
新たにリリースされた SQL Server エージェントでは、既定で、次のジョブ ステップの作成は sysadmins のみに許可されます。
アクティブ スクリプト
DTS
分析コマンド
分析クエリ
すべてのレプリケーション サブシステム
Transact-SQL サブシステムについては、SQL Server 2000 と同様、所有者アカウントのみで実行可能です。
Transact-SQL 以外のジョブ ステップを作成する権限を、sysadmins 以外のユーザーに付与するには、sysadmin が、対象ユーザー用に 1 つ以上のプロキシ アカウントを作成する必要があります。このプロキシ アカウントは、単にフレンドリ名を指定した資格情報となります。
エージェントのプロキシ アカウントを作成する前に、資格情報を作成することが必要です。資格情報を作成するには、次のスクリプトを使用します。
CREATE CREDENTIAL [MyCredential] WITH IDENTITY = '<domain>\<user>',
secret = '<password>'
メモ Beta 2 では、SQL Server Management Studio に資格情報を作成するダイアログ ボックスはありません。SQL エージェントの UI ダイアログ ボックスを使用してプロキシ アカウントを作成する場合は、最初に Transact-SQL で資格情報を作成する必要があります。
プロキシ アカウントを追加するには、次のスクリプトを使用します。
Sp_add_proxy @proxy_name='My Proxy', @credential_name='MyCredential'
sysadmin は、作成したプロキシ アカウント アカウントに対するアクセス権限を、1 つ以上の SQL ログイン、msdb ロール、またはサーバー ロールに割り当てます。
図 1 My Proxy アカウントに割り当てられた SQL ログインと msdb ロール
プロキシ アカウントに SQL ログインを割り当てるには、次のスクリプトを使用します。
Sp_grant_login_to_proxy @login_name='Jeff Price', @proxy_name='My Proxy'
メモ この例では、SQL ログイン "'Jeff Price" は、msdb データベースのデータベース ユーザーであり、msdb の SQLAgentUserRole ロールのメンバであることを前提としています。
次に、sysadmin は、このプロキシ アカウントにアクセス可能なサブシステムを割り当てることができます。sysadmin がサブシステムを割り当てると、Jeff Price と msdb の MaintenanceUserRole に含まれるユーザーは、"My Proxy" プロキシ アカウントを使用して、SQL Server エージェントのジョブ ステップ (DTS 型) の作成と実行を行うことができます (図 2)。
図 2 DTS サブシステムに割り当てられたプロキシ アカウント
プロキシ アカウントに DTS サブシステムを割り当てるには、次のスクリプトを使用します。
Sp_grant_proxy_to_subsystem @proxy_name='My Proxy', @subsystem_name='DTS'
メモ プロキシ アカウントを 0 以上のサブシステムに割り当てることができます。プロキシ アカウントのサブシステムとユーザーを無効にするには、sysadmins は、それぞれ sp_revoke_proxy_from_subsystem と sp_revoke_login_from_proxy を使用します。
SQL Server 2005 にアップグレードすると、既存のプロキシ アカウントが作成され、すべてのサブシステムは、この 1 つのプロキシ アカウントに割り当てられます。この処理によって、アップグレード後も、SQL Server エージェントのジョブは SQL Server 2000 と同様に機能します。ただし、アップグレードの後、sysadmin はプロキシ アカウントのセットアップを検証することが大切です。sysadmin は、プロキシ アカウントへのアクセスを必要としないユーザーは削除します。さらに、プロキシ アカウントを追加で作成し、権限を制限して特権が昇格する可能性を排除します。
パフォーマンスの向上
スレッドの寿命
SQL Server 2000 では、レジストリのエントリを使って、同時にアクティブにすることが可能なサブシステムのスレッド数を決定していました。このサブシステムのレジストリ キーは、HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.x\SQLServerAgent\Subsystems のサブツリーに残っていますが、SQL Server 2005 では、各ジョブ ステップの最後にスレッドを終了するのではなく、スレッドを SQL Server エージェントに戻し、実行に備えて待機している同じ種類のジョブ ステップがあるかどうかを判断します。ステップがある場合、このスレッドでジョブ ステップが実行されます。ステップがない場合、スレッドは終了します。この変更によって、SQL Server 2005 の SQL Server エージェントは、効率的に多くのジョブを実行できるようになりました。
パフォーマンス カウンタ
SQL Server 2005 の SQL Server エージェントでは、新しく 4 つのパフォーマンス カウンタが追加されました。
SQLAgent:Alerts SQL Server エージェント サービスの起動後に発生した警告数、分単位に発生した警告数を監視できます。
SQLAgent:Jobs ジョブの成功率、アクティブなジョブ数などの情報を監視できます。このカウントによって、ジョブの開始方法が、適宜であるか、警告によるか、スケジュールによるかについても判断できます。
SQLAgent:JobSteps 実行に備えて待機中のジョブ ステップ数、特定のステップが再試行された回数などの情報を監視できます。
SQLAgent:Statistics エージェント サービスで SQL Server サービスを再起動した回数を監視できます。
これらのオブジェクトには、Microsoft Windows® で提供されている一般的なパフォーマンス監視ユーティリティを使用してアクセスできます。
新機能
SQL Server エージェントの新サブシステム
SQL Server 2005 Beta 2 の SQL Server エージェントには、新しく 3 つのサブシステムが追加されました。
DTS
分析クエリ
分析コマンド
DTS サブシステム
DTS サブシステムを使用すると、DTS パッケージを実行するジョブ ステップを作成できます。DTS ジョブ ステップのパラメータとして、DTExec コマンド プロンプト アプリケーションで定義されているすべてのパスワードを使用できます。
メモ 暗号化された DTS パッケージを実行する場合、プロキシ アカウントのユーザーは、そのパッケージを作成した Windows ユーザーと同じ資格情報を持っている必要があります。暗号化されていないパッケージは、実行時にこのような制限はありません。
分析クエリ サブシステム
分析クエリ サブシステムを使用すると、MDX クエリを送信するジョブ ステップを作成し、ストアド プロシージャから分析サーバーのコンピュータを呼び出すことができます。
分析コマンド サブシステム
分析コマンド サブシステムを使用すると、分析サーバーのコンピュータに XML for Analysis ステートメントを送信するジョブ ステップを作成できます。
メモ ほとんどの管理ダイアログ ボックスでは、XML for Analysis としてアクションをスクリプト化できます。
共有スケジュール
SQL Server 2005 の SQL Server エージェントでは、1 つのスケジュールを作成して、そのスケジュールを使用する 1 つ以上のジョブを割り当てることができます。
メモ ジョブとスケジュールは、互いに割り当てられているユーザーが所有することが必要です。
WMI イベント アラート
SQL Server 2005 は、データベース内部で生じるさまざまなアクションによって発行される WMI イベントに対応しています。今回のリリースでは、WMI イベントの発生後にアラートを発行するように SQL Server エージェントを構成できます。SQL Server エージェントでは、オペレーティング システムや他の WMI プロバイダから発行される WMI イベントだけでなく、SQL Server の WMI イベントにも応答します。
メモ リモートの WMI イベントに対する SQL エージェントの応答は、サポートされません。ただし、経験豊富なユーザーであれば、レジストリを編集して、リモートの WMI イベントに対応できます。HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.X\SQLServerAgent サブキーの下に DWORD レジストリ エントリ AlertAllowWMIRemoteEvents を追加して、値を 1 に設定します。設定したら、SQL Server エージェント サービスを再起動します。
注意 レジストリの編集を誤ると深刻な問題が発生し、オペレーティング システムの再インストールが必要になる場合があります。レジストリの編集ミスによる問題の解決については、Microsoft では保証いたしかねます。レジストリを編集する前に、重要なデータはバックアップをとってください。
WMI イベント アラートの例
"My Agent Operator" という SQL Server エージェントのオペレータが、システムに定義されています。My Agent Operator は、net send コマンドを使用して、メッセージを "jeffprice-yukon" というワークステーションに送信するように設定されています (例 1)。
メモ net send を通知メソッドとして使用する場合、SQL Server エージェントをホストするサーバーでメッセンジャ サービスが起動していることを確認してください。起動していない場合、net send 通知を受信できません。
USE [msdb]
GO
EXEC msdb.dbo.sp_add_alert @name=N'Alert when database is created',
@enabled=1,
@delay_between_responses=0,
@include_event_description_in=4,
@wmi_namespace=N'\\.\root\Microsoft\SqlServer
\ServerEvents\MSSQLSERVER',
@wmi_query=N'SELECT * FROM CREATE_DATABASE""'
GO
USE [msdb]
GO
exec sp_add_notification @alert_name=N'Alert when database is created'
,@operator_name=N'My Agent Operator'
,@notification_method=4
上記のコード例では、sp_add_alert: wmi_namespace と wmi_query の下に 2 つの新しいパラメータがあります。wmi_namespace は、SQL Server エージェントでイベントを探すときに使用する WMI の名前空間です。
メモ SQL Server 2005 は、ローカル サーバーで発行された WMI イベントのみをサポートしています。
wmi_query は WQL クエリです。SQL Server エージェントで、応答するイベントを特定するときに使用されます。
上記のコードに基づいてアラートを作成してから、新しいデータベースを作成します。30 秒以内に、"Alert when database is created (データベースの作成時にアラートする)" のアラートが送信されたことを示すメッセージを確認できます。
図 3 "Alert when database is created (データベースの作成時にアラートする)" のアラート
SQL Server エージェントのレジストリを編集して、時間遅延を既定の 30 秒から変更できます。HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\MSSQL.x\SQLServerAgent の下にあるレジストリ キーを "30" から変更します。
次のキーは、SQL Server エージェントの WMI イベントに影響を及ぼします。
EventWMILimit |
REG_DWORD |
既定 = 5 |
EventWMIPeekInterval |
REG_DWORD |
既定 = 30 |
EventWMIPeekInterval は、SQL Server エージェントに対し、WMI イベントを探す回数を指示します。EventWMILimit は、SQL Server エージェントに対し、WMI イベント キューの確認ごとに消費するイベント数を指示します。
トークン
SQL Server の以前のバージョンでは、SQL Server エージェントの機能として、ジョブ ステップ コマンド、出力ファイル、アラートにおいて、トークンを使用して実行時に文字列をパースする機能と置換する機能がありました。SQL Server 2005 の SQL Server エージェントでは、トークンに使用する構文が "[X]" から "$(X)" に変わりました (X はトークン名)。そのため、トークン名は、既存のデータベース オブジェクトと競合しなくなりました。構文変更の他、SQL Server エージェントでは、WMI トークンが追加されました。これによって、WMI イベントからの情報を送信できます。
WMI イベント アラートの例
次のコードでは、SQL Server から発行される CREATE_DATABASE の WMI イベントに基づいて、SQL Server エージェントのアラートを作成します。このアラートで、新規に作成されたデータベースをバックアップするための新しいジョブを、動的に作成するジョブを実行します。
まず、"Automatically create a backup job (自動的にバックアップ ジョブを作成する)" という SQL Server エージェント ジョブを作成します。このジョブでは、次の操作を行います。
WMI イベントで提示されたソース データベースのプロパティに基づいた名前を持つ、新しいジョブを作成します。
1 つの Transact-SQL ステップを追加して、データベースを定義済みのバックアップ デバイス (この例では "MyBackups") にバックアップします。
メモ このスクリプトを実行するには、"MyBackups" というバックアップ デバイスを作成する必要があります。
use msdb exec sp_add_job @job_name=N'Automatically create a backup job' GO exec sp_add_jobstep @job_name=N'Automatically create a backup job', @subsystem=N'TSQL', @database_name=N'MSDB', @on_success_action=3, @step_name=N'Create Backup Job', @command=N'sp_add_job @job_name=N''Backup $(WMI(DatabaseName))''' GO exec sp_add_jobstep @job_name=N'Automatically create a backup job', @subsystem=N'TSQL', @database_name=N'MSDB', @on_success_action=3, @step_name=N'Add Backup Step', @command=N'sp_add_jobstep @job_name=N''Backup $(WMI(DatabaseName))'' ,@step_name=N''Issue Backup Command'' ,@database_name=N''MSDB'' ,@command=N''BACKUP DATABASE $(WMI(DatabaseName)) TO MyBackups''' GO exec sp_add_jobstep @job_name=N'Automatically create a backup job', @subsystem=N'TSQL', @step_name=N'Give job a jobserver', @database_name=N'MSDB', @command=N'sp_add_jobserver @job_name=N''Backup $(WMI(DatabaseName))''' GO exec sp_add_jobserver @job_name=N'Automatically create a backup job' GO
次に、SQL Server サービス マネージャから発行される CREATE_DATABASE WMI イベントに基づいて、アラートを追加します。
EXEC msdb.dbo.sp_add_alert @name=N'Alert when database is created',
@job_name=N'Automatically create a backup job',
@wmi_namespace=N'\\.\root\Microsoft\SqlServer
\ServerEvents\MSSQLSERVER',
@wmi_query=N'SELECT * FROM CREATE_DATABASE '
GO
このスクリプトの実行後、"HR_Dev" というデータベースを新しく作成します。既定の WMI ピーク間隔 (30 秒) 以内に、"Backup HR_Dev" という SQL Server エージェント ジョブを確認できます。Backup HR_Dev で、HR_Dev データベースをバックアップできるようになりました。Backup HR_Dev にスケジュールを自動的に追加するという別のオプションもあります。
SQL Server エージェントのセッション
SQL Server エージェント サービスが起動するたびに、セッション番号を割り当てられた新しいセッションが作成されます。このセッション番号は、増分する整数で、msdb の syssessions テーブルに格納されます。クエリ (select * from msdb..syssessions) を syssessions テーブルで実行すると、表 1 の結果がわかります。
表 1 syssessions テーブルの一覧
Session_id |
Agent_start_date |
---|---|
1 |
2004-03-16 15:51:04.897 |
2 |
2004-03-18 16:12:52.770 |
3 |
2004-03-19 15:01:22.677 |
表 1 は、SQL Server エージェント サービスが 3 回起動され、最後に起動されたのが 2004 年 3 月 19 日 15:01 であったことを示しています。
また、SQL Server エージェントによって、現在のセッションに基づいて、リアルタイムのジョブ アクティビティを列挙する新しいストアド プロシージャも提供されます。query sp_help_jobactivity を実行すると、すべてのアクティブな SQL Server エージェント ジョブが一覧されます (表 2)。
メモ 表 2 に示すジョブは、毎日 15:00 に実行するようにスケジュールされています。
表 2 sp_help_jobactivity 一覧 (一部)
session_id |
job_name |
next_scheduled_run_date |
... |
... |
... |
---|---|---|---|---|---|
3 |
Full Backup HR DB |
2004-03-20 15:00:00 |
|
|
|
3 |
OLAP DB Prep |
2004-03-20 15:00:00 |
|
|
|
リアルタイムのジョブ アクティビティを列挙するこの新しいストアド プロシージャには、msdb の sysjobactivity テーブルにあるデータの一部が含まれます。sysjobactivity テーブルは、SQL Server エージェントの現在のセッションと過去の全セッションに関するジョブ ステータス情報を格納する場所です。
SQL Server エージェント サービスに予期しないエラーが発生した場合、その前のセッションについての sysjobactivity テーブルを確認することで、実行途中であった SQL Server エージェント ジョブを判断できます。表 3 は、sysjobactivity テーブルのフィールドの一部を示しています。
表 3 sysjobactivity 一覧 (一部)
session_id |
job_name |
run_requested_date |
start_execution_date |
stop_execution_date |
next_scheduled_run_date |
---|---|---|---|---|---|
1 |
Full Backup HR DB |
2004-03-16 15:00:04 |
2004-03-16 15:00:07 |
2004-03-16 15:04:23 |
2004-03-16 15:00:00 |
1 |
OLAP DB Prep |
2004-03-16 15:00:02 |
2004-03-16 15:00:09 |
2004-03-16 15:04:01 |
2004-03-16 15:00:00 |
2 |
Full Backup HR DB |
2004-03-19 15:00:03 |
2004-03-19 15:00:07 |
NULL |
2004-03-19 15:00:00 |
2 |
OLAP DB Prep |
2004-03-19 15:00:02 |
2004-03-19 15:00:06 |
NULL |
2004-03-19 15:00:00 |
3 |
Full Backup HR DB |
NULL |
NULL |
NULL |
2004-03-20 15:00:00 |
3 |
OLAP DB Prep |
NULL |
NULL |
NULL |
2004-03-20 15:00:00 |
表 3 によると、Full Backup HR DB ジョブと OLAP DB Prep ジョブはエラーのため完了していません。原因は、stop_execution_date 列にエントリがないためです。
run_requested date は、スケジューラから SQL Server エージェント サービスに対して、ジョブの実行時間であることを通知する時刻を示します。
start_execution_date は、SQL Server エージェント サービスがジョブの実行を開始する時刻を示します。
stop_execution_date は、SQL Server エージェント サービスがジョブの実行を完了する時刻を示します。
next_scheduled_run_date は、ジョブの実行後に計算されます。
SQLIMail のサポート
SQL Server 2005 の SQL Server エージェントでは、新たに SMTP ベースの SQLIMail を使用します。エージェントでの SQLIMail 使用を有効にするには、SQLIMail 構成ウィザードを実行し、msdb を mailhost データベースとして定義します。ウィザードでの定義が終了したら、SQL Server エージェントのプロパティにある [アラート] タブを開いて、SQL Server エージェントでメールの送信時に使用する SQLImail のプロファイルを定義します。SQLIMail を使用する場合は、MAPI のプロファイルを定義する必要はありません。
メモ SQL Server エージェントで使用するメール システムを変更する場合、変更内容を有効にするためにはサービス起動が必要です。
ストアド プロシージャの変更
SQL Server エージェントの新しいストアド プロシージャのほとんどは、新しい共有スケジュール機能に対応するものです。表 4 で、新しい各ストアド プロシージャについて簡単に説明します。
表 4 新しいストアド プロシージャ
ストアド プロシージャ |
説明 |
---|---|
sp_add_schedule |
任意の数のジョブで使用できるスケジュールを作成します。 |
sp_update_schedule |
SQL Server エージェントのスケジュール設定を変更します。 |
sp_delete_schedule |
スケジュールを削除します。 |
sp_attach_schedule |
ジョブのスケジュールを設定します。 |
sp_detach_schedule |
スケジュールとジョブ間の関連付けを削除します。 |
sp_help_schedule |
スケジュール情報を一覧します。 |
Sp_help_jobactivity |
SQL Server エージェント ジョブの実行時の状態に関する情報を一覧します。 |
Sp_notify_operator |
SQLiMail を使用して、オペレータに電子メール メッセージを送信します。 |
Sp_add_proxy |
指定した SQL Server エージェント プロキシを追加します。 |
Sp_delete_proxy |
指定したプロキシを削除します。 |
Sp_update_proxy |
既存プロキシのプロパティを変更します。 |
Sp_help_proxy |
1 つ以上のプロキシに関する情報を一覧します。 |
Sp_grant_proxy_to_subsystem |
サブシステムに対するアクセス権限をプロキシに付与します。 |
Sp_grant_login_to_proxy |
プロキシに対するアクセス権限をセキュリティ プリンシパルに付与します。 |
Sp_revoke_login_from_proxy |
プロキシに対するアクセス権限をセキュリティ プリンシパルから削除します。 |
Sp_revoke_proxy_from_subsystem |
サブシステムに対するアクセス権限をプロキシから削除します。 |
Sp_enum_proxy_for_subsystem |
指定したサブシステムに対するアクセス権限を持つプロキシ アカウントを一覧します。 |
Sp_enum_login_for_proxy |
指定したプロキシ アカウントに対するアクセス権限を持つログインを一覧します。 |
Sp_help_jobcount |
スケジュールが割り当てられているジョブ数を提示します。 |
Sp_help_jobs_in_schedule |
特定のスケジュールが割り当てられているジョブに関する情報を返します。 |
Sp_cycle_agent_errorlog |
現在の SQL Server エージェントのエラー ログ ファイルを閉じ、SQL Server エージェントのエラー ログの拡張番号を循環させます (サーバーの再起動と同じ結果になります)。 |
Sp_purge_jobhistory |
ジョブの履歴を削除します。 このストアド プロシージャに @oldest_date パラメータが追加されました。これで、特定の SQL Server エージェント ジョブの SQL Server エージェント履歴をすべて削除できるようになりました。同様に、ストアド プロシージャを呼び出して、指定した日付よりも古い場合に、ジョブの履歴をすべて削除することもできます。 |
まとめ
SQL Server 2005 Beta 2 の SQL Server エージェントは、SQL Server の以前のバージョンと比較して、セキュリティ設計がより強固になりました。設計の改善によって、エージェント サービスの管理に必要な柔軟性が向上しました。さらに、パフォーマンスの向上で、従来の SQL Server エージェントよりもジョブの処理量が多くなりました。SQL Server エージェントでは、分析サービスやデータ変換サービス (DTS) など、他の SQL Server 機能を使用するジョブ ステップをネイティブでサポートするようになりました。このドキュメントでは、SQL Server 2005 Beta 2 における SQL Server エージェントの主な改善点についてのみ触れました。本ドキュメントに記載されていない機能が他にもあることに留意してください。