March 7, 2020 at 10:24 am
I am trying to perform this upgrade (nothing newer will run on the server I have), and am so far batting zero. After starting and selecting "Upgrade existing installation", the package says it is unable to search for updates through the Windows Update service. When I skip over that step, I get a popup with the message "The specified service does not exist as an installed service", but no clue what that "...specified service..." might be. When I close that, the table of check behind says that everything has passed, but has a warning about .NET Application Security. When I click on the warning, it says that this computer cannot access the Internet, which is nonsense - it is connected and browsers work just fine. It also directed me to some Microsoft Root Authority website, but says that if I am prompted to download a .crl file, I do NOT have a security validation issue. I don't get it - if I am prompted to download this file, and that means I don't have a problem, should I download it? If so, what should I then do with it? In any case, it says it's a warning, not a show-stopper.
When I click next, it shows me the existing instance. I click on Next and that is the end of the show. The installer hangs and does not respond any further.
Nothing I have found on the net has been helpful.
March 8, 2020 at 11:10 am
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
March 9, 2020 at 11:47 am
You're trying to do an in-place upgrade? This is the installation software that is generating these errors? I'm unclear precisely what's happening.
Also, whatever you do, avoid updating to 2014. It's not that the version of SQL Server is bad per se. The issue is tha the cardinality estimation engine changed in 2014, but there are very few knobs to deal with issues that may introduce in your database. 2016 or better have a bunch of knobs (Query Store & Plan Forcing, DATABASE SCOPED CONFIGURATION, others). I would fight like the dickens to not upgrade to 2014, but rather go on to 2016, 2017 or 2019. In fact, I'd strongly recommend only going to 2019 at this point in time. Any other upgrade path is putting you on older software. If you're going through the pain of an upgrade, go all the way.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 9, 2020 at 12:22 pm
Yes, I was trying to upgrade in place, over the existing installation, to avoid having to migrate everything. It's a fairly simple setup, but still, copying everything over manually is a PIA. I don't have that much experience with installations - just this one, years ago, when I was first learning to use SQL Server at all, after outgrowing Access on a specific project. I found a post of yours somewhere, where you recounted your experience of having done exactly that, an in-place upgrade, and it working with no problems, so I was trying to do the same.
I would love to go all the way to the newest version, but as I wrote in the initial post, nothing newer will run on this setup. It's an old HP ProLiant box running Windows Server 2008, 64-bit, single four-core processor. It's more than adequate for the needs of this operation, except that I'm getting kind of nervous about the machine's age. It's already dropped a few disk drives over the years, fortunately in a RAID configuration.
From looking at the hardware requirements, it seems that the machine might even be able to run a 2019 OS, but I don't know if that would be enough to allow an upgrade to SQL Server 2019 - I don't know what the requirements are or what the installation checker examines before making its decision about whether or not to run. I'd hate to persuade people to cough up for a new OS, and then have to say, sorry, it's not going to work after all.
March 9, 2020 at 1:31 pm
Running out of support software is a serious business risk. I'd focus on that above anything else. I know this stuff comes with a price tag, but talk to the business. Balance that price tag with the company just losing all the data, entirely. If they're OK with that, you can chill. If not, I'd do whatever was necessary to move them to a more modern system to ensure safety and reliability.
As far as the in-place upgrade goes, it sounds like you may not have been running it locally on the system where there was already an instance of SQL Server running. I'm saying that based on the fact that it can't find the instance. Make sure that SQL Server is up, in place, and running before trying to do an in-place upgrade.
Beyond that, I'd at least need to see some more data. It's hard to know. Most of the time, these upgrades in place, just work. They're not the safest method (I much prefer a side-by-side upgrade for safety, but I get it that's not always possible). However, it should work.
For a little paranoia, take a backup before you start.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
March 9, 2020 at 3:04 pm
Thank you. Losing all data is NOT going to happen – I've got multiple backups all over the place, on-site and off. Transaction log every 15 minutes, differential every hour and full every night, and yes, I manually test-restore them to full functionality and DBCC CHECKDB regularly. A script checks to see if any changes to the database were made in the preceding interval, to avoid making unnecessary backups when nothing has changed. A bit of overkill, perhaps, but I am paranoid by nature and training (I'm also a pilot, where paranoia is also a useful trait). Lots of this stuff was built based on advice from your website, as well as some stuff you told me in person years ago (we met once at an SQL in the City event).
I have two copies of the database: production and development. I work in the development, then when I have a new version ready to use, a script clears all the development data, backs up the production data, copies the production data into the now-empty development version, then immediately does a full backup of that, the former production is killed, the fresh backup is restored to the production name (just ONE of my regular test restores), so the former development becomes the new production. I then have the newest data in my development version, a copy of the former development version is in service as the production version, and the cycle starts again.
ALL of this is backed up constantly into a special backup folder on the same disk and to a NAS unit in the same room, then nightly to a SAN in an adjacent building, and to an off-site professional storage facility. Once per week, I manually back up to a little stand-alone USB disk unit. I log into the server, manually look over the sort of stuff that is normally attacked by crypto-viruses and similar garbage, and I check the server's activity, to make sure it's just idling and not doing anything it shouldn't be. When I'm certain everything is okay, I turn on and connect the USB disk, run a comparative backup script that backs up all data from the server, then disconnect it and turn it off again. And on top of all that, I regularly make backup copies of the most critical stuff to a number of DropBox-type cloud storage sites linked to dummy e-mail accounts, set up expressly for that purpose.
I know 100% certainty is not possible, but if anything manages to skunk me in spite of all this, I'm just going to go jump off a bridge.
As for the machine, this is not time critical stuff. It's the administrative and scientific data for the paleontology department of a museum. If the machine goes down, it will be a pain in the fundament, but nothing devastating will happen. There is plenty of other work besides playing with the database. One time a disk drive failed just as I was leaving for an out-of-town conference. No sweat – just shut the server down, ordered a new disk drive and left. People did other work for a few days and I fixed it when I got back.
If the server does go down completely (which could happen even with a new machine), things will just have to wait until a new one is secured somehow. But the data should be safe.
Sorry – I tend to ramble. As for the installation, yes, I was trying to run it locally (via RDP into the server), directly over the running instance. I thought that is the proper way to do an in-place over-install – isn't it? The install does find the running instance, and the process seems to start, but then just hangs. No error message, no response. It's not completely stuck – it does close in response to clicking the Close X button, but it's not just me being impatient. I left it running all night and nothing happened. Tried this several times, with machine restarts in between. Tried it once with SQL Server shut down – then it did not find the instance to install over.
Otherwise, the install package seems okay. I just finished a new install alongside the old one, and it finished with no problems. It was a fairly simple install – very few of the electable components, like reporting services or replication, since I do not use any of those. I can migrate to this instance if I have to, but it will be a lot more work making sure I have all users, logins, connectivity and everything else set up properly. I would prefer to do it in place, if I can figure out how to do so.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply