![]() You should not infer anything meaningful from specific build numbers, the size of an update, or the date an update was released. Build NumbersĮvery update bumps SQL Server to a new build number. The caveat is that you should apply any new CU in a dev or staging environment first, and really test your workloads (including backups and other scheduled jobs) against it, for at least a business cycle, before planning to deploy to production. I can understand some short-term restrictions and even some hesitancy for a new major version, but this shouldn't be permanent state. That said, I always strive for staying up to date on the CU path, and recommend customers and peers do the same. ![]() You can uninstall a Cumulative Update to try to downgrade back to GDR, for example, but this is not something I'd be excited to try in production – especially if multiple CUs have been installed. They can always jump to the CU path later – but the reverse is not necessarily as easy. An organization may not have the bandwidth or testing infrastructure to validate such a wide range of changes, so they opt instead to reduce their test coverage and risk of regression to just the areas that are fixed in GDRs. ![]() The primary reason is that non-critical fixes can require additional testing. Occasionally someone will ask why the GDR path exists at all. These updates do not include any of the non-GDR fixes in CUs, but they are also cumulative within GDR: if you install the GDR from last week, you also get all of the other GDR fixes before it. Depending on severity, they may be issued even after a branch is out of mainstream support. These are usually security-related (but not always), and are sometimes offered via Windows Update. A GDR update contains one or more fixes that Microsoft deems critical.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |