データベース内のすべてのテーブルの非圧縮サイズを見つける
Dynamics AXには、メモリにロードしてキャッシュするようにテーブルを構成できるキャッシュメカニズムがあります。このキャッシュは、メモリの問題を防ぐために一定のKBに制限されています。私が話している設定は呼び出さentiretablecacheれ、単一のレコードが要求されるとすぐにテーブル全体をメモリにロードします。 最近まで、いくつかのスクリプトに依存して、この設定を持つテーブルのサイズを検証し、テーブルサイズがこの制限を超えているかどうかを確認していました。 しかし、今では圧縮が作用し始めており、sp_spaceusedやsys.allocation_unitsのようなものが、圧縮されたデータによって実際に使用されているスペースを報告しているようです。 明らかに、アプリケーションサーバーは圧縮されていないデータを処理しているため、SQL Serverのディスク上のデータサイズは無関係です。非圧縮データの実際のサイズが必要です。 私はsp_estimate_data_compression_savingsを知っていますが、名前が示すように、これは単なる見積もりです。 サイズをできるだけ正確にしたいと思います。 私が考えることができる唯一の方法は、圧縮テーブルと同じ構造の非圧縮テーブルを作成し、そのシャドウテーブルに圧縮データを挿入し、そのシャドウテーブルのサイズを確認する、複雑な動的SQLでした。 言うまでもなく、これは少し面倒で、数百GBのデータベースで実行するには時間がかかります。 Powershellはオプションの可能性がありますが、すべてのテーブルを反復処理しselect *てスクリプトでサイズを確認するのは好ましくありません。 要するに、可能であれば、アプリケーションに提示された方程式から断片化された状態で圧縮されないため、各テーブルのサイズを取得する方法が必要です。私はさまざまなアプローチを受け入れています。T-SQLをお勧めしますが、Powershellや他の創造的なアプローチには反対しません。 アプリケーションのバッファがデータのサイズであると仮定します。bigintは常にbigintのサイズであり、文字データ型は1文字あたり2バイト（ユニコード）です。BLOBデータはデータのサイズも取ります。enumは基本的にintであり、数値データはnumeric（38,12）、datetimeはdatetimeのサイズです。また、NULL値はありません1900-01-01。空の文字列として保存されるか、ゼロになります。 これがどのように実装されているかについてのドキュメントはありませんが、前提はPFEおよびサポートチームが使用するいくつかのテストとスクリプトに基づいています（また、チェックはアプリケーションに組み込まれ、アプリは認識できないため、明らかに圧縮を無視します）基になるデータが圧縮されている場合）、テーブルサイズもチェックします。例のこのリンクは述べています： 大きなテーブルにはEntireTableキャッシュを使用しないでください（AX 2009では128 KBまたは16ページ以上、AX 2012では「テーブルキャッシュサイズ全体」アプリケーション設定[デフォルト：32KB、または4ページ]）–代わりにレコードキャッシュに移動します。