SQL Server の設計に関する考慮事項SQL Server Design Considerations

重要

このバージョンの Operations Manager はサポート終了に達したので、Operations Manager 2019 にアップグレードすることをお勧めします。This version of Operations Manager has reached the end of support, we recommend you to upgrade to Operations Manager 2019.

System Center Operations Manager は、オペレーション データベース、データ ウェアハウス データベース、ACS 監査データベースをサポートするために、Microsoft SQL Server を実行するサーバーのインスタンスにアクセスする必要があります。System Center Operations Manager requires access to an instance of a server running Microsoft SQL Server to support the operational, data warehouse, and ACS audit database. オペレーション データベースとデータ ウェアハウス データベースは、管理グループに最初の管理サーバーを展開するときに必要になるため、作成されますが、ACS データベースは、管理グループに ACS コレクターを展開する際に作成されます。The operational and data warehouse databases are required and created when you deploy the first management server in your management group, while the ACS database is created when you deploy an ACS collector in your management group.

Operations Manager のラボ環境または小規模展開では、SQL Server を管理グループの最初の管理サーバーに併置できます。In a lab environment or small-scale deployment of Operations Manager, SQL Server can be co-located on the first management server in the management group. 中規模から大規模の分散型展開では、SQL Server インスタンスを専用スタンドアロン サーバーまたは SQL Server 高可用性構成に配置する必要があります。In a medium to enterprise-scale distributed deployment, the SQL Server instance should be located on a dedicated standalone server or in a SQL Server high-availability configuration. どちらの場合でも、最初の管理サーバーまたは ACS コレクターをインストールする前に、SQL Server が既に存在し、アクセスできる必要があります。In either case, SQL Server must already exist and is accessible before you start the installation of the first management server or ACS collector.

SQL Server の要件SQL Server requirements

レポート サーバー、Operational、Data Warehouse、および ACS データベースをホストする System Center Operations Manager バージョンの既存のインストールに対しては、次のバージョンの SQL Server Enterprise Edition および Standard Edition がサポートされています。The following versions of SQL Server Enterprise & Standard Edition are supported for an existing installation of System Center Operations Manager version to host Reporting Server, Operational, Data Warehouse, and ACS database:

  • 累積的な更新プログラム 8 (CU8) 以降の SQL Server 2019 (詳細)SQL Server 2019 with Cumulative Update 8 (CU8) or later, as detailed here

    注意

    • Operations Manager 2019 では、CU8 以降の SQL 2019 がサポートされています。ただし、SQL 2019 RTM はサポートされていません。Operations Manager 2019 supports SQL 2019 with CU8 or later; however, it does not support SQL 2019 RTM.
    • ODBC 17.3 以降、および MSOLEDBSQL 18.2 以降を使用します。Use ODBC 17.3 or later, and MSOLEDBSQL 18.2 or later.
  • SQL Server 2017 と累積的な更新プログラム (詳細)SQL Server 2017 and Cumulative Updates as detailed here

  • SQL Server 2016 および各 Service Pack (詳細)SQL Server 2016 and Service Packs as detailed here

レポート サーバー、Operational、Data Warehouse、および ACS データベースをホストする System Center Operations Manager バージョンの既存のインストールに対しては、次のバージョンの SQL Server Enterprise Edition および Standard Edition がサポートされています。The following versions of SQL Server Enterprise & Standard Edition are supported for an existing installation of System Center Operations Manager version to host Reporting Server, Operational, Data Warehouse, and ACS database:

  • SQL Server 2017 と累積的な更新プログラム (詳細)SQL Server 2017 and Cumulative Updates as detailed here
  • SQL Server 2016 および各 Service Pack (詳細)SQL Server 2016 and Service Packs as detailed here

SQL Server をアップグレードする前に、2017 のアップグレード情報2019 のアップグレード情報に関する記事をご覧ください。Before upgrading SQL Server, see upgrade information for 2017, and upgrade information for 2019.

SQL Server 2017 にアップグレードする前に、2017 のアップグレード情報に関する記事をご覧ください。Before upgrading to SQL Server 2017, see upgrade information for 2017.

レポート サーバー、オペレーション、データ ウェアハウス、および ACS データベースをホストする System Center Operations Manager バージョン 1801 の新規または既存のインストールに対しては、次のバージョンの SQL Server Enterprise Edition および Standard Edition がサポートされています。The following versions of SQL Server Enterprise & Standard Edition are supported for a new or existing installation of System Center Operations Manager version 1801 to host Reporting Server, Operational, Data Warehouse, and ACS database:

  • SQL Server 2016 および各 Service Pack (詳細)SQL Server 2016 and Service Packs as detailed here

レポート サーバー、オペレーション、データ ウェアハウス、および ACS データベースをホストする System Center 2016 - Operations Manager の新規または既存のインストールに対しては、次のバージョンの SQL Server Enterprise Edition および Standard Edition がサポートされています。The following versions of SQL Server Enterprise & Standard Edition are supported for a new or existing installation of System Center 2016 - Operations Manager to host Reporting Server, Operational, Data Warehouse, and ACS database:

  • SQL Server 2016 および各 Service Pack (詳細)SQL Server 2016 and Service Packs as detailed here
  • SQL Server 2014 および各 Service Pack (詳細)SQL Server 2014 and Service Packs as detailed here
  • SQL Server 2012 および各 Service Pack (詳細)SQL Server 2012 and Service Packs as detailed here

注意

System Center Operations Manager データベースは、同じバージョンの SQL Server を使用する必要があります。SQL Server 照合順序を、セクションで説明されている通り、以下のサポートされる種類のいずれかに設定する必要があります。オペレーション データベースとデータ ウェアハウス データベースの両方に SQL Server フルテキスト検索が 必要 です。System Center Operations Manager databases must use the same version of SQL Server, the SQL Server collation setting must be one of the following supported types as described in that section, and SQL Server Full Text Search is required for both the operational and data warehouse databases. Operations Manager データベース コンポーネントでサポートされる Windows Server 2016 インストール オプション (Server Core、デスクトップ エクスペリエンス搭載サーバー、Nano Server) は、SQL Server でサポートされる Windows Server のインストール オプションに基づいています。The Windows Server 2016 installation options (Server Core, Server with Desktop Experience, and Nano Server) supported by Operations Manager database components, are based on what installation options of Windows Server are supported by SQL Server.

注意

System Center Operations Manager レポートは、前のバージョンのレポート ロールと併置インストールすることはできません。インストールはネイティブ モードに 限られますSystem Center Operations Manager Reporting cannot be installed in a side-by-side fashion with a previous version of the Reporting role and must be installed in native mode only. (SharePoint 統合モードはサポートされていません。)(SharePoint integrated mode is not supported.)

設計では、ハードウェアとソフトウェアの付加的な考慮事項が適用されます。Additional hardware and software considerations apply in your design planning:

  • SQL Server は NTFS ファイル形式のコンピューターで実行することが推奨されます。We recommend that you run SQL Server on computers with the NTFS file format.
  • オペレーション データベースとデータ ウェアハウス データベースの場合、1024 MB 以上の空き容量がディスクに必要です。There must be at least 1024 MB of free disk space for the operational and data warehouse database. データベースの作成時は、このサイズ以上しか設定できません。設定後、必要なディスク領域は大幅に増大する可能性があります。It is enforced at the time of database creation, and it will likely grow significantly after setup.
  • .NET Framework 4 が必要です。.NET Framework 4 is required.
  • レポート サーバーは、Windows Server Core ではサポートされていません。Reporting Server is not supported on Windows Server Core.

詳細については、SQL Server 2014 または 2016 のインストールに必要なハードウェアおよびソフトウェアに関する記事を参照してくださいFor more information, see Hardware and Software Requirements for Installing SQL Server 2014 or 2016

注意

オペレーション データベースの初期インストール中は、Operations Manager オペレーション データベースをホストする SQL Server 上の Windows 認証だけを使用してください。During the initial installation of the operational database, only use Windows Authentication on the SQL Server that hosts the Operations Manager operational database. 混合モード (Windows 認証と SQL Server 認証) は使用しないでください。オペレーション データベースの初期インストール中に SQL Server 認証を使用すると、問題が発生します。Do not use Mixed Mode (Windows Authentication and SQL Server Authentication) because using SQL Server Authentication mode during the initial installation of the operational database can cause issues. Operations Manager オペレーション データベースをホストする SQL Server で混合モード セキュリティを有効にすることはできますが、データベースとの接続にはすべて Windows アカウントのみが使用されるため、サポートされません。Although enabling Mixed Mode security is possible on the SQL Server hosting the Operations Manager operational database, it is not supported as all contact with the database is accomplished using Windows accounts only.

SQL Server の照合順序SQL Server collation setting

次の SQL Server と Windows の照合順序は、System Center Operations Manager でサポートされます。The following SQL Server and Windows collations are supported by System Center Operations Manager.

注意

比較またはコピー操作における互換性の問題を回避するには、SQL と Operations Manager DB に対して同じ照合順序を使用することをお勧めします。To avoid any compatibility issues in comparing or copying operations, we recommend you use the same collation for the SQL and Operations Manager DB.

SQL Server の照合順序SQL Server collation

  • SQL_Latin1_General_CP1_CI_ASSQL_Latin1_General_CP1_CI_AS

Windows 照合Windows collation

  • Latin1_General_100_CI_ASLatin1_General_100_CI_AS
  • French_CI_ASFrench_CI_AS
  • French_100_CI_ASFrench_100_CI_AS
  • Cyrillic_General_CI_ASCyrillic_General_CI_AS
  • Chinese_PRC_CI_ASChinese_PRC_CI_AS
  • Chinese_Simplified_Pinyin_100_CI_ASChinese_Simplified_Pinyin_100_CI_AS
  • Chinese_Traditional_Stroke_Count_100_CI_ASChinese_Traditional_Stroke_Count_100_CI_AS
  • Japanese_CI_ASJapanese_CI_AS
  • Japanese_XJIS_100_CI_ASJapanese_XJIS_100_CI_AS
  • Traditional_Spanish_CI_ASTraditional_Spanish_CI_AS
  • Modern_Spanish_100_CI_ASModern_Spanish_100_CI_AS
  • Latin1_General_CI_ASLatin1_General_CI_AS
  • Cyrillic_General_100_CI_ASCyrillic_General_100_CI_AS
  • Korean_100_CI_ASKorean_100_CI_AS
  • Czech_100_CI_ASCzech_100_CI_AS
  • Hungarian_100_CI_ASHungarian_100_CI_AS
  • Polish_100_CI_ASPolish_100_CI_AS
  • Finnish_Swedish_100_CI_ASFinnish_Swedish_100_CI_AS

SQL Server インスタンスが、前述のサポートされる照合順序のいずれかで構成されていない場合、Operations Manager のセットアップを新規に実行すると失敗します。If your SQL Server instance is not configured with one of the supported collations listed earlier, performing a new setup of Operations Manager setup will fail. ただし、一括アップグレードは正常に完了します。However, an in-place upgrade will complete successfully.

ファイアウォールの構成Firewall configuration

Operations Manager は SQL Server に依存し、そのデータベースとレポート プラットフォームをホストし、過去の運用データを分析し、表示します。Operations Manager depends on SQL Server to host its databases and a reporting platform to analyze and present historical operational data. 管理サーバー、オペレーション、Web コンソールのロールは SQL Server と正常に通信する必要があります。環境を正しく構成するには、通信パスとポートを理解することが重要です。The management server, Operations, and Web console roles need to be able to successfully communicate with SQL Server, and it is important to understand the communication path and ports in order to configure your environment correctly.

Operations Manager データベースにフェールオーバー機能を提供するために SQL AlwaysOn 可用性グループを必要とする分散型展開を設計している場合、追加のファイアウォール構成設定をファイアウォール セキュリティ戦略に含める必要があります。If you are designing a distributed deployment that will require SQL Always On Availability Groups to provide failover functionality for the Operations Manager databases, there are additional firewall configuration settings that need to be included in your firewall security strategy.

Operations Manager 管理グループのサーバー ロールが正常に通信するために最小限許可する必要がある SQL Server で必要なファイアウォール ポートを特定するとき、次の表が役に立ちます。The following table helps you identify the firewall ports required by SQL Server that will need to be allowed at a minimum in order for server roles in your Operations Manager management group to successfully communicate.

通信の種類Scenario ポートPort DirectionDirection Operations Manager ロールOperations Manager Role
Operations Manager データベースをホストする SQL ServerSQL Server hosting Operations Manager databases TCP 1433 *TCP 1433 * 着信Inbound 管理サーバーと Web コンソール (Application Advisor と Application Diagnostics 用)management server and Web console (for Application Advisor and Application Diagnostics)
SQL Server Browser サービスSQL Server Browser service UDP 1434UDP 1434 着信Inbound 管理サーバーmanagement server
SQL Server 専用管理者接続SQL Server Dedicated Admin Connection TCP 1434TCP 1434 着信Inbound 管理サーバーmanagement server
SQL Server で使用される追加のポートAdditional ports used by SQL Server
- Microsoft リモート プロシージャ呼び出し (MS RPC)- Microsoft remote procedure calls (MS RPC)
- Windows Management Instrumentation (WMI)- Windows Management Instrumentation (WMI)
- Microsoft 分散トランザクション コーディネーター サービス (MS DTC)- Microsoft Distributed Transaction Coordinator (MS DTC)
TCP 135TCP 135 着信Inbound 管理サーバーmanagement server
SQL Server AlwaysOn 可用性グループ リスナーSQL Server Always On Availability Group Listener 管理者構成ポートAdministrator configured port 受信Inbound 管理サーバーmanagement server
Operations Manager Reporting Server をホストしている SQL Server Reporting ServicesSQL Server Reporting Services hosting Operations Manager Reporting Server TCP 80 (既定)/443 (SSL)TCP 80 (default)/443 (SSL) 受信Inbound 管理サーバーとオペレーション コンソールmanagement server and Operations console

*TCP 1433 はデータベース エンジンの既定インスタンスの標準ポートです。スタンドアロン SQL Server で名前付きインスタンスを作成する場合、あるいは SQL AlwaysOn 可用性グループを展開している場合、カスタム ポートが定義されます。ファイアウォールを正しく構成するために、このカスタム ポートを記録し、参照します。設定時にこの情報を入力します。* While TCP 1433 is the standard port for the default instance of the Database Engine, when you create a named instance on a standalone SQL Server or have deployed a SQL Always On Availability Group, a custom port will be defined and should be documented for reference so that you properly configure your firewalls and enter this information during setup.

SQL Server のファイアウォール要件の詳細な概要が必要な場合、「Configure the Windows Firewall to Allow SQL Server Access」 (Windows ファイアウォールを構成し、SQL Server アクセスを許可する) を参照してください。For a more detailed overview of the firewall requirements for SQL Server, see Configure the Windows Firewall to Allow SQL Server Access.

容量と記憶域に関する考慮事項Capacity and storage considerations

Operations Manager データベースOperations Manager database

Operations Manager データベースは、毎日の監視で Operations Manager が必要とするすべてのデータが含まれる SQL Server データベースです。The Operations Manager database is a SQL Server database that contains all of the data needed by Operations Manager for day-to-day monitoring. データベース サーバーのサイズ変更と構成は、管理グループの全体的パフォーマンスにとって重要です。Sizing and configuration of the database server is critical to the overall performance of the management group. Operations Manager データベースにより使用される最も重要なリソースはストレージ サブシステムですが、CPU と RAM も重要です。The most critical resource used by the Operations Manager database is the storage subsystem, but CPU and RAM are also significant.

Operations Manager データベースの負荷に影響を与える要因:Factors that influence the load on the Operations Manager database include:

  • オペレーション データの収集率。Rate of operational data collection. オペレーション データは、すべてのイベント、アラート、状態変更、エージェントによって収集されたパフォーマンス データで構成されます。Operational data consists of all the events, alerts, state changes, and performance data collected by agents. Operations Manager データベースにより使用されるリソースのほとんどは、このデータがシステムに入ったときに、データをディスクに書き込むのに使用されます。Most of the resources that are used by the Operations Manager database are used to write this data to disk as it comes into the system. オペレーション データの収集率は増加する傾向にあります。追加管理パックがインポートされ、追加エージェントが追加されるためです。The rate of operational data collected tends to increase as additional management packs are imported and additional agents are added. オペレーション データ コレクションの全体的なレートを判断するとき、エージェントが監視しているコンピューターの種類も重要な要素です。The type of computer that an agent is monitoring is also an important factor used when determining the overall rate of operational data collection. たとえば、ビジネス クリティカルなデスクトップ コンピューターを監視しているエージェントは、大量のデータベースを備えた SQL Server のインスタンスを実行しているサーバーを監視しているエージェントより収集するデータが少ないと予想されます。For example, an agent that is monitoring a business-critical desktop computer can be expected to collect less data than an agent monitoring a server that is running an instance of SQL Server with a large number of databases.
  • インスタンス スペースの変更率。Rate of instance space changes. Operations Manager データベースでこのデータを更新することは、新しいオペレーション データを書き込むことに比べて高額になります。Updating this data in the Operations Manager database is costly relative to writing new operational data. また、インスタンス スペース データが変わると、構成とグループの変更を計算する目的で、管理サーバーが Operations Manager データベースに追加クエリを実行します。In addition, when instance space data changes, the management servers make additional queries to the Operations Manager database in order to compute configuration and group changes. 追加管理パックを管理グループにインポートすると、インスタンス スペースの変更率が増加します。The rate of instance space changes increases as you import additional management packs into a management group. 新しいエージェントを管理グループに追加した場合も、インスタンス スペースの変更率が一時的に増加します。Adding new agents to a management group also temporarily increases the rate of instance space changes.
  • オペレーション コンソールと同時に実行されるその他の SDK 接続の数。Number of Operations Consoles and other SDK connections running simultaneously. 各オペレーション コンソールが Operations Manager データベースからデータを読み取ります。Each Operations console reads data from the Operations Manager database. このデータを問い合わせると、大量のストレージ I/O リソース、CPU 時間、RAM が消費される可能性があります。Querying this data consumes potentially large amounts of storage I/O resources, CPU time, and RAM. イベント ビュー、状態ビュー、アラート ビュー、パフォーマンス データ ビューに大量のオペレーション データを表示するオペレーション コンソールは、データベースに大きな負荷が発生する傾向があります。Operations consoles that display large amounts of operational data in the Events View, State View, Alerts View, and Performance Data View tend to cause the largest load on the database.

Operations Manager データベースは、管理グループにエラーが発生する唯一の源です。SQL Server AlwaysOn 可用性グループやフェールオーバー クラスター インスタンスなど、サポートされているフェールオーバー構成を利用し、可用性を高めることができます。The Operations Manager database is a single source of failure for the management group, so it can be made highly available using supported failover configurations such as SQL Server Always On Availability Groups or Failover Cluster Instances.

Operations Manager データ ウェアハウス データベースOperations Manager data warehouse database

System Center – Operations Manager はレポート データ ウェアハウスにほぼリアルタイムでデータを挿入します。レポート データ ウェアハウスに集められるすべてのデータの書き込みをサポートするこのサーバーに十分な容量を与えることが重要です。System Center – Operations Manager inserts data into the Reporting data warehouse in near-real time, it is important to have sufficient capacity on this server that supports writing all of the data that is being collected to the Reporting data warehouse. Operations Manager データベースと同様に、レポート データ ウェアハウスの最重要リソースはストレージ I/O サブシステムです。As with the Operations Manager database, the most critical resource on the Reporting data warehouse is the storage I/O subsystem. ほとんどのシステムで、レポート データ ウェアハウスの負荷は Operations Manager データベースと同じですが、変わる場合もあります。On most systems, loads on the Reporting data warehouse are similar to the Operations Manager database, but they can vary. また、レポートによりレポート データ ウェアハウスに与えられる作業負荷は、オペレーション コンソールの使用により Operations Manager データベースに与えられる負荷とは異なります。In addition, the workload put on the Reporting data warehouse by reporting is different than the load put on the Operations Manager database by Operations console usage.

レポート データ ウェアハウスの負荷に影響を与える要因:Factors that influence the load on the Reporting data warehouse include:

  • オペレーション データの収集率。Rate of operational data collection. より効率的なレポートを実現するために、レポート データ ウェアハウスは限られた量の生データに加え、集合データを計算し、保存します。To allow for more efficient reporting, the Reporting data warehouse computes and stores aggregated data in addition to a limited amount of raw data. この追加の作業は、レポート データ ウェアハウスにオペレーション データを集めることは Operations Manager データベースにオペレーション データを集める場合より少々コストがかかることを意味します。Doing this extra work means that operational data collection to the Reporting data warehouse can be slightly more costly than to the Operations Manager database. この追加のコストは、一般的に、レポート データ ウェアハウスは Operations Manager データベースに比べて探索データの処理コストが安くなることで相殺されます。This additional cost is typically balanced by the reduced cost of processing discovery data by the Reporting data warehouse versus the Operations Manager database.
  • 同時実行のレポート ユーザーまたはスケジュールされたレポート生成の数。Number of concurrent reporting users or scheduled report generation. レポートは頻繁に大量のデータを集約するため、各レポート ユーザーはシステムに相当な負荷を加えると考えられます。Because reports frequently summarize large volumes of data, each reporting user can add a significant load on the system. 同時に実行されるレポートの数と実行されるレポートの種類の両方が全体的容量ニーズに影響を与えます。The number of reports run simultaneously and the type of reports being run both affect overall capacity needs. 一般的に、大きな日付範囲または大量のオブジェクトにクエリを実行するレポートは追加のシステム リソースを必要とします。Generally, reports that query large date ranges or large numbers of objects require additional system resources.

これらの要因に基づき、レポート データ ウェアハウスのサイズを変更するとき、考慮するべき推奨プラクティスがいくつかあります。Based on these factors, there are several recommended practices to consider when sizing the Reporting data warehouse:

  • 適切な記憶域サブシステムを選択します。Choose an appropriate storage subsystem. レポート データ ウェアハウスは管理グループの全体的データ フローの不可欠な部分です。レポート データ ウェアハウスに適切な記憶域サブシステムを選択することは重要です。Because the Reporting data warehouse is an integral part of the overall data flow through the management group, choosing an appropriate storage subsystem for the Reporting data warehouse is important. Operations Manager データベースと同様に、多くの場合、RAID 0 + 1 が最適な選択肢です。As with the Operations Manager database, RAID 0 + 1 is often the best choice. 一般的に、レポート データ ウェアハウスの記憶域サブシステムは、Operations Manager データベースの記憶域サブシステムと同じにする必要があります。Operations Manager データベースに適用されるガイダンスはレポート データ ウェアハウスにも適用されます。In general, the storage subsystem for the Reporting data warehouse should be similar to the storage subsystem for the Operations Manager database, and the guidance that applies to the Operations Manager database also applies to the Reporting data warehouse.
  • データ ログとトランザクション ログの適切な配置を考慮します。Consider appropriate placement of data logs vs. transaction logs. Operations Manager データベースと同様に、エージェントの数を増やすとき、SQL データとトランザクション ログを分けることは、適切な選択肢であることが多いです。As for the Operations Manager database, separating SQL data and transaction logs are often an appropriate choice as you scale up the number of agents. Operations Manager データベースとレポート データ ウェアハウスの両方が同じサーバーにあり、データとトランザクション ログを分離したい場合、メリットを得るには、レポート データ ウェアハウスとは別の物理ボリュームとディスク スピンドルに Operations Manager データベースのトランザクション ログを置く必要があります。If both the Operations Manager database and Reporting data warehouse are located on the same server and you want to separate data and transaction logs, you must put the transaction logs for the Operations Manager database on a separate physical volume and disk spindles from the Reporting data warehouse to receive any benefit. Operations Manager データベースとレポート データ ウェアハウスのデータ ファイルは、物理ボリュームが適切な容量を提供し、ディスク I/O パフォーマンスが監視とレポートの機能に悪影響を与えない限り、同じ物理ボリュームを共有できます。The data files for the Operations Manager database and Reporting data warehouse can share the same physical volume as long as the volume provides adequate capacity and disk I/O performance does not negatively impact monitoring and reporting functionality.
  • レポート データ ウェアハウスは Operations Manager データベースとは別のサーバーに配置することを検討してください。Consider placing the Reporting data warehouse on a separate server from the Operations Manager database. 小規模の展開では、多くの場合、Operations Manager データベースとレポート データ ウェアハウスを同じサーバーで統合できますが、エージェントの数と入ってくるオペレーション データの量を増やすときに、分離すると効果的です。Although smaller-scale deployments can often consolidate the Operations Manager database and Reporting data warehouse on the same server, it is advantageous to separate them as you scale up the number of agents and the volume of incoming operational data. レポート データ ウェアハウスとレポート サーバーが Operations Manager データベースとは別のサーバーにあると、レポート パフォーマンスが向上します。When the Reporting data warehouse and Reporting Server are on a separate server from the Operations Manager database, you experience better reporting performance.

Operations Manager データ ウェアハウス データベースは、管理グループにエラーが発生する唯一の源です。SQL Server AlwaysOn 可用性グループやフェールオーバー クラスター インスタンスなど、サポートされているフェールオーバー構成を利用し、可用性を高めることができます。The Operations Manager data warehouse database is a single source of failure for the management group, so it can be made highly available using supported failover configurations such as SQL Server Always On Availability Groups or Failover Cluster Instances.

SQL Server AlwaysOnSQL Server Always On

SQL Server AlwaysOn 可用性グループは、個別のユーザー データベース (可用性データベース) のセットのフェールオーバー環境をサポートします。SQL Server Always On availability groups support failover environments for a discrete set of user databases (availability databases). 可用性データベースの各セットは、可用性レプリカによってホストされます。Each set of availability databases is hosted by an availability replica.

System Center 2016 以降の Operations Manager の場合、SQL AlwaysOn の方がフェールオーバー クラスタリングより高い可用性をデータベースに提供します。With System Center 2016 and later - Operations Manager, SQL Always On is preferred over failover clustering to provide high availability for databases. 2 つのデータベースを使用し、永続的データ記憶域と一時的記憶域要件を分けるネイティブ モードのレポート サービスのインストールを除くすべてのデータベースを AlwaysOn 可用性グループでホストできます。All databases except the native mode Reporting Services installation, which uses two databases to separate persistent data storage from temporary storage requirements, can be hosted in an AlwaysOn Availability Group.

可用性グループをセットアップするには、Windows Server フェールオーバー クラスタリング (WSFC) クラスターを展開して可用性レプリカをホストし、クラスター ノード上で AlwaysOn を有効にする必要があります。To set up an availability group you'll need to deploy a Windows Server Failover Clustering (WSFC) cluster to host the availability replica, and enable Always On on the cluster nodes. その後で、可用性データベースとして Operations Manager SQL Server データベースを追加できます。You can then add the Operations Manager SQL Server database as an availability database.

SQL Server AlwaysOnSQL Server Always On

SQL Server AlwaysOn 可用性グループは、個別のユーザー データベース (可用性データベース) のセットのフェールオーバー環境をサポートします。SQL Server Always On availability groups support failover environments for a discrete set of user databases (availability databases). 可用性データベースの各セットは、可用性レプリカによってホストされます。Each set of availability databases is hosted by an availability replica.

System Center 2016 以降の Operations Manager の場合、SQL AlwaysOn の方がフェールオーバー クラスタリングより高い可用性をデータベースに提供します。With System Center 2016 and later - Operations Manager, SQL Always On is preferred over failover clustering to provide high availability for databases. 2 つのデータベースを使用し、永続的データ記憶域と一時的記憶域要件を分けるネイティブ モードのレポート サービスのインストールを除くすべてのデータベースを AlwaysOn 可用性グループでホストできます。All databases except the native mode Reporting Services installation, which uses two databases to separate persistent data storage from temporary storage requirements, can be hosted in an AlwaysOn Availability Group.

可用性グループをセットアップするには、Windows Server フェールオーバー クラスタリング (WSFC) クラスターを展開して可用性レプリカをホストし、クラスター ノード上で AlwaysOn を有効にする必要があります。To set up an availability group you'll need to deploy a Windows Server Failover Clustering (WSFC) cluster to host the availability replica, and enable Always On on the cluster nodes. その後で、可用性データベースとして Operations Manager SQL Server データベースを追加できます。You can then add the Operations Manager SQL Server database as an availability database.

注意

SQL Always On に参加している SQL のサーバー ノードに Operations Manager を展開した後、CLR の厳密なセキュリティを有効にするには、各 Operations Manager データベースで SQL スクリプトを実行します。After deploying Operations Manager on the SQL server nodes participating in SQL Always On, to enable CLR strict security, run the SQL script on each Operations Manager database.

マルチサブネットの文字列Multisubnet string

Operations Manager では、接続文字列キーワードをサポートしていません (MultiSubnetFailover = True)。Operations Manager does not support the connection string key words (MultiSubnetFailover=True). クロスサイト フェールオーバー構成で展開する場合など、可用性グループには、さまざまなサブネットからの複数の IP アドレスに依存するリスナー名 (WSFC クラスター マネージャーのネットワーク名またはクライアント アクセス ポイントとして知られる) が使用されるため、管理サーバーから可用性グループ リスナーへのクライアント接続要求が接続タイムアウトになります。Because an availability group has a listener name (known as the network name or Client Access Point in the WSFC Cluster Manager) depending on multiple IP addresses from different subnets, such as when you deploy in a cross-site failover configuration, client-connection requests from management servers to the availability group listener will hit a connection timeout.

マルチサブネット環境にある可用性グループにサーバー ノードを展開するときにこの制限を回避するには、次の方法をお勧めします。The recommended approach to work around this limitation when you have deployed server nodes in the availability group in a multi-subnet environment, is to do the following:

  1. 単一の有効な IP アドレスのみを DNS に登録するように、可用性グループ リスナーのネットワーク名を設定します。Set the network name of your availability group listener to only register a single active IP address in DNS
  2. 登録済みの DNS レコードに対して低い TTL 値を使用するようにクラスターを構成します。Configure the cluster to use a low TTL value for the registered DNS record

これらの設定を使用すれば、別のサブネット内のノードにフェールオーバーするときに、新しい IP アドレスでクラスター名の回復および解決を迅速に行うことができます。These settings allow, when fail over to a node in a different subnet, for quicker recovery and resolution of the cluster name with the new IP address.

SQL ノードのいずれか 1 つに対して次の PowerShell クエリを実行して、その設定を変更します。Run the following PowerShell query on any one of the SQL nodes to modify its settings.

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"

リスナー名で AlwaysOn を使用している場合は、リスナーに対してもこのような構成変更を行う必要があります。If you are using Always On with a listener name, you should also make these configurations changes on the listener.

現在リスナーをホストしている SQL ノードに対して次の PowerShell クエリを実行して、その設定を変更します。Run the following PowerShell query on the SQL node currently hosting the listener to modify its settings.

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>

クラスター化されたインスタンスまたは Always On SQL インスタンスが高可用性のために使用されると、ノード間のフェールオーバーが発生したときにいつでも Operations Manager データ アクセス サービスが再起動されないように、管理サーバーで自動復旧機能を有効にする必要があります。When a clustered or an Always On SQL instance is used for high availability, you should enable the automatic recovery feature on your management servers to avoid the Operations Manager Data Access service restart anytime a failover between nodes occur. この構成方法の詳細については、サポート技術情報の「The System Center Management service stops responding after an instance of SQL Server goes offline」 (System Center Management サービスは、SQL Server のインスタンスがオフラインになった後に応答を停止する) を参照してください。For information on how to configure this, see the following KB article The System Center Management service stops responding after an instance of SQL Server goes offline.

SQL Server を最適化するOptimizing SQL Server

概して、これまでのお客様の展開からわかることは、通常、SQL Server 自体の高いリソース使用 (プロセッサやメモリ) が原因でパフォーマンス問題が発生することはなく、むしろ、記憶域サブシステムの構成が直接関連しているということです。In general, previous deployment experience with customers shows that performance issues are typically not caused by high resource utilization (that is, processor or memory) with SQL Server itself; rather it is directly related to the configuration of the storage subsystem. パフォーマンスのボトルネックは、通常、SQL Server データベース インスタンスにプロビジョニングされる記憶域の推奨構成ガイダンスに従っていないことに起因します。Performance bottlenecks are commonly attributed to not following recommended configuration guidance with the storage provisioned for the SQL Server database instance. たとえば、次のような場合です。Such examples are:

  • LUN のスピンドルの割り当てが不十分であり、Operations Manager の IO 要件をサポートできない。Insufficient allocation of spindles for the LUNs to support the IO requirements of Operations Manager.
  • トランザクション ログとデータベース ファイルを同じボリュームでホストしている。Hosting transaction logs and database files on the same volume. これら 2 つのワークロードの IO 特性と待機時間特性が異なる。These two workloads have different IO and latency characteristics.
  • 配置やサイズなどに関して、TempDB の構成が間違っている。Configuration of TempDB is incorrect with respect to placement, sizing, etc.
  • トランザクション ログ、データベース ファイル、TempDB をホストするボリュームのディスク パーティションの調整が間違っている。Disk partition misalignment of volumes hosting the database transaction logs, database files, and TempDB
  • 基本的な SQL Server 構成を見落としている (データベースやトランザクション ログ ファイルに AUTOGROW を使用する、クエリ並列性のために MAXDOP を設定する、CPU コアごとに複数の TempDB データ ファイルを作成する、など)。Overlooking the basic SQL Server configuration such as using AUTOGROW for database and transaction log files, MAXDOP setting for query parallelism, creating multiple TempDB data files per CPU core, etc.

Operations Manager の SQL Server 展開にとって、記憶域構成は重要な構成要素の 1 つです。Storage configuration is one of the critical components to a SQL Server deployment for Operations Manager. データベースの読み書きとトランザクション ログの処理が厳密であるためめ、データベース サーバーは厳重な I/O 制約を受ける傾向があります。Database servers tend to be heavily I/O bound due to rigorous database read and write activity and transaction log processing. Operations Manager の I/O 動作パターンは、通常、80% が書き込み、20% が読み取りです。The I/O behavior pattern of Operations Manager is typically 80% writes and 20% reads. 結果として、I/O サブシステムの構成を間違えると、SQL Server システムのパフォーマンスが低下し、それが Operations Manager で顕著になります。As a result, improper configuration of I/O subsystems can lead to poor performance and operation of SQL Server systems and becomes noticeable in Operations Manager.

SQL Server の設計を試験することが重要です。SQL Server を展開する前に、I/O サブシステムのスループットを試験します。It is important to test the SQL Server design by performing throughput testing of the IO subsystem prior to deploying SQL Server. I/O 要件を満たし、待機時間が許容されるレベルであることを確認します。Make sure these tests are able to achieve your IO requirements with an acceptable latency. Diskspd ユーティリティ を使用して、SQL Server をサポートする記憶域サブシステムの I/O 容量を評価します。Use the Diskspd Utility to evaluate the I/O capacity of the storage subsystem supporting SQL Server. 製品グループのファイル サーバー チームのメンバーが書いた次のブログ記事に、このツールと PowerShell コードを利用してストレス テストを実行し、PerfMon を利用して結果を記録する方法に関する詳しいガイダンスと推奨事項があります。The following blog article, authored by a member of the File Server team in the product group, provides detailed guidance and recommendations on how to go about performing stress testing using this tool with some PowerShell code, and capturing the results using PerfMon. Operations Manager のサイズ測定ヘルパーも最初のガイダンスとして参照できます。You can also refer to the Operations Manager Sizing Helper for initial guidance.

NTFS 割り当てユニット サイズNTFS allocation unit size

RAID デバイスでボリュームを作成するときは必ず、一般的にはセクター配置と呼ばれているボリューム配置をファイル システム (NTFS) で実行する必要があります。Volume alignment, commonly referred to as sector alignment, should be performed on the file system (NTFS) whenever a volume is created on a RAID device. 実行しない場合、パフォーマンスが大幅に低下する可能性があります。このパフォーマンスの低下は多くの場合、不適切なパーティションとストライプ ユニットの境界に起因します。Failure to do so can lead to significant performance degradation and are most commonly the result of partition misalignment with stripe unit boundaries. 不適切なハードウェア キャッシュも引き起こし、配列キャッシュの利用が非効率になることがあります。It can also lead to hardware cache misalignment, resulting in inefficient utilization of the array cache. SQL Server データ ファイルに使用されるパーティションを書式設定するとき、データ、ログ、tempdb に 64-KB 割り当てユニット サイズ (つまり、65,536 バイト) を使用することが推奨されます。When formatting the partition that will be used for SQL Server data files, it is recommended that you use a 64-KB allocation unit size (that is, 65,536 bytes) for data, logs, and tempdb. ただし、割り当てユニット サイズが 4 KB を超えると、ボリュームの NTFS 圧縮を使用できなくなります。Be aware however, that using allocation unit sizes greater than 4 KB results in the inability to use NTFS compression on the volume. SQL Server では、圧縮ボリュームで読み取り専用データがサポートされますが、推奨されません。While SQL Server does support read-only data on compressed volumes, it is not recommended.

メモリの予約Reserve memory

System Center - Operations Manager をサポートするために、SQL Server の Windows サーバーに割り当てる物理メモリとプロセッサの量を正しく特定することは、簡単ではありません (この製品以外の他の作業負荷の場合でも簡単ではありません)。Identifying the right amount of physical memory and processors to allocate to the Windows server for SQL Server in support of System Center - Operations Manager is not an easy question to answer (not even for other workloads outside of this product for that matter). 製品グループによって提供されるサイズ計算ツールでは、作業負荷の規模 (500 システム、1000 システムなど) に基づいたガイダンスが提供されますが、多くの場合、その計算内容の整合性には疑問が残ります。計算ツールはラボ環境で実行されるテストを基にしていますが、このラボ環境が実際の典型的な作業負荷や構成と一致しているかどうかは確実ではありません。While the sizing calculator provided by the product group, which is based off of testing performed in a lab environment that may or may not align with the typical workload and configuration in the real-world, provides guidance based on workload scale (that is, 500 systems, 1000 systems, etc.) the integrity of what's stated is often brought into question. 最初の構成としては推奨されますが、最終構成ではなく、最終構成にすることはできません。It serves as an initial recommendation to start with, however it's not and cannot be considered the final configuration.

既定では、SQL Server は、利用可能なシステム リソースに基づきメモリ要件を動的に変更できます。By default, SQL Server can change its memory requirements dynamically based on available system resources. 最小サーバー メモリの既定の設定は 0 です。最大サーバー メモリの既定の設定は 2147483647 です。The default setting for min server memory is 0, and the default setting for max server memory is 2147483647. 最大サーバー メモリに指定できるメモリの最小量は 16 メガバイト (MB) です。The minimum amount of memory you can specify for max server memory is 16 megabytes (MB). パフォーマンスやメモリに関連する問題の多くは、お客様が値に最大値を設定しないことに起因します。A number of performance and memory-related problems are because customer’s don’t set a value for Max. 設定しないのは、何を設定すればよいのかわからないためです。Server Memory and they don’t do that because they don’t know what to set. HBA カード、管理エージェント、アンチウイルス リアルタイム スキャンなど、そのシステムで実行されている他のプロセスをサポートするための十分なメモリをオペレーティング システムに与えるように SQL に割り当てるメモリの最大量には、他にもさまざまな要因が影響を与えます。十分なメモリが与えられない場合、OS と SQL はディスクにページングし、ディスク I/O が増え、パフォーマンスがさらに低下し、"波及" 効果が作られ、それが Operations Manager で顕著になります。A number of other factors influence the maximum amount of memory you allocate to SQL to ensure the operating system has enough memory to support the other processes running on that system, such as HBA card, management agents, anti-virus real-time scanning, etc. Otherwise, the OS and SQL will page to disk and then disk I/O increases, further decreasing performance and creating a "ripple" effect where it is noticeable in Operations Manager.

SQL Server では、そのプロセスで予約し、使用する必要があるメモリの最小量と最大量を構成できます。SQL Server allows you to configure the minimum and maximum amount of memory that should be reserved and used by its process. 最小量として少なくとも 4 GB の RAM を指定します。Specify at least 4 GB of RAM as minimum amount. Operations Manager データベース (オペレーション、データ ウェアハウス、ACS) の 1 つをホストする SQL ノードごとにこれを行う必要があります。This should be done for every SQL node hosting one of the Operations Manager databases (Operational, Data warehouse, ACS).

最初は OS 用に 1 GB の RAM、4–16 GB の範囲で取り付けられた RAM の 4 GB ごとに 1 GB、16 GB RAM を超えて取り付けられた 8 GB RAM ごとに 1 GB を予約します。First start by reserving 1 GB of RAM for the OS, 1 GB for each 4 GB of RAM installed from 4–16 GB, and then 1 GB for every 8 GB RAM installed above 16 GB RAM. 次に、Windows のメモリ/利用可能メガバイトのパフォーマンス カウンターを監視し、最初の値を超え、SQL Server に利用できるメモリを増加できるか判断します。Then monitor the Memory\Available MBytes performance counter in Windows to determine if you can increase the memory available to SQL Server above the starting value.

注意

このカウンターは、少なくとも 150 ~ 300 MB 以上に維持されている必要があります。This counter should remain above the 150-300 MB at a bare minimum. Windows が 96 MB で LowMemoryResourceNotification を通知したらバッファーが必要になりますが、RAM が 256 GB 以上の大規模サーバーでは 1 GB 以上から始めることを検討してください。Windows signals the LowMemoryResourceNotification at 96 MB so you want a buffer, but you should consider starting above 1 GB on larger servers with 256 GB or higher RAM.

この方法は通常、SQL Server 専用のサーバーで効果を出しています。This approach has typically worked out well for servers that are dedicated to SQL Server. '最大サーバー メモリ' はさらに厳密に決定することもできます。OS、他のアプリケーション、SQL Server スレッド スタック、他の複数ページ アロケーターのメモリ要件を分析します。You can also get much more technical with determining where to set 'max server memory' by working out the specific memory requirements for the OS, other applications, the SQL Server thread stack, and other multipage allocators. 通常、これは ((システム メモリ合計) – (スレッド スタックのメモリ) – (OS メモリ要件 ~ 2-4 GB) – (他のアプリケーション用のメモリ) – (SQLCLR、リンク サーバーなど、複数ページ割り当てのメモリ)) になります。ここで、スレッド スタックのメモリ = ((最大 worker スレッド) (スタック サイズ)) であり、スタック サイズは x86 システムの場合は 512 KB、x64 システムの場合は 2 MB、IA64 システムの場合は 4 MB です。Typically this would be ((Total system memory) – (memory for thread stack) – (OS memory requirements ~ 2-4 GB) – (memory for other applications) – (memory for multipage allocations; SQLCLR, linked servers, etc.)), where the memory for thread stack = ((max worker threads) (stack size)) and the stack size is 512 KB for x86 systems, 2 MB for x64 systems and 4 MB for IA64 systems. '最大 worker スレッド' の値は sys.dm_os_sys_info の max_worker_count column にあります。The value for 'max worker threads' can be found in the max_worker_count column of sys.dm_os_sys_info. ただし、いずれの方法でも、他のアプリケーションのための計算で予約していない限り、コンピューター上で利用できるすべてを SQL Server に使用させることを前提としています。However, the assumption with either of these methods is that you want SQL Server to use everything that is available on the machine, unless you've made reservations in the calculations for other applications.

多くのお客様の環境で SQL Server を仮想化する傾向が強まっていることから、SQL Server を仮想マシンで実行するために必要なメモリの最小量を判断するとき、この質問が大いに関係します。As more customers move towards virtualizing SQL Server in their environment, this question is more relevant in determining what is the minimum amount of memory that a SQL Server will need to run in a virtual machine. 残念ながら、SQL Server の特定のインスタンスに対して実際に最適となるメモリ量を計算する方法はありません。SQL Server はバッファー プールのデータをキャッシュするように設計されているためです。通常、割り当てた量のメモリを使用します。Unfortunately there is no way to calculate what the ideal amount of memory for a given instance of SQL Server might actually be since SQL Server is designed to cache data in the buffer pool, and it will typically use as much memory as you can give it. SQL Server インスタンスに割り当てるメモリを減らすときに留意するべき点の 1 つは、ディスクの I/O アクセスを高くする代償としてメモリを減らす段階にいずれはたどり着くということです。One of the things to keep in mind when you are looking at reducing the memory allocated to a SQL Server instance, is that you will eventually get to a point where the lower memory gets traded off for higher disk I/O access.

過度にプロビジョニングされた環境で SQL Server メモリの理想的な構成を見つけ出す必要がある場合、それに取り組む最良の方法は、環境の基線と性能測定基準から始めることです。If you need to figure out the ideal configuration for SQL Server memory in an environment that has been over provisioned, the best way to try to go about doing it is to start with a baseline of the environment and the current performance metrics. 最初に次のカウンターを監視します。Counters to initially monitor include:

  • SQL Server:バッファー マネージャー\ページの予測保持期間SQL Server:Buffer Manager\Page Life Expectancy
  • SQL Server:バッファー マネージャー\ページ読み取り数/秒SQL Server:Buffer Manager\Page reads/sec
  • 物理ディスク\ページ読み取り数/秒Physical Disk\Disk Reads/sec

一般的に、バッファー プールに対して過度のメモリが環境にある場合、[ページの予測保持期間] の値は 1 秒おきに増加を続けます。すべてのデータ ページが最後にはキャッシュされるため、作業負荷の下でも低下しません。Typically if the environment has excess memory for the buffer pool, the Page Life Expectancy value will continue to increase by a value of one every second and it won't drop off under the workload because all of the data pages end up being cached. 同時に、キャッシュ増加の発生後、[SQL Server:バッファー マネージャー\ページ読み取り数/秒] が低くなります。これはまた、[物理ディスク\ページ読み取り数/秒] の低い値に対応します。At the same time, the number of SQL Server:Buffer Manager\Page reads/sec will be low after the cache ramp up occurs, which will also correspond to a low value for Physical Disk\Disk Reads/sec.

環境のベースラインを用意したら、'最大サーバー メモリ' オプションの sp_configure 値を変更し、バッファー プールのサイズを 1 GB 単位で減らします。次に、最初のキャッシュ フラッシングから状態が安定した後に、パフォーマンス カウンターへの影響を監視します。最初のキャッシュ フラッシングは通常、環境で RECONFIGURE が実行されているときに発生することがあります。Once you have your baseline for the environment, make a change to the sp_configure 'max server memory' option to reduce the size of the buffer pool by 1GB and then monitor the impact to the performance counters after things stabilize from the initial cache flushing that may typically occur when RECONFIGURE is run in the environment. [ページの予測保持期間] が環境にとって許容できるレベルであり (大量の RAM が取り付けられているサーバーの場合、>= 300 という固定ターゲットは不合理であることに留意してください)、[SQL Server:バッファー マネージャー\ページ読み取り数/秒] の数値がパフォーマンスを低下させずにディスク I/O サブシステムがサポートできる範囲内であれば、'最大サーバー メモリ' の sp_configure 値を 1 GB 減らし、環境に与える影響を監視する作業を繰り返します。If the level of Page Life Expectancy remains acceptable for your environment (keeping in mind that a fixed target of >= 300 is ridiculous for servers with large amounts of RAM installed), and the number of SQL Server:Buffer Manager\Page reads/sec is within what the disk I/O subsystem can support without performance degradation, repeat the process of reducing the sp_configure value for 'max server memory' by 1GB and continuing to monitor the impact to the environment.

サーバーのメモリ構成に関する詳細を確認してください。Learn more about server memory configuration.

サーバーのメモリ構成に関する詳細を確認してください。Learn more about server memory configuration.

TempDB の最適化Optimize TempDB

tempdb データベースのサイズと物理的配置は Operations Manager のパフォーマンスに影響を与えます。The size and physical placement of the tempdb database can affect the performance of Operations Manager. たとえば、tempdb に定義されているサイズが小さすぎる場合、SQL Server のインスタンスを再起動するたびに作業負荷をサポートするために必要なサイズに tempdb を自動増加することにシステム処理負荷の一部が占められる可能性があります。For example, if the size that is defined for tempdb is too small, part of the system-processing load may be taken up with autogrowing tempdb to the size required to support the workload every time you restart the instance of SQL Server. 最適な tempdb パフォーマンスを得るためには、運用環境で次のように tempdb を構成することが推奨されます。To achieve optimal tempdb performance, we recommend the following configuration for tempdb in a production environment:

  • tempdb の回復モデルを SIMPLE に設定します。Set the recovery model of tempdb to SIMPLE. このモデルは自動的にログ領域を再要求し、領域要件を少ない状態で維持します。This model automatically reclaims log space to keep space requirements small.
  • すべての tempdb ファイルの領域を事前に割り当てます。環境における典型的な作業負荷に対応するために十分な大きさを持つ値にファイル サイズを設定します。Preallocate space for all tempdb files by setting the file size to a value large enough to accommodate the typical workload in the environment. tempdb があまりにも頻繁に拡大させる状況が回避されます。そのような状況では、パフォーマンスに影響が出ることがあります。It prevents tempdb from expanding too frequently, which can affect performance. tempdb データベースには自動増加を設定できますが、自動増加は例外に対してディスク領域を増加するときに使用してください。The tempdb database can be set to autogrow, but this should be used to increase disk space for unplanned exceptions.
  • ディスク帯域幅を最大化するために必要な数のファイルを作成します。Create as many files as needed to maximize disk bandwidth. 複数のファイルを使用すると、tempdb のストレージ競合が減り、拡張性が改善されます。Using multiple files reduces tempdb storage contention and yields improved scalability. ただし、過度に大量のファイルを作成することは控えてください。パフォーマンスが下がり、管理費が増えることになります。However, do not create too many files as it can reduce performance and increase management overhead. 一般的なガイドラインとしては、サーバー上の (アフィニティ マスク設定があれば、それを担う) 論理プロセッサ 1 つにつきデータ ファイルを 1 つ作成します。それから必要に応じてファイル数を増やしたり、減らしたりします。As a general guideline, create one data file for each logical processor on the server (accounting for any affinity mask settings) and then adjust the number of files up or down as necessary. 一般的なルールとしては、論理プロセッサの数が 8 以下の場合、論理プロセッサと同じ数のデータ ファイルを使用します。As a general rule, if the number of logical processors is less than or equal to 8, use the same number of data files as logical processors. 論理プロセッサの数が 8 より多い場合、8 つのデータ ファイルを使用します。競合が続くようであれば、競合が許容できるレベルになるまでデータ ファイルの数を 4 の倍数単位で増やします (最大で論理プロセッサの数まで)。あるいは、作業負荷/コードを変更します。If the number of logical processors is greater than 8, use eight data files and then if contention continues, increase the number of data files by multiples of 4 (up to the number of logical processors) until the contention is reduced to acceptable levels or make changes to the workload/code. 競合が減らないようであれば、場合によっては、データ ファイルの数を増やす必要があります。If the contention is not reduced, you may have to increase the number of data files more.
  • 各データ ファイルを同じサイズにします。最適な比例書き込みを可能にします。Make each data file the same size; allowing for optimal proportional-fill performance. データ ファイルのサイズを等しくすることが重要です。比例書き込みアルゴリズムはファイルのサイズに基づくためです。The equal sizing of data files is critical because the proportional fill algorithm is based on the size of the files. データ ファイルが異なるサイズで作成されると、比例書き込みアルゴリズムは、すべてのファイルに割り当てせず、一番大きいファイルを GAM 割り当てに使用しようとします。そのため、複数のデータ ファイルを作成する目的にそぐわなくなります。If data files are created with unequal sizes, the proportional fill algorithm tries to use the largest file more for GAM allocations instead of spreading the allocations between all the files, thereby defeating the purpose of creating multiple data files.
  • 最適なパフォーマンスを得るために、ソリッドステート ドライブを利用し、高速の I/O サブシステムに tempdb データベースを置きます。Put the tempdb database on a fast I/O subsystem using solid-state drives for the most optimal performance. たくさんのディスクが直接接続されている場合、ディスク ストライピングを使用します。Use disk striping if there are many directly attached disks.
  • ユーザー データベースで使用されているディスクとは異なるディスクに tempdb データベースを置きます。Put the tempdb database on disks that differ from those that are used by user databases.

tempdb を構成するには、次のクエリを実行するか、Management Studio でそのプロパティを変更できます。To configure tempdb, you can run the following query or modify its properties in Management Studio.

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

sys.sysprocesses から T-SQL クエリの SELECT * を実行し、tempdb データベースのページ割り当て競合を検出します。Run the T-SQL query SELECT * from sys.sysprocesses to detect page allocation contention for the tempdb database. システム テーブルの出力で、待機リソースが "2:1:1" (PFS ページ) または "2:1:3" (共有グローバル割り当てマップ ページ) として表示されることがあります。In the system table output, the wait resource may show up as "2:1:1" (PFS Page) or "2:1:3" (Shared Global Allocation Map Page). 競合の程度によっては、短い間、SQL Server が応答していないように見えることもあります。Depending on the degree of contention, this may also lead to SQL Server appearing unresponsive for short periods. もう 1 つの手法は動的管理ビューを調べることです [sys.dm_exec_request または sys.dm_os_waiting_tasks]。Another approach is to examine the Dynamic Management Views [sys.dm_exec_request or sys.dm_os_waiting_tasks]. 結果には、これらの要求またはタスクが tempdb リソースを待っていると表示されます。sys.sysprocesses クエリを実行したときに強調表示されたものと同じ値が与えられます。The results will show that these requests or tasks are waiting for tempdb resources, and have similar values as highlighted earlier when you execute the sys.sysprocesses query.

前の推奨事項で割り当て競合が大きく減ることがなく、競合が SGAM ページにある場合、SQL Server の起動パラメーターにトレース フラグ -T1118 を実装します。SQL Server が再起動した後でも、このトレース フラグの効力が残ります。If the previous recommendations do not significantly reduce the allocation contention and the contention is on SGAM pages, implement trace flag -T1118 in the Startup parameters for SQL Server so that the trace flag remains in effect even after SQL Server is recycled. このトレース フラグの下で、SQL Server は範囲全部を各データベース オブジェクトに割り当てます。そのため、SGAM ページで競合がなくなります。Under this trace flag, SQL Server allocates full extents to each database object, thereby eliminating the contention on SGAM pages. このトレース フラグは SQL Server のインスタンスにあるすべてのデータベースに影響を与えることに注意してください。Note that this trace flag affects every database on the instance of SQL Server.

並列処理の最大限度Max degree of parallelism

Operations Manager を中小規模で展開する場合、SQL Server の既定の構成でほとんどのニーズに対応できます。The default configuration of SQL Server for small to medium size deployments of Operations Manager is adequate for most needs. ただし、管理グループの作業負荷が増大し、大企業クラスのシナリオになるとき (通常、エージェントにより管理されるシステムが 2,000 を超え、サービス レベルの監視、高度な代理トランザクション、ネットワーク デバイス監視、プラットフォーム非依存などを含む高度な監視機能で構成される)、本書のこのセクションの説明に基づき、SQL Server の構成を最適化する必要があります。However, when the workload of the management group scales upwards towards an enterprise class scenario (typically 2,000+ agent-managed systems and an advanced monitoring configuration, which includes service-level monitoring with advanced synthetic transactions, network device monitoring, cross-platform, and so forth) it is necessary to optimize the configuration of SQL Server described in this section of the document. 前のガイダンスで説明していない構成オプションの 1 つが MAXDOP です。One configuration option that has not been discussed in previous guidance, is MAXDOP.

Microsoft SQL Server の並列処理の最大限度 (MAXDOP) 構成オプションは、並列計画でクエリの実行に使用されるプロセッサの数を制御します。The Microsoft SQL Server max degree of parallelism (MAXDOP) configuration option controls the number of processors that are used for the execution of a query in a parallel plan. このオプションは、作業を並列で実行するクエリ計画演算子に使用される計算処理リソースとスレッド リソースを決定します。This option determines the computing and thread resources that are used for the query plan operators that perform the work in parallel. SQL Server の構成の基礎、つまり、対称型マルチプロセッシング (SMP) コンピューター、Non-Uniform Memory Access (NUMA) コンピューター、またはハイパースレッディング対応プロセッサのいずれかに基づき、並列処理の最大限度オプションを適切に構成する必要があります。Depending on whether SQL Server is set up on a symmetric multiprocessing (SMP) computer, a non-uniform memory access (NUMA) computer, or hyperthreading-enabled processors, you have to configure the max degree of parallelism option appropriately.

複数のマイクロプロセッサまたは CPU を持つコンピューターで SQL Server が実行されている場合、並列実行のたびに、並列処理の最良限度、つまり、1 つのステートメントを実行するために使用されるプロセッサの数が検出されます。When SQL Server runs on a computer with more than one microprocessor or CPU, it detects the best degree of parallelism, that is, the number of processors employed to run a single statement, for each parallel plan execution. 既定では、このオプションのその値は 0 です。SQL Server は並列処理の最大限度を決定できます。By default, its value for this option is 0, which allows SQL Server to determine the maximum degree of parallelism.

オペレーション データベース、データ ウェアハウス データベース、さらには監査データベースとの関連で Operations Manager に事前定義されたストアド プロシージャとクエリには、MAXDOP オプションは含まれていません。インストール中に、オペレーティング システムに提示されるプロセッサの数を動的に問い合わせる方法がないためです。また、クエリの実行時にマイナスの結果が現れる可能性があるため、この設定の値がハードコードされることはありません。The stored procedures and queries pre-defined in Operations Manager as it relates to the operational, data warehouse, and even audit database do not include the MAXDOP option, as there is no way during installation to dynamically query how many processors are presented to the operating system, nor does it attempt to hardcode the value for this setting, which could have negative consequences when the query is executed.

注意

構成オプションの [並列処理の最大限度] は、SQL Server が使用するプロセッサの数を制限しません。The max degree of parallelism configuration option does not limit the number of processors that SQL Server uses. SQL Server が使用するプロセッサの数を構成するには、アフィニティ マスク構成オプションを使用します。To configure the number of processors that SQL Server uses, use the affinity mask configuration option.

  • サーバーで 8 個より多いプロセッサが使用される場合、MAXDOP=8 という構成を使用します。For servers that use more than eight processors, use the following configuration: MAXDOP=8
  • サーバーで 8 個以下のプロセッサが使用される場合、MAXDOP=0 to N という構成を使用します。この構成では、N はプロセッサの数を表します。For servers that use eight or fewer processors, use the following configuration: MAXDOP=0 to N Note In this configuration, N represents the number of processors.
  • サーバーで NUMA が構成されている場合、各 NUMA ノードに割り当てられている CPU の数を MAXDOP が超えないようにしてください。For servers that have NUMA configured, MAXDOP should not exceed the number of CPUs that are assigned to each NUMA node.
  • サーバーがハイパースレッディング対応の場合、物理プロセッサの数を MAXDOP 値が超えないようにしてください。For servers that have hyperthreading enabled, the MAXDOP value should not exceed the number of physical processors.
  • サーバーで NUMA が構成されており、さらにハイパースレッディング対応の場合、NUMA ノードあたりの物理プロセッサの数を MAXDOP 値が超えないようにしてください。For servers that have NUMA configured and hyperthreading enabled, the MAXDOP value should not exceed number of physical processors per NUMA node.

sys.dm_os_tasks に問い合わせることで、並列 worker の数を監視できます。You can monitor the number of parallel workers by querying sys.dm_os_tasks.
このサーバーのハードウェア構成は、HP Blade G6、24 個のコア プロセッサ、196 GB の RAM でした。The hardware configuration of this server was an HP Blade G6 with 24 core processors and 196 GB of RAM. Operations Manager データベースをホストするインスタンスの MAXMEM 設定は 64 GB でした。The instance hosting the Operations Manager database had a MAXMEM setting of 64 GB. このセクションで提案されている最適化を実行すると、パフォーマンスが改善しました。After performing the suggested optimizations in this section, performance improved. ただし、クエリの並列処理のボトルネックは引き続き存在します。However, a query parallelism bottleneck still persisted. さまざまな値を試したところ、MAXDOP=4 を設定したときに最適なパフォーマンスが得られました。After testing different values, the most optimal performance was found by setting MAXDOP=4.

最初のデータベース サイズ調整Initial database sizing

展開から数か月以内で、Operations Manager データベース、特にオペレーション データベースとデータ ウェアハウス データベースの将来的な増加を予測することは、簡単ではありません。Estimating the future growth of the Operations Manager databases, specifically the operational and data warehouse databases, within the first several months after deployment is not a simple exercise. Operations Manager のサイズ測定ヘルパーは、ラボの試験から製品グループが導き出した計算式に基づいて潜在的増加を見積もり、合理的ですが、短期間と長期間の対比で増加に影響を与えうる要因がいくつか考慮されません。While the Operations Manager Sizing Helper is reasonable in estimating potential growth based on the formula derived by the product group from their testing in the lab, it does not take into account several factors, which can influence growth in the near term versus long term.

最初のデータベース サイズは、サイズ測定ヘルパーが提案する、その予測サイズに割り当て、断片化とそれに関わる間接費を減らします。これは、オペレーション データベースとデータ ウェアハウス データベースの場合、設定時に指定できます。The initial database size, as suggested by the Sizing Helper, should be allocated to a predicted size, to reduce fragmentation and corresponding overhead, which can be specified at setup time for the Operational and Data Warehouse databases. 設定時に十分なストレージ領域が利用できない場合、SQL Management Studio を利用することで、後でデータベースを拡張できます。それからインデックスを再作成し、適宜デフラグし、最適化できます。If during setup not enough storage space is available, the databases can be expanded later by using SQL Management Studio and then reindexed thereafter to defragment and optimize accordingly. この推奨事項は ACS データベースにも適用されます。This recommendation applies also to the ACS database.

オペレーション データベースとデータ ウェアハウス データベースの増加は、先を見越し、毎日あるいは毎週のペースで監視してください。Proactive monitoring of the growth of the operational and data warehouse database should be performed on a daily or weekly cycle. この監視は、突然の爆発的な増加を確認し、問題解決を開始するために必要です。管理パック ワークフロー (つまり、検出ルール、パフォーマンスまたはイベント収集ルール、監視または警告ルール) のバグが原因であるか、リリース管理プロセスの試験または品質確認段階で特定されなかったその他の症状が管理パックにあるのか判断します。This will be necessary to identify unexpected and significant growth spurts, and begin troubleshooting in order to determine if it is caused by a bug in a management pack workflow (that is, discovery rule, performance or event collection rule, or monitor or alert rule) or other symptom with a management pack that was not identified during testing and quality assurance phase of the release management process.

データベースの自動拡張Database autogrow

ディスクで予約されているデータベース ファイル サイズがいっぱいになると、SQL Server はある割合だけ、あるいは決められた量だけサイズを自動的に増やします。When the databases file size that has been reserved on disk becomes full, SQL Server can automatically increase the size, by a percentage or by a fixed amount. さらに、データベースの最大サイズを構成し、ディスク上の全領域が占有される事態を回避できます。Moreover, a maximum database size can be configured, to prevent filling up all the space available on disk. 既定では、Operations Manager データベースでは自動拡張は有効になっていません。データ ウェアハウス データベースと ACS データベースだけです。By default, the Operations Manager database is not configured with autogrow enabled; only the Data Warehouse and ACS databases are.

自動拡張は、突然の増加という不測の事態に備えるためにのみ利用します。Only rely on autogrow as a contingency for unexpected growth. 自動拡張ではパフォーマンス ペナルティが利用されます。トランザクション数の多いデータベースを扱うとき、このペナルティを考慮します。Autogrow introduces a performance penalty that should be considered when dealing with a highly transactional database. パフォーマンス ペナルティに含まれる項目:Performance penalties include:

  • 適切な増分を指定しない場合のログ ファイルまたはデータベースの断片化。Fragmentation of the log file or database if you don’t provide an appropriate growth increment.
  • 利用できる以上のログ領域を必要とするトランザクションを実行するとき、そのデータベースのトランザクション ログの自動拡張オプションをオンにしている場合、トランザクションの完了にかかる時間には、トランザクション ログが設定した量だけ増加するための時間が含まれます。If you run a transaction that requires more log space than is available, and you have turned on the autogrow option for the transaction log of that database, then the time it takes the transaction to complete will include the time it takes the transaction log to grow by the configured amount.
  • ログの拡張を必要とする大きなトランザクションを実行すると、トランザクション ログへの書き込みを必要とするその他のトランザクションは拡張の完了を待つ必要があります。If you run a large transaction that requires the log to grow, other transactions that require a write to the transaction log will also have to wait until the grow operation completes.

自動拡張オプションと自動圧縮オプションを組み合わせた場合、不必要なオーバーヘッドが生まれる可能性があります。If you combine the autogrow and autoshrink options, you might create unnecessary overhead. サイズが頻繁に変わらないように、拡張や圧縮を始動させるしきい値を指定してください。Make sure that the thresholds that trigger the grow and shrink operations will not cause frequent up and down size changes. たとえば、コミット時にトランザクション ログを 100 MB 増やすトランザクションを実行するとします。For example, you may run a transaction that causes the transaction log to grow by 100 MB by the time it commits. その後しばらくしてから、自動圧縮が始動し、トランザクション ログを 100 MB 減らします。Some time after that the autoshrink starts and shrinks the transaction log by 100 MB. それから、同じトランザクションを実行し、トランザクション ログを再び 100 MB 増やします。Then, you run the same transaction and it causes the transaction log to grow by 100 MB again. この例では、不必要なオーバーヘッドが作り出され、ログ ファイルを断片化させている可能性があります。いずれもパフォーマンスに悪影響を与えます。In that example, you are creating unnecessary overhead and potentially creating fragmentation of the log file, either of which can negatively affect performance.

この 2 つの設定は慎重に構成することが推奨されます。It is recommended to configure these two settings carefully. 実際、特定の構成はご利用の環境に依存します。The particular configuration really depends on your environment. 一般的に、ディスクの断片化を減らすために、一定量だけデータベース サイズを増やすことが推奨されます。In general, it is recommended to increase database size by a fixed amount in order to reduce disk fragmentation. 次の図をご覧ください。自動拡張が必要になるたびに 1024 MB 増えるようにデータベースが構成されています。See, for example, the following figure, where the database is configured to grow by 1024 MB each time autogrow is required.

クラスター フェールオーバー ポリシーCluster failover policy

Windows Server フェールオーバー クラスタリングは可用性の高いプラットフォームであり、ネットワーク接続とクラスター内のノードの健全性を常に監視します。Windows Server Failover Clustering is a high availability platform that is constantly monitoring the network connections and health of the nodes in a cluster. ネットワーク経由でノードに到着できない場合、クラスターの別のノードで、アプリケーションやサービスを復元し、オンラインに戻す回復措置が取られます。If a node is not reachable over the network, then recovery action is taken to recover and bring applications and services online on another node in the cluster. 何も変更していない既定の設定は、‘ハードの’ 障害として見なされる、サーバーの完全喪失という障害に対して最適化されています。The default settings out of the box are optimized for failures where there is a complete loss of a server, which is considered a ‘hard’ failure. 非冗長のハードウェアまたは電源の故障など、回復不可能なエラー シナリオです。These would be unrecoverable failure scenarios such as the failure of non-redundant hardware or power. そのような状況では、サーバーが失われ、フェールオーバー クラスタリングがサーバーの喪失をすばやく検出し、クラスター内の別のサーバーですぐに復元することが目標となります。In these situations, the server is lost and the goal is for Failover Clustering to quickly detect the loss of the server and rapidly recover on another server in the cluster. このようなハードの障害から迅速に回復するために、クラスターの健全性監視は、非常に活動的な初期設定です。To accomplish this fast recovery from hard failures, the default settings for cluster health monitoring are fairly aggressive. ただし、すべてのパラメーターが設定可能であり、さまざまなシナリオに柔軟に対応できます。However, they are fully configurable to allow flexibility for a variety of scenarios.

既定の設定でほとんどのお客様にとって最良の動作が提供されますが、クラスターは数インチから数マイルまで離れることがあり、信頼できないネットワーク コンポーネントがノード間に加わり、クラスターがそれにさらされる可能性があります。These default settings deliver the best behavior for most customers, however as clusters are stretched from being inches to possibly miles apart, the cluster may become exposed to additional and potentially unreliable networking components between the nodes. 別の要因に、汎用的サーバーの質が継続的に向上していることがあります。冗長コンポーネント (二重電源、NIC チーミング、マルチパス I/O など) により弾力性が向上し、非冗長ハードウェアが故障する可能性がかなり低くなっています。Another factor is that the quality of commodity servers is constantly increasing, coupled with augmented resiliency through redundant components (such as dual power supplies, NIC teaming, and multi-path I/O), the number of non-redundant hardware failures may potentially be fairly rare. ハードウェアの故障の頻度が減ったため、一時的な故障に備えてクラスターを調整するお客様もいます。ノード間の短時間のネットワーク エラーに対してクラスターの回復力を上げます。Because hard failures may be less frequent, some customers may wish to tune the cluster for transient failures, where the cluster is more resilient to brief network failures between the nodes. 既定のエラーしきい値を増やすことで、短時間だけ続くネットワーク問題に対する感度を下げることができます。By increasing the default failure thresholds, you can decrease the sensitivity to brief network issues that last a short period of time.

ここでは正解はないということを理解することが重要です。最適な設定は、特定のビジネス要件やサービス レベル契約によって異なる場合があります。It is important to understand that there is no right answer here, and the optimized setting may vary by your specific business requirements and service level agreements.

SQL Server の仮想化Virtualizing SQL Server

仮想環境では、オペレーション データベースとデータ ウェアハウス データベースについては、パフォーマンスの理由上、仮想ディスクではなく、直接接続されているストレージに保存することをお勧めします。In virtual environments, for performance reasons, it is recommended that you store the operational database and data warehouse database on a direct attached storage, and not on a virtual disk. 常に Operations Manager のサイズ測定ヘルパーを使用し、必要な IOPS を見積もり、データ ディスクにストレス テストを実施し、確認してください。Always use the Operations Manager Sizing Helper to estimate required IOPS, and stress test your data disks to verify. このタスクには SQLIO ツールを活用できます。You can leverage the SQLIO tool for this task. 仮想化 Operations Manager 環境に関してさらにガイダンスが必要な場合、「Operations Manager 仮想化のサポート」も参照してください。See also Operations Manager virtualization support for additional guidance on virtualized Operations Manager environment.

AlwaysOn と復旧モデルAlways On and recovery model

厳密には最適化ではありませんが、AlwaysOn 可用性グループに関して重要な考慮事項があります。設計上、この機能では “完全” 復旧モデルでデータベースを設定する必要があります。Although not strictly an optimization, an important consideration regarding Always On Availability Group is the fact that, by design, this feature requires the databases to be set in the “Full” recovery model. つまり、完全バックアップが完了するか、トランザクション ログのみのバックアップが完了するまで、トランザクション ログは破棄されません。Meaning, the transaction logs are never discarded until either a full backup is done, or only the transaction log. このような理由から、バックアップ方針は Operations Manager データベースの AlwaysOn 設計にとって任意ではなく、必須となります。For this reason, a backup strategy is not an optional but a required part of the AlwaysOn design for Operations Manager databases. バックアップ方針を導入しない場合、時間の経過と共に、トランザクション ログを含むディスクがいっぱいになります。Otherwise, with time, disks containing transaction logs will fill up.

バックアップ方針では、ご利用の環境の詳細を考慮する必要があります。A backup strategy must take into account the details of your environment. 一般的なバックアップ スケジュールは次の表のようになります。A typical backup schedule is given in the following table.

バックアップの種類Backup Type スケジュールSchedule
トランザクション ログのみTransaction log only 1 時間おきにEvery one hour
完全Full 毎週日曜日午前 3 時 00 分Weekly, Sunday at 3:00 AM

SQL Server Reporting Services を最適化するOptimizing SQL Server reporting services

Reporting Services インスタンスは、データ ウェアハウス データベースのデータにアクセスする際、プロキシとして機能します。The Reporting Services instance acts as a proxy for access to data in the Data Warehouse database. 管理パック内に保存されているテンプレートに基づいてレポートを生成し、表示します。It generates and displays reports based on templates stored inside the management packs.

Reporting Services の裏には、ReportServer データベースと ReportServerTempDB データベースをホストする SQL Server データベース インスタンスがあります。Behind the scenes of Reporting Services, there is a SQL Server Database instance that hosts the ReportServer and ReportServerTempDB databases. このインスタンスのパフォーマンス調整に関する一般的な推奨事項が適用されます。General recommendations regarding the performance tuning of this instance apply.

注意

SQL Server Reporting Services (SSRS) 2017 バージョン 14.0.600.1274 以降の既定のセキュリティ設定では、リソース拡張機能のアップロードは許可されていません。From SQL Server Reporting Services (SSRS) 2017 version 14.0.600.1274 and later, the default security settings do not allow resource extension uploads. これにより、レポート コンポーネントの展開中に Operations Manager で ResourceFileFormatNotAllowedException の例外が発生します。This leads to ResourceFileFormatNotAllowedException exceptions in Operations Manager during deployment of reporting components.

これを解決するには、SQL Management Studio を開き、Reporting Services インスタンスに接続し、 [プロパティ] > [詳細] を開いて、*.* を AllowedResourceExtensionsForUpload の一覧に追加します。To fix this, open SQL Management Studio, connect to your Reporting Services instance, open Properties>Advanced, and add *.* to the list for AllowedResourceExtensionsForUpload. または、SSRS の 許可リスト に Operations Manager のレポート拡張機能の完全な一覧を追加することもできます。Alternatively, you can add the full list of Operations Manager's reporting extensions to the allow list in SSRS.

次のステップNext steps

ファイアウォールの背後にあるレポート データ ウェアハウスをホストする構成方法を理解するには、「ファイアウォール間でレポート データ ウェアハウスを接続する」を参照してください。To understand how to configure hosting the Report data warehouse behind a firewall, see Connect Reporting Data Warehouse Across a Firewall.