After-failing over a databases to the mirror instance, the application
couldn’t login to the databases complaining of login issues.
It was later identified that the SQL logins were not created
when the mirroring sessions were created. So I took the responsibility of
creating the logins but didn’t realize the importance of the SID impact on the
mirror instance and executed SP_Change_user_login to map the login with the
respective database users.
After the failover testing was completed on the mirror
instance the databases were failed back over to the primary instance at which point
we ran into further login issue. Even though the problem was sorted by
executing SP_Change_user_login I obviously hadn’t ironed out the problem.
After backtracking my steps I realized the importance of creating
the SQL login with the same SID in
mirror instance to the same of the primary instance. Following is the syntax for
the creation of the loginwith hased SID
CREATE LOGIN MirrorDB WITH password =
0x0100F2C6ADC64E59D28531B1000DCADB0F881E51D9329F358A0B
hashed, sid =
0x3C1025E1DBC23D469CF1E9141258A0EB
, default_database =Master,
CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF
Even though the SID is easily retrievable from Syslogins the
password is not in binary format which doesn’t really help. And the easiest way
of getting this sorted is to use the sp_help_RevLogin which is available at http://support.microsoft.com/kb/918992.
Comments
Post a Comment