Home Forums SQL Server 2012 SQL 2012 - General Database Mirroring. Mirror server to be unavailable for 4 hours. What to do? RE: Database Mirroring. Mirror server to be unavailable for 4 hours. What to do?

  • simeharr (8/27/2015)


    Thank you for your thorough reply.

    You're welcome

    simeharr (8/27/2015)


    This seems to contradict the TechNet documentation

    Synchronous operation is maintained in the following manner:

    1. On receiving a transaction from a client, the principal server writes the log for the transaction to the transaction log.

    2. The principal server writes the transaction to the database and, concurrently, sends the log record to the mirror server. The principal server waits for an acknowledgement from the mirror server before confirming either of the following to the client: a transaction commit or a rollback.

    3. The mirror server hardens the log to disk and returns an acknowledgement to the principal server.

    On receiving the acknowledgement from the mirror server, the principal server sends a confirmation message to the client.

    High-safety mode protects your data by requiring the data to be synchronized between two places. All the committed transactions are guaranteed to be written to disk on the mirror server.

    Erm, no it doesn't, you're completely missing the detail below which precedes the section you posted above 😉

    MSDN - Database Mirroring Operating Modes


    To achieve synchronous operation for a session, the mirror server must synchronize the mirror database with the principal database. When the session begins, the principal server begins sending its active log to the mirror server. The mirror server writes all of the incoming log records to disk as quickly as possible. As soon as all of the received log records have been written to disk, the databases are synchronized. As long as the partners remain in communication, the databases remain synchronized.

    After synchronization finishes, every transaction committed on the principal database is also committed on the mirror server, guaranteeing protection of the data. This is achieved by waiting to commit a transaction on the principal database, until the principal server receives a message from the mirror server stating that it has hardened the transaction's log to disk. Note the wait for this message increases the latency of the transaction.

    The time required for synchronization depends essentially on how far the mirror database was behind the principal database at the start of the session (measured by the number of log records initially received from the principal server), the work load on the principal database, and the speed of the mirror system. After a session is synchronized, the hardened log that has yet to be redone on the mirror database remains in the redo queue.

    simeharr (8/27/2015)


    Good point, but I wanted to clarify whether their effect was the same? There is no effective difference between a SUSPEND and DISCONNECT during the period of DISCONNECTION. It only dictates how they respond with the mirror becomes available again?

    Yes, the end result is they both accumulate unsent log and the principal runs exposed

    .

    -----------------------------------------------------------------------------------------------------------

    "Ya can't make an omelette without breaking just a few eggs" 😉