Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>(Disclaimer: I'm a developer, not a DBA)</p> <p>We have SQL Server 2005 merge replication set up to replicate between two active/active geographically-separated nodes for resilience in a legacy system.</p> <p>I don't know whether it's easy to monitor; outside of my remit.</p> <p>It creates triggers on every table to do the publish/subscribe mechanism, each of which calls its own stored procedure.</p> <p>In our case, it was set up to use identities 1-1bn in node 0, 1bn-2bn in node 1 to avoid identity collisions (rather than use a composite key of NodeId + EntityId for each table, or change keys to be GUIDs, for example).</p> <p>I think the replication latency is around 15s (between London and New York over dedicated bandwidth).</p> <p>It is a <strong>huge pain to work with</strong>:</p> <ul> <li>It took a highly paid contractor a year to set it up (granted, part of this was due to the legacy nature of the DB design)</li> <li>We lack anyone in-house with the expertise to support it (the in-house DBA we had took ~6 months to learn it, and has since moved on)</li> <li>Schema updates are now <strong>painful</strong>. From what I understand: <ul> <li>Certain updates must be performed on only one node; replication then takes care of figuring out what to do on the other node(s)</li> <li>Certain updates must be performed on both nodes</li> <li>Data updates must be performed on one node only (I think)</li> <li>All updates now take significantly longer to perform - from the split-second it takes to run a DDL change-script to ~30 minutes</li> </ul></li> <li>I don't know for sure, but I think the bandwidth requirement for replication is very high (in the MBit/s range)</li> <li>It introduces <strong>many</strong> "noise" objects (3 sprocs per table, 3 triggers per table) into the DB, making it inconvenient to find in the object explorer the item that one wants to work on.</li> <li>We will <strong>never</strong> set up a third node for this system, based largely on the perceived difficulty and added pain it would introduce at deployment-time.</li> <li>We also now lack a staging environment that mirrors production, because it's too painful to set up.</li> <li>Anecdotal: The DBA doing the setup would frequently curse the fact that it was an "MS v1" he was being forced to work with.</li> <li>Dimly remembered: The DBA needed to raise several priority support tickets to get help from MS directly.</li> </ul> <p>Granted - some of the pain involved is due to our specific environment and not having in-house talent to support this setup. Your mileage may vary.</p>
    singulars
    1. This table or related slice is empty.
    1. POPeer to peer replication in SQL Server 2005/08
      singulars
      1. PTQuestion
    1. PTAnswer
    1. This table or related slice is empty.
    1. USPeter Mounce
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POPeer to peer replication in SQL Server 2005/08
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. CO(PTP replication has nothing to do with merge replication. It works with transactionnel rep, where all servers are publishers/subscribers). I am really surprised by yr comments on merge replication, schema updates and bandwidth issues. Can you confirm it, or are these just things you've heard?
      singulars
      1. PO
      1. USPhilippe Grondier
    2. COThese are issues I have to help deal with during 5am usage-ebb-time deployments. (Thanks for clarifying PTP vs merge replication; I hadn't realised they were two different things.)
      singulars
      1. PO
      1. USPeter Mounce
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload