Showing posts with label profiler. Show all posts
Showing posts with label profiler. Show all posts

Friday, March 30, 2012

Read80Trace.exe in SQL Server 2005

My present production environment is in SQL Server 2000 and we are
planning to upgrade to SQL Server 2005 soon. I use the profiler a lot
and then use Read80trace.exe to process the trace files.
However, the Read80Teace does not accept a trace file from SQL Server
2005 and a SQL Server 2000 profiler does not connect to SQL Server
2005.
Are there any other tools similar to Read80Trace.exe for SQL Server
2005? If not, is there a way to trick the tool to accept a file from
SQL server 2005?
Thanks.
Sorry that I can't answer your question but I was hoping to get some help from you. I am interested in using Read80Trace.exe but have some questions on it. What specific eventclasses do you use when capturing your profile for use with Read80Trace? t
he documentation talks about capturing different events for different needs but is unclear as to what exactly is needed for use as a "minimul set". I would like to use the capture for reporting but do not need all of the events because I am not going to
use the Ostress tool. I just want the minimul set of events to get the most out of reporting... Any help you could offer would be greatly appreciated...
************************************************** ********************
Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
|||Hi
The format of trace files seems to be different to SQL 2000, but you can
work around this by loading the SQL 2005 trace into a table and then
exporting it back into SQL 2000. You can then use SQL 2000 profile to read
the table and save it as a trace file to feed into Read80Trace.
John
"baddy" wrote:

> My present production environment is in SQL Server 2000 and we are
> planning to upgrade to SQL Server 2005 soon. I use the profiler a lot
> and then use Read80trace.exe to process the trace files.
> However, the Read80Teace does not accept a trace file from SQL Server
> 2005 and a SQL Server 2000 profiler does not connect to SQL Server
> 2005.
> Are there any other tools similar to Read80Trace.exe for SQL Server
> 2005? If not, is there a way to trick the tool to accept a file from
> SQL server 2005?
> Thanks.
>
|||Hi
The event classes for Read80Trace are listed in the help file as
·SQL: Cursor Open/Close – Cursors
·Attention - Errors and warnings
·Audit:Login/Logout - Security Audit
·ExistingConnection - Sessions
·RPC:Starting/Completed - Stored Procedures
·RPC:OutputParameter - Stored Procedures
·Prepare/Unprepare SQL - TSQL
·SQL:BatchStarting/Completed – TSQL
If you use the scripted trace in the help file then it seems to log
everything, therefore if you want to script the trace I would create your own
by setting up the events above and using the file/script trace option in SQL
Profiler. These are the events for capture
For aggregation analysis check out the events described in the Events &
Columns for Aggregation in the Design Overview. This lists
·Audit:Login/Logout - Security Audit
·ExistingConnection - Sessions
·RPC:Starting/Completed - Stored Procedures
·SP:Starting/Completed - Stored Procedures
It does not list the following, but if you are not using stored procedures
you may want to also capture (I have not seen if these are used in the
analysis)
·SQL:BatchStarting/BatchCompleted – TSQL
·SQL:StmtStarting/StmtCompleted – TSQL
John
"Paul S" wrote:

> Sorry that I can't answer your question but I was hoping to get some help from you. I am interested in using Read80Trace.exe but have some questions on it. What specific eventclasses do you use when capturing your profile for use with Read80Trace?
the documentation talks about capturing different events for different needs but is unclear as to what exactly is needed for use as a "minimul set". I would like to use the capture for reporting but do not need all of the events because I am not going t
o use the Ostress tool. I just want the minimul set of events to get the most out of reporting... Any help you could offer would be greatly appreciated...
> ************************************************** ********************
> Sent via Fuzzy Software @. http://www.fuzzysoftware.com/
> Comprehensive, categorised, searchable collection of links to ASP & ASP.NET resources...
>
|||Something else...
I had issues with transfering the columns of image datatype, so don't
capture BinaryData and LoginSID.
John
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> The event classes for Read80Trace are listed in the help file as
> ·SQL: Cursor Open/Close – Cursors
> ·Attention - Errors and warnings
> ·Audit:Login/Logout - Security Audit
> ·ExistingConnection - Sessions
> ·RPC:Starting/Completed - Stored Procedures
> ·RPC:OutputParameter - Stored Procedures
> ·Prepare/Unprepare SQL - TSQL
> ·SQL:BatchStarting/Completed – TSQL
> If you use the scripted trace in the help file then it seems to log
> everything, therefore if you want to script the trace I would create your own
> by setting up the events above and using the file/script trace option in SQL
> Profiler. These are the events for capture
> For aggregation analysis check out the events described in the Events &
> Columns for Aggregation in the Design Overview. This lists
> ·Audit:Login/Logout - Security Audit
> ·ExistingConnection - Sessions
> ·RPC:Starting/Completed - Stored Procedures
> ·SP:Starting/Completed - Stored Procedures
> It does not list the following, but if you are not using stored procedures
> you may want to also capture (I have not seen if these are used in the
> analysis)
> ·SQL:BatchStarting/BatchCompleted – TSQL
> ·SQL:StmtStarting/StmtCompleted – TSQL
> John
> "Paul S" wrote:
? the documentation talks about capturing different events for different needs but is unclear as to what exactly is needed for use as a "minimul set". I would like to use the capture for reporting but do not need all of the events because I am not going
to use the Ostress tool. I just want the minimul set of events to get the most out of reporting... Any help you could offer would be greatly appreciated...[vbcol=seagreen]
|||Opps.. this was supposed to be on my reply to baddy's post!!!
"John Bell" wrote:
[vbcol=seagreen]
> Something else...
> I had issues with transfering the columns of image datatype, so don't
> capture BinaryData and LoginSID.
> John
> "John Bell" wrote:
ce? the documentation talks about capturing different events for different needs but is unclear as to what exactly is needed for use as a "minimul set". I would like to use the capture for reporting but do not need all of the events because I am not goi
ng to use the Ostress tool. I just want the minimul set of events to get the most out of reporting... Any help you could offer would be greatly appreciated...[vbcol=seagreen]
|||I used to do that (manually load trace files into SQL tables) before
Microsoft opened up Read80Trace to the whole world. Read80Trace is
very very fast in loading a trace file into tables. For example, it can
load a 750 MB trace file (approximatelt 3.5 million rows in the trace)
and generate an RML output in about 2 minutes or less.
Nothing else that I know of comes anywhere close to this.
John Bell wrote:
> Hi
> The format of trace files seems to be different to SQL 2000, but you can
> work around this by loading the SQL 2005 trace into a table and then
> exporting it back into SQL 2000. You can then use SQL 2000 profile to read
> the table and save it as a trace file to feed into Read80Trace.
> John
>
|||I used to do that (manually load trace files into SQL tables) before
Microsoft opened up Read80Trace to the whole world. Read80Trace is
very very fast in loading a trace file into tables. For example, it can
load a 750 MB trace file (approximatelt 3.5 million rows in the trace)
and generate an RML output in about 2 minutes or less.
Nothing else that I know of comes anywhere close to this.
John Bell wrote:
> Hi
> The format of trace files seems to be different to SQL 2000, but you can
> work around this by loading the SQL 2005 trace into a table and then
> exporting it back into SQL 2000. You can then use SQL 2000 profile to read
> the table and save it as a trace file to feed into Read80Trace.
> John
>
|||it depends on what exactly you are trying to analyze. most imortant
you should include endtime column. with that info, you do not need the
start event. let me know if you need more specific info on what events
/ col to use.
|||But did you use that technique to convert between the SQL 2005 trace files
and SQL 2000?
John
"baddy" wrote:

> I used to do that (manually load trace files into SQL tables) before
> Microsoft opened up Read80Trace to the whole world. Read80Trace is
> very very fast in loading a trace file into tables. For example, it can
> load a 750 MB trace file (approximatelt 3.5 million rows in the trace)
> and generate an RML output in about 2 minutes or less.
> Nothing else that I know of comes anywhere close to this.
>
> John Bell wrote:
>

Wednesday, March 28, 2012

Read the profiler output.

In 2005 I am running the profiler on 2 large batch processes that we run.
I am focusing on READS. Query below.
select * from ecdbprod.[ASPState].[dbo].[Tweaks2]
where Reads > 15000
and substring(TextData, 1,31 ) != 'exec MAR_Get_Daily_Trans_Report '
and loginName != 'ELECTRACASH\srussell'
--and substring(TextData, 1,20 ) != 'exec ARP_getPrevious'
Or should I be going for duration instead?
I am excluding a B2B report at this time as well as one SP that I have
tuned.
Any ideas on this method of madness?
TIA
__Stephen_Stephen wrote:
> In 2005 I am running the profiler on 2 large batch processes that we run.
> I am focusing on READS. Query below.
> select * from ecdbprod.[ASPState].[dbo].[Tweaks2]
> where Reads > 15000
> and substring(TextData, 1,31 ) != 'exec MAR_Get_Daily_Trans_Report '
> and loginName != 'ELECTRACASH\srussell'
> --and substring(TextData, 1,20 ) != 'exec ARP_getPrevious'
> Or should I be going for duration instead?
> I am excluding a B2B report at this time as well as one SP that I have
> tuned.
> Any ideas on this method of madness?
> TIA
> __Stephen
>
Reads is generally a good thing to focus on, but it really depends on
what your bottlenecks are. If your server is CPU-bound, focus on CPU.
If it is I/O-bound, focus on reads.|||_Stephen wrote:
> In 2005 I am running the profiler on 2 large batch processes that we run.
> I am focusing on READS. Query below.
> select * from ecdbprod.[ASPState].[dbo].[Tweaks2]
> where Reads > 15000
> and substring(TextData, 1,31 ) != 'exec MAR_Get_Daily_Trans_Report '
> and loginName != 'ELECTRACASH\srussell'
> --and substring(TextData, 1,20 ) != 'exec ARP_getPrevious'
> Or should I be going for duration instead?
> I am excluding a B2B report at this time as well as one SP that I have
> tuned.
> Any ideas on this method of madness?
> TIA
> __Stephen
>
Reads is generally a good thing to focus on, but it really depends on
what your bottlenecks are. If your server is CPU-bound, focus on CPU.
If it is I/O-bound, focus on reads.|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:O3irMBalGHA.2112@.TK2MSFTNGP04.phx.gbl...
> Reads is generally a good thing to focus on, but it really depends on what
> your bottlenecks are. If your server is CPU-bound, focus on CPU. If it is
> I/O-bound, focus on reads.
My indicators for the performance monitor are showing huge lock counts, and
when I drill around I see that the counts can be up into the 10,000 for
brief bursts. The CPUs are chugging along around 25% usage as a guess when
you try to put all the graph lines together.
Locks to me are more IO then CPU so I'll stick to that tact.
Thanks again.|||_Stephen wrote:
> "Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
> news:O3irMBalGHA.2112@.TK2MSFTNGP04.phx.gbl...
> My indicators for the performance monitor are showing huge lock counts, an
d
> when I drill around I see that the counts can be up into the 10,000 for
> brief bursts. The CPUs are chugging along around 25% usage as a guess whe
n
> you try to put all the graph lines together.
> Locks to me are more IO then CPU so I'll stick to that tact.
> Thanks again.
>
Are you monitoring scans? High reads and the bursts of lock counts
could be caused by excessive table or index scans, indicating the need
to better indexing...|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:O3irMBalGHA.2112@.TK2MSFTNGP04.phx.gbl...
> Reads is generally a good thing to focus on, but it really depends on what
> your bottlenecks are. If your server is CPU-bound, focus on CPU. If it is
> I/O-bound, focus on reads.
My indicators for the performance monitor are showing huge lock counts, and
when I drill around I see that the counts can be up into the 10,000 for
brief bursts. The CPUs are chugging along around 25% usage as a guess when
you try to put all the graph lines together.
Locks to me are more IO then CPU so I'll stick to that tact.
Thanks again.|||_Stephen wrote:
> "Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
> news:O3irMBalGHA.2112@.TK2MSFTNGP04.phx.gbl...
> My indicators for the performance monitor are showing huge lock counts, an
d
> when I drill around I see that the counts can be up into the 10,000 for
> brief bursts. The CPUs are chugging along around 25% usage as a guess whe
n
> you try to put all the graph lines together.
> Locks to me are more IO then CPU so I'll stick to that tact.
> Thanks again.
>
Are you monitoring scans? High reads and the bursts of lock counts
could be caused by excessive table or index scans, indicating the need
to better indexing...

Monday, March 26, 2012

Read the profiler output.

In 2005 I am running the profiler on 2 large batch processes that we run.
I am focusing on READS. Query below.
select * from ecdbprod.[ASPState].[dbo].[Tweaks2]
where Reads > 15000
and substring(TextData, 1,31 ) != 'exec MAR_Get_Daily_Trans_Report '
and loginName != 'ELECTRACASH\srussell'
--and substring(TextData, 1,20 ) != 'exec ARP_getPrevious'
Or should I be going for duration instead?
I am excluding a B2B report at this time as well as one SP that I have
tuned.
Any ideas on this method of madness?
TIA
__Stephen_Stephen wrote:
> In 2005 I am running the profiler on 2 large batch processes that we run.
> I am focusing on READS. Query below.
> select * from ecdbprod.[ASPState].[dbo].[Tweaks2]
> where Reads > 15000
> and substring(TextData, 1,31 ) != 'exec MAR_Get_Daily_Trans_Report '
> and loginName != 'ELECTRACASH\srussell'
> --and substring(TextData, 1,20 ) != 'exec ARP_getPrevious'
> Or should I be going for duration instead?
> I am excluding a B2B report at this time as well as one SP that I have
> tuned.
> Any ideas on this method of madness?
> TIA
> __Stephen
>
Reads is generally a good thing to focus on, but it really depends on
what your bottlenecks are. If your server is CPU-bound, focus on CPU.
If it is I/O-bound, focus on reads.|||"Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
news:O3irMBalGHA.2112@.TK2MSFTNGP04.phx.gbl...
> Reads is generally a good thing to focus on, but it really depends on what
> your bottlenecks are. If your server is CPU-bound, focus on CPU. If it is
> I/O-bound, focus on reads.
My indicators for the performance monitor are showing huge lock counts, and
when I drill around I see that the counts can be up into the 10,000 for
brief bursts. The CPUs are chugging along around 25% usage as a guess when
you try to put all the graph lines together.
Locks to me are more IO then CPU so I'll stick to that tact.
Thanks again.|||_Stephen wrote:
> "Tracy McKibben" <tracy@.realsqlguy.com> wrote in message
> news:O3irMBalGHA.2112@.TK2MSFTNGP04.phx.gbl...
>> Reads is generally a good thing to focus on, but it really depends on what
>> your bottlenecks are. If your server is CPU-bound, focus on CPU. If it is
>> I/O-bound, focus on reads.
> My indicators for the performance monitor are showing huge lock counts, and
> when I drill around I see that the counts can be up into the 10,000 for
> brief bursts. The CPUs are chugging along around 25% usage as a guess when
> you try to put all the graph lines together.
> Locks to me are more IO then CPU so I'll stick to that tact.
> Thanks again.
>
Are you monitoring scans? High reads and the bursts of lock counts
could be caused by excessive table or index scans, indicating the need
to better indexing...

Read SQL Profiler Trace output

Hi Folks,

I want to Read the SQL Profiler Trace Output using VB or VB.NET

I read some forums. They advice to import SMO in VB.NET..

But how can i Import this....

This is very Urgent for me....

Please Reply me immediately...You don't need SMO to read trace output. select from ::fn_get_trace into a table, then use normal ADO.Net to access the trace data from the table.|||Thanks for Reply...

Please can u give me a sample code for this....

Please this is very urgent for me...|||

First thing you need to do is set up your trace to go into a file. (Sending the trace data directly into SQL Server is very bad for performance.) Once you've got the trace file you can do something like this (which is right out of Books Online - see that document for more details.)

USE AdventureWorks;

GO

SELECT * INTO temp_trc

FROM fn_trace_gettable('c:\temp\my_trace.trc', default);

GO|||Thanks for help me...