July 10, 2008 at 6:07 am
george sibbald (7/10/2008)
well, looks like a done deal, so good luck. If you get performance problems make sure vmware admin is involved as well and its not just dumped on the 'database'.
Couldn't agree with this statement more. We are still facing a couple of issues from time to time and everyone points to me. I'm doing all the checking I can of processes, memory constraints, disk I/O and things are fine the majority of the time but you get that one time every couple of days....I think it's the way vmware and the san are working together. Sixteen disks but all vm machines are sharing the resources. Same with the eight processors. I truly believe that's where the issues are coming from, not from the database. Still trying to prove it out....and when I do, look out! 😀
-- You can't be late until you show up.
July 10, 2008 at 10:07 am
Hi Sharon,
1. Yes, we run the trace on the server that is being audited. The trace rollover argument of sp_trace_create specifies that when the trace file reaches it's max file size, the current trace file is closed and an new file is created. In the example I gave, the max file size is 5 mb.
2. As I mentioned, our trace is stopped once a day then restarted. Each time it's started it creates a new trace file with the current date as part of the filename. You don't need to stop the SQL Server service to stop the trace. Just use sp_trace_setstatus.
3. Yes, because the trace is stopped and restarted.
Greg
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply