Does the change of the host name of the server impact the functioning of Microsoft SQL Server?
Yes, there are some additional steps that you need to perform after changing the host name.
I could not find the relevant documentation for SQL Server 2012 online any more, but here is the official document for SQL Server 2016-2019:
Rename a Computer that Hosts a Stand-Alone Instance of SQL Server
In a nutshell, you need to execute
sp_dropserver <old_name\instancename>;
GO
sp_addserver <new_name\instancename>, local;
GO
to update system metadata and then restart SQL Server.
Additional steps (see the linked document above) might be necessary if you use:
a failover cluster,
replication,
Reporting Services,
database mirroring,
Windows groups containing a hard-coded reference to the computer name,
remote logins,
linked server configurations or
named pipes.
Obviously, the connection strings of any clients connecting to your server will need to be updated as well.
Related
I have the server
DESKTOP-TI7M67V\SQLEXPRESS (SQL Server 12.0.2269 - DESKTOP-TI7M67V\joe)
It is a SQL Server 2014 database engine using Windows authentication.
I need to create a new server, database engine with SQL Server authentication this time, that I need to connect and view into the same SQL Server Management Studio instance I use for my server by now, since I need to create queries involving both.
I've seen that I can do it with linked server feature, but I need to create and setup the new server correctly.
The access to this new server, obtainable through SQL Server authentication, must have different authentication parameters than the other one already existing, if a user doesn't have them, he would be able to access the old server, but not the new. The access of both servers has to happen in the same SQL Server Management Studio instance.
Plus, the databases files of this new server must be portable. For portable, I mean that all its files (that make it work) must be able to be put in a custom directory on two pcs, with SQL Server 2014 already installed on both, and be copyable and pastable, e.g on a pendrive, in order to be transferred from a PC to the other. That's for maintain synchronization between two different physical users workplaces in which the database will be used, workplaces that for the moment are not directly interfaceable with a single, fixed, detached and interconnected source on which place the database.
My question is how to create a new server that would have these features.
We have an application called IpSwitch Whatsup and it's installed in a machine that I can connect to remotely as administrator. This is all in our intranet.
We need to connect to the sql server database being used by IpSwitch Whatsup, but this particular machine doesn't have sql server installed. On the other hand, in sql server configuration manager there is indeed a sql server installation for whatsup (the entry says SQL Server (WHATSUP)).
So, two questions:
How does one go about in connecting to this database? I'm pretty sure I know the name of the database and I already know the server name and instance, so I would like to connect to this DB from a sql server installation in another machine.
How does one configure a sql server installation to receive remote connections if it doesn't have sql server installed?
Thanks.
For the first question, you just type in (or browse) the appropriate instance name and authentication options using SSMS - which is the GUI tool used to manage sql server instances. Note - the term "sql server installation" can mean different things so it is not a useful reference.
As for the second question, review the information here. Note that any task you do in SSMS can be done via tsql - you can see the appropriate commands using the script button in the SSMS dialog windows.
And you can also (and probably should based on these questions) install SSMS on the same machine as your server instance so you can do "anything" "anywhere". Now would probably be a good time to review your disaster recovery options (and start backing up your databases regularly).
I have been searching for directions and steps to rename a named server instance of SQL Server 2012. I have a rare opportunity to rename both the computer name and instance of the SQL Server. I stepped into a situation where all of the naming conventions need to be revamped. I'm assuming because I have no linked jobs or connections that I should be worried about, this will be okay. I have read that this isn't possible and others who say to use the sp_dropserver, sp_addserver but that doesn't work. Syntax would be helpful. My names are as such:
{machinename}\{instancename}
{COLO-VSR=SQLDW}\{SQLBISERVER}
I want to change it to {COLO-VSR-SQLDW}{SQLDW}
The "safest" way to do this is to (this does assume that downtime is possible for you):
Take a backup of each database (or, if you're going to install exactly the same version of SQL Server, including Service Pack level, detaching the databases is probably safe
Take the old instance offline
Rename the machine, including rebooting as required
Install the new instance of SQL Server
Restore the databases to the new instance of SQL Server
Validate
7. Uninstall the old instance of SQL Server
SQL Server has never seemed to handle renaming of the server it's installed on particularly well, hence the suggestion of creating a new SQL Server instance after renaming the machine. This may be better with newer, e.g. SQL Server 2016, versions but I suspect that "rename machine" is a scenario that doesn't get a lot of engineering priority or resource.
I understand that there are a few threads existing on this area, around a local server using Azure MSSQL as a linked DB.
My specific issue is the linked server appears, connects and I can view the databases but when trying to go deeper, as in see the tables I get the following error:
Reference to the database and/or server name in
'databasetable.sys.sp_tables_rowset2' is not supported in this version
of SQL Server. (Microsoft SQL Error, Error 40515).
I have tried any of the suggestions already mentioned via the other threads, and to no avail can I get any deeper than listing the databases on the Azure server from my local installation of SQL Server.
I experience the same issue when trying to do anything more than simple Select/Insert/update/delete/create Table/Drop table on my SQL Azure databases. It appears you cant do anything that touches the settings of SQL Server or any stored procs that touch system tables, perhaps because the SQL servers could be shared between multiple customers.
There are also documented areas where Azure SQL has limitations versus a local SQL Server.
We now have this capability using elastic database query, you need to follow two simple steps mentioned as:
Step-1: Create reference to external database
Step-2: Then create remote table reference in the target database
then you can execute remote queries just the way you do it with SQL Server.
Please refer for step by step details https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-query-getting-started-vertical/
This is a continuation of an earlier question I had about moving the databases for a MOSS 2007 installation from SQL 2000 to SQL 2005. Here's the URL for the original question: Migrating MOSS 2007 from SQL 2000 to SQL 2005
In my test environment, I've successfully moved the databases to the SQL 2005 test machine and things appear to be working fine. But, on the "Servers in Farm" page of the Central Admin | Operations, it still shows the old (i.e. SQL 2000) server as the Configuration Database Server. Also, it shows the old config database as being the Configuration Database. I know that the SQL2000 server and old config database (that are showing on this page) are NOT being used, because we've deactived the SQL instance in SQL2000.
I've tried "removing" the server, and get a message about "Uninstalling SharePoint products and technologies" being the better route. So, I disconnected from the test databases, uninstalled SharePoint from the test WFE server, and reinstalled it. That didn't do anything. Before uninstalling/reinstalling I also tried simply rerunning the SharePoint Configuration wizard, and that didn't do anything either.
Does anyone know how to update the Config Server and Config Database on the "Servers in Farm" page after having moved the Config and Content DBs? Is there something I'm missing or overlooking?
Thanks.
stsadm setconfigdb
?
stsadm -help setconfigdb
shows:
stsadm.exe -o setconfigdb
[-connect]
-databaseserver
[-databaseuser ]
[-databasepassword ]
[-databasename ]
[-hh]
[-adcreation]
[-addomain ]
[-adou ]
Also see Technet which says PSConfig has superseded stsadm.
Hey, I completely understand your issue. YOu have moved your configuration database from the previous sql server to the new sql server. Let me make one thing very clear on this post that a configuration database cannot be moved to another sql server.
Hence, you need to run psconfig and disconnect from the current farm. Run psconfig again and create a new server farm. Once that is done, create new web application/applications and then attach the site content database/databases back to them. This is the only way to get your farm restored properly with the new sql server.
The best way we have found to do this is to use a SQL client side or DNS alias for the SQL server so that you can easily move the SP databases to a new server and just update the alias to point to the new one. In your case you could try the steps below, server names have been changed to protect the innocent. In this scenario you will need to have the same instance name (or use default) and possibly the same port.
Turn off SharePoint services
Rename the old SQL server from SQL2000 to SQL2000OLD
Create a DNS CNAME record called SQL2000 that points to new server called SQL2005
Detach/attach or backup/restore all databases from SQL2000 to SQL2005
Ping SQL2000 on SharePoint server to make sure that it resolves to SQL2005 and if not then run "ipconfig /flushdns" and repeat test until it resolves to new server
Bring SharePoint services back up, should connect to new server using DNS alias