SQL に関する Q&Aサマータイム、サーバー メモリ、その他
Nancy Michell
サマータイム
質問 - 米国では 2005 年エネルギー政策法 (Energy Policy Act of 2005) に準拠してサマータイム (DST) への変更が予定されていますが、SQL Server™ を更新する必要がありますか。
回答 - 必要ありません。現時点では、DST に変更できるようにするために必要な SQL Server 専用の更新プログラムはありません。時間に関連するデータについて、SQL Server は基盤となるオペレーティング システムに依存します。つまり、OS が正しい日付と時刻を報告していれば、SQL Server もその同じ値を報告し、使用します。DST への変更が予定されていますが、この変更に準拠するには、support.microsoft.com/kb/928388 にある概要のとおり Windows® を更新する必要があります。この更新は、DST 変更に準拠するために Windows Vista™ より前のすべての Windows オペレーティング システムで必要です (Vista にはこの変更が既に含まれています)。これには SQL Server を実行しているオペレーティング システムも含まれます (オーストラリアでも変更が発生しています。support.microsoft.com/kb/912475 を参照してください)。
Windows Vista に接続する
質問 - Windows Vista をインストールしたら、自分のシステムにある SQL Server 2005 に接続できません。私はローカル管理者ですが、以前は問題なくこの接続を行うことができました。どうしてでしょうか。
回答 - これは、Service Pack 2 (SP2) が適用されていない SQL Server 2005 と Windows Vista の組み合わせの場合に予期される動作です。Windows Vista には新しいセキュリティ モデルのユーザー アカウント制御が搭載されています。このモデルにより、ローカル管理者グループ内のあなたのメンバシップがトラップされ、管理者権限が必要な操作を確認するダイアログ ボックスが表示されます。[許可] ボタンをクリックすると、あなたの管理者トークンを含む資格情報がアプリケーションに送信されます。SQL Server Management Studio (SSMS) の場合、ダイアログ ボックスは表示されません。ツールを実行するだけであれば管理アクセス許可は必要ないためです。問題は、SQL Server 2005 システム管理者ロールには、オペレーティング システムのローカル管理者グループが既定で含まれていることです。あなたのアカウントでは、過去にこれを使用して SQL Server にアクセスしていたのです。Windows Vista ではこの許可は送信されないため、アクセスが許可されません。
Windows Vista では SP2 を適用していない SQL Server 2005 の実行はサポートされていないこと、また SP2 にはあなたのアカウントを追加するためのツールがあることに注意する必要があります。SP2 をまだインストールしていない場合でも、修正はとても簡単です。あなたの個人用 Windows ユーザー アカウントを SQL Server (あなたの場合はシステム管理者のロール) に追加する必要があります。追加するには、SQL Server Management Studio を右クリックして [管理者として実行] を選択します。SQL Server に接続してあなたの Windows アカウントをシステム管理者のロールに追加します。この設定の動作の詳細については、SQL Server Books Online を参照してください。
ビューを使用したトランザクションのレプリケーション
質問 - 使用している公開ビューを更新すると、トランザクションがレプリケートされることは知っています。このビューのベース テーブルを更新しても、トランザクションはレプリケートされますか。また、使用している公開テーブルのビューを作成してベース テーブルではなくこのビューを更新すると、トランザクションはレプリケートされますか。
回答 - ベース テーブルはパブリケーション内のアーティクルとして構成されている (つまり、ベース テーブルをレプリケーション向けにも構成している) と仮定しますが、ベース テーブルへの更新はすべてレプリケートされます。
ビューのレプリケート時は、既定では、ビューの一部としてレプリケートされるのは、ビューのスキーマ部分またはビューの背後にあるコードのみです。ビューの基になるデータはレプリケートされません (インデックス付きビューを使用していない場合)。したがって、レプリケートを行わなくても、ビューの更新時 (この場合は、ビューをターゲットとしてデータ操作言語 (DML) のステートメントを実行することを指します) はいつでも基になるテーブルのデータを更新しているだけであり、ビューは更新していません。ビューは、物理記憶域を持たないクエリ ステートメントの単なる論理記憶域です (ここでも、インデックス付きビューを使用していない場合)。
最大サーバー メモリ
質問 - 5GB の RAM を搭載し、Windows Server® 2003 と SQL Server 2000 を実行するコンピュータを所有しています。たとえば、/3GB スイッチを使用してユーザー モードの仮想アドレス空間を拡大し、/PAE スイッチで Windows カーネルの物理アドレス拡張 (PAE) バージョンを読み込み、そしてアドレス ウィンドウ化拡張 (AWE) の Enabled を 1 に設定するとします (そして、メモリ内のページのロックを有効にします)。AWE を有効にすると、最大サーバー メモリのオプションでデータ キャッシュのサイズだけが構成されますか。または、すべてのバッファ キャッシュ (データ、プロセス、セッションなど) のサイズが構成されますか。AWE でマッピングしたメモリを利用できるのはデータ キャッシュのみであるため、最大サーバー メモリを 4GB に構成しても、データ キャッシュは 1 GB (AWE によりマッピングされた部分) しか使用しないでしょうか。または、この追加の 1 GB を使用した上で、それ以上のメモリを使用し続けるかまたは標準アドレス空間にある他のメモリ コンシューマすべてと競合しますか。
回答 - 最大サーバー メモリは、常にバッファ プール サイズ全体を制限します。ただし、AWE によりマッピングされたメモリを使用できるのはデータ キャッシュだけです。
そのため最初の質問については、AWE が有効な状態であっても最大サーバー メモリはバッファ プール全体を制限しますが、データ キャッシュを行わないコンシューマが AWE によりマッピングされたメモリを使用することはありません。
2 番目の質問については、データ キャッシュは AWE によりマッピングされたメモリに加えて、SQL Server が適切と判断するバッファ プール内の他のメモリを使用します。つまり、データ キャッシュが使用するのは AWE メモリのみに限られません。ただし、データ キャッシュは AWE メモリを利用できる唯一のコンシューマなのです。/3GB スイッチの機能がわからない場合は、Raymond Chen のブログ (英語) を参照してください。
プロファイリングとパフォーマンス
質問 - SQL Server 2005 を運用環境でミラーリングしています。データベースを実行するマシンで SQL Server Profiler を開始し、トレース データをファイルに書き込むと、パフォーマンスが大幅に低下します。なぜでしょうか。
回答 - パフォーマンス低下の理由は、Profiler をどこで実行しているかによって異なります。Profiler をサーバー マシンで対話的に実行している場合、Profiler の UI がサーバーのメモリと CPU の両方を消費することで、パフォーマンスに影響を与えます。
Profiler をワークステーションで対話的に実行している場合、イベント情報をネットワーク内で移動させていることになり、スループットに影響を与えます。ミラーリングに使用しているネットワークと同じネットワーク内であれば、そのネットワークに対する影響もあります。また、プロファイラの出力をネットワーク共有に保存している場合、データをネットワーク内で移動させていることになり、パフォーマンスに悪影響があります。
これらの影響を軽減する最善の方法は、プロファイル対象のインスタンスを実行するサーバー上で Profiler を非対話的に実行し、出力をローカル ファイルにパイプすることでしょう。それでもサーバー リソースを消費し続けますが、通常この方法が最小の影響で済みます。この方法は、(メモリ内) Profiler トレースよりもうまく機能します。ファイル トレースではシステム メモリがさらに効果的に使用されます。バッファはより大きく、ディスクへのフラッシュもより効果的に行われます。また、ファイル トレースは、SQL Server Profiler のように外部プロセスには依存しません。
最終的には、トレース データは、Profiler がプロファイリングを行っている間にディスク ファイルに書き込まれます。トレース ファイルは、他の人がプロファイル データをリアルタイムにリモートで確認できるようにするため共有されています。トレース ファイルを対話的に呼び出すということは、Profiler を手動で呼び出して画面上の出力を見ていることになります。トレースは画面出力なしでプログラムにより作成できますから、非対話的に実行する方がよいでしょう。
また、ローカル ディレクトリ上に共有を作成すれば、他の人はそこにあるファイルにアクセスできます。これで通常問題ありません。前述のように、トレース出力をリモート共有上のファイルに書き込むのは良くありません。そのファイルがミラーリングに使用されるのと同じネットワーク パイプでアクセスされる場合は特にそうです。
また、調査に必要な最低限のイベントだけを選択する必要があります。トレース ファイルの場所については、システムで最速のドライブを選択してください (SQL Server データベースとトランザクション ログのドライブ以外が良いでしょう)。それでもパフォーマンスが大幅に低下する場合、イベントを複数のトレースに分け、それぞれを別個のハード ドライブに格納します。トレースの格納先が同じハード ドライブであっても、トレースごとに独自のバッファがあるため分割のメリットがあります。詳細については、SQL Server Books Online で sp_trace_create とその関連事項を確認してください。
クラスタリングの問題
質問 - SQL Server を Windows Server 2003 を実行するクラスタにインストールしようとしています。ですが毎回「クラスタ ノードで必要な操作を実行できませんでした。」というメッセージが表示されます。sqlstp.log には、ただ次のように記載されているだけです。
Script file copied to '\\SERVER01\ADMIN$\SERVER01_MSSQLSERVER.iss' successfully.
Installing remote service (SERVER01)...
An error occured in the service create (SERVER01): 1069...
どうしてでしょうか。
回答 - このエラーにはいくつかの理由が考えられます。セットアップでは、Windows NT® サービスが選択されたノードすべてにインストールされ、個々のマシンのセットアップ処理をリモートで管理します。したがって、発生する可能性のある多くの問題について知っておく必要があります。
まず、ドメイン アカウント ユーザーに対し、"サービスとしてログオン" 許可を拒否するグループ ポリシーがある可能性があります (ドメイン ポリシーは、ローカル マシン ポリシーより優先することを思い出してください)。こうした制限のないアカウントを使用していることを確認してください。
次に、セットアップの実行元マシンにログインしているアカウントに、すべてのノードに対する管理者アクセス許可がある必要があります。その理由は、マスタのセットアップ プロセスは、すべてのマシンのレジストリにリモートでアクセスできる必要があるためです。また、セットアップでは cnvsvc.exe をリモート マシンの Windows ディレクトリにコピーします。さらに、リモート マシンにアクセスするためにログイン済みのアカウントのアクセス許可のみを使用する標準 Windows API を使用するため、という理由もあります。これらの理由から、既定ですべてのノードに管理者としてログインする必要があります。
障害時復旧計画
質問 - SAP データベースの障害復旧 (DR) 戦略を実装するため、データベース ミラーリング (非同期モード) またはログ配布の使用を検討しています。運用環境と DR サイトには、100 Mb のミラーリング セッション専用ではないブロードバンド接続を使用します。この接続は、別のミラーリング セッションまたは別の DR サーバーと共有されます。
ログ レコードがミラー データベースに送信されなくなるネットワーク上の問題が発生した場合、再試行は行われますか。
ミラーリング セッションの中断中に、保存期間はありますか。そして、システム ビュー以外に、ミラーリング トラフィックとログ レコード送信の監視に使用できるログ情報はありますか。
回答 - まず質問にお答えします。データベース ミラーリングの再試行ロジックについては、2 つの面から考えることができます。第一に、一時的なネットワークの問題であれば、ミラーリング セッションは切断状態になります。既定のネットワーク タイムアウト値は 10 秒であり、ログ レコードをプリンシパル データベースからミラー データベースに送信できないことになります。このような場合、プリンシパルはミラーリングが行われない状態で実行し続け、トランザクションはクライアント側でコミットされます。ネットワークの問題が解決されると、ミラーリング セッションはユーザーの介入なしで自動的に再試行されます。ミラーリング セッションでは、ログ レコードを使用して遅れを取り戻そうとします。つまり、パートナーがまず同期を取り、遅れを取り戻したら同期状態となります。
第二に、再実行の問題の場合、ミラーリング セッションは中断状態になります。再実行の問題とは、ミラー データベースがそのデータベースのログ レコードをコミットできないことを指します。再実行の問題は、主に物理的ファイルが見つからない、または十分なディスク スペースがないなどで発生します。このような場合、プリンシパルはミラーリングが行われない状態で実行し続け、トランザクションはクライアント側でコミットされます。ミラー サーバー上で再実行の問題を手動で解決すると、ミラー セッションに介入して次のような操作が必要になります。
ALTER DATABASE <db> SET PARTNER RESUME;
保存期間については、回答は次のようになります。ミラー セッションが切断されているか中断されているかに関係なく、ログ レコードはセッションが復元されるまで保持されます。そして、セッションの中断から再開までの間に発生したすべてのレコードがミラーに保存されます。基本的に、ミラーリング セッションの切断中または中断中は、プリンシパルのログの切り捨てはできません。なぜなら切り捨てによりログの再実行チェーンが破壊されてしまうためです。この場合、プリンシパルのログがセッションの復元まで際限なく大きくなります。したがって、事実上ミラーリング セッションでは保存期間の制限がありませんが、現実的な制約は、プリンシパル サーバー上のログ保存用ディスク スペースだけです。というのも、ログが切り捨てられないためです。
最後に、ミラーリングの監視に利用できる特定のログ ファイルはありません。SQL Server 2005 では、データベース ミラーリング モニタという GUI ツールがこの目的で用意されています。このツールを使用すると、システム管理者は状態を表示および更新したり、いくつかの主要なパフォーマンス評価基準の警告しきい値を構成したりできます。これにより、ミラーリングが正常に実行されていない場合にアラートを表示できます。データベース ミラーリングに関するパフォーマンス上の主要な問題は、ログ レコードがタイミングよく処理されるかどうかということです。データベース ミラーリングの監視に関する詳細については、msdn2.microsoft.com/fr-fr/library/ms365781.aspx の記事「ミラーリングの状態の監視」を参照してください。
**技術的知識を提供してくれた次の Microsoft IT 技術支援スタッフの皆様に感謝します。**Chad Boyd、Sandu Chirica、Alan Doby、Kaloian Manassiev、Luciano Moreira、Ivan Penkov、Sivagaminathan Rajarethinam、Deborah To、Patrick Woodward、Buck Woody、Stanley Yau、Warren Young。
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; 許可なしに一部または全体を複製することは禁止されています.