You are using some scripts like:

RESTORE DATABASE YourDB

FROM  DISK = N'F:\MSSQL\BACKUPS\YourDB.BAK'

WITH  REPLACE, 

MOVE N'YourDB_Data' TO N'H:\data\YourDB_Data.MDF',

MOVE N'YourDB_Log' TO N'G:\Log\YourDB_Log.LDF'

to get a list of all triggers:

  select p.name,  

  t.name,  

  syscomments.text  

  FROM sysobjects t 

  INNER JOIN sysobjects p on p.id=  t.parent_obj  

  INNER JOIN syscomments on...

I would agree with Philip with one exception: try to create a server side trace with limited impact on the server, since most likely

it will be running...

run "limited" server side traces... they have minimal impact on the system

11 Active\Passive Clusters, about 250 SQL Servers with roughly 10 DBs on each server. 3 DBA

Did you update statistics with full scan or run dbcc dbreindex?...

you may want to design your own DBA database where you would store all info about other servers/databases/failed jobs/space... We are using a linked servers approach to collect all that...

maybe you want to split it into two files ( or more files) of the equal size to reduce the allocation resource contention for tempdb that is experiencing heavy usage....And might...

 Dbcc shrink file works faster since it works on file by file basis and the changes are permanently stored as it completed the single file operation. This is not a...

try to run profiler for the most commonly missed tables....

check if it helps: http://www.sqlservercentral.com/forums/shwmessage.aspx?forumid=5&messageid=271442

check/compare  Estimated Execution Plan on both Prod and Local box...

we collect data about failed jobs and displayed them in html report ( updated daily). It will take just couple of minutes to look into that then.

may be this can help you a bit:

http://www.microsoft.com/technet/prodtechnol/sql/2005/sqlupgrd.mspx

unless you want to run a light weight server side trace