Metldown and Spectre

  • Has anyone deployed any of the patches released for SQL 2016 and SQL 2017 to any of their environments. 

    Is anyone considering it?
    Has anyone tested the impact. 

    I do not run 2016 or 2017 in the environment I am responsible for.

  • We have a SQL Server 2017 and Windows Server 2016 Evaluation VM, which I'm just doing some benchmarking on now. I'll then be patching it and seeing where those same things come out.

    Thom~

    Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
    Larnu.uk

  • Please keep me informed.

  • Super Cat - Friday, January 5, 2018 6:53 AM

    Please keep me informed.

    Read the main article that came out on this site this morning.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Link to Steve's article should anyone find this.

    ...

  • Thanks. Read it recently. 
    MS has not really released anything concrete and concise especially around PHYSICAL servers.
    (You may not be affected if you trust the code???). Not really crystal clear.
    Still a bit vague. Only patches for SQL 2016 and SQL 2017 are available.

  • Super Cat - Monday, January 8, 2018 4:40 AM

    Thanks. Read it recently. 
    MS has not really released anything concrete and concise especially around PHYSICAL servers.
    (You may not be affected if you trust the code???). Not really crystal clear.
    Still a bit vague. Only patches for SQL 2016 and SQL 2017 are available.

    I'm not sure what else you would expect them to say.  All systems have the problem.  If you trust everything on the system and only trusted things are used by trusted people, then you don't need to do the patch with the understanding that the problem still remains.

    If you don't know whether the code or access should be trusted or not, assume that it's not.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • Super Cat - Friday, January 5, 2018 4:50 AM

    Has anyone deployed any of the patches released for SQL 2016 and SQL 2017 to any of their environments. 

    Is anyone considering it?
    Has anyone tested the impact. 

    I do not run 2016 or 2017 in the environment I am responsible for.

    I applied CU3 to SQL Server 2017 yesterday afternoon. I don't have a lot of load running against this server currently (3 QA people and some developers - 25 databases) but so far I'm not seeing the dreaded 30% I/O hit that some articles have mentioned. Using Redgate SQL Monitor, I compared a 3 hour window this morning against the same window a week ago and see nothing out of the ordinary. I looked at CPU usage on the VM and on SQL Server as well as average disk read/write on the data, log and tempdb drives. Everything looks like very similar to before the patch. I will continue monitoring this during the day today and will be patching our DEV box this afternoon. DEV has 10 developers hitting it and some report writers / analysts as well so it sees more I/O. This will give me a better idea if a busier box will show more of a hit.

    A little about the QA box:
    Windows Server 2016 (not patched for Meltdown / Spectre yet - one step at a time) (VM)
    64GB RAM
    4 core
    Largest DB ~ 500GB - active QA work going on against this database.

    (more to come)

  • Thanks for the information TueLiner. 
    Please keep us updated.

  • TUellner - Tuesday, January 9, 2018 9:39 AM

    Super Cat - Friday, January 5, 2018 4:50 AM

    Has anyone deployed any of the patches released for SQL 2016 and SQL 2017 to any of their environments. 

    Is anyone considering it?
    Has anyone tested the impact. 

    I do not run 2016 or 2017 in the environment I am responsible for.

    I applied CU3 to SQL Server 2017 yesterday afternoon. I don't have a lot of load running against this server currently (3 QA people and some developers - 25 databases) but so far I'm not seeing the dreaded 30% I/O hit that some articles have mentioned. Using Redgate SQL Monitor, I compared a 3 hour window this morning against the same window a week ago and see nothing out of the ordinary. I looked at CPU usage on the VM and on SQL Server as well as average disk read/write on the data, log and tempdb drives. Everything looks like very similar to before the patch. I will continue monitoring this during the day today and will be patching our DEV box this afternoon. DEV has 10 developers hitting it and some report writers / analysts as well so it sees more I/O. This will give me a better idea if a busier box will show more of a hit.

    A little about the QA box:
    Windows Server 2016 (not patched for Meltdown / Spectre yet - one step at a time) (VM)
    64GB RAM
    4 core
    Largest DB ~ 500GB - active QA work going on against this database.

    (more to come)

    I patched our development server yesterday afternoon. This VM sees more traffic than the QA VM with the entire dev team using it.Looking at a baseline in SQL Monitor of the same time last week, I can see some difference in the average disk reads/writes. That lead me to look at the job execution history for Ola's scripts (we use backup and integrity check). I can see the full backup took about 5% longer than previous. Also, the integrity checks took 11% longer. I tuned the backups previously and I will probably take a look at it again to see if I can tune it a little more to make up for this.

  • Thanks for the info. Very helpful.

  • I applied the 'fix' on a SQL Server 2016.  It said successful and everything looks good.  However, when I look in the server application log I see these below.  When I search for these type errors some people saw this type issue a while back in SQL Server 2012 and said to go to the discover report and run that.  If it all shows the updated version you are good which mine did show the version upgraded fine.  Did anyone look at their server log after applying the patch?

     

    Product:SQL Server 2016 Database Engine Services - Update'{21AEDE29-2A59-4206-B7BF-F1BC8C4D9B6B}' could not be installed. Error code1642. Windows Installer can create logs to help troubleshoot issues withinstalling software packages. Use the following link for instructions onturning on logging support: http://go.microsoft.com/fwlink/?LinkId=23127

     

    Product:SQL Server 2016 Full text search - Update'{186A3570-FBA9-4259-B45B-3EA0C735C107}' could not be installed. Error code1642. Windows Installer can create logs to help troubleshoot issues withinstalling software packages. Use the following link for instructions onturning on logging support: http://go.microsoft.com/fwlink/?LinkId=23127

     

    Product:SQL Server 2016 Reporting Services - Update'{CCB682B8-8620-46F0-8276-C17BCC88E9D4}' could not be installed. Error code1642. Windows Installer can create logs to help troubleshoot issues withinstalling software packages. Use the following link for instructions onturning on logging support: http://go.microsoft.com/fwlink/?LinkId=23127

  • Good spot. I have the same messages in the Application area in the Event Viewer on the 2016 Dev server that I upgraded yesterday.

    When I compare the timings of the messages with the SQL install log though they coincide with the locked file checker section. I had to run that twice because there were a couple of people logged in running SSMS so I had to kick them out and the messages appear during both attempts so I assume that the messages are actually a by product of that process so nothing to worry about.

  • Yesterday I also patched two SQL Server 2014s and they had the same messages in the App. server log and the patch was applied successfully.  Microsoft needs to change those messages.

    CC-597066, you don't really need to kick people out of SQL Server during a patch.. it is good practice to, however, when it comes time for the patch to run things within SQL Server it will stop the service and start it in DBA mode that will only allow the scripts to be run and no one can connect while that is going on.

Viewing 15 posts - 1 through 15 (of 16 total)

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