I've been looking from Google opinions about whether to do or not do SQL Server patching with SCCM. I've only found one topic from SQL Server Central (http://www.sqlservercentral.com/Forums/Topic1589012-1550-1.aspx -- might require userid to see) with one answer 'I do not recommend'.
This was not the answer which I was looking for so I went ahead together with our company's SCCM guys and made some test patching of SQL Server's (2008/2008 R2 and 2012 -versions). Those patch runs executed without any hassle and issues.
I'll agree that this process is missing the part where the application connection is tested afterwards and no backup is taken before patching. These are though things that can be tackled by regular backup schedule. Application connection testing would require end-to-end monitoring, but usually rebooting the application server(s) will re-establish the db connection and would end to errors if the connection is not working.
So if you're like me and trying to find courage from Google to start patching SQL Server by using SCCM I can assure you that it's not a big of deal and the trade off is quite huge. No more time on moving the Service Pack's into servers and executing them manually. We got several (tens -- not hundreds) of internal SQL Server's back into shape in a day.
This was not the answer which I was looking for so I went ahead together with our company's SCCM guys and made some test patching of SQL Server's (2008/2008 R2 and 2012 -versions). Those patch runs executed without any hassle and issues.
I'll agree that this process is missing the part where the application connection is tested afterwards and no backup is taken before patching. These are though things that can be tackled by regular backup schedule. Application connection testing would require end-to-end monitoring, but usually rebooting the application server(s) will re-establish the db connection and would end to errors if the connection is not working.
So if you're like me and trying to find courage from Google to start patching SQL Server by using SCCM I can assure you that it's not a big of deal and the trade off is quite huge. No more time on moving the Service Pack's into servers and executing them manually. We got several (tens -- not hundreds) of internal SQL Server's back into shape in a day.
No comments:
Post a Comment