Yes, database mirroring is a reliable technology and is in use by many Enterprise customers today. I've helped people set up mirroring both while inside and outside Microsoft - I used to own database mirroring when I responsible for the SQL Server Storage Engine.
As with any HA technology, you need to understand your requirements and limitations before choosing technologies to help you implement an HA strategy. If you choose technologies before doing this and try to retrofit them to your requirements, you won't get a successful strategy.
I've just finished writing a 35-page whitepaper on HA with SQL Server for the SQL team - it'll be published before SQL PASS. In the meantime, to get an idea of the kind of questions to ask yourself, see this blog post of mine: HA: Where do you start when choosing a high-availability solution?. For database mirroring, you need to consider:
- How many databases are in your application ecosystem? I.e. what resources need to all be failed over at once. More than 2-3 and you might look at failover clustering with SAN replication instead.
- Outside a single application ecosystem, how many databases do you want to mirror? Going more than 10 and you'll start to see issues with worker threads, memory, and waits on the shared mirroring send buffer.
- What is the transaction log generation rate?
- What is the network bandwidth and latency? These two things determine whether the mirror will be in synch with the principal - and how much data loss you may be looking at in asynch mode (from a large send queue) or workload throughput degeneration from having to wait for transactions to be hardened on the mirror (for synch mode)
And so on.
Once you set up mirroring, you'll need to monitor it to make sure its working within your desired parameters - most important things to monitor are the SEND and REDO queues - which give you a measure of how far behind the mirror is, and how much time a failover will take, respectively. It doesn't need continuous tuning in common scenarios, but YMMV as with any technology.
Automatic failover - it depends. There are a variety of scenarios to consider, in terms of which network links go down, which mirroring partners go down, and what the actual failure is. Checkout this blog post for a list of failures: Search Engine Q&A #3: Database mirroring failover types and partner timeouts.
This has all been a bit of a brain dump, but to summarize, yes, mirroring is reliable and shouldn't need excessive tuning and monitoring. SQL Server 2008 added some cool new stuff to help - log stream compression and automatic page repair - both of which I've blogged about in my Database Mirroring blog post category.
Finally - there are a bunch of good whitepapers you should look at (see the database mirroring links on our whitepapers uber-links page - I wrote the one on combining database mirroring with transactional replication in SS2008) and a new book Pro SQL Server Mirroring.
Hope this helps!
Simply put you must activate the mirror from the principal server in the High Safety mode without automatic fail over.
This method is great for planned outages and maintenance. It is not really beneficial in a disaster or unplanned downtime scenario as you cannot fail over without access to the principal server.
I use a very low cost old computer running MSSQL express as the monitor server. It has windows XP pro on it. I am sure you can find a small computer to carry out the task of the monitor server.
Something that can meet minimum requirements for MSSQL express will do fine.
Hope this helps.
Best Answer
If you have several databases, I recommend clustering. Mirroring is configured and managed per database, whereas clustering is configured and managed per instance. That's a very big (and potentially time-consuming) difference.