<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: tools/strategy for server replication in Operating System - HP-UX</title>
    <link>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379983#M197360</link>
    <description>This is a lot more complicated than it sounds. You must first determin the worst case amount of data that will be transmitted. A T1 line or DSL is *very* slow for most databases. 1Mb/sec is only 100Kb/sec but because it is a WAN, the line turnaround time may be very slow, perhaps several hundred milliseconds. So you may see only 50Kb/sec or less. If you have a 50 Gb database, it will take about 277 hours to transmit. Oops..&lt;BR /&gt; &lt;BR /&gt;Now if you can figure out a way to transmit just the data that changed, then perhaps you can get this time down to a few hours. The problem is that for databases, there isn't a simple way to find just the changed records, indexes, etc. There are special accessories for Oracle, Sybase, etc which are designed to sync a remote database for DR purposes. But you still need to know the amount of changed data to see if there is enough time to sync all the data. You may need a much faster link (T3 at 45Mb) to make this DR plan work, even with a realtime sync.</description>
    <pubDate>Wed, 15 Sep 2004 22:07:09 GMT</pubDate>
    <dc:creator>Bill Hassell</dc:creator>
    <dc:date>2004-09-15T22:07:09Z</dc:date>
    <item>
      <title>tools/strategy for server replication</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379982#M197359</link>
      <description>I have a replica of a production server which is used as a DR (Disaster Recovery) server.  I would like to configure the PROD server to "sync" its data with the DR server overnight across the WAN (1Mb).  This would allow me to have the DR server come online immediately in the event of a DR without having to restore the system from tape.  What tools/strategy would you advise?   Thanks in advance.&lt;BR /&gt;&lt;BR /&gt;J</description>
      <pubDate>Wed, 15 Sep 2004 21:36:07 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379982#M197359</guid>
      <dc:creator>James Nguyen</dc:creator>
      <dc:date>2004-09-15T21:36:07Z</dc:date>
    </item>
    <item>
      <title>Re: tools/strategy for server replication</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379983#M197360</link>
      <description>This is a lot more complicated than it sounds. You must first determin the worst case amount of data that will be transmitted. A T1 line or DSL is *very* slow for most databases. 1Mb/sec is only 100Kb/sec but because it is a WAN, the line turnaround time may be very slow, perhaps several hundred milliseconds. So you may see only 50Kb/sec or less. If you have a 50 Gb database, it will take about 277 hours to transmit. Oops..&lt;BR /&gt; &lt;BR /&gt;Now if you can figure out a way to transmit just the data that changed, then perhaps you can get this time down to a few hours. The problem is that for databases, there isn't a simple way to find just the changed records, indexes, etc. There are special accessories for Oracle, Sybase, etc which are designed to sync a remote database for DR purposes. But you still need to know the amount of changed data to see if there is enough time to sync all the data. You may need a much faster link (T3 at 45Mb) to make this DR plan work, even with a realtime sync.</description>
      <pubDate>Wed, 15 Sep 2004 22:07:09 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379983#M197360</guid>
      <dc:creator>Bill Hassell</dc:creator>
      <dc:date>2004-09-15T22:07:09Z</dc:date>
    </item>
    <item>
      <title>Re: tools/strategy for server replication</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379984#M197361</link>
      <description>like Bill said, this involves looking at the amount of data and the kind of data.&lt;BR /&gt;&lt;BR /&gt;For databases like Oracle, Informix and even DB2 there exist build in funtionalities to do the replication.&lt;BR /&gt;&lt;BR /&gt;If it comes to simple file system data you could take a look at rsync for this task.&lt;BR /&gt;Rsync is based on a very sophisticated algorithm for data replication.&lt;BR /&gt;&lt;BR /&gt;Regards&lt;BR /&gt;Rainer</description>
      <pubDate>Thu, 16 Sep 2004 04:06:17 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379984#M197361</guid>
      <dc:creator>Rainer von Bongartz</dc:creator>
      <dc:date>2004-09-16T04:06:17Z</dc:date>
    </item>
    <item>
      <title>Re: tools/strategy for server replication</title>
      <link>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379985#M197362</link>
      <description>Hi James,&lt;BR /&gt;&lt;BR /&gt;If you are talking about Oracle you have RAC on 9i or standby database on previous versions.&lt;BR /&gt;&lt;BR /&gt;You must be more explicit explaining what is your situation...&lt;BR /&gt;&lt;BR /&gt;Eric&lt;BR /&gt;</description>
      <pubDate>Thu, 16 Sep 2004 04:15:46 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-hp-ux/tools-strategy-for-server-replication/m-p/3379985#M197362</guid>
      <dc:creator>Eric Antunes</dc:creator>
      <dc:date>2004-09-16T04:15:46Z</dc:date>
    </item>
  </channel>
</rss>

