This is what Task Manager looks like in Windows Server 2008 R2 when you restart the SQL Server Service. This is one of my Production SQL Server 2008 R2 instances that runs the Mirrored copies of several databases. I am using Synchronous Mirroring with a Witness, so I have automatic failover.

As part of my preparation for a scheduled maintenance window, I applied SQL Server 2008 R2 RTM CU4 to my Witness “instance” of SQL Server. The Cumulative Update setup program stops the SQL Server Service, applies its updates, and then restarts the SQL Server Service. In the first screenshot, you see the Physical Memory Usage History graph, with the usage dropping sharply as the SQL Server Service is stopped. It stays flat while the Cumulative Update is installed, and then starts to steadily rise after the SQL Server Service is restarted, and the workload causes SQL Server to start using more memory.

I typically like to apply a SQL Server Cumulative Update at the same time as any pending Windows Updates. In order to minimize your reboots, you should do the SQL Server Cumulative Update first (since the CU setup program checks for a pending reboot), and then install your pending Windows Updates, and then finally allow Windows to reboot.

I always update the Witness first, and then once it is completely back, I update the Mirror. Depending on your SLA, you should be able to do those servers before your maintenance window starts, since your active workload is not affected. There is a small risk in doing that, since you are running exposed while the Witness and Mirror are being updated and rebooted. I would argue that the risk is pretty small, and that doing this work ahead of time reduces the complexity and length of your maintenance window activities.

After running for a few minutes, you can see the memory usage continue to steadily climb.