web-dev-qa-db-ja.com

これを頻繁に統計を更新することは正常ですか？

ソーステーブルのデータを処理し、1日に何度も（約20,000回）実行されるストアドプロシージャがあります。

パラメータスニッフィングが原因で、ときどきぎくしゃくしていると思います。これを修正するための手順で、関連するテーブル（8つのテーブル）の統計を更新しています。

それが詰まると、未処理のデータのバックログが蓄積されます（カウントを監視することができます）。

統計を更新すると、バックログは即座にクリアされます。

私は1日に約10回（ほぼ1時間に1回）統計を更新しています。これは正常に見えますか、それとも修正する必要があるより大きな問題がありますか？

sql-serversql-server-2016statisticsrecompile
1
J.D.

パラメータスニッフィングの問題を修正するには、いくつかの方法があります。

統計を1日に10回更新する場合、特にそれがパフォーマンスの問題を引き起こしている場合は、他のオプションを検討します。

統計情報の更新が、パラメータスニッフィングの問題を修正するものではない可能性があります。統計の更新により、プランがキャッシュからフラッシュされます（これにより問題が修正されている可能性があります）。キャッシュからそのプランのみをフラッシュすると、統計を再構築する必要なく、おそらく同様に機能します;）

もし私があなただったら、最初からそれを取り、どのパラメータのセットがSQLに悪い実行計画をとらせるかを見つけます。これができたら、それを修正する方法を検討し始めることができます。

たとえば、QueryStoreを使用してこれを修正し、SQLが常に「適切な」実行プランを使用するように強制できます。

場合によっては、適切なインデックスがパラメーターのスニッフィングの問題を修正することもあります（SQLが、パラメーターが何であれ、適切な別の実行プランを構築する可能性があります）。

2
Dominique Boucher

（おそらくデフォルトの）サンプリングパーセンテージでは、統計情報を長期間使用するのに十分ではないシナリオに遭遇している可能性があります。次のクエリを使用して、最後のUPDATE STATISTICSステートメントで使用されたサンプルレートをすばやく確認できます。

SELECT  OBJECT_SCHEMA_NAME(st.object_id) + '.' + OBJECT_NAME(st.object_id) AS TableName
    ,   col.name AS ColumnName
    ,   st.name AS StatsName
    ,   sp.last_updated
    ,   sp.rows_sampled
    ,   sp.rows
    ,   (1.0*sp.rows_sampled)/(1.0*sp.rows) AS sample_pct
FROM sys.stats st 
    INNER JOIN sys.stats_columns st_col
        ON st.object_id = st_col.object_id
        AND st.stats_id = st_col.stats_id
    INNER JOIN sys.columns col
        ON st_col.object_id = col.object_id
        AND st_col.column_id = col.column_id
    CROSS APPLY sys.dm_db_stats_properties (st.object_id, st.stats_id) sp
--WHERE OBJECT_SCHEMA_NAME(st.object_id) + '.' + OBJECT_NAME(st.object_id) = 'dbo.Mytable'     -- <-- uncomment to filter for a specific table
ORDER BY 1, 2

問題の原因となっている表をフィルタリングして、サンプルレートが低いことがわかった場合は、サンプルレートを増やして、統計が長期間にわたって関連性を維持するかどうかを確認することができます。 FULLSCANsが必要な場合もあります。以下は、サンプルレートの増加に関して私が話していることを示すいくつかの例です。

-- reference 20 percent of the column table when building the stat
UPDATE STATISTICS dbo.MyTable myTableStatName WITH SAMPLE 20 PERCENT

 -- or -

-- reference all the column data when building the stat
UPDATE STATISTICS dbo.MyTable myTableStatName WITH FULLSCAN

注目すべきことに、サンプルレートを上げると統計の寿命が向上し、SQL Server 2016 SP1 CU4（またはSQL Server 2017 CU1）以降を使用している場合、新しいキーワードPERSIST_SAMPLE_PERCENTが含まれていますUPDATE STATISTICSコマンド。このキーワードは、手動で指定したサンプルの割合を使用するように、統計に対して実行される自動更新統計を強制します。このキーワードを含めないと、統計の自動更新の実行中にデフォルトのサンプリングが使用され、より高いサンプリング率が必要な場合に大きな頭痛の種になる可能性があります。

タイガーチームは 件名についての素敵なブログ投稿 をリリースしました。この新しいキーワードについてさらに詳しい情報が必要な場合は、チェックすることをお勧めします。

Erin Stellatoのブログ投稿 で概説されている@RandiVertongenのコメントのおかげで、最初のテストでより大きいFULLSCANパーセンテージを選択する前にSAMPLEを試すほうが理にかなっています。 。

1
John Eisbrener