Sounds like you're using CDR replication, and you are using the APP detection when creating the pair to replicate the SQL database?  Are you trying an out-of-band sync or just a straight over the wan copy when starting?

Here comes my vent for the CDR our of-band-sync with exchange...prepare yourself.  First, I would love your 16GB db vs the 200GB db exchange server with 50gb + logs I'm trying to replicate and the 24 regions the same situation.  V8 SP5 CDR, I went round and round with support on the best method for trying to replicate this data over a wan.  After numerous failed attempts with CV failing on itself and trying to re-replicate the entire edb file.  Only one method seemed plausible after speaking with Cliff from the replication team.  CV fails because of two reasons on the out of band sync.  Either 1) USN was not marked properly prior to backing the data up and moving it to destination or 2)FLR change journal has already rolled itself over in the commserv database and CV can't recover.  (The FLR rolling typically occurs when there is to much time between getting the data to destination and starting the pair.  Come to find out there is also a way support can flag FLR and reset it after syncing the data.  Wish I knew this prior to the other 10 failed attempts and prior to us upgrading to V9 SP1a which is suppose to solve all the problems by checking itself via the gui.  Well in a sense V9 does correct it.  Except on V9 in our environment being this large it takes the GUI out of band option 3 days to finally begin replicating, which by this time either source or destination is already flooded with 20+ GB of cv rep logs while it was busy checking itself and this puts itself so far behind that it never can catch up across the wan.  Which leads me to another support call tomorrow to see if there is a method in v9 sp1a to perform a successful out of band sync without it taking 3 days to try itself and causing itself to get behind and never able to sync up.  I'm sorry, we can't afford 2 weeks of no CRP's occurring while an out-of-band sync tries to occur.  Maybe there is a way to out-of-band sync the rep logs...really...come on.

Not sure if my vent above made sense, but to truely answer your question.  You're probably failing because CDR thinks the destination does not match the source and therefore is attempting to re-replicate your entire DB.  Again this is caused by either the USN not being set properly before moving the data or FLR rolling to quickly in the commserv database and not being flagged and reset prior to starting the pair.  The CDR.log will tell you exactly why if you just tail it on source.  Another common cause is the setting on the CDR Agent.  It will stop/fail itself if source or destination hits a certain threshold of free space on the cv logs directory.  This is configurable as well as where the logs are placed on both source and destination.

I wish you luck, if you find a workable out of band sync method please let me know.  Still looking for that magic answer that I'm sure someone knows.  Cliff in Replication support has been the most help.  Knowledgable guy.  Hopefully I can reach him tomorrow.  This environment being setup for replication keeps getting pushed and pushed because one thing after another...sigh.

Thank you Man, i am trying my best and will help you too anyways can you tell me where can i set USN number in the commserver..??

Thanks

This is for the out of band sync method....

Make sure the pair is in a stopped or new pair state.  On the source server open a command prompt.  Navigate to the base folder and run this command:

cdrxhelp.exe -readUSN -cn *sourceservername* -vm Instance001 -pID *pair id of the rep pair*

This will query the source USN and tell you what the current USN of change journal is.  Mark the USN down and run the command to set the USN.  This will tell commvault what point in time to start checking for changes to replicate.  Remember there is stil FLR that is tracked in commserv and I know it can be tracked and set in the DB, but if you move the data over quick enough this shouldn't be a concern.  Now just run the command to tell CommVault what USN to start at.

cdrxhelp.exe -setUSN -cn *sourceservername* -vm Instance001 -pID *pair id of the rep pair* -USN *usn value returned from previous command*

With the USN set.  Take a backup using other means or simply stop SQL and do a flat file copy.  Place your data in your destination location specified in the pair.  Simply restart replication.  Setting the USN tells commvault to bypass the baseline phase and simply replicate only changed data.