Results 1 to 7 of 7
  1. #1
    Join Date
    Jul 2004
    Posts
    6

    Question Unanswered: Estimating needed size when replicating

    Hi,

    Can somebody tell how to make an estimation of the size needed when creating a 'consult' DB with snapshot replication ?

    Thanks !

  2. #2
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Five liters.

    If you can be a bit more specific, I can be a bit more serious

    -PatP

  3. #3
    Join Date
    Jul 2004
    Posts
    6

    oeps


    sorry, i ment how much extra size is there needed besides the size of the database itself, like for systemtables and that kind of stuff....

  4. #4
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    The overhead within the database is trivial. I'd allow a megabyte or two tops.

    Now the distribution server (both database and snapshot file space) can be a very different story!

    -PatP

  5. #5
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    There is no difference in size between the published database and the resulting snapshot on the subscriber. Subscriber's disk subsystem needs to be as fast if not faster than the publisher's. Depending on the origin of invocation (I hate this style of writing myself, so don't laugh) of the distribution agent subscriber's CPU may take quite a bit of a hit. Network, interestingly, is very often the bottleneck. To minimize its affects, use Alternate location with compression (default location does not support compression option).
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

  6. #6
    Join Date
    Feb 2004
    Location
    In front of the computer
    Posts
    15,579
    Provided Answers: 54
    Quote Originally Posted by rdjabarov
    There is no difference in size between the published database and the resulting snapshot on the subscriber. Subscriber's disk subsystem needs to be as fast if not faster than the publisher's. Depending on the origin of invocation (I hate this style of writing myself, so don't laugh) of the distribution agent subscriber's CPU may take quite a bit of a hit. Network, interestingly, is very often the bottleneck. To minimize its affects, use Alternate location with compression (default location does not support compression option).
    At least on my servers, I get a handful of tables in the publisher that track the replication details (like syspublications, sysarticles, etc). The overhead is trivial, but it is there.

    I've never had problems with disk speed... The distributor always takes up the slack for me.

    I never use compression with databases. Maybe that's because I got bit so badly years ago, but I've never been able to justify doing it since.

    -PatP

  7. #7
    Join Date
    Jul 2003
    Location
    San Antonio, TX
    Posts
    3,662
    Pat, "years ago" alternate location and compression weren't supported, so I don't know what you're referring to
    "The data in a record depends on the Key to the record, the Whole Key, and
    nothing but the Key, so help me Codd."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •