File size / disk space for replication

  • I am setting up SQL Server 2005 for merge replication with around 160 clients running SQL Server 2005 Express and set up for pull subscription. The data will be partitioned but the partitions will be overlapping. I am trying to keep as many tables as possible as download only.

    On a development server I have noticed that the transaction log has grown in size dramatically and it seems to create a new snapshot folder for each client. I am concerned at the amount of disk space this scenario could use and potential problems.

    I have come across a couple of Microsoft articles:

    http://support.microsoft.com/kb/317375

    http://support.microsoft.com/kb/873235

    If I limit the size of the transaction log file is this going to store up problems for the future?

    If we have a couple of clients that do not synchronise for a period of time or stop altogether is this going to cause problems?

    Should the system be creating a snapshot folder for each client?

    Bit of a novice so forgive the basic questions.

    Any help or advice greatly appreciated.

    Thanks in advance.

    JDS.

     

  • When you have partitions it would generate snapshot seperately for every client.

    Because the snapshot is different for each and every client so it tries to generate .sch and.bcp files accordingly.

    What you can do in this aspect is check the retention period of the publication.  Also check if your cleanup agent is running properly.  if not take a backup and then execute the agent so that the metadata gets cleaned up.  But before that ensure that all your subscribers are in sync.

     

    Hope this answers your question

     

  • Thanks for this. I will look into the setup in more detail. As each snapshot is specific to a client it would be ideal to delete it after use - the time involved in re-creation is manageable but the number of them is a concern and once they have been applied I do not see why they need to be retained.

    I am also concerned about the size of the transaction log. Again, I will look into the settings in more detail.

     

    Thanks.

  • Jeremy,

    The size of the transaction log (of the app db) won't grow faster because of replication.

    One question: how are you going to implement the pull replication on SQL 2005 Express Editions?

  • Erik,

    Thanks for the reply. I saw the transaction log jump in size and I assumed it was because of implementing replication - they say you should never assume!

    The replication on the clients seems to be working well. It is set up as a merge pull subscription over a web connection, tested first from Windows synchronisation and now implemented using RMO in VS2005. Getting there was painful to ensure all the settings were correct.

    Jeremy.

Viewing 5 posts - 1 through 4 (of 4 total)

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