SQL SERVER ALIAS

When the lone SharePoint Server (SPWFE1) needs to connect to a database (such as WSS_Content_MyContentDB) on the back-end SQL Server (PRODSQL1), it might create a connection string that looks similar to the following.

Server=PRODSQL1;Database=WSS_Content_MyContentDB;IntegratedSecurity=true;

In this situation, the SharePoint server is directly coupled to the SQL Server because SPWFE1 directly references the production SQL Server (PRODSQL1) by name. This works just fine for day-to-day operations, but it doesn’t provide any real flexibility to accommodate topology changes that might be required (or “just happen”) in the future.

Consider the same farm when a SQL Server alias is used instead of a direct reference to the SQL Server:

The corresponding connection string that is built by SharePoint to connect to the SQL Server looks a little different; note the difference in Server name:

Server=SPSqlAlias;Database=WSS_Content_MyContentDB;IntegratedSecurity=true;

The SQL Server alias serves as an abstraction layer between theSPWFE1 and PRODSQL1. Whenever SharePoint needs to access a database, it indicates that it wants to connect toSPSqlAlias instead of PRODSQL1. When this happens, the SQL Server Native Client maps SPSqlAlias requests through toPRODSQL1 at runtime; SharePoint doesn’t specifically know about PRODSQL1, so direct coupling doesn’t occur.