SQL Q&A: Preventing Reboots, Installing Multiple Updates, and More

[アーティクル]
08/25/2016

Nancy Michell

再起動の防止

Q 一般に、修正プログラムなどを SQL Server やサーバーオペレーティングシステムに適用する際に、再起動の回数を制限する方法はありますか。

A まず、インストール後に行われるほとんどの再起動は、インストーラにハードコーディングされたものではないことを知っておくとよいでしょう。通常は、ファイルがロックされている場合に再起動が行われます。つまり、他のアプリケーションやオペレーティングシステムが現在使用 (ロック) しているファイルをインストーラが更新しようとしています。このような再起動を回避するには、問題のファイルを使用しているプロセスがないことを確認するだけです。では、これを行うにはどうすればよいでしょうか。

最初に、インストール中に使用されていたファイル、およびロックされたファイルを特定します。最も簡単な方法は、レジストリの HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations でこのようなファイルを探すことです。このレジストリキーを確認すると、2 つのことがわかります。1 つは本当にファイルがロックされていることが原因で再起動の要求が発生したかどうか、もう 1 つはどのファイルがロックされたのかということです。インストール後、再起動の前にこれらのキーを調べることにより、再起動が要求された原因を特定し、今後のインストールでその原因を取り除くための対策を講じることができる可能性があります。

表示されるエントリは 2 種類あります。ファイルに読み取りロックがかけられている場合は、ファイルごとに 1 行のエントリが表示されます。これは、更新されたファイルが既にディスク上に存在するが、そのファイルの一時コピーがまだ使用されているので削除する必要があることを示しています。ファイルに書き込みロックがかけられている場合は、ファイルごとに 2 行のエントリが表示されます。これは、更新がまだ行われておらず、アプリケーションの状態が不明であるため、ファイルを使用できないことを示しています。まさにセットアップが途中で停止されたことを示します。この場合、1 行は実際のファイル、もう 1 行は一時ファイル (再起動時に実際のファイルになります) を示しています。

次の手順は多くの要素に依存しますが、目的はロックされたファイルを使用しているソフトウェアを特定することです。可能な場合は、依存関係チェックツールを使用します。チェックツールがない場合は、MSDN® の DLL HELP データベース (support.microsoft.com/kb/815065 を参照) を使用します。

特定したソフトウェアにサービスが含まれている場合は、そのサービスを手動で停止してから再度テストを行います。アプリケーションの場合は、終了してから再度テストを行います。複数のアプリケーションが 1 つのファイルを使用していることもあるので、その場合はそれらのアプリケーションをすべて終了する必要があります。

これらの (テスト環境での) テストの結果、運用環境でインストールを実行する前に停止する必要があるアプリケーションとサービスの一覧が得られます。これで、インストーラがインストールするファイルをロックするソフトウェアが存在しなくなるので、運用環境では再起動が要求されません。もちろん、インストールが完了したらこれらのソフトウェアを再起動することを忘れないでください。

この解決策のメリットは、通常、ロックがそれほど変更されないということです。このため、一度システムのパターンを理解すれば、そのシステムを使用している間、多くの再起動を回避できます。

もう 1 つ紹介したい技があります。SQL Server™ や他の製品の複数のバージョンが並列インストールされていて、さらにこれらの製品間のバージョンレベルも異なる場合があります。更新は常に最新のバージョンから行う必要があります。この更新によってすべてのファイルが最新のバージョンに置き換えられ、他のすべてのインスタンスを更新する際にロックに関する問題が発生しなくなる可能性は高いと言えます。たとえば、SQL Server 2000 SP3 のインスタンスが 3 つある場合、1 つ目のインスタンスを SP4 にアップグレードすると MSXML3.dll ファイルがアップグレードされ、再起動が必要になります。ここで再起動を行ったとしましょう。これで MSXML3.dll ファイルが更新されるので、残りの 2 つのインスタンスを SP4 にアップグレードするときに再起動が不要になります。SQL Server 2000 インスタンスの前に SQL Server 2005 インスタンスをアップグレードした場合や、SQL Server 7.0 インスタンスの前に SQL Server 2000 インスタンスをアップグレードした場合も同じことが言えます。これは一般に再起動の回数を最小限に抑えるために使用される、非常に効果の高い方法です。

大きな枠組みで考えると、マイクロソフトの開発チームはさまざまな場面で再起動を回避したりその回数を制限するための研究を数多く行ってきました。今回は「SQL に関する Q&A」のコラムなので、SQL Server を例に挙げてみましょう。

SQL Server 2005 の開発時に、SQL Server チームは Microsoft® Data Access Components (MDAC) 全体を更新するのではなく、SQL Server に必要な MDAC のコードを新しい SQLNCLI ファイルに分離し、残りの MDAC を再度 OS に組み込みました。これがどのように役立つのでしょうか。Windows® オペレーティングシステム自体が MDAC を使用し、これらのファイルを常にロックしています。このため、SQL Server の Service Pack やその他のパッケージのインストール時には常に再起動が必要でした。SQL Server 2005 では、OS が使用している MDAC ファイルに対して処理を行うことなく SQL Server 2005 用の MDAC を更新するので、再起動が不要になります。

さらに、SQL Server 2005 SP1 セットアップには依存関係チェック機能と一時停止機能が組み込まれています。この機能により、ロックされているファイルとロックをかけている可能性が高いソフトウェアが表示され、再起動を行うことなくその場でロックを解除してセットアップを続行できます。つまり、テストラボでテストを行うことなくリアルタイムでロックに対処できます。もちろん、再起動が発生してもかまわない場合や無人モードで実行している場合など、単純に続行して再起動を行うことも常に可能です。この機能により、ファイルをロックしているソフトウェアの特定が非常に簡単になります。

また、Microsoft インストーラテクノロジによる既存の PendingFileRenameOperations (PFR) の処理も強化されました。SQL Server 2000 セットアップでは、上記で説明したレジストリキーにファイル名が追加されるとセットアップがブロックされることを思い出してください。SQL Server 2005 セットアップには、それらのファイルが SQL Server に属している (競合が発生している可能性がある) 場合のみセットアップをブロックするという優れた機能がありますが、そのような場合でも PFR キーを参照し、再起動を要求することなく直接それらのファイルを更新できる場合がほとんどです。このテクノロジは、現在あらゆる更新プログラムの実行に使用されている標準 Microsoft インストーラの MSI と update.exe の両方に、ある程度ではありますが含まれています。

再起動が行われることがわかっているファイルにはどのようなものがあるでしょうか。最大の原因になるファイルの 1 つが MSXML3.dll です。このファイルは常に Windows SVCHost サービスによってロックされるので、このサービスを含むコンピュータでは再起動が必要になります。またこのファイルは、ほとんどの MDAC スタック (mdac_typ.exe) にも含まれています。さいわい、MDAC は Windows Server® 2003 と Windows XP SP2 以降に含まれています。SQL Server 開発チームが msxmlsql.dll を分離するというすばらしい仕事をしたことによって、SQL Server の更新プログラムを適用するときの再起動はなくなりましたが、もうしばらくはときどき再起動が発生するでしょう。発生した場合の対策はありません。SVCHost を終了すると、更新プログラムを実行できなくなります。

また、update.exe パッケージのアンインストールプロセスでも特殊な動作が発生します。いずれかの update.exe パッケージをアンインストールすると、インストーラの配置済みファイルが (もちろん PFR キーの外部で) ロックされます。これにより、再起動を行ってそのロックを解除するまで他の update.exe パッケージを実行できなくなります。この場合は、この動作が発生することを承知して、修正プログラムのアンインストール後に再起動を計画するしかありません。

もう 1 つの問題は断続性です。すべてのプログラムが、実行中に常にファイルをロックしているわけではありません。実際、共有 DLL はほとんどの場合、特定の時点でしか使用されません。つまり、他のプログラムは負荷とコードパスに応じて、必要なときだけこれらのファイルにアクセスします。これは、10 回テストを行ってファイルがロックされなくても、運用環境への展開時にファイルがロックされる可能性があるということです。あいにく、この問題に対する効果的な解決策はありません。負荷 (少なくとも適切な目安) も含め、できるだけ運用環境に近いテスト環境を構築し、このような変化が発生しないように十分なテストを行ってください。

OS の Service Pack とアップグレードは再起動を必要とします。下位バージョン (Windows 2000、Windows XP などの以前のバージョン) では、pendingfilerenameoperations レジストリキーが空の場合でも、再起動が完了するまでインストールは完了しませんでした。この再起動中に、コードをインストールするための例外パッケージの登録操作が実行される場合があります。これらの操作は Service Pack のセットアップの一部ではなく、アップグレードシナリオによって起動される、現在のオペレーティングシステムの埋め込みコマンドです。これらのコマンドにより、現在使用している特定のコードをアップグレード後も使用できるようになります。

最後に、PFR キーはファイルのバージョンチェックを実行せず、シリアル化の順序も強制しません。つまり、リストに格納された順にファイルの置換が開始されます。しかし、ハードディスクに適用される順序は、最初に置換を開始したファイルが最初に適用されるのではなく、置換が最後に完了したファイルが最後に適用されます。これは理にかなっていますが、同じパスに同じファイルの 2 つのコピーがあり、それぞれが異なるバージョンを指している場合、再起動後の結果は一定ではありません。このような問題が発生した場合は、問題を解決する必要があります。問題があるかどうかがわからない場合は、単純に再起動後に両方のインストーラを実行します。正しいファイルが適用されている場合、追加操作は不要です。誤ったファイルが適用されている場合、正しいファイルを含むパッケージを実行すると問題は解決します。率直に言うと、必要な結果を考えるよりもこの方法を使用した方が時間がかからず、安全です。

複数の Service Pack のインストール

Q 4 ノードクラスタで 8 個のクラスタ化された SQL Server 2000 インスタンスを実行しており、最小限の再起動回数で SP4 をインストールすることを考えています。8 個のインスタンスすべてに SP4 を順番にインストールして、最後にすべてのノードを再起動することはできますか。

A 特定の Windows サーバー (クラスタ化されていない場合も含みます) に 1 つの SQL Server SP4 インスタンスを完全にインストールした後は、そのサーバー上にある他の SQL Server インスタンスに SQL Server SP4 をインストールしても再起動は行われません。これは、ツール、MDAC、MSXML など、すべての共有ファイルが既に正しいバージョンであり、ロックされていても、これ以上更新する必要がないためです。共有されていないすべてのファイルは、最初のインスタンスでのみ使用され、このインスタンスはセットアップによって停止されます。バージョンが異なる複数の SQL Server インスタンスを実行している場合、最も新しいインスタンスを最初に更新してください。

Network Service としての実行

Q NT AUTHORITY\NETWORK SERVICE アカウントとは何ですか。またその主な目的は何ですか。さらに、このアカウントに sysadmin (sa) 権限を与えた場合、セキュリティ面でどのような影響がありますか。

A ネットワーク上の Network Service アカウントの ID (コンピュータ ID) は System アカウントと同じですが、ローカルコンピュータに対する特権が System アカウントよりも制限されています。このため、あるサービスからネットワークリソースにアクセスする必要がある場合 (おそらくドメインコントローラでアカウント名を解決することが目的です)、System、ドメインアカウント、または Network Service で実行する必要があります。一般には、ローカルコンピュータのみを対象とし、特権が制限されている Network Service を使用した方が安全です。

Network Service を SQL Server の sysadmin に追加すると、ローカルコンピュータで Network Service として実行している他のすべてのサービスに、サーバーに対するフルコントロール権限が与えられます。この状況は、SQL Server サービスアカウントを Network Service で実行するように構成している場合などに発生します。サーバーの機能 (ループバック接続の許可など) を有効にするには、SQL Server サービスアカウントを sysadmin のメンバとして追加する必要があります。SQL Server で Network Service を管理者として実行するのはセキュリティ面から見てあまりよくありませんが、同じ目的にドメインアカウントを使用するよりは適切でしょう (適切でない場合もあります)。また、SQL Server を LocalSystem で実行するよりも安全です。

Network Service に sysadmin 特権を与えたくない場合、次に検討する選択肢は、1 つ以上の Windows NT® のインストールで SQL Server を実行するときに専用のドメインアカウントを使用する方法です。

次の記事に関連情報が記載されています。microsoft.com/japan/msdn/enterprise/pag/securityguidance/paght000009.aspx と microsoft.com/technet/security/topics/serversecurity/serviceaccount (英語) を参照してください。

複数のデータベースの作成

Q データを複数のデータベースに分割し、最大 250 個ぐらいのデータベースを同時にオンラインにすることを考えています。アクティブなクエリに使用できるデータベースは、いずれの時点でも 20% のみであると予想しています。データベースの数を増やすメリットはありますか。

A 1 つのデータベースサーバーインスタンスに配置するデータベースの数は、ビジネスニーズと管理上の要素に応じて決定する必要があります。1 つのサーバーインスタンスに複数のデータベースを作成する際のオーバーヘッドはほとんどありませんが、データベースの数が増えると、バックアップと復元、ミラーリング、ユーザーアカウント、ユーザーロールなどのメンテナンスタスクにかかる管理オーバーヘッドが増加します。管理上の複雑さが増すことにより、データベースを追加するメリットが相殺される可能性があります。

一般的な規則としては、1 つのアプリケーションに関連するデータは、障害からの復旧を容易にするために、すべて 1 つのデータベースに格納しておきます。アプリケーションのデータが複数のデータベースに分散した場合、フェールオーバー中にすべてのデータベースを復旧する必要があります。この場合、復旧が遅れるだけでなく、復旧できないデータベースがあった場合は復旧自体が失敗します。

そうは言うものの、次のようにデータを複数のデータベースに分散させる理由もあります。

データのサブセットのバックアップ要件が他のデータと異なる。
特定のデータに、異なるデータベース所有者などの別のセキュリティコンテキストが必要である。
データを格納する目的が履歴の保存であり、読み取り専用モードでデータを保持する必要がある。

**技術的知識を提供してくれたマイクロソフトの次の IT Pro に感謝します。**Ramon Arjona、Frank De Waelle、Robert Djabarov、Herman Learmond-Criqui、Maxwell Myrick、Ruslan Ovechkin、Uttam Parui、Shashi Ramaka、Gary Roos、Gavin Sharpe、Vijay Sirohi、Jimmie Thompson、Madhusudhanan Vadlamaani。

Nancy Michell

次の方法で共有

その他のリソース