MSSQLTips.com - your daily source for SQL Server tips

Google
 
Web mssqltips.com

ESSENTIALS: Home | Tips | Search | Categories | Top 10 | Products | Authors | Blogs | Forums | Webcasts | Advertise | About
Login failures connecting to new principal after failover using Database Mirroring: - Chad Boyd

MSSQLTips

MSSQLTips.com - your daily source for SQL Server tips
Welcome to MSSQLTips Sign in | Join | Help
in Search

Chad Boyd

MSSQLTips - SQL Server Blog

Login failures connecting to new principal after failover using Database Mirroring:

Q:  I have configured Database Mirroring successfully between 2 Sql Server 2005 instances. My application is connecting to Sql Server using a Sql Server login, and is built using ADO and the Sql Native Client. My connection strings/connection settings specify the correct information, including the appropriate failover partner.  I have also created all the same logins on the mirror server as exist on the principal server.  Upon testing a database failure, the mirror successfully assumes the principal role and everything looks correct on the Sql Server (I can even connect successfully to the mirror using my Windows login).  However, the application reconnect fails with the following error:

 Cannot open database "<db name>" requested by the login. The login failed.

It appears that the login is not associated with a user in the new principal (originally the mirror) database.  I run sp_change_users_login to synchronize the users and logins for the database, and I get a message saying it fixed multiple orphaned users.  My application then reconnects successfully to the new principal server.  I have tried multiple failovers, and each time I see the same behavior, i.e. the association between the login and user gets lost.

Is there a way to configure the mirroring setup so this is not a problem?

A:  Yes.  The problem is due to the fact that the SIDs (security identifiers) for the Sql Server Logins on each server do not match, even though the names for the logins are the same.  This is not a problem with Windows/Domain user/group logins because the SIDs for these logins are created based on the domain SID for the user/group, and hence will be the same for the same given user/group no matter what Sql Server the user/group is added to.

In order to make the sp_change_users_login synchronization step unnecessary, you'll need to create the Sql Server logins on the mirror server not only with the same name, but also with the same SID as on the principal server.  You do this by using the SID specification in the 'CREATE LOGIN' statement when creating the logins on the mirror server, like follows:

 CREATE LOGIN <loginname> WITH PASSWORD = <password>, SID = <sid for same login on principal server>,...

You can retrieve the SID for each login from the principal server by querying the sys.sql_logins catalog view. Here's an example of a query that will generate an actual 'CREATE LOGIN...' statement for each sql/windows login on a given server:

select 'create login [' + p.name + '] ' +
  case when p.type in('U','G') then 'from windows ' else '' end +
  'with ' +
  case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) + ' hashed, ' +
  'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
   case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' + case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
   case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
  else '' end +
  'default_database = ' + p.default_database_name +
  case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end

from sys.server_principals p
left join sys.sql_logins l
on  p.principal_id = l.principal_id
left join sys.credentials c
on  l.credential_id = c.credential_id
where p.type in('S','U','G')
and  p.name <> 'sa'


Chad Boyd ~~~ This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.mssqltips.com/disclaimer.asp and http://www.mssqltips.com/copyright.asp.

 

Published Oct 15 2007, 11:15 PM by Chad Boyd
Filed under: ,

Comments

No Comments

About Chad Boyd

Chad is an Architect, Administrator, and Developer with technologies such as Sql Server (and all related technologies), Windows Server, and Windows Clustering. He currently works as an independent consultant and also spends a significant amount of time writing, talking, presenting and blogging about Sql Server in person and online at http://mssqltips.com. In the past, Chad has worked with companies and organizations such as Microsoft Corporation and The American Red Cross, and provided consulting/support services at companies such as Bank of America, HP, Citigroup, Qualcomm, Scottrade, TJX, SunTrust, and Zurich Financial Services. For over 3 years with Microsoft Corporation Chad was responsible for providing onsite and remote support, guidance, and advice with SQL Server products to some of Microsoft’s foremost enterprise customers running the largest, most complex SQL Server installations and configurations in the world. This included all SQL Server products and versions, including SQL Server 7.0, 2000, 2005, and recently 2008, the SQL Server database engine, Reporting Services, SSIS/DTS, Notification Services, and Analysis Services on both 32 and 64 bit systems. Chad's primary responsibilities today include troubleshooting critical server situations, performance tuning and monitoring, disaster recovery planning and execution, architectural guidance for new Sql Server related deployments, and delivering deep technical workshops/presentations/proof-of-concept sessions covering a variety of technologies and functionality. Chad regularly posts Sql Server related content, tools, and advice with the mssqltips team at http://blogs.mssqltips.com/blogs and http://mssqltips.com. Chad can be contacted via his blog or email at chad dot boyd dot tips at gmail dot com.

This Blog

Syndication