Planning Server データベースの保守

各 Planning Server インストール環境には、Planning システム データベース (PPSPlanningSystem) と Planning サービス データベース (PPSPlanningService) が 1 つずつあります。

Planning システム データベースには、次のコンポーネントが含まれています。

• Planning システム セキュリティ データ

• Planning タイプ ライブラリ データ

• Planning システム レベル構成データ

• Planning アプリケーション レベル メタデータ

Planning システム データベースと Planning サービス データベースは両方ともサイズが小さく、比較的小さいサイズのまま維持されます。

Planning システム データベースと Planning サービス データベースは、手動で作成するか、Planning Server 構成マネージャを実行しているときに作成できます。

Planning Server 構成マネージャでこれらの 2 つのデータベースを作成する場合は、どちらのデータベースも既定のデータ ファイル サイズが 50 MB で、自動拡張が 50 MB に設定されているプライマリ ファイル グループに配置されます。既定のログ ファイルのサイズは 20 MB、自動拡張は 20 MB に設定されます。

これら 2 つのデータベースを手動で作成する場合、ファイル グループを選択し、データベースとログ ファイルの初期サイズの既定の設定を変更できます。

SQL Server 2005 は、データベースを一連のオペレーティング システム ファイルにマップします。データとログ情報が同一のファイル内に混在することはなく、個々のファイルは 1 つだけのデータベースによって使用されます。データベースのデータ ファイルとログ ファイルの詳細については、「SQL Server」を参照してください。

Planning Server によって自動的に作成されるすべての Planning Server データベースでは、既定のデータ ファイルの初期サイズは 50 MB に、自動拡張は 50 MB に設定されています。

アプリケーション データベースおよびステージング データベースでは、Planning Server データベース管理者が容量計画を実行し、組織のデータおよびデータ保存ポリシーを使用して、データ ファイルの適切な初期サイズを決定することをお勧めします。たとえば、各モデル サイトに設定する望ましいモデル数やアプリケーションに設定する望ましいモデル サイト数を決定します。

データベースのデータ ファイルとログ ファイルを設計するときの一般的なガイドラインの一部を次に示します。

• データ ファイルおよびログ ファイルの自動拡張を有効にします。

• データベースとログ ファイルに適切な初期サイズを割り当てます。

• データ ファイルの最大サイズを設定して、ディスク領域がないときに領域を使い切らないようにします (複数のデータベースを使用する場合は特に重要)。

• データ ファイルの拡張幅を適切なサイズにを設定します (推奨 : 1 GB 以下の固定幅。ファイルの即時初期化が非常に役立ちます)。

• データ ファイルの即時初期化を許可にすることを検討します。

• データ ファイルおよびログ ファイルに対して RAID テクノロジを検討します。

• ログ ファイルを 1 つだけ割り当てます。

• ログ ファイルを別のドライブに分離します (パフォーマンスを向上させるには、データ ファイルではなくログ ファイルを別の物理ディスクに配置する必要があります)。

ログ ファイルの監視も重要です。次のクエリを実行することにより、ログ ファイルの状態を監視できます。

select * from 
sys.dm_os_performance_counters 
where counter_name like '%Log%'
and instance_name = 'Alpine_Ski_House_AppDB'

詳細については、「SQL Server」を参照してください。

ログ ファイルの自動拡張を最小限に抑えるには、ログに適切なサイズを事前に割り当てることをお勧めします。ログ ファイルのサイズは次の 2 つの要因に応じて異なります。ログ バックアップの頻度と Planning Server システムの活動です。

一般的なガイドラインでは、ログ ファイルにデータベース ファイルの 10% または 15% を事前に割り当てますが、実際のログ ファイルのサイズは、ログ バックアップの頻度に応じて異なります。

ログ ファイルを 5 分ごとにバックアップし、Planning の活動が普通である場合、ログ ファイルの初期サイズとして次のように割り当てることをお勧めします。

• Planning システム データベース : 50 MB

• Planning サービス データベース : 200 MB

• Planning アプリケーション データベース : 1 GB

• Planning ステージング データベース:1 GB

• Planning 外部データベース : 400 MB

これらの数値は、ログ バックアップの頻度に基づいて、変更することができます。たとえば、ログを 10 分ごとにバックアップする場合は、ログ ファイルの初期サイズをさらに大きくする必要があります。ログ ファイルを 2 分ごとにバックアップする場合は、より小さいログ ファイル サイズを割り当てることができます。

ログ ファイルの適切な初期サイズに加え、ログ ファイルを固定量 (パーセントではない) ずつ自動拡張するように設定し、拡張可能な最大サイズも設定することをお勧めします (制限のない拡張サイズを設定しないでください)。

仮想ログ ファイル (VLF) をできるだけ小さくすることも、SQL Server のパフォーマンスにとって重要です。このタスクの実行の詳細については、「SQL Server」を参照してください。

ログ ファイルを定期的にバックアップすることは重要です。運用システムでは、データ損失を防ぐため、SQL Server を実行するコンピュータに、ログ バックアップを定期的 (5 または 10 分ごとなど) に実行するスケジュールを設定することを強くお勧めします。データベース回復モードが "フル" で、ログを長時間バックアップしないと、データベースは "ログがいっぱいです" というエラーが表示されるまで拡張し続けます。

ログのバックアップを実行するときのシステムにかかるオーバーヘッドはわずかです。そのため、頻繁にバックアップを行っても負担になりません。ログ ファイルの断片化が進むほど、ログ バックアップでの負担が大きくなります。このため、システムに対して適切なサイズのログ ファイルを事前に割り当てることが重要で、その結果ログ バックアップのパフォーマンスが向上します。

ログ ファイルがいっぱいになったとき実行できるのは、ログをバックアップすることだけです。ログのバックアップにより、非アクティブなログが消去されるので、ログ ファイルのサイズが縮小します。トランザクションがまだコミットされていないため、ログをバックアップしてもアクティブなログは消去されません。

データの損失について懸念する必要のない非運用環境では、ログを切り捨てて消去することができます。ただし、この操作はデータの損失が許容されるプロトタイプ、開発またはテスト システムにおいてのみ実行してください。

運用システムまたは非運用システムのどちらでも、ログ ファイルの管理 (バックアップまたは切り捨て) を行う必要があります。これを怠ると、ログ ファイルはすぐに拡張し、Planning システムのパフォーマンスに影響します。

サンプル スクリプト

このセクションでは、ログのバックアップまたは切り捨てを実行するサンプル スクリプトを紹介します。SQL Server を実行しているコンピュータに、次のスクリプトを実行するスケジュールを設定することが重要です。テスト環境またはプロトタイプ環境での作業時、ログのバックアップや切り捨てに時間をかけたくない場合は、SQL Server Management Studio のデータベースのプロパティ ページを変更して、データベース回復モードを既定のフル モードから簡易モードに設定します。

重要 :
簡易モードは運用システムでは使用しないでください。データベース回復モデルの詳細については、「SQL Server」を参照してください。

-- Truncate Log sample script
-- Use only if you are in testing environment and do not care about DB backup.
BACKUP LOG 'Alpine_Ski_House_AppDB WITH NO_LOG
GO
BACKUP LOG 'Alpine_Ski_House_AppDB WITH TRUNCATE_ONLY
GO

USE 'Alpine_Ski_House_AppDB
GO
EXEC sp_helpfile 
GO
-- get the log file name for this DB

-- now shrink the log file
USE 'Alpine_Ski_House_AppDB
GO
DBCC SHRINKFILE(Alpine_Ski_House_AppDB_log, TRUNCATEONLY)
GO

-- Backup log sample script
-- For any DB that you care about data loss, you should back up DB and the 
-- log, that is the only good way to clear the inactive logs.

-- Create dump devices first
EXEC sp_addumpdevice 'disk', 'ServiceDBData', 
'C:\work\ServiceDBData.bak';
GO

EXEC sp_addumpdevice 'disk', 'ServiceDBLog', 
'C:\work\ServiceDBLog.bak';
GO

-- Back up database and log file
USE PPSPlanningService
GO
BACKUP DATABASE PPSPlanningService TO ServiceDBLog;
GO
BACKUP LOG PPSPlanningService TO ServiceDBLog
GO
DBCC SHRINKFILE(PPSPlanningService_log, TRUNCATEONLY)
GO

重要 :
ログ ファイルのサイズを小さくしてパフォーマンスの向上とデータの損失防止を実現するためには、非運用システム内ではログを切り捨てるか、ログを定期的にバックアップするように SQL Server を実行するコンピュータを設定する必要があります。ログ ファイルが大きくなるままにしておくと、Planning Server のパフォーマンスが大幅に低下します。また、時間の経過とともに、最終的には膨大なディスク領域を消費します。

TempDB のサイズがシステムのパフォーマンスに影響する場合があります。たとえば、TempDB に定義されているサイズが小さすぎる場合、SQL Server (MSSQLSERVER) サービスを再起動するたびに、作業負荷のサポートに必要なサイズまでデータベースが自動拡張されるため、システム処理負荷の一部が占有される可能性があります。TempDB のサイズを増やすことでこのオーバーヘッドを回避できます。

TempDB の物理的な配置とデータベース オプションの一般的な推奨事項を次に示します。

• 必要な場合に TempDB の自動拡張を許可します。

• より多くの領域が必要となったときにファイルが自動的に拡張されないようにするには、TempDB ファイルの元のサイズを適切なサイズに設定します。TempDB が頻繁に拡張されると、パフォーマンスに影響する場合があります。

• TempDB ファイルの拡張率を妥当なサイズに設定し、拡張サイズが小さくなり過ぎないようにします。ファイルの拡張サイズが小さすぎる場合、TempDB に書き込まれるデータの量の割にはデータベースが頻繁に拡張される可能性があります。これはパフォーマンスに影響します。

• 良好なパフォーマンスを確保するため、高速入出力サブシステム上に TempDB を配置します。複数のディスクに TempDB をストライプ化し、パフォーマンスの向上を図ります。ユーザー データベースで使用されるディスクとは異なるディスクに TempDB を配置します。TempDB を新しい場所に移動する方法の詳細については、「SQL Server」を参照してください。

SQL Server を再起動すると、TempDB のサイズは初期の構成サイズに戻り、必要に応じて拡張します。そのため、TempDB が断片化されてオーバーヘッドが生じる場合があります。これは作業負荷のパフォーマンスに影響します。TempDB に事前に適切なサイズを割り当てることをお勧めします。

Planning Server データベースでは Row Versioning 機能を使用して "Read Committed 分離" が行われるため、パフォーマンス向上のためには TempDB をそれなりの大きさに設定する必要があります。パフォーマンスを向上させるには、TempDB の初期サイズを少なくとも 500 MB に設定してください。さらなるパフォーマンス向上を図るには、TempDB の初期サイズを 1 GB に設定します。

TempDB の空き領域を監視することが重要です。詳細については、「SQL Server」を参照してください。

割り当ておよび管理のために、データベース オブジェクトとファイルをまとめてファイル グループにグループ化する必要があります。

Planning システム データベースと Planning サービス データベースは、Planning Server のセットアップ時に作成できます。または、Planning Server ソフトウェアをインストールする前に手動で準備できます。Planning Server 構成マネージャでこれら 2 つのデータベースを作成する場合は、そのファイル グループを指定することはできません。これら 2 つのデータベースはサイズが比較的小さいため、ファイル グループを使用する必要はほとんどありません。

Planning アプリケーション データベースは、アプリケーションの作成プロセスで作成されます。アプリケーション データベースを作成するときには 2 つのオプションがあります。データベース管理者がアプリケーションの作成プロセスで CREATE DATABASE/CREATE TABLE をカスタマイズできるように、Planning 管理コンソールの [アプリケーションの作成] ユーザー インターフェイスの [手動による実行]**** を指定できます。具体的には、データベース管理者は、アプリケーション データベースを作成するときにファイル グループ情報を追加できます。SQL Server のスクリプトがアプリケーションの作成プロセスで生成された後、データベース管理者は CreateAppDB.sql と TypeLibMasterSchema.sql を編集し、これらのスクリプトにファイル グループ情報を追加してから実行できます。

メモ :
CREATE DATABASE または ALTER DATABASE でファイル グループを作成できます。CREATE TABLE ではテーブルにファイル グループを指定できます。新しいファイル グループを作成した場合は、新しいファイル グループが使用される前に必ず新しいファイル グループにファイルを追加してください。

ファイル グループの詳細については、「SQL Server」を参照してください。