ST0207028

　データベース（テーブル）の断片化チェックについて

Tips!

データベースの更新により、データベースのファイル、テーブル、インデックスが断片化することでパフォーマンスが低下する可能性があります。Adaptive Server Anywhere Ver8では、これらの断片化レベルを査定する情報を取得することが可能です。

1. データベース・ファイルの断片化

データベース・ファイルが断片化が大きくなると、パフォーマンスに影響が出ます。
これはディスク断片化であり、データベースが大きくなるにつれ、より影響度は大きくなります。

- データベースを起動すると、データベース・サーバが各 DB 領域内でファイルの断片化数を判断します。断片化の数が 1 より大きい場合は、サーバのメッセージ・ウィンドウに次の情報が表示されます。

「nnn フラグメントで構成される mydatabase.db データベース・ファイル」（nnn はフラグメント数）

- db_property システム関数のDBFileFragments データベース・プロパティを使用し、データベース・ファイルの断片化の数を取得できます。
（例）次の文は、現在のデータベースのフラグメント数を返します。

　　select db_property ( 'DBFileFragments' )

2. テーブル、インデックスの断片化

ローが連続して格納されていない場合や、複数ページに分割されている場合には、ページへのアクセスが増大することでパフォーマンスが低下します。

- sa_table_fragmentation ストアド・プロシージャを使用すると、データベース・テーブルの断片化レベルに関する情報を取得できます。このプロシージャを実行するには、DBA 権限が必要です。
（例）次の文は、sa_table_fragmentation ストアド・プロシージャを呼び出します。

　　CALL sa_table_fragmentation (['table_name' [,'owner_name']])

- 同様にインデックスの断片化レベルに関する情報はsa_index_density ストアド・プロシージャにより取得できます。同じく実行するには、DBA 権限が必要です。
（例）次の文は、sa_index_density ストアド・プロシージャを呼び出します。

　　CALL sa_index_density (['table_name'[,'owner_name']])

⇒ データベースのアンロード／再ロードは、システム・テーブルを含むすべてのテーブルの断片化を解除するという点で最も良い方法ですが、対象のデータベースへの連続アクセスがあるという要件のため、データベース全体の再構築が難しい場合には、REORGANIZE TABLE 文が役立ちます。テーブルの再編成を実行しても、データベース・アクセスは中断されません。
（注意）インデックスについては注意が必要ですのでオンライン・ヘルプをご参照下さい

これらのプロシージャやSQL 文を使用してイベント・ハンドラを作成することで、更新頻度の高いテーブルに対し、任意のフラグメント数を超えた場合には再編成をおこなう等の処理を定期的に実行させることが可能です。