Skip to Content

If ASE server was been disable MDA monitoring, you hit a query issue frequently and hard to identify the exact query being run by the user at the point in time. You want to capture submitted SQL using application tracing.  

Following is steps of Application Tracing:

  1. Use sp_who to find the spid of the slow query in application.
  2. set tracefilepathname’ for spid
  3. Enable desired options
    dbcc traceon(3604)
    set show_sqltext on
    set statistics time, io on
  4. Check tracing (sp_helpapptrace)
  5. (run test in application)
  6. set tracefile off for spid

       For example, during the slow query being run:

      ————————-

      isql -Usa -P<pwd> -S<servername>

      1> sp_who                                   –find spid of the slow uery, e.g. spid 12

      2> go

      1> set tracefile ‘/tmp/spid12_20150825.out’ for 12

      2> go

      1> dbcc traceon(3604)

      2> go

      1> set show_sqltext on                 –‘set’ commands apply to session 12 from now on

      2> go

      1> set statistics time, io on

      2> go

          <Waiting for the query (session:12) to finish>

      1> set tracefile off                      — disable tracing

      2> go

      1> set tracefile off for 12

      2> go

      You could find trace output in tracefile: ‘/tmp/spid12_20150825.out’.
      ————————-

Application Tracing in ASE 15.0.2 and above:

  • Capture executing SQL in another session
  • Capture diagnostics output from that another session into a file
  • Set options in another session than yourself 
          set showplan, set statistics…
  • All fully transparent to the session being traced

Please note:

  • set tracefile {‘pathname’ | off } [for spid]
    1. Saves all SQL text to a flat file until turned off
    2. Session tracing is enabled for the spid/session being traced.
        It is not the perspective that the sa session is tracing a spid, but rather that a spid is being traced
    3. You can also trace yourself — for example from a login trigger
       
    Restrictions
    1. You cannot save the SQL text for system tasks (housekeeper, checkpoint process, etc.).
    2. You must have the sa or sso roles, or be granted set tracing permission
    3. set tracefile is not allowed to open an existing file as a tracefile.
    4. During an SA or SSO session, if you enable set tracfile for a specific spid, all subsequent tracing commands executed take effect on that spid, not the SA or SSO spid.
    5. You cannot trace more than one session at a time from a single sa or sso session.
    6. You cannot trace the same session from multiple sa or sso sessions.

           Notes
           1. The file storing the trace output is closed when the session being traced quits or when you disable tracing.
           2. Before you allocate resources for tracing, keep in mind that each tracing requires one file descriptor per engine.

  • sp_helpapptrace
    System proc reporting sessions being traced, and those doing the tracing.
      
  • Set options that affect tracing
    set show_sqltext [on | off]   (requires trace flag 3604 to be on)
    set showplan [on | off]
    set statistics io [on | off]
    set statistics time [on | off]
    set statistics plancost [on | off]
    set option show [normal | brief | long | on | off]
    set option show_ …. (etc)  
      
  • Tracing a session

    Once you have enabled tracing for a session, any further set commands associated with QP debugging take effect for the session being traced vs. the session issuing the commands.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply