What’s the issue?
SQL Server recreates the tempdb database every time the SQL Server service starts, which means the creation date of tempdb in sys.databases reflects the time of the most recent service restart. Comparing this date against the current date provides a reliable measure of how long the instance has been running continuously since its last restart.This finding identifies instances where the tempdb creation date indicates the SQL Server service has been online for more than 180 days without a restart. The threshold is a useful indicator that the instance has likely been missing scheduled maintenance, including the application of cumulative updates and security patches.
Why is this a problem?
180 days is a long interval to go without applying any updates. SQL Server cumulative updates are typically released every two to three months, and security updates are released as needed when vulnerabilities are identified. An instance running for 180 days has almost certainly missed multiple updates, including any security fixes that have been issued during that window.Missing security updates leaves the instance exposed to publicly-known vulnerabilities. Once Microsoft releases a security update, the underlying vulnerability is documented in the security bulletin, and exploit code often follows quickly. Unpatched instances become attractive targets for both opportunistic and targeted attacks, particularly for any vulnerabilities that affect features exposed on the network.
Beyond security, missing cumulative updates means the instance is not benefiting from the bug fixes, performance improvements, and feature enhancements that have been released. Some performance issues, query optimizer bugs, and corruption-related problems are addressed only in cumulative updates, and instances that are far behind on patching can experience problems that have already been fixed in the engine.
What should you do about this?
Plan a maintenance window to apply the missed updates, working with application owners to coordinate downtime. For environments with Always On Availability Groups, follow the rolling update pattern to minimize downtime; for standalone instances, schedule the work during a low-activity window with appropriate notification and rollback planning.Apply the updates in the standard sequence: take a fresh full backup, apply Windows updates, restart Windows, apply the latest SQL Server cumulative update, restart again, and verify the instance comes online cleanly with all databases and features working as expected. Verify the new build number and patch level after the restart.
Establish a regular patching cadence going forward. We recommend a target of at least quarterly patching for cumulative updates with immediate application of critical security fixes (which are often released monthly), which keeps the gap between updates within a manageable window.