April 4, 2008 at 8:12 am
julia.nicholas (4/4/2008)
Of course, duh! I didn't think of that. So basically as long as when changes are made on the Principal server in terms of adding new jobs and SQL Logins, jobs etc. you just need to do it twice over.
And make sure if you add logins on the two servers that the SIDs match
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
April 4, 2008 at 10:30 pm
A KB article I always have handy:
How to transfer the logins and the passwords between instances of SQL Server 2005[/url]
If you run sp_help_revlogin periodically, you can ensure that not only do the logins stay synchronized, but so do the passwords, in the event of SQL Server-based logins. You can save a script (good for DR purposes) and do a compare to see if passwords have changed before dropping and re-adding the login to the server containing the standby copy of the mirror.
K. Brian Kelley
@kbriankelley
April 28, 2008 at 2:25 pm
The Window logins still has to be created on the mirror.
As default use master as default database and grant connect.
Database roles lies in the database and will be available when failover and the database becomes live
April 29, 2008 at 6:03 am
AndyD (4/4/2008)
bbr (4/4/2008)
AndyD (4/3/2008)
...Database Mirroring is not the perfect high-availability solution. It is, however, very, very cheap compared to setting up a Microsoft Cluster.I don't agree. Database Mirroring is not a cheap alternative to Clustering. They both provide very different feature sets and serve different purposes.
I am genuinely interested in your views here. If you ignore the hardware setup, OS setup and costs (eg. MSCS requires Windows Server 2003 Enterprise or Datacenter editions, very exacting standards for hardware, etc), where are the differences?
Yes they are based on different technologies (transaction logging/shipping vs. virtual resources), and yes a Mirror is per database not per Instance. But if you are talking about a high-availability solution, with automatic failover, for a database, what are the differences?
The limitation of using "SQL Native Client" DSN is a factor (or the application being mirror-aware). But what else?
Andy
In my point of view, the application using the database is the achilles heel when dealing with mirroring.
Many applications are cluster-aware, which lets me move the cluster groups as I please, and even if the applications aren't cluster-aware, nothing but a restart of the application service is needed.
With mirroring though, many (most?) applications aren't mirror-aware, and because of that I need to restart the application service AND correct a connection string before I can use the database on the mirror server.
Because of this limitation, I/we will continue using MS Cluster for most HA solutions.
April 29, 2008 at 6:22 am
If the application makes use of a DSN, then choose "SQL Native Client". You can configure a Mirror with this DSN. The SQL Native Client could work with all VB and .NET apps (although apps could, of course, be written to connect to the DB via a different technology/protocol).
But you are right, the failover of a Mirror is nowhere near as clean as a Cluster. In particular, existing connections (or sessions) are likely to be lost. But I am still happy with what a Mirror can provide: namely, a high-availability solution at relatively low cost.
April 29, 2008 at 6:31 am
One advantage of mirroring is the ability to use a broader spectrum of hardware. In many onf the sites where we mirror, the backup server is the old production server.
Also the ability to separate the 2 servers over some distance.
These methods both have their pros and cons. You need to weight them against your requirements.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply