これはデータベースで一般的です。アクセス頻度の低いブロックが含まれていることがわかっているデータベースも、FabricPool階層化の候補になります。たとえば、サプライチェーン管理データベースには履歴情報が含まれている可能性があります。この情報は、必要に応じて利用できなければなりませんが、通常の運用中はアクセスできません。FabricPoolを使用すると、非アクティブなブロックを選択的に再配置できます。

たとえば、FabricPoolで実行されているデータファイルの場合、 tiering-minimum-cooling-days 90日の期間には、過去90日間にアクセスされたブロックがパフォーマンス階層に保持されます。ただし、90日間アクセスされなかったデータはすべて大容量階層に再配置されます。それ以外の場合は、通常のアプリケーションアクティビティで正しいブロックが正しい階層に保持されます。たとえば、データベースが通常、過去60日間のデータを定期的に処理するために使用されている場合、 tiering-minimum-cooling-days 期間を設定できるのは、アプリケーションの自然なアクティビティによって、ブロックが早期に再配置されないようにするためです。

。 auto データベースには注意してポリシーを使用する必要があります。多くのデータベースには、四半期末のプロセスやインデックスの再作成などの定期的なアクティビティがあります。これらの操作の期間が tiering-minimum-cooling-days パフォーマンスに問題が生じる可能性があります。たとえば、四半期末の処理で1TBのデータをまだ使用していない状態で処理する必要がある場合、そのデータは大容量階層に配置される可能性があります。大容量階層からの読み取りは非常に高速であることが多く、原因のパフォーマンスに問題はない可能性がありますが、正確な結果はオブジェクトストアの設定によって異なります。