Post reply

Stairway to Transaction Log Management in SQL Server, Level 9: Monitoring the Transaction Log

  • April 24, 2013 at 12:00 am

    #292434

    Comments posted to this topic are about the item Stairway to Transaction Log Management in SQL Server, Level 9: Monitoring the Transaction Log

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

  • April 24, 2013 at 8:19 am

    #1609529

    I work on a busy, highly transactional database server running SQL Server 2008 R2. There were performance problems last year which were wrongly attributed to SAN replication. Replication was switched off, the problems persisted, application changes were made which resolved the problems then Syncronous SAN Replication was switched back on.

    WRITE_LOG operations, as a percentage of overall wait time statistics, went from 20% to 50% as a result of re-enabling SAN replication. There's a battery backed write cache on the SAN but Disk Queue Lengths are up a bit and other PERFMON counters show a negative impact. The system is coping with SAN Replication on but there is definitely a cost associated with it, mainly to log writes.

    This article - http://blogs.msdn.com/b/psssql/archive/2013/04/22/how-it-works-always-on-when-is-my-secondary-failover-ready.aspx

    explains how 'Log Blocks' are replicated in AlwaysOn artictures, rather than discreet transactions, to maintain a syncronized state.

    We are about to implement a new (again highly transactional) system using SQL Server 2012 AlwaysOn with syncronous replica's at a DR site, local clusters at each site using shared storage, AlwaysOn data mirroring to the DR site instead of SAN replication.

    This and the PSS article compliment each other for certain architectures, both articles are great.

    Thanks

  • April 24, 2013 at 4:05 pm

    #1609745

    Paul Brewer (4/24/2013)

    WRITE_LOG operations, as a percentage of overall wait time statistics, went from 20% to 50% as a result of re-enabling SAN replication. There's a battery backed write cache on the SAN but Disk Queue Lengths are up a bit and other PERFMON counters show a negative impact. The system is coping with SAN Replication on but there is definitely a cost associated with it, mainly to log writes.

    I've had similar experiences

    Gail Shaw
    Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
    SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

    We walk in the dark places no others will enter
    We stand on the bridge and no one may pass

Viewing 3 posts - 1 through 2 (of 2 total)

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