Thanks for the feedback guys 🙂 Much appreciated!
I have tried trace flag 1485 on the mirror, just to be sure, but as the Guru theorized; there is probably only one thread applying log entries. I have 32 cores to the work, and only 2 are running at 100%, so no thread starvation here; no threadpool waits either <scratches a suggestion of a *very small* list>. 't was worth a try 🙂
I have moved one of the problem DWH's to a Fusion IO card that has only the tempdb on it (which does next to nothing on a dedicated mirror) to rule out any IO related issues.
And to my dismay; the size of the "unrestored log" of last night's ETL run was even bigger!
As a last step before i escalate to the Microsoft CST, i will go from the deprecated mirroring to HA mirroring.
Yes, yes.... I know there is a only a small chance that it will fix it since it is essentially still mirroring, but I do not see any other options that I can try.
I have even read every KB's above my build level to see if there is any fix that will address the mirror restore speed problem, but nothing is mentioned about log speed.
So HA it is, and after that.... ?
Logshipping does not seem a viable alternative either, since it does the same as mirrorring; except that it "mirrors" log entries in chunks of 15 minutes. My problem seems to lie in the process that applies the log entries to the database file.
And i found i cannot trust the mirror monitor software either, It claims for one DB: 222 GB unsent log + 221 GB unrestored log, while the actual log sizes where 167 GB and 35 GB....
Any more idea guys?
p.s. @TheSQLGuru;
i feel your pain, i had my laptop stolen recently.... and even though you make backups, it takes weeks to get your PC "comfy" again!