Post reply

Database Mirroring to reduce down time during DB Releases?

  • July 30, 2007 at 9:54 am

    #117665

    Good day -

    I have been trying to read about DB Mirroring, when I saw the following:

    Improves the availability of the production database during upgrades.

    During synchronous operation, the database administrator can use manual failover. To use database mirroring for software upgrades, the mirror server and/or system must have already received the upgrades. For more information, see "Role Switching," later in this topic.

    and that prompted the question, could I use mirroring to allow our releases to upgrade one DB, while the other is up, taking transactions, and when done, somehow "merge" the DB's, resulting in a DB with the new changes (SP's, table structure, etc) with the newly written transactions?

    Does this make any sense?

    C

    -- Cory

  • July 30, 2007 at 10:01 am

    #723345

    those upgrades refer to OS upgrades not to DB upgrades


    * Noel

  • July 30, 2007 at 10:04 am

    #723346

    Mirroring propagates updates right away. I know about the case when somebody had the upgrade failed and the mirror database got corrupted too. Next time he requested to break the mirror before the upgrade and it worked better.

    Regards,Yelena Varsha

  • July 30, 2007 at 10:07 am

    #723348

    Fair enough, that makes sense - is there any way that this could work? 

    If I need am tasked with getting downtime for DB Maint to as small of a period as possible, how might this be accomplished?  I am sure there are places that run nearly 24 hours, they must need time for DB upgrades (schema), right?

    I was thinking that at the time of the DB Schema changes (new release of internal code), we could break the mirror, run on the backup, upgrade the primary "offline", and bring it back...getting the new transactions, and propagating the changes...

    Am I nuts?  Is this possible?

    C

    -- Cory

  • July 31, 2007 at 9:01 am

    #723618

    I am currrently looking at Mirroring in a production environment and was considering the options ... here are some thoughts ---- thinking as I type:

    For Service Packing SQL Server i have read that you are required to break the mirror and service pack the members individually.  This will mean that your HA solution is no more....

    An Option is to implement logshipping from the primary to the Witness (make use of the Spare instance) then when you break the Mirror you still have a HA solution.  the problem comes when you want to add the mirror as a partner again.

    HMM

    You could failover to the Logshipped Server then SP the Principal and rejoin the Mirror ... But What about the Logshipped Witness???

    There is No Easy Option..  Except Downtime

    As there are No Service Packs Available yet (since mirroring went mainstream) we will have to wait and see what the Reccomendations are.

    Since a schema change on the Offline Principal (now the mirror) will mean that the Backup from the Principal will have to be restored to the mirror, the only option without loosing data is probably downtime.

    I may be wrong

    Andy

Viewing 5 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply