SQL Server 2019のMax Memory設定が再起動後に自動変更される原因と対処法

SQL Server 2019を運用していると、思わぬタイミングでメモリ設定が変更されてしまう場合があります。特に「Max Memory」を意図した値にしても再起動後に別の値になっていると、パフォーマンス管理やリソース割り当てに支障をきたす恐れがあります。この記事では、再起動後にSQL ServerのMax Memory設定が自動変更されてしまう原因と、その具体的な対処方法を詳しく解説します。

SQL Serverのメモリ管理の基本

SQL Serverは、デフォルトの状態ではサーバーの物理メモリを可能な限り活用しようとします。しかし、他のアプリケーションを同時に動作させる場合や、ハードウェアリソースを最適に配分したい場合などは、sp_configureを用いて「Max Memory（max server memory）」や「Min Memory（min server memory）」を設定し、使用可能メモリの範囲を制限するのが一般的です。

Max MemoryとMin Memoryの概要

max server memory (MB): SQL Serverが使用できるメモリの上限をMB単位で指定します。これ以上のメモリをSQL Serverが使用しないように制限します。
min server memory (MB): SQL Serverが確保しようとするメモリの下限値をMB単位で指定します。SQL Serverはこの値を下回らないようにメモリを確保しようとします。

一般的には、OSや他のアプリケーションに必要なメモリを差し引いた残りのメモリを上限として設定することで、必要以上にSQL Serverがメモリを独占するのを防ぎます。設定の際は、以下のような手順を実行します。

USE master;
GO

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO

EXEC sp_configure 'max server memory (MB)', 16384; -- 例: 16GBをMB換算
RECONFIGURE;
GO

上記の設定を行い、SQL Serverを再起動しても通常は設定が保持されるはずです。しかし、再起動後に勝手に設定値が変わってしまうケースが報告されることがあります。

Max Memory設定を変更しても再起動後に戻ってしまう原因

SQL Server 2019で、たとえば「Max Memory」を16GBに設定しても再起動すると24GBに変わってしまう場合、いくつかの要因が考えられます。ここでは、代表的な原因を洗い出してみましょう。

自動化スクリプトやジョブの影響

サーバー起動時やSQL Serverサービス起動時に実行されるスクリプトやタスクが存在すると、再起動後に意図しない構成が適用されることがあります。特に大規模な環境では、以下のような仕組みで設定が自動的に上書きされるケースが多いです。

SQL Serverエージェントジョブ: サービス起動後に自動実行されるジョブが含まれている。
Windowsのタスクスケジューラ: サーバー再起動時に設定ファイルやスクリプトを呼び出している。
スタートアップスクリプト: Windowsの起動時に実行されるスクリプトでSQL Serverの構成を変更している。

これらのジョブやスクリプトを確認し、Max Memoryを変更している箇所がないかを調べることが必要です。

構成管理ツールやグループポリシーによる強制適用

企業や組織のITインフラでは、サーバーの設定を一括管理するためにChef、Puppet、Ansibleなどの構成管理ツールを導入している場合があります。また、Active Directoryのグループポリシー（GPO）を用いてポリシーレベルで設定を強制しているケースも考えられます。これらの管理ツールやポリシーがSQL Server構成を保持しようとすると、再起動時に「正しい」値（ツールやポリシーで定義されている値）に上書きされることがあります。

クラウドやマネージドサービス特有の設定

Azure Virtual Machineなどのクラウド環境上でSQL Serverを運用している場合、プラットフォームのベストプラクティスに基づく自動調整機能がオンになっていることがあります。特にAzure SQL DatabaseやAzure SQL Managed Instanceなどのマネージドサービスでは、ユーザーが意図せずともメモリなどの構成が変更されることがあるため、クラウドサービス側のドキュメントを確認する必要があります。

複数インスタンスやクラスタ構成による影響

1台のサーバーに複数のSQL Serverインスタンスが存在する場合、インスタンスごとに設定を管理する必要があります。誤って別のインスタンスにログインして設定を変更していたり、クラスタ環境下でフェールオーバーが発生した際に設定が共有されておらず、思わぬタイミングで別の値が適用されることも起こり得ます。

SQL Serverのスタートアップ構成（スタートアッププロシージャ等）の影響

SQL Serverには、インスタンスが起動する際に自動的に実行できるスタートアッププロシージャを登録することができます。これは通常の運用ではあまり使われない機能ですが、過去の設定でスタートアッププロシージャを作成している場合、そこにsp_configureの実行を含めていることがあります。忘れられたスタートアッププロシージャが原因で、再起動時にMax Memoryが書き換わってしまうケースもあります。

具体的な調査手順

原因を特定するには、以下のような段階的な手順で調査を進めると効果的です。

1. 現在の構成値を確認する

まずはOSが起動し、SQL Serverサービスが立ち上がった直後にsp_configureを使って現在の「max server memory (MB)」の値をチェックします。以下のコマンドで確認可能です。

USE master;
GO

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
GO

EXEC sp_configure 'max server memory (MB)';
GO

ここで表示される「run value」が、実際に反映されている設定値です。これが想定外の値になっていれば、何らかのプロセスや仕組みによって書き換えが行われている可能性があります。

2. エラーログやイベントログの確認

SQL ServerのエラーログおよびWindowsのイベントビューア（システム、アプリケーションログ）を確認し、SQL Server起動時に関連するメッセージや警告、エラーが記録されていないかを調べます。特に「Server memory configuration」のような文言が含まれるログや、ジョブの実行を示すメッセージがないかを注意深くチェックしましょう。

3. SQL Serverエージェントジョブやタスクスケジューラの確認

SQL Serverエージェントが稼働している場合は、SQL Serverエージェントのジョブをすべて確認し、起動時やサービス開始時に実行されるステップが含まれていないかを調べます。Windowsタスクスケジューラに関しても「サーバー起動時」にスクリプトを実行しているタスクが存在しないかを確認してください。

4. 構成管理ツールやグループポリシーの確認

システムがActive Directoryドメインの一員になっている場合は、ドメインコントローラーやグループポリシー管理コンソールでポリシーを確認します。特に「ログオンスクリプト」や「スタートアップスクリプト」などに設定がないかを探します。また、ChefやPuppet、Ansibleなどの構成管理ツールを導入している場合は、該当サーバー用のレシピやプレイブック、マニフェストをチェックし、SQL Serverに関連する設定がないかを調べてください。

5. スタートアッププロシージャの確認

SQL Serverでスタートアッププロシージャが有効になっている場合は、以下のように設定を確認できます。

SELECT  *
FROM    sys.configurations
WHERE   name = 'scan for startup procs';

上記で「run_value」が1になっていればスタートアッププロシージャが有効化されています。さらに、以下のクエリで実際に登録されているスタートアッププロシージャを確認します。

SELECT  p.name AS procedure_name,
        m.definition
FROM    sys.procedures p
JOIN    sys.sql_modules m
ON      p.object_id = m.object_id
WHERE   p.is_auto_executed = 1;

もしここでsp_configureによるメモリ設定の変更が書かれているプロシージャが見つかった場合は、それが原因になっている可能性が高いです。

具体的な対処策

ここでは、考えられる主な要因と対処策をまとめた表を示します。

要因	症状	対処策
自動化スクリプトやジョブの存在	再起動直後に設定が意図せず上書きされる	スクリプト・ジョブの内容を見直し、不要なら削除または修正
構成管理ツール (Chef, Puppet, Ansibleなど)	サーバーが起動するたびにツールにより設定が適用される	ツール側のレシピ・プレイブックを確認しSQL Serverの設定を修正
グループポリシー	GPOのスタートアップスクリプトなどでSQL設定を上書き	ドメインコントローラーでポリシーを確認し、修正あるいは除外
複数インスタンスやクラスタ構成	実際には別のインスタンス設定を変更していたり、フェールオーバーで設定が切り替わる	対象となるインスタンスを明確にし、クラスタ・レジストリの設定も確認
スタートアッププロシージャ	SQL Server起動時に自動実行され、Max Memoryが再設定される	不要なスタートアッププロシージャを削除または修正

具体的な対処は、上述の調査で発見した原因に合わせて行います。以下は、代表的な対処例です。

対処例1: SQL Serverエージェントジョブの無効化または修正

もし、SQL Serverエージェントジョブが原因でMax Memoryが書き換えられている場合は、そのジョブを無効化するか、ジョブステップから該当のsp_configure実行ステートメントを削除して修正します。ジョブの実行スケジュールも「サービス起動時」になっていないかを確認しましょう。

対処例2: 構成管理ツールの設定変更

ChefやPuppet、Ansibleなどを利用している場合は、設定ファイルやレシピの中でsp_configureが実行されていないかをチェックします。もしSQL Serverのメモリ設定を規定値に戻すような構成が入っていれば、その箇所をコメントアウトまたは修正してください。また、一括管理が必要な場合でも、サーバーごとのメモリ要件を考慮した設定を作成することをおすすめします。

対処例3: グループポリシーの修正または除外

Active DirectoryのGPO（スタートアップスクリプトなど）によって設定が適用されている場合は、ドメインコントローラーでポリシーの内容を確認し、SQL Serverのメモリ設定にかかわるスクリプトやレジストリ変更が含まれていないかを調べましょう。必要であれば、そのサーバーをポリシーの適用対象外にするか、該当のスクリプトを修正・削除します。

対処例4: スタートアッププロシージャの削除

スタートアッププロシージャが原因であれば、先に紹介したクエリで特定し、以下のコマンドで自動実行設定を解除します。

ALTER PROCEDURE dbo.YourStartupProc
WITH EXECUTE AS CALLER
AS
BEGIN
    -- ここに書かれているsp_configure実行などを削除
END
GO

-- もしくはプロシージャ自体を削除
DROP PROCEDURE dbo.YourStartupProc;
GO

-- スタートアッププロシージャのスキャンをオフにする
EXEC sp_configure 'scan for startup procs', 0;
RECONFIGURE;
GO

実際には、スタートアッププロシージャを完全に削除する代わりに、sp_configureを実行する部分のみ削除して用途を絞るなどの方法も考えられます。

対処例5: 複数インスタンスやクラスタの設定整合性の確認

1台のサーバーに複数のSQL Serverインスタンスがある場合は、対象インスタンスごとに正しいポート番号とインスタンス名でログインし、sp_configureを実行して設定値を確認してください。また、クラスタ環境（Always On可用性グループやFailover Cluster Instanceなど）の場合は、フェールオーバー後に設定が同期される仕組みになっているか、レジストリやクラスタ構成が正しく反映されているかを調べましょう。

運用時のベストプラクティス

Max Memoryの再設定が想定外に行われるのは、環境管理の見落としや複雑化が一因になることが多いです。以下のベストプラクティスを取り入れて、より安定した運用を実現しましょう。

1. 運用ドキュメントの整備

サーバーのスタートアップ時にどのようなスクリプトが走るのか、どのような構成管理ツールがどのサーバーに適用されているのかを整理し、ドキュメント化しておきましょう。担当者が変わった際やトラブル時にもスムーズに追跡が可能となります。

2. バージョン管理ツールの活用

インフラストラクチャをコード（Infrastructure as Code）で管理する場合、Gitなどのバージョン管理ツールを活用することで、「いつ」「誰が」「どのような」変更を加えたのかを追跡しやすくなります。ChefやPuppetのレシピ、Ansibleのプレイブックもすべてリポジトリで管理することで、変更の履歴が一目瞭然となります。

3. リソースモニタリングと通知

Max Memoryが意図せず変更された結果、SQL Serverのパフォーマンスに影響が出ることがあります。監視ツールやSQL ServerのNative Monitoring（SQL Server Management Studioでも利用可能）を使って、メモリ使用量やページングの発生状況、待機イベントなどをモニタリングし、異常があればすぐに通知されるように仕組みを作っておきましょう。

4. 定期的な構成レビュー

組織で管理対象のサーバーが増えるほど、「いつのまにか古いスクリプトが残っていた」という事態が起こりやすくなります。定期的に構成をレビューし、不要になったジョブやスクリプト、ポリシーを整理することで、トラブルの防止に役立ちます。

まとめ

SQL Server 2019の「Max Memory」設定が再起動後に意図せず変更されてしまう問題の多くは、サーバーやSQL Serverの起動時に実行されるスクリプトや構成管理ツールなどによる自動再設定が原因である場合がほとんどです。
これを解決するためには、まずは現在の構成状態を調べ、エラーログやイベントログで手がかりを探すことから始めます。次に、SQL Serverエージェントジョブ、タスクスケジューラ、スタートアッププロシージャ、構成管理ツール、グループポリシーなどを順番に確認し、不要または間違った設定を特定して修正していきましょう。
さらに、複数インスタンスやクラスタを使用している場合は、インスタンスやクラスタごとに設定の整合性を確かめることが大切です。運用ドキュメントの整備やバージョン管理ツールの活用、監視体制の強化、定期的な構成レビューを組み合わせることで、予期せぬメモリ設定の変更を防止し、安定したSQL Server環境を築くことができます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。