New answers tagged sql
Here's a crazy idea: keep the alias, and for your custom SQL DBs, use the IP of the SQL Server in your web config that those web parts use. That way you bypass the alias that is borking your custom DB pointers.
It's not ideal, however the best way (in my experience) would be to use multiple aliases to help simplify this issue. One possible workaround could also be to update the SharePoint servers host files to point the db server names to the new IP address(es). The hosts file overwrites DNS entries, and is located in C:\windows\system32\drivers\etc\hosts. The ...
If you have the old db-server up and running, use the following command in PowerShell: Get-SPSite -ContentDatabase <SourceContentDb> | Move-SPSite -DestinationDatabase <DestinationContentDb> This command moves all site collections from the source content database to the destination content database. Reference: Move site collections ...
As the change in the allocation should not require a SQL restart I would guess that you have something else hogging the rest of the RAM. Look into the Proccesses tab and see if the culprit is visible there. As a best practice, nothing except SQL should be running there.
Top 50 recent answers are included