Migration Challenge: Excessive FULLSCAN Statistics Update Duration Blocking SQL

  • Hello everyone ,

    I am planning to migrate a database from SQL Server 2014 to SQL Server 2019. The migration process includes a double-run, and one of the steps in the timeline is an UPDATE STATISTICS with FULLSCAN.

    This operation takes more than three days, which makes the cutover impossible because such a delay is not acceptable.

    I would like to know whether this step can be skipped, or if there is a way to optimize or replace it. My concern is that skipping it may lead to poor execution plans after the migration

    Thanks

  • As the forum does funny things with url's lookup schackenberg Upgrading to SQL Server 2022: Paths, Pitfalls, and Best Practices

    Assuming this happens in a non-production environment first.

    I don't think the full scan is needed because the new cardinality estimator was introduced in sql 2014. Stats should remain valid after upgrade

    Why do you upgrade to 2019 (already 6 years out) when sql 2022/2025 is out (solving most kinks)?

    A) upgrade

    B) First checks. Don't change settings (keep compatiblity 2014 to be as close to the 2014 original), enable query store to gather a "baseline". There can be changes in performance due hardware / os changes

    C) Evaluate for a week. Now you have a "baseline" in Query Store.

    D) Start updating statistics of changing compatiblity level ... Evaluate the effect in Query Store. If it worsens you can "pin" the good plan whilst troubleshooting

Viewing 2 posts - 1 through 2 (of 2 total)

You must be logged in to reply to this topic. Login to reply