recovery mode and log size

hi friends,
after setting merge replication my log file is incresing continuouly.its going in gbs.what should be the optimum log file size for a database.what are the microsoft recommendations regarding this
what should be the best recovery mode to implement.it is simple,full,bulklogback.
which should be the efficient .
what is the microsoft recommendations for this
please help
thanks
reddy
Reddy,
the size of the transaction log depends on too many factors to recommend a fixed value. As you're using merge replication, this shouldn't be related to transactions not read from the log.
The frequency of the backup of the database depends on the normal factors - personally I backup the database each evening and the log every 30 mins.
If it is particularly large then you might increase the frequency of your log backups (if you're doing things this way). Generally, to remove committed transactions - backup the log, truncate the log or use simple recovery mode. To reduce the log size, ru
n DBCC SHRINGFILE.
HTH,
Paul Ibison
|||paul,
thanks for your solution
regards
reddy
"Paul Ibison" wrote:

> Reddy,
> the size of the transaction log depends on too many factors to recommend a fixed value. As you're using merge replication, this shouldn't be related to transactions not read from the log.
> The frequency of the backup of the database depends on the normal factors - personally I backup the database each evening and the log every 30 mins.
> If it is particularly large then you might increase the frequency of your log backups (if you're doing things this way). Generally, to remove committed transactions - backup the log, truncate the log or use simple recovery mode. To reduce the log size,
run DBCC SHRINGFILE.
> HTH,
> Paul Ibison

Records Deleted after merge

PKs and FKs are all uniquidentifiers.
(the db will eventually have 100's of subscribers)
The FK validation errors only occur sometimes - this the odd thing.
And when it does happen it is on new records added by one subscriber, so
there shouldn't be any conflicts.
Thx
You may get the behavior you describe if your foriegn keys are missing the
"NOT FOR REPLICATION" option.
|||Thanks Jim.
Any idea where can I get more details on this behaviour?
Darren
|||I haven't seen any documentation on this yet but basically you cannot
guarantee that replication will apply your changes in the order that they
originally occured.
"Darren Wallace" wrote:

> Thanks Jim.
> Any idea where can I get more details on this behaviour?
> Darren
>
>
|||Thanks Jim.
Pity about that.
So it sounds like all foreign keys should have the Not For Replication
option.
Cheers
Darren