Features in 2nd 2019 Instance breaking the first instance on my VM
-
I'm working on developing and testing a number of PowerShell scripts, and need at least two SQL Instances with a wide range of features installed on a single VM. The first instance is basic, but for the second instance I installed almost everything so I could test the PS Script. By "almost everything" I mean all the Machine Learning features, SSAS, Data Quality Client, Master Data Services, Replication, as below, but I can’t think of anything that would break the first instance.
This has happened twice, so I don't think it's coincidence. The first time I didn't connect the problem to the 2nd install, but after setting up the VM from scratch again I specifically checked, and the first instance was definitely not starting after the 2nd install. Unfortunately I don't have any error messages because I've reverted to a checkpoint I took before the 2nd install, but I could test again if needed.
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated. -
Not sure what you are testing or what your errors are or what's breaking but shared features tend to be shared by instances on the server. Instance specific are specific to that instance. So installing "everything" including shared features on the second instance will affect the first instance.
Sue
-
To emphasize what Sue_H said, check the logs.
Without error messages it is impossible to say what is wrong.
And to reiterate what Sue_H said, "Shared Features" are features that are shared by all instances at the same version.
As for what you are testing via powershell, is there any reason you can't test the minimal install and once you are done testing that, do the test again with the feature rich install? My thoughts here are that shared features MAY or MAY NOT be required for your testing. Generally, when I am testing something, I like to have a "minimal feature set" when I am doing the initial test and after I am confident that it works with the minimal feature set or I determine the actual minimum feature set if my first few attempts were wrong, I test it in a prod-like environment. This allows me to determine the actual minimal requirements (like does it need "Client Tools Backwards Compatability"?) and then determine will it work in our existing environment.
By installing 2 instances, you are already limiting yourself on resources IF both are running at the same time which it sounds like is your intention. Depending on the configuration of the server and VM, it could easily be resource constraints are preventing 2 instances from running at once (such as if your VM only has 4 GB of RAM or less).
TL;DR version - I would test your powershell with the minimum install (single instance) then add features to that instance OR do a fresh install and re-test.
Just my 2 cents...
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
Well it's not actually possible to install the shared features twice, so this definitely isn't the problem. Also, I've already done all the core testing, at this point I'm testing extraction of the "installed features" list when multiple instances are installed. This already works for a single instance on the server, but I need to test further functionality at this point:
- Does my PS Script correctly separate/identify the features installed by instance.
- Does it correctly identify all the features (Pollybase, Launchpad, etc.).
- Can I correctly separate shared features from instance based features.
When I install the 2nd instance, with all the extra features, the previously installed SQL Server instance just doesn't start. The only error I see is an "Access Denied" message, but this is not very informative.
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated. -
"ACCESS DENIED" is actually very informative, depending on where you are seeing it as it SHOULD contain more information such as what access is being denied.
Is that in the SQL Server log or Windows Event log? If so, what this tells me is that the SQL instance is unable to start due to some access being denied. What I would try is stopping the second SQL instance and see if the first can start up. If it can, is there a chance that you accidentally gave both instances the same file for a system database (such as tempdb) during the install?
Failing that, I think seeing the WHOLE error message would be a LOT more informative as I HIGHLY suspect that the full error will give a lot more clues as to what the actual problem is. Along with the full error, seeing previous and following errors and warnings in the SQL Server log will give even more clues as to what the actual issue is, presuming the full error for the access denied doesn't tell you what is wrong.
One question I have about your script is does it handle offline instances? What if you have a "cold spare" failover system in place? Would you want your script to be able to handle that situation or should it ignore offline instances? The reason I ask is it MAY be more informative to check the registry and registered services on the server than to query an offline SQL Instance for features.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system. -
One question I have about your script is does it handle offline instances?
At the moment the input for the script is a file with a list of servers, so I am essentially controlling which servers I inspect. One item on my todo list is add tests for both the Windows Server and the SQL Instance being accessible before I start extracting data.
Once I've finished the current dev cycle I'll install the 2nd instance again and do some more testing. But I've already checked all the basics like shared system files (e.g. TempDB). SQL Actually won't let the install progress if you don't define separate file paths. I've gone over my install screen shots to check and I definitely used different folders, and Master, model & msdb are in their "instance" specific locations by default.
Leo
Nothing in life is ever so complicated that with a little work it can't be made more complicated. -
I kind of expected SQL to be smart enough to not let you re-use files like that during the install, but was just guessing in case that was the issue.
I think my next step would be to review the logs. Knowing the full error message and any surrounding messages (info, warning, or error) would help debug what is happening and why.
I haven't done what you did with SQL Server 2019, but I've done similar with 2008 R2, 2012, and 2016 with no issues. That is having a feature poor version of SQL installed and then installing a feature rich version of SQL. One difference though is I always use an AD account for the service and don't have any local accounts, but I highly doubt that is causing the issue.
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply