Worth checking this link - contains a part about file cleanup;

http://ola.hallengren.com/sql-server-backup.html

Cheers

Vultar

Hi,

Checkpoints write all dirty pages to disk.. Whether they're committed or not, if the page has changed in memory, it will get written to disk.

Cheers

Vultar

How many rows are in the data sets being merged ?

I guessing the population of the cache is taking the additional 8 seconds, especially if the query usually runs sub...

Think you'll need to break the mirroring because you won't be able to move the storage for the db - unless the Eva's can do this in the background (ones...

You need to change the polling interval setting in the merge agent profile - the default is 60 secs.

Cheers

Vultar

Hi,

How many subscribers have you got.. Are the push or pull ? 1200+ publishers seems a lot for 1 distribution db. Have you Checked the waits, locking, blocking etc ?...

Sounds like the distribution agent hasn't / isn't running.. I'm guessing the sync type of the publication is automatic because you've run the snapshot agent - the distribution agent needs...

I think option 1 would be the best and easiest to manage in this situation.

Re-publishing from a subscriber adds another level of complexity.

You can re-initialize a single subscription without effecting...

Thanks for your response!

Granting these permissions was one of the 1st things I tried - tried again to double check and it still didn't work.

I've made some progress since my...

Try inserting a tracer token via the relication monitor to find where the issue is.. That should give you a good starting point on where to investigate the latency (pub...

Have you looked into the possibility of using Mirroring ? I think that would be an easier option here.

Cheers

Vultar

Thanks for your post.. I've just fixed a database with exactly the same error using this method 🙂 Have you had anymore thoughts as to why it occurred in the...

vultar (7/5/2012)

---

maybe try a rebuild using the SORT_IN_TEMPDB option ?

this should prevent the transaction log from ballooning.. just make sure you have enough space in your tempdb to accommodate the...

maybe try a rebuild using the SORT_IN_TEMPDB option ?

this should prevent the transaction log from ballooning.. just make sure you have enough space in your tempdb to accommodate the amount...

I've seen this before on a non-prod cluster and restarting the agent also fixed the problem.

For me, me the problem appeared after the system clock was maunally changed.

Cheers

Vultar