mssql-conf ツールを使用して SQL Server on Linux を構成する

適用対象: SQL Server - Linux

使用上のヒント

• Always On 可用性グループと共有ディスク クラスターの場合は、常に、各ノードで同じ構成の変更を行います。

• 共有ディスク クラスターのシナリオでは、変更を適用するために mssql-server サービスを再起動しないでください。 SQL Server がアプリケーションとして実行されています。 代わりに、リソースをオフラインにしてからオンラインに戻します。

• これらの例では、完全なパス (/opt/mssql/bin/mssql-conf) を指定して mssql-conf を実行しています。 代わりにそのパスに移動する場合は、現在のディレクトリ (./mssql-conf) のコンテキストで mssql-conf を実行します。

• コンテナー内の mssql.conf ファイルを変更する場合は、目的の設定でコンテナーを実行しているホスト上に mssql.conf ファイルを作成し、コンテナーを再デプロイします。 たとえば、mssql.conf ファイルに次を追加すると、SQL Server エージェントが有効になります。

  [sqlagent]
  enabled = true
  

  次のコマンドを使用してコンテナーをデプロイできます。

  docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<YourStrong@Passw0rd>" \
  -p 5433:1433 --name sql1 \
  -v /container/sql1:/var/opt/mssql \
  -d mcr.microsoft.com/mssql/server:2019-latest
  

  詳細については、「SQL Server コンテナーによって使用される構成ファイルを作成する」を参照してください。

SQL Server エージェントを有効にする

sqlagent.enabled の設定では、SQL Server エージェントを有効にします。 既定では、SQL Server エージェントは無効になっています。 sqlagent.enabled が mssql.conf 設定ファイルに存在しない場合、SQL Server では内部的に、SQL Server エージェントが無効になっていると見なします。

この設定を変更するには、次の手順を実行します。

1. SQL Server エージェントを有効にします。

   sudo /opt/mssql/bin/mssql-conf set sqlagent.enabled true
   

2. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

SQL Server on Linux の既定のデータベース メール プロファイルを設定する

sqlagent.databasemailprofile を使用すると、メール アラートの既定の DB メール プロファイルを設定できます。

sudo /opt/mssql/bin/mssql-conf set sqlagent.databasemailprofile <profile_name>

SQL Agent のエラー ログ

sqlagent.errorlogfile と sqlagent.errorlogginglevel の設定を使用すると、それぞれ、SQL Agent のログ ファイル パスとログ レベルを設定できます。

sudo /opt/mssql/bin/mssql-conf set sqlagent.errorlogfile <path>

SQL Agent のログ レベルは、次の値と等しいビットマスク値です。

• 1 = エラー
• 2 = 警告
• 4 = 情報

すべてのレベルをキャプチャする場合は、値として 7 を使用します。

sudo /opt/mssql/bin/mssql-conf set sqlagent.errorlogginglevel <level>

Microsoft Entra 認証を構成する

SQL Server 2022 (16.x) 以降では、SQL Server 用の Microsoft Entra ID を構成できます。 Microsoft Entra ID を構成するには、SQL Server のインストール後に、SQL Server 用の Azure 拡張機能をインストールする必要があります。 Microsoft Entra ID を構成する方法については、「チュートリアル: SQL Server 用に Microsoft Entra 認証を設定する」を参照してください。

既定の Microsoft Entra ID 証明書パスを変更

既定では、Microsoft Entra 証明書ファイルは /var/opt/mssql/aadsecrets/ に格納されます。 証明書ストアまたは暗号化されたドライブを使う場合は、このパスを変更できます。 パスを変更するには、次のコマンドを使います。

sudo /opt/mssql/bin/mssql-conf set network.aadcertificatefilepath /path/to/new/location.pfx

前の例の /path/to/new/location.pfx は、証明書名を "含む" 任意のパスです。

SQL Server 用 Azure 拡張機能によってダウンロードされた Microsoft Entra 認証のための証明書は、この場所に格納されます。 これは /var/opt/mssql/secrets には変更できません。

Microsoft Entra ID の構成オプション

次のオプションは、Linux 上で動作する SQL Server のインスタンスに対する Microsoft Entra 認証で使用されます。

Windows Active Directory 認証を構成する

setup-ad-keytab オプションを使用して keytab を作成できますが、このオプションを使用するには、ユーザーとサービス プリンシパル名 (SPN) が作成されている必要があります。 Active Directory ユーティリティ、adutil を使用して、ユーザー、SPN、および keytab を作成できます。

setup-ad-keytab の使用に関するオプションについては、次のコマンドを実行します。

sudo /opt/mssql/bin/mssql-conf setup-ad-keytab --help

validate-ad-config オプションは、Active Directory 認証の構成を検証します。

SQL Server の照合順序を変更する

set-collation オプションは、照合順序の値を、サポートされている任意の照合順序に変更します。 この変更を行うには、SQL Server サービスを停止する必要があります。

1. 最初に、サーバー上のすべてのユーザー データベースをバックアップします。

2. 次に、sp_detach_db ストアド プロシージャを使用してユーザー データベースをデタッチします。

3. set-collation オプションを実行し、画面の指示に従います。

   sudo /opt/mssql/bin/mssql-conf set-collation
   

4. mssql-conf ユーティリティにより、指定された照合順序の値への変更とサービスの再開が試みられます。 エラーが発生した場合は、照合順序が前の値にロールバックされます。

5. ユーザー データベースのバックアップを復元します。

サポートされている照合順序の一覧については、sys.fn_helpcollations 関数: SELECT Name from sys.fn_helpcollations() を実行してください。

カスタマー フィードバックを構成する

telemetry.customerfeedback 設定により、SQL Server が Microsoft にフィードバックを送信するかどうかが変更されます。 既定では、この値はすべてのエディションで true に設定されます。 値を変更するには、次のコマンドを実行します。

1. telemetry.customerfeedback の set コマンドを使って、mssql-conf スクリプトを root として実行します。 次の例では、false を指定することによってカスタマー フィードバックをオフにします。

   sudo /opt/mssql/bin/mssql-conf set telemetry.customerfeedback false
   

2. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

詳細については、「SQL Server on Linux の使用状況と診断データの収集を構成する」および「SQL Server のプライバシーの補足情報」を参照してください。

既定のデータまたはログのディレクトリの場所を変更する

filelocation.defaultdatadir と filelocation.defaultlogdir の設定により、新しいデータベース ファイルとログ ファイルが作成される場所が変更されます。 既定では、この場所は /var/opt/mssql/data です。 これらの設定を変更するには、次の手順を実行します。

1. 新しいデータベースのデータ ファイルとログ ファイルのターゲット ディレクトリを作成します。 次の例では、新しい /tmp/data ディレクトリを作成します。

   sudo mkdir /tmp/data
   

2. ディレクトリの所有者とグループを mssql ユーザーに変更します。

   sudo chown mssql /tmp/data
   sudo chgrp mssql /tmp/data
   

3. mssql-conf を使用して、set コマンドで既定のデータ ディレクトリを変更します。

   sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdatadir /tmp/data
   

4. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

5. これで、新しく作成されたデータベースのすべてのデータベース ファイルが、この新しい場所に格納されました。 新しいデータベースのログ (.ldf) ファイルの場所を変更する場合は、次の set コマンドを使用できます。

   sudo /opt/mssql/bin/mssql-conf set filelocation.defaultlogdir /tmp/log
   

6. このコマンドは、/tmp/log ディレクトリが存在し、ユーザーとグループ mssql の下にあることも前提としています。

既定の master データベース ファイルのディレクトリの場所を変更する

filelocation.masterdatafile と filelocation.masterlogfile の設定により、SQL Server データベース エンジンが master データベース ファイルを検索する場所が変更されます。 既定では、この場所は /var/opt/mssql/data です。

これらの設定を変更するには、次の手順を実行します。

1. 新しいエラー ログ ファイルのターゲット ディレクトリを作成します。 次の例では、新しい /tmp/masterdatabasedir ディレクトリを作成します。

   sudo mkdir /tmp/masterdatabasedir
   

2. ディレクトリの所有者とグループを mssql ユーザーに変更します。

   sudo chown mssql /tmp/masterdatabasedir
   sudo chgrp mssql /tmp/masterdatabasedir
   

3. mssql-conf を使用して、set コマンドで master データ ファイルとログ ファイルの既定のマスター データベース ディレクトリを変更します。

   sudo /opt/mssql/bin/mssql-conf set filelocation.masterdatafile /tmp/masterdatabasedir/master.mdf
   sudo /opt/mssql/bin/mssql-conf set filelocation.masterlogfile /tmp/masterdatabasedir/mastlog.ldf
   

   Note

   マスター データ ファイルとログ ファイルを移動するだけでなく、他のすべてのシステム データベースの既定の場所も移動します。

4. SQL Server サービスを停止します。

   sudo systemctl stop mssql-server
   

5. master.mdf および mastlog.ldf ファイルを移動します。

   sudo mv /var/opt/mssql/data/master.mdf /tmp/masterdatabasedir/master.mdf
   sudo mv /var/opt/mssql/data/mastlog.ldf /tmp/masterdatabasedir/mastlog.ldf
   

6. SQL Server サービスを開始します。

   sudo systemctl start mssql-server
   

   Note

   SQL Server で指定されたディレクトリに master.mdf ファイルと mastlog.ldf ファイルが見つからない場合は、指定されたディレクトリにシステム データベースのテンプレート化されたコピーが自動的に作成され、SQL Server が正常に起動します。 ただし、ユーザー データベース、サーバー ログイン、サーバー証明書、暗号化キー、SQL エージェント ジョブ、古い SA ログイン パスワードなどのメタデータは、新しい master データベースでは更新されません。 引き続き既存のメタデータを使うには、SQL Server を停止して、古い master.mdf と mastlog.ldf を指定した新しい場所に移動し、SQL Server を起動する必要があります。

master データベース ファイルの名前を変更する

filelocation.masterdatafile と filelocation.masterlogfile の設定により、SQL Server データベース エンジンが master データベース ファイルを検索する場所が変更されます。 これを使用して、master データベース ファイルとログ ファイルの名前を変更することもできます。

これらの設定を変更するには、次の手順を実行します。

1. SQL Server サービスを停止します。

   sudo systemctl stop mssql-server
   

2. mssql-conf を使って、set コマンドで master データ ファイルとログ ファイルの master データベースに想定される名前を変更します。

   sudo /opt/mssql/bin/mssql-conf set filelocation.masterdatafile /var/opt/mssql/data/masternew.mdf
   sudo /opt/mssql/bin/mssql-conf set filelocation.mastlogfile /var/opt/mssql/data/mastlognew.ldf
   

   重要

   master データベース ファイルとログ ファイルの名前は、SQL Server が正常に起動された後でのみ変更できます。 SQL Server では、最初の実行まではファイルの名前が master.mdf と mastlog.ldf であると想定されます。

3. master データベースのデータ ファイルとログ ファイルの名前を変更します。

   sudo mv /var/opt/mssql/data/master.mdf /var/opt/mssql/data/masternew.mdf
   sudo mv /var/opt/mssql/data/mastlog.ldf /var/opt/mssql/data/mastlognew.ldf
   

4. SQL Server サービスを開始します。

   sudo systemctl start mssql-server
   

既定のダンプ ディレクトリの場所を変更する

filelocation.defaultdumpdir の設定により、クラッシュが発生するたびにメモリと SQL ダンプが生成される既定の場所が変更されます。 既定では、これらのファイルは /var/opt/mssql/log 内に生成されます。

この新しい場所を設定するには、次のコマンドを使用します。

1. 新しいダンプ ファイルのターゲット ディレクトリを作成します。 次の例では、新しい /tmp/dump ディレクトリを作成します。

   sudo mkdir /tmp/dump
   

2. ディレクトリの所有者とグループを mssql ユーザーに変更します。

   sudo chown mssql /tmp/dump
   sudo chgrp mssql /tmp/dump
   

3. mssql-conf を使用して、set コマンドで既定のデータ ディレクトリを変更します。

   sudo /opt/mssql/bin/mssql-conf set filelocation.defaultdumpdir /tmp/dump
   

4. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

既定のエラー ログ ファイルのディレクトリの場所を変更する

filelocation.errorlogfile の設定により、新しいエラー ログ、既定のプロファイラー トレース、システム正常性セッション XE ファイル、および Hekaton セッション XE ファイルが作成される場所が変更されます。 既定では、この場所は /var/opt/mssql/log です。 SQL Server のエラー ログ ファイルが設定されているディレクトリが、他のログの既定のログ ディレクトリになります。

これらの設定を変更するには、次の操作を行います。

1. 新しいエラー ログ ファイルのターゲット ディレクトリを作成します。 次の例では、新しい /tmp/logs ディレクトリを作成します。

   sudo mkdir /tmp/logs
   

2. ディレクトリの所有者とグループを mssql ユーザーに変更します。

   sudo chown mssql /tmp/logs
   sudo chgrp mssql /tmp/logs
   

3. mssql-conf を使って、set コマンドでの既定のエラー ログ ファイル名を変更します。

   sudo /opt/mssql/bin/mssql-conf set filelocation.errorlogfile /tmp/logs/errorlog
   

4. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

errorlog.numerrorlogs の設定を使用すると、ログを循環するまでに保持されるエラー ログの数を指定できます。

既定のバックアップ ディレクトリの場所を変更する

filelocation.defaultbackupdir の設定により、バックアップ ファイルが生成される既定の場所が変更されます。 既定では、これらのファイルは /var/opt/mssql/data 内に生成されます。

この新しい場所を設定するには、次のコマンドを使用します。

1. 新しいバックアップ ファイルのターゲット ディレクトリを作成します。 次の例では、新しい /tmp/backup ディレクトリを作成します。

   sudo mkdir /tmp/backup
   

2. ディレクトリの所有者とグループを mssql ユーザーに変更します。

   sudo chown mssql /tmp/backup
   sudo chgrp mssql /tmp/backup
   

3. mssql-conf を使って、set コマンドでの既定のバックアップ ディレクトリを変更します。

   sudo /opt/mssql/bin/mssql-conf set filelocation.defaultbackupdir /tmp/backup
   

4. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

コア ダンプ設定を指定する

SQL Server のいずれかのプロセスで例外やクラッシュが発生した場合、SQL Server によってメモリ ダンプが作成されます。 メモリ ダンプのキャプチャには時間がかかったり、大きなスペースを占めたりする場合があります。 リソースを節約し、メモリ ダンプの繰り返しを回避するために、coredump.disablecoredump オプションを使って自動的なダンプのキャプチャを無効にすることができます。

sudo /opt/mssql/bin/mssql-conf set coredump.disablecoredump <true or false>

自動コア ダンプが無効になっている (coredump.disablecoredump が true に設定されている) 場合でも、ユーザーは手動でメモリ ダンプを生成できます。

SQL Server によって収集されるメモリ ダンプの種類を制御するための 2 つのオプション (coredump.coredumptype と coredump.captureminiandfull) があります。 これらは、コア ダンプ キャプチャの 2 つのフェーズに関連しています。

最初のフェーズのキャプチャは、例外の発生時に生成されるダンプ ファイルの種類を決定する coredump.coredumptype 設定によって制御されます。 2 番目のフェーズは、coredump.captureminiandfull の設定時に有効になります。 coredump.captureminiandfull が true に設定されている場合は、coredump.coredumptype によって指定されたダンプ ファイルが生成され、2 番目のミニ ダンプも生成されます。 coredump.captureminiandfull を false に設定すると、2 回目のキャプチャの試行が無効になります。

1. coredump.captureminiandfull の設定を使用して、ミニ ダンプと完全ダンプを両方ともキャプチャするかどうかを決定します。

   sudo /opt/mssql/bin/mssql-conf set coredump.captureminiandfull <true or false>
   

   既定値: false

2. coredump.coredumptype の設定を使用して、ダンプ ファイルの種類を指定します。

   sudo /opt/mssql/bin/mssql-conf set coredump.coredumptype <dump_type>
   

   既定値: miniplus

   次の表は coredump.coredumptype で指定できる値です。

   Type	説明
   mini	mini は、最も小さいダンプ ファイルの種類です。 これは、Linux システム情報を使用して、プロセス内のスレッドとモジュールを特定します。 ダンプには、ホスト環境のスレッド スタックとモジュールのみが含まれます。 間接的なメモリ参照またはグローバルは含まれません。
   miniplus	miniplus は mini に似ていますが、追加のメモリが含まれています。 これは、SQLPAL とホスト環境の内部構造を認識して、次のメモリ領域をダンプに追加します。 - さまざまなグローバル - 64 TB を超えるすべてのメモリ - /proc/$pid/maps で見つかったすべての名前付きリージョン - スレッドとスタックからの間接メモリ - 関連付けられたスレッド環境ブロック (TEB) とプロセス環境ブロック (PEB) を含むスレッド情報 - モジュール情報 - VMM および VAD ツリー
   filtered	filtered では、明示的に除外しない限りプロセス内のすべてのメモリが含まれる、減算ベースの設計を使用します。 この設計では、特定のリージョンをダンプから除外して、SQLPAL とホスト環境の内部構造を認識します。
   full	full は、 /proc/$pid/maps にあるすべてのリージョンを含む完全なプロセス ダンプです。 これは coredump.captureminiandfull の設定によって制御されません。

Edition

SQL Server のエディションは、set-edition オプションを使用して変更できます。 SQL Server のエディションを変更するには、最初に SQL Server サービスを停止する必要があります。 使用可能な SQL Server on Linux エディションの詳細については、「SQL Server エディション」を参照してください。

高可用性

hadr.hadrenabled オプションは、SQL Server インスタンスで可用性グループを有効にします。 次のコマンドは、hadr.hadrenabled を 1 に設定することで可用性グループを有効にします。 設定を有効にするには、SQL Server を再起動する必要があります。

sudo /opt/mssql/bin/mssql-conf set hadr.hadrenabled  1
sudo systemctl restart mssql-server

可用性グループでの使用方法については、次の 2 つの記事を参照してください。

• Linux で高可用性を実現するために SQL Server の Always On 可用性グループを構成する
• Linux で読み取りスケールの SQL Server 可用性グループを構成する

ローカル監査ディレクトリを設定する

telemetry.userrequestedlocalauditdirectory の設定により、Local Audit が有効になり、Local Audit ログが作成されるディレクトリを設定できます。

1. 新しい Local Audit ログのターゲット ディレクトリを作成します。 次の例では、新しい /tmp/audit ディレクトリを作成します。

   sudo mkdir /tmp/audit
   

2. ディレクトリの所有者とグループを mssql ユーザーに変更します。

   sudo chown mssql /tmp/audit
   sudo chgrp mssql /tmp/audit
   

3. telemetry.userrequestedlocalauditdirectory の set コマンドを使って、mssql-conf スクリプトを root として実行します。

   sudo /opt/mssql/bin/mssql-conf set telemetry.userrequestedlocalauditdirectory /tmp/audit
   

4. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

詳細については、「SQL Server on Linux の使用状況と診断データの収集を構成する」を参照してください。

SQL Server のロケールを変更する

language.lcid の設定により、SQL Server のロケールが、サポートされている言語識別子 (LCID) に変更されます。

1. 次の例では、ロケールをフランス語 (1036) に変更します。

   sudo /opt/mssql/bin/mssql-conf set language.lcid 1036
   

2. SQL Server サービスを再起動して、変更を適用します。

   sudo systemctl restart mssql-server
   

メモリ制限を設定する

memory.memorylimitmb の設定により、SQL Server で使用できる物理メモリの量 (MB 単位) を制御します。 メモリ不足 (OOM) の状態を防ぐため、既定値は物理メモリの 80% です。

1. memory.memorylimitmb の set コマンドを使って、mssql-conf スクリプトを root として実行します。 次の例では、SQL Server で使用可能なメモリを 3.25 GB (3,328 MB) に変更します。

   sudo /opt/mssql/bin/mssql-conf set memory.memorylimitmb 3328
   

2. SQL Server サービスを再起動して、変更を適用します。

   sudo systemctl restart mssql-server
   

追加メモリの設定

メモリの設定では、次のオプションを使用できます。

MSDTC の構成

Microsoft 分散トランザクション コーディネーター (MSDTC) を構成するには、network.rpcport と distributedtransaction.servertcpport の設定を使います。 これらの設定を変更するには、次のコマンドを実行します。

1. network.rpcport の set コマンドを使って、mssql-conf スクリプトを root として実行します。

   sudo /opt/mssql/bin/mssql-conf set network.rpcport <rcp_port>
   

2. その後、distributedtransaction.servertcpport を設定します。

   sudo /opt/mssql/bin/mssql-conf set distributedtransaction.servertcpport <servertcpport_port>
   

これらの値を設定するだけでなく、ルーティングを構成し、ポート 135 のファイアウォールを更新する必要があります。 これを行う方法の詳細については、「Linux で Microsoft 分散トランザクション コーディネーター (MSDTC) を構成する方法」をご覧ください。

mssql-conf には、MSDTC の監視とトラブルシューティングに使用できるその他のいくつかの設定があります。 次の表では、これらの設定について簡単に説明しています。 使用方法の詳細については、Windows 10 コンピュータでMS DTC の診断トレースを有効にするに関する Windows サポートの記事を参照してください。

# For all packages: database engine and mlservices
# Setup prompts for mlservices EULAs, which you need to accept
sudo /opt/mssql/bin/mssql-conf setup

# Add R or Python to an existing installation
sudo /opt/mssql/bin/mssql-conf setup accept-eula-ml

# Alternative valid syntax
# Adds the EULA section to the INI and sets acceptulam to yes
sudo /opt/mssql/bin/mssql-conf set EULA accepteulaml Y

# Rescind EULA acceptance and removes the setting
sudo /opt/mssql/bin/mssql-conf unset EULA accepteulaml

[EULA]
accepteula = Y
accepteulaml = Y

# Adds the extensibility section and property.
# Sets "outboundnetworkaccess" to true.
# This setting is required if you want to access data or operations off the server.
sudo /opt/mssql/bin/mssql-conf set extensibility outboundnetworkaccess 1

# Turns off network access but preserves the setting
sudo /opt/mssql/bin/mssql-conf set extensibility outboundnetworkaccess 0

# Removes the setting and rescinds network access
sudo /opt/mssql/bin/mssql-conf unset extensibility.outboundnetworkaccess

[extensibility]
outboundnetworkaccess = 1

Azure Key Vault 向け SQL Server コネクタのログ レベルを変更する

SQL Server 2022 (16.x) CU 14 以降のバージョンでは、SQL Server on Linux が Azure Key Vault を使用した TDE 拡張キー管理をサポートしています。 ログ レベルを次のいずれかの値に設定できます。

SQL Server コネクタのログ レベルを変更するには、次の例を使用します。

sudo /opt/mssql/bin/mssql-conf set sqlconnector.logginglevel 1

詳細については、「SQL 暗号化機能で SQL Server コネクタを使用する」を参照してください。

TCP ポートを変更する

network.tcpport 設定は、SQL Server が接続をリッスンする TCP ポートを変更します。 既定では、このポート番号は 1433 に設定されています。 ポートを変更するには、次のコマンドを実行します。

1. network.tcpport の set コマンドを使って、mssql-conf スクリプトを root として実行します。

   sudo /opt/mssql/bin/mssql-conf set network.tcpport <new_tcp_port>
   

2. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

3. この時点で SQL Server に接続する場合は、ホスト名または IP アドレスの後にコンマ (,) を付けてカスタム ポートを指定する必要があります。 たとえば、sqlcmd で接続するには、次のコマンドを使います。

   sqlcmd -S localhost,<new_tcp_port> -U test -P test
   

TLS 設定を指定する

次のオプションでは、Linux で実行されている SQL Server のインスタンスに対して TLS を構成します。

TLS 設定の使用例については、「SQL Server on Linux への接続の暗号化」を参照してください。

ネットワーク設定

「チュートリアル:SSQL Server on Linux で Active Directory 認証を使用する」で、SQL Server on Linux での Active Directory 認証の使用に関する包括的な情報について参照してください。

次のオプションは、mssql-conf を使って構成可能な追加のネットワーク設定です。

トレース フラグを有効または無効にする

この traceflag オプションは、SQL Server サービスを起動するためのトレースフラグを有効または無効にします。 トレース フラグを有効または無効にするには、次のコマンドを使用します。

1. 次のコマンドを使用してトレース フラグを有効にします。 たとえばトレース フラグが 1234 の場合:

   sudo /opt/mssql/bin/mssql-conf traceflag 1234 on
   

2. 複数のトレース フラグは個別に指定することで有効にすることができます。

   sudo /opt/mssql/bin/mssql-conf traceflag 2345 3456 on
   

3. 同様の方法で、1 つ以上の有効なトレース フラグは、それらを指定して off パラメーターを追加することによって無効にすることができます。

   sudo /opt/mssql/bin/mssql-conf traceflag 1234 2345 3456 off
   

4. SQL Server サービスを再起動して、変更を適用します。

   sudo systemctl restart mssql-server
   

設定を削除する

mssql-conf set で行われた設定を設定解除するには、unset オプションと設定の名前を指定して mssql-conf を呼び出します。 これにより設定がクリアされ、実質的に既定値に戻ります。

1. 次の例では、network.tcpport オプションをクリアします。

   sudo /opt/mssql/bin/mssql-conf unset network.tcpport
   

2. SQL Server サービスを再起動します。

   sudo systemctl restart mssql-server
   

現在の設定を表示する

構成されている設定を表示するには、次のコマンドを実行して mssql.conf ファイルの内容を出力します。

sudo cat /var/opt/mssql/mssql.conf

このファイルで示されていないすべての設定については、既定値が使用されます。 次のセクションで、mssql.conf ファイルのサンプルを示します。

さまざまなオプションを表示する

mssql-conf ユーティリティを使用して構成できるさまざまなオプションを表示するには、次の help コマンドを実行します。

sudo /opt/mssql/bin/mssql-conf --help

この結果から、さまざまな構成オプションと、各設定の簡単な説明が得られます。

mssql.conf format

次の /var/opt/mssql/mssql.conf ファイルで各設定の例を示します。 この形式を使用すると、必要に応じて mssql.conf ファイルに手動で変更を加えることができます。 ファイルを手動で変更する場合は、変更を適用する前に SQL Server を再起動する必要があります。 Docker で mssql.conf ファイルを使用するには、Docker がデータを保持している必要があります。 まず、完全な mssql.conf ファイルをホスト ディレクトリに追加してから、コンテナーを実行します。 この例は、「SQL Server on Linux の使用状況と診断データの収集を構成する」にあります。

[EULA]
accepteula = Y

[coredump]
captureminiandfull = true
coredumptype = full

[filelocation]
defaultbackupdir = /var/opt/mssql/data/
defaultdatadir = /var/opt/mssql/data/
defaultdumpdir = /var/opt/mssql/data/
defaultlogdir = /var/opt/mssql/data/

[hadr]
hadrenabled = 0

[language]
lcid = 1033

[memory]
memorylimitmb = 4096

[network]
forceencryption = 0
ipaddress = 10.192.0.0
kerberoskeytabfile = /var/opt/mssql/secrets/mssql.keytab
tcpport = 1401
tlscert = /etc/ssl/certs/mssql.pem
tlsciphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
tlskey = /etc/ssl/private/mssql.key
tlsprotocols = 1.2,1.1,1.0

[sqlagent]
databasemailprofile = default
errorlogfile = /var/opt/mssql/log/sqlagentlog.log
errorlogginglevel = 7

[telemetry]
customerfeedback = true
userrequestedlocalauditdirectory = /tmp/audit

[traceflag]
traceflag0 = 1204
traceflag1 = 2345
traceflag = 3456

[EULA]
accepteula = Y
accepteulaml = Y

[coredump]
captureminiandfull = true
coredumptype = full

[distributedtransaction]
servertcpport = 51999

[filelocation]
defaultbackupdir = /var/opt/mssql/data/
defaultdatadir = /var/opt/mssql/data/
defaultdumpdir = /var/opt/mssql/data/
defaultlogdir = /var/opt/mssql/data/

[hadr]
hadrenabled = 0

[language]
lcid = 1033

[memory]
memorylimitmb = 4096

[network]
forceencryption = 0
ipaddress = 10.192.0.0
kerberoskeytabfile = /var/opt/mssql/secrets/mssql.keytab
rpcport = 13500
tcpport = 1401
tlscert = /etc/ssl/certs/mssql.pem
tlsciphers = ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA
tlskey = /etc/ssl/private/mssql.key
tlsprotocols = 1.2,1.1,1.0

[sqlagent]
databasemailprofile = default
errorlogfile = /var/opt/mssql/log/sqlagentlog.log
errorlogginglevel = 7

[telemetry]
customerfeedback = true
userrequestedlocalauditdirectory = /tmp/audit

[traceflag]
traceflag0 = 1204
traceflag1 = 2345
traceflag = 3456

関連するコンテンツ

• Linux 上で環境変数を使って SQL Server の設定を構成する
• SQL Server on Linux を管理するための適切なツールの選択
• SQL Server Linux コンテナーの構成およびカスタマイズ

SQL ドキュメントへの投稿

SQL コンテンツを自分で編集できることはご存じですか。 これにより、ドキュメントが改善されるだけでなく、ページの共同作成者としてもクレジットされます。

詳細については、「SQL Server のドキュメントに投稿する方法」を参照してください。