SQL に関する Q&ABest Practices Analyzer、マルチコア プロセッサなど
Nancy Michell
質問 – スキーマ修飾テーブルとスキーマ修飾ビューの使用に関する Best Practices Analyzer (BPA) のルールについていくつか質問があります。BPA のドキュメントによると、このルールでは一時テーブルでのスキーマ修飾がチェックされません。BPA レポートでは、ストアド プロシージャ内で作成された一時テーブルへの参照にフラグが設定されます。これらは修飾されるべきではないでしょうか。この場合、どのようなスキーマで修飾されますか。他のテーブルと同様に、一時テーブルもその所有者で修飾されるのではないかと思うのですが。
回答 – スキーマ修飾テーブルとスキーマ修飾ビューの参照についての BPA による推奨は、SQL Server™ 2005 では完全には当てはまりません。これ以前のバージョンではスキーマ修飾が必要になっていた問題が、SQL Server 2005 ではユーザーとスキーマの分離により解決されているためです。SQL Server 2000 では、既定のスキーマが異なる別のユーザーがクエリ プランを再利用できるようにするために、スキーマ修飾が必要でした。修飾なしで dbo オブジェクトを使用することもできましたが、SQL Server はまずオブジェクトの既定のスキーマをチェックしなければならず、これがクエリ プランの再利用を妨げていました。ユーザーとスキーマが分離されたことにより、他のユーザーが既定のスキーマを共有できるようになったため、一般的にはすべてのデータベース ユーザーが各ユーザーの既定のスキーマのオブジェクトにアクセスできるようにするために、修飾されていないテーブル名とビュー名を使用するアドホック プランが、通常ユーザー間で共有および再利用されます。ストアド プロシージャ内の修飾されていないテーブル名やビュー名は、そもそもこの問題の影響を受けることはなく、このことからもこの処理の必要性は低くなります。SQL Server 2005 の BPA には、T-SQL パーサーがないため、このようなルールは含まれない予定です。代わりに、不適切な構成やセキュリティ設定がないかがチェックされます。
質問 – SQL Server 2005 SP1 で奇妙な動作が見られます。同じテーブルに対してテーブルの行の削除と挿入を同時に行うと、削除のトランザクションがコミットされるまで挿入がロックされます。何がブロックしているのかを確認する方法はありますか。
回答 – はい、あります。図 1 の動的管理ビュー (DMV) スクリプトを実行して、ロックおよびブロックしている処理を確認できます。
Figure 1 ブロックしている処理とロックの検出
-- script to show blocking and locks
SELECT
t1.request_session_id AS spid,
t1.resource_type AS type,
t1.resource_database_id AS dbid,
(case resource_type
WHEN ‘OBJECT’ THEN object_name(t1.resource_associated_entity_id)
WHEN ‘DATABASE’ THEN ‘ ‘
ELSE (SELECT object_name(object_id)
FROM sys.partitions
WHERE hobt_id=resource_associated_entity_id)
END) AS objname,
t1.resource_description AS description,
t1.request_mode AS mode,
t1.request_status AS status,
t2.blocking_session_id
FROM sys.dm_tran_locks AS t1 LEFT OUTER JOIN sys.dm_os_waiting_tasks AS t2
ON t1.lock_owner_address = t2.resource_address
GO
質問 – ハイパースレッドやデュアルコア テクノロジだけでなく、さらに多くのコア (4 コア、8 コアなど) を搭載したプロセッサのリリースが始まっています。現在、SQL Server 2005 Standard Edition の展開を行うために、マルチコア プロセッサを搭載した新しいサーバーの購入を検討していますが、4 コアのプロセッサを使用する場合、実際に使用できるのは 1 基の物理 CPU のみになるのでしょうか (Standard Edition でサポートされるのは最高で 4 CPU のため)。
回答 – ライセンスやエディションでの CPU のサポート数について、SQL Server ではプロセッサのコア数とは無関係に、物理ソケット (CPU) 数のみが考慮されます。したがって、たとえば SQL Server 2005 Standard Edition が最高で 4 CPU をサポートするという場合、CPU のコア数とは無関係に、4 つの物理 CPU ソケットをサポートすることになります (つまり、4 コアの物理 CPU が 4 基ある場合、展開した Standard Edition が使用できる論理 CPU 数は 16 になります)。また、コア (論理 CPU) 数は 16 でも、必要になるライセンス費用は 16 コア分ではなく、4 物理 CPU 分のみです。SQL Server およびマルチコアの詳細については、microsoft.com/sql/howtobuy/multicore.mspx を参照してください。
質問 – 新しいデータベース サーバーの購入を検討しています。64 ビット版を購入すべきでしょうか。それとも、テスト済みの 32 ビット版を購入すべきでしょうか。
回答 – 状況によって異なります。x86 から x64 へのハードウェアの移行が進んでいるため、最近よくこのような質問を受けます。まず、データベース サーバーのメモリ負荷がどの程度になるかを確認する必要があります。ハードウェアの運用期間中 (通常 3 年間) に SQL Server インスタンスが使用する RAM が 3 GB 未満の場合、他のサーバー (ドメイン コントローラ、DNS サーバー、アプリケーション サーバー、Web サーバー、メール サーバー) で 32 ビット x86 が使用されているのであれば、32 ビット x86 が妥当です。SQL Server インスタンスが 16 GB 以上を使用するか、1 サーバー (またはクラスタ) に複数のインスタンスが存在する場合は、64 ビット テクノロジへの移行をお勧めします。8 プロセッサを超える場合は、IA64 が標準の推奨です。ただし、4 コアと 8 コアの x64 CPU が市場へ多量に供給され始めているため、コスト面から IA64 ではなく x64 の方がメリットがある場合もあります。
x64 (または IA64) に移行する際、最初のコストの見積もりでは、開発環境、テスト環境、パフォーマンス環境で同じアーキテクチャを展開することは考慮されていない場合があります。しかし、ハードウェア ライフサイクルの途中までは古いテクノロジを使用するかどうかについても考慮する必要があります。18 か月後には、純粋な x86 ハードウェアはほぼ調達できなくなるでしょう。この種のソリューションを現時点で選択した場合、今後 1 ～ 2 年のうちにアップグレードを行うと、完全なリプレースとなるため、コストが高くなると思われます。現時点で 64 ビット ハードウェアを選択しておけば、今後数年間で使用できる選択肢が多くなります。
そのため、64 ビットへ移行するタイミングとしては、新しいハードウェアの購入時、主要アプリケーションのリリース サイクルの開始時、または SQL Server 2000 から SQL Server 2005 へのアップグレード時が適しています。
質問 – 2 台のサーバー間でログ配布を有効にしています。週末にプライマリ サーバーでハードウェア障害が発生し、ログ配布が停止しました。ログ配布の監視を再開したところ、数時間ダウンタイムがあったにもかかわらず、LS_backup_dbname は適切に実行されていました。
しかし、セカンダリ サーバーでは、コピー ジョブは適切に機能しているようですが、復元ジョブではファイルがスキップされ、最終的に失敗を繰り返しているようです。実行はされているのですが、すべてのファイルがスキップされ、失敗します。そのため、最後の復元から、849 分が経過しています。以前同じような状況では、単純に配布構成をもう一度初期化しました。つまり、配布を一度無効にしてから再び有効にして、セカンダリ サーバーに新しいバックアップがコピーおよび復元されるようにして、ログ配布を再開しました。このような状況の対応として、他に良い方法はあるでしょうか。
回答 – おそらくこれは、バックアップ ファイルが失われていることによる影響です。ご存じのとおり、ログ配布では、バックアップ ジョブ、コピー ジョブ、および復元ジョブが個別に実行されます。コピー先の古いバックアップ ファイルも、指定されたスケジュールに従って削除されます。復元ジョブが実行されない期間があった場合、スケジュール設定された期間を過ぎてしまい、バックアップ ファイルが失われることがあります。ログ配布の復元ジョブには、別の操作上の状態に起因するこれ以外の問題からの復元を試みるロジックがあります。これは基本的に、エラーが発生した際にファイルをスキャンし、適切なバックアップ ファイルの検出を試みるものです。適切なバックアップ ファイルが見つからない場合は、何らかの理由で必要なファイルが削除されたか、ログ配布のバックアップの部分が再構成されたと考えられます。
解決策としては、他のバックアップ ジョブにより何らかの事情で作成されているトランザクション ログ バックアップ ファイルを使用して手動で復元することです。これをログ配布用のコピー先に単にコピーした場合問題になるのは、ログ配布が認識する命名規則です。ただし、その時点から手動で復元できれば、通常の復元が再び機能するようになります。
質問 – T-SQL を使用して物理メモリの合計容量と空き容量を調べる方法を教えてください。この情報を取得する簡単な方法はありますか。
回答 – 図 2 のクエリを実行すれば、必要なデータを取得できます。
Figure 2 メモリの取得
With VASummary(Size,Reserved,Free) AS
(SELECT
Size = VaDump.Size,
Reserved = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
WHEN 0 THEN 0 ELSE 1 END),
Free = SUM(CASE(CONVERT(INT, VaDump.Base)^0)
WHEN 0 THEN 1 ELSE 0 END)
FROM
(
SELECT CONVERT(VARBINARY, SUM(region_size_in_bytes))
AS Size,
region_allocation_base_address AS Base
FROM sys.dm_os_virtual_address_dump
WHERE region_allocation_base_address <> 0x0
GROUP BY region_allocation_base_address
UNION
SELECT CONVERT(VARBINARY, region_size_in_bytes),
region_allocation_base_address
FROM sys.dm_os_virtual_address_dump
WHERE region_allocation_base_address = 0x0
)
AS VaDump
GROUP BY Size)
SELECT SUM(Size*Free)/1024 AS [Total avail mem, KB] ,CAST(MAX(Size) AS INT)/1024
AS [Max free size, KB]
FROM VASummary
WHERE Free <> 0
質問 – 対称キーを使って暗号化されたファイルに sa (システム管理者) パスワードを保存して、アプリケーションから簡単にデータベースを作成できるようにしたいのですが、これは可能でしょうか。
回答 – まず何より、sa は決してアプリケーションから使用しないでください。また、SQL Server 認証ではなく、Windows 認証を使用してください。
高いレベルの特権が必要な操作を実行する必要がある場合は、次のように処理してください。目的の操作の実行に必要最低限の権限を定義します。このような権限を含むデータベース ロールを定義します。このロールにユーザーを割り当てます。目的の機能を実行する Execute As 句を指定したストアド プロシージャを作成します。Execute As 句の説明については、msdn2.microsoft.com/ms188354.aspx を参照してください。
もちろん、問題のアカウントが sa アカウントであるかどうかにかかわらず、また Windows 認証が常に利用できるとは限らないことを考慮した場合に、より基本的な問題となるのは、SQL Server のログイン アカウントのパスワードを、このパスワードを使用する必要があるアプリケーションからはアクセスでき、権限のないユーザーやアプリケーションからはアクセスできないような形で、安全に保存するにはどうしたらよいかということです。
パスワードの暗号化は、方向性は正しくても、問題がパスワードの保護から暗号化キーの保護に代わっただけのことです。
これが Microsoft® .NET Framework ベースのアプリケーションの場合は、エンタープライズ ライブラリ (msdn2.microsoft.com/aa480453.aspx) および MSDN® の「パターンとプラクティス」(msdn.microsoft.com/practices) を参照してください。エンタープライズ ライブラリには、構成用のブロック、暗号化用のブロック、データ アクセス用のブロックなど、役立ちそうなアプリケーション ブロックがいくつかあります。これらは、(少なくとも) 安全にパスワードを保存するうえで有用なだけでなく、データ アクセス全般の管理にも役立ちます。
エンタープライズ ライブラリを使用できない場合 (.NET Framework を使用していない場合など) は、CryptoAPI (msdn2.microsoft.com/aa380255.aspx) を参照してください。この記事では、OS に組み込まれている中核となる暗号化機能について説明しています。この暗号化機能を使用すると、暗号化キーと、ユーザー プリンシパルやコンピュータを関連付けることができるため、(パスワードを暗号化した場合に問題となる) キーの管理が容易になります。
質問 – SQL Server 2000 ベースの 2 ノードのクラスタ サーバー (アクティブ/アクティブ構成、64 ビット ハードウェアを使用) を、同じフォレスト内のドメイン A からドメイン B に移行する必要があります。SQL Server データベースは、SAN 内に配置されています。Active Directory® アーキテクチャでは、空のルート ドメインの下に、2 つの子ドメイン (ドメイン A とドメイン B) を配置する必要があります。ドメイン B が、すべてのインフラストラクチャ コンポーネントの配置先となるドメインです。Windows Server® 2003 Enterprise 環境で、Windows 2000 を実行するドメイン コントローラが他にあります。
SQL Server クラスタ サーバーのメンバシップをドメイン A からドメイン B に変更することは可能でしょうか。
回答 – まず、「SQL Server 2000 フェールオーバー クラスタのドメインを変更する方法」および「Windows クラスタ サーバーをあるドメインから別のドメインに移動する方法」を参照してください。複数インスタンスのクラスタにも、同じプロセスを利用できます。唯一の違いは、必要に応じてインスタンスごとに手順を繰り返し実行しなければならないことです。クラスタのドメインの変更は、複雑な処理が必要になるため "推奨" されていませんが、頻繁に行われています。これ以外の方法としては、ご指摘のように、新しいインスタンスをサイド バイ サイドで構築し直して、データを移行する方法しかありません。
プロジェクトはそれぞれ異なり、実際のドメイン レベルの変更を行うためにはさまざまなツールが使用されます (セキュリティ上の考慮事項、アカウントの移行、SID マッピングなど)。変更自体よりも、プロセスのこの部分が最も難しくなることが多くあります。
**次の Microsoft IT 技術支援スタッフに心より感謝します。**Sunil Agarwal、Laurent Banon、Steve Bloom、Chad Boyd、Matt Burr、Shaun Cox、Cindy Gross、Bobby Gulati、Matt Hollingsworth、Arnost Kobylka、Mikhail Shir、Fernando Pessoa Sousa、Stephen Strong、Ramu Veeraraghavan。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.