Comments (8)

  1. I’m worried about some of these “debunks”.

    Number 4 is correct but it seems clear that the myth being debunked is that MS doesn’t have a big idiocy/usability problem in the UI here – it’s more a subject for a connect item than for a “myth” debunking – presenting it as a myth suggests that we should put up with this appalling bit or UI design.

    Number 3 is debunking something that just is not a myth. “Committed” does not mean anything like “written to the database pages so that the log entries are now redundant” it means “committed to the log”. There may be a myth that says recovering committed transactions is low cost – if so debunk that (easily done) instead of pretending that there is a different myth.

    Number 2 is corret but there are other work-arounds than the one described. I don’t think the other work-arounds should be used, but if you don’t mention them someone will notice them and use them. For example (at least in WIn2003, I haven’t looked at later versions) one can change the permissions/privileges of the Local System built-in account, so the debunk should point this out and also point out that doing so would be absolutely stupid.

  2. Thanks for the feedback Tom!!

    I agree that #4 would make a good Connect item. I consider it a bug. In fact, I consider that MSFT recommends starting in high performance mode and the default mode is high safety to be a problem. The default mode should be the one they recommend you start in unless a Witness is included.

    For #3, I don’t agree that it not a valid myth. The myth is that many people do not understand what is meant by “committed” in this context. They think that committed means that the transaction is hardened to the database and not just the log file. When I tell people that SQL Server may have to roll transactions forward when they fail over, I usually get a response that the session was in sync and therefore all of the transactions were already committed.

    I agree that there are different ways this could have been approached, but as is, it is a valid myth.

    For #2, how would you change the permissions of the Local System account so that it can connect to a different SQL Server? If that is possible, I don’t know how to do it.

    Again, thanks for the feedback. It was some very good comments!!

  3. interesting, thanks

  4. […] Robert, the lead author of “Pro Database Mirroring”, shares some very good information around Database Mirroring myths. Its a fun technologu that was introduced in SQL Server 2005 and optimized even more in SQL Server 2008. […]

  5. Hi Soldier,

    Good explaination….

    Could you have any steps for How to change the SQL server service account on the

    DB mirroring server.

    Thanks,
    Rama

    1. Thanks Rama!! The SQL Server service account is external to the database. You can change it without worry as long as it has CONNECT permissions to the endpoint of all other servers involved with mirroring sessions on the server.

  6. […] blogged about this issue back in 2010: Top 5 Myths of Database Mirroring. When you mirror a database to a higher level version, at the point of failover, the mirroring […]

  7. […] blogged about this issue back in 2010: Top 5 Myths of Database Mirroring. When you mirror a database to a higher level version, at the point of failover, the mirroring […]

Leave a Reply