Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
mfemenel
Professor Frink
1421 Posts |
 Posted - 2004-11-04 : 12:59:34
|
| I was playing with creating traces today, and I love it, but I'm stuck trying to take it to the next level. Due to all the warnings about running profiler on production, i really don't want to have to use it so please, let's try to find a way around this. I create a trace, no problem, dumps out to a trace file, all good and wonderful. The behavior is that the trace file doesn't dump out to disk until it reaches the max file size and then if you told it to, it rolls to another file. What I'm wanting to do is to be able to repalce using profiler, with traces. What that means is i'd like to do,in near real time is get that file data into a table without having to stop the trace, read the file, restart the trace. That way I can run some real time stats and information without having to use profiler and also without having to stop & start my trace. Any ideas?Mike"oh, that monkey is going to pay" |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2004-11-04 : 16:19:56
|
| You can save directly to a table when you run a trace. While the trace is running, you can read from the table. Is that what you want?Tara |
 |
|
|
mfemenel
Professor Frink
1421 Posts |
Posted - 2004-11-04 : 16:24:06
|
| From profiler, yes, you can do that, but I'm lazy, I don't want to sit down and remote desktop over and run the trace every day. I want it to be automated and send it to my table for me so I don't have to think about it. I was playing with the trace stored procedures and got it worked out how to create and run a trace, but that option only lets you dump it to a file and it keeps the file locked until it reaches its max size, or the trace ends.Mike"oh, that monkey is going to pay" |
|
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2004-11-04 : 16:32:03
|
| This won't help your problem about the file being locked, but this will help you automatically load them into a table (it's from graz):http://weblogs.sqlteam.com/billg/archive/2004/04/11/cleartrace.aspxAnyway, running scripted traces has the same performance issue that SQL Profiler has. So you should do it sparingly or filter only the data that you need. Both have more overhead when you run it on the database server, but I'm sure that's not what you are referring to as that's the number one no no for traces or SQL Profiler.Tara |
|
|
|
mfemenel
Professor Frink
1421 Posts |
Posted - 2004-11-04 : 16:37:22
|
| Graz's solution is great, if the damn file was closed, it would be 100%. But I digress. Believe me, I know profiler can do bad things but the scripted traces, from what I've read are the lesser of the 2 evils. We have a new system and for a few more months, we need to keep a close eye until we've got it all humming along the way we want it to. I'm thinking later on I'll sample 15 mins every few hours and that should balance between the risk and early warning.Mike"oh, that monkey is going to pay" |
|
|
|
|
|
|
|
|
Trace Files