Great article and equally good and interesting responses.
Food for thought. Whilst Mirroring in my mind used to be a great feature when we used to build Servers (physical) for SQL, these days I tend to not set mirroring up as often as I am completely satisfied with the redundancy offered in VM environments.
In the days of physical servers the concern was that both physical and software related failure (except for data corruption as that will also be mirrored) could cause system failure and warrant a switch to the mirror.
With virtual environments, Hardware redundancy is ideally built into the VM environment and in my view the risk of software failure is minimal as I have never had this happen to me even when we had physical servers.
The only scenario where software could possibly fail is when an patch or software update is implemented on the server. In these circumstances, I would normally have tested said software patches or updates before applying to live environment. Additionally, I would have scheduled downtime and therefore take a VM snapshot before applying patches so I can revert back instantly if needed.
Therefore I find the need for mirroring servers is becoming less. Even when system uptime is crucial, I would consider building a Mirror when I do a software update, switch to the mirror, break the mirror, apply the patch, switch the mirror to the main, test to ensure it is working, if satisfied remove the mirror.
If I wish to upgrade from say SQL 2005 to SQL 2012, I tend to simply build a new SQL Server completely in VM, copy database over, then change all sofware to point to the new database. Leaving the SQL 2005 in place and ready to fire up if need to revert back.
I find many software companies tend to recommend mirror setup, but on questioning they are normally unable to provide good reason and I get the impression they simply suggest this as they think it is the best and safest option.
Anyhow, I would be interested in others thoughts or views on this