 TechNet Magazine April 2008

TechNet Magazine April 2008

SQL Server 2008: 新機能

この新しいバージョンの SQL Server では、パフォーマンス強化、セキュリティ強化、およびデータベース管理者の作業の効率化を約束する多数の新機能と機能強化が施されました。この記事では、その主要な変更点と SQL Server 2008 から期待できるメリットについて概説します。

Randy Dyess SQL Server 2008: セキュリティ

セキュリティは、今もなお SQL Server において、入念に機能強化が行われている分野です。この記事では、法的要件の遵守に役立つ、暗号化と認証の強化点から、ポリシー ベースの管理と新しい監査システムまで、SQL Server 2008 に加えられた、セキュリティ関連の最も重要ないくつかの変更点について説明します。

Rick Byham SQL Server 2008: 新しいデータ型

SQL Server 2008 に組み込まれている 7 つの新しいデータ型を使用すると、より複雑なデータを操作できるだけでなく、構造化されているデータ、半構造化されているデータ、および構造化されていないデータを容易に管理できるようになります。この記事では、これらの新しいデータ型について詳しく説明し、これらを使用してインフラストラクチャ内のデータを容易に管理する方法を紹介します。

Kelly Wilson SQL Server 2008: データ ウェアハウスのクエリ パフォーマンス

SQL Server 2008 では、より強力なリレーショナル データ ウェアハウス機能が提供されます。この記事では、パフォーマンス関連の主要なデータ ウェアハウス機能について詳しく説明し、この新しいテクノロジを使用して、クエリのパフォーマンスを最適化する方法を紹介します。

S. Agarwal, T. Grabs, and J. Hammer SQL Server: SQL Server のブロッキングを最小限に抑える

ロックは、データベースに対して同時に行われる読み取り操作と書き込み操作をサポートするために不可欠な処理ですが、ブロッキングはシステムのパフォーマンスに悪影響を及ぼす可能性があります。この記事では、SQL Server データベースを最適化してブロッキングの発生率を最小限に抑える方法、およびシステムを監視して、ロックがパフォーマンスに与える影響を適切に把握する方法について説明します。

Cherié Warren Microsoft Office: Access データベースを SharePoint と統合する

多くの企業では、依然として Microsoft Access を頼りにしています。さいわいにも、Microsoft Office SharePoint Server 2007 を使用して、既存の Access データを統合することができます。この記事では、これらのツールを使用して、組織で使用する新しいソリューションを作成する方法を紹介します。

Peter Serzo 編集長から: 今まで貢献してくれた仲間と新しい仲間へ

Joshua Hoffman レター: 読者の皆さんからの声

ツールボックス: IT プロフェッショナル向けの新製品

Greg Steen SQL に関する Q&A: データベースの拡張、IFilter の使用、およびリモート接続

プログラムでデータベースを拡張する方法、IFilter の使用法、および SQL Server のリモート接続をサポートするファイアウォールの設定について説明します。

Edited by Matthew Graven ユーティリティ スポットライト: Web Capacity Analysis Tool

Web のログとトラフィック分析は、今後予想されるトラフィックの種類を把握するための手掛かりを得るのに役立ちます。では、インフラストラクチャの処理能力を判断するにはどうしたらよいでしょうか。そのような場合は、無料で利用できる Web Capacity Analysis Tool を使用すると、負荷がかかったときのシステムのパフォーマンスを確認することができます。

Greg Steen The Cable Guy: NAP 強制のトラブルシューティングを行う

ネットワーク アクセス保護プラットフォームにおける強制動作のトラブルシューティングは、困難な作業になる場合があります。この記事では、The Cable Guy が、NAP 正常性ポリシー評価のしくみと、最も一般的な問題のトラブルシューティング方法について説明します。

Joseph Davies Windows PowerShell: 署名をお願いします

AllSigned 実行ポリシーを使用すると、非常に強固なセキュリティで保護された Windows PowerShell 環境を提供することができます。では、Windows PowerShell スクリプトに署名するにはどうすればよいでしょうか。Don Jones がその方法をご紹介します。

Don Jones Hey, Scripting Guy!: 帰ってきたデータベース スクリプト

組織で最も重要な情報は、データベースに格納されていることが多いようです。今月の Scripting Guys は、VBScript を使用してデータベースから情報をすばやく読み取る方法やレコードを追加したり削除したりする方法を紹介します。また、ほんの数行のコードでレコードを更新する方法も紹介します。

The Microsoft Scripting Guys セキュリティ ウォッチ: PII はどこに

個人情報を効果的に保護するには、PC 上のどこに個人情報が保存されているのかを知っておく必要があります。この記事では、コンピュータに保存されている個人データを検索するためのスクリプトを記述する方法を紹介します。これらのスクリプトによって、驚くべきことがわかります。

Frank Simorjay デスクトップ ファイル: WAIK を使用して Windows XP を展開する

Windows 自動インストール キットは、主に Windows Vista と Windows Server 2008 用に設計されましたが、Windows XP と Windows Server 2003 の展開にも役立つことをご存知でしょうか。この記事では、Windows XP と Windows Server 2003 で Windows 自動インストール キットを活用するために必要な情報を提供します。

Wes Miller フィールド ノート: MAR というすばらしい構想

この新しい Microsoft Authorized Refurbisher (MAR) プログラムが、古い PC を再生する際に、ソフトウェアの使用許諾に関する複雑な問題に対応している企業を、どのように支援するのかをご説明します。

Neil Fawcett Windows 秘話: 共有するときは公正に

プログラムを削除するときにアンインストーラによって、"この共有ファイルを削除しますか" というメッセージが表示される理由について、Raymond Chen が解説します。

Raymond Chen


 SQL Server 2008: 新機能
SQL Server 2008 Randy Dyess

新機能
概要:
  • より強力な管理
  • 向上したパフォーマンスとスケーラビリティ
  • 強化されたセキュリティと可用性
  • 開発者向けの変更点

マイクロソフトは再び、データベース管理者の作業の効率化を約束する SQL Server の新しいバージョンをリリースしました。この最新バージョンは、SQL Server 2008 です。SQL Server 2008 では、さまざまな
新機能と、管理を大幅に強化する機能が提供されます。
使用期間の長短を問わず、SQL Server® 2005 を使用したことがあるデータベース管理者であれば、SQL Server 2008 には日常業務で使用している機能と同じ機能を多数見つけられるでしょう。ただし、この新しいバージョンの SQL Server では、このような使い慣れたツールが強化されていることを実感していただけると思います。既存の機能を基盤にした新機能を使用すると、これまで複雑なデータベース環境でさまざまな機能を使用するために必要だった多数の次善策やカスタマイズを効率よく削減できます。
SQL Server 2008 の新機能として、さまざまなデータベース ジョブのロールが追加されたため、このようなロールを分類することは困難です。トピックごとに機能を分類すると、読者の中には機能 X が明らかにカテゴリ Z に属しているのに、カテゴリ Y に分類されていることを不思議に思われる方もいるでしょう。これは観点の問題であって、分類方法は会社の業務の進め方によって異なります。
たしかに、データベース管理者は、多くの場合いつの間にかさまざまな業務を担当しているものですが、ここでは新機能を次の一般的なカテゴリに沿って分類したいと思います。このカテゴリとは、管理、スケーラビリティ、パフォーマンス、高可用性、セキュリティ、開発、およびビジネス インテリジェンスです。

管理に関する新機能
私のようなデータベース管理者にとって、新しく導入された管理機能により、SQL Server 2008 は非常に楽しみな新製品となっています。新しいポリシーの管理、複数サーバーのクエリ機能、構成サーバー、およびデータ コレクタ/データ管理ウェアハウスの各機能は、数十台から数百台ものサーバー上に数十万個のデータベースが展開されている大規模で複雑なデータベース環境の管理を担当することが多いデータベース管理者にとって、新しい強力な武器を提供しています。
SQL Server 2008 ポリシー管理機能は、Community Technology Preview (CTP) では宣言型管理フレームワークと呼ばれていたもので、これを使用すると、1 つまたは複数のデータベース サーバーに対して構成ポリシーを作成して実行できます。このような構成ポリシーを使用すると、対象のサーバーとデータベースのそれぞれに、標準の構成設定が確実に適用および維持されるようにできます。この機能の例を図 1 に示します。
Figure 1 Data and Log File Location Best Practice ポリシー
Figure 1 Data and Log File Location Best Practice ポリシー
ポリシーは、事前に定義された一連のファセットから作成されます。各ファセットには、SQL Server 2008 構成設定と制御可能なその他のイベントのサブグループが保持されています。このファセットと条件を組み合わせて、ポリシーを作成します。条件は、ファセットのプロパティ、構成設定、またはファセットに含まれている他のイベントに設定できる値です。
また、条件は、ポリシーのフィルタに使用される値でもあります。ポリシーを特定のデータベースに対してのみ実行するようにする場合は、そのデータベースの名前を含む条件を作成して、この条件をポリシーに追加します。これで、ポリシーはそのデータベースのみに適用されるようになります。SQL Server 2008 ポリシー管理は複雑に見えますが、一度試してみると非常に直感的に使用できることがおわかりいただけるので、ぜひ一度お試しください。
複数サーバーの対話と構成サーバー機能は、複数のサーバーに対してクエリを同時に実行する必要があるときに便利な新機能です。Management Studio にサーバーを登録し、登録したサーバーをグループ化することができます。ポリシーまたはクエリを、ある特定のグループに含まれるすべてのサーバーに対して実行する必要がある場合は、グループを右クリックするだけで操作を実行できます。
さらに、この機能を構成して、1 台のサーバーごとに結果を返すことも、すべての結果セットをマージして 1 つの大きな結果セットを生成することもできます。また、各サーバーの結果を区別できるように、サーバーとデータベース名を結果に含めるかどうかも指定できます。登録したサーバーを、各 Management Studio ではなく、構成サーバーに保存できるのは、大きなメリットです。
またデータ コレクタという別の便利な新しい管理機能もあります。データベース管理者は、多数のサーバーから管理データを収集しなければならないことが往々にしてあり、多くのデータベース管理者は、そのために独自のカスタム ソリューションを作成しています。データ コレクタは、管理関連データの収集作業を容易にする組み込みのメカニズムです。データ コレクタを利用すると、SQL Server エージェントと SQL Server Integration Services (SSIS) を使用して、エラー処理、監査、収集履歴機能がある、データを収集して保存できるフレームワークを作成できます。
データ コレクタでは、SQL Server エージェントと SSIS によって、データへの接続、収集、保存を処理する一連のジョブが作成およびパッケージ化されるため、サードパーティ製のツールやカスタム ジョブと異なり、データ コレクタはほとんどのデータベース管理者が簡単に理解できます (図 2 参照)。管理ウェアハウスと呼ばれる集中管理用の場所にデータが保存されると、T-SQL ステートメントや SQL Server 2008 Reporting Services のレポートを使用して、データを表示したりまとめたりできます。この集中管理用のデータ ストアにより、データベース環境の全体的な管理データの分析と表示がかなり楽になります。
Figure 2 データ コレクタのディスク使用量についてのログ ファイル
Figure 2 データ コレクタのディスク使用量についてのログ ファイル

スケーラビリティに関する新機能
年を追うごとに、SQL Server のデータベース環境はますます規模が大きくなってきています。データベース環境の規模が大きくなるにつれて、ほとんどの企業で必要とされるスケーラビリティを実現するための新しい方法やツールが必要になります。SQL Server 2008 には、このようなスケーラビリティを実現するのに役に立ついくつかの新機能が導入されています。
SQL Server 2008 には圧縮機能が組み込みまれており、この機能を使用するとデータベース ファイルと、そのデータベースに関連付けられたトランザクション ログ ファイルを圧縮できます。SQL Server 2005 では、読み取り専用のファイルやファイル グループのデータ圧縮機能が導入されましたが、この圧縮は単に Windows® NTFS の圧縮機能を使用したものでした。SQL Server 2008 では、行レベルとページ レベルの圧縮が可能になり、データ ファイル レベルでの圧縮では得られないメリットを享受できます。
行レベルとページ レベルの圧縮では、必要なデータ領域が少なくなるだけでなく、データはメモリ内にある場合も圧縮された状態であるため、必要なメモリ量も少なくなります。メモリ内でもデータが圧縮された状態を維持することにより、メモリの利用効率が高まり、多くのシステムのスケーラビリティが向上します。
SQL Server 2008 では、バックアップ レベルでの圧縮機能も導入されています。データベースのバックアップでは、データベースの変更された部分のみがバックアップされますが、それでも数百 GB から数十 TB ものデータが処理されます。数 TB サイズのバックアップ ファイルが複数あるデータベース環境では、他に有効活用できるであろう貴重な記憶域が、このようなバックアップ ファイルに使われていることが多くあります。SQL Server 2008 では、バックアップ ファイルを圧縮することで、このような領域を解放し、運用データに使用できるようにしています。
また、リソース ガバナという機能もあります。この新機能を使用すると、個々のワークロードまたは一群のワークロードが実行時に使用できるリソース量を定義できます。リソース ガバナを使用すると、1 つまたは複数のワークロードが原因でサーバーのリソース不足が発生したり、他のワークロードのパフォーマンスが低下したりすることを心配することなく、同じサーバー上で多数の異なるワークロードを実行できる環境を作成できます。
この機能のメリットは、データベース サーバーで利用できるリソースのすべてをより有効に使用できることです。図 3 に、リソース ガバナを使用して特定のサーバーで行われる処理を制限するコードの例を示します。
Figure 3 Limit activity with the Resource Governor (Close Figure 3)
USE master
go

--Drop function
IF OBJECT_ID('rgclassifier_demo','Function') IS NOT NULL
DROP FUNCTION rgclassifier_demo
go

--Create a classifier function for report group
CREATE FUNCTION rgclassifier_demo() RETURNS SYSNAME
WITH SCHEMABINDING
AS
BEGIN
    DECLARE @group_name AS SYSNAME
  IF (USER_NAME() LIKE '%Launch_Demo%')
         SET @group_name = 'demogroup'
    RETURN @group_name
END
GO

--Drop workload group for anything coming from Management Studio
IF EXISTS (SELECT name FROM sys.resource_governor_workload_groups
  WHERE name = 'demogroup')
BEGIN
  DROP WORKLOAD GROUP demogroup
END
GO

--Create workload group
CREATE WORKLOAD GROUP demogroup
GO

--Register the classifier function with
--Resource Governor
ALTER RESOURCE GOVERNOR WITH (CLASSIFIER_FUNCTION= dbo.rgclassifier_demo)
GO

--Alter the dbogroup workload group to only
--allow 10% of CPU for each workload request
ALTER WORKLOAD GROUP demogroup
WITH (REQUEST_MAX_CPU_TIME_SEC = 10)
GO

--Create a new resource pool and set a maximum CPU limit for all workloads.
IF EXISTS (SELECT name FROM sys.resource_governor_resource_pools
  WHERE name = 'pooldemo')
DROP RESOURCE POOL pooldemo
GO

CREATE RESOURCE POOL pooldemo
WITH (MAX_CPU_PERCENT = 40)
GO

--Configure the workload group so it uses the
--new resource pool.
ALTER WORKLOAD GROUP demogroup
USING pooldemo
GO

--Apply the changes to the Resource Governor
--in-memory configuration.
ALTER RESOURCE GOVERNOR RECONFIGURE
GO

パフォーマンスに関する新機能
SQL Server 2008 では、データベースのパフォーマンスが全体的に向上しています。SQL Server 2008 のいくつかの新機能により、データベースとデータベースに対して実行されるアプリケーションのパフォーマンスを制御および監視することができます。
毎秒多数のトランザクションを実行すると、トランザクションの処理中に通常発生するロックによって、データベース アプリケーションのパフォーマンスが低下することがあります。SQL Server は、ロックを行レベルやページ レベルという小さな単位のロックから、テーブル レベルのロックにエスカレートすることで、プロセスが保持するロックの総数を削減しています。ただし、このロックのエスカレートが原因で、問題が発生する可能性があることに注意してください。たとえば、ある 1 つのトランザクションがテーブル全体をロックしていることが原因で、他のトランザクションがこのテーブルを操作できなくなることがあります。
SQL Server 2008 では、テーブルのパーティション分割メカニズムを使用して、テーブル レベルの前にパーティション レベルへのロックのエスカレートを実現しています (このメカニズムは SQL Server 2005 で導入されました)。この中間レベルのロックによって、毎秒数十万件のトランザクションを処理する必要があるシステムで、ロックのエスカレーションによる影響が大幅に軽減されます。
SQL Server 2008 では、クエリがパーティション テーブルを処理するときのパフォーマンスの向上に役立つ、クエリ プロセッサの機能強化もいくつか導入されています。クエリ オプティマイザでは、テーブル レベルでのパーティション分割メカニズムではなく、パーティション ID のみを使用して、個々のインデックスに対する場合と同様に、パーティションに対してクエリのシークを実行できるようになりました。

高可用性に関する新機能
データベース環境がより複雑になり、データベースのサイズが大きくなるにつれて、データベースの可用性を確保することがますます困難になっています。これまで高可用性を実現するために使用してきた従来のメカニズムは、SQL Server 2008 でも提供されています。SQL Server 2008 では、このような機能のいくつかが強化されているだけでなく、いくつかの新機能も追加されています。
SQL Server 2005 では、多くの管理者が、高可用性を実現するために、データベース ミラーリングの実装を始めました。SQL Server 2008 では、データベース ミラーリングに関するさまざまな機能強化が施されました。たとえば、これまでは、データベース ミラーリングを行うと、プリンシパル データベースからミラー データベースにトランザクション ログ データを移動するときに、パフォーマンス上の問題が発生することがありました。その対応策として、SQL Server 2008 では、データを書き込むためにミラーのトランザクション ログにデータの送信を開始する前にデータを圧縮して、プリンシパルのトランザクション ログからミラーのトランザクション ログにネットワークを介して移動される情報量を削減しています。
また、プリンシパル データベース内の破損したデータ ページを修復できるようになりました。エラー 823 とエラー 824 が原因で、プリンシパル データベースのデータ ページが破損している場合、プリンシパル データベースでは、ミラー サーバーから破損したデータ ページの正常なコピーを取得することができます。この正常なデータ ページの要求は、現在プリンシパル データベースにアクセスしているユーザーに意識されることなく、自動的に処理されます。
ホット アド CPU という別の新機能により、サーバー上のデータベースに影響することなく、そのデータベース サーバーに新たに CPU を追加できます。ただし、ホット アド CPU には制限事項があります。この機能を使用するには、64 ビットの Itanium ベースの Windows Server® 2008 Enterprise Edition または Datacenter Edition と、SQL Server 2008 Enterprise Edition を実行している必要があることに注意してください。

セキュリティに関する新機能
SQL Server 2005 では、データ暗号化という形でデータ セキュリティが導入されました。SQL Server 2008 では、拡張キー管理および透過的なデータ暗号化という 2 つの新機能によって、暗号化が大幅に強化されています。
拡張キー管理を使用すると、データベース内だけでなく、サードパーティのソフトウェア モジュールやハードウェア セキュリティ モジュールなどデータベース外も含め、暗号化インフラストラクチャで使用されるキーを安全に保存できる拡張構造を実現できます。
透過的なデータ暗号化を使用すると、コード内の関数の結果だけでなく、データベースの暗号化を可能にすることで、より柔軟にデータを暗号化できます。結果として、管理者は、データ レベルでの暗号化を実行する際にデータベース構造やアプリケーション コードに対して多くの変更を行う必要がなくなります。図 4 のコードでは、透過的なデータ暗号化を使用してデータベースを暗号化する方法の例を示しています。
Figure 4 Using Transparent Data Encryption (Close Figure 4)
USE master;
GO

--Create a master key
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'YouWillNeedToCreateAStrongPassword';
GO

--Create a certificate to use with TDE
CREATE CERTIFICATE TDECERT WITH SUBJECT = 'TDECert'
GO

--Change to the database to encrypt
USE AdventureWorks
GO

--Create your database master key
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_128 --Use a strong algorithm
ENCRYPTION BY SERVER CERTIFICATE TDECERT
GO

--Alter the database to encrypt it with the
--master database key
ALTER DATABASE AdventureWorks
SET ENCRYPTION ON
GO

開発者向けの新機能
SQL Server 2008 に加えられた変更のメリットを直接享受できるのは、データベース管理者だけではありません。データベース開発者の支援を目的とした多くの新機能があります。これには、T-SQL のいくつかの新しい強化機能や、データベース クエリを作成および使用する際に役立つ新しいコンポーネントなどがあります。
多くのデータベース開発者は、アプリケーションに必要なデータを返すために必要とされるクエリを作成しています。おそらく、標準の T-SQL ステートメントではなく、Microsoft® .NET ベースのプログラミング言語を使用して、データベースをクエリできるようにする LINQ (統合言語クエリ) ツールについてはよくご存知だと思います。SQL Server 2008 では、LINQ コマンドを SQL Server のテーブルや列に対して直接発行できるようにする LINQ to SQL という新しいプロバイダを提供することで、LINQ を強化しています。このプロバイダにより、新しいデータ クエリの作成にかかる時間が短縮されます。
データベースを使用する開発では、個々のデータベース テーブルや列にマップする上位オブジェクトが使用されます。このようなオブジェクトはエンティティとも呼ばれ、データベース アプリケーションで必要なデータを表現しています。そのため、開発者は、データベースのスキーマやデータが格納されている実際の構造を理解する必要がありません。新しい ADO.NET Entity Framework を使用すると、このようなエンティティを使用してデータベース クエリを作成できます。基盤のデータベース構造の抽象化により、開発者の生産性が向上します。
SQL Server 2008 では、データベース開発者の効率を向上するさまざまな機能強化が T-SQL に施されています。その 1 つには、MERGE という新しいステートメントがあります。このステートメントを使用すると、データの挿入を行う前にデータの存在を確認できます。この確認を INSERT ステートメントの実行前に行うと、データを更新することが可能になります。データが存在する場合は更新し、存在しない場合はデータを挿入するという処理を行うために、複雑な結合を作成する必要はなく、これらの一連の処理を 1 つのステートメントでまとめて行えるようになりました。
また、複合的なデータ型の日付と時刻データ型から、時刻データと日付データを分離しやすくなりました。SQL Server 2008 では、日付データと時刻データを処理する 2 つの個別のデータ型が導入されています。個別のデータ型を使用することで、データをクエリで使用するために事前に操作する必要がなくなったため、多くのクエリのパフォーマンスが向上します。
新しいデータベース構造を作成するときには、データベースの構造を拡張して、マッピング アプリケーションを実装することが多くあります。SQL Server 2008 では、この問題の対応策として新しい空間データを導入しています。GEOGRAPHY および GEOMETRY という 2 つの空間データ型では、場所固有のデータを直接データベースに保存できるので、このようなデータ要素を他の標準のデータ型に合うように分割する必要がありません。図 5 は、簡単な空間データ型を使用したテーブルの例です。
Figure 5 A simple spatial table (Close Figure 5)
IF OBJECT_ID ( 'Demo_SpatialTable', 'Table' ) IS NOT NULL
    DROP TABLE Demo_SpatialTable
GO

--Create table to hold spatial data
CREATE TABLE Demo_SpatialTable
    ( SpatialID int IDENTITY (1,1),
    SpatialInputCol geography,
    SpatialOutputCol AS SpatialInputCol.STAsText() )
GO

--Insert data into table
INSERT INTO Demo_SpatialTable (SpatialInputCol)
VALUES (geography::STGeomFromText('LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326));

INSERT INTO Demo_SpatialTable (SpatialInputCol)
VALUES (geography::STGeomFromText('POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));
GO

--View data to see that data has been converted and stored in col2
SELECT * FROM Demo_SpatialTable
これまでデータース開発者が抱えていた非常に一般的な問題の 1 つは、ドキュメント ファイルやメディア ファイルのようなバイナリ ラージ オブジェクトをどのようにして保存して、使用するかということでした。この問題の一般的な対策としては、ファイルをデータベースの外部に保存して、データベースには、その外部ファイルへのポインタのみを保存する方法が使用されていました。ただし、この方法では、ファイルを移動するときには、忘れずにポインタを更新する必要があります。
SQL Server 2008 では、FILESTREAM という新しいデータ型によりこの問題に対応しています。このデータ型を使用すると、ファイルをデータベースの外部に保存しても、データベースでは、外部ファイルのデータがトランザクションの一貫性を確保する対象として扱われます。その結果、一般的なファイル操作が可能でありながら、データベースのパフォーマンスとセキュリティのメリットも得られます。

ビジネス インテリジェンスに関する新機能
この数年間の SQL Server の導入拡大の大きな原動力となっているのは、ビジネス インテリジェンス戦略の採用です。ビジネス インテリジェンス機能は、SQL Server にとって新しいものではありませんが、SQL Server 2008 ではテーブルにいくつかの新機能を追加しています。
たとえば、データをデータ ウェアハウスに保存すると、NULL 値により領域が無駄に使用されることが多くあります。NULL 値を保持する列では、列に定義されている最大データ サイズ分の領域が使用されます。つまり、数千もの NULL 値を保持する列では、データを実際に保持していないにもかかわらず、数 MB 分もの領域を使用している可能性があります。
SQL Server 2008 では、ディスク上の物理的な領域を使用せずに NULL 値を保持できるスパース列が導入されました。スパース列は実際の領域を使用しないため、スパース列を含むテーブルは、制限である 1,024 列を超える列数を保持できます。
SQL Server 2008 では、データ ウェアハウスに読み込む必要がある増分 (変更内容) を管理するための新しいメカニズムである Change Data Capture も導入されています。このメカニズムでは、変更されたデータをキャプチャして、一連の変更テーブルに保存します。更新、削除、および挿入されたデータを使いやすいストレージ スキーマにキャプチャすることで、テーブルからのデータ ウェアハウスへの増分読み込みを実現しています。データ ウェアハウスを更新する前に、既存のデータ行に加えられた変更を特定するためのカスタムの Insert ステートメントを作成する必要はありません。

まとめ
この記事では、SQL Server 2008 の機能について簡単に概説しました。SQL Server 2008 では、データベース管理者とデータベース開発者の両方に役立つ、さまざまな新機能と既存機能の強化が提供される予定です。その結果、かつてないほど要件が厳しい現在のデータベースのパフォーマンスとスケーラビリティが大幅に向上されるでしょう。

Randy Dyess は Solid Quality Mentors のよき指導者で、専門は SQL Server OLTP システムです。『Transact-SQL Language Reference Guide』の著者であり、『MCTS Self-Paced Training Kit: Microsoft SQL Server 2005 Implementation and Maintenance (Exam 70-431)』の共著者であるほか、数々の雑誌やニュースレターの記事を執筆しています。また、North Texas SQL Server Users Group のプログラム ディレクターも務め、SQL Server の MVP 資格保有者でもあります。blogs.solidq.com/EN/rdyess/default.aspx では、ブログも公開されています。
© 2007 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.


 SQL Server 2008: セキュリティ
SQL Server 2008 Rick Byham

セキュリティ
概要:
  • 暗号化の強化点
  • 認証の強化点
  • セキュリティ監査
  • ポリシー ベースの管理

SQL Server 2008 には、データベース環境全体のセキュリティを強化するようにデザインされた、多くの機能強化と新機能が用意されています。SQL Server 2008 では、キー暗号化機能と認証機能が追加され、新しい監査システムが導入されています。
これは、ユーザー操作を把握したり、法的要件を遵守したりするうえで役立ちます。
この記事では、SQL Server® 2008 のセキュリティに関する最も重要な変更点の概要について説明します。システム管理者が最初に気付く変更点の 1 つに、SQL Server 2005 セキュリティ構成ツールの廃止があります。SQL Server 2008 では、セキュリティ構成ツールで提供されていたプロトコル オプションは、構成マネージャ ツールで提供されていますが、機能の有効化と無効化には、SQL Server 2008 で新しく導入されたポリシー ベースの管理フレームワークを使用します。

暗号化の強化点
暗号化に関しては、主に 2 つの強化点があります。第 1 に、SQL Server 2008 では、外部のサードパーティ製ハードウェア セキュリティ モジュールに格納された暗号化キーを使用できます。第 2 に、SQL Server に格納されたデータを、データベースに接続するアプリケーションに透過的な方法で暗号化できます。つまり、データベース管理者は、既存のアプリケーション コードを変更する必要なく、データベース全体に格納されたすべてのデータを簡単に暗号化できます。
第 1 の強化点は、拡張キー管理 (EKM) という新機能により実現されました。この機能は、SQL Server 2008 Enterprise Edition、Developer Edition、および Evaluation Edition で使用できます。EKM により、エンタープライズのキー管理やハードウェア セキュリティ モジュール (HSM) ソリューションを提供しているサードパーティ ベンダは、SQL Server にそれぞれのデバイスを登録できます。デバイスが登録されると、ユーザーは、このようなモジュールに格納された暗号化キーを使用できるようになります。
これらのベンダは、それぞれのモジュールで高度暗号化機能 (キーの有効期間や回転など) を提供することもできます。一部の構成では、高度暗号化機能を使用することで、sysadmin グループのメンバではないデータベース管理者からデータを保護できます。また、T-SQL 暗号化ステートメントでは、外部 EKM デバイスに格納されたキーを使用して、データの暗号化と暗号化解除を実行できます。
第 2 の強化点である透過的なデータ暗号化により、アプリケーションを変更する必要なく、データベース ファイルを暗号化できます。この機能では、データ ファイルとログ ファイルのリアルタイム I/O の暗号化と暗号化解除が実行されます。暗号化では、データベース暗号化キー (DEK) が使用され、DEK は、復旧時に使用できるようにするためデータベースのブート レコードに格納されます。DEK は、サーバーの master データベースに格納された証明書で保護されています。図 1 は、透過的なデータ暗号化を可能にするアーキテクチャを示しています。
Figure 1 透過的なデータ暗号化のアーキテクチャ
Figure 1 透過的なデータ暗号化のアーキテクチャ
これは、非アクティブなデータの保護に役立ちます。機密資産の暗号化やデータベース サーバーの外側にファイアウォールを配置するなど、データベースのセキュリティ保護に役立ついくつかの予防措置を講じることができますが、データベースが格納されている物理メディアによって (バックアップ テープを含む)、異なる脆弱性がもたらされます。たとえば、悪意のあるユーザーが、このメディアを盗み、格納されているデータにアクセスする可能性があります。
ただし、透過的なデータ暗号化により、データベース内の機密データを暗号化し、データの暗号化に使用されるキーを証明書で保護することができます。これは、組織で、データの適切な保護に関する多数の法律、規制、および業界ガイドラインを遵守するのに役立ちます。
透過的なデータ暗号化により、ソフトウェア開発者は、高度暗号化標準 (AES) 暗号化アルゴリズムと Triple Data Encryption Standard (3DES) 暗号化アルゴリズムを使用してデータを暗号化できます。データベース ファイルの暗号化は、ページ レベルで実行されます。ページは、ディスクに書き込まれる前に暗号化され、メモリに読み込まれるときに暗号化解除されます。また、透過的なデータ暗号化が有効になっているデータベースのバックアップ ファイルも、データベース暗号化キーを使用して暗号化されます。
暗号化されたデータベースを復元するには、データベースの暗号化に使用された証明書または非対称キーにアクセスできる必要があります。証明書または非対称キーがないと、データベースを復元できないので、関連バックアップへのアクセスが必要となる可能性がある限り、すべてのキーを保持してください。

認証の強化点
おそらくご存知だと思いますが、Kerberos は、ネットワーク認証プロトコルです。Kerberos を使用すると、ネットワーク上のクライアントとサーバーのエンティティ (またはセキュリティ プリンシパル) を相互認証するための安全性の高い方法を提供できます。Kerberos により、ユーザーは、誘引や介入者攻撃などのセキュリティの脆弱性を軽減できます。Windows® NTLM 認証と比べて、Kerberos は、より安全かつ堅牢で、高いパフォーマンスを提供します。
Kerberos を使用して接続を相互認証するには、SQL Server インスタンスのサービス プリンシパル名 (SPN) が Active Directory® に登録され、接続時には、クライアント ドライバで登録された SPN が提供される必要があります。SQL Server 2008 では、Kerberos 認証は、TCP、名前付きパイプ、共有メモリ、仮想インターフェイス アダプタ (VIA) など、すべてのネットワーク プロトコルに対応するように拡張されています。既定では、クライアント ドライバによって、接続先の SQL Server インスタンスの適切な SPN が自動的に推測されます。セキュリティ、制御、およびトラブルシューティングの強化のため、接続文字列パラメータで SPN を明示的に指定することもできます。
インターネット インフォメーション サービス (IIS) では、ASP.NET、レポート マネージャ、またはレポート サーバー Web サービスへのアクセスが提供されなくなります。SQL Server 2008 の Reporting Services では、Windows ベースの認証とカスタム認証をサポートする新しい認証サブシステムで、すべての認証要求が処理されます。
Reporting Services では、SQL Server 共通言語ランタイム (CLR) に組み込まれた Microsoft® .NET Framework と ASP.NET のテクノロジがホストされ、OS の HTTP.SYS 機能も使用されます。レポート サーバーには、サーバーの構成時に定義した URL とポートに送信される要求を受け付ける HTTP リスナが備わっています。URL の予約と登録は、HTTP.SYS を介して、レポート サーバーによって直接管理されます。

セキュリティ監査
SQL Server Audit は、データベース エンジンのイベントに関する独自の監査を作成できる新機能です。この機能では、拡張イベントを使用して監査に関する情報が記録され、さまざまなサーバーとデータベース オブジェクトの監査を有効、保存、および表示するのに必要なツールとプロセスが提供されます。
また、SQL Server Audit は SQL Server トレースよりも高速で、SQL Server Management Studio を使用すると、監査ログを簡単に作成して監視できます。各ユーザーが実行した SELECT、INSERT、UPDATE、DELETE、REFERENCES、および EXECUTE ステートメントをキャプチャして、さらに詳細な監査を行うこともできます。さらに、SQL Server Audit は、T-SQL ステートメント CREATE SERVER AUDIT および CREATE SERVER AUDIT SPECIFICATION と、関連する ALTER ステートメントおよび DROP ステートメントを使用してスクリプトを作成できます。
監査を設定するには、監査を作成し、監査対象のイベントが記録される場所を指定します。監査は、Windows セキュリティ ログ、Windows アプリケーション ログ、または指定場所にあるファイルに保存できます。監査に名前を付け、監査ファイルへのパスやその最大サイズなどの特性を構成します。監査が失敗した場合に SQL Server をシャットダウンするように選択することもできます。また、監査対象のイベントを複数の場所に記録する必要がある場合は、複数の監査を作成するだけです。
次に、1 つまたは複数の監査仕様を作成します。サーバーの監査仕様により、SQL Server インスタンスに関する情報が収集され、ログインやサーバー ロール メンバシップなどのサーバー スコープのオブジェクトが含まれます。また、データベースへのアクセス権など、master データベースで管理されているデータベース情報も含まれます。監査仕様を定義する際には、監視対象のイベントを受信する監査を指定します。複数のサーバーの監査と複数のサーバーの監査仕様を定義することはできますが、各サーバーの監査に含められるサーバーの監査は、一度に 1 つだけです。
単一のデータベースのイベントを監視するデータベースの監査仕様を作成することもできます。監査には複数のデータベースの監査仕様を追加できますが、1 つのサーバー監査で、各データベースに対して有効にできるデータベースの監査仕様は一度に 1 つだけです。
サーバーの監査仕様に使用される SQL Server 監査アクションのイベントは、関連する監査アクションのイベントのコレクションにグループ化されます。このようなイベントは、監査アクションのグループとして公開されます。グループを監査仕様に追加すると、そのグループに含まれるすべてのイベントが監視されます。たとえば、DBCC コマンドを公開する DBCC_GROUP という監査アクションのグループがあります。ただし、DBCC コマンドを個別に監査することはできません。
サーバーに対して使用できる監査アクションのグループが 35 個ありますが、その一部は互いに密接に関連しています。たとえば、SUCCESSFUL_LOGIN_GROUP、FAILED_LOGIN_GROUP、LOGOUT_GROUP などがあります。また、監査プロセスの監査に使用できる AUDIT_ CHANGE_GROUP という監査アクションの種類もあります。
データベースの監査仕様では、データベース レベルの監査アクションのグループに収集された監査アクションのイベントのグループを指定することもできます。監査アクションのグループに加えて、データベースの監査仕様には、データ操作言語ステートメントを監査する個別の監査アクションのイベントを含めることもできます。これらのイベントは、データベース全体または特定のデータベース オブジェクトのみを監視するように構成できます。たとえば、SELECT 監査アクションは、単一のテーブルまたはスキーマ全体に対して実行された SELECT クエリの監査に使用できます。これらのイベントは、特定のユーザーまたはロール (db_writers など) によるアクションを監視するように構成することもできます。
たとえば、SELECT 監査アクションを使用して、ユーザー Mary、FINANCE_DEPT データベース ロール、またはパブリック データベース ロールにより、ある特定のテーブルに対して実行された SELECT クエリを監査できます。この監査アクションにより、必要な監査の作成の制御能力と柔軟性が向上するのは明らかです。

依存関係レポート
依存関係レポートは、新しいカタログ ビューと新しいシステム関数によって強化されています。sys.sql_expression_dependencies、sys.dm_sql_referencing_entities、および sys.dm_sql_referenced_entities を使用すると、スキーマ バインド オブジェクトと非スキーマ バインド オブジェクトの両方について、サーバー間依存関係、データベース間依存関係、およびデータベース SQL 依存関係を報告できます。

新しいデータベース ロール
msdb データベースのデータベース ロールには変更点があります。db_dtsadmin ロールは db_ssisadmin、db_dtsltduser ロールは db_ssisltduser、db_dtsoperator ロールは db_ssisoperator に、それぞれの名前が変更されています。旧バージョンとの互換性をサポートするため、サーバーのアップグレード時に、古いロールは新しいロールのメンバとして追加されます。
これらの変更に加えて、SQL Server 2008 の新機能をサポートするために、新しいデータベース ロールが追加されています。特に、msdb データベースには、サーバー グループ (ServerGroupAdministratorRole と ServerGroupReaderRole)、ポリシー ベースの管理 (PolicyAdministratorRole)、およびデータ コレクタ (dc_admin、dc_operator、および dc_proxy) の新しいロールが含まれています。また、管理データ ウェアハウス データベースにも、データ コレクタ (mdw_admin、mdw_writer、および mdw_reader) の新しいロールが含まれています。

FILESTREAM のセキュリティ
SQL Server では、FILESTREAM ストレージのサポートが導入されました。これにより、SQL Server アプリケーションで、構造化されていないデータ (ドキュメントや画像など) をファイル システムに格納できます。つまり、クライアント アプリケーションでは、構造化されていないデータと対応する構造化されたデータ間のトランザクションの一貫性を維持したまま、ストリーミング API とファイル システムのパフォーマンス向上というメリットを得ることができます。
FILESTREAM データは、FILESTREAM ファイル グループに格納する必要があります。このファイル グループは、実際のファイルではなくファイル システム ディレクトリを含む、特殊なファイル グループです。これらのディレクトリは、データ コンテナと呼ばれ、データベース エンジンのストレージとファイル システムのストレージの間にインターフェイスを提供します。
セキュリティに関しては、FILESTREAM データは他のすべてのデータと同じようにセキュリティで保護され、アクセス許可はテーブル レベルまたは列レベルで付与されます。FILESTREAM コンテナへの NTFS アクセス許可が付与されるアカウントは、SQL Server サービスの実行アカウントだけです。T-SQL トランザクションと OpenSqlFilestream API を使用してアクセスしている場合を除き、データベースが開かれると、SQL Server によって FILESTREAM データ コンテナへのアクセスが制限されます。

ポリシー ベースの管理
SQL Server 2008 のポリシー ベースの管理では、SQL Server を管理するための新しいシステムが提供されます。ポリシーを作成して、SQL Server のさまざまな要素についてテストしたり、報告したりすることができます。また、作成したポリシーは、単一データベース、SQL Server の単一インスタンス、または管理しているすべての SQL Server に適用できます。
ポリシー ベースの管理を使用することで、SQL Server の構成オプションと多くのセキュリティ設定をテストできます。また、一部のセキュリティ設定については、要件を満たしていないデータベース サーバーを検出して、要件に準拠させるための処理を実行するポリシーを作成できます。
SQL Server 2008 では、攻撃を受ける確率を最小限に抑えるため、必須ではない機能の多くが既定で無効になっています。ポリシー ベースの管理を使用して、必要な追加機能を選択して有効にできます。機能を有効にしたら、構成を定期的に評価して、構成設定がポリシーを満たしていない場合には警告が表示されるようにすることができます。
ポリシー ベースの管理では、関連プロパティがまとめてグループ化され、ファセットと呼ばれるコンポーネントとして公開されます。たとえば、セキュリティ構成のファセットには、アドホック リモート クエリ、CLR 統合、データベース メール、OLE オートメーション、リモート DAC、SQL Mail、Web Assistant、および xp_cmdshell のプロパティが含まれます。CLR 統合のみを有効にして、その他すべての機能を無効にするポリシーを作成できます。また、ポリシーには、複雑な条件ステートメントを含めることができます。たとえば、「Customer_Response という名前のインスタンスでない限り、すべての SQL Server インスタンスでデータベース メールを無効にする」という条件ステートメントを含めることが可能です。
ポリシーを作成したら、すべてのサーバーでポリシーを評価して、ポリシーに準拠していないサーバーを示すレポートを作成できます。[構成] ボタンをクリックすると、準拠していないすべてのインスタンスがポリシーで指定されている設定を使用して構成されます。また、定期的に実行されるようにポリシーのスケジュールを設定して、サーバーの状態を監視する必要があります。セキュリティ構成のファセットは、データベース エンジン、Analysis Services、および Reporting Services 向けに提供されているコンポーネントです。
ただし、このポリシー ベースの管理は、セキュリティ設定のメカニズムとして機能することを目的としたものではないことに注意してください。ほとんどの場合、ポリシーに違反する操作を実行するのに十分な特権を持つユーザーは、ポリシーに違反するステートメントを発行したり、ポリシーを使用せずに、セキュリティ ポリシーに違反する可能性のある再構成アクションを実行したりすることができます。SQL Server 2008 のポリシー ベースの管理は、SQL Server セキュリティ設定を監視するサポート機能として使用する必要があります。
ファセットは、関連する DDL ステートメントをオートコミット モード以外のモードで実行できるかどうかによって、設定を適用できるかどうかが異なります。ファセットで構成設定をデータベース エンジンのインスタンスに適用できる場合もありますが、管理者は適用された設定を再構成できます。一部のファセットは、サーバー トリガで適用できます。この方法を使用すると、低い特権しか持たないユーザーが設定を変更できないようにし、管理者が誤って設定を変更する可能性を軽減できます。この場合、管理者は、設定を変更する前にポリシーを一時的に無効にする必要があります。ただし、プロパティの状態の報告のみを実行でき、状態を変更することはできないファセットもあります。これは、対称キーまたは非対称キーの長さを確認するポリシーについても同様です (図 2 参照)。
Figure 2 非対称キーのファセット
Figure 2 非対称キーのファセット
ほとんどの種類のデータベース オブジェクトにはファセットがあり、その多くはセキュリティに使用されます。たとえば、ログインのファセットは、パスワード ポリシーがログインごとに適用されるかどうかを特定でき、ストアド プロシージャのファセットは、すべてのプロシージャが暗号化されているかどうかを検出できます。その他のファセットは、ユーザー、スキーマ、暗号化サービス プロバイダ、情報セキュリティ国際評価基準への準拠、および C2 監査のプロパティをテストします。

Windows Server 2008
SQL Server 2008 は、ファイアウォールが既定で有効になっている Windows Server® 2008 で完全にテストされています。ファイアウォール設定の構成方法を確認するには、今が最適な時期です。また、Windows Vista® でも使用されていますが、Windows Server 2008 では、ユーザー アクセス制御が提供されます。この機能により、管理ユーザーとして自動的に付与される特権が制限されます。これらの機能は、すべてのバージョンの SQL Server に影響します。

まとめ
セキュリティは、今もなお SQL Server において、入念に機能強化が行われている分野です。暗号化と認証の機能強化によって、新しい機能が提供され、新しい監査システムと SQL Server 2008 のポリシー ベースの管理によって、セキュリティ遵守の状態を監視するための新しいツールが提供されます。

Rick Byham は、1995 年にマイクロソフトに入社しました。Customer Support Services で SQL Server サポート エンジニアとして働いた後に、Microsoft Learning の SQL Server チームに加わりました。2003 年にはテクニカル ライターとして SQL Server オンライン ブック チームに異動し、現在はセキュリティに関するドキュメントを担当しています。Rick の連絡先は、rick.byham@microsoft.com (英語のみ) です。


 SQL Server 2008: 新しいデータ型
SQL Server 2008 Kelly Wilson

新しいデータ型
概要:
  • 新しい日付および時刻データ型
  • 階層内の位置を表現する
  • 空間データの操作に使用される 2 つのモデル

経済がグローバル化した今日、企業のビジネスでは、新しい種類のデータ、アプリケーション、および複雑な計算を使用する必要性がますます高まっています。SQL Server 2008 に組み込まれている 7 つの新しいデータ型を使用すると、
より複雑なデータを操作できるだけでなく、これらのデータを容易に管理できるようになります。

date と time
従来の datetime データ型では、SQL Server® ユーザーは日付と時刻の情報を別々に操作することはできませんでした。現在は、date、time、datetime2、および datetimeoffset という 4 つの新しいデータ型によってこの状況が変わり、日付と時刻のデータを容易に操作できるようになりました。また、これらのデータ型では、日付の範囲、秒の小数部分の有効桁数、およびタイム ゾーンのサポートが強化されています。新しいデータベース アプリケーションでは、従来の datetime ではなくこれらの新しいデータ型を使用することをお勧めします。では、これらのデータ型について詳しく見ていきましょう。
date データ型には、時刻要素を除いた日付が格納されます。日付の範囲は、1000 年 1 月 1 日 (0001-01-01) から 9999 年 12 月 31 日 (9999-12-31) までです。date 型の各変数は 3 バイトの領域を必要とし、有効桁数は 10 桁です。このデータ型の精度は 1 日に制限されています。
図 1 は、T-SQL スクリプトで date 型の変数を作成および初期化する方法を示しています。変数 @myDate1 は、'MM/DD/YYYY' という形式の文字列によって初期化されています。変数 @myDate2 は初期化されていないので、値は NULL になります。変数 @myDate3 は、ローカル コンピュータ システムの日付に初期化されています。変数の値は、SELECT ステートメントまたは SET ステートメントを使用していつでも変更することができます。この例では、@myDate2 の値を変更しています。また、テーブル内に date 型の列を作成することもできます。図 2 は、3 つの date 型の列が含まれたテーブルの作成方法を示しています。
Figure 2 Create a table with three date columns (Close Figure 2)
USE TempDB
GO

CREATE TABLE myTable
(
    myDate1 date,myDate2 date,myDate3 date
)
GO

INSERT INTO myTable
VALUES('01/22/2005',
       '2007-05-08 12:35:29.1234567 +12:15',
       GetDate())

SELECT * FROM myTable

--Results
--myDate1    myDate2    myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20
Figure 1 Create and initialize date variables in T-SQL scripts (Close Figure 1)
DECLARE @myDate1 date = '01/22/2005'
DECLARE @myDate2 date
DECLARE @myDate3 date = GetDate()

SELECT @myDate2 = '2007-05-08 12:35:29.1234567 +12:15'

SELECT @myDate1 AS '@myDate1',
       @myDate2 AS '@myDate2',
       @myDate3 AS '@myDate3'

--Results
--@myDate1   @myDate2   @myDate3
------------ ---------- ----------
--2005-01-22 2007-05-08 2007-11-20
time データ型には、日付要素を除いた時刻が格納されます。この時刻は 24 時間形式に基づいているので、サポートされる範囲は 00:00:00.0000000 ～ 23:59:59.9999999 (時間、分、秒、秒の小数部分) です。秒の小数部分の有効桁数は、データ型の作成時に指定できます。既定の有効桁数は 7 桁で、精度は 100 ナノ秒です。有効桁数は、必要な領域のサイズに影響します。2 桁の場合は 3 バイト、3 桁または 4 桁の場合は 4 バイト、5 ～ 7 桁の場合は 5 バイトがそれぞれ必要です。
図 3 の T-SQL スクリプトは、初期化に使用した文字列の値が暗黙的に変換されることによって、変数の有効桁数がどのような影響を受けるかを示しています。この T-SQL コードでは、まず 8 個の異なる time 型の変数を作成し、これらをまったく同じ値に初期化しています。各変数の小数部分の有効桁数は、変数名に含まれている数字と等しくなっています。たとえば、@myTime3 の小数部分の有効桁数は 3 桁です。結果からわかるとおり、各 time データ型の有効桁数は、宣言時に指定した小数部分の有効桁数と等しくなっています。有効桁数を超える範囲の値は切り捨てられます。
Figure 3 Display time data type's variable precision (Close Figure 3)
DECLARE @myTime  time = '01:01:01.1234567 +01:01'
DECLARE @myTime1 time(1) = '01:01:01.1234567 +01:01'
DECLARE @myTime2 time(2) = '01:01:01.1234567 +01:01'
DECLARE @myTime3 time(3) = '01:01:01.1234567 +01:01'
DECLARE @myTime4 time(4) = '01:01:01.1234567 +01:01'
DECLARE @myTime5 time(5) = '01:01:01.1234567 +01:01'
DECLARE @myTime6 time(6) = '01:01:01.1234567 +01:01'
DECLARE @myTime7 time(7) = '01:01:01.1234567 +01:01'

SELECT @myTime  AS '@myTime',
       @myTime1 AS '@myTime1',
       @myTime2 AS '@myTime2',
       @myTime3 AS '@myTime3',
       @myTime4 AS '@myTime4',
       @myTime5 AS '@myTime5',
       @myTime6 AS '@myTime6',
       @myTime7 AS '@myTime7'

--Results
--@myTime          @myTime1   @myTime2    @myTime3     @myTime4
------------------ ---------- ----------- ------------ -------------
--01:01:01.1234567 01:01:01.1 01:01:01.12 01:01:01.123 01:01:01.1235
--
--@myTime5       @myTime6        @myTime7
---------------- --------------- ----------------
--01:01:01.12346 01:01:01.123457 01:01:01.1234567

DROP TABLE myTable
time データ型は、テーブル内の列として作成することができます。DROP TABLE myTable を使用する図 4 の T-SQL スクリプトでは、まず myTable1 というテーブルを作成し、このテーブルに time 型の列を 3 つ追加しています。その後、1 つのレコードをテーブルに追加し、SELECT ステートメントでテーブルの内容を表示しています。
Figure 4 Create myTable1 (Close Figure 4)
USE TempDB
GO

CREATE TABLE myTable1
(
    myTime1 time(1),
    myTime2 time(2),
    myTime3 time(3)
)
GO

INSERT INTO myTable1
VALUES('01:30:01.1234567',
       '02:34:01.1234567',
       '03:01:59.1234567')

SELECT * from myTable1

--Results
--myTime1    myTime2     myTime3
------------ ----------- ------------
--01:30:01.1000000 02:34:15.1200000 03:01:59.1230000

DROP TABLE myTable1

datetimeoffset と datetime2
datetimeoffset データ型は、タイム ゾーンに対応しています。タイム ゾーンを含まない time データ型で操作できるのはローカル時間のみですが、経済がグローバル化した今日では、ある地域の時刻と他の地域の時刻の関連性を把握しなければならない状況が頻繁に発生します。タイム ゾーンのオフセットは、+ hh:mm または - hh:mm で表されます。
次のコードは、datetimeoffset 型の変数を作成し、その変数の値を太平洋標準時の午前 8 時 52 分に初期化しています。
DECLARE @date DATETIMEOFFSET = '2007-11-26T08:52:00.1234567-08:00'
PRINT @date
--Results
--2007-11-26 08:52:00.1234567 -08:00
datetimeoffset 型の変数 (スクリプト内の @date) を初期化する文字列は特殊な形式で記述されており、最上位要素から順番に並んでいます。大文字の T を境に日付要素と時刻要素が分かれており、マイナス記号 (-) を境に時刻要素とタイム ゾーン要素が分かれています。マイナス記号と時刻要素、およびマイナス記号とタイム ゾーン要素の間にスペースはありません。この形式は、datetimeoffset データ型でサポートされている 2 つの ISO 8601 形式のうちの 1 つです (ISO 8601 は、日付値と時刻値の表現に関する国際標準です)。
時刻要素の有効桁数は、time データ型と同じ形式で指定します。指定しなかった場合は、既定の 7 桁になります。サポートされる範囲も、time データ型と同じです。
datetime2 データ型は、datetime 型を拡張した型です。この型では、表現できる日付の範囲と秒の小数部分の有効桁数が強化されています。また、有効桁数を指定することもできます。datetime2 型で表現できる日付の範囲は、1 年 1 月 1 日から 9999 年 12 月 31 日までです。これに対し、datetime 型で表現できる日付の範囲は、1753 年 1 月 1 日から 9999 年 12 月 31 日までです。time 型と同様、秒の小数部分の有効桁数は 7 桁です。datetime 型の有効桁数は 3 桁、時刻の範囲は 0 時 0 分 0 秒から 23 時 59 分 59.999 秒です。次のコードでは、datetime2 型の変数を作成し、その変数の値をローカル サーバーの日付と時刻に初期化しています。
DECLARE @datetime2 DATETIME2 = GetDate();
PRINT @datetime2

--Results
--2007-11-26 09:39:04.1370000
次に、新しい hierarchyid データ型について説明します。このデータ型は、特定の日付や時刻に関するデータではなく、テーブル内のデータ要素間の関係を表します。

hierarchyid データ型
hierarchyid データ型を使用すると、テーブル内のデータ要素間の関係を構築して、階層内の位置を明確に表すことができます。このデータ型について説明するために、まず図 5 のようなスクリプトを使用して、MyCompany データベースを作成し、従業員に関するデータを格納します。
Figure 5 Create and populate the MyCompany database (Close Figure 5)
USE MASTER
GO

CREATE DATABASE MyCompany
GO
USE MyCompany
GO

--Create a table called employee that will store
--the data for the employees for MyCompany.

CREATE TABLE employee
(
    EmployeeID int NOT NULL,
    EmpName    varchar(20) NOT NULL,
    Title      varchar(20) NULL,
    Salary     decimal(18, 2) NOT NULL,
    hireDate   datetimeoffset(0) NOT NULL,
)
GO

--These statements will insert the data for the employees of MyCompany.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00, '2000-05-23T08:30:00-08:00')

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(271, 'John',   'Specialist', 14000.00, '2002-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(119, 'Jill',   'Specialist', 14000.00, '2007-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(269, 'Wanida', 'Assistant', 8000.00, '2003-05-23T09:00:00-08:00')

INSERT INTO employee
VALUES(272, 'Mary',   'Assistant', 8000.00, '2004-05-23T09:00:00-08:00')
GO
--Results
--EmployeeID  EmpName Title      Salary   hireDate
------------- ------- ---------- -------- --------------------------
--6           David   CEO        35900.00 2000-05-23 08:30:00 -08:00
--46          Sariya  Specialist 14000.00 2002-05-23 09:00:00 -08:00
--271         John    Specialist 14000.00 2002-05-23 09:00:00 -08:00
--119         Jill    Specialist 14000.00 2007-05-23 09:00:00 -08:00
--269         Wanida  Assistant  8000.00  2003-05-23 09:00:00 -08:00
--272         Mary    Assistant  8000.00  2004-05-23 09:00:00 -08:00
図 6 は、このスクリプトの結果として作成された、1 つの従業員テーブルから成る単純なデータベースを示しています。この MyCompany データベースの従業員テーブルには、構造が指定されていません。リレーショナル データベースの場合は、アプリケーションのクエリや処理コードによって構造が動的に指定されるので、このままで問題ありません。
Figure 6 MyCompany の従業員テーブル
Figure 6 MyCompany の従業員テーブル
ただし一般に、ビジネス データには特有の構造が存在します。たとえば、どのような企業でも報告構造が存在します。図 7 は、MyCompany の報告構造を示しています。MyCompany のすべての従業員は、CEO である David に報告を行います。Jill のように直接報告を行う従業員もいれば、Mary のように他の従業員を経由して報告を行う従業員もいます。プログラミング用語で言うと、MyCompany の報告構造は、その形からツリー構造と呼ばれます。最上位の David は報告する相手が存在せず、親または先祖と呼ばれます。David に報告を行う従業員は、階層内で David より下のノードに位置します。これらのノードは、子または子孫と呼ばれます。David が直接報告を受ける子孫の数に制限はありません。
Figure 7 MyCompany の組織構造
Figure 7 MyCompany の組織構造
図 8 のスクリプトでは、hierarchyid データ型を使用して MyCompany データベースを再作成し、MyCompany の報告構造と一致する関係を構築しています。まず ALTER TABLE ステートメントを使用して、hierarchyid 型の列を追加します。次に hierarchyid 型の GetRoot メソッドを使用して David のノードを挿入します。その後、GetDescendant メソッドを使用して、David に直接報告を行う従業員をツリーに追加します。
Figure 8 Rebuild the database using hierarchyid (Close Figure 8)
DELETE employee
GO
ALTER TABLE employee ADD OrgNode hierarchyid NOT NULL
GO

DECLARE @child hierarchyid,
@Manager hierarchyid = hierarchyid::GetRoot()

--The first step is to add the node at the top of the
--tree. Since David is the CEO his node will be the
--root node.

INSERT INTO employee
VALUES(6,   'David',  'CEO', 35900.00,
       '2000-05-23T08:30:00-08:00', @Manager)

--The next step is to insert the records for
--the employees that report directly to David.

SELECT @child = @Manager.GetDescendant(NULL, NULL)

INSERT INTO employee
VALUES(46,  'Sariya', 'Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(271, ‚John',   ‚Specialist', 14000.00,
       '2002-05-23T09:00:00-08:00', @child)

SELECT @child = @Manager.GetDescendant(@child, NULL)
INSERT INTO employee
VALUES(119, ‚Jill',   ‚Specialist', 14000.00,
       ‚2007-05-23T09:00:00-08:00', @child)

--We can now insert the employee that reports to
--Sariya.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 46

INSERT INTO employee
VALUES(269, ‚Wanida', ‚Assistant', 8000.00,
       ‚2003-05-23T09:00:00-08:00', @manager)

--Next insert the employee that report to John.
SELECT @manager = OrgNode.GetDescendant(NULL, NULL)
FROM employee WHERE EmployeeID = 271

INSERT INTO employee
VALUES(272, ‚Mary',   ‚Assistant', 8000.00,
       ‚2004-05-23T09:00:00-08:00', @manager)
GO
データベースにレコードを追加し、階層を構築したら、次のクエリを使用して、従業員テーブルの内容を表示することができます。
SELECT EmpName, Title, Salary, OrgNode.ToString() AS OrgNode
FROM employee ORDER BY OrgNode
GO
--Results
--EmpName  Title      Salary    OrgNode
---------- ---------- --------- -------
--David    CEO        35900.00  /
--Sariya   Specialist 14000.00  /1/
--Wanida   Assistant  8000.00   /1/1/
--John     Specialist 14000.00  /2/
--Mary     Assistant  8000.00   /2/1/
--Jill     Specialist 14000.00  /3/
OrgNode は hierarchyid 型の列です。結果として表示される文字列のスラッシュ (/) は、階層ツリー内のノードを示しています。ルートの David は 1 つのスラッシュで表されています。David に直接報告を行う Sariya、John、および Jill は 2 つのスラッシュで表されており、階層内の上から 2 番目のノードであることを示しています。数字 1、2、3 は各子ノードの順番を示しています。このシステムの柔軟性はそれほど高くありません。子ノードは必要に応じて削除、挿入、または追加できます。たとえば、John と Jill の間に従業員を追加した場合、その従業員は結果セット内で /2.1/ として表されます。
Sariya に報告を行う従業員を参照するには、次の T-SQL コードのようなクエリを作成します。
DECLARE @Sariya hierarchyid

SELECT @Sariya = OrgNode
FROM employee WHERE EmployeeID = 46

SELECT EmpName, Title, Salary, OrgNode.ToString() AS 'OrgNode'
FROM employee
WHERE OrgNode.GetAncestor(1) = @Sariya
GO
--Results
--EmpName Title     Salary  OrgNode
--------- --------- ------- -------
--Wanida  Assistant 8000.00 /1/1/
このクエリでは、hierarchyid 型の GetAncestor メソッドを使用して、現在の hierarchyid 型ノードの親を返しています。上記のコードでは、変数 @Sariya に階層内の Sariya のノードが設定されています。これは、Sariya に報告を行う従業員の直接の先祖が Sariya だからです。したがって、Sariya に直接報告を行う従業員を返すクエリでは、ツリーから Sariya のノードを取得した後、先祖ノードが Sariya のノードであるすべての従業員を選択します。
ツリー内のノードを表現するために必要な領域のサイズは、ノードの子の数 (よくノードのファンアウトと呼ばれます) の平均によって決まるので、hierarchyid 型の列は小規模になる傾向があります。たとえば、100,000 人の従業員が所属する組織で構成している階層のファンアウトの平均が 6 である場合、新しいノードを作成するには約 5 バイトの領域が必要です。
hierarchyid データ型では、階層データを容易に操作できるいくつかのメソッドが提供されます。図 9 は、これらのメソッドの概要を示しています。すべてのメソッドの詳細については、SQL Server オンライン ブック (msdn2.microsoft.com/ms130214) を参照してください。
Figure 9 Methods provided by the hierarchyid data type (Close Figure 9)

メソッド | 説明
GetAncestor | この hierarchyid 型ノードの n 番目の先祖を表す hierarchyid 型ノードを返します。
GetDescendant | この hierarchyid 型ノードの子ノードを返します。
GetLevel | 階層全体におけるこの hierarchyid 型ノードの深さを表す整数を返します。
GetRoot | この階層ツリーのルートである hierarchyid 型ノードを返します (静的メソッド)。
IsDescendant | 渡したノードがこの hierarchyid 型ノードの子孫である場合、true を返します。
Parse | 階層の文字列表現を hierarchyid 型の値に変換します (静的メソッド)。
Reparent | 階層内のノードを同じ階層内の新しい場所に移動します。
ToString | hierarchyid 型ノードの論理表現が含まれた文字列を返します。

空間データ型
空間データとは、主に地球上の地理的な場所や地形を表すデータです。このデータの例としては、目印となる建物、道路、会社の場所などが考えられます。SQL Server 2008 では、このようなデータを操作するための地理データ型とジオメトリ データ型が提供されます。
地理データ型は、3 次元の情報を操作します。この 3 次元モデルは、湾曲した地球の表面を考慮して計算を行います。位置に関する情報は、緯度と経度で提供されます。このモデルは、海外輸送、軍事計画、近距離通信など、地球の表面に基づいた計算を行うアプリケーションに適しています。データを緯度と経度で格納する場合は、このモデルを使用します。
ジオメトリ データ型は、2 次元モデルを操作します。このモデルでは、地球を特定のポイントを基点とする平面として扱います。この平面モデルは、地球の湾曲を考慮しないので、建物の内部の地図を作成するデータベース アプリケーションなど、主に短い距離を表す場合に使用されます。
地理型とジオメトリ型は、Well-Known Text (WKT) または Well-Known Binary (WKB) 形式で指定されたベクタ オブジェクトから構築されます。これらの形式は、Open Geospatial Consortium (OGC) Simple Features for SQL Specification で規定されている空間データの転送形式です。図 10 は、SQL Server 2008 でサポートされている 7 種類のベクタ オブジェクトを示しています。
Figure 10 Vector objects supported by SQL Server 2008 (Close Figure 10)

オブジェクト | 説明
Point | 1 つの場所です。
MultiPoint | 複数の場所のコレクションです。
LineString | 線でつながれた 0 個以上のポイントです。
MultiLineString | 複数の LineString のコレクションです。
Polygon | 一連の LineString で囲まれる隣接領域です。
MultiPolygon | 複数の多角形のコレクションです。
GeometryCollection | ジオメトリ型のコレクションです。
1 つまたは複数のベクタ オブジェクトを使用して地理型を構築するには、まず T-SQL スクリプト内で地理型を宣言します (図 11 参照)。次に、図 12 の一覧に記載されているいずれかのメソッドを呼び出し、ベクタ オブジェクトと Spatial Reference ID (SRID) を示す文字列を渡します。SRID は、European Petroleum Survey Group によって定義された空間参照 ID システムであり、地図作成、測量、および測地に関する一連の標準の一部として策定されました。各 SRID は、地理に関する計算で使用される楕円の種類を特定します。地球は完全な球体ではないので、このような処理が必要になります。SQL Server 2008 は、同じ SRID に対してのみ計算を実行できます。
Figure 12 Construct objects for geography and geometry (Close Figure 12)

メソッド | 説明
STGeomFromText | 入力テキストから任意の種類の地理インスタンスを構築します。
STPointFromText | 入力テキストから Point 型の地理インスタンスを構築します。
STMPointFromText | 入力テキストから MultiPoint 型の地理インスタンスを構築します。
STLineFromText | 入力テキストから LineString 型の地理インスタンスを構築します。
STMLineFromText | 入力テキストから MultiLineString 型の地理インスタンスを構築します。
STPolyFromText | 入力テキストから Polygon 型の地理インスタンスを構築します。
STMPolyFromText | 入力テキストから MultiPolygon 型の地理インスタンスを構築します。
STGeomCollFromText | 入力テキストから GeometryCollection 型の地理インスタンスを構築します。
Figure 11 Create points, lines, and polygon geometry (Close Figure 11)
DECLARE @geo1 geometry
SELECT @geo1 = geometry::STGeomFromText('POINT (3 4)', 0)
PRINT @geo1.ToString()

DECLARE @geo2 geometry
SELECT @geo2 = geometry::Parse('POINT(3 4 7 2.5)')
PRINT @geo2.STX;
PRINT @geo2.STY;
PRINT @geo2.Z;
PRINT @geo2.M;

DECLARE @geo3 geography;
SELECT @geo3 = geography::STGeomFromText(
    'LINESTRING(47.656 -122.360, 47.656 -122.343)', 4326);
SELECT @geo3.ToString();

--Results
--POINT (3 4)
--3
--4
--7
--2.5

DECLARE @gx geometry;
SET @gx = geometry::STPolyFromText(
    'POLYGON ((5 5, 10 5, 10 10, 5 5))', 0);
PRINT @gx.ToString();
--Results
--POLYGON ((5 5, 10 5, 10 10, 5 5))

地理型とジオメトリ型の違い
地理データ型とジオメトリ データ型はそれぞれ異なる種類のデータを操作することを目的としており、注意すべき重要な違いがいくつかあります。ジオメトリ データ型では、距離と領域がインスタンスの座標と同じ測定単位で提供されます。たとえば、ポイント (0,0) から (6,8) までの距離は常に 10 です。緯度と経度で表現される楕円の座標と連動する地理型の場合、この動作は異なります。
緯度と経度の組み合わせで座標を表現した場合、GEOMETRY データ型は一貫性のない結果を返します。次の T-SQL コードは、ポイント (90 0) と (90 180) の間の距離を計算しています。どちらのポイントも北極を参照しているので、両者間の距離は 0 になる必要があります。ただし GEOMETRY の場合、算出される距離は 180 になります。
DECLARE @g1 GEOMETRY, @g2 GEOMETRY, @g3 GEOGRAPHY, @g4 GEOGRAPHY
SELECT @g1 = GEOMETRY::STGeomFromText('POINT (90 0)', 0)
SELECT @g2 = GEOMETRY::STGeomFromText('POINT (90 180)', 0)

SELECT @g3 = GEOGRAPHY::STGeomFromText('POINT (90 0)', 4326)
SELECT @g4 = GEOGRAPHY::STGeomFromText('POINT (90 180)', 4326)
SELECT @g2.STDistance(@g1) AS 'GEOMETRY',
       @g4.STDistance(@g3) AS 'GEOGRAPHY';

--Results
--GEOMETRY               GEOGRAPHY
------------------------ ----------------------
--180                    0
また、これら 2 つのデータ型では、空間データの方向も異なります。ジオメトリ データ型によって使用される 2 次元システムでは、多角形の向きは重要な要素ではありません。たとえば、座標 (0, 0)、(10, 0)、(0, 20)、(0, 0) から構成される多角形は、(0, 0)、(0, 20)、(10, 0)、(0, 0) から構成される多角形と同じものであると見なされます。ただし、地理データ型によって使用されるデータ モデルでは、向きを指定しなければ多角形の特性が不明確になります。たとえば、赤道を囲むリングについて考えてみましょう。このリングによって表された多角形は、北半球と南半球のどちらを参照するのでしょうか。地理データを操作する場合は、その向きと場所を正確に記述する必要があるということを覚えておいてください。
また、SQL Server 2008 の地理データ型には、いくつかの制限があります。たとえば、各地理インスタンスは、1 つの半球内に収まる必要があります。空間オブジェクトのサイズが大きすぎる場合は例外が発生し、ArgumentException がスローされます。地理データ型は 2 つの入力値を処理し、メソッドの結果が 1 つの半球内に収まらない場合は NULL を返します。
SQL Server では、地理インスタンスとジオメトリ インスタンスを操作できる数多くのメソッドが提供されます。図 13 は、SQL Server 2008 で提供されるメソッドを使用して空間データを操作する例を示しています。スペースの関係上、ここでは詳しく説明できないので、詳細については SQL Server オンライン ブックを参照してください。
Figure 13 Working with spatial data (Close Figure 13)
DECLARE @gm geometry;
DECLARE @gg geography;
DECLARE @h geography;

SET @gm = geometry::STGeomFromText('POLYGON((0 0, 13 0, 3 3, 0 13, 0 0),(2 2, 2 1, 1 1, 1 2, 2 2))', 0);
SELECT @gm.STArea();

--Results
--38

SET @gg = geography::STGeomFromText('LINESTRING(0 0, 5 5)', 4326);
--Calculate the distance to a point slightly offset from the LINESTRING.
SET @h = geography::STGeomFromText('POINT(4 4)', 4326);
SELECT @gg.STDistance(@h);

--Results
-- 430.182777043046

--Calculate the distance to a point on the LINESTRING.
SET @h = geography::STGeomFromText('POINT(5 5)', 4326);
SELECT @gg.STDistance(@h);

--Results
-- 0

DECLARE @temp table ([name] varchar(10), [geom] geography);

INSERT INTO @temp values ('Point', geography::STGeomFromText('POINT(
5 10)', 4326));
INSERT INTO @temp values ('LineString', geography::STGeomFromText(
'LINESTRING(13 5, 50 25)', 4326));
--Calculate the distance to a point on the LINESTRING.
--Display the number of dimensions for a geography object stored in a --table variable.
INSERT INTO @temp values ('Polygon', geography::STGeomFromText(
'POLYGON((47.653 -122.358, 47.649 -122.348, 47.658 -122.348, 47.658 -122.358, 47.653 -122.358))', 4326));

SELECT [name], [geom].STDimension() as [dim]
FROM @temp;

--Results
--name       dim
------------ -----------
--Point      0
--LineString 1
--Polygon    2
今回ご紹介した、SQL Server 2008 で新しく提供される 7 つのデータ型に関する情報が皆さんのお役に立てば幸いです。

Kelly Wilson は、20 年以上にわたってソフトウェア エンジニアリングに携わってきました。今までに開発を担当したのは、SQL Server、3D グラフィックス、ゲーム、および色彩科学に関するアプリケーションです。現在は、マイクロソフトの SQL Server グループでプログラミング ライターとして勤務しています。


 SQL Server 2008: データ ウェアハウスのクエリ パフォーマンス
SQL Server 2008 Sunil Agarwal and Torsten Grabs and Dr. Joachim Hammer

データ ウェアハウスのクエリ パフォーマンス
概要:
  • スター結合クエリの最適化
  • パーティション テーブルの並列処理
  • 行の圧縮とページの圧縮
  • パーティションで固定されたインデックス付きビュー

SQL Server 2008 では、前のバージョンよりも強力なリレーショナル データ ウェアハウス機能が提供されますが、この新しいテクノロジを使用して、パフォーマンスの高いデータ ウェアハウスをどのように構築し、何十億ものデータ行に基づいた意思決定を支援できるか、疑問に思われるかもしれません。また、どの機能が意思決定支援クエリとレポートのパフォーマンスを最適化するのに役立つか、およびこの新しいバージョンの SQL Server® を利用することで、実際にどのようなパフォーマンスの向上を期待できるかということについても気になるのではないでしょうか。
実際のリリースが近づくにつれて、実にさまざまな疑問が浮かんできます。この記事では、SQL Server 2008 で提供されるパフォーマンス関連のデータ ウェアハウス機能の中で、重要度の高いいくつかの機能について詳しく説明します。製品の導入に先立ち、これらの説明を参考にしていただければと思います。

データベースの論理設計 : ディメンション モデリング
通常、基幹業務トランザクション アプリケーションでは、正規化されたデータベース スキーマが使用されます。リレーショナル データ ウェアハウスの論理的なデータベース スキーマを設計するとき、正規化にはあまり重点が置かれません。現在のリレーショナル データ ウェアハウスの多くは、ディメンション モデリングを使用して設計されています。ディメンション モデリングは、Ralph Kimball 氏と Margy Ross 氏の著書『データ ウェアハウス・ツールキット - 多次元データ ウェアハウス構築の実践手法』によって普及した手法です。
データ ウェアハウスを扱う機会が多い皆さんは、おそらく既にリレーショナル データ ウェアハウスでよく使用されているスキーマのパターン (スター スキーマやスノーフレーク スキーマなど) をよくご存知だと思います。ディメンション モデリングでは、ディメンション テーブルとファクト テーブルが区別されます。ディメンション テーブルはマスタ データ (製品、顧客、店舗、国など) を格納するテーブルで、ファクト テーブルはトランザクション データ (売り上げ、注文数、購入数、返品数など) を格納するテーブルです。
ディメンション テーブルとファクト テーブルは、主キー (PK) と外部キー (FK) のリレーションシップによって関連付けられます。多くのデータ ウェアハウスは、FK 制約を適用しないことで、必要なストレージのサイズを抑えています。これにより、基盤となるインデックスのストレージに関するオーバーヘッドが軽減されるので、ファクト テーブルのメンテナンスにかかるコストを削減することができます。通常、データ ウェアハウスのディメンション テーブルのサイズはかなり小さく、格納される行の数は数千または多くても数百万個です。一方、ファクト テーブルのサイズはかなり大きく、数億または数十億個の行が格納される場合もあります。したがって、論理設計では、ファクト テーブルのストレージ要件に十分な注意を払う必要があります。
このサイズという要素は、ディメンション テーブル内のどの列をキーとして選択し、ファクト テーブルとディメンション テーブルのリレーションシップを維持するかを判断するときにも影響を与えます。ディメンションのビジネス キー (ディメンションによって表現されるエンティティの実世界における ID) に基づく複合キーは、一般に複数の列で構成されます。このことは、ファクト テーブル内の対応する外部キーにとって問題となります。その理由は、ファクト テーブルの行ごとに複数行の複合キーが存在することになるからです。
この問題に対処するために、通常はサイズの小さい代理キーを使用してファクト テーブルとそのディメンションのリレーションシップを実装します。代理キーは整数型の ID 列で、ディメンション テーブルの疑似的な主キーとして機能します。ファクト テーブルがサイズの小さい代理キーを参照することで、サイズの大きいファクト テーブルのストレージ要件を大幅に縮小することができます。図 1 は、ディメンション モデリング、ディメンション テーブルとファクト テーブル、および代理キーを使用してモデル化されたデータ ウェアハウス スキーマを示しています。
Figure 1 1 つのファクト テーブルと 2 つのディメンション テーブルから構成されたスター スキーマの例
Figure 1 1 つのファクト テーブルと 2 つのディメンション テーブルから構成されたスター スキーマの例
スノーフレーク スキーマの設計では、1 つまたは数個のディメンションが複数のレベル (顧客ディメンションの場合は顧客、国、地域など) にまたがるようにすることで、データ内に過度の冗長性が見られる、サイズの大きいディメンションを正規化します。各レベルは別々のテーブルで表現されるので、スキーマはスノーフレーク (雪の結晶) の形になります。一方、スター スキーマの設計では、ディメンションは複数のテーブルにまたがりません。ファクト テーブルを中心にディメンション テーブルのグループが形成されるので、スキーマはスター (星) の形になります。
通常、ディメンション モデリングを使用してスター スキーマまたはスノーフレーク スキーマをモデル化した場合、一定のパターンに従って意思決定支援クエリを記述します。まずファクト テーブルからいくつかのメジャーを選択し、代理キーを使用してファクト行を 1 つまたは数個のディメンションに結合します。次に、ディメンション テーブルのビジネス列にフィルタ述語を適用し、1 つまたは数個のビジネス列に基づいてグループ化した後、ファクト テーブルから取得したメジャーを一定の期間にわたって集計します。以下のクエリは、このパターンを示しています。これは、スター結合クエリと呼ばれることもあります。
select ProductAlternateKey,
CalendarYear,sum(SalesAmount)
from FactInternetSales Fact
     join DimTime
on Fact.OrderDateKey = TimeKey
     join DimProduct
on DimProduct.ProductKey =
   Fact.ProductKey
where CalendarYear between 2003 and 2004
      and ProductAlternateKey like 'BK%'
group by ProductAlternateKey,CalendarYear

物理設計
リレーショナル データ ウェアハウスで使用される SQL クエリの多くは、スター結合クエリの構造に従って記述されます。ただし通常、意思決定者は常に新しい方法を使用して基本的なビジネス データを理解しようとするので、意思決定支援クエリの内容も時間の経過と共に変化します。したがって、データ ウェアハウスのワークロードには、高い割合でアドホック クエリが使用されます。このことが原因で、意思決定支援クエリと、ディメンション モデリングを使用してモデル化されたデータ ウェアハウス スキーマの物理設計は、困難な作業になります。
通常、SQL Server データ ウェアハウスを設計する場合は、青写真と物理設計を作成し、ワークロードの変化に合わせてこれらを調整および改良します。この青写真は、独自のデータ ウェアハウス環境に合わせて自由に変更することができます。ただし、その場合はもちろん、変更に伴って実施されるインデックスのメンテナンス作業がパフォーマンスに与える影響や、インデックスのストレージ要件など、データベースの物理設計に関するベスト プラクティスに従って作業を行う必要があります。

ファクト テーブル
青写真の設計は、通常のスター クエリの形を前提としており、ファクト テーブルにインデックスを構築します。ファクト テーブルのクラスタ化インデックスでは、複数のディメンション代理キー列 (外部キー列) をインデックス キーとして使用します。インデックス キーには、最も頻繁に使用される列が含まれるようにします。また、実際にこの設計を使用したときに、ワークロードで最も頻繁に実行されるクエリに対して、適切なアクセス パスが提供されるかどうかを確認することをお勧めします。
さらに、この青写真では、ファクト テーブル内のディメンション代理キー (外部キー) 列ごとに、単一列の非クラスタ化インデックスを作成します。これにより、いずれかのディメンションの選択度が非常に高いクエリに対して、効果的なアクセス パスが提供されます。
クラスタ化インデックスの目的は、ワークロード内の大部分のクエリのパフォーマンスを向上させることです。これに対し、非クラスタ化インデックスの目的は、特定の顧客または製品に関するファクト テーブルのメジャーを取得するクエリのパフォーマンスを向上させることです。たとえば、これらの非クラスタ化インデックスによって、ファクト テーブルをスキャンしなくても、特定の顧客の売り上げデータを取得できるようになります。

ディメンション テーブル
青写真の設計をディメンション テーブルに適用する場合、ディメンション テーブルごとにインデックスを作成する必要があります。たとえば、ディメンションの代理キー列に主キー制約を適用して非クラスタ化インデックスを作成したり、ディメンション エンティティのビジネス キー列にクラスタ化インデックスを作成したりします。ディメンション テーブルのサイズが大きい場合は、選択度の高い述語で頻繁に使用される列に非クラスタ化インデックスを追加することも検討してください。
クラスタ化インデックスを使用すると、データ ウェアハウスのメンテナンス中に実行される抽出、変換、および読み込み (ETL) 処理が効率化されます。多くの場合、これらの処理では速度が重視されます。たとえば、ディメンションの更新速度が遅いと、ディメンション内にまだ存在しない行がディメンション テーブルに追加されている間に、既存の行が更新されてしまいます。このアクセス パターンで適切に処理が実行されるようにするには、ETL 処理時に実行されるディメンション テーブルの参照および更新処理のパフォーマンスを向上させる必要があります。
ここで説明した青写真の設計は、SQL Server を使用してリレーショナル データ ウェアハウスを構築するときに、その物理設計の基盤として役立ちます。この一般的なリレーショナル データ ウェアハウスの構成を基に、SQL Server 2008 の主要な新機能について説明します。

スター結合クエリの最適化
通常、ディメンション モデリングを使用してモデル化されたリレーショナル データ ウェアハウスのスター結合クエリで実行される最も実行コストの高い処理は、ファクト テーブルの処理です。選択度が非常に高いクエリでも、ファクト テーブルから取得する行の数は、ディメンション テーブルから取得する行の数よりも桁違いに多くなります。このため、クエリのパフォーマンスを向上させるには、ファクト テーブルへの最適なアクセス パスを使用することが不可欠です。
SQL Server では、クエリ オプティマイザによって、一連のパスの中から最も推定コストの低いアクセス パスが自動的に選択されます。データ ウェアハウスの場合、最大の目標は、クエリ オプティマイザがスター結合クエリの実行プラン用に効率的なアクセス パスを選択できるようにすることです。SQL Server のクエリ オプティマイザには、パフォーマンスの高いスター結合クエリの実行プランを自動的に提供するためのさまざまな機能が含まれています。
スター結合クエリは、3 つのカテゴリに分類することができます (図 2 参照)。このように大まかなカテゴリに分類することで、SQL Server エンジンは、それぞれのカテゴリのクエリに適したプランを特定することができます。SQL Server が依存する最も重要な概念は、ファクト テーブルに対するクエリの選択度です。ファクト テーブルから取得する行の数が少ないほど、そのクエリは選択度が高いと見なされます。ファクト テーブルから取得する行の割合によって、直感的にこれらのカテゴリを理解することができます。この割合は、一般的な顧客の展開事例から割り出した値ですが、アクセス パスの定義を決定するために使用できるほど厳密な境界値ではありません。
Figure 2 スター結合クエリの選択度の範囲
Figure 2 スター結合クエリの選択度の範囲
1 つ目のカテゴリに分類されるのは、ファクト テーブルに格納されている行の最大 10% を処理する、選択度が非常に高いクエリです。2 つ目のカテゴリに分類されるのは、ファクト テーブルに格納されている行の 11 ～ 75% を処理する、中間の選択度を持つクエリです。そして、3 つ目のカテゴリに分類されるのは、ファクト テーブルに格納されている行の 76% 以上を処理する、選択度の低いクエリです。図の四角形の中には、各カテゴリで基本的に使用されるクエリ実行プランも記載されています。

選択度に基づいたプランの選択
通常、選択度の高いスター クエリでは、取得されるファクト テーブルの行が 10% 以下であるため、ファクト テーブルへのランダム アクセスが可能です。したがって、このカテゴリのクエリ プランは、入れ子になったループ結合、(非クラスタ化) インデックスのシーク、およびファクト テーブルのブックマーク参照に大きく依存しています。これらのクエリでは、ランダムにファクト テーブルへの I/O が実行されるので、より多くのファクト テーブルのデータを取得する場合は、順次 I/O を実行するクエリを使用するとパフォーマンスが向上します。このため、ファクト テーブルから取得される行の数が増加してきたら、別のクエリ プランの使用を検討する必要があります。
中間の選択度を持つスター クエリは、ファクト テーブルに格納されている大量の行を処理するので、通常、ファクト テーブルへのアクセス パスとして優先されるのは、ファクト テーブルのスキャンまたは範囲スキャンを使用するハッシュ結合です。SQL Server では、ビットマップ フィルタの使用によって、このようなハッシュ結合のパフォーマンスを向上させます。
図 3 は、SQL Server でのスター結合クエリの実行中に、ビットマップ フィルタによって結合のパフォーマンスを向上させるしくみを示しています。この図は、Product と Time という 2 つのディメンション テーブルに対して実行されるクエリのプランです。これらのテーブルは、代理キーによってファクト テーブルと結合されます。このクエリでは、WHERE 句などのフィルタ述語を両方のディメンション テーブルに使用することで、1 つのディメンションにつき 1 つの行のみが取得されるようにしています。2 つの結合演算子の横にある赤いテーブルが、このことを示しています。
Figure 3 結合引き下げ処理を行うスター結合クエリ プラン
Figure 3 結合引き下げ処理を行うスター結合クエリ プラン
それぞれの結合にはハッシュ結合を実装します。この目的は、SQL Server で、ディメンション テーブルから取得された条件に一致する行の情報を使用して、各ディメンション テーブルの結合引き下げ情報と呼ばれるものを作成できるようにすることです。緑の四角形は、結合引き下げ情報のデータ構造を表しています。SQL Server では、基盤となるディメンション テーブルから取得したデータによって結合引き下げ情報が作成されると、クエリの実行中に、ファクト テーブルを処理する演算子 (テーブル スキャンなど) にこれらのデータ構造が自動的に渡されます。この演算子は、ディメンション テーブルの行に関する情報を使用して、ディメンションの結合条件に一致しないファクト テーブルの行を除外します。
SQL Server では、クエリ処理の非常に早い段階 (ファクト テーブルから行を取得した後) で、これらのファクト テーブルの行が除外されます。これにより、除外された行がクエリ プランのそれ以降の演算子によって処理されなくなるので、CPU 使用率が低下し、場合によってはディスク I/O の回数も削減することができます。SQL Server では、ビットマップ表現によって、クエリの実行時に結合引き下げ情報のデータ構造が効率的に実装されます。

スター結合の最適化手順
最適化処理は、結合クエリの最適化に使用される標準的なヒューリスティックを使用して、クエリ実行プランの初期セットを生成します。その後、特定の用途に使用される拡張機能を呼び出して、追加のクエリ プランを生成します。
この拡張機能をデータ ウェアハウスに使用した場合、スター スキーマ、スノーフレーク スキーマ、およびスター クエリのパターンを検出し、ファクト テーブルに対するクエリの選択度を推定します。スキーマとクエリの形式がパターンに一致する場合、SQL Server ではクエリ プランが自動的にプラン領域に追加されます。その後、この領域に対してコスト ベースの最適化を実行し、最適であると判断されたクエリ プランを実行プランとして選択します。
SQL Server では、クエリの実行時に、結合引き下げの実際の選択度も監視されます。選択度が変化した場合、結合引き下げ情報のデータ構造を動的に配置し直して、最も選択度の高いプランが最初に適用されるようにします。

スター結合のヒューリスティック
多くの場合、データ ウェアハウスの物理設計ではスター スキーマが使用されますが、ファクト テーブルとディメンション テーブルのリレーションシップ (たとえば、前述の外部キー制約など) が明示的に指定されるわけではありません。外部キー制約が明示的に指定されていない場合、SQL Server では、ヒューリスティックに基づいてスター スキーマ クエリのパターンを検出する必要があります。スター結合クエリのパターンを検出するときに適用されるヒューリスティックを次に示します。
  1. N 項結合されているテーブルの中で最もサイズの大きいものが、ファクト テーブルであると見なされます。他にもファクト テーブルの最小サイズに関する制約があります。たとえば、最も大きいテーブルが特定のサイズを超えていなければ、N 項結合はスター結合とは見なされません。
  2. スター結合クエリに含まれるバイナリ結合では、結合条件として単一列の等価述語を使用する必要があります。また、それらの結合は内部結合である必要があります。制限が厳しいと思うかもしれませんが、通常のスター スキーマでは、ほとんどのファクト テーブルとディメンション テーブルの結合がこの条件を満たしています。上記のパターンに当てはまらない、より複雑な結合条件が使用されている場合、その結合はスター結合から除外されます。たとえば、5 ウェイ スター結合の 2 つの結合で複雑な結合述語が使用されている場合、その結合は 3 ウェイ スター結合 (と後続の 2 つの結合) として扱われる可能性があります。
以上は、あくまでもヒューリスティックに基づいた規則です。実際は、これらのヒューリスティックを基に、ディメンション テーブルがファクト テーブルとして選択されることはほとんどありません。このことは、どのプランが選択されるかということには影響を与えますが、選択されるプランの正確性には影響を与えません。この後、スター結合に含まれるバイナリ結合が、選択度の高い順に並べ替えられます。この結合の選択度は、ファクト テーブルの入力基数と結合の結果基数の割合、つまり特定のディメンションによってファクト テーブルの基数がどれぐらい減少したかを示しています。一般的には、選択度の高い結合の使用を検討します。
SQL Server のクエリ プロセッサでは、選択されたクエリ プランの推定コストが理想的な数値である場合、スター結合のパターンと前述の条件に従って、クエリが自動的に最適化されます。したがって、アプリケーションに変更を加える必要なく、パフォーマンスを大幅に向上させることができます。ただし、結合引き下げなど、スター結合の一部の最適化機能は、SQL Server Enterprise Edition のみで提供されることに注意してください。

スター結合のパフォーマンスに関する調査結果
SQL Server 2008 で提供されるスター結合の最適化機能を開発する作業の一環として、ベンチマークと実際の顧客のワークロードを基に、さまざまなパフォーマンス調査を実施しました。これら 3 つのワークロードの結果は参考になると思います。
マイクロソフトの販売部門のデータ ウェアハウス このワークロードは、マイクロソフトの販売部門で意思決定の支援を目的として内部的に使用されているデータ ウェアハウスのパフォーマンスを追跡したものです。サンプルとして、約 750 GB (インデックスを含む) のデータベースのスナップショットを作成しました。このワークロードの大部分のクエリでは、10 個を超える結合が使用されているので、クエリ処理には時間がかかります。
小売業界の顧客 この調査は、データ ウェアハウスを使用している小売業界の顧客 (通常の店舗とオンライン ショップを運営する企業) の環境を基に実施されました。この顧客の特徴は、ディメンション モデリングを使用してモデル化されたスノーフレーク スキーマと、標準的なスター結合クエリを使用していることです。この調査では、約 100 GB の未加工のデータを使用して、データ ウェアハウスのスナップショットを作成しました。
意思決定支援ワークロード この調査では、ディメンション モデリングを使用してモデル化された 100 GB のデータベースに対して実行された意思決定支援ワークロードのパフォーマンスを追跡しました。図 4 は、これら 3 種類のワークロードの結果を示しています。このグラフの値は、ワークロード内で実行されたすべてのクエリの応答時間の幾何平均を正規化したものです。これは、ワークロード内のいずれかのクエリを実行するとき、予想されるそのクエリのパフォーマンスを知るための目安として役立ちます。図の棒グラフは、スター結合の最適化機能を使用しなかった場合のベースライン パフォーマンス (1.0) と、スター結合の最適化機能を使用した場合のパフォーマンスを比較しています。これらの調査は、すべて SQL Server 2008 を使用して実施されました。
Figure 4 スター結合の最適化によるパフォーマンスの向上
Figure 4 スター結合の最適化によるパフォーマンスの向上
図のデータからわかるように、すべてのワークロードのパフォーマンスが、12 ～ 30% と大幅に向上しています。実際の結果は環境によって異なりますが、SQL Server エンジンに対して実行される意思決定支援ワークロードのパフォーマンスは、SQL Server 2008 の新機能であるスター結合の最適化によって、約 15 ～ 20% 向上することが予想されます。

パーティション テーブルの並列処理
大規模なデータ ウェアハウスで実行されるクエリの処理速度を向上させるために、サイズの大きいファクト テーブルを日付でパーティション分割することがよくあります。これにより、データが複数のファイル グループに分割されるので、特定のデータ範囲内に含まれる行を処理するときに検索するデータの量が減少します。また、ファイル グループを多数の物理ディスクにまたがって展開すると、基盤となるディスク システムの同時実行機能によって、パフォーマンスが向上します。
SQL Server 2005 では、サイズの大きいテーブルを管理しやすくするために、サイズの大きいリレーションをサイズの小さい論理的なまとまりに分割する機能が導入されました。特に大規模な意思決定支援アプリケーションの場合は、この機能を使用して、クエリ処理のパフォーマンスを向上させることができます。
残念ながら、SQL Server 2005 を使用している一部の顧客の環境では、このようなパーティション テーブルにアクセスするクエリを実行した場合 (特に並列処理を行う共有メモリ型マルチプロセッサ コンピュータ上で実行した場合)、パフォーマンスに関する問題が発生します。これは、SQL Server 2005 では、パーティション テーブルにアクセスする並列クエリを処理するときに、そのクエリに割り当てられるスレッドが、利用可能なスレッドのサブセットに限定される場合があるためです。
たとえば、最大 64 個のスレッドを使用してクエリの並列処理を実行できる、64 個のコアが搭載されたコンピュータがあり、あるクエリからこのコンピュータの 2 つのパーティションにアクセスするとします。SQL Server 2005 は、64 個のスレッドのうち 2 個のみを取得するので、使用される CPU の処理能力は 64 分の 2 (3.1%) です。同じコンピュータの同じファクト テーブルにアクセスするクエリを実行した場合、テーブルをパーティション分割したときの方が、パーティション分割していないときよりも 10 倍以上パフォーマンスが低下したという報告も寄せられています。
SQL Server 2005 は単一のパーティションにアクセスするクエリ用に最適化されていることに注意する必要があります。このバージョンのクエリ プロセッサは、すべての利用可能なスレッドをスキャンの実行用に割り当てます。マルチコア コンピュータの単一のパーティションにアクセスするクエリを実行した場合、この特殊な最適化機能によってパフォーマンスは大幅に向上するので、複数のパーティションにアクセスするクエリでも、顧客は当然このような動作を期待したのです。
SQL Server 2008 で新しく提供されるパーティション テーブルの並列処理 (PTP) 機能を使用すると、クエリがアクセスするパーティションの数や、個々のパーティションの相対的なサイズに関係なく、既存のハードウェアの処理性能を活用して、パーティション テーブルにアクセスするクエリのパフォーマンスを向上させることができます。パーティション分割されたファクト テーブルを使用する一般的なデータ ウェアハウスのシナリオでは、特にクエリがアクセスするパーティションの数が利用可能なプロセッサ コアの数よりも少ない場合、並列プランで実行されるクエリのパフォーマンスは大幅に向上する可能性があります。この新機能は、調整や構成を行う必要なく、すぐに使用することができます。
たとえば、売り上げデータを表すファクト テーブルがあり、このデータが売り上げの発生日に基づいて 4 つのパーティションに分割されているとします。図 5 を参照していただくと、この例をイメージしやすいと思います。通常は、データをパーティション分割しない場合のように、データ範囲全体用のクラスタ化インデックスが 1 つ作成されるのではなく、ファクト テーブルの各パーティションの日付列にクラスタ化インデックスが作成されます。クエリ Q が、過去 7 日間の売り上げを集計するとします。新しい売り上げデータは、最後のパーティション (P4) からファクト テーブルに追加され続けるので、クエリを実行するタイミングによっては、そのクエリが他のパーティションにアクセスすることになります。図 5 の一番上の行は、この状況を示しています。Q1 クエリは 1 つのパーティションにのみアクセスしますが、Q2 クエリは実行時に関連データが P3 および P4 パーティションに分散しているので、これら 2 つのパーティションにアクセスします。
Figure 5 新しい PTP 機能の動作
Figure 5 新しい PTP 機能の動作
今度は、利用可能なスレッドが 8 つあるとします。Q1 と Q2 を SQL Server 2005 で実行すると、予期しない動作が発生する可能性があります。SQL Server 2005 の最適化機能では、クエリからアクセスするパーティションが 1 つのみであることをオプティマイザがコンパイル時に認識した場合、そのパーティションは分割されずに 1 つのテーブルとして扱われるので、生成されるプランではすべての利用可能なスレッドがこのテーブルへのアクセスに使用されます。
この結果、1 つのパーティション (P3) にアクセスする Q1 用に生成されるプランでは、クエリが 8 つのスレッドによって処理されます (図には示されていません)。2 つのパーティションにアクセスする Q2 の場合、基盤となるハードウェアが他のスレッドを使用できる場合でも、実行エンジンは 1 つのスレッドのみを各パーティションに割り当てます。したがって、Q2 は CPU の能力をほとんど利用できないので、おそらく Q1 よりも格段に時間がかかります。
Q1 と Q2 を SQL Server 2008 で実行すると、ハードウェアがより効率的に利用されるので、パフォーマンスが向上し、動作が予測しやすくなります。この場合も、Q1 を実行するときは、利用可能な 8 つのスレッドがすべて P2 のデータ処理に割り当てられます (図には示されていません)。一方 Q2 の場合は、実行エンジンが利用可能なすべてのスレッドを P3 と P4 にラウンドロビン方式で割り当てる並列プランが作成されます。その結果、この 2 つのパーティションにそれぞれ 4 つのスレッドが割り当てられます (図の一番下の行を参照)。CPU の能力がすべて利用されるので、Q1 と Q2 で同程度のパフォーマンスが得られます。
クエリがアクセスするパーティションの数よりもプロセッサ コアの数が多い場合、このラウンド ロビン方式のスレッド割り当てによって、クエリのパフォーマンスが大幅に向上します。ただし残念ながら、この例ほど簡単にパーティションへのスレッド割り当てが行われない場合もあります。
図 6 は、SQL Server 2008 がインストールされたマルチコア プロセッサ コンピュータでパーティション テーブルを使用したときに、SQL Server 2005 と比較してどの程度パフォーマンスが向上するかを示しています。このテスト結果に基づいたグラフは、パーティション テーブルをスキャンしたときのパフォーマンスを表しています。このテストでは、64 個のコアと 256 GB の RAM が搭載されたシステムを使用し、121 GB のテーブル 1 個を 11 GB のパーティション 11 個に分割しました。この図に記載されている一連のテストでは、コールド バッファ スタートとウォーム バッファ スタートの両方でヒープ ファイルの構成が使用されています。また、すべてのクエリで単純なデータ スキャンが実行されます。
Figure 6 SQL Server で新しい PTP 機能を有効にした場合のスキャン パフォーマンス
Figure 6 SQL Server で新しい PTP 機能を有効にした場合のスキャン パフォーマンス
Y 軸は応答時間 (秒)、X 軸は並列処理の程度 (DOP) をそれぞれ表しています。DOP は、クエリに割り当てられるスレッドの数に相当します。図からわかるように、コールド スタートでもウォーム スタートでも、応答時間は DOP が 22 になるまで短縮され続けます。DOP が 22 になった時点で、コールド スタートの場合は I/O システムが飽和 (これ以上パフォーマンスが向上しない) 状態になります。これは、この例で使用したクエリが I/O を頻繁に実行するからです。CPU を集中的に使用するワークロードでは、この制限が発生しないか、DOP が高くなった場合のみ制限が発生します。
ただし、ウォーム スタートを表す曲線では、DOP レベルが高くなるにつれて、応答時間が短縮され続けています。SQL Server 2005 では、複数のパーティションを処理するときに 1 つのパーティションに割り当てられるスレッドが 1 つのみであるため、DOP が 11 に達したあたりから、どちらの曲線も徐々に平坦になります。
実際には、DOP が増加しても、それに比例して応答時間が短縮されるわけではないことに注意してください。予期される動作は、ステップ関数の動作に近くなります。これは、基本的にクエリの処理には時間のかかる部分が存在するという事実を反映しています。したがって、たとえば、あるスキャンに 1 つまたは複数のスレッドを追加するだけでなく、残りのすべてのスキャンにもスレッドを追加して、より短時間で処理が完了するようにしない限り、最終的なクエリの処理速度は向上しません。
他にもテストを実施し、さまざまなハードウェアとファイル構成を使用して PTP の動作を確認しました。これらのテストでも、1 つのパーティションに割り当てられるスレッドの数が 2 つ以上に増加すると、スループットの向上という点で同様の現象が見られました。
大事なことを言い忘れていましたが、SQL Server 2008 で提供される新しい PTP 機能によって、クエリ プランの信頼性が向上し、特定のワークロードの実行に関するより正確な洞察を得ることができます。たとえば、PTP 機能の一環として、並列プランと順次プランを XML プラン表示で表現する処理が強化されているほか、コンパイル時のプランと実行時のプランで提供されるパーティション分割情報の質が向上しています。

データ圧縮
ビジネス インテリジェンスの普及と共に、分析用のデータが続々とデータ ウェアハウスに追加されています。この結果、管理するデータのサイズが急激に増加しています。1995 年に Winter Corporation によって初めて実施されたデータベースのサイズに関する調査によると、世界最大のシステムに格納されたデータの量は 1 TB でした。10 年後、データベースの最大サイズは 100 倍近くまで増加しました。さらに驚くべきことに、データ ウェアハウスのサイズは 2 年おきに 3 倍増加しています。このため、このような大量のデータを管理し、データ ウェアハウスのクエリで許容レベルのパフォーマンスを実現するという新たな課題が生まれました。通常、このようなクエリは複雑であり、多くの結合と集計を使用して大量のデータにアクセスします。また、ワークロードに含まれるクエリの多くが I/O を頻繁に実行することも珍しくありません。
ネイティブのデータ圧縮機能は、この問題の解決を目的としています。SQL Server 2005 SP2 では、10 進数と数値データ用に新しい可変長ストレージ形式である VarDecimal ストレージ形式が導入されました。この新しいストレージ形式を使用すると、データベースのサイズを大幅に縮小することができます。領域の節約は 2 つのメリットをもたらし、これによって I/O を頻繁に実行するクエリのパフォーマンスが向上します。1 つ目は、読み取るページ数が減少することです。そして 2 つ目は、データが圧縮された状態でバッファ プール内に格納されることによって、ページの推定寿命が長くなることです (つまり、要求されたページがバッファ内に存在する確率が高くなります)。データ圧縮によって領域は節約されますが、データを圧縮および圧縮解除する処理には当然 CPU コストがかかります。
VarDecimal ストレージ形式に基づいて構築された SQL Server 2008 では、2 種類の圧縮を利用できます。これらは、行の圧縮とページの圧縮です。行の圧縮は、VarDecimal ストレージ形式を拡張して、すべての固定長データ型を可変長ストレージ形式で格納します。
固定長データ型には、integer、char、float などがあります。SQL Server ではこれらのデータ型を可変長形式で格納しても、データ型のセマンティクスは変わりません (アプリケーションでは固定長のデータ型として認識されます)。したがって、アプリケーションに変更を加えることなく、データ圧縮のメリットを得ることができます。
ページの圧縮では、特定のページに格納された 1 つまたは複数の行に含まれている列のデータの冗長性が最小限に抑えられます。この圧縮機能では、LZ78 (Lempel-Ziv) アルゴリズムのマイクロソフトによる実装が使用されるため、冗長なデータが 1 回のみページ内に格納され、複数の列からこのデータを参照できます。ページ圧縮を使用すると、実際には行の圧縮も行われることに注意してください。
行の圧縮とページの圧縮は、1 つのテーブルとインデックス、またはパーティション テーブルとパーティション分割されたインデックスの 1 つまたは複数のパーティションで有効にすることができます。これにより、圧縮する範囲をテーブル、インデックス、およびパーティションの中から自由に選択できるので、領域の節約と CPU への影響のバランスを適切にとることができます。図 7 は、固定インデックスを使用して異なる方法でパーティション分割された売り上げテーブルを示しています。
Figure 7 異なる圧縮設定が適用されたパーティション テーブル
Figure 7 異なる圧縮設定が適用されたパーティション テーブル
各パーティションは四半期を示しており、10 ～ 12 月が最新の四半期です。最初の 2 つのパーティションへのアクセスはあまり頻繁に発生せず、3 つ目のパーティションへのアクセスはある程度発生し、最後のパーティションへのアクセスは頻繁に発生しています。この場合、適切な構成を挙げるとすれば、まず最初の 2 つのパーティションでページ圧縮を有効にして、ワークロードのパフォーマンスに与える影響を最小限にとどめながら、領域をできるだけ節約します。また、3 つ目のパーティションで行圧縮を有効にし、最後のパーティションでは圧縮を実行しないようにします。
圧縮は、オンラインであるかオフラインであるかを問わず、Alter Table または Alter Index データ定義言語 (DDL) ステートメントを使用して有効にすることができます。SQL Server では、節約できる領域を見積もるためのストアド プロシージャも提供されます。どの程度の領域を節約できるかは、データの分散状態と、圧縮対象のオブジェクトのスキーマによって異なります。
さまざまな顧客のデータベースでテストを行った結果から判断すると、ほとんどのデータベースでサイズが 50 ～ 65% 減少すること、および I/O を頻繁に実行するクエリのパフォーマンスが大幅に向上することが予想されます。ただし、CPU を集中的に使用するクエリのパフォーマンスへの影響については、多少見積もりが難しく、クエリの複雑さに左右されると言えます。SQL Server では、インデックスまたはテーブルにアクセスする場合のみ、圧縮解除のコストが発生します。一般的なデータ ウェアハウスのシナリオでは、スキャン演算子の相対的な CPU コストがクエリの全体的な CPU コストよりも低い場合、CPU 使用率への影響は 20 ～ 30% 未満です。

パーティションで固定されたインデックス付きビュー
SQL Server 2008 のパーティションで固定されたインデックス付きビューを使用すると、リレーショナル データ ウェアハウス内でサマリ集計をより効率的に作成および管理し、これまで集計を有効に使用できなかった状況でも、集計を使用できるようになります。そしてこれに伴い、クエリのパフォーマンスも向上します。一般的なシナリオとしては、日付でパーティション分割されたファクト テーブルが挙げられます。このテーブルにはインデックス付きビュー (サマリ集計) が定義され、これによってクエリの処理速度が向上します。テーブル内のパーティションを切り替えると、そのパーティション テーブルに定義されている、パーティションで固定されたインデックス付きビュー内の対応するパーティションも自動的に切り替わります。
これは、SQL Server 2005 からの大きな機能強化です。SQL Server 2005 では、ALTER TABLE SWITCH 操作を使用してパーティションを切り替える前に、パーティション テーブルに定義されているインデックス付きビューを削除する必要がありました。SQL Server 2008 では、パーティションで固定されたインデックス付きビュー機能が提供されるので、インデックス付きビューによってサイズの大きいパーティション テーブルにもたらされるメリットを得ることができるだけでなく、パーティション テーブル全体の集計を再構築するコストの発生を回避することができます。このメリットとしては、集計のメンテナンスが自動的に実行されることや、インデックス付きビューの対応付けが行われることなどが挙げられます。

パーティション レベルのロックのエスカレート
SQL Server では、範囲パーティション分割がサポートされています。範囲パーティション分割を使用すると、データを管理しやすいように分割したり、使用パターンに従ってデータをグループ化したりすることができます。たとえば、売り上げデータを月または四半期単位で分割することができます。パーティションを自身のファイル グループにマップし、さらにそのファイル グループを一連のファイルにマップすることができます。これには 2 つの大きなメリットがあります。まず、パーティションを独立した 1 つの単位としてバックアップおよび復元することができます。また、使用パターンやクエリの負荷に応じて、ファイル グループを低速または高速な I/O サブシステムにマップすることができます。
ここで興味深いのは、データのアクセス パターンです。クエリと DML 操作では、パーティションのサブセットにアクセスしたり、そのサブセットを操作したりするだけで処理が完了する場合があります。したがって、たとえば 2004 年の売り上げデータを分析する場合は、関連するパーティションにアクセスするだけで済みます。他のパーティションに格納されているデータに同時にアクセスしているクエリの影響を受けないことが理想です (システム リソースへの影響は除きます)。SQL Server 2005 では、他のパーティションに格納されているデータへのアクセスが同時に発生した場合、テーブルがロックされ、他のパーティションへのアクセスに影響が出ることがあります。
SQL Server 2008 では、このような影響を最小限に抑えるために、パーティション レベルまたはテーブル レベルでロックのエスカレートを制御できるテーブル レベルのオプションが導入されています。既定では、ロックのエスカレートは SQL Server 2005 と同様にテーブル レベルで有効になります。ただし、テーブルのロックのエスカレートに関するポリシーは上書きすることができます。したがって、たとえば、次のようにロックのエスカレートを設定することができます。
Alter table <mytable> set (LOCK_ESCALATION = AUTO)
このコマンドは、テーブルのスキーマに適したロックのエスカレートの粒度を選択するよう SQL Server に指示しています。テーブルがパーティション分割されていない場合、ロックのエスカレートはテーブル レベルで有効になります。テーブルがパーティション分割されている場合、ロックのエスカレートはパーティション レベルで有効になります。また、SQL Server では、テーブル レベルでのロックを無効にするためのヒントとして、このオプションが使用されます。

まとめ
この記事では、リレーショナル データ ウェアハウスで使用する意思決定支援クエリのパフォーマンスを向上させるのに役立つ、SQL Server 2008 の機能強化についてごく簡単に説明しました。意思決定支援クエリの応答時間を短縮することは重要ですが、他にもこの記事では説明しなかった重要な要件があることに留意してください。
リレーショナル データ ウェアハウスに関連するその他の機能としては、次のものがあります。
  • T-SQL における MERGE 構文のサポート : 1 つのステートメントとラウンドトリップを使用して、データベースの (ディメンション) データを更新、削除、または挿入することができます。
  • SQL Server エンジンがログ記録を行うときのパフォーマンスの最適化 : より効率的な ETL が実現されます。
  • グループ化セット : T-SQL で意思決定に役立つ集計クエリを容易に記述できるようになります。
  • バックアップの圧縮 : 完全バックアップと増分バックアップの I/O 回数が減少します。
  • リソース管理 : さまざまなワークロードへのシステム リソースの割り当てを制御することができます。
これらの魅力的な機能の詳細については、SQL Server Web サイト (microsoft.com/sql) を参照してください。
技術的知識を提供してくれた Boris Baryshnikov、Prem Mehra、Peter Zabback、および Shin Zhang に感謝します。

Sunil Agarwal は、マイクロソフトの SQL Server ストレージ エンジン グループでシニア プログラム マネージャを務めています。担当分野は、同時実行、インデックス、tempdb、LOBS、サポータビリティ、一括インポート、および一括エクスポートです。
Torsten Grabs は、マイクロソフトの SQL Server チームで、コア ストレージ エンジンのリード シニア プログラム マネージャを務めています。データベース システムの博士号を持ち、SQL Server には 10 年間携わっています。
Dr. Joachim Hammer は、マイクロソフトのクエリ処理グループでプログラム マネージャを務めています。専門分野は、大規模なデータ ウェアハウス アプリケーションにおけるクエリの最適化、分散クエリ、ETL、および情報の統合です。


 SQL Server: SQL Server のブロッキングを最小限に抑える
SQL Server Cherié Warren

SQL Server のブロッキングを最小限に抑える
概要:
  • ロックのエスカレートが発生する理由
  • 不要なブロッキングの発生を回避する
  • クエリを最適化する
  • ロックがパフォーマンスに与える影響を監視する

ロックは、データベースに対して同時に行われる読み取り操作と書き込み操作をサポートするために不可欠な処理ですが、ブロッキングはシステムのパフォーマンスに悪影響を及ぼす可能性があり、場合によっては、そのしくみは複雑です。この記事では、SQL Server 2005 データベースまたは SQL Server 2008 データベースを最適化してブロッキングの発生率を最小限に抑える方法、
およびシステムを監視してロックがパフォーマンスに与える影響を適切に把握する方法について説明します。

ロックとエスカレート
SQL Server® では、影響を受けるレコードの数、およびシステム上で行われる同時操作の種類に基づいて、最も適切なロックの粒度が選択されます。既定では、SQL Server では可能な限り最も粒度の細かいロックが選択されます。粒度の粗いロックが選択されるのは、システム メモリをより効果的に使用できる場合のみです。SQL Server では、全体的なシステムのパフォーマンスが向上すると判断された場合、ロックがエスカレートされます。エスカレートが発生するのは、特定のスキャンで検出されたロックの数が 5,000 個を上回った場合、またはシステムによってロックに使用されるメモリの量が、次のように使用可能な量を上回った場合です (図 1 参照)。
Figure 1 ロックのエスカレートが発生する条件
Figure 1 ロックのエスカレートが発生する条件
  • locks の値が 0 に設定されているときに、データベース エンジンによって使用される Address Windowing Extensions (AWE) 以外のメモリの量が 24% を超えた場合
  • locks が 0 以外の値に設定されているときに、データベース エンジンによって使用される AWE 以外のメモリの量が 40% を超えた場合
エスカレートが発生する場合、ロックは常にテーブル ロックになります。

不要なブロッキングの発生を回避する
ブロッキングはすべてのロックの粒度で発生しますが、エスカレートが発生すると、ブロッキングの発生率は高くなります。ロックのエスカレートが発生するということは、アプリケーションの設計、コーディング、または構成が効果的ではない可能性があります。
ブロッキングの発生を回避するには、データベースの設計が基本的な要件 (正規化されたスキーマと厳密なキーを使用する、トランザクション システムでデータの一括操作を実行しないようにするなど) を満たしている必要があります。このような原則に従わなかった場合 (トランザクション システムからレポート システムを分離する、業務時間外にデータ フィードを処理するなど)、システムのチューニングは困難になります。
インデックスは、データへのアクセスに必要なロックの数に大きく影響を与える可能性があります。インデックスによって、データベース エンジンが実行する内部参照の回数が減少するので、クエリがアクセスするレコードの数も減少します。たとえば、テーブルに格納されている、インデックスが作成されていない列から 1 つの行を選択する場合は、目的のレコードが特定されるまで、テーブル内の各行を一時的にロックする必要があります。これに対し、列にインデックスが作成されている場合、必要なロックは 1 つのみです。
SQL Server 2005 と SQL Server 2008 には、動的管理ビュー (sys.dm_db_missing_index_group_stats、sys.dm_db_missing_index_groups、sys.dm_db_missing_index_details) が含まれています。これらの動的管理ビューは、使用状況の累積統計情報に基づいて、インデックスからメリットを得ることができるテーブルと列を特定します。
データが断片化していると、データベース エンジンが多くのページにアクセスする必要があるので、パフォーマンスが低下する可能性があります。また、統計が適切でないことが原因で、クエリ オプティマイザがあまり効果的ではないプランを選択する可能性もあります。
インデックスを使用すると、データ アクセスの速度は向上しますが、データ変更の速度は低下することに注意してください。この理由は、基になるデータを変更するだけでなく、インデックスも更新する必要があるからです。動的管理ビューの sys.dm_db_index_usage_stats は、インデックスの使用頻度を示します。効率的でないインデックスの一般的な例としては、複合インデックスが挙げられます。つまり、同じ列に単独インデックスと複合インデックスの両方が作成されている場合です。SQL Server はインデックスの左から右へとアクセスするので、左端の列が有用であると判断された場合、その列に設定されているインデックスが使用されます。
テーブルをパーティション分割すると、システムを最適化できる (その結果ブロッキングの発生率が低下します) だけでなく、テーブルのデータを、個別にアクセスできる複数の物理オブジェクトに分割できます。行のパーティションを有効にするとデータを明示的に分割できますが、もう 1 つの選択肢として、データを行方向にパーティション分割することも考慮します。また、同時に複数の処理がデータへの排他アクセスする機会を減らすために、意図的に非正規化を行う場合もあります。つまり、1 つのテーブルを複数のテーブルに分割し、それぞれのテーブルに同数の行とキー、および異なる列を使用します。
アプリケーションが特定の行へのアクセスに使用する方法の種類、およびその行に含まれる列の数が多ければ多いほど、列のパーティション分割を使用する方法は魅力的です。場合によっては、アプリケーション キューと状態テーブルに関するメリットを得ることができます。SQL Server 2008 では、パーティション単位 (テーブルでパーティションが有効になっていない場合はテーブル単位) でロックのエスカレートを無効にする機能が追加されています。

クエリの最適化
パフォーマンスを強化するうえで、クエリの最適化は重要な役割を果たします。考えられる 3 つの方法を次に示します。
トランザクションのサイズを小さくする ブロッキングの発生回数を減らし、全体的なパフォーマンスを向上させる最も重要な方法の 1 つは、トランザクションのサイズをできるだけ小さくすることです。トランザクションの整合性にとって大きな問題にならない処理 (関連データの参照、インデックスの作成、データの最適化など) をすべて除外して、トランザクションのサイズを小さくする必要があります。
SQL は、各ステートメントを暗黙的なトランザクションとして扱います。ステートメントが大量の行に影響を与える場合、1 つのステートメントでも大きなトランザクションを構成する可能性があります (特に、大量の列が関与する場合や、列にサイズの大きなデータ型が含まれている場合)。また、FILL FACTOR に大きな値が設定されている場合や、UPDATE ステートメントが、割り当てられた範囲よりも大きな値を列に格納している場合、1 つのステートメントでもページの分割が発生する可能性があります。このような状況では、トランザクションを行のグループに分割し、1 つのグループの処理が完了してから次のグループの処理を実行するとよいでしょう。バッチ処理は、個々のステートメントまたはステートメントのグループを小さい (成功または失敗した場合に、1 つの作業単位として完了したと見なすことができる) バッチに分割できる場合のみ考慮することをお勧めします。
トランザクションを順序付ける トランザクション内のステートメントを意図的に順序付けることで、ブロッキングの発生率が低下する場合があります。このときに考慮する原則は 2 つあります。1 つ目は、すべての SQL コード内で、同じ順序を使用してシステム内のオブジェクトにアクセスすることです。順序に一貫性がない場合、2 つの競合する処理が異なる順序でデータにアクセスし、そのことが原因でデッドロックが発生する可能性があります。この場合、どちらかの処理でシステム エラーが発生します。2 つ目は、頻繁にアクセスするオブジェクト、またはアクセスに時間がかかるオブジェクトをトランザクションの最後に配置することです。SQL は、トランザクション内でオブジェクトが要求されるまで、それらのオブジェクトをロックしません。アクセスが集中するオブジェクトへのアクセスを遅延させることによって、これらのオブジェクトがロックを保持する時間を短縮できます。
ロック ヒントを使用する ロック ヒントは、特定のテーブルとビューにセッション レベルまたはステートメント レベルで使用できます。セッション レベルのヒントを使用する一般的なシナリオは、データ ウェアハウスのバッチ処理です。つまり、特定の時間にあるデータ セットに対して唯一実行されるのがそのバッチ処理であることを開発者が把握している場合です。ストアド プロシージャの冒頭で SET ISOLATION LEVEL READ UNCOMMITTED などのコマンドを使用すると、SQL Server は読み取りロックを予約しません。したがって、ロックによって発生する全体的なオーバーヘッドが軽減され、パフォーマンスが向上します。
ステートメント レベルのヒントを使用する一般的なシナリオとしては、ダーティ リードが安全に発生することを開発者が把握している場合 (テーブルから 1 つの行を読み取るとき、同時に実行される他の処理でその行が要求されない場合など) や、他のすべてのパフォーマンス チューニング作業 (スキーマの設計、インデックスの設計と管理、およびクエリのチューニング) が失敗し、コンパイラで特定の種類のヒントを使用する必要がある場合などが挙げられます。
行ロックのヒントを使用するシナリオは、より粒度の粗いロックが発生し、ほとんどのレコードがクエリの影響を受けない場合です。この場合、行ロックのヒントを使用することによって、ブロッキングの発生率を低下させることができます。テーブル ロックのヒントを使用するシナリオは、テーブル内のほぼすべてのレコードがクエリによる影響を受けず、より粒度の細かいロックが (エスカレートされずに) 発生する場合です。この場合、テーブル ロックのヒントを使用することによって、ロックの保持に必要なシステム リソースを削減することができます。ここで注意する必要があるのは、ロック ヒントを指定しても、ロックの数がシステム メモリのしきい値に達したときにロックがエスカレートされる場合があることです。ただし、ロック ヒントを指定すると、その他の場合に発生するすべてのエスカレートを回避することができます。

構成を調整する
図 2 が示すように、SQL Server システムを構成するときは、多くの要素を考慮する必要があります。
Figure 2 SQL Server がロックに使用するメモリの量を決定する流れ
Figure 2 SQL Server がロックに使用するメモリの量を決定する流れ
メモリ ロックは常に AWE 以外のメモリで保持されるので、AWE 以外のメモリ サイズを増加させれば、システムはより多くのロックを保持できるようになります。
より多くのロックを保持できるようにするには、まず 64 ビット アーキテクチャの導入を検討することをお勧めします。その理由は、32 ビット アーキテクチャでは AWE 以外のメモリが 4 GB に制限されるのに対し、64 ビットではまったく制限されないからです。
32 ビット システムでは、/3GB スイッチを Boot.ini ファイルに追加することによって、SQL Server に使用できるオペレーティング システムのメモリを 1 GB 増加させることができます。
SQL Server の構成設定 sp_configure を使用して、ロックに関連するさまざまな設定を調整できます。locks 設定を使用すると、エラーがスローされるまでにシステムが保持できるロックの数を構成できます。既定では、この値は 0 に設定されています。0 に設定されている場合、同時にメモリを要求した他の処理によって予約されるロックをサーバーが動的に調整します。SQL は最初に 2,500 個のロックを予約します。また、各ロックは 96 バイトのメモリを使用します。ページ メモリは使用されません。
min memory および max memory 設定を使用すると、SQL Server が使用するメモリの量を予約できます。つまり、メモリを静的に保持するようにサーバーを構成します。ロックのエスカレートが発生するかどうかは、使用可能なメモリの量によって決まるので、競合する他の処理用のメモリを予約することによって、エスカレートの発生率も変化する可能性があります。
接続設定 既定では、処理をブロックしているロックがタイムアウトすることはありませんが、@@LOCK_TIMEOUT 設定を使用すると、ロックを解放するまでの待機時間を指定して、その時間が経過したときにエラーを発生させることができます。
トレース フラグ 特にロックのエスカレートに関連しているトレース フラグは 2 つあります。1 つ目は、ロックのエスカレートを無効にするトレース フラグ 1211 です。使用可能な量を超えるメモリがロックに使用された場合、エラーがスローされます。もう 1 つは、ステートメント単位でロックのエスカレートを無効にするトレース フラグ 1224 です。

システムを監視する
関連資料
  • インサイド Microsoft SQL Server 2005 (Kalen Delaney 著)
  • SQL Server 2005 および SQL Server 2000 のブロッキングを監視する方法
  • SQL Server 2005 のパフォーマンス統計情報を取得するスクリプト
  • SQL Server でロックのエスカレーションが原因で発生するブロッキング問題を解決する方法
  • ロックのエスカレーション (データベース エンジン)

ブロッキングとロックがシステム全体のパフォーマンスに与える影響を監視するには、特定の間隔 (1 時間など) で状態データをポーリングし、保持されているロックの状態に関する統計情報をキャプチャします。キャプチャする重要な情報は、次のとおりです。
  • 影響を受けるオブジェクト、粒度、およびロックの種類
  • ロックとブロッキングの期間
  • 発行された SQL コマンド (ストアド プロシージャ名、SQL ステートメントの内容)
  • パフォーマンスに影響を与えるブロッキング チェーンの情報
  • システムがロックに使用しているメモリの量
図 3 のようなスクリプトを実行してこの情報をキャプチャし、関連するタイムスタンプと共にテーブルに書き込むことができます。さらに、ブロックされているデータの ResourceId を確認するには、図 4 のようなスクリプトを実行します。
Figure 4 Learning more about blocked data (Close Figure 4)
DECLARE @SQL                           nvarchar(max)
      , @CallingResourceType           varchar(30)
      , @Objectname                    sysname
      , @DBName                        sysname
      , @resource_associated_entity_id int

-- TODO: Set the variables for the object you wish to look up

SET @SQL = N'
USE     ' + @DbName + N'
DECLARE @ObjectId int

SELECT  @ObjectId = CASE
                    WHEN @CallingResourceType = ''OBJECT''
                    THEN @resource_associated_entity_id
                    WHEN @CallingResourceType IN (''HOBT'', ''RID'', ''KEY'',''PAGE'')
                    THEN (SELECT  object_id
                          FROM    sys.partitions
                          WHERE   hobt_id = @resource_associated_entity_id)
                    WHEN @CallingResourceType = ''ALLOCATION_UNIT''
                    THEN (SELECT  CASE
                                     WHEN type IN (1, 3)
                                     THEN (SELECT  object_id
                                           FROM    sys.partitions
                                           WHERE   hobt_id = allocation_unit_id)
                                     WHEN type = 2
                                     THEN (SELECT  object_id
                                           FROM    sys.partitions
                                           WHERE   partition_id = allocation_unit_id)
                                     ELSE NULL
                                     END
                          FROM    sys.allocation_units
                          WHERE   allocation_unit_id = @resource_associated_entity_id)
                    ELSE NULL
                    END

SELECT  @ObjectName = OBJECT_NAME(@ObjectId)'

EXEC    dbo.sp_executeSQL
        @SQL
      , N'@CallingResourceType varchar(30)
      , @resource_associated_entity_id int
      , @ObjectName sysname OUTPUT'
      , @resource_associated_entity_id = @resource_associated_entity_id
      , @CallingResourceType = @CallingResourceType
      , @ObjectName = @ObjectName OUTPUT
Figure 3 Capturing locking stats (Close Figure 3)
SELECT  er.wait_time                      AS WaitMSQty
      , er.session_id                     AS CallingSpId
      , LEFT(nt_user_name, 30)            AS CallingUserName
      , LEFT(ces.program_name, 40)        AS CallingProgramName
      , er.blocking_session_id            AS BlockingSpId
      , DB_NAME(er.database_id)           AS DbName
      , CAST(csql.text AS varchar(255))   AS CallingSQL
      , clck.CallingResourceId
      , clck.CallingResourceType
      , clck.CallingRequestMode
      , CAST(bsql.text AS varchar(255))   AS BlockingSQL
      , blck.BlockingResourceType
      , blck.BlockingRequestMode
FROM    master.sys.dm_exec_requests er WITH (NOLOCK)
        JOIN master.sys.dm_exec_sessions ces WITH (NOLOCK)
          ON er.session_id = ces.session_id
        CROSS APPLY fn_get_sql (er.sql_handle) csql
        JOIN (
-- Retrieve lock information for calling process, return only one record to
-- report information at the session level
              SELECT  cl.request_session_id                 AS CallingSpId
                    , MIN(cl.resource_associated_entity_id) AS CallingResourceId
                    , MIN(LEFT(cl.resource_type, 30))       AS CallingResourceType
                    , MIN(LEFT(cl.request_mode, 30))        AS CallingRequestMode
-- (i.e. schema, update, etc.)
              FROM    master.sys.dm_tran_locks cl WITH (nolock)
              WHERE   cl.request_status = 'WAIT' -- Status of the lock request = waiting
              GROUP BY cl.request_session_id
              ) AS clck
           ON er.session_id = clck.CallingSpid
         JOIN (
              -- Retrieve lock information for blocking process
              -- Only one record will be returned (one possibility, for instance,
              -- is for multiple row locks to occur)
              SELECT  bl.request_session_id            AS BlockingSpId
                    , bl.resource_associated_entity_id AS BlockingResourceId
                    , MIN(LEFT(bl.resource_type, 30))  AS BlockingResourceType
                    , MIN(LEFT(bl.request_mode, 30))   AS BlockingRequestMode
              FROM    master.sys.dm_tran_locks bl WITH (nolock)
              GROUP BY bl.request_session_id
                    , bl.resource_associated_entity_id
              ) AS blck
           ON er.blocking_session_id = blck.BlockingSpId
          AND clck.CallingResourceId = blck.BlockingResourceId
        JOIN master.sys.dm_exec_connections ber WITH (NOLOCK)
          ON er.blocking_session_id = ber.session_id
        CROSS APPLY fn_get_sql (ber.most_recent_sql_handle) bsql
WHERE   ces.is_user_process = 1
        AND er.wait_time > 0
SQL Server Profiler (Lock:Escalation イベント) や dm_db_index_operational_stats 動的管理ビュー (index_lock_promotion_count) を使用したり、定期的にシステムのロックに関する情報をポーリングすることによって、システムで発生するエスカレートを監視できます。エスカレートの監視では、特定の処理が原因でエスカレートが発生しているかどうかを調査します。特定の処理がエスカレートの原因ではない場合、関連するストアド プロシージャがパフォーマンスに関する問題の根本的な原因となっている可能性があります。また、最も重点的に評価する必要があるのは、大量のデータが格納されているテーブルや、同時に使用する頻度が高いテーブルです。
ロック、ブロッキング、およびエスカレートに関するデータを収集したら、それらのデータを分析して、発生したブロッキングとロックの累積時間をオブジェクト単位で確認できます (発生回数に発生期間を掛けて算出します)。これで通常は、変更の展開、監視、分析、および修正という作業から構成されるパフォーマンス チューニングのサイクルを開始できます。場合によっては、インデックスの追加などの簡単な変更を加えるだけで、大幅にパフォーマンスが向上したり、これまでとは異なる領域が、システムで最も大きなパフォーマンスのボトルネックになったりすることがあります。
SQL Server でのブロッキングの発生率を最小限に抑える方法については、補足記事「関連資料」を参照してください。設計、コーディング、および安定化という各段階で、トランザクションのサイズを抑えることに注意が向けられれば、ブロッキングに関する問題の発生率を最小限に抑えることができます。また、適切なハードウェアを使用することによって、不要なエスカレートが発生する可能性を大幅に低下させることができます。さらに、どのような場合でも、システムで発生するブロッキングを継続的に評価すれば、パフォーマンスに関する問題の根本的な原因をすばやく特定できます。

Cherié Warren は、Microsoft IT の上級開発責任者です。現在マイクロソフトで、非常に大規模なトランザクション データベースの開発を担当しています。ブロッキングの原因に関するコンサルティングを行ったり、ブロッキングによって発生するパフォーマンスの問題に対処したりすることもよくあります。10 年間にわたって、企業レベルの SQL Server データベースを専門とした業務に従事しています。


 Microsoft Office: Access データベースを SharePoint と統合する
Microsoft Office Peter Serzo

Access データベースを SharePoint と統合する
概要:
  • Access と SharePoint を統合するメリット
  • Access データを SharePoint に移行する
  • SharePoint を使用して Access の機能を拡張する

エンド ユーザーに Microsoft Office SharePoint Server (MOSS) 2007 の話をするときには、必ず彼らが使用しているツールとその使用方法を確認します。ほぼ間違いなく、
組織の中のだれかは、必要不可欠なビジネス ニーズに対応するために Microsoft® Office AccessTM を使用しています。多くの企業において、Access は、今もなお有効なツールであり、重要な資産です。
MOSS 2007 では、Access ベースのアプリケーションを活用し、それらのアプリケーションを SharePoint® に統合して、はるかに優れた新しいソリューションを作成する方法を提供します。この記事では、MOSS と Access を統合する方法とそのタイミング、エンド ユーザーが、これらの 2 つの製品を構成してソリューションを作成する方法に重点を置いて説明します。
MOSS が Access との統合にもたらす基礎となるテクノロジには、ワークフロー、共通のリポジトリ (SQL Server®)、および Web ベースのインターフェイス (ブラウザ) があります。SharePoint の機能には、ドキュメントの管理、ワークスペース、カスタム リストの設定、組み込みのワークフローや Web パーツを使用する機能があります。組み込みのワークフローと Web パーツを使用すると、イベントの公開、連絡先リストや案件リストの作成、ユーザーが作成したフォームの管理など、ありとあらゆる処理に対応できます。また、使い慣れていて、使いやすい Office テクノロジが採用されている点で、エンド ユーザーが、ツールを使いこなせていると感じる度合いが高くなります。この後で説明しますが、MOSS は現在使用している既存のソリューションに影響しません。それどころか、アプリケーションを記述し直す必要がなく、エンド ユーザーは、技術的な問題ではなく、業務上の問題解決に注力できるので、MOSS の導入により作業効率が向上します。
メリットがあるのはエンド ユーザーだけではありません。社内の至るところにあるカスタム データベースの管理に関してエンド ユーザーをサポートするという問題に取り組んでいる IT 部門や IT 管理者にもメリットがあります。記憶域の制限、複数のユーザーによるアクセス、セキュリティ、破損したデータベースの修復、Web の使用、互換性のない Access のバージョン、複数のデスクトップ コンピュータに変更を展開するなどの、具体的な問題が発生するまで、Access がミッション クリティカルなビジネスの問題を解決するのに使用されていることを知らないユーザーは少なくありません。SharePoint には、このような問題への対応策が用意されています。
Access には制限事項がありますが、特に業務でコードを記述しない人にとっては、強力で使いやすいツールです。Access では、構成可能なリレーショナル テーブル、シンプルなクエリ (と複雑なクエリ)、ドラッグ アンド ドロップに対応したフロントエンドのフォーム作成ツール、データに基づいたレポート、複数のユーザーを構成する機能に 1 つの場所からアクセスできます。Access と SharePoint ベースのソリューションを作成することは、資産と人材をプールすることを望んでいる組織にとっても、長年にわたって作成および培ってきたアプリケーションとスキルを活用することを望んでいる個人にとってもメリットがあります。

はじめに
Access 2007 には、MOSS 2007 と統合するためのいくつかのオプションが用意されています。このようなオプションには、図 1 に示すように、SharePoint リストからのデータのインポート、SharePoint サイトへのデータの発行、SharePoint リストの作成、SharePoint データを外部ソースとして使用、Access データベースを新しい SharePoint サイトまたは既存の SharePoint サイトに移行、SharePoint データへのオフライン アクセスを行うものがあります。
Figure 1 SharePoint と統合するための Access 2007 のわかりやすいエントリ ポイント
Figure 1 SharePoint と統合するための Access 2007 のわかりやすいエントリ ポイント
最初の作業としては、Access テーブルから SharePoint リストを作成するのがお勧めです。SharePoint リストは Access のテーブルとよく似ています。SharePoint リストは SQL Server のコンテンツ データベースに格納され、ある一定のフィールド属性があり、ルックアップをサポートしています。
SharePoint リストを作成するときには、覚えておいた方がよい注意事項があります。まず、最適なパフォーマンスを実現するには、1 つのビューで表示するアイテムの数を 2,000 個に制限することがマイクロソフトにより推奨されています。また、SharePoint では、参照整合性が維持されません。そして、OLE オブジェクトは SharePoint にエクスポートされず、データの検証に制限があります。
Access テーブルから SharePoint リストを作成するには、[外部データ] タブを選択し、[エクスポート] の [SharePoint リスト] ボタンをクリックします。次に、このリストがアクティブになる SharePoint サイトを指定する必要があります。これには、[エクスポート - SharePoint サイト] ダイアログ ボックス （図 2 参照） で必要なデータを入力するか、テーブルを右クリックし、[SharePoint リストにエクスポート] をクリックします。テーブルが、リレーションシップの子である場合、親テーブルもエクスポートされることに注意してください。
Figure 2 Access データを指定した SharePoint サイトにエクスポートする
Figure 2 Access データを指定した SharePoint サイトにエクスポートする
エクスポートの処理が完了すると、同じ手順を繰り返さなくて済むように、エクスポートの手順を保存するオプションが提示されます。この時点で、SharePoint サイトにアクセスして、アップロードしたデータを確認できます。この単純な操作は、Access のデータを SharePoint に移行して、ユーザーがアクセスできるようにする場合に役立ちます。この移行により、データは SQL Server データベースに格納され、情報にはブラウザ経由でアクセスできるようになるので、セキュリティが強化され、簡単にアクセスできるようになるというメリットがあります。
しかし、SharePoint リストを Access のテーブルとしてリンクするという別の操作の方が、Access と SharePoint を統合するより効率的な方法であることがわかりました。この操作を行うには、Access で [外部データ] タブをクリックし、[インポート] の [SharePoint リスト] ボタンをクリックします。このボタンをクリックすると、図 3 のようなダイアログ ボックスが表示されます。
Figure 3 Access を SharePoint にリンクする
Figure 3 Access を SharePoint にリンクする
リンク対象のデータ ソースとして使用する SharePoint リストを含むサイトを選択してから、リンクするリストを選択します。Access では、この操作が完了すると、SharePoint リストはリンクされたテーブルとして表示されます。また、Access の右下隅には、"SharePoint とオンライン接続" というインジケータが表示されます。この時点では、Access と SharePoint の間では双方向の同期が行われるようになり、SharePoint と Access のどちらからでも追加、変更、および削除の操作を行うことができます。この後で説明しますが、テーブルに対してコードを記述することで追加機能を提供できます。
Access で SharePoint リストにリンクすると、別のテーブル (Windows® SharePoint Services (WSS) ユーザー情報リスト) も既定でインポートおよびリンクされます。"SharePoint サイトへの移動に関する問題" という名前の問題のテーブルが作成されます。このテーブルでは、データに関する競合情報を確認できます。
データの移行と変換時のデータ型の処理方法の詳細については、「Access が Access と SharePoint 間でデータ型を変換する方法」(office.microsoft.com/en-us/access/HP010477131033.aspx) と、「Access データベースのテーブルを SharePoint サイトに移行およびリンクする」(office.microsoft.com/en-us/access/HA101314681033.aspx) の移行に関する制限事項について説明しているセクションを参照してください。
テーブルとリストを統合する 3 つ目の方法は、SharePoint 側から行う操作です。リストを選択し、[操作] タブの [Access で開く] をクリックします。この操作により、新規または既存のデータベースの名前を指定するダイアログ ボックスが表示されます。データベース名を指定したら、データを単に SharePoint サイトにリンクするのか、データを Access に完全エクスポートするのかを選択します (図 4 参照)。
Figure 4 Access から SharePoint データにアクセスできるようにする
Figure 4 Access から SharePoint データにアクセスできるようにする

データベースを SharePoint に移行する
ここまでは、SharePoint リストをリンクされたテーブルとしてインポートし、テーブルを SharePoint にリストとしてエクスポートする処理について説明しましたが、データベース全体にアクセスする必要がある場合は、どうしたらよいでしょうか。多くの組織では、Access ベースのミッションクリティカルなアプリケーションを所有しており、そのような Access アプリケーションをリモートで使用できるようにして、各ユーザーがレポートやクエリを実行したり、データを入力したりできるようにする必要があります。このような場合は、経済的にも、利用できるスキルによっても、アプリケーションを記述し直すことが適切な処置とは限りません。SharePoint と Access では、Access の [SharePoint リスト] タブにある [SharePoint に移動] オプションで、この問題に対応しています。このオプションは、Access 97 で初めて導入された、アップサイジング ウィザードを使用して SQL Server にデータを移動する機能と似ています。
Access データベース全体を SharePoint に移動するメリットは、すべてのテーブルが SharePoint リストに変換され、バックアップが Access データベース形式で作成され、リストが自動的に Access にリンクされたテーブルに変換され、テーブルだけでなくデータベース全体を移動でき、データベースが移動前と同様に動作することです。
[SharePoint に移動] ボタンをクリックすると、図 5 に示すダイアログ ボックスが表示されます。サイトを指定したら、データベースを保存するオプションを選択するかどうかを決める必要があります。このオプションを選択すると、データベース全体が選択したドキュメント ライブラリに保存されます。つまり、データベース全体 (フォーム、レポート、クエリ、およびマクロを含む) が、SharePoint に保存され、サーバーで利用できるようになります。ユーザーがデータベースにアクセスする必要がある場合は、データベースが保存されているライブラリにアクセスして、データベースをクリックすると、データベースは自動的にそのユーザーのデスクトップに展開されます。
Figure 5 データベースの移動先となる SharePoint サイトを指定する
Figure 5 データベースの移動先となる SharePoint サイトを指定する
データベース全体を移動すると、リボンの下に [変更内容の発行] メッセージ バーが表示されます。このメッセージ バーを使用すると、ローカルでデザインとデータに加えた変更内容をサーバーにあるデータベースと同期できます。このオプションを選択しない場合、テーブルは単にリストに変換され、Access にリンクされます。また、ユーザーはデータベース全体にアクセスすることはできず、データベースは SharePoint でオブジェクトとしてバックアップされません。
どちらかのオプションを選択すると、データベースとその関連情報は、選択した SharePoint サイトで利用できるようになります。ここでも、"SharePoint サイトへの移動に関する問題" という名前のテーブルが自動的に作成されます。このテーブルには、移行に起因する競合情報が格納されます。SharePoint サイトにテーブルをアップロードしているときに Access 側で発生した問題については、このテーブルで確認できます。

ビュー、フォーム、およびレポート
データベースを移動したら、移動したデータベースの機能をテストする必要があります。テストを開始する前に "SharePoint とオンライン接続" というインジケータが表示されていることを確認します。Access クエリは SharePoint ビューに変換されていることに注意してください。SharePoint ビューは Access クエリとよく似ています。
データベース全体を移動すると、既存のクエリはビューとして SharePoint にコピーされます。Access ユーザーであれば、クエリを記述してデータのサブセットを確認できることはご存知だと思いますが、これと同じ処理を SharePoint ビューで行う方法を習得すると、SharePoint リストでデータがどのように管理されているのかを理解するのに役立ちます。
ユーザーが作成できる最も有益なビューは、アクセス ビューです。このビューを作成するには、ビューを作成するリストに移動し、[ビュー] を選択し、[ビューの作成] をクリックします。この操作により、リストに基づいてフォームやレポートを作成するアクセス ビューのオプションが表示されます。このオプションをクリックして、Access データベースを選択すると、図 6 に示すようなダイアログ ボックスが表示されます。ご覧のとおり、このダイアログ ボックスでは、形式 (フォーム、ピボットグラフ、ピボットテーブル、またはレポートの種類) を定義します。この処理が完了すると、Access データベースにリンクされたフォームまたはレポートが作成されます。
Figure 6 アクセス ビューを作成する
Figure 6 アクセス ビューを作成する

オフライン アクセス
実世界では、ミッションクリティカルなアプリケーションの処理範囲を広げることは、投資収益につながります。統合された Access と SharePoint ベースのアプリケーションの処理範囲を拡大する 1 つの方法は、アプリケーションを使用するのに SharePoint に接続している必要がないことを認識することです。このような柔軟性を活用するために、Access 2007 ではオフライン作業の機能が導入されました。情報は、サーバーにアタッチされるまで、ローカルにあるデータベースのコピーにキャッシュされます。データベースをオフラインで作業するには、リボンの [外部データ] タブにある [SharePoint リスト] の [オフライン作業] ボタンをクリックします。
SharePoint に再接続する際には、[オンライン作業] または [同期] のどちらかのオプションを選択できます。どちらのオプションを選択した場合も、データがアップロードされ、競合情報が提示されますが、[同期] をクリックすると、データはアップロードされますが、アプリケーションではオフラインの状態が維持されます。
[SharePoint リスト] グループにあるアイテムで紹介すべきものは、[変更を破棄] で、これには 2 つのオプションがあります。1 つ目のオプションは、すべての変更を破棄しますが、Access に格納されている SharePoint データは更新しません。これに対して、2 つ目のオプションでは、すべての変更を破棄して、SharePoint データ (リンクされたリスト) を更新します。

Access テンプレート
Access 2007 には、ユーザーがビジネス ソリューションを迅速に作成するのに役立つ、いくつかの組み込みのテンプレートが用意されています。ご覧のように、ソリューションは、[作成] タブの [テーブル] グループにある [SharePoint リスト] ボタンをクリックして作成できます (図 7 参照)。テンプレートを選択すると、SharePoint にリンクされたテーブルのスキーマが自動的に定義されます。現時点では、連絡先、タスク、案件、およびイベントのみがサポートされています。つまり、これらの種類の情報を含むテーブルをエクスポートすると、データは対応する WSS のコンテンツ タイプに変換されます (たとえば、案件は案件リストになります)。
Figure 7 リストの種類を選択する
Figure 7 リストの種類を選択する
また、SharePoint リストに使用できるカスタム テンプレートを作成したり、自動的にリンクする Access 2007 データベースを使用して SharePoint サイトを作成できます。これには、Access 2007 Developer Extensions とテーブルに WSSTemplateID を設定することが必要です。このプロパティでは、SharePoint リスト テンプレートに相当するものを含むテーブルを追跡します。

Access とメタデータ
さまざまな機能を備えた Access アプリケーションを使用している企業では、すべての Access アプリケーションを SharePoint に移動することができたり、移動することを希望しているとは限りません。このような場合は、Access 側でコードを記述して SharePoint を更新するのが適しています。コードを使用すると、SharePoint と Access を連結できます。
簡単な例として、Northwind Traders のデータベースを使用して説明しましょう。このデータベースには、製品、仕入先、受注に関する情報が格納されています。通常、各製品には、業者が .pdf ファイル形式で提供している製品シートが関連付けられています。Access データベースには、場所、製品番号、リビジョン履歴、企業の部門コードなど、製品シートに含まれているすべての情報が格納されています。この情報は、SharePoint エクストラネットを経由して仕入先と業者が利用できる必要があります。
SharePoint サイトは設定され、すべてのドキュメントはリンクされたドキュメント ライブラリに移動されますが、メタデータ フィールドは空のままです (図 8 参照)。これは、データが Access で追跡されていることが原因です (また、この情報を監視している担当者は、Access を使用する操作に慣れているため、それを変更することに乗り気でないからです)。
Figure 8 SharePoint で表示した Northwind ドキュメント (メタデータがありません)
Figure 8 SharePoint で表示した Northwind ドキュメント (メタデータがありません)
図 9 に示すように、Visual Basic® for Applications (VBA) コードを使用して、Access アプリケーションからメタデータを更新できるので、アプリケーションを記述し直す必要はありません。従業員は、これまでどおり使い慣れているツールを使用することができ、業者は与えられた権限に基づいてエクストラネットにアクセスできます (権限は各業者に適切な情報のみが提供されるようにするために必要です)。また、同時接続やデータベースのサイズに関する問題が発生することはありません。
Figure 9 コードを使用してメタデータを更新する
Figure 9 コードを使用してメタデータを更新する

組み込みのセキュリティ機能
Access アプリケーションを SharePoint に移動することの最大のメリットは、Active Directory® 認証が組み込まれている SharePoint のセキュリティ モデルを活用できることです。つまり、スキーマとテーブルを作成して、ユーザーを追加するなど、Access アプリケーションにセキュリティを実装する方法について悩む必要がなくなります。SharePoint リストを使用すると、ユーザーに許可されているものだけが表示されるようにするセキュリティ調整を活用できます。これは、SharePoint の組み込み機能です。また、SharePoint に移動しないことが望ましいコンポーネントは、移動する必要がありません。
SharePoint には、詳細な役割ベースのセキュリティ モデルが用意されています。データベースの移動方法と移動先を決める際には、移行の前にサイトとセキュリティをデザインすることをお勧めします。このような手順を踏むと、権限の設定とテストを簡単に行えます。また、移行時の問題も少なくなり、Access データベースのパフォーマンスが効率的になります。

参照整合性
参照整合性に言及しなければ、この記事はその役割を怠っているということになるでしょう。実のところ、Access と異なり、SharePoint では参照整合性が維持されません。多くの Access データベースでは、ある程度の正規化が行われています。というのも、ミッション クリティカルな Access データベースが機能するには、ある程度の正規化が行われている必要があるからです。さいわいにも、既存のシステムへの機能強化として解釈できるいくつかの回避策があります。
データベースを SharePoint に移動する際に、子テーブルを移動すると親テーブルも移動されるということについては既に説明しました。また、SharePoint では、フィールドの値が別のテーブルに基づいていることが認識されると、ルックアップ フィールドが使用されます。たとえば、顧客が選択されていて、注文が Northwind Traders データベースに格納されたとしましょう。これらのテーブルを SharePoint に移動すると、受注リストでは、顧客フィールドがルックアップ フィールドになります。
更新または削除した内容を転送したり、複雑な操作を行う必要がある場合については、どうでしょうか。このような場合は、ソリューションの 1 つとして SharePoint とそのワークフローを検討することをお勧めします。Northwind Traders データベースの話に戻りますが、顧客から連絡があって、既存の注文がキャンセルされると、それに伴い、いくつかの操作が行われます。在庫を元に戻し、仕入先に連絡し、その注文を担当している従業員は顧客に対応し、発送をキャンセルし、課金情報を更新する必要があります。この操作では、多くのパーツを移動したり、多くのものを調整したりする必要があります。
SharePoint では、SharePoint デザイナを使用すると、注文の状態が変更されるとすぐに、前述のすべての処理を行うワークフローを作成できます。組み込みのワークフローが 22 個あり、これらを組み合わせて数百もの操作を実現できます。SharePoint デザイナは、サイトに商標を付ける作業とワークフローを作成する作業のどちらにも役立つ優れたツールです。
最も良いことは、SharePoint デザイナを使用してワークフローを作成するのに必要なスキルに、Access でプログラミングを行う方法を把握しているユーザーに馴染みのあるスキルが含まれていることです。つまり、Access アプリケーションを作成していたユーザーは、それほど努力をする必要なく自分が持っているスキルをワークフローの作成に活かすことができます。SharePoint デザイナを使用してワークフローを作成する際にはコードを記述する必要はなく、ワークフローは簡単に展開できます。

Peter Serzo は CDW Berbee に勤務しているシニア エンジニアです。彼は世界各地の企業が SharePoint エンタープライズ ソリューションを作成するサポートをしています。


 編集長から: 今まで貢献してくれた仲間と新しい仲間へ
編集長から
今まで貢献してくれた仲間と新しい仲間へ

今月は、 嬉しくもあり悲しくもあるお知らせから始めなければなりません。悲しいことに、「The Cable Guy」の執筆者である Joseph Davies とのお別れのときが来てしまいました。彼が TechNet Magazine でコラムを執筆するのは、今月号が最後です。Joseph のような才能のある専門家に Windows ネットワークに関する無数のトピックについて教えてもらうことができ、私たちは非常に幸運でした。Joseph は最近マイクロソフトで新たに重要な職務を引き受けたので、残念ながら月刊コラムの執筆を続けることはできなくなりました。TechNet Magazine の製作に携わっている私たち全員が、彼が長年にわたって多大な貢献を果たしてくれたことに感謝し、彼が新たな仕事で成功を収めることを願っています。
「The Cable Guy」が終了してしまうのは悲しいことですが、歩みを止めるわけにはいきません。そこで、来月号からは「SharePoint の内部」という新しいコラムを開始します。この 1 年間、SharePoint についての知識やガイダンスをもっと提供してほしいという意見が非常に多く寄せられました。また、SharePoint は急速に発展している魅力的なテクノロジであり、まさに月刊コラムにうってつけのテーマです。執筆を担当する Pav Cherny は、まず SharePoint インフラストラクチャのアーキテクチャについて概説します。今後数か月にわたり、セキュリティ、可用性、パフォーマンス、トラブルシューティングなど、さまざまなことについて説明していきます。取り上げてほしい SharePoint 関連のトピックがある場合は、tnmag@microsoft.com まで電子メールをお送りください。
また、Terrence Dorsey と Nancy Michell という 2 人の上級編集者にも大いなる感謝の意を表さなければなりません。Terry と Nancy は創刊当初から製作に携わっているメンバであり、その多彩な才能と経験によって、今日の TechNet Magazine を形作ってくれました。しかし、今月号から Terry と Nancy は、TechNet Magazine の姉妹誌である MSDN Magazine に全精力を注ぐことになりました。代わりに、Matthew Graven と Sharon Terdeman という才能あふれる上級編集者 2 人が、MSDN Magazine に別れを告げ、TechNet Magazine での職務に全力で取り組んでくれます。さいわい、Terry と Nancy は遠くに行ってしまうわけではないので、今後も私たちは、TechNet Magazine の発展のために、2 人の見識や専門的知識に頼ることになると思います。
お知らせは以上です。では、今月号をお楽しみください。今月号では、間もなく発売される SQL Server 2008 を特集しており、データの格納、保護、管理、および活用に役立つさまざまな新機能について説明しています。データの量は増加の一途をたどり、その範囲も拡大しているので、ほぼ間違いなく、最も重要なビジネス資産であると言えるでしょう。 —Joshua Hoffman


 レター: 読者の皆さんからの声
レター
読者の皆さんからの声

強力なホストと弱いホスト
2007 年 9 月の The Cable Guy コラム「強力なホスト モデルと弱いホスト モデル」(technetmagazine.com/issues/ 2007/09/CableGuy) に、弱いホストの使用を有効または無効にできるという説明がありましたが、その方法は記載されていませんでした。ファイアウォールを有効または無効にしたり、レジストリのパラメータを設定したりすればよいのでしょうか。この操作に関連するレジストリのパラメータがあれば教えてください。
また、ローカル アクセスの構成には、IP アドレスと IP マスクという 2 つの情報が必要です。オプションのゲートウェイ パラメータが含まれていない構成は、なぜ無効な構成と見なされないのでしょうか。
—Milt B
Windows Vista® と Windows Server® 2008 では、図に記載されているコマンドを使用して、強力なホストまたは弱いホストの動作を構成できます (このコマンドは、2007 年 9 月のコラムで初めて紹介しました)。対応するレジストリ エントリはありません。また、Windows® XP と Windows Server 2003 では、強力なホストまたは弱いホストの動作を構成できません。IPv4 では弱いホストのみ、IPv6 では強力なホストのみを構成できます。
2 番目のご質問についてですが、私たちの知る限り、インターフェイスの IPv4 または IPv6 の設定を構成する際に、ユーザー インターフェイスやコマンド ラインを使用してデフォルト ゲートウェイやルーターを構成する必要はありません。


 ツールボックス: IT プロフェッショナル向けの新製品
ツールボックス
IT プロフェッショナル向けの新製品
Greg Steen

複数のモニタを管理する
UltraMon
realtimesoft.com
LCD パネルの価格の低下により、ほとんどのシステム管理者は、さまざまな管理用ダッシュボードを監視するために、ワークステーションで少なくとも 2 台のモニタを使用しています (複数のモニタを使用すると作業が非常に楽になるので、複数のモニタを使用していない場合は、複数のモニタを使用することを強くお勧めします)。しかし、モニタをさらに 1、2 台追加すると、マウスを頻繁に使用することになるので、作業効率が低下します。そのため、キーボード ショートカットに対応している優れた使い勝手の良いディスプレイ管理ユーティリティは、非常に役立ちます。そのような検討する価値のあるツールの 1 つが Realtime Soft の UltraMon です。このツールでは、Windows® 98 から Windows Vista® までの 32 ビット版と 64 ビット版の両方をサポートしています。
UltraMon の初回起動時には、各アプリケーション ウィンドウの隅に 2 つの小さなアイコンが表示されることに気付くでしょう。1 つ目のアイコンをクリックすると当該アプリケーション ウィンドウが複数のモニタにまたがるようすばやく拡大され、2 つ目のアイコンをクリックすると当該アプリケーションが別のモニタに移動されます。また、タスク バーがすべてのモニタに拡張して表示され、各モニタのアクティブなアプリケーションが表示されていることにも気が付くでしょう。つまり、アプリケーションを拡張するのにプライマリ モニタと行き来する必要がなく、最大化および最小化を行ったときにアプリケーションが表示される場所がすぐにわかります。
アプリケーションのすべてのショートカットでは、UltraMon タブを使用して、アプリケーションが起動する場所や配置を定義できます。たとえば、必ず Microsoft® Outlook® が左のモニタに表示され、Internet Explorer® が右のモニタに表示されるように設定できます。IT プロフェッショナルである皆さんは、ノート コンピュータや自宅のデスクトップ コンピュータなどのさまざまな場所からワークステーションにリモートで接続していると思いますが、これらの各リモート接続では、おそらくデスクトップとモニタの解像度の変更が若干必要になる場合があることをご理解ください。
さいわい、UltraMon では、モニタのプロファイルもサポートされており、モニタ間でカスタマイズした表示を簡単に切り替えることができます。これは、独自にカスタマイズした表示が必要な他の人とコンピュータを共有している場合や、作業内容に基づいて表示を変更する場合に非常に便利です。
Windows 2000 または Windows XP を実行している場合は、ミラー機能を使用できます。この機能は、プライマリ モニタをプレゼンテーション用のモニタより高い解像度で実行しても、両方のモニタでアプリケーションの動作をミラー化できるので、プレゼンテーションに最適です。Windows Vista にまだアップグレードしていない場合でも、UltraMon を使用するとアプリケーションのウィンドウを複数のモニタにまたがるように拡張することもできます (これは、Windows Vista では既定の動作です)。
[Display Settings] (ディスプレイの設定) ウィンドウへのショートカット、システムでプライマリ モニタを簡単に設定して切り替える機能、別のモニタ プロファイルへの切り替えなどの他の表示機能には、簡単にアクセスすることが可能で、これらの機能は頻繁に使用することになるでしょう。これらの機能はシステム トレイにある UltraMon のアイコンからアクセスできます。このアイコンから [UltraMon Options] (UltraMon のオプション) ウィンドウを開くと、Smart Taskbar (スマート タスク バー) のカスタマイズ、ウィンドウの移動や変更を行うホット キーの設定、および指定したフォーカス ポイントへのマウスの移動など、さまざまな操作を実行できます。

価格 : 1 ライセンス 39.95 ドル～
The options window in UltraMon lets you set up hotkeys and manage your Smart Taskbar
The options window in UltraMon lets you set up hotkeys and manage your Smart Taskbar

ブック レビュー
Microsoft SQL Server 2005 Analysis Services
informit.com
顧客ベースについての広範なデータを保持することと、そのデータを理解および処理して、顧客に関する有用でわかりやすい統計を作成することはまったく別の問題です。このような計算される展望や予測を得るには、動的で強力なビジネス インテリジェンス ソリューションが必要です。ビジネス インテリジェンスとオンライン分析処理 (OLAP) の分野で役立つマイクロソフト ソリューションの 1 つが、SQL Server® 2005 Analysis Services です。そしてこのソリューションを完全に活用する方法を説明するのが、『Microsoft SQL Server 2005 Analysis Services』です。
この書籍は Py Bateman、Alexander Berger、Irina Gorbach、および Edward Melomed の共著で、Analysis Services 2000 から Analysis Services 2005 にアップグレードして新しいデータ マイニングを配置することを検討している方にも、ご自身と所属組織にこれらのツールがどのようなメリットをもたらすのかということに興味を持っているデータベース管理者にもお勧めです。本書はビジネス インテリジェンスの理論的な手法の領域にとどまらず、実際の Analysis Services の使用、開発、展開、および管理について詳しく具体的に説明しています。ここで紹介されている例の多くは、Analysis Services に同梱されているサンプル データベースの Food Mart 2005 を利用しているので、すぐにテスト環境で試してみることができます。
本書の導入部分では、Web サービスの XML for Analysis (XMLA) 通信に対応したクライアント サーバー アーキテクチャ、統合ディメンション モデル、スケーラビリティの強化など、SQL Server 2005 の新機能を紹介しています。また、Food Mart サンプル データベースの概要と、多次元データベースの基礎についても説明しています。次に、データ定義言語 (DDL) の XML、ディメンションの属性と階層、およびキューブと多次元分析を学習して、実際にデータ モデルを作成します。また、Business Intelligence Development Studio を使用して、デザインおよび開発時に SQL Server 2005 Analysis Services のビジネス インテリジェンスを活用する方法についても紹介しています。
デザイン上の概念を理解したら、多次元式 (MDX) によるデータの操作に進みます。MDX でデータをクエリする方法だけでなく、MDX 関数、メンバ プロパティ、およびセルのプロパティの使用方法についても学習します。また、空のセットと NULL、サブセレクト、およびサブキューブの処理方法と、キューブ ベースの MDX の計算を作成して使用し、クエリをストアド プロシージャで拡張する方法についても学習します。その次に主要業績評価指標 (KPI)、ドリルスルー、およびスコアカードについて詳しく説明します。これらはすべて、事業の成長、評価基準、および目標のさまざまな側面を知るのに役立ちます。
次のセクションでは、データの抽出、変換、および読み込み (ETL) 処理について説明し、データをシステムに取り込む方法だけでなく、パフォーマンスが向上するように集計デザインを最適化し、プロアクティブ キャッシュを使用する方法についても説明します。ここでも、キューブとディメンションの物理的なデータ モデルを操作して、それぞれの処理が SQL Sever 2005 Analysis Services と連携する方法を理解します。さらに、ビジネス ニーズに合わせて、展開をスケール アウトおよびスケール アップする方法を説明し、ネットワーク負荷分散、OLAP ファーム、リンク メジャー グループとディメンション グループ、およびリモート パーティションの処理についても説明しています。
本書では、クエリの実行についての実際の詳細についても説明しているので、基盤となっている操作についての理解を深め、アプリケーションのパフォーマンスを微調整できるようになります。クライアントの観点からのデータへのアクセスと、XMLA、ADOMD.net、分析管理オブジェクト (AMO) など、この作業で使用できるさまざまなオプションについて説明します。Visual Studio と Business Intelligence Development Studio の IDE を活用して独自のカスタム データ ウェアハウス アプリケーションを作成する方法を理解するには、このセクションの "内なる開発者" から抜け出す必要があります。
最後のセクションでは、システムのパフォーマンスと正常性を監視するための追跡ツール、フライト レコーダ、および SQL Server Profiler の使用など、Analysis Services の管理について詳しく説明します。さらに、DDL コマンドを使用したデータベースのバックアップ、SQL Server エージェントまたは SQL Server Integration Services (SSIS) による自動化、および紛失または破損したデータの復元テクニックに関する各セクションでは、展開のバックアップと復元のさまざまなオプションを紹介します。全体として、この SQL Server 2005 Analysis Services についてのガイドは、広範囲なトピックについて詳しく解説している書籍です。

価格 : 59.99 ドル

データベースの問題を診断する
ApexSQL Audit
apexsql.com/sql_tools_audit.asp
問題のトラブルシューティングを行ったり、攻撃を受けた場合に追跡を行う際には、まず問題の原因となったイベントに関する適切な情報を収集する必要があることは、ご存知でしょう。エンド ユーザーをサポートする業務に携わっている方であれば、おそらく「システムからデータが消えた」という苦情はよく耳にすると思います。SQL Server データベースの問題にすばやくねらいを定めるのに役立つツールとして、ApexSQL が提供している ApexSQL Audit があります。このツールは SQL Server 7.0 から SQL Server 2005 までを完全にサポートしています。
名前から推測できるように、このツールは指定したデータベースで行われた操作を追跡して、分析に使用する監査記録のカスタム レポートの作成に使用できます。監査エントリは SQL トリガによって追加され、自動生成されたスキーマに保存されます。監査に関する情報は、監視対象のデータと同じデータベースに保存するか、または専用のデータベースに保存して分離するかを選択できます。
監査スキーマ (通称、アーキテクチャ) のインストール (および削除) は、GUI で簡単に行えます。データベースの監査計画は比較的簡単に設定できます。データベースを選択し、監視するテーブルとフィールドを選び、ボタンをクリックすると、トリガが生成されます。
このアプリケーションでは、プロジェクトに応じてトリガ テンプレートを変更できます。私が非常に気に入っている点は、テンプレート エディタで、監査オブジェクト モデルに IntelliSense® と似た機能を使用でき、トリガが起動するタイミングと保存する情報の両方を簡単にカスタマイズできることです。もう 1 つの優れた機能は、参照テーブルを簡単に参照できることです。この機能により、監査に関する情報が単なる不可解な ID の羅列ではなく、わかりやすい情報として提供されます。また、列をマップする場合は、監視されているフィールド名を監査フィールド名にマップできます。
ApexSQL Audit を構成して実行すると、UI で現在適用中の監査トリガをすぐに確認し、1 回のクリック操作で必要に応じて特定のトリガの有効と無効を切り替えることができます。また、インターフェイスの便利なテーブル ビューで、設定している監査の範囲を調べることもできます。
ご存知のとおり、監査に関する情報は冗長になりがちで、監査データベースのアーカイブとトリミングを行うために、なんらかの情報管理計画を導入する必要があります。ApexSQL Audit にはデータ管理ツールが用意されています。このツールでは、1 回のクリック操作で、すべての情報を削除することも、一連の条件を指定してから情報を削除することも、条件に基づいた削除処理をスケジュールすることもできます。
スケジュールされたジョブは、データ変換サービス (DTS) パッケージとして自動的に作成され、SQL エージェントを使用してスケジュールされます。もちろん、監査に関する情報をすべて収集することと、それを活用することはまったく別の問題です。さいわい、ApexSQL Audit には、強力なレポート作成コンポーネントがあり、カスタマイズしてフィルタ処理した最小の監査データのビューと、その監査データを集計したビューの両方を生成できます。レポートが生成されたら、簡単にレポートを印刷したり、出力結果を HTML、Microsoft Excel、またはテキスト ファイルにエクスポートしたりすることができます。

価格 : 599 ドル～
The look-up tables in ApexSQL Audit provide extensive audit information
The look-up tables in ApexSQL Audit provide extensive audit information

パスワードの有効期限切れの通知を自動化する
Password Reminder PRO v1.4
sysoptools.com/password-reminder-pro.html
パスワードの有効期限切れポリシーを組織のグループに適用すると、ヘルプデスクに問い合わせが殺到すると感じたことはありませんか。その場合は、SysOp Tools が提供している Password Reminder PRO を試してみることをお勧めします。この単純なツールは Active Directory® と統合して、エンド ユーザーにアカウントやパスワードの有効期限が間もなく切れることを通知します。
このツールでは、3 つの異なる通知を設定することが可能で、それぞれに別個のテキスト ベース、または HTML 形式の電子メール テンプレートを使用できます。また、パスワードの有効期限を Active Directory の構成と同じ日数に構成し、ユーザーに通知を送信する時刻がピーク時と重複しないように構成することができます。テスト モードを使用すると、実際にエンド ユーザーに影響を与えることなく、結果をプレビューしてすべてが適切に構成されていることを確認できます。
このユーティリティには、レポート コンソールが用意されているので、さまざまなユーザー クラスのデータ グリッド ビューを表示できます。このビューに表示できるのは、有効期限が近づいているアカウント、非アクティブなユーザー、新しいアカウント、無効なアカウントなどです。このレポート コンソールでは、すべての情報を XLS ファイルにエクスポートして、後で確認することができます。送信された通知の詳細な監査については、送信された通知と宛先ユーザーについてのレポートが Password Reminder PRO によって毎日送信されます。

価格 : 100 ユーザー ライセンスあたり 249 ドル～
Password Reminder PRO previews configurations before deployment
Password Reminder PRO previews configurations before deployment

リモートのトラブルシューティングを簡略化する
UltraVnc SC
uvnc.com/pchelpware/sc
多くの場合、問題のトラブルシューティングを行ったり、ユーザーに説明したりする最も簡単な方法は、実際にそのコンピュータのところへ足を運ぶことです。しかし、現代の地理的に分散した企業では、このようなことができない場面は少なくありません。Windows に組み込まれているリモート デスクトップ接続やリモート アシスタンス ツールを使用すると、企業環境内のコンピュータの一部には接続できます。しかし、すべての拠点のコンピュータに対応するには、UltraVNC の主要プロジェクトの製作者が提供している UltraVNC SC を試してみることをお勧めします。
以前の姉妹製品と同様に、UltraVNC SC を使用するとリモート コンピュータの状態を確認して操作できます。ただし、このバージョンは、構成してエンド ユーザーに送信するわずか 166 KB の UltraVNC サーバーです。レジストリ エントリは不要で、サービスとして実行されることはなく、インストーラも不要です。このため、エンド ユーザーがセットアップを実行したり、構成したりする必要はありません。ユーザーが実行可能ファイルをダブルクリックするだけで、小規模な VNC サーバーが実行され、管理者は、ユーザーのコンピュータに接続して、サポートしたり、必要に応じて問題に対応することができます。
標準的な UltraVNC サーバーはファイルとディレクトリの転送をサポートしますが、現在 UltraVNC SC ではファイル転送のみをサポートしています。セキュリティに関しては、通信は Microsoft Crypto API (40 ビットまたは 128 ビット) のレベルで暗号化されます。また、この小型サーバーでは受信接続が許可されず、エンド ユーザーだけがインスタンスを作成できます。さらに、このサーバーが接続できるのは、エンド ユーザーに送信する前に送信側の構成で指定したコンピュータに限定されます。
カスタム ビューアを作成するには、いくつかのテキスト形式の構成ファイルと画像を調整し、PCHelpware という別のプロジェクトのアドオンのインストールからバッチ ファイルを実行して、実行可能ファイルを生成します。このツールのドキュメントは充実していませんが、比較的単純な手順の実行方法が示されています。最後に、このアプリケーションは使用後に接続が切断されると、自動的にアンインストールされるので、使用した形跡が残ることも、セキュリティ ホールを残すこともありません。

価格 : 無償

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、品質保証、および開発に役立つ IT プロフェッショナルのための新しいツールを日夜追い求めています。


 SQL に関する Q&amp;A: データベースの拡張、IFilter の使用、およびリモート接続
SQL に関する Q&A
データベースの拡張、IFilter の使用、およびリモート接続
Edited by Matthew Graven

ヒント : キャッシュをクリアする
テスト環境では問題なく動作するのに、運用環境の SQL Server に展開するとパフォーマンスが低下するストアド プロシージャについて疑問を感じたことはありませんか。その原因はキャッシュと関連がある可能性があります。ストアド プロシージャを運用環境に展開する前に、テスト環境で、キャッシュされているクエリ プランをクリアしてからテストを実行して、ストアド プロシージャに関するデータがキャッシュされていない環境で実行した場合のストアド プロシージャの動作を確認してください。キャッシュをクリアする場合に覚えておくと重宝するものを以下にご紹介します。
SQL Server のプロシージャ キャッシュをクリアするコマンド
DBCC FREEPROCCACHE
Go
キャッシュされているすべてのプランを一覧表示するクエリ
Select * from sys.dm_exec_cached_plans
Go

質問 – 日中のトラフィック量が多いデータベースがあるのですが、トラフィックのピーク時に SQL Server® が自動拡張を実行するとタイムアウトになるおそれがあるので、自動拡張は使用していません。一定の割合の領域が使用されたときに、このデータベース ファイルを拡張する、定期実行ジョブの実装を考えています。このような方法はありますか。
回答 - ファイルの拡張には集中的なディスク I/O 操作が伴います。また、SQL Server でデータ ファイルまたはログ ファイルの拡張を待機する必要が生じると、パフォーマンスと応答時間に確実に影響します。既定の拡張増分値は、データ ファイルでは 1 MB、ログ ファイルでは 10% ですが、アクセスの多いシステムでは、この拡張増分値は不十分です。また、自動拡張に依存していると、データ ファイルまたはログ ファイルのデータが隣接するディスクに格納されないので、ディスクの断片化の原因になります。つまり、データがディスク上で物理的に分散しているので、応答時間が必要以上に長くなることがあります。
高いパフォーマンスを実現するための鍵は、データ ファイルとログ ファイルに、十分なファイル領域を事前に割り当てることです。十分な領域を事前に割り当てるには、なんらかの傾向分析と増分の予測を行う必要がありますが、事前に領域を割り当てると、ファイルのデータがディスク上で連続するようになり、ピーク時間に自動拡張を行った場合に必要になる I/O コストを回避できるので、パフォーマンスが向上します。データ ファイルやログ ファイルが最大サイズに達すると、データベースへのアクセスが妨げられるので、多くの場合、自動拡張は有効にすることをお勧めします。しかし、自動拡張はデータベースを管理するための機能というよりも、重大な障害を避けるための保険であることを覚えておいてください。
定期的にデータベース ファイルを拡張するように設定すると、ファイルのデータがディスク上で連続しなくなり、パフォーマンスの低下を招きます。そのため、定期的にデータベース ファイルを拡張する設定は使用しないことをお勧めします。各データベースの空き領域の割合を判断するスクリプトを (SQL エージェント ジョブを使用して) 定期的に実行し、対策をとる (たとえば、データベース メールを使用してメールで通知を送信する) ことによって積極的な監視を実現できます。現在のデータベースの空き領域の割合を集計して表示するサンプル スクリプトを図に示します。
警告が生成されたら、ALTER DATABASE コマンドを一時的に実行するようなスクリプトを作成し、SQL エージェント ジョブを使用して、ピーク時を避けてこの処理を実行するように設定できます。今後の拡張の見込みに対して十分なサイズまでファイルを拡張し、少しずつファイルを拡張する必要が生じないようにします。自動圧縮が設定されていると、データベースで不必要に拡張と縮小が繰り返し行われる可能性があるので、自動圧縮を設定しているデータベースがないことを確認することもお勧めします。
- Justin Langford
データベースの空き領域の確定
-- Script to gather size, free space and
-- calculate % free space for current
-- USER database
DECLARE @size DEC(15,2)
DECLARE @free DEC(15,2)
DECLARE @result DEC(15,2)

SELECT @size = SUM(size)*1.0/128
FROM sys.database_files

SELECT @free =
(SUM(unallocated_extent_page_count)*1.0/128)
FROM sys.dm_db_file_space_usage

PRINT 'DB Size ' + CONVERT(VARCHAR(15), @size)
PRINT 'Free Space ' +
CONVERT(VARCHAR(15), @free)

SELECT @result = (@free/@size)*100

PRINT '% Free Space ' +
CONVERT(VARCHAR(15), @result)

質問 – 私の会社では、varbinary 列と image 列を使用して、形式の異なるファイルをデータベースに格納しています。SQL Server では、このように形式の異なるファイルを検索する機能が導入されたと聞きましたが、その機能を使用できるように SQL Server を設定する方法を教えてください。
回答 – その機能は、フルテキスト インデックス サービスに組み込まれています。このサービスは、IFilter インターフェイスを使用する柔軟性を備えているので、組織が所有しているデータから有用な情報を抽出するフィルタを開発して読み込むことができます。この IFilter は、Microsoft® Office SharePoint® Server などの他の製品でも、クロールされたファイルに関する情報を収集する場合に使用できます。
IFilter は、そのファイル形式の作成者、またはサードパーティ ベンダのいずれかから提供されます。SQL Server には、FulltextService (FTS) がインストールされた段階で読み込まれる IFilter がいくつかあります。これには、HTML ファイルや DOCファイルに対応するフィルタなどがあります。ただし、必要に応じて IFilter を追加することができます。たとえば、Adobe PDF 用のフィルタは Adobe 社の Web サイトで提供されています。2007 Office system の拡張機能として、新しいフィルタ パックが 2007 年の終わりに公開されました。IFilter のバージョンを確認する必要があることに注意してください。たとえば、32 ビット システム用の IFilter は、64 ビット版の SQL Server では動作しません。
通常、クライアントでインストール パッケージを実行すると、IFilter は OS のエコシステムに登録されます。FTS で IFilter を読み込めるようにするには、OS に BITS が登録された後に、いくつかの手順を実行する必要があります。クエリ実行ツールを起動して、次のコマンドを実行します。
  • sp_fulltext_service 'load_os_resources',1 (このステートメントによって、FTS が登録された BITS を読み込んで、ワードブレーカやステマなどのコンポーネントを含む処理を行います)。
  • sp_fulltext_service 'verify_signature',0 (標準に従ってフィルタには署名をしていないベンダが多いので、このステートメントによって、使用しているフィルタが署名されているかどうかを SQL Server がチェックするのをバイパスします)。
  • SQL Server のインスタンスと FTS のインスタンスを再起動します。
  • IFilter でクロールするコンテンツをバイナリ列として保持している列と、コンテンツのリダイレクト先をフィルタ選択するのに使用するフィルタを SQL Server が選択するのに使用する拡張列 (つまり、DOCX などの拡張子を含む列) にフルテキスト インデックスを作成します。
詳細については、go.microsoft.com/fwlink/?LinkId=7912971 を参照してください。
- Jens Suessmeyer

質問 – SQL Server にリモート接続できません。クライアント コンピュータまたはサーバー コンピュータのファイアウォールを構成する必要がありますか。
SQL Server 2005 へのリモート接続ができない理由は複数考えられますが、ファイアウォールの構成は最も一般的な問題の 1 つです。SQL Protocols blog (blogs.msdn.com/sql_protocols) では、SQL 接続に関するさまざまな情報が提供されているので、参照することをお勧めします。
SQL Server 2005 の既定のインストールでは、リモート接続は許可されていません。SQL Server を実行しているコンピュータで、[スタート] ボタンをクリックし、[Microsoft SQL Server 2005]、[構成ツール]、[SQL Server セキュリティ構成] の順にクリックします。表示されたウィンドウで [サービスと接続のセキュリティ構成] をクリックし、[リモート接続] および [TCP/IP および名前付きパイプを使用する] を選択します。この変更を反映するには、SQL Server コンピュータを再起動する必要があります。
既定では、SQL Server はポート 1433 を使用します。ポートが開いていることを確認するには、次の telnet コマンドを使用してください。コマンドの実行時には、<ipaddress> の部分は SQL Server を実行しているコンピュータの実際の IP アドレスに置き換えます。
telnet <ipaddress> 1433
接続に失敗した場合は、Windows® ファイアウォールを開き、[例外] タブで [ポートの追加] を選択し、TCP ポート 1433 を追加しますこの設定を行うと telnet コマンドは成功するようになります (Windows Vista® では telnet が既定でインストールされていないことに注意してください)。
- Rick Anderson
このコラムに貢献してくれた SQL Server の専門家に感謝します。
Justin Langford は、Microsoft Certified Partner として認定されているシステム インテグレータである英国の企業 Coeo Ltd. に勤務しています。Jens Suessmeyer はマイクロソフトのドイツ法人に所属するデータベース コンサルタントです。Rick Anderson はマイクロソフトの Developer User Education チームに所属しています。Saleem Hakani はマイクロソフトでシニア データベース エンジニアおよび SQL Server コミュニティ リードを務めています。


 ユーティリティ スポットライト: Web Capacity Analysis Tool
ユーティリティ スポットライト
Web Capacity Analysis Tool
Greg Steen

Web のログ と従来のトラフィック分析からは、今後予想されるトラフィックの種類の手掛かりを得ることはできますが、インフラストラクチャの処理可能範囲を判断するにはどうしたらよいでしょうか。それには、インフラストラクチャとアプリケーション スタックを限界の状態まで持って行くツールが必要です。そのようなツールの 1 つに、無料で利用できる Web Capacity Analysis Tool (WCAT) があります。このツールは、軽量な負荷生成ユーティリティで、スクリプト化した HTTP 要求を Web サーバー (または負荷分散サーバー ファーム) に対して再生しながら、後で分析するパフォーマンスの統計を収集します。最新バージョン (このコラムの執筆時点では 6.3.1) では、x86 と x64 の両方の Windows システムに対応したものが用意されており、IPv6 ネットワークをサポートしています (x86 用は iis.net/downloads/1466/ItemPermaLink.ashx、x64用は iis.net/downloads/1467/ItemPermaLink.ashx からダウンロードできます)。また、WCAT は、マルチスレッド対応で、1 つの場所で制御している複数の負荷テスト クライアントをサポートするので、何千もの同時接続ユーザーのシミュレーションを行うことができます。
このユーティリティでは、古いコンピュータをテスト クライアントとして使用して、各テスト クライアントで複数の仮想クライアントを作成することができます (作成できる仮想クライアントの最大数は、テスト クライアント コンピュータに搭載されているネットワーク アダプタや他のハードウェアの構成によって異なります)。HTTP 1.0 要求と HTTP 1.1 要求のどちらを使用するのか、SSL を使用するかしないのかを選択できます。テスト シナリオで必要があれば、スクリプト化した基本認証または NTLM 認証を使用して、サイトの制限を設けている部分へのアクセスを行うことも可能です (サイトで Cookie、フォーム、またはセッション ベースの認証を使用している場合は、適切な GET 要求または POST 要求を作成して、テスト ユーザーを認証できます)。WCAT では、サイトで設定している Cookie を管理するので、プロファイルとセッション情報が維持されます。
WCAT can help you test the limits of your Web site infrastructure
WCAT can help you test the limits of your Web site infrastructure
WCAT には、優れたユーザー ガイドが用意されています。このガイドを読むだけで、サイトのトラフィック監査履歴のユーザー トラフィック データに基づいてテスト クライアント スクリプトを生成する Microsoft® .NET Framework コンソール アプリケーションを簡単に作成して、展開前に新しいコードベースで実際のトラフィックのシミュレーションを行うことができるのです。C 言語に対応できるプログラマがいる場合は、シナリオ ファイルで呼び出して、環境に応じて調整できるカスタム関数と応答ハンドラを作成できます。
WCAT を使用するには 2 つのファイルを構成する必要があります。1 つ目のファイルは、クライアントの数、クライアントごとの仮想クライアントの数、追跡するパフォーマンス カウンタ、テストに使用する Web サーバーなど、一般的なテストの設定を含む制御ファイルです。2 つ目のファイルは、テスト シナリオ、既定の要求パラメータ、およびカスタム関数やライブラリへの参照を含むシナリオ ファイルです。
WCAT では、テスト結果が XML ファイルに記録されます。この XML ファイルには、同梱の XSL スタイル シートを適用して、Internet Explorer® で開いたときに適切な表形式で表示することができます。レポートには、実行されたトランザクションの数、発生したコンテキスト スイッチの回数、(すべての CPU の) CPU 使用率の割合、発生したエラーの総数が含まれます。また、設定ファイルで構成したパフォーマンス カウンタの結果が一覧表示されたセクション (スクリーンショット参照)、応答時間の分析、トランザクションごとの統計レポート、クライアントごとの分析結果セクション、およびテスト セットアップの構成に関する情報が提示されます。さらには、テストに使用したリモート Web サーバーのハードウェア構成と、インストールされているすべての更新プログラムの一覧も提示されます。これは、特定の修正プログラムがサイトのパフォーマンスに影響を与えているかどうかを判断および追跡するのに適した方法です。
全体的に見て、Web サイトのインフラストラクチャを管理している場合、WCAT ユーティリティを使用すると、次の大きな製品のリリースまでに、負荷がかかったときのプラットフォームのパフォーマンスを把握するのに役立ちます。

Greg Steen は技術プロフェッショナルであり、企業家でもあります。また、新製品のファンとも言えます。より簡単な操作、品質保証、および開発に役立つ IT プロフェッショナルのための新しいツールを日夜追い求めています。


 The Cable Guy: NAP 強制のトラブルシューティングを行う
The Cable Guy
NAP 強制のトラブルシューティングを行う
Joseph Davies

Windows Vista、Windows Server 2008、および Windows XP SP3 に組み込まれている新しいネットワーク アクセス保護 (NAP) プラットフォームを使用すると、コンピュータの正常性要件への準拠を強制することができるので、プライベート イントラネットの保護に役立ちます。NAP の主要な構成要素は、NAP クライアント、NAP 強制ポイント、および NAP 正常性ポリシー サーバーです。
NAP クライアントは、システム正常性の評価に必要な正常性状態情報を提供できるコンピュータです。NAP 強制ポイントは、NAP を使用するか NAP と併用されるコンピュータまたはネットワーク アクセス デバイスであり、NAP クライアントの正常性状態の評価を要求し、制限付きのネットワーク アクセスや通信を提供します。NAP 正常性ポリシー サーバーは、Windows Server® 2008 とネットワーク ポリシー サーバー (NPS) サービスを実行しているコンピュータであり、正常性要件ポリシーを格納し、NAP クライアントの正常性評価を実行します。NAP 正常性ポリシー サーバーと NAP 強制ポイントは、リモート認証ダイヤルイン ユーザー サービス (RADIUS) サーバー メッセージとプロキシ メッセージを使用して、システム正常性情報と制限付きアクセスに関する指示を交換します。
このコラムでは、正常性要件ポリシーの構成要素について説明した後、NPS サービスが NAP 評価の着信要求を処理するしくみと、NAP 強制に関する最も一般的な問題のトラブルシューティング方法について説明します。

正常性要件ポリシー
NAP 正常性評価のしくみ
NAP 正常性ポリシー サーバー上の NPS サービスは、次のプロセスに従って正常性評価を実行します。
  1. NPS サービスが、着信要求メッセージを構成済みの接続要求ポリシーと比較します。NAP の場合、この着信要求メッセージは、NPS サービスが認証と承認をローカルで実行することを指定した接続要求ポリシーと照合されます。
    2. 接続要求ポリシーによって接続要件が課される場合もあります。たとえば、802.1X 強制と VPN 強制では、PEAP (Protected Extensible Authentication Protocol) ベースの認証方法を使用する必要があります。接続元のクライアントが PEAP を使用していない場合、接続要求は拒否されます。
  2. NPS サービスが要求メッセージに含まれている正常性情報を評価します。この情報は、正常性状態情報を含むシステム正常性ステートメント (SSoH) で構成されています。NPS サービスは、インストールされているシステム正常性検証ツール (SHV) に正常性状態情報を渡し、SHV が NPS サービスに正常性評価情報を返します。
  3. NPS サービスが、要求メッセージと SHV から取得した正常性評価情報を、一連の適切なネットワーク ポリシーと比較します。正常性評価情報は、NAP ベースのネットワーク ポリシーに含まれている正常性ポリシー条件と比較されます。正常性ポリシー条件は、正常性要件に準拠しているかどうかを判断するための条件です。NPS サービスは、最初に照合されたネットワーク ポリシーを要求メッセージに適用します。
  4. 照合された NAP ベースのネットワーク ポリシー、およびそれに関連付けられた NAP 設定に基づいて、NPS サービスがシステム正常性ステートメントの応答 (SSoHR) を作成します。この応答には SHV から取得した正常性評価情報が含まれています。また、この応答は、NAP クライアントに無制限のアクセスと制限付きアクセスのどちらが許可されるか、および NAP クライアントが自動的に正常性状態の修復を試みる必要があるかどうかを示しています。
  5. NPS サービスが RADIUS 応答メッセージと SSoHR を NAP 強制ポイントに送信します。クライアントが制限付きアクセスを許可された場合、この応答メッセージには、NAP クライアントのアクセスがどのように制限されるかを指定する指示が含まれることもあります。
  6. NAP 強制ポイントが SSoHR を NAP クライアントに送信します。

正常性要件ポリシーは、NAP の強制方法で使用する 1 つの接続要求ポリシー、1 つまたは複数のネットワーク ポリシー、1 つまたは複数の正常性ポリシー、および NAP 設定を組み合わせたものです。正常性要件ポリシーを作成するには、ネットワーク ポリシー サーバー スナップインで、[NAP を構成する] をクリックして表示されるウィザードを使用します (評価処理の詳細については、補足記事「NAP 正常性評価のしくみ」を参照してください)。
接続要求ポリシー このポリシーは、順序付けられた一連の規則です。NPS サービスは、このポリシーを使用して、着信接続要求をローカルで処理する必要があるか、または別の RADIUS サーバーに転送する必要があるかを判断できます。NAP 正常性ポリシー サーバーは、接続要求をローカルで処理します。
Windows® ベースの NAP 強制ポイントからの着信 RADIUS 要求には、動的ホスト構成プロトコル (DHCP) サーバーや仮想プライベート ネットワーク (VPN) サーバーなど、NAP 強制ポイントの種類を指定するソース タグが含まれている場合があります。
着信要求メッセージにソース タグが含まれている場合、NAP 正常性ポリシー サーバー上の NPS サービスは、ソースが一致する接続要求ポリシーとその着信要求を照合しようとします (他の接続要求ポリシーはすべて無視されます)。着信要求メッセージにソース タグが含まれていない場合、この NPS サービスは、要求をソースが指定されていない接続要求ポリシーと照合しようとします (ソースが指定されている他の接続要求ポリシーは、すべて無視されます)。
たとえば、NAP 対応 DHCP サーバーからの着信要求には、DHCP のソース タグが指定されています。NPS サービスは、DHCP サーバーから発行された要求を、ソースが DHCP である接続要求ポリシーと照合しようとします。802.1X 対応スイッチおよびワイヤレス アクセス ポイントからの着信要求には、ソース タグが指定されていません。NPS サービスは、これらの要求を、ソースが指定されていない接続要求ポリシーと照合しようとします。
ローカルまたはリモート処理の評価に使用される接続要求ポリシーは、着信要求に適用される順序付けられたポリシーのサブセットの中で、最初に照合される接続要求ポリシーです。要求がどの接続要求ポリシーとも一致しなかった場合、その要求は拒否されます。
ネットワーク ポリシー このポリシーは順序付けられた一連の規則であり、着信要求メッセージに対応する接続が承認される状況と拒否される状況を指定します。規則ごとに、アクセスを許可または拒否するアクセス許可、一連の条件、一連の制約、およびネットワーク ポリシー設定が存在します。接続が承認された場合、ネットワーク ポリシーの制約と設定を使用して、接続に関する一連の制限を指定できます。NAP の場合は、ネットワーク ポリシーを使用して、正常性要件と強制動作の設定を確認する正常性ポリシー条件を指定できます。
接続要求ポリシーと同様、ネットワーク ポリシーもソース タグを使用して、着信要求と照合するネットワーク ポリシーを判断します。着信要求メッセージにソース タグが含まれている場合、NPS サービスは、ソースが一致するネットワーク ポリシーと着信要求を照合しようとします (他のネットワーク ポリシーはすべて無視されます)。着信要求メッセージにソース タグが含まれていない場合、NPS サービスは、ソースが指定されていないネットワーク ポリシーと着信要求を照合しようとします (ソースが指定されている他のネットワーク ポリシーは、すべて無視されます)。
試行された接続に適用される、順序付けられたポリシーのサブセットの中で、最初に照合されるネットワーク ポリシーは、承認や正常性評価に使用されるネットワーク ポリシーです。試行された接続がどのネットワーク ポリシーとも一致しなかった場合、要求は拒否されます。
正常性ポリシー このポリシーを使用すると、インストールされている SHV (正常性評価に使用されます) に基づいた正常性要件を指定できます。また、NAP クライアントがどの SHV チェックに合格する必要があるかも指定できます。たとえば、NAP クライアントが要件に準拠していることを示す正常性ポリシーでは、クライアントがすべての正常性チェックに合格する必要があることを指定できます。NAP クライアントが要件に準拠していないことを示す正常性ポリシーでは、クライアントが少なくとも 1 つの正常性チェックまたはすべての正常性チェックに不合格になる必要があることを指定できます。
ネットワーク アクセス保護の設定 この設定は、NAP 正常性ポリシー サーバーにインストールされている SHV の正常性要件とエラー条件の構成、および修復サーバー グループの構成から成ります。修復サーバー グループでは、DHCP 強制と VPN 強制でネットワーク アクセスが制限された、要件に準拠していない NAP クライアントがアクセスできる一連のサーバーが指定されます。

NAP 強制に関する問題を詳しく調べる
どのような問題のトラブルシューティングを行う場合でも、論理的な手法を使用すると役立ちます。トラブルシューティングの担当者がよく質問することをいくつか挙げると、「何が機能しているか」、「何が機能していないか」、「機能しているものと機能していないものはどのように関連しているか」、「機能していないものは今までに機能していたことがあるか」、「機能していたことがある場合、最後に機能していたときから何が変わったか」などがあります。
当然のことながら、NAP 強制に関する問題に対処する場合、これらの質問の範囲はさらに限定されます。たとえば、「その NAP の強制方法を展開する前から接続は機能していたか」、「IPsec 強制を展開する前は、インターネット プロトコル セキュリティ (IPsec) サーバーまたはドメインの分離は機能していたか」、「802.1X 強制を展開する前は 802.1X 認証は機能していたか」、「VPN 強制を展開する前は VPN リモート アクセスは機能していたか」、「DHCP 強制を展開する前は DHCP は機能していたか」といった質問になります。
さらには、「その NAP の強制方法は以前は機能していたか」、「機能していた場合、NAP クライアント、NAP 強制ポイント、または NAP 正常性ポリシー サーバーで何が変わったか」などの質問も考えられます。これらの質問に対する回答をヒントに、どこからトラブルシューティングを始めればよいかを特定できることがあり、場合によっては、問題の原因となっているコンポーネント、層、または構成に関する問題を特定できることもあります。
NAP 強制に関する問題の一般的なトラブルシューティングでは、その問題の範囲を特定する必要があります。まずは、実際に NAP 強制が問題となっているかどうかを突き止めます。IPsec 強制の場合は、NAP クライアントに適用されている一連の IPsec ポリシーが、IPsec ピア間のネゴシエーションとデータ保護に適しているかどうかを確認します。DHCP 強制の場合は、NAP クライアントが DHCP メッセージを DHCP サーバーと交換できるかどうかを確認します。802.1X 強制と VPN 強制の場合は、NAP クライアントの認証を正常に実行できるかどうかを確認します。たとえば、VPN クライアントで VPN 接続の認証を実行できない場合は、VPN クライアントの認証設定と資格情報を確認します。
NAP 強制が問題となっていることを確認できたら、次は問題の程度を確認します。つまり、適用された NAP の強制方法にかかわらず、すべての NAP クライアントが影響を受けるのか、特定の強制方法が適用されたすべての NAP クライアントが影響を受けるのか、特定の強制方法や特定の NAP 強制ポイントが適用されたすべての NAP クライアントが影響を受けるのか、特定のグループに属するすべての NAP クライアントが影響を受けるのか、特定の NAP クライアントのみが影響を受けるのか、ということを確認します。
たとえば、適用された NAP の強制方法にかかわらず、すべての NAP クライアントで問題が発生している場合は、NAP 正常性ポリシー サーバーの構成に問題がある可能性があります。特定の強制方法が適用されたすべての NAP クライアントで問題が発生している場合は、NAP クライアントに適用されるグループ ポリシー設定の構成に問題がある可能性があります。また、NAP 正常性ポリシー サーバーで構成されている、特定の NAP の強制方法に適用される正常性要件ポリシーに問題がある可能性もあります。NAP 強制に関する問題が特定の NAP クライアントのみで発生している場合は、その NAP クライアントの NAP 強制に関する構成に問題がある可能性があります。

NAP 強制に関する一般的な問題
NAP の関連情報
  • ネットワーク アクセス保護の概要
  • ネットワーク アクセス保護プラットフォームのアーキテクチャ
  • Windows Server 2008 のネットワーク アクセス保護ポリシー
  • NPS のネットワーク アクセス保護

無制限のアクセス 無制限のアクセスが許可された NAP クライアントは、NAP 正常性ポリシー サーバーによって、要件に準拠していると評価された可能性があります。これは、まさに期待どおりの結果です。ただし、無制限のアクセスは、NAP クライアントが SSoHR を受け取らなかった場合でも許可されます。通常、この状況は、NAP クライアントの正常性評価が実行されなかった場合に発生します。NAP 正常性評価が実行されなかった場合、SSoHR は NAP クライアントに返されないので、NAP クライアントに無制限のアクセスが許可されます。
たとえば、DHCP 強制用に構成された NAP クライアントは、DHCP サーバーに SSoHR を送信します。Windows Server 2008 を実行している DHCP サーバーが NAP 用に構成されていない場合、このサーバーは NAP 正常性ポリシー サーバーに正常性評価の要求メッセージを送信しません。また、Windows Server 2008 を実行しており、NAP 用に構成されている DHCP サーバーが、NAP 正常性ポリシー サーバーにアクセスできない場合、DHCP サーバーは既定で無制限のアクセス用のアドレス構成を割り当てます。
NAP 正常性評価を要求しないネットワーク ポリシーと着信要求が照合されたために、NAP 正常性ポリシー サーバーで正常性評価が実行されない場合も、無制限のアクセスが許可されることがあります。NAP クライアントの要求と照合されたネットワーク ポリシーを特定する方法については、このコラムの「順を追って NAP 強制のトラブルシューティングを行う」を参照してください。
制限付きアクセス 制限付きアクセスが許可された NAP クライアントは、NAP 正常性ポリシー サーバーによって、要件に準拠していないと評価されています。制限付きアクセスが許可された NAP クライアントに、無制限のアクセスを許可する必要がある場合は、その NAP クライアントの正常性状態を、NAP クライアントの要求と照合されたネットワーク ポリシーに対応する正常性ポリシー設定に対して検証します。
自動修復が実行されない NAP クライアントが適切に構成されていれば、そのクライアントの正常性状態を自動的に修復できます。NAP クライアントの自動修復を実行できない場合は、その NAP クライアントの要求と照合されるネットワーク ポリシーの NAP 強制設定で、[クライアント コンピュータの自動修復を有効にする] チェック ボックスがオンになっていることを確認します。
自動修復に影響を与える可能性があるもう 1 つの問題は、制限付きアクセスが許可されている NAP クライアントが、更新プログラムをダウンロードするために修復サーバーにアクセスできないという問題です。IPsec 強制を適用している場合は、修復サーバーに適切な IPsec ポリシーが適用されていることを確認します。802.1X 強制を適用している場合は、照合されるネットワーク ポリシーで、アクセス制御リスト (ACL) または仮想ローカル エリア ネットワーク識別子 (VLAN ID) の割り当てを行う設定、およびスイッチやワイヤレス アクセス ポイント (AP) の ACL または VLAN の構成を確認します。VPN 強制または DHCP 強制を適用している場合は、照合されるネットワーク ポリシーで、修復サーバー グループ用の設定を確認し、すべての修復サーバーをこのグループのメンバとして構成します。DHCP 強制を適用している場合は、NAP クライアントの DHCP スコープ オプションが適切に構成されていることを確認します (NAP ユーザー クラスのデフォルト ゲートウェイ オプションの値など)。
NAP 対応ではないと評価される 使用している NAP の強制方法にかかわらず、NAP クライアントで、対応する強制クライアントが有効になっていることを確認します。802.1X 強制または VPN 強制を適用している場合は、PEAP 認証に関するシステム正常性チェックが接続要求ポリシーと NAP クライアントの両方で有効になっている ([保護された EAP のプロパティ] ダイアログ ボックスの [検疫のチェックを有効にする] チェック ボックスがオンになっている) ことを確認します。
アクセスを制限されていない NAP クライアントがイントラネットにアクセスできない IPsec 強制を適用している場合は、要件に準拠している NAP クライアント用の IPsec ポリシーと、イントラネット コンピュータの IPsec ポリシーとの間で、ネゴシエーションと保護の設定が一致していることを確認します。802.1X 強制を適用している場合は、要件に準拠している NAP クライアント用のネットワーク ポリシーで、制限付きネットワーク用ではなくイントラネット用の ACL や VLAN ID が指定されていることを確認します。スイッチやワイヤレス AP で、イントラネット用の ACL や VLAN ID が正しく構成されていることを確認してください。VPN 強制を適用している場合は、要件に準拠している NAP クライアント用のネットワーク ポリシーで、VPN クライアントのトラフィックを制限する IP パケット フィルタが構成されていないことを確認します。

順を追って NAP 強制のトラブルシューティングを行う
ここでは、特定の NAP クライアントで発生した NAP 強制に関する問題のトラブルシューティングを進めていく方法を 1 つ紹介します。まず NAP クライアントの構成を確認し、NAP クライアントのイベント ログを確認します。次に、NAP 正常性ポリシー サーバーで、NAP クライアントの要求が NPS サービスによってどのように処理されたかを確認します。
手順 1: NAP クライアントの構成を確認する NAP クライアントの構成は、Windows サービス、強制クライアント、および NAP 強制に固有の設定から成ります。NAP クライアントの状態と構成に関する情報を表示するには、netsh nap client show state コマンドと netsh nap client show configuration コマンドを使用します。
NAP クライアントの設定がグループ ポリシーによって提供されている場合、NAP クライアントのすべての設定はグループ ポリシーによって指定され、ローカルでの NAP クライアントの設定はすべて無視されることに注意してください。その場合は、netsh nap client show grouppolicy コマンドを使用してグループ ポリシー ベースの NAP クライアントの構成を表示し、グループ ポリシーを通じてそれらの構成を変更します。
Windows Vista® を実行しているコンピュータに IPsec 強制を適用している場合は、net start コマンドを使用して、ネットワーク アクセス保護エージェント サービス、IKE および AuthIP IPsec のキー モジュール サービス、IPsec ポリシー エージェント サービスが開始されていることを確認します。また、netsh nap client show configuration コマンドを使用して、IPSec 証明書利用者強制クライアントが有効になっていることを確認します。必要に応じて、NAP クライアントの構成スナップインを使用して IPSec 証明書利用者強制クライアントを有効にするか、netsh nap client set enforcement 79619 enabled コマンドを使用します。netsh nap client set enforcement コマンドは、システム特権を使用してコマンド プロンプトから実行する必要があります。
Windows Vista を実行しているコンピュータに 802.1X 強制を適用している場合は、net start コマンドを使用して、拡張認証プロトコル サービス、ネットワーク アクセス保護エージェント サービス、ワイヤード自動構成サービス (ワイヤード接続で 802.1X 強制を使用している場合)、および WLAN 自動構成サービス (ワイヤレス接続で 802.1X 強制を使用している場合) が開始されていることを確認します。
また、netsh nap client show configuration コマンドを再び使用して、EAP 検疫強制クライアントが有効になっていることを確認します。必要に応じて、NAP クライアントの構成スナップインを使用して EAP 検疫強制クライアントを有効にするか、netsh nap client set enforcement 79623 enabled コマンドを使用します。ワイヤード接続またはワイヤレス接続に使用される、保護された EAP 認証のプロパティで、[検疫のチェックを有効にする] チェック ボックスがオンになっていることを確認します。
Windows Vista を実行しているコンピュータで VPN 強制を使用している場合、net start コマンドを使用して、拡張認証プロトコル サービス、ネットワーク アクセス保護エージェント サービス、およびリモート アクセス接続マネージャ サービスが開始されていることを確認します。
また、netsh nap client show configuration コマンドを使用し、その表示内容から、リモート アクセス検疫強制クライアントが有効になっていることを確認します。必要に応じて、NAP クライアントの構成スナップインを使用してリモート アクセス検疫強制クライアントを有効にするか、netsh nap client set enforcement 79618 enabled コマンドを使用します。また、VPN 接続に使用される、保護された EAP 認証のプロパティで、[検疫のチェックを有効にする] チェック ボックスがオンになっていることを確認します。
Windows Vista を実行しているコンピュータに DHCP 強制を適用している場合、net start コマンドを使用して、ネットワーク アクセス保護エージェント サービスと DHCP クライアント サービスが開始されていることを確認します。必要に応じて、サービス スナップインまたは Sc.exe ツールを使用してこれらのサービスを開始した後、これらのサービスを自動的に開始するように構成します。
netsh nap client show configuration コマンドを使用し、その表示内容から、DHCP 検疫強制クライアントが有効になっていることを確認します。必要に応じて、NAP クライアントの構成スナップインを使用して DHCP 検疫強制クライアントを有効にするか、netsh nap client set enforcement 79617 enabled コマンドを使用します。
手順 2: NAP クライアントのイベント ログを確認する イベント ビューア スナップインを使用して、ネットワーク アクセス保護エージェント サービスによってイベント ログに記録されたイベントを確認します。Windows Vista を実行しているコンピュータでは、イベント ビューア スナップインを使用して、"アプリケーションとサービス ログ\Microsoft\Windows\ Network Access Protection \Operational" のイベントを確認します。Windows XP SP3 を実行しているコンピュータでは、イベント ビューア スナップインを使用して、システム イベント ログの NAP イベントを確認します。
NAP クライアントのイベントでは、NAP クライアントの正常性評価に割り当てられた関連付け ID を確認します。関連付け ID または NAP クライアントのコンピュータ名を使用すると、NAP 正常性ポリシー サーバーで、対応する正常性評価イベントを検索できます。図 1 は、要件に準拠していない NAP クライアントのイベント ログに記録されたイベントの例を示しています。この情報には関連付け ID が含まれています。
Figure 1 Windows Vista NAP クライアントのイベント ログに記録されたイベントの例
Figure 1 Windows Vista NAP クライアントのイベント ログに記録されたイベントの例
手順 3: NPS イベント ログを確認する NAP 正常性ポリシー サーバーのイベント ビューア スナップインで、"Windows ログ\セキュリティ" に移動し、NPS サービスによって記録されたイベントを確認します。NPS イベントを確認するには、イベント ビューアで [カスタム ビュー]、[サーバーの役割] の順に展開し、[ネットワーク ポリシーとアクセス サービス] をクリックします。イベントに関連するオンライン ヘルプ トピックを確認するには、イベントの [全般] タブにある [イベント ログのヘルプ] をクリックします。
一般的な NAP 正常性評価イベントのイベント ID は、6278 (無制限のアクセスの場合) または 6276 (制限付きアクセスの場合) です。NAP 正常性ポリシー サーバーで、NAP クライアントのコンピュータ名 (イベントの説明の中で、クライアント コンピュータに関するセクションに含まれている、アカウント名を示すフィールド) または関連付け ID (イベントの説明の中で、検疫情報に関するセクションに含まれている、セッション識別子を示すフィールド) を基に、対応するイベントを検索します。
NPS イベント ログに記録されたイベント 6278 とイベント 6276 には、照合された接続要求ポリシーの名前 (イベントの説明の中で、認証に関するセクションに含まれている、プロキシ ポリシー名を示すフィールド)、照合されたネットワーク ポリシー (イベントの説明の中で、認証に関するセクションに含まれている、ネットワーク ポリシー名を示すフィールド) など、NAP 正常性評価に関する情報が含まれています。図 2 は、イベント ID 6276 の [詳細] タブの例を示しています。この情報には、プロキシ ポリシー名、ネットワーク ポリシー名、および関連付け ID (QuarantineSessionID という箇所) が含まれています。これは、図 1 で示した Windows Vista NAP クライアントのイベントに対応する NAP 正常性ポリシー イベントです。
Figure 2 NAP 正常性ポリシー サーバーのイベント ログに記録されたイベントの例
Figure 2 NAP 正常性ポリシー サーバーのイベント ログに記録されたイベントの例
NAP クライアントのイベントに対応するイベントが存在しない場合は、ネットワーク ポリシー サーバー サービスが開始されていることを確認します。また、NAP 強制ポイントが NAP 用に正しく構成されていること、およびこの強制ポイントが NAP 正常性ポリシー サーバーを RADIUS サーバーとして使用するように正しく構成されていることを確認します。また、NAP 強制ポイントと NAP 正常性ポリシー サーバーとの間で RADIUS メッセージを送受信できることを確認します。
この 3 つの手順を実行することによって、NAP 強制が期待どおりに機能しない理由を突き止めることができるでしょう。NAP の詳細については、補足記事「NAP の関連情報」を参照してください。

Joseph Davies は、マイクロソフトのテクニカル ライターとして Windows ネットワークのトピックに関する講義および執筆を 1992 年から行っています。Microsoft Press から 8 冊の書籍を上梓しており、月刊の TechNet Cable Guy コラムの執筆者でもあります。


 Windows PowerShell: 署名をお願いします
Windows PowerShell
署名をお願いします
Don Jones

2008 年 1 月号の Windows PowerShell コラムでは、Windows PowerShell スクリプトにデジタル署名することの重要性を強調しました。また、AllSigned 以外の実行ポリシーを使用することによって、環境内のセキュリティの脆弱性が大幅に高まる可能性のあるいくつかのシナリオについて説明しました。
このときは、実際にスクリプトに署名する方法については、詳しい説明を省略しました。このコラムの内容を確認するには、technetmagazine.com/issues/2008/01/PowerShell を参照してください。では、今月のコラムのテーマはどうしましょうか。

単なる署名ではありません
署名という語は、これから説明するテーマを表す正しい専門用語ですが、その語自体は、実際の処理を適切に表していません。スクリプトに署名するということは、契約を結ぶときやクレジット カードを使用するときのように、それを承認または許可するということではありません。デジタル セキュリティにおける署名とは、署名者の ID を付加することによって、あるものの状態が変更されていないことを保証する処理です。この処理は、すべて暗号化に基づいて行われます。暗号化では、(少なくともこの場合) 2 つの暗号化キーが使用されます。
これらのキーは、互いに異なることから、"非対称キー" と呼ばれます。非対称キーは、暗号化を行った人物のみがアクセスできる秘密キーと、だれでもアクセスできる公開キーで構成されます。少し説明を簡略化しますが、基本的に、秘密キーで暗号化されたデータは、対応する公開キーを使用しなければ暗号化を解除できません。
ここから、そのしくみについて説明します。繰り返しますが、ここでは説明を円滑に進めるために、内容を少し簡略化しています。まず、署名する Windows PowerShell® スクリプトと、スクリプトへの署名に使用する秘密キーが含まれた証明書を用意します。Windows PowerShell 自体にも、指定されたスクリプトと証明書を使用して実際に署名を実行するコマンドレット (この後すぐ説明します) が含まれています。このコマンドレットを実行すると、Windows PowerShell は秘密キーを使用して、指定されたスクリプトを暗号化します。暗号化されたコピーは、スクリプトの最後に一連のコメントとして追加され、よく意味のわからないテキストとして表示されます (図 1 参照)。署名者の ID もそれらのコメント内にエンコードされますが、暗号化はされません。ID 自体は、暗号化機能を使用しなくても確認できます。
Figure 1 スクリプトの最後に格納された署名ブロック
Figure 1 スクリプトの最後に格納された署名ブロック
後から署名を調べるときに、Windows PowerShell は ID をデコードし、それを使用して公開キーを取得します。署名の残りの暗号化を解除できるのは署名者の公開キーのみであるため、Windows PowerShell は、署名の暗号化を解除できた場合、公開キーの作成者が署名を実行したことを認識します。他のユーザーが署名を実行した場合、この署名者の公開キーで署名の暗号化を解除することはできません。署名の暗号化が解除されたら、Windows PowerShell は、スクリプトと、署名に暗号化されたそのスクリプトのコピーを比較します。それらが一致した場合、署名は変更されていないものと見なされます。2 つのスクリプトが異なる場合、署名は破損しており、無効であると見なされます。
このようにしてクリア テキストのスクリプトを署名で保護し、気付かないうちに変更されることがないようにします。スクリプト自体は簡単に変更できますが、変更されたスクリプトと一致するように署名を変更するには、必ず署名者の秘密キーを使用する必要があります。そして、その秘密キーを所持するのは署名者のみです。
確かにここでは、前提となる技術的な処理の説明を簡略化しています。実際には、署名者の公開キーのコピー、キーを発行した証明機関 (CA) に関する情報など、より多くの情報が署名に含まれます。しかし、ここでは署名処理における重要な部分の説明は省略していません。また、署名を使用することによって実際に不正な変更からスクリプトを保護できるということも明確にしています。
セキュリティを確保するには、秘密キーを厳重に保護することが重要です。秘密キーは、他のユーザーの手に渡らないようにする必要があります。Windows にキーをインストールするときは、気付かないうちに悪意のある処理によって使用されないよう、直ちにそのキーをパスワードで保護する必要があります。スマート カードを使用すると、スマート カードに秘密キーを格納できるので、セキュリティを強化できます。スマート カードでは、秘密キーがカードから切り離されることはありません。暗号化されるデータは、スマート カード リーダー ハードウェアからカードに転送された後、カードの回路によって暗号化され、その結果がコンピュータに返されます。

証明書を取得する
今月のコマンドレット : Export-CSV
PowerShellCommunity.org のフォーラムでよく尋ねられるのは、Windows PowerShell で Microsoft Excel® へのエクスポートを実行できるかどうかということです。もちろんそれは可能です。Excel はネイティブで CSV ファイルを開き、編集および保存することができるので、Export-CSV コマンドレットを使用すると、Excel へのエクスポートを実行できます。たとえば、サービスの一覧をエクスポートする場合は、Get-Service | Export-CSV MyServices.csv を実行すれば、作業は完了です。また、Export-CSV を任意のパイプラインの末尾に追加し、そのパイプライン内のすべてのオブジェクトを指定した CSV ファイルにエクスポートすることもできます。既定では、Export-CSV は、ヘッダー行をファイルの先頭に追加し、その行を使用して、エクスポートされたオブジェクトの種類を指定します。Excel がファイルを開く操作を妨げないように、この行はコメントになっています。オブジェクトの種類に関する情報をエクスポートしない場合は、単純に -notype パラメータを Export-CSV に追加します。また、-force パラメータを追加して、同じ名前の既存の CSV ファイルを確認なしで上書きしたり (既定では確認メッセージが表示されます)、-noClobber パラメータを追加して、その名前のとおり、既存のファイルを上書きしないようにすることもできます。

スクリプトに署名するには、特定の種類の証明書 (クラス 3 の Authenticode コード署名証明書) が必要です。この証明書を入手する主な方法は 3 つあります。1 つ目は、組織内の公開キー基盤 (PKI) を使用する方法です (組織に実装されている場合)。適切に実装された PKI では、ルート CA が組織のすべてのコンピュータによって信頼されています。CA から発行された証明書を組織内で使用するには、この要件を満たしている必要があります。
Windows® 2000 以降、Windows Server® には独自の証明書サーバー ソフトウェアが付属しており、そのソフトウェアを使用して独自の PKI を作成できます。PKI を完全に実装するには、非常に多くの計画作業を行う必要がありますが、コード署名証明書を発行するためだけに PKI を使用する場合、すべての作業を行う必要はありません。単純にグループ ポリシーを使用して、CA のルート証明書をコンピュータにインストールすれば、すべてのコンピュータでその証明書が信頼されます。
2 つ目は、商用の CA を使用する方法です。商用の CA を使用する利点の 1 つは、いずれかの主要な CA を使用したときに、組織のコンピュータが既にその CA の証明書を信頼するように構成されている可能性が高いことです (Windows XP では既定で多くの証明書が信頼されていますが、Windows Vista® ではその数が大幅に減少していることに注意してください)。よく使用される商用の CA としては、VeriSign (verisign.com) が挙げられます。その他、CyberTrust (cybertrust.com) や Thawte (thawte.com) なども調べてみる価値はあります。
コード署名証明書を入手する 3 つ目の方法は、Makecert.exe などのツールを使用して独自の自己署名証明書を作成することです。このツールは Windows Platform SDK に付属しており、一部のエディションの Microsoft® Office でもインストールされます。これらの他にも、さまざまな方法でこのツールを入手できます。自己署名証明書の利点は、無償であること、およびインフラストラクチャを必要としないことです。一方、自己署名証明書の欠点は、自分のコンピュータでしか使用できないことです。しかし、(コード署名を使用したテストや一般的な実験を行う場合など) 自分のコンピュータのみでスクリプトを実行する必要がある場合は、Makecert.exe が役立ちます。このツールに関するドキュメントは、go.microsoft.com/fwlink/?LinkId=108538 で参照できます。このツールは、これまでに多くのバージョンが公開されているので、使用中のコンピュータで古いバージョンを実行している場合は、ドキュメントの説明どおりに動作しないことがあります。
Makecert.exe を入手したら、Windows PowerShell コマンド ラインで次のようなコードを実行して、自己署名証明書を作成できます (このコラムを読んでいるのであれば、cmd.exe ではなく Windows PowerShell を使用してください)。
makecert -n "CN=MyRoot" -a sha1 –eku
1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer
–ss Root -sr localMachine
続いて、次のコードを実行します。
makecert -pe -n "CN=MyCertificate" -ss MY
–a sh1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk
–c root.cer
Makecert.exe によって、キーを保護するためのパスワードが要求された後、証明書が作成されます。この証明書がインストールされたことを確認するには、Windows PowerShell で次のコードを実行します。
gci cert:\CurrentUser\My -codesigning
これにより、CERT: ドライブ (Windows 証明書ストア) に格納されているすべてのコード署名証明書が一覧表示されます。ちなみに、これらの情報はすべて Windows PowerShell でも確認できます。この情報を確認するには、Get-Help about_signing を実行し、数画面分スクロールしてください。

スクリプトに署名する
証明書とスクリプト (必要に応じてテスト用に簡単なものを作成してもかまいません) を用意したら、スクリプトに署名する準備は完了です。Windows PowerShell では、驚くほど簡単にスクリプトへの署名を実行できます。次のコードを入力するだけで、署名は完了します。
$cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature myscript.ps1 $cert
最初の部分では、最初にインストールされたコード署名証明書を取得しています (複数の証明書がインストールされており、別の証明書を使用する場合は、"0" を適切な値に変更します)。次の部分では、ファイルに署名しています (もちろん、ファイル名は必要に応じて変更してください)。以上で処理は完了です。しかし正直なところ、Set-AuthenticodeSignature というコマンドレット名は必要以上に長いと思います。そのため、Sign というエイリアスを作成しました。これで、次のコードを実行するだけで済みます。
Sign myscript.ps1 $cert
ここで、上記のスクリプトを開くと、最後に署名ブロックが挿入されているのを確認できます。実行ポリシーを AllSigned に設定してスクリプトを実行すると (Set-ExecutionPolicy AllSigned)、スクリプトは正しく動作します。次に、スクリプトを変更して保存します。ただし、今度は署名処理を実行しないようにします。署名が破損しているので、Windows PowerShell は、この変更後のスクリプトの実行を拒否します。

労力を費やす価値
ここで紹介したスクリプトの作成に費やす労力は、その価値に見合っているでしょうか。いくつかの管理タスクをスクリプト化することによって、500 ドルを費やして証明書を購入したり、まったく新しいインフラストラクチャ要素を実装したりする必要性をなくすということは、無理な要求でしょうか。私も管理者なので、管理者が抱える問題は理解しています。答えは簡単です。間違いなく、ありったけの労力を費やすだけの価値はあります。
実際、セキュリティには、ほぼ必ずある程度の煩わしさが伴います。ウイルス対策ソフトウェアは悩みの種になりますが、それなしでコンピュータを実行することはありません。また、ファイアウォール ソフトウェアは確かに面倒ですが、ご存知のとおり、ファイアウォールなしでコンピュータを実行するのは危険です。また、Windows Vista のユーザー アカウント制御 (UAC) も面倒ですが、これによってコンピュータの安全性が保たれます。そして、この強化されたセキュリティこそが、まさに私たちが実現しようとしていることではないでしょうか。
Windows PowerShell は強力なツールです。そして、他のあらゆるツールと同様、常に、悪意のあるユーザーによって、セキュリティの脆弱性を利用するための手段へとねじ曲げられる可能性があります。このため、そういった悪意のあるユーザーによる攻撃を阻止するための手段を講じることが重要です。
コードへの署名は最適な対策であり、それほど煩わしさもありません。たとえば、私は [Save] (上書き保存) をクリックするたびにスクリプトへの署名が自動的に実行されるグラフィカルなスクリプト エディタを使用しているので、ほとんど意識することなくコードに署名できます。
特別なエディタを使用しなくても、より透過的にコードに署名できます。たとえば、独自の Windows PowerShell プロファイルを作成し (ドキュメント フォルダの WindowsPowerShell という名前のフォルダに Microsoft.PowerShell_profile.ps1 ファイルを作成します)、次の関数を追加します。
function sign ($filename) {
  $cert = @(gci cert:\currentuser\my
-codesigning)[0]
Set-AuthenticodeSignature $filename $cert
}
あとは、次のコードを入力するだけでスクリプトに署名できます。
Sign c:\scripts\myscript.ps1
そうですね、このプロファイル スクリプトが初めて署名したスクリプトということになります。煩わしさをなくすには、いくつかの手順を実行して、スクリプトへの署名をできるだけ簡単な操作にする必要があります。
コード署名証明書を発行するというだけの目的であれば、1 台の PKI サーバーを展開する作業はそれほど大変ではありません (ただし、特にルート CA の保護や障害回復機能の提供など、PKI を他の目的で使用する場合は、PKI に関するより詳細な調査を行い、綿密な計画を立てる必要があります)。環境内でスクリプトを実行するのが自分のみである場合は、Makecert.exe を使用します。Get-Help about_signing によって表示されるヘルプ トピックには、Makecert.exe によって生成された証明書のセキュリティ保護に関する情報も含まれています。

Don Jones は、『Windows PowerShell: TFM』と『VBScript, WMI, and ADSI Unleashed』の著者です。連絡先については、PowerShellCommunity.org を参照してください。


 Hey, Scripting Guy!: 帰ってきたデータベース スクリプト
Hey, Scripting Guy!
帰ってきたデータベース スクリプト
The Microsoft Scripting Guys
この記事で使用しているコードのダウンロード: HeyScriptingGuy2008_04.exe (151KB)

ご存知のとおり、 もし Scripting Guys に欠点があるとすれば ("もし" ですよ、"もし")、それは、何かを行ったときの影響、または行わなかったときの影響を気にしすぎるということです。たいてい Scripting Guys が何かを行う場合は、自分たちの利益は考えず、他の人の利益を最優先にします。それが自分たちにどんな影響を与えるとしても。
たとえば、データベース スクリプトに関する記事を例に考えてみましょう。包み隠さず正直に言うと、データベース スクリプトに関する記事を執筆することは、Scripting Guys にとって大変な作業です。データベース スクリプトの作成が難しいというわけではありません、この作業は非常に簡単です。問題は、Scripting Guys がデータベースを扱う機会があまりないということです。このため、データベースに関する記事を執筆するときは、いつも少し立ち止まって、自分たちが何をしようとしているかを考えなくてはなりません。皆さんはずっと前からお気付きだと思いますが、Scripting Guy になるために、"考える" という行為はまったく必要ありません。
そもそも Scripting Guys のだれかが実際にそのようなことを考えていたら、Scripting Guys 自体が存在しなかったでしょう。
では、データベース スクリプトに関する記事の執筆がそこまで大変であるにもかかわらず、なぜ Scripting Guys は現在でもこの記事の執筆を続けているのでしょうか。答えは簡単です。それは、記事の執筆を止めたら世界中の皆さんがどうなってしまうかが心配だからです。かのアーサー コナン ドイル氏がシャーロック ホームズの命を絶つ (ホームズは「最後の事件」で崖から転落してその生涯を終えました) ことを決めた理由は、単にもうこの人物に関する話を執筆したくなかったからだそうです。しかしこの後、世界中から激しい抗議の声が上がりました。ある報告によると、ロンドンの人々は、彼の死を耳にしたとき、実際に帽子と腕に喪章を付けて街を歩いたそうです。「最後の事件」は 1893 年に Strand Magazine で発表されましたが、この後 20,000 人の読者が定期購読を中止したといいます。
何ということでしょう。
Scripting Guys は、データベース スクリプトに関する記事の執筆を止めたときに、同じようなことが起こるのではないかと心配しているのです。皆さんを辛い気持ちにさせたり落ち込ませたりしたくはありませんし、20,000 人もの TechNet Magazine の読者が定期購読を中止することなど考えたくもありません。ですから、Scripting Guys はデータベース スクリプトに関する記事の執筆を続けていくことを、ここに宣言します。いつからですって。では今からにしましょう。

データベースにレコードを追加する
今月は、データベースの操作に関する気の利いたテクニックをいくつか紹介します。これらは、2007 年 9 月号 (technetmagazine.com/issues/2007/09/HeyScriptingGuy) で紹介したテクニックを改良したものです。Scripting Guys もまったく同じ記事を 2 回掲載するほど落ちぶれてはいません。
ばれないようであれば、そうしていたかもしれませんが。
まずは単純な方法でデータベースにレコードを追加してみましょう。C:\Scripts\Inventory.mdb というデータベースがあり、このデータベースに Computers というテーブルが含まれているとします。Computers テーブルには、次のフィールドが含まれています。
  • ComputerName
  • SerialNumber
  • UserName
  • Department
では、このデータベースに新しいコンピュータを追加するにはどうすればよいでしょうか。図 1 のコードをご覧ください。
Figure 1 Adding a record to the Computers table (Close Figure 1)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "INSERT INTO Computers (ComputerName, SerialNumber, UserName, Department)" &  _
    "VALUES ('atl-ws-07', '11234', 'Ken Myer', 'Finance')", _
        objConnection, adOpenStatic, adLockOptimistic
このスクリプトの最初の数行については、詳しい説明を省略します。これらの情報が必要な場合は、スクリプト センター ( microsoft.com/technet/scriptcenter) で提供されているリソースを参照してください。説明が必要なのは、定数 adOpenStatic と adLockOptimistic を使用して、レコードセットのカーソルの種類とレコードのロックを制御しているということだけでしょう (格好をつけているわけではなく、このコードが本当に単純であるということです)。ADODB.Connection オブジェクトと ADODB.Recordset オブジェクトのインスタンスを作成したら、次のコマンドを使用してデータベースを開きます。
objConnection.Open _
"Provider = Microsoft.Jet.OLEDB.4.0; " & _
"Data Source = C:\Scripts\Inventory.mdb"
ちなみに、上記のコマンドを実行すると、Microsoft® Access® 2003 データベースが開かれます。Access 2007 データベースを開くには、次のコマンドを使用します。
objConnection.Open _
"Provider = Microsoft.ACE.OLEDB.12.0; " & _
"Data Source = C:\Scripts\Inventory.accdb"
記事の内容から少し離れてしまいますが、これと似た次のコマンドを使用すると、SQL Server® データベースを開くことができます。
objConnection.Open _
"Provider=SQLOLEDB;" & _
"Data Source=atl-sql-01;" & _
"Trusted_Connection=Yes;" & _ "InitialCatalog=Inventory;" & _
"User ID=fabrikam\kenmyer;Password=34DE6t4G!;"
ここまでに紹介したのは、お決まりのコードです。すぐにわかると思いますが、データベース スクリプトの大半は、上記のようなコードから始まります。特に重要なのは、次のコードです。
objRecordSet.Open _
  "INSERT INTO Computers " & _
  "(ComputerName, SerialNumber, " & _
  "UserName, Department) " & _
    "VALUES ('atl-ws-07', 'A14B1234', " & _
      "'Ken Myer', 'Finance')", _
        objConnection, adOpenStatic, _
        adLockOptimistic
このコードでは、INSERT INTO クエリを使用して、Computers テーブルに新しいレコードを追加しています。テーブル名の後に、値を格納するすべてのフィールドの名前を、かっこ内にコンマで区切って記述していることに注意してください。
ここで、「"値を格納するすべてのフィールド" とはどういう意味だろう」という疑問が浮かぶかもしれません。良い質問です。では、この新しいコンピュータにまだ部署名が割り当てられていないとしましょう。このデータベースの Department フィールドには Null 値を指定できるので、単純に Department をリストから除外し、このフィールドに値を割り当てないことにします。つまり、次のようなクエリを記述します。
objRecordSet.Open _
  "INSERT INTO Computers " & _
  "(ComputerName, SerialNumber, " & _
  "UserName) " & _
    "VALUES ('atl-ws-07', 'A14B1234', " & _
      "'Ken Myer')", _
        objConnection, adOpenStatic, _
        adLockOptimistic
値の割り当てと言えば、フィールド名の後の文字列をご覧ください。VALUES キーワードの後に、各フィールドに割り当てる値が指定されています (これらもかっこで囲まれています)。フィールド名は、指定した順序どおりに配置されているわけではありません。たとえば、1 つ目に ComputerName を指定しても、それがデータベースの 1 つ目のフィールドではない場合があります。このことはフィールド名では特に問題ありませんが、値の場合は問題があります。値はフィールドとまったく同じ順序で指定する必要があります。つまり、1 つ目のフィールドに ComputerName を指定した場合、1 つ目の値にはコンピュータ名を指定する必要があります。これに従わなかった場合、問題が発生します (たとえば、ComputerName フィールドにユーザー名やシリアル番号が割り当てられることになります)。
ご覧のとおり、値の割り当てはそれほど複雑ではありませんが、データ型に応じて異なる形式で値を指定する必要があります。日付と文字列値は単一引用符で囲みますが、数値とブール値は単一引用符で囲まないようにします。
値自体に単一引用符が含まれている (O'Brien という名前など) 場合は、単一引用符を 2 つ続けて記述することによって、この文字を "エスケープ" する必要があります。
'O''Brien'
妙な感じがしますが、正しい処理です。

データベースからレコードを削除する
すばらしいスクリプトでしたね。1 つの SQL クエリを実行するだけでデータベースにレコードを追加できるのですから、これ以上のものはないでしょう。私たちの知る限りでは。
でも、1 つのクエリを使用してデータベースから複数のレコードを削除できるスクリプトがあれば、話は別です。
たとえば、人事部を廃部することにしたとします (冗談ではありません。Scripting Guys はいつもマイクロソフトの人事部に非常に悩まされています)。人事部のコンピュータを会社の資産データベースから削除するにはどうすればよいでしょうか。この操作を行うには、図 2 のようなスクリプトを使用します。
Figure 2 Deleting multiple records (Close Figure 2)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "DELETE * FROM Computers Where Department='Human Resources'", _
    objConnection, adOpenStatic, adLockOptimistic
ご覧のとおり、このスクリプトは先ほど新しいレコードを追加するときに使用したスクリプトとまったく同じコードで始まっています。つまり、定数を定義し、オブジェクトを作成した後、Inventory.mdb データベースに接続しています。その後、単純に DELETE クエリを使用して Computers テーブルからすべてのレコード (*) を削除します。少なくとも、Department フィールドの値が "Human Resources" になっているレコードはすべて削除します。
objRecordSet.Open _
  "DELETE * FROM Computers " & _
   "Where Department='Human Resources'", _
    objConnection, adOpenStatic, _
    adLockOptimistic
崖から転落するくらい簡単ですね。
悪気はありませんよ、シャーロック ホームズ。

データベース内のレコードを更新する
人事部の存在を跡形もなく消し去ることができたら、どんなにすばらしいことでしょう (マイクロソフト人事部の皆さんへ : 読者の皆さんと世間一般の人事部について面白おかしく説明しているだけで、マイクロソフトの人事部のことを言っているわけではありませんよ。楽しむつもりなどまったくありません)。そうは言っても、人事部のコンピュータを資産データベースからすべて削除することが最善ではない場合もあります。なぜでしょうか。それは、人事部の従業員がすべてのハードウェアを持ち逃げしない限り (実際にその可能性があるかのように聞こえますが、気にしないでください、冗談は言っていませんから)、それらのコンピュータは引き続き会社で使用されるからです。つまり、データベース内には存在している必要があるということです。そのことを踏まえて、データベースからすべてのレコードを削除するのではなく、単純にそれぞれのレコードを更新しましょう。コンピュータの部署名を "Human Resources" から "None" に変更します。つまり、図 3 のようなスクリプトを実行します。
Figure 3 Updating records (Close Figure 3)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Inventory.mdb"

objRecordSet.Open "UPDATE Computers Set Department = 'None' " & _
    "Where Department = 'Human Resources'", _
    objConnection, adOpenStatic, adLockOptimistic
先ほどと同じように、変更した部分は SQL クエリだけです。この場合は、UPDATE クエリを使用して Computers テーブル内のレコードを更新しています。また、UPDATE キーワードの他に次の 2 つのパラメータを追加して、どのようにレコードを更新するか、およびどのレコードを更新するかを指示する必要があります。
  • Set Department = 'None': この部分では、Department フィールドに新しい値を指定しています。また、Set Department = 'None', UserName = 'None' という構文を使用すれば、一度に複数のフィールドに値を指定できます。おわかりのとおり、この構文では Department フィールドと UserName フィールドに None という値を設定しています。
  • Where Department = 'Human Resources': これは、どのレコードを更新するかを指定するための標準的な Where 句です。この場合は、Department フィールドの値が "Human Resources" になっているすべてのレコードを指定しています。この Where 句を記述した理由は単純です。データベース内のすべてのレコードを変更するのではなく、以前人事部に所属していたレコード (コンピュータ) のみを削除する必要があるからです。
ここで、Update クエリを使用したすばらしいテクニックをご紹介しましょう。たとえば、全従業員の給料が 10% アップすることになったとします (Scripting Guys とアーサー コナン ドイル氏との間で少なくとも 1 つ共通していることは、どちらも架空の話を扱っているということです)。次のスクリプトでは、Employees というテーブルを開き、各従業員の Salary フィールドを変更しています。では Salary フィールドには何が設定されるのでしょうか。このフィールドには、従業員の現在の給料からの増加率である 1.1 を設定します。つまり、各従業員の給料を 10% アップするということです (こんな風にして簡単に給料がアップすればいいのですが)。このクエリを次に示します。
objRecordSet.Open _
  "Update Employees " & _
  "Set Salary = (Salary * 1.1)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
すばらしいですね。ご覧のとおり、Update クエリでは計算を実行できます。たとえば、すべての臨時社員の契約を 60 日間延長することになったとしましょう。このような場合は、次のクエリを使用すると便利です。
objRecordSet.Open _
  "Update TempEmployees " & _
  "Set ContractExpirationDate = " & _
  "(ContractExpirationDate + 60)", _
    objConnection, adOpenStatic, _
    adLockOptimistic

簡単にデータを取得する
便利なクエリという話が出たところで、最後にまとめとしてデータベースから簡単にデータを取得する方法をいくつかご紹介します。まずは、単純ですが非常に便利なスクリプトをご紹介します。資産データベースに Price というフィールドが含まれているとします。ある程度予想できると思いますが、このフィールドはコンピュータの価格を表しています。では、組織内で最も高額な 5 台のコンピュータを確認するにはどうすればよいでしょうか。図 4 のサンプル スクリプトをご覧ください。
Figure 4 Sorting the recordset (Close Figure 4)
Const adOpenStatic = 3
Const adLockOptimistic = 3

Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")

objConnection.Open _
    "Provider = Microsoft.Jet.OLEDB.4.0; " & _
        "Data Source = C:\Scripts\Test.mdb"

objRecordSet.Open "SELECT Top 5 * FROM Computers Order By Price", _
     objConnection, adOpenStatic, adLockOptimistic

objRecordSet.MoveFirst

Do Until objRecordset.EOF
    Wscript.Echo objRecordset.Fields.Item("ComputerName")
    objRecordset.MoveNext
Loop

objRecordSet.Close
objConnection.Close
ご覧のとおり、この SQL クエリでは 2 つの操作を行っています。Price を基準にレコードセットを並べ替え (Order By Price)、上位 5 台 (つまり価格のトップ 5) のコンピュータを取得 (SELECT Top 5) しています。上位 10 台のコンピュータを取得する場合は、次のクエリを使用します。
objRecordSet.Open _
  "SELECT Top 10 * FROM Computers " & _
  "Order By Price", _
    objConnection, adOpenStatic, _
    adLockOptimistic
注 : 今回、ループ処理によってレコードセット内のレコードを 1 つずつ処理して、各コンピュータの名前を表示するコードを追加しました。以前のスクリプトではデータを返して表示する必要がなかったので、このコードは使用しませんでした。
次のクエリを使用すると、価格が上位 10% のコンピュータを取得することができます。
objRecordSet.Open _
  "SELECT Top 10 PERCENT * " & _
  "FROM Computers Order By Price", _
    objConnection, adOpenStatic, _
    adLockOptimistic
では、最も低額なコンピュータを取得するにはどうすればよいでしょうか。同じ方法を使用すれば問題ありませんが、今回はレコードセットを降順 (最低額から最高額の順) に並べ替えます。つまり、次のように DESC を使用して、レコードセットを降順に並べ替えるよう指示します。
objRecordSet.Open _
  "SELECT Top 5 * FROM Computers " & _
  "Order By Price DESC", _
    objConnection, adOpenStatic, _
    adLockOptimistic
どうですか。便利なスクリプトですよね。
さらに 2 つ面白いものをご紹介します。たとえば、データベースに Budgeted というフィールドが含まれているとします。このフィールドには、特定のコンピュータ用に計上された予算が値として格納されます。では、この予算と実際にかかった金額を比較するにはどうすればよいでしょうか。次のクエリを使用すると、予算を上回っているコンピュータの一覧を返すことができます。
objRecordSet.Open _
  "SELECT * FROM Computers " & _
  "Where (Budgeted < Price)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
一方、次のクエリを使用すると、すべてのコンピュータの平均価格を計算し (SELECT AVG(Price) FROM Computers)、平均価格を下回っているコンピュータの一覧を返すことができます。
objRecordSet.Open _
  "SELECT * FROM Computers " & _
  "WHERE Price < " & _
  "(SELECT AVG(Price) FROM Computers)", _
    objConnection, adOpenStatic, _
    adLockOptimistic
そうです、Where 句の中で SELECT クエリを使用しています。このしくみですか。その話はまた別の機会に譲ります。しかし、ご覧のとおり、SQL クエリを使用してさまざまな役立つ情報を取得できることはおわかりいただけたのではないでしょうか。

今回の教訓
冒頭でお話したように、データベース スクリプトに関する記事をそこまで執筆したかったかと言われれば自信がありませんが、執筆してよかったと思います。理由の 1 つは、皆さんに便利なクエリを使用していただけるからですが、もう 1 つの理由は、今回でなくてもいずれは執筆しなければならなかっただろうと思うからです。あのアーサー コナン ドイル氏でさえ、シャーロック ホームズをよみがえらせることを余儀なくされました。アーサー氏が最初に取った一時的な措置は、シャーロック ホームズが最後を迎える直前の話として、新たな物語を執筆することでした。しかしその後、彼は読者からの重圧に屈して、シャーロック ホームズが命を絶ったふりをしたという少々あやふやな話を作り上げました。結局それによってすべての読者が満足したので、事態は丸く収まりました。
面白いことに、最新のシャーロック ホームズの作品が発表されると、Strand Magazine に 30,000 件の新規購読申し込みがありました。英国と米国の両出版社は、アーサー氏に感謝の意を表して、世界で最も高額な執筆料を支払いました。
アーサー コナン ドイル氏は、非常に愛された登場人物をよみがえらせ、世界で最も高額な執筆料を受け取りました。そして今回 Scripting Guys は、非常に愛されたトピックをよみがえらせました。しかもその死をごまかす必要なく。すばらしい TechNet Magazine の読者の皆さんであれば、気付いていただけましたよね。

Dr. Scripto のスクリプト パズル
パズルを解くスキルだけでなく、スクリプト作成スキルもテストする月に一度の課題です。

2008 年 4 月 : 文字選び
今月号のパズルでは、青色のマス目に A から O までのいずれかの文字を当てはめて VBScript 関数の名前を作成します。それぞれの文字 (A から O まで) は 1 回しか使用できません。また、これらの文字はアルファベット順どおりのマス目には当てはまりません。当てはめる文字が関数名の先頭の文字になる場合もあれば、末尾や中間の文字になる場合もあります。たとえば、次の行に D を当てはめると、関数名 IsDate が出来上がります。
それではいざ挑戦です。A から O までのいずれかの文字を当てはめて、VBScript 関数の名前を作成してください。

Dr. Scripto のスクリプト パズル
解答 : 文字選び (2008 年 4 月)

The Microsoft Scripting Guys は、マイクロソフトの仕事をしています、というよりもマイクロソフトにより雇われています。野球をプレイしたり監督したり観戦したり (または他のさまざまな活動を) しているのでない限り、彼らは TechNet スクリプト センターを運営しています。詳細については、www.scriptingguys.com を参照してください。


 セキュリティ ウォッチ: PII はどこに
セキュリティ ウォッチ
PII はどこに
Frank Simorjay

保護すべき最も重要な情報として、PII (個人情報) が常に話題になっています。ただし、PII を保護するには、どのような PII が PC 上に収集されているかをすべて把握しておく必要があります。コンピュータ上のデータはすべて機密情報であると言ってしまえば簡単ですが、その "すべて" とは具体的に何を指しているのでしょうか。
これを明らかにするために、この問題についてもう少し詳しく考えてみましょう。機密情報であると思われるデータをいくつかのカテゴリに分類し、それらのデータがコンピュータ上のどこに保存されているのかを解明します。まず、多くの場合、情報の機密性は主観的に判断されます。たとえば、検索結果に自分の名前が表示されたときに脅威を感じる人もいれば、そうでない人もいます。もちろん、どこかに身を隠していない限り、これまでになんらかの形で、だれかが皆さんの名前をインターネット上に投稿した可能性は十分にあります。よく使用している検索エンジンで自分の名前を検索してみてください。一般的な名前であれば、同じ名前が見つかってもそれが自分のことを指している可能性は低くなります。安心した方もいらっしゃるでしょう。
インターネット上で自分に関する情報を探す場合、ミクシィ、GREE、YouTube などの有名なソーシャル ネットワーク サイトも確認してみるとよいでしょう。以前は、個人情報を入手するには時間をかけて調査を行う必要がありましたが、現在はインターネット上に個人情報が保存され、世界中に広まっているという驚くべき状況になっています。
現在は、以前よりも技術的な観点から、保護すべき情報を知る必要があります。そのためには、保護する必要があっても自分ではその存在に気付いていない個人情報がコンピュータに保存されているかどうかがわかれば便利ではないでしょうか。身分を特定できるすべての個人情報は機密情報であると思うかもしれませんが、実際には情報は 2 つの詳細レベルに分けることができます。情報には、容易に入手できる情報と、一般に人物を特定する上で重要であると考えられている、より個人的な情報があります。
通常、容易に入手できる情報は PII とは見なされません。この情報には、名前、電話番号、住所、電子メール アドレス、性別などがあり、多くの場合、勤務先や学歴なども含まれます。これらの情報は、インターネット上や電話帳などの公的な名簿から容易に入手できます。たとえば、スパムの送信者が皆さんの電子メール アドレスを偶然入手し、この情報を公開しても、面倒なことにはなりますが、これだけでは個人情報の盗難にはつながりません。
機密情報とは、人物を特定できる、より個人的なデータから構成されます。公開することが望ましくないデータには、社会保障番号 (または行政機関が発行するその他の類似した一意識別情報)、銀行の口座番号、クレジット カード番号 (特に、有効期限とカードのメンバ ID が記載されているもの)、運転免許証番号、指紋 (またはその他のバイオメトリクス関連の情報) などがあります。これらの情報が悪意のある人物の手に渡ると、悪用されて大きな損害を受ける可能性があります。したがって、これらの情報をインターネット上や PC 上のどこに、どのようにして記録および保存するかを管理することが重要です。今から紹介するいくつかの簡単な方法を使用し、システムのハード ドライブに保存されているすべての PII を検索することによって、この目的を達成することができます。

コンピュータ上の PII データを検索する
PII は、あらゆる場所に散らばっています。実際に、ごみ箱の中を調べてみれば、きわめて容易にいくつかの PII を見つけることができるでしょう。この情報を保護するには、努力と少しの注意が必要です。性能の高いシュレッダーを購入し、個人情報が記載されているものをすべてシュレッダーにかけることをお勧めします。
では、PC に潜んでいる PII についてはどうでしょうか。このデータを見つけることは、それを安全に保存することと同じくらい困難です。システム上の情報を検索する場合は、Windows Vista® やその他のさまざまなデスクトップ検索ツールが役立ちます。ただし、どのような情報を探すのかを認識しておく必要があります。
この問題について説明するために、いくつかの簡易ツールを使用した実践的な例を簡単に示します。ここでは、Windows PowerShell® で実行するスクリプトを使用します。Windows PowerShell では数多くの機能が提供されますが、その中でも文字列の検索機能は特に優れています。今回は、正規表現を検索する機能に重点を置いて説明します。Windows PowerShell (microsoft.com/powershell から入手できます) は、瞬く間に管理作業で標準的に使用されるようになった強力なツールです。
さらに、findstr.exe を使用して誤検知を管理します。つまり、該当する文字列が含まれている可能性があっても、(バイナリ ファイル内にデータ文字列がランダムに格納されていることにより) 実際には対象にならないファイルを無視できます。今回の作業に関して言えば、テキスト ファイル以外は無視できます。
今回は、社会保障番号とクレジット カード情報という 2 つの一般的な PII データを検索します。このデータが実際にクリア テキストでハード ドライブに保存されていれば、簡単に見つけることができます。これらのデータの構造とパターンは一意なので、単純なスクリプトを使用して情報を検索できます。ただし、その機密性を考えると、このデータを PC に保存することはお勧めできません。この情報を保存する場合は、情報を確実に保護する必要があります。この後、PII を瞬時に保護する方法についても説明します。正直なところ、今回の説明は範囲が限定されています。ここには記載していませんが、ユーザー名やパスワードなど、重要な PII データは他にも存在します。

社会保障番号を検索する
ここでは、単純な文字列を使用して、XXX XX XXXX または XXX-XX-XXXX という米国の標準的な社会保障番号の構造と一致する情報をファイル内から検索します。Windows PowerShell を使用して、次のコードを入力します。
Get-ChildItem  -rec -exclude *.exe,*.dll |
select-string " [0-9]{3}[-| ][0-9]{2}[-| ]
[0-9]{4}"
また、次のように findstr.exe を使用して、バイナリ ファイルが読み取られないようにすることもできます。
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
" [0-9]{3}[-| ][0-9]{2}[-| ][0-9]{4}"
このサンプルでは、Get-ChildItem –rec によって、ディレクトリ内のファイルが再帰的に検索されます。検索は、コマンドが実行されたディレクトリから開始されます。findstr.exe は、ファイル内の文字列を検索します。また、select-string は Windows PowerShell の文字列検索関数です (ここでは説明を省略しますが、findstr.exe でもこれと似た機能が提供されています)。正規表現の先頭のスペースは意図的に追加しています。これにより、HKLM\SOFTWARE\tool\XXX-XX-XXXX のようなレジストリ文字列などの不要な情報を除外し、誤検知を減らすことができます。
私の環境でこのサンプルを実行すると、指定した検索パターンに一致する、サブディレクトリに配置したテスト サンプル ファイルが返されました。また、クレジット カード番号と社会保障番号のファイル パターンに一致するサンプル XML ファイルも検出されました (図 1 参照)。
Figure 1 番号のパターンを検索した際の結果
Figure 1 番号のパターンを検索した際の結果
最初の例では、結果としては不要な .exe ファイルと .dll ファイルが検出される可能性があるので、-exclude を使用してこれらのファイルをすべて除外しています。その他にも、誤検知の原因となるファイルの種類がいくつか検出される場合があります。その場合は、-exclude を使用して検索処理の内容を調整してください。
特定の社会保障番号のみを検索する場合は、次のコードを使用します ("123 45 6789" を検索対象の社会保障番号に置き換えてください)。
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"123 45 6789","123-45-6789"
図 2 は、この検索処理の結果を示しています。
Figure 2 特定の番号の検索
Figure 2 特定の番号の検索

クレジット カード情報を検索する
クレジット カード情報にはさまざまな形式があるので、少し注意が必要です。また、誤検知 (つまり、偶然クレジット カード番号のような形式になっているデータ) を制限する必要があります。ただし、この制限を適用しても、偶然クレジット カード番号のような形式になっているデータはいくつか検出されると思います。
ここで使用する検索文字列の作成時には、Michael Gilleland が執筆した「Anatomy of Credit Card Numbers」( merriampark.com/anatomycc.htm) に記載されている情報を参考にしました。たとえば、この検索文字列では、最初の番号が 4、5、または 6 であるという条件を指定しています。この理由は、これらの番号がクレジット カード業界で主に使用される識別子として定義されているからです。
ここでは、Discover、MasterCard、および Visa のカードを検索する単純な文字列を作成しました。Windows PowerShell で、次のような検索文字列を使用します。
Get-CchildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
 "[456][0-9]{15}","[456][0-9]{3}[-| ][0-9]{4}
[-| ][0-9]{4}[-| ][0-9]{4}"
図 3 のサンプルでは、-exclude を使用して、結果としては不要な .rtf、.rbl、および .h ファイルを除外しています。このサンプル コードでは、スペースまたはダッシュが使用されていないクレジット カード文字列も検出されます。残念ながら、これでは結果が表示しきれなくなってしまいます。このため、同じ機能を持つ次のコマンドを使用します。このコマンドでは、スペースやダッシュが使用されていないカード番号は検索されません。
Figure 3 -exclude を使用して不要なデータを結果から除外する
Figure 3 -exclude を使用して不要なデータを結果から除外する
Get-ChildItem  -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"[456][0-9]{3}[-| ][0-9]{4}[-| ][0-9]{4}
[-| ][0-9]{4}"
American Express のカードは大幅に形式が異なるので、そのパターンに一致するカードを検出するための検索文字列を作成しました。Windows PowerShell で、次のような検索文字列を使用します。
Get-ChildItem -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"3[47][0-9]{13}","3[47][0-9]{2}[-| ][0-9]{6}
[-| ][0-9]{5}"
上記のコマンドでも、表示しきれないほどのデータが検出される可能性があります。次のコマンドでは同じ機能が提供されますが、スペースやダッシュが使用されていないカード番号は検出されません。
Get-childitem -rec | ?{ findstr.exe
/mprc:. $_.FullName } | select-string
"3[47][0-9]{2}[-| ][0-9]{6}[-| ][0-9]{5}"
このコラムの執筆時に、自分の環境でこれらの検索を実行しましたが、非常に驚きました。自分の社会保障番号が、保存した覚えのない場所に保存されていたからです。後からわかりましたが、これらの情報は少し前に書いたメモに記載されており、私はそのことを忘れていました。メモとして残すべきものとそうでないものについて、改めて考えさせられました。
この情報を安全に保存するには、Password Safe などのツールを使用します (このツールは passwordsafe.sourceforge.net から入手できます)。または、BitLockerTM ドライブ暗号化などのツールを使用して、ハード ドライブを暗号化します。さらに、モバイル PC のデータ保護に関するテスト済みのガイダンスが記載されている、Data Encryption Toolkit for Mobile PC を参考にすることもできます。これらの方法を使用すれば、悪意のある人物が PC 上の個人情報を入手することは、少なくとも今までより難しくなります。

まとめ
PII を検索する作業は非常に単純です。大変なのは、検索すべき情報を認識することです。しかし、マルウェアや悪意のあるユーザーが一度システムへのアクセスに成功すれば、ここで紹介したような検索方法を使用して、システム上の情報を簡単に検索できるようになることを忘れないでください。重要なのは、いつどこに PII を入力したのかを把握し、保存する必要がある情報を暗号化することです。
Windows PowerShell スクリプトの作成時に、問題点の解決に協力してくれた Matt Hainje 氏に感謝します。

Frank Simorjay は、マイクロソフト ソリューション アクセラレータのセキュリティおよび法令順守グループで、テクニカル プログラム マネージャを務めています。マイクロソフト顧客向けのセキュリティ ソリューションを設計したり、Secure World Exposition (彼はその発起人です) などのイベントで講演を行ったりしています。また、セキュリティに関する教育やトレーニングを行ったり、セキュリティに関するさまざまな学術論文や書籍を執筆したりしています。最近手がけた仕事には、"マルウェアの削除スタート キット" があります。


 デスクトップ ファイル: WAIK を使用して Windows XP を展開する
デスクトップ ファイル
WAIK を使用して Windows XP を展開する
Wes Miller

驚くべきことに (そして厄介なことに)、顧客によって環境は大きく異なります。理想的なのは、すべての顧客が常に同じバージョンの Windows を展開し、同じ段階の作業を行っていることです。そうすれば、確実にテスト作業は容易になります。しかし、もちろん現実は違います。既に Windows Vista® の展開で苦労している (または展開を終えた) 方や、
運用環境に 1 台目の Windows Server® 2008 読み取り専用ドメイン コントローラ (RODC) を展開する準備に熱心に取り組んでいる方もいらっしゃると思いますが、長期に渡って計画してきた Windows® XP や Windows Server 2003 R2 を現在展開しているという報告も、それと同じくらい頻繁に寄せられています (ありがたいことです)。
先日、ある読者の方から "Windows 自動インストール キット (WAIK) と Windows XP について教えてください。Windows XP を展開するときに、WAIK をどのように使用すればよいですか" という内容のメールをいただきました。それでは、この質問にお答えしましょう。

WAIK を見直す
1 年ほど前に、WAIK に関するコラム (technetmagazine.com/issues/2007/01/DesktopFiles) を執筆しました。WAIK は、Windows Vista の展開に役立つように設計された一連の強力なツールです。現在では、WAIK は Windows Server 2008 の展開にも対応しています。また、これら 2 つのオペレーティング システムでは、新しいセットアップ インフラストラクチャが提供されます。WAIK のツールは、主にこれら 2 つのオペレーティング システムを利用することを想定して設計されています。無人セットアップまたは Sysprep を使用して、Windows Vista より前のバージョンの Windows を展開する場合は、好むと好まざるとにかかわらず、これらのバージョン専用のツールを使用する必要があります。しかし、今回 WAIK を見直し、Windows XP の展開に役立つツールの存在を明らかにしたいと思います。
Windows PE 2.0 共通点を見つけるために、まず Windows PE 2.0 と Windows XP のデュアル ブートに関する 2008 年 2 月号のコラム (technetmagazine.com/issues/2008/02/DesktopFiles) を見てみましょう。基本的に、Windows PE 2.0 がこのコラムのようなデュアル ブート環境で正常に動作する場合は、今回のコラムの環境でも Windows PE 2.0 を使用できます。RAM が 512 MB 未満のシステムや、Windows Vista で提供される Advanced Configuration and Power Interface (ACPI) がサポートされていないシステムに Windows XP を展開する場合は、Windows PE 1.6 が必要です。また、その場合は、ソフトウェア アシュアランスの特典として Windows PE 1.6 を入手できるかどうかを確認する必要があります。現在、Windows PE 2.0 と 2.1 は無料で入手できますが、Windows PE 1.6 以前のバージョンを入手するには、ソフトウェア アシュアランスのメンバシップが必要です。
ImageX と WIM ImageX と Windows Imaging Format (WIM) は、NTFS ボリュームまたは FAT ボリュームにインストールされた Windows 2000 以降のすべてのバージョンの Windows で動作させることを目的として基礎から設計されました。そのため、もちろん ImageX と WIM を使用して Windows XP (または Windows Server 2003) を展開することができます。
Windows 展開サービス リモート インストール サービス (RIS) に置き換わる Windows 展開サービス (WDS) は、最初は WAIK 1.0 の OOB (Out-of-Band) リリースとして提供されましたが、その後更新され、Windows Server 2003 SP2 に統合されました。Windows Server 2008 ではその機能が強化されていますが、Windows XP の展開にも非常に適しています。
RIS サーバーを所有しているか、WDS サーバーをレガシ モードで実行している場合、WDS はあまり適していません。しかし、WDS を混合モードまたはネイティブ モードに移行し始めている場合は、Windows XP の展開シナリオに使用できる方法の 1 つとして、WDS の機能を理解しておく必要があります。
Windows System Image Manager (WSIM) WSIM は、Windows Vista と Windows Server 2008 の展開にのみ使用できます。Windows Server 2003 以前のオペレーティング システムを展開する場合、WSIM はあまり役立ちません。

Windows XP の展開ツール
Windows XP は、Windows NT® 4.0 から Windows Server 2003 までのすべてのバージョンの Windows と同様、unattend.txt ファイルまたは "イメージ" を使用して展開できます。無人セットアップは以前の機能なので、このコラムでは説明を省略します。WAIK (具体的には ImageX) を利用する場合、イメージ ベースの展開を行うことになります。そのため、unattend.txt ではなく、Sysprep 用の応答ファイル形式である sysprep.inf が必要です。
このコラムでは、OS イメージの作成方法について大まかに説明するときに、"イメージ" という言葉を使用します。従来は、Ghost、PQDI、またはその他のイメージ作成ツールを使用していたと思います。マイクロソフトは、ImageX で初めて、Sysprep 実行後の OS やアプリケーションのイメージを作成し、1 台以上のコンピュータにコピーする機能を提供しました。
Windows のイメージを作成する際は、次に示す 2 つの重要なポイントを考慮する必要があります。
  • ユニプロセッサ システムをマルチプロセッサ システムに移行する (またはその逆) 場合を除いて、ハードウェア アブストラクション レイヤ (HAL) を変更することはできません。また、以前公開したコラムに記載されているように、ACPI アーキテクチャを ACPI 以外のアーキテクチャに移行する (またはその逆) 場合、イメージを安全に変更することはできません。
  • 大容量記憶域コントローラを変更することは可能です。変更できないと考えられることがよくありますが、それは誤解です。しかし、これを行うには、Sysprep を使用して、インストール先のコンピュータで必要になると考えられるすべての大容量記憶域コントローラをインストールする必要があります。展開後、Sysprep を使用して、インストール先のシステムで使用されていないデバイスのドライバをすべて削除します。これについては、この後すぐに説明します。
これら 2 つのポイントを考慮すると、1 つのシステムで準備したイメージを、同一または互換性のある HAL を使用する他のシステムで動作させることができるようにする必要があります。

使用するツール
イメージ ベースの展開シナリオで Windows XP を使用するときは必ず、以下の 3 つを用意しておく必要があります。
Ref.chm 無人セットアップ テキスト ファイルのリファレンス。Windows Vista よりも前のバージョンの Windows に含まれているオプション コンポーネントを構成する場合は、イメージを作成する前が最適なタイミングであることを覚えておいてください。ただし、セットアップ後にオプション コンポーネントをインストールする必要がある場合は、support.microsoft.com/ kb/222444 で説明されているように、sysocmgr.exe を実行してこれらのコンポーネントをインストールすることができます。Windows XP Tablet PC Edition を展開する場合は、go.microsoft.com/fwlink/?LinkId=108589 に記載されている手順に従って、該当するシステムに Tablet PC コンポーネントをインストールする 1 つのイメージを作成します。
Sysprep マイクロソフトによってサポートされている、ディスク複製されたシステムを作成するための方法です。現在でも、サードパーティ製のセキュリティ識別子 (SID) 変更ツールの使用が推奨されることがありますが、これまでどおり、Sysprep の使用をお勧めします。これは、他のツールでは重要な場所 (特に、公開されていない場所) にある Windows SID が検出されない傾向があるからです。
セットアップ マネージャ sysprep.inf ファイルを最も短時間で容易に作成できる方法です。これまでどおり、正しいバージョンを使用するようにしてください。一般に、展開する Windows のバージョンと同じであれば、正しいバージョンです (たとえば、Windows XP SP2 と Windows XP SP2 用展開ツール)。
これら 3 つは、すべて Windows XP の CD に収録されています。最新版は go.microsoft.com/fwlink/?LinkId=107541 から入手できます。
また、tap.exe も用意しておく必要があります。このユーティリティは、Windows XP Embedded ツール (go.microsoft.com/fwlink/?LinkId=108590) に同梱されており、無料の評価版にも同梱されています。Windows PE では、tap.exe は Windows PE が検出したすべてのプラグ アンド プレイ (PnP) デバイスに関する情報を返します。最も興味深い機能は、Windows PE がデバイス用に選択した HAL を通知する機能です (図 1 参照)。この機能が重要である主な理由は、Windows PE が HAL を選択する際に使用するロジックと、Windows の標準セットアップが配置する HAL を判断する際に使用するロジックが同じであるからです。そのため、Windows PE で tap.exe を使用すると、特定のシステム用に Windows が推奨する HAL の種類を確認するのに役立ちます。
Figure 1 特定のシステム用に Windows PE が選択した HAL を通知できる tap.exe ユーティリティ
Figure 1 特定のシステム用に Windows PE が選択した HAL を通知できる tap.exe ユーティリティ

イメージを作成する
次の手順を実行することによって、ImageX を使用して独自の Windows XP イメージを展開するための準備を行うことができます (別のイメージ作成ツールを使用することもできますが、すぐにこのワークフローにとって ImageX を使用することが理想的である理由がわかるでしょう)。
まず、Sysprep、セットアップ マネージャ、ImageX、Windows PE など、必要なすべてのツールとコンポーネントを用意します (要件や環境に応じて、Windows PE 2.0 または 1.6 を用意します。ImageX を含む Windows PE 2.0 を使用している場合は、パーティションの作成時に /nt52 スイッチを指定して bootsect.exe を実行し、Windows XP と互換性があるブート コードに変更する必要があります)。
もちろん、コンピュータに Windows XP (任意の SKU) をインストールし、最新の更新プログラムを Windows とインストールされているその他のソフトウェアに適用することも必要です。また、ドメインに参加したことがないシステムを使用するのが理想的です。理由は、後でドメインやネットワークに関する問題が発生する可能性が低くなるからです。システムには、安全にイメージを作成できるアプリケーションのみがインストールされている必要があります。コンピュータ名、SID、ドメイン、またはユーザー固有の情報を独自に格納するアプリケーションがインストールされている場合、Sysprep はそれらの情報を検出できないか、SID の変更時に置き換えることができません。また、システムでは、展開数が最も多いと予想される HAL が使用されている必要があります。一般に、最近のハードウェアでは ACPI マルチプロセッサ (MP) HAL が使用されます。この理由は、ACPI とマルチコア (以前のハイパースレッディング。ハイパースレッディングでも MP HAL が使用されていました) が普及したからです。
では、要件に合わせてエンド ユーザー用の Windows XP システムを構成します。まず、大部分のユーザーが使用するアプリケーション (および無人操作でインストールできないすべてのアプリケーション) をすべてインストールします。次に、Windows のオプション コンポーネントをインストールまたは削除することによって、エンド ユーザー用のシステムを適切に構成します。その後、デスクトップを構成します。Administrator としてログオンし、デスクトップの背景、スクリーン セーバー、スタート メニューなど、プロファイルに必要な変更を加えます。既定では (Windows XP SP2 以降)、これらの設定は、Sysprep によって Administrator アカウントから既定のユーザー アカウントにコピーされます。
次に、セットアップ マネージャ (図 2 参照) を実行し、新しい Sysprep 無人ファイルを作成すること、およびセットアップを完全に自動化することを指定します。セットアップ マネージャの手順では、プロダクト キーの入力を要求されることに注意してください。プロダクト キーが手元にない場合、またはプロダクト キーを入力するスクリプトを後で作成する (およびボリューム ライセンス キーを保有していない) 場合は、Windows XP または Windows Server 2003 の CD に収録されている既定の unattend.txt ファイルに含まれているキーを指定できます (これによりセットアップを完了できますが、ライセンス認証を完了することはできません)。
Figure 2 セットアップ マネージャを使用した Sysprep 応答ファイルの作成
Figure 2 セットアップ マネージャを使用した Sysprep 応答ファイルの作成
また、コンピュータ名も指定する必要があります。この作業は SQL やその他のメカニズムを使用して後から自動的に実行することもできますが、ここではなんらかの値を入力し、コンピュータに WIM を展開した後、Sysprep を実行する前にスクリプトを使用してコンピュータ名を変更します。
Administrator アカウントのパスワードを指定した場合、そのパスワードは、イメージの既存の Administrator アカウントにパスワードが指定されていない場合のみ適用されます。また、ドメインへの参加に関するセクションでは、ドメインへの参加に使用する資格情報を暗号化できません。このため、最小限の特権が与えられたアカウントを使用してコンピュータ アカウントを設定する必要があります。最後に、セットアップ マネージャのバージョン文字列に関するオプションを使用して、作成したイメージの "バージョン" を記録することをお勧めします。
次に、作成した sysprep.inf ファイルを、sysprep.exe と setupcl.exe と共に C:\Sysprep ディレクトリに配置して、次のコードをこの .inf ファイルに追加します。
[Sysprep]
BuildMassStorageSection = Yes

[SysprepMassStorage]
その後、Sysprep –bmsd を実行します。これにより、sysprep.inf が変更され、インストールされている Windows が対応しているすべての大容量記憶域 ID が追加されます (図 3 参照)。必要に応じて、インストールされている Windows に他のデバイスを追加して、sysprep –bmsd を再度実行することもできます。
Figure 3 sysprep.inf への大容量記憶域 ID の追加
Figure 3 sysprep.inf への大容量記憶域 ID の追加
次に、sysprep.inf ファイルを共有にコピーし、sysprep.exe –factory を実行して、システムをシャットダウンします。その後 Windows PE で再起動し、次のコードを使用して UNC 共有 (推奨) に接続します。
NET USE Y: \\myserver\myshare
/USER:DOMAIN\USER password
接続後、次のコードを使用してイメージをキャプチャします。
ImageX /capture C: Y:\NewImage.wim
"Factory Mode capture from 4/1/2008"
その後、システムをシャットダウンします。
これで、ファクトリ モードで更新できるイメージが作成されました。今回のコラムでは詳しく説明しませんが、簡単に言うと、ファクトリ モードは、展開用のイメージを作成する準備が整うまでイメージを最も安全に保存しておくことができるモードです。詳細については、先ほど紹介した Windows XP の deploy.cab ドキュメントを参照してください。
展開用のイメージを作成する準備が整ったら、つまり、展開の準備ができたら、Windows PE で起動し、Diskpart を使用して必要なパーティションを作成します。format コマンドを使用してパーティションをフォーマットし、必要に応じて bootsect.exe を使用して Windows Vista より前のバージョンのブート コード (/nt52) を適用します。ここで、次のコードを使用して UNC 共有に接続 (またはイメージが保存されているディレクトリに移動) します。
NET USE Y: \\myserver\myshare
/USER:DOMAIN\USER password
その後、次のコードを使用してイメージを適用します。
ImageX /apply Y:\NewImage.wim C: 1
最後に、Windows ファクトリ モードで再起動し、イメージに必要な変更を加えます (このとき、winbom.ini ファイルを使用する必要があります。詳細については、deploy.cab に含まれている ref.chm を参照してください)。winbom.ini には、必ず次のコード行が含まれます。このコード行は、次回再起動したときにミニセットアップを実行できるように、イメージを再シールすることを指示しています。
[FACTORY]
ResealMode = Mini
処理が完了したら、シャットダウンします。イメージのキャプチャに使用した前述の手順を再度実行します。ただし、ここでは次のようにキャプチャ コマンドを変更します。
ImageX /append C: Y:\NewImage.wim "Resealed
and ready for deployment – captured 4/4/2008"
/append を指定して、大きな空き領域を確保します。ファクトリ モードと再シールしたイメージを組み合わせたので、それらを簡単に切り替えることができます。また、/delete を指定して、使用しないすべてのイメージを途中で削除することもできます。ただし、イメージを削除しても、空き領域が確保されるわけではなく、指定したボリューム イメージへの参照が削除されるだけであるということに注意してください。使用されていない領域をクリーンアップする場合は、保持しておくすべてのボリューム イメージをエクスポートする必要があります。
WAIK は主に Windows Vista と Windows Server 2008 用に設計およびサポートされていますが、どのバージョンの Windows を展開する場合でも役立つツールであることがおわかりいただけたと思います。Windows XP のツールと WAIK のツール (主に ImageX、場合によっては Windows PE 2.0) を組み合わせて使用する必要がありますが、現在はすべてのバージョンの Windows を展開するために必要な機能がマイクロソフトから提供されています。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (www.CoreTrace.com) のシニア テクニカル プロダクト マネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラム マネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。


 フィールド ノート: MAR というすばらしい構想
フィールド ノート
MAR というすばらしい構想
Neil Fawcett

たとえば、 5,000 台の再生した PC が地下室にあり、その PC を買い求める客が既に列を作って並んでいるところを想像してみてください。ハードウェアを再生しても、オペレーティング システムにはまったく異なる問題があります。搭載している OS は正規に入手したものなのか、各 PC には OS が搭載されているのか、OS は再販できるのか、などの問題です。
この新しい Microsoft Authorized Refurbisher (MAR) プログラムには、このような問題の解決策が用意されています。このプログラムは、一見すると、きわめて単純な発想に基づいたものです。このプログラムでは企業が古い PC を回収して、正式版の OS をインストールして再販することを支援します。
ただし、MAR プログラムにはさらに目的があります。実用的な面で、マイクロソフトと PC 再生業者の両方にビジネス チャンスをもたらすという目的です。法律の面では、ソフトウェアの不正コピーの蔓延を (事故または故意の両方において) 食い止めるのに役立ちます。また、環境の面では、まだ使用できるハードウェアが廃棄されることを防げます。さらに、特に PC の所有者がある人から別の人に変わるときに、マイクロソフトで使用許諾をどのように扱うかを企業が理解する手段となります。
このプログラムは、マイクロソフトと PC の再生業者だけにメリットがあるわけではありません。消費者にも多くのメリットがあります。消費者が購入するのは、古いデータが完全に消去され、正式版の Windows® XP Home Edition または Windows XP Professional がプレインストールされた PC です。したがって、この PC を購入した消費者はダウンロード、更新プログラム、および強化された機能を使用することができます。また、今後リリースされる Windows の後継バージョンにアップグレードすることもできます。以前ならば簡単に廃棄物扱いになっていた PC を、このとおり再生しています。そして、PC を有害廃棄物にしない努力という面で一定の成果を上げています。
MAR プログラムは、毎月平均 5,000 台の PC を再生するキャパシティがある企業を対象にしています。その程度の数の PC を再生した実績を示すことがプログラムに参加するための要件となっています。MAR は全世界を対象としたプログラムです。アメリカ国内またはカナダに本社のある再生業者はもちろん、主要な OEM 再生業者に対しても広く門戸を開いています。現在、このプログラムには、Redemtech、Techturn、および Apto Solutions の 3 社の再生業者が参加しています。
新しいソフトウェア製品のライセンスに関しては、売り手と買い手の両方に混乱を招いている場合が時折見受けられますが、再生 PC 市場の出現により、古いバージョンの Windows について可能なこととそうでないことに関する新たな混乱が生じています。MAR プログラムは再生業者が直面している、この新しい複雑な状況を打開するものです。インストール用のツール一式が提供され、その中には、再生した多様な PC に Windows XP をプレインストールする作業負荷を軽減する Refurbisher Preinstallation Kit (RPK) も含まれます。各 PC にはマイクロソフトが発行する Certificate of Authenticity (COA) が添えられます。PC が再生されて、その PC に付属する COA がまだ有効で、かつ会社がリカバリ メディアまたはハードディスク ベースのリカバリ イメージを所有していれば、新たに Windows のライセンスを取得する必要はありません。ただし、MAR プログラムでは、リカバリ メディアやリカバリ イメージがない場合の処理も簡略化するように考慮されています。
寄贈、再生、再販などの形で行われるコンピュータの再利用は、特に、これまでテクノロジに触れる機会にあまり恵まれなかった人々にとってテクノロジを使う機会が増えるので、非常に有望です。また、テクノロジ業界が環境に与える悪影響を抑制することにも役立ちます。現に、"中古 PC 市場" と呼ばれる使用済み PC の市場は、経済発展途上の地域においてはテクノロジの普及手段であることが既に証明されつつあります。
再生 PC の市場は拡大しています。企業が PC の処分方法について廃棄以外の手段を検討すれば、廃棄する時期を遅らせることができる PC は何百万台もあることを指摘する予測がいくつもあります。MAR プログラムはマイクロソフト社内で戦略的な役割を担っているだけでなく、他の企業やユーザーにメリットをもたらす低コストのハードウェア ソリューションを展開することで、大規模な企業を強力に支援しています。地球規模で起こっている環境問題への関心の高まりにより、PC を適切に処理することは、これまでになく重要になっています。古い PC の再生により、低コストのテクノロジを必要としているユーザーにメリットをもたらし、PC を有害廃棄物にしない、という点において MAR プログラムのような構想の重要性は増すでしょう。単にソフトウェア使用許諾の供与を明確にすることを支援した点だけをとっても、このプログラムは再生 PC に注目を集めることに大きく貢献しています。MAR プログラムの詳細については、microsoft.com/oem/mar を参照してください。

Neil Fawcett は IT の分野で多数の書籍の執筆と編集に 20 年以上携わっています。また、イベントでの講演の経験や、IT 関連のテーマで書籍を 13 冊出版した実績もあります。執筆活動を始める以前は、ソフトウェア開発者およびハードウェア エンジニアとしてシリコン バレーで働いていました。


 Windows 秘話: 共有するときは公正に
Windows 秘話
共有するときは公正に
Raymond Chen

これまで、 プログラムをアンインストールするときに、"このファイルを削除すると、他のアプリケーションを適切に実行できなくなる可能性がありますが、よろしいですか" と Windows® が確認するのはなぜか、疑問に思ったことはありませんか。まず、このメッセージ (スクリーンショットを参照) は、Windows からではなく、アンインストーラから出力されます。したがって、正しい疑問は "アプリケーションのアンインストーラは、なぜこのダイアログ ボックスを表示するのだろうか" ということになります。これは、答えられない質問をユーザーに投げかけているよい例です。では、このような悲しい状況に至った経緯をご説明しましょう。
インストーラは、複数のアプリケーションによって使用されるファイル (関連性のない複数のプログラムによって使用される MFC ランタイム ライブラリなど) の参照カウントを管理するために、あるエントリを SharedDLLs レジストリ キーの下に作成します。このエントリは、ファイルとその参照カウントの一覧を保持します。既にファイルのエントリが存在する場合は、そのファイルの参照カウントを 1 増加します。エントリが存在しない場合は、そのファイルの参照カウントを 1 に設定します。逆に、プログラムがアンインストールされるときに、参照カウントを 1 減少し、カウントが 0 になると、このファイルを使用するプログラムがなくなるので、ファイルを削除します。少なくとも、理論上はそうでした。
Should I delete it or not?
Should I delete it or not?
このモデルには、すべてのプログラムが規則に従って動作することを前提としているという重要な問題点があります。ただし、ごまかしたとしても通常はそのプログラムが罰せられることはないので、ついごまかしてしまいたい誘惑に駆られます。
たとえば、MFC ランタイム ライブラリを使用するプログラムがあり、そのインストーラは参照カウントを更新せずに、単純にライブラリをシステムに直接コピーするとします。その後、このプログラムをアンインストールすると、単純にそのランタイム ライブラリも削除されます。では、このプログラムが、規則に従っている別のプログラムと共存しようとすると、どのような動作が発生するか考えてみましょう。基本的なイベントの流れは、次のようになります。
  1. 良いプログラムをインストールします。ライブラリがインストールされ、参照カウントが 1 に設定されます。
  2. 悪いプログラムをインストールします。ライブラリがインストールされますが、参照カウントは変更されません。
  3. 悪いプログラムをアンインストールします。ライブラリが削除されます。
この一連のイベントの結果、ライブラリが削除されるので、良いプログラムが機能しなくなります。
別のシナリオを次に示します。
  1. 良いプログラムをインストールします。ライブラリがインストールされ、参照カウントが 1 に設定されます。
  2. 悪いプログラムをインストールします。ライブラリがインストールされますが、参照カウントは変更されません。
  3. 良いプログラムをアンインストールします。参照カウントが 0 になり、ライブラリが削除されます。
このシナリオの結果、悪いプログラムが機能しなくなります。
良いプログラムの開発者は、「悪いプログラムが良いプログラムを停止するのは止められないけれど、少なくとも良いプログラムは悪いプログラムを停止しないようにしよう」と考えました。したがって、良いプログラムがファイルを削除しようとすると、一度処理が停止し、"このファイルを削除しますが、問題ないでしょうか。悪いプログラムがインストールされていて、このファイルを使用している場合、悪いプログラムは停止します。悪いプログラムがインストールされている場合は、[削除しない] をクリックしてください" という警告メッセージが表示されます。そうですね。これは正確な言い回しではありませんが、どのダイアログ ボックスについて話をしているかおわかりでしょう。あの Jeffrey Richter でさえ、1996 年発行の『Microsoft Systems Journal』の記事で、この方法を推奨しています。
残念ながら、このような操作を実行すると、適切に答えられない質問がユーザーに表示されます。
もちろん、どんなファイルが上書きされる場合でも Windows に確認を要求するような、何でも管理したがる人であれば、このダイアログ ボックスを称賛するでしょう。世の中のアンインストーラ プログラムでは、アンインストール プロセスをファイル単位で制御できる機能が提供されています。ただし、設定には十分注意してください。実際に設定どおりになって、困ることもありますから。

Raymond Chen は自分の Web サイト「The Old New Thing」および同じタイトルの書籍で、Windows の歴史と Win32 プログラミングについて扱っています。関心があるのは、自分が生きているうちに核融合が可能になるかどうかということです。