?

thats a high number. How big is the log?

I would recommend scheduling an outage to shrink the log right down then grow it again in sensibly sized chunks.

see http://www.sqlskills.com/BLOGS/KIMBERLY/post/Transaction-Log-VLFs-too-many-or-too-few.aspx

Probably the number of vlfs in the log file, excessive numbers slow recovery.

run dbcc loginfo(yourdbname)

and see how many rows returned, thats how many vlfs you have

the no. of vlfs is very possibly the cause for the slow recovery. Reducing the number should help.

If the no is large I would shrink the log right down and...

any errors from the log restore job?

any evidence in the errorlog of logs being restored?

what does query

select * from msdb..log_shipping_monitor_secondary

say about last copied and restored files?

GilaMonster (1/17/2012)

No, there won't be just one log backup to restore. You'll have just...

storing them in msdb keeps your SSIS packages together with your other SQL objects, it also means you have a ready made backup mechanism for the packages as long as...

The only thing that I can think of which is no big deal is Database ID's would be different if I do not attach them in the same order then...

see the FAQ here

which version of the security patch you apply depends on the version of SQL you are patched up to - you want the GDR, not the QFE

GilaMonster (1/13/2012)

Maybe, assuming that truncation was necessary and that said truncation...

the OP may need to back up the log as well, but I would not expect active log in a read only database,

but either way the log cannot be shrunk...

Definitely. But if you are applying directly after SP4 apply the GDR version - 2494120

truncate the log file means remove the inactive portion of the log, it does not physically shrink the size of the log file on the drive, only a shrink command...

sorry Dev, that won't make the files any smaller.