So in the quest to have no GUIDs I wrote the blog post How to remove the GUIDs from the SharePoint search service application databases to great fan fair. After reviewing my VM and other servers I have performed the steps on I have found the error message below. (Text and image included to help with the search engines getting you here.)
SQL Database ‘NewSearch_DB_e28b777e4e664c479879f5a257b932f9′ on SQL Server instance ‘CowTown’ not found. Additional error information from SQL Server is included below.
Cannot open database “NewSearch_DB_e28b777e4e664c479879f5a257b932f9″ requested by the login. The login failed.
Login failed for user ‘CONTOSO\sp_farm’.
(Don’t make fun of my server being named CowTown.)
So that seemed kind of scary but made sense because I had deleted that old database. After digging around I found that search seemed to work fine and apparently one of the timer jobs was just trying to check this database once an hour. So first thought I had was “I wonder if SharePoint still thinks that is a database somewhere even though the Search service application isn’t using it?”
Well, I know PowerShell to find out the answer to that question. I opened up a SharePoint Management Shell and simply ran:
Which gave me the output below:
Sure enough. The old database is still listed even though Search isn’t using it. UGH. (Fifth database from the bottom.)
Another place I saw it that was kind of freaky was Central Administration > Upgrade and Migration > Review database status
Here you can see that it is listed as Not Responding. UGH.
So all of this makes sense. We did delete the database because Search doesn’t use it anymore. Now we just need a way to tell the farm to quit trying to reference it. I fought with about 3 different ways to make this work and finally I came up with this one which I believe should be completely supported. J (My other ways may have been a little too direct.)
Getting rid of the error
- Open the SharePoint Management Shell
- Type get-spdatabase and press enter. This will give the output below.
- Find the database in question. You need to then copy the Id for it. You can right click in PowerShell and choose mark.
- Type $bad = get-spdatabase <your id> and press enter.
- Type $bad and hit enter. This will show you the database you have in the variable. It is your last chance to double check you got the correct database.
- Type $bad.Delete() and press enter. No more database.
- Type get-spdatabase and press enter. All better.
At this point all of your worries are gone. No more stupid error message. Standard precautions try this in your test world first. You are up a river without a paddle if you do this for the wrong database since it is a pretty violent way to delete the database.
May the force be with you!