Skip to main content

 

 

 

Template:OutSystems/Documentation_KB/Breadcrumb_New_Layout

 

Template:OutSystems/OSLanguageSwitcher
Language:

 

 

 

 

 
OutSystems

SQL Serverのベストプラクティス

この記事では、SQL ServerデータベースでOutSystemsプラットフォームサーバーを操作する際にOutSystemsが推奨する現在のベストプラクティスを紹介します。

ハードウェアの推奨事項

このセクションでは、ハードウェアを購入する前やハードウェアプラットフォームを再評価する際に検討すべき対象のリストを示します。

CPU

SQL Serverは複数のCPUを利用できます。デュアルコアテクノロジーの登場により、サーバーのCPU能力を簡単にほぼ2倍にすることができるようになり、あらゆるシステムがこの恩恵を受けています。

CPUを選択する際には、L2キャッシュが大きいCPUを選択してください。キャッシュが大きいほど、CPUがメインメモリにアクセスする必要が少なくなるため、パフォーマンスが向上します。これがさらに重要になるのは、サーバーで複数のソケットを使用する場合です。ソケットが多いほど、保持する必要があるL2キャッシュが多くなります。

ただし、小規模なサーバー(2つのソケットを備え、各ソケットにデュアルコアCPUがインストールされているサーバー)とわずかなデータベースのほうが、大規模な8ウェイサーバーよりもパフォーマンスに優れている場合があることに留意してください。これは、サーバーに対して発生している負荷に応じて、また他のサーバーが設計上処理する種類のデータベース負荷にどの程度近い負荷になるかに応じて異なります。

メモリ

デフォルトでは、SQL Serverは可能な限り多くのメモリを使用しようとします。オペレーティングシステムに256MBを残してSQL Serverのメモリ使用量を構成します。

ハードディスク

I/Oボトルネックは、SQL Serverで最も一般的なボトルネックです。保存されるデータの量が増えると、I/Oサブシステムにかかる負荷も増えます。これに対処する方法について以下に詳しく説明します。

RAIDの概要

サーバーのI/Oサブシステムを構成する際に、選択するRAIDにはいくつかのレベルがあります。

選択するRAIDレベルに関係なく、SQL Serverの推奨ストライプサイズは64Kbです。

以下に、SQL Serverのパフォーマンスに関連する最も一般的な各レベルについて簡単に説明します。

RAIDレベル 説明
0 ストライプセットとも呼ばれ、このセットに含まれるディスクに分散している個別の情報チャンクは各ディスクで保持されます。これはフォールトトレラントではありませんが、最適な読み取り/書き込みパフォーマンスを提供します。RAID 0のディスクセットは2つのドライブで始まりますが、拡張してI/Oパフォーマンスを向上させることができます。ただし、ドライブを追加して、ディスクを増設するにつれてパフォーマンスが低下します。いずれかのドライブが故障すると、復旧できません。
1 ミラーセットとも呼ばれ、このセットに含まれるディスクは互いにミラーリングします。これは、すべてのドライブが情報の読み取り/書き込みを行う必要があるため、ディスク領域とパフォーマンスをある程度犠牲にして最適なフォールトトレランスを提供します。RAID 1のディスクセットは2つのドライブで始まります。故障していないドライブがアレイに1つ残っている限り、アレイを復旧できます。
5 RAID 5は、すべてのメンバーに分散しているパリティデータを含むブロックレベルのストライピングを使用しており、冗長性のコストが低いため広く普及しています。RAID 5のディスクセットは3つのドライブで始まりますが、必要に応じてドライブを追加できます。いずれかのドライブを失ってもアレイは引き続き動作し、故障したドライブが交換されるとアレイが再構築されます。ただし、アレイを再構築すると、ディスクがI/O容量を使用して新しいディスクを再構築するため、パフォーマンスが低下します。再構築が完了する前に2番目のドライブが失われると、データが失われます。
10 (1+0) これはネストされたRAIDレベルであり、2つの異なるRAIDレベルを併用してパフォーマンスやフォールトトレランスを高めます。この場合、RAID 0ストライプはRAID 1ドライブアレイの2つ以上のセットで作成されます。ディスクセットは4つのドライブで始まり、2つのドライブアレイに分散されます。フォールトトレランスを高めるにはディスクアレイにあるドライブの数を増やし、パフォーマンスを改善するにはアレイの数を増やします。いずれかのミラーセットにあるドライブがすべて故障するまで、データは失われません。つまり、1つのミラーが完全に消去されない限り、故障がいくつあってもアレイは正しく動作し続けることができます。

ストレージサブシステムの設計

ストレージサブシステムの設計には、慎重な検討と考慮が必要です。設計上の選択を決定した後に設計を変更すると、コストがかかるため綿密な計画を立てる必要があります。

以下の点を考慮してください。

  • 他の主要なアプリケーションを備えたサーバーでSQL Serverを実行しないでください。SQLはそうしたアプリケーションとI/O容量を共有することになります。

  • OutSystemsプラットフォームのデータベースをSQL Serverと共通のプラットフォームに配置します。

ストレージサブシステムを設計する場合、特定のストレージニーズに対応できる小さな要素に分割するほうが簡単です。

3つの異なるファイルセットのI/O要件を調べることにより、ストレージニーズを以下の3つの要素に分割できます。

  • システムファイル

  • データファイル

  • ログファイル

ファイルタイプ 説明
システムファイル システムファイルは、ページファイルやSQL Serverのバイナリなど、Windows用のファイルです。このサブシステムは主に読み取り操作が中心となります。しかし、主たる関心事はI/Oパフォーマンスよりも整合性とフォールトトレランスを確保することです。RAIDレベル1、5、10が適切ですが、RAID 1が最も一般的です。
データファイル(.mdf、.ndf) データファイル(.mdf、.ndf)は、SQLがデータベースのデータとスキーマ情報をすべて格納するファイルです。これらのファイルにかかる負荷は、データベースが主にトランザクション指向であるか、書き込み負荷を高めているか、または一般に読み取り負荷が高くなる分析的役割を担っているかによって異なります。RAID 10レベルが推奨されるのは、最適なフォールトトレランスと最高速度を実現するためです。
ログファイル(*.ldf) トランザクションログファイル(*.ldf)は、データベースのジャーナリングが行われるファイルであり、適切なデータベース復旧を保証するうえで重要です。データベース復旧アクションを除いて、主に書き込み負荷が中心となります。RAID 1またはRAID 10が推奨されます。

これらのファイルセットで最大のパフォーマンスを得るには、64k(推奨)のNTFSブロックサイズを使用する必要があります。64ビットシステムでは、このサイズをさらに高く設定できますが、64kを超える場合は最初にテストシステムで試してください。

オペレーティングシステムでは、4~32k程度のブロックサイズを使用する必要があります。

SANを使用する場合は、ご利用のRAIDのタイプに最適なストライプサイズを構成するための推奨ベストプラクティスについてベンダーにお問い合わせください。

SQL Serverの推奨事項

データベースファイル

ファイルのサイズ設定

データベースを作成する際に、データベースファイルがデータベースに占める領域を指定する必要があります。想定する初期データ量を格納するのに十分な大きさのファイルを作成し、さらにファイルの拡張も考慮する必要があります。

また、ディスク領域を固定量で自動的に拡張するようにデータベースファイルを構成する必要があります。これにより、データベースは時間の経過とともに拡張します。ただし、データベースを週に何度も拡張する必要がないように注意してください。そのような状況が発生した場合は、拡張量のサイズを増やします。

さらに多くのデータを読み込むことがわかっている場合を除き、データファイルのサイズを2GBにし、トランザクションログファイルのサイズを512MBに設定します。どちらのファイルも512MBずつ自動拡張するように設定する必要があります。

データファイルが8GBを超える場合は、データを8GBのデータファイルに分割して、SQL Serverによる異なるデータファイルへの同時アクセスを利用することを検討してください。

ファイルの配置

ファイルセットごとに異なるI/Oニーズがあるため、必要なパフォーマンスを実現するように設計された個別のボリュームにファイルを配置するのが最適です。

サーバーがすでに構築されている場合でも、必ず各ファイルセットのニーズを理解したうえで、ファイルセットを使用して現在の環境を最適化してください。特に、ログファイルとデータファイルを異なる物理I/Oサブシステムに分離すると、通常はパフォーマンスが大幅に向上します。

また一方、物理ディスクを共有するディスクボリュームでは、パフォーマンスが低下します。

SANを使用する場合は、SQL Serverを使用するようにSANを構成するための推奨ベストプラクティスについてベンダーにお問い合わせください。

デフラグ

データベースファイルは、ファイルのフラグメント化を最小限に抑えるために、空き領域のチャンクが大きいボリュームに配置する必要があります。

データベースを普通に使用しているとファイルが大きくなるため、ファイルのフラグメント化が進む場合があります。デフラグタスクを定期的に実行するようにスケジュールを設定する必要があります。これにより、フラグメント化は最小限に抑えられます。データベースの圧縮については、以下の説明もご覧ください。

SQL Serverの保守計画

保守計画を適切に構成することで、データベースのピークパフォーマンスレベルを維持しながら定期的にデータをバックアップできるようになります。

整合性チェック

完全バックアップを実行する前に、整合性チェックを少なくとも週単位で行う必要があります。これにより、データベースが破損した後にバックアップが実行されなくなり、DBAの介入が求められます。

ただし、軽微なエラーを修正するというオプションは、データベースをシングルユーザーモードにする必要があるため使用しないでください。これは本番環境では推奨されません。

インデックスの再編成

インデックスは大きくなるにつれてフラグメント化されます。インデックスの再編成を設定すると、SQL Serverが該当のインデックスを再編成します。このプロセスはシステムリソースの使用量を減らし、SELECTを実行できるようにするインデックスとともにオンラインで使用できます。ただし、インデックスが大幅にフラグメント化されている場合はインデックスを再構築することで、より良い結果が得られます。

インデックスの再編成は、現在のフラグメント化のレベルを踏まえてDBAが評価する必要があります。1日あたりのデータ変更回数が多くなれば、この必要性も高まります。通常、これは週単位または月単位で行われます。

インデックスの再構築

インデックスを再構築すると、SQL Serverが既存のインデックスを削除し、インデックスで使用されていたリソースを解放して、連続するページにインデックスを再作成します。これはリソースをさらに集中的に使用する操作であり、インデックスの再編成と同様の結果になります。

インデックスの再構築は、現在のフラグメント化のレベルを踏まえてDBAが評価する必要があります。1日あたりのデータ変更回数が多くなれば、この必要性も高まります。通常、これは週単位または月単位で行われます。

統計の更新

SQL Serverのクエリガバナーはテーブルとインデックスの統計を使用して、各クエリに適したインデックスを決定します。統計が古くなると、クエリ時間を短縮する適切なインデックスが使用されないおそれがあります。

データを変更する頻度に応じて、保守計画で統計を再構築する必要があります。データがほぼ一定である場合、テーブルの内容に対して毎日から毎週大幅な変更があるシステムでは、標準値が日単位になります。

バックアップ

SQL Serverは、ご利用のデータベースに応じて使用可能なバックアップの種類に制限をいくつか設定しています。たとえば、マスターデータベースは差分バックアップをサポートしていません。

システムデータベースとユーザーデータベースで別の保守計画を立てることを推奨します。これにより、特定のデータベースのニーズに合わせて各保守計画を微調整できます。また、1つのデータベースで保守計画が失敗しても、他のすべてのデータベースでは保守計画を実行できます。マスターデータベースは復旧手順に不可欠であり、マスターデータベースには別の保守計画を保持することを推奨します。

データベース 当初の推奨バックアップ方式 オプションのバックアップ方式
マスター 週単位の完全バックアップ、日単位のトランザクションログのバックアップ 週単位の完全バックアップ、日単位のトランザクションログのバックアップ
モデル、MSDB、その他のシステムデータベース 週単位の完全バックアップ、日単位のトランザクションログのバックアップ 週単位の完全バックアップ、日単位のトランザクションログのバックアップ
OutSystemsプラットフォームのデータベース 週単位の完全バックアップ、日単位のトランザクションログのバックアップ 週単位の完全バックアップ、日単位の差分バックアップ、時間単位のトランザクションログのバックアップ

1日あたりのトランザクション数が多い場合は、バックアップの週の途中でOutSystemsプラットフォームのデータベースの差分バックアップを導入することもできます。これにより、最後の完全バックアップ、最後の部分バックアップ、最後の部分バックアップの後に発生したトランザクションログのバックアップの順に復元するだけで、より速くデータベースを復元できるため、復旧時間が短縮される場合があります。

また、トランザクションログのバックアップの作成頻度を高めることも検討できます。たとえば、3時間ごとにトランザクションログのバックアップを作成することで、データ損失期間を短くすることができます。

完全バックアップの頻度を高めると、トランザクションログに必要な領域も減少します。

データベースの圧縮

保守計画では、データベースの圧縮操作を実行しないでください。データベースを圧縮するとディスク領域が解放されるため、SQL Serverは後でファイルを拡張しなければならなくなります。これにより、時間の経過とともにファイルが大規模にフラグメント化されていきます。

必要に応じて、DBAがデータベースの空き領域を評価し、手動で圧縮操作を実行します。こうした操作の後、インデックスを再構築して統計を更新することを推奨します。

追加情報

SQL Serverの詳細については、以下をご覧ください。

  • Was this article helpful?