Hi,
I'm usin g profiler to trace TSQL (stmtstarting etc) and
there are 100s of rows with empty values for the textdata
column - any ideas why?
TIANot all events return data for every column. What events are these that have
the blank textdata values?
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Bob" <anonymous@.discussions.microsoft.com> wrote in message
news:ac8801c4d6fe$3192d480$a601280a@.phx.gbl...
> Hi,
> I'm usin g profiler to trace TSQL (stmtstarting etc) and
> there are 100s of rows with empty values for the textdata
> column - any ideas why?
> TIA|||sp:stmtStarting, sp:stmtCompleted :)|||Is it possible that the procedure is encrypted?
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"Bob" <anonymous@.discussions.microsoft.com> wrote in message
news:187c01c4d707$1473e8e0$a501280a@.phx.gbl...
> sp:stmtStarting, sp:stmtCompleted :)|||Kalen Delaney wrote:
> Is it possible that the procedure is encrypted?
>
> "Bob" <anonymous@.discussions.microsoft.com> wrote in message
> news:187c01c4d707$1473e8e0$a501280a@.phx.gbl...
>> sp:stmtStarting, sp:stmtCompleted :)
What I generally see with an encrypted SP in Profiler for
SP:StmtStarting/Completed is something like:
-- <sp_name> Encrypted Text
Strange.
David Gugick
Imceda Software
www.imceda.com
Wednesday, March 28, 2012
profiler
Hi
I need to gather user activities on our SQL2K server on
weekdays between 8-5 using the profiler. Is there a way to
schedule this to start and stop at these times?
Thanks,
MarkYou can create and start traces using TSQL scripts. You get a handle back with which you can stop
and close a trace. Easiest way to get started is to define the trace in Profiler, and from the
profiler menu save the trace definition as a TSQL script.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"mark" <anonymous@.discussions.microsoft.com> wrote in message
news:067d01c51055$dd11e810$a501280a@.phx.gbl...
> Hi
> I need to gather user activities on our SQL2K server on
> weekdays between 8-5 using the profiler. Is there a way to
> schedule this to start and stop at these times?
> Thanks,
> Mark
I need to gather user activities on our SQL2K server on
weekdays between 8-5 using the profiler. Is there a way to
schedule this to start and stop at these times?
Thanks,
MarkYou can create and start traces using TSQL scripts. You get a handle back with which you can stop
and close a trace. Easiest way to get started is to define the trace in Profiler, and from the
profiler menu save the trace definition as a TSQL script.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"mark" <anonymous@.discussions.microsoft.com> wrote in message
news:067d01c51055$dd11e810$a501280a@.phx.gbl...
> Hi
> I need to gather user activities on our SQL2K server on
> weekdays between 8-5 using the profiler. Is there a way to
> schedule this to start and stop at these times?
> Thanks,
> Mark
Profiler
Is there any way I can give user permission to run SQL profiler witout giving
them sysadmin access
thxstoney wrote:
> Is there any way I can give user permission to run SQL profiler
> witout giving them sysadmin access
> thx
No. It is a sysadmin function. SQL 2005 will have other options.
--
David Gugick
Imceda Software
www.imceda.com
them sysadmin access
thxstoney wrote:
> Is there any way I can give user permission to run SQL profiler
> witout giving them sysadmin access
> thx
No. It is a sysadmin function. SQL 2005 will have other options.
--
David Gugick
Imceda Software
www.imceda.com
profiler
I stsrted a trace on one of my bds and it is creating mulitple 5 mb files. I
thought it would stop once I closed the profiler. WRONG!!!
How can I stop this?You can use the following TSQL statement to identify the TraceID of any
Traces that are currently running:
SELECT DISTINCT traceid FROM :: fn_trace_getinfo(default)
You can then stop any running traces by setting the status of the TraceID to
stopped (0).
ie.
EXEC sp_trace_setstatus @.traceid = 1,
@.status = 0
HTH
- Peter Ward
WARDY IT Solutions
"Andre Gibson" wrote:
> I stsrted a trace on one of my bds and it is creating mulitple 5 mb files. I
> thought it would stop once I closed the profiler. WRONG!!!
> How can I stop this?|||thanks so much Peter,
I will try that
"P. Ward" wrote:
> You can use the following TSQL statement to identify the TraceID of any
> Traces that are currently running:
> SELECT DISTINCT traceid FROM :: fn_trace_getinfo(default)
> You can then stop any running traces by setting the status of the TraceID to
> stopped (0).
> ie.
> EXEC sp_trace_setstatus @.traceid = 1,
> @.status = 0
> HTH
>
> - Peter Ward
> WARDY IT Solutions
>
> "Andre Gibson" wrote:
> > I stsrted a trace on one of my bds and it is creating mulitple 5 mb files. I
> > thought it would stop once I closed the profiler. WRONG!!!
> >
> > How can I stop this?
thought it would stop once I closed the profiler. WRONG!!!
How can I stop this?You can use the following TSQL statement to identify the TraceID of any
Traces that are currently running:
SELECT DISTINCT traceid FROM :: fn_trace_getinfo(default)
You can then stop any running traces by setting the status of the TraceID to
stopped (0).
ie.
EXEC sp_trace_setstatus @.traceid = 1,
@.status = 0
HTH
- Peter Ward
WARDY IT Solutions
"Andre Gibson" wrote:
> I stsrted a trace on one of my bds and it is creating mulitple 5 mb files. I
> thought it would stop once I closed the profiler. WRONG!!!
> How can I stop this?|||thanks so much Peter,
I will try that
"P. Ward" wrote:
> You can use the following TSQL statement to identify the TraceID of any
> Traces that are currently running:
> SELECT DISTINCT traceid FROM :: fn_trace_getinfo(default)
> You can then stop any running traces by setting the status of the TraceID to
> stopped (0).
> ie.
> EXEC sp_trace_setstatus @.traceid = 1,
> @.status = 0
> HTH
>
> - Peter Ward
> WARDY IT Solutions
>
> "Andre Gibson" wrote:
> > I stsrted a trace on one of my bds and it is creating mulitple 5 mb files. I
> > thought it would stop once I closed the profiler. WRONG!!!
> >
> > How can I stop this?
PROFILER
Hello,
What would be the best place to run profiler, on the production Server or on
another client Machine?
Thanks,QA
http://vyaskn.tripod.com/server_side_tracing_in_sql_server.htm
"OA" <omrana@.verizon.net> wrote in message
news:%23GQ7oPukIHA.1052@.TK2MSFTNGP05.phx.gbl...
> Hello,
> What would be the best place to run profiler, on the production Server or
> on another client Machine?
>
> Thanks,
>sql
What would be the best place to run profiler, on the production Server or on
another client Machine?
Thanks,QA
http://vyaskn.tripod.com/server_side_tracing_in_sql_server.htm
"OA" <omrana@.verizon.net> wrote in message
news:%23GQ7oPukIHA.1052@.TK2MSFTNGP05.phx.gbl...
> Hello,
> What would be the best place to run profiler, on the production Server or
> on another client Machine?
>
> Thanks,
>sql
Profiler
We usually monitor our production server via profiler from
our desktop. We had an issue over the weekend and would
usually have the profiler results to review and
troubleshoot. However, over the weekend our desktop's were
rebooted and all info lost.
So we were thinking of running the profiler directly on
the production server but have read/heard of issue's
related to this and a potential performance hit on the
server. When running it on my own desktop I sometimes run
into memory issues.
What are the pro's and con's of running profiler directly
on the server?
What about running the stored proc's in query analyzer
from our desktop compared to running the profiler directly?
Would it be better to use the stored procedures instead of
profiler?
Any input would be greatly appreciated.
ThanksI don't run Profiler on the server directly because of the way I store the
Profiler data. In order to really use the data I find that I need to store
the profile stuff in a table. I don't like the idea of writing to the
production server so I have a seperate server where I run Profiler and log
the data in an SQL table.
Christian Smith
<anonymous@.discussions.microsoft.com> wrote in message
news:e36a01c3f0f4$082d9f80$a101280a@.phx.gbl...
> We usually monitor our production server via profiler from
> our desktop. We had an issue over the weekend and would
> usually have the profiler results to review and
> troubleshoot. However, over the weekend our desktop's were
> rebooted and all info lost.
> So we were thinking of running the profiler directly on
> the production server but have read/heard of issue's
> related to this and a potential performance hit on the
> server. When running it on my own desktop I sometimes run
> into memory issues.
> What are the pro's and con's of running profiler directly
> on the server?
> What about running the stored proc's in query analyzer
> from our desktop compared to running the profiler directly?
> Would it be better to use the stored procedures instead of
> profiler?
> Any input would be greatly appreciated.
> Thanks
>|||If your server's not under heavy load, this is probably ok, but if the
server is under heavy load, using the Profiler on the server might hurt
performance because it consumes CPU, memory to collect data, display on the
screen etc.
If you are dealing with a server under heavy load, there is a better
alternative:
SQL Profiler is a client side tool that collects data from SQL Trace (server
side component) and displays it on the GUI. SQL Trace can be run on it's own
on the server without the overhead of Profiler by using it's stored procs -
sp_trace_create (& cousins). SQL 7 has a different set of procs for this,
but I'll assume you're on SQL 2K for now unless you say otherwise..
When you use SQL Trace, you can set the output to go to a .trc file on the
server and open the .trc file later with Profiler, save to a table, run
queries whatever..
To make life super-easy when doing this, you can even define your SQL Trace
in SQL Profiler, then use SQL Profiler's scripting tool to script the
sp_trace_create commands. You can even schedule starting & stopping SQL
Trace via these stored procs from the SQL Agent.
For more info, read up on sp_trace_create in SQL Books Online..
Then again, if you're just doing ad-hoc tracing on a server that's not under
heavy load, you're probably ok running small-ish SQL Profilers directly on
the server, but do be sensitive that it will add load & might affect users..
HTH
Regards,
Greg Linwood
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:e36a01c3f0f4$082d9f80$a101280a@.phx.gbl...
> We usually monitor our production server via profiler from
> our desktop. We had an issue over the weekend and would
> usually have the profiler results to review and
> troubleshoot. However, over the weekend our desktop's were
> rebooted and all info lost.
> So we were thinking of running the profiler directly on
> the production server but have read/heard of issue's
> related to this and a potential performance hit on the
> server. When running it on my own desktop I sometimes run
> into memory issues.
> What are the pro's and con's of running profiler directly
> on the server?
> What about running the stored proc's in query analyzer
> from our desktop compared to running the profiler directly?
> Would it be better to use the stored procedures instead of
> profiler?
> Any input would be greatly appreciated.
> Thanks
>|||you can script the sp_trace calls directly per greg's
description or just run profiler on the server,
under almost no circumstances should profiler be saving
directly to a table on the production server
set it to save to a file, and place the file on lightly
loaded disk
also, an accumalation rate by profiler of <1000 line
items /sec should not be a significant load on the server,
but to be safe, try to keep it under 200/sec
>--Original Message--
>We usually monitor our production server via profiler
from
>our desktop. We had an issue over the weekend and would
>usually have the profiler results to review and
>troubleshoot. However, over the weekend our desktop's
were
>rebooted and all info lost.
>So we were thinking of running the profiler directly on
>the production server but have read/heard of issue's
>related to this and a potential performance hit on the
>server. When running it on my own desktop I sometimes run
>into memory issues.
>What are the pro's and con's of running profiler directly
>on the server?
>What about running the stored proc's in query analyzer
>from our desktop compared to running the profiler
directly?
>Would it be better to use the stored procedures instead
of
>profiler?
>Any input would be greatly appreciated.
>Thanks
>.
>
our desktop. We had an issue over the weekend and would
usually have the profiler results to review and
troubleshoot. However, over the weekend our desktop's were
rebooted and all info lost.
So we were thinking of running the profiler directly on
the production server but have read/heard of issue's
related to this and a potential performance hit on the
server. When running it on my own desktop I sometimes run
into memory issues.
What are the pro's and con's of running profiler directly
on the server?
What about running the stored proc's in query analyzer
from our desktop compared to running the profiler directly?
Would it be better to use the stored procedures instead of
profiler?
Any input would be greatly appreciated.
ThanksI don't run Profiler on the server directly because of the way I store the
Profiler data. In order to really use the data I find that I need to store
the profile stuff in a table. I don't like the idea of writing to the
production server so I have a seperate server where I run Profiler and log
the data in an SQL table.
Christian Smith
<anonymous@.discussions.microsoft.com> wrote in message
news:e36a01c3f0f4$082d9f80$a101280a@.phx.gbl...
> We usually monitor our production server via profiler from
> our desktop. We had an issue over the weekend and would
> usually have the profiler results to review and
> troubleshoot. However, over the weekend our desktop's were
> rebooted and all info lost.
> So we were thinking of running the profiler directly on
> the production server but have read/heard of issue's
> related to this and a potential performance hit on the
> server. When running it on my own desktop I sometimes run
> into memory issues.
> What are the pro's and con's of running profiler directly
> on the server?
> What about running the stored proc's in query analyzer
> from our desktop compared to running the profiler directly?
> Would it be better to use the stored procedures instead of
> profiler?
> Any input would be greatly appreciated.
> Thanks
>|||If your server's not under heavy load, this is probably ok, but if the
server is under heavy load, using the Profiler on the server might hurt
performance because it consumes CPU, memory to collect data, display on the
screen etc.
If you are dealing with a server under heavy load, there is a better
alternative:
SQL Profiler is a client side tool that collects data from SQL Trace (server
side component) and displays it on the GUI. SQL Trace can be run on it's own
on the server without the overhead of Profiler by using it's stored procs -
sp_trace_create (& cousins). SQL 7 has a different set of procs for this,
but I'll assume you're on SQL 2K for now unless you say otherwise..
When you use SQL Trace, you can set the output to go to a .trc file on the
server and open the .trc file later with Profiler, save to a table, run
queries whatever..
To make life super-easy when doing this, you can even define your SQL Trace
in SQL Profiler, then use SQL Profiler's scripting tool to script the
sp_trace_create commands. You can even schedule starting & stopping SQL
Trace via these stored procs from the SQL Agent.
For more info, read up on sp_trace_create in SQL Books Online..
Then again, if you're just doing ad-hoc tracing on a server that's not under
heavy load, you're probably ok running small-ish SQL Profilers directly on
the server, but do be sensitive that it will add load & might affect users..
HTH
Regards,
Greg Linwood
SQL Server MVP
<anonymous@.discussions.microsoft.com> wrote in message
news:e36a01c3f0f4$082d9f80$a101280a@.phx.gbl...
> We usually monitor our production server via profiler from
> our desktop. We had an issue over the weekend and would
> usually have the profiler results to review and
> troubleshoot. However, over the weekend our desktop's were
> rebooted and all info lost.
> So we were thinking of running the profiler directly on
> the production server but have read/heard of issue's
> related to this and a potential performance hit on the
> server. When running it on my own desktop I sometimes run
> into memory issues.
> What are the pro's and con's of running profiler directly
> on the server?
> What about running the stored proc's in query analyzer
> from our desktop compared to running the profiler directly?
> Would it be better to use the stored procedures instead of
> profiler?
> Any input would be greatly appreciated.
> Thanks
>|||you can script the sp_trace calls directly per greg's
description or just run profiler on the server,
under almost no circumstances should profiler be saving
directly to a table on the production server
set it to save to a file, and place the file on lightly
loaded disk
also, an accumalation rate by profiler of <1000 line
items /sec should not be a significant load on the server,
but to be safe, try to keep it under 200/sec
>--Original Message--
>We usually monitor our production server via profiler
from
>our desktop. We had an issue over the weekend and would
>usually have the profiler results to review and
>troubleshoot. However, over the weekend our desktop's
were
>rebooted and all info lost.
>So we were thinking of running the profiler directly on
>the production server but have read/heard of issue's
>related to this and a potential performance hit on the
>server. When running it on my own desktop I sometimes run
>into memory issues.
>What are the pro's and con's of running profiler directly
>on the server?
>What about running the stored proc's in query analyzer
>from our desktop compared to running the profiler
directly?
>Would it be better to use the stored procedures instead
of
>profiler?
>Any input would be greatly appreciated.
>Thanks
>.
>
Profiler
How big is the performance penalty for running profiler?The best phrase I've heard is "you pay as you go".
In other words, if you have one row and lots of columns in profiler for
every page-lock event, then the hit will be significant. On the other hand,
if you only trace infrequent events, and capture few columns, like say,
login/logout, then the penalty will be negligable.
--
Kevin Connell, MCDBA
----
The views expressed here are my own
and not of my employer.
----
"Andrew" <a@.b.com> wrote in message
news:085901c38cdb$e56df160$a001280a@.phx.gbl...
> How big is the performance penalty for running profiler?
In other words, if you have one row and lots of columns in profiler for
every page-lock event, then the hit will be significant. On the other hand,
if you only trace infrequent events, and capture few columns, like say,
login/logout, then the penalty will be negligable.
--
Kevin Connell, MCDBA
----
The views expressed here are my own
and not of my employer.
----
"Andrew" <a@.b.com> wrote in message
news:085901c38cdb$e56df160$a001280a@.phx.gbl...
> How big is the performance penalty for running profiler?
Subscribe to:
Posts (Atom)