DMS replication has become unusable since Sunday

Question

After our maintenance window on Sunday our latency spike. Had usually been in the seconds.

I'm not sure if we upgraded from 3.5.1 to 3.52 or something to that effect, but afterwards haven't been able to get it working. Can't keep up.

Seems like it really wants to read from the transaction log backup and it seems very slow on our machines. Have rebooted and upped the size on everything involved. Just can't seem to read the transactions fast at all.

Did anything happen Sunday the 22nd? Wondering if there is an easy way to find out what happened to our DMS instance that morning? We did have logging turned on, but having a hard time searching through it.

twiggy · Answer

So after upgrading from 3.4.x to 3.5.x our latency from SQL Server got super slow. This was a forced upgrade by AWS.

Turns out our production instance had a 8 tempdb files. Some where on the Z: drive and some on the C: drive. Not sure why this freaked SQL Server out, but fn_dblog performance got very poor. Tempdb verison store old transaction time steadily increased.

Dropped down to 2 tempdb files both on Z and contention went away. Luckily we had a QA system where we didn't have that config and saw the Tempdb stats in one of our monitoring tools.

I did notice the syntax of the fn_dblog call changed from 3.4 to 3.5 with a few additional parts of the where clause. Like a lot of things SQL server probably uses the tempdb during the fn_dblog calls...wish they would just admit it needs to be a documented function.

DMS replication has become unusable since Sunday

Add your answer

Relevant content