January 9, 2020 at 8:29 pm
Every page 've tried to get to SQL Server 2016 SP2 is returning 404. All the below are the different jump points Ive tried to get the SQL Server 2016 SP2 and all fail. Does anyone know whats going on with this? I can get to the pages that list all the SPs and CU's but when I try to go to the SP I get 404.
https://support.microsoft.com/en-us/help/4052908/sql-server-2016-service-pack-2-release-information
Kindest Regards,
Just say No to Facebook!January 9, 2020 at 8:56 pm
It might help if I just include what I am trying to achieve. I am trying to restore a copy of our DB from our cloud vendor and when I try I get the message that the media family on device is incorrectly formed. I assume its because the version of SQL Server I am trying to restore to is 13.0.1601 while the version of SQL Server the DB backup came from is 13.0.5233. If this is incorrect and I should be able to restore the backup then let me know so I can get another copy of the backup. It may be that the backup file is bad as we have had trouble trying to get the DB backup.
Assuming that I do indeed need to update my local SQL Server to version 13.0.5233 then my questions is how. I've tried a number of page links and every link is either sent me to a 404 page or if I can get the link to work and download an update I get the message that the expected installed version is wrong; as if the update itself has a minimum SQL version requirement.
The last time I had to update SQL Server you downloaded the latest SP/CU and that was it.
Any help any of you can offer is appreciated.
Thanks
Kindest Regards,
Just say No to Facebook!January 9, 2020 at 9:09 pm
Try this link for 2016 SP2 and see if it works:
Microsoft SQL Server 2016 Service Pack 2 (SP2)
A lot of the links no longer work. A lot of the documentation is in the same shape too - they used to have a drop down to select the version but that drop down has been broken for quite awhile. I've submitted feedback for it quite a few times but either way, you can't easily find documentation or service packs for previous version anymore. Point being...it's not you.
Sue
January 9, 2020 at 9:29 pm
Try this link: https://www.microsoft.com/en-us/download/details.aspx?id=56836 for SP2 and this link: https://support.microsoft.com/en-us/help/4527378/cumulative-update-11-for-sql-server-2016-sp2 for CU11.
You should be able to restore to the same version - the error you are getting indicates that the backup file is not a native backup file (it could be a 3rd party utility). It could also be a striped backup that is missing one of the files - or you are specifying an incorrect file in your restore command. I would try a RESTORE HEADERONLY on the file to confirm it is a native backup file.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
January 9, 2020 at 9:42 pm
Thank you Sue that worked.
This is certainly one way to drive users away from SQL 2016, make it hard to use the updates.
Kindest Regards,
Just say No to Facebook!January 9, 2020 at 9:54 pm
Jeff - Your links worked also and i will definitely give that a try now that IO know I should be able to do the restore.
You also may be onto something with the backup coming from some third party software.
Followup Q specif to 2016.
When we sent the DB to the vendor to move to the cloud we were on SQL2008R2 at the time and the data file was just under 600GB and when backed up and compressed (native SQL Server backup) it was around 58 GB. I noticed today via the tools the cloud vendor provides that the same data file is now only 158GB a substantial reduction and yet the backup its self is still roughly the same size as it was when we had the DB on prem in SQL 2008R2.
Was there some kind of mass improvement with data storage between SQL Server 2008R2 and 2016 that would account for a reduction this large with the DB's data file?
Kindest Regards,
Just say No to Facebook!January 9, 2020 at 10:03 pm
The only thing that comes to mind is database compression - or the original database had a lot of extra space in the data file and the cloud team performed a shrinkfile (and I would hope an index rebuild).
There is nothing in SQL Server that would automatically shrink a file or compress the data files.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
January 9, 2020 at 10:06 pm
Thank you Sue that worked.
This is certainly one way to drive users away from SQL 2016, make it hard to use the updates.
It is actually much easier now than it was previously...it use to be required to enter your email information and then from that email you would have a link to a compressed (zip) that you could then download and extract. Now - you just download whichever one you want...once you find it.
I link to a site that lists all of the patches for all versions - and they do a very good job of providing the links and keeping them updated.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
January 16, 2020 at 3:33 pm
I think your right with the shrink file because the DB when backed up is still around the same size as when we had it ion prem. I have another question with regards to this. If they did use shrinkfile can't this have a negative impact on performance when it comes time for the DB to grow? The DB is set to FULL recovery model and is also set set to autogrow. They have the log file size set to 2Gb. When we had it on prem I had the log file set to the 5Gb as that was the size it would typically grow to during the busiest time of the month. I'm concerned that the space saving actions taken were done to reduce the cloud vendors space used without any consideration on how that might impact performance. Being that were on 2016 which I have a lot less experience with I don't know if the best practices regarding things like log file size and the like are still applicable on SQL 2016.
Thoughts?
Kindest Regards,
Just say No to Facebook!January 16, 2020 at 6:57 pm
Can you clarify:
Is the backup file the same size as the backup file you sent to the cloud? Or - is the restored database the same size as the on-premise version of the database before you sent it to the cloud? What is the size differences you are seeing?
To answer your question about performance - no, shrinking does not affect performance when the database needs to grow. It affects performance because a shrink will fragment your indexes. The issue that is seen is that someone shrinks the database to as small as it will go - then rebuilds the indexes - which causes the database to grow - they then shrink again - and it grows again...
Don't automatically assume that the cloud vendor is doing something wrong - they may have improved processes in place that avoids the issues you were having with the transaction log. With that said - you need to confirm that they are performing normal maintenance - especially updating statistics.
Jeffrey Williams
“We are all faced with a series of great opportunities brilliantly disguised as impossible situations.”
― Charles R. Swindoll
How to post questions to get better answers faster
Managing Transaction Logs
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply