Thank you very much for your answers!
Jeffrey: That sounds logical, I agree. But what about the part "The log scan number (82666:12760:1) passed to log scan in database.." in the error message?
It's great to hear that three mirrored databases shouldn't be an issue. As you say it might be the index rebuild that is suspending the mirror and then takes time to enable again. When it comes to the database snapshots, they are created ever 30 minutes in a SQL Agent job. The job first drops the existing snapshot (for each database) and then creates a new one. So there are no duplicates. Here's how it looked in the error log a few minutes before the database got suspended:
Recovery of database 'Principal_Database_Stats' (9) is 0% complete (approximately 208254 seconds remain). Phase 1 of 3.
Recovery of database 'Principal_Database_Stats' (9) is 0% complete (approximately 208239 seconds remain). Phase 1 of 3.
Recovery of database 'Principal_Database_Stats' (9) is 0% complete (approximately 208682 seconds remain). Phase 2 of 3.
Recovery of database 'Principal_Database_Stats' (9) is 2% complete (approximately 6120 seconds remain). Phase 2 of 3.
Recovery of database 'Principal_Database_Stats' (9) is 14% complete (approximately 869 seconds remain). Phase 2 of 3.
Recovery of database 'Principal_Database_Stats' (9) is 15% complete (approximately 802 seconds remain). Phase 2 of 3.
..
It then came to 35% with approx 800 seconds left, just before error 9003 occured.
At daytime and normal production load, the drop and create of the three snapshots take between 5 and 10 seconds. At the time of the index rebuild and the other "delete job" running at the same time, the snapshot job takes about 15 - 25 minutes.
Marios: I'll definitely look into upgrading to the latest CU. It had some interesting info, and the title of the fix is spot on to our problem!
Thanks once again for your answers, I appreciate it!
Sincerely,
Gord