Data in filegroup

  • I have 2 servers and each have a database which has multiple filegroups defined. One of this filegroup has 1 table on both server and data from one is replicated to teh other which means practically same vol fo data on this filegrroup. However what surprises me is that  filegroup space on the 2nd server is way above than  on the first server from where the data is replicated. Can anyone think fo any reason why there is so much fo difference. Its abt 3 GB space difference that i notice. any help will be greatly apprecaited.

  • if replication is in the way there can be many things going on Like:

    the delete sps are disable or commented out

    if data can be modified on the destination there is no need for both to be equal

    if queue updates are in place with SQL queue and with a long metadata retention period  you may have extra info there

    ... etc

    hth

     


    * Noel

  • Surprisingly the source server (in replication) has more rows but space usage is more on destination server. also can you please explain a bit more on

    "if queue updates are in place with SQL queue and with a long metadata retention period  you may have extra info there"

    Thanks

  • Queue updates with SQL Server as the manager of the queue mechanism implies that you will have an extra table : MSreplication_queue.

    If your queue reader has not piked those yet or is disabled there is information stored on it but again this is a big assumtion

    Are you sure you have the same number of objects on both files ?

     


    * Noel

  • Yes theres only 1 table on thsi filegroup on both sourec and destination. I am trying a dbcc updateusage to see if that makes any difference.

    any other thoughts/ideas??

  • Fargmentation level (due to page splitts) could also be the problem but I have never seen an extreme difference in size due to that.

    Do you have indexes rebuild on your target (large) table?

     

     


    * Noel

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

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