Non- SQL Replication - Third Party Tools

  • We currently do use sql replication but day by day it has become more complicated and over head for because we use many synonyms and they dont work that great with SQL replication.

    We are looking for other non-sql replication products. I would like to know from other DBA's what other products do they use and approx how much does it cost. One example is Double-take replication, it does exactly what we need but i think this is a very expensive product. I would appreciate if others can provide there feedback on any third party product for replication.

    Our requirement is to have secondary always in sync with production and should ALWAYS be accessible. Secondary should get updated from primary instantly (like sql replication).

    Thanks

  • I've never used third party tools for replication.

    Question, though. This secondary server requirement for always online... Is it because you're using it as a report server?

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • No, not for reporting server. Our architecture is setup in such a way that all the reads has to go to local server and writes to central server(publisher). So secondary has to be available always.

  • Well, okay. There's still a non-Replication method around this.

    Depending on your edition, you could use Log Shipping or Data Mirroring to get a readable version of a secondary server. Log Shipping has more latency than Data Mirroring, but Data Mirroring only allows for a max of 3 servers to be set up (one as a witness).

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • I'm not sure mirroring or log shipping work if this is a local server being read only for online work in an application. Updates for both of those will cause issues with connections.

    I haven't used any third party replication tools, so can't help you here. What part of the synonyms causes issues with replication? Can you not replicate the underlying tables and then fix any issues with synonyms manually? Do synonyms change that often?

  • Brandie Tarvin (2/22/2012)


    Well, okay. There's still a non-Replication method around this.

    Depending on your edition, you could use Log Shipping or Data Mirroring to get a readable version of a secondary server. Log Shipping has more latency than Data Mirroring, but Data Mirroring only allows for a max of 3 servers to be set up (one as a witness).

    I don't think either will work because as i said data should be available ALWAYS. In LS DB will go into recovery mode for few secs and snapshot mirroring is not instant. I don't think there is a native SQL solution. I know our architecture is not that great but i need to provide best solution :). Thanks

  • Steve Jones - SSC Editor (2/22/2012)


    I'm not sure mirroring or log shipping work if this is a local server being read only for online work in an application. Updates for both of those will cause issues with connections.

    I haven't used any third party replication tools, so can't help you here. What part of the synonyms causes issues with replication? Can you not replicate the underlying tables and then fix any issues with synonyms manually? Do synonyms change that often?

    Actually thats what we have been doing. My biggest concern here is whenever we add a new object to subscriber we need to reset-up replication and re-create all synonyms ( about 2000 + across all databases) causing downtime to the application

  • Actually thats what we have been doing. My biggest concern here is whenever we add a new object to subscriber we need to reset-up replication and re-create all synonyms ( about 2000 + across all databases) causing downtime to the application

    I'm assuming you meant you had to re-setup replication when you add a new object to the publisher.

    You don't need to re-setup replication when you add a new article - depending on how you initialize your replication (via snapshot or via backup) you can add an article to replication without having to re-setup replication. We've been able to add and remove articles from our replicated environment without having to re-setup (following the steps listed here which apply for subscribers initialized via snapshot ->http://msdn.microsoft.com/en-us/library/ms146887(v=sql.90).aspx - for subscribers initialized by backup you need to manually create and populate the table on the subscribers and then use sp_addarticle).

  • winash (2/22/2012)


    Actually thats what we have been doing. My biggest concern here is whenever we add a new object to subscriber we need to reset-up replication and re-create all synonyms ( about 2000 + across all databases) causing downtime to the application

    I'm assuming you meant you had to re-setup replication when you add a new object to the publisher.

    I would assume publisher too, but just in case, could you please verify this, sqldba_newbie?

    If it's the subscriber that's causing you grief, there's a bigger issue with the server than your synonyms. At least, that's how I see it.

    Brandie Tarvin, MCITP Database AdministratorLiveJournal Blog: http://brandietarvin.livejournal.com/[/url]On LinkedIn!, Google+, and Twitter.Freelance Writer: ShadowrunLatchkeys: Nevermore, Latchkeys: The Bootleg War, and Latchkeys: Roscoes in the Night are now available on Nook and Kindle.

  • winash (2/22/2012)


    Actually thats what we have been doing. My biggest concern here is whenever we add a new object to subscriber we need to reset-up replication and re-create all synonyms ( about 2000 + across all databases) causing downtime to the application

    I'm assuming you meant you had to re-setup replication when you add a new object to the publisher.

    You don't need to re-setup replication when you add a new article - depending on how you initialize your replication (via snapshot or via backup) you can add an article to replication without having to re-setup replication. We've been able to add and remove articles from our replicated environment without having to re-setup (following the steps listed here which apply for subscribers initialized via snapshot ->http://msdn.microsoft.com/en-us/library/ms146887(v=sql.90).aspx - for subscribers initialized by backup you need to manually create and populate the table on the subscribers and then use sp_addarticle).

    let try this

Viewing 10 posts - 1 through 9 (of 9 total)

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