Platform: SQL Server 2000 with sp4 , Win2k3

Can I schedule the SQL profiler to run autimatically on certain time?

Thank you.
Maggie

I don't think you want to schedule an interactive GUI to run at certain
times. You should schedule a server-side trace (not using the Profiler GUI)
to capture data to a trace table. Here is an article that might help you
get started:

http://vyaskn.tripod.com/server_side_tracing_in_sql_server.htm

And this will show you why you want a server-side trace instead of an active
profiler:

http://sqlblog.com/blogs/linchi_shea/archive/2007/08/01/trace-profiler-test.aspx

Even though you are on 2000, the performance characteristics are likely very
equivalent, depending on how much data your trace is collecting (both which
columns, and how the filters are limiting rows).

A

Aaron Bertrand [SQL Server MVP] (ten.xoc@dnartreb.noraa) writes:

And it's far better to trace to file than to a table.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

Again, depending on how much data is actually being saved, I would argue
that USING the data from a table is going to be far easier than a file in
the long run. :-)

On 5/6/08 6:13 PM, in article Xns9A9725C6292FYazorman@127.0.0.1, "Erland
Sommarskog" wrote:

Aaron Bertrand [SQL Server MVP] (ten.xoc@dnartreb.noraa) writes:

Definitely. But getting the data from the file into a table is just a matter
of using fn_trace_gettable().

And if the trace is on a busy production system, it may be better to load
the file on a different server to run the analysis of the data.

--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

I agree with Erland and tracing directly to a table will most likely impede
overall performance of the server while tracing to a file will likely not
see an impact. I actually do all my analyzing directly from the files and
never touch a table but that is not to say a table will not be useful to
some. Just don't impede performance gathering the data in the first place.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors

"Erland Sommarskog" wrote in message
news:Xns9A975E5A39CBYazorman@127.0.0.1...

Yes, and I was only suggesting a table in the first place because scheduling
a trace seems to imply that it will be for a limited amount of time and
therefore, hopefully, a limited amount of data and impact on the server.

On 5/7/08 8:47 AM, in article uqbd0BEsIHA.5096@TK2MSFTNGP02.phx.gbl, "Andrew
J. Kelly" shadhawk.com> wrote:

I routinely run traces for only a minute or less but end up with GB's worth
of trace information. Time is not as important as the frequency and type of
statements executed along with what events are being captured.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors

"Aaron Bertrand [SQL Server MVP]" wrote in message
news:C4471E78.3BE9%%ten.xoc@dnartreb.noraa...

I know, that is why I initially said, " depending on how much data your
trace is collecting (both which columns, and how the filters are limiting
rows)."