| Steven J. Serenska 2005-05-31, 7:23 am |
| Paul:
Thanks very much. I will try these out.
[Also, sorry for posting the original message in the wrong thread. I
must have clicked Reply instead of Compose. All followups will be made
to this thread.]
Paul Horan[TeamSybase] wrote:
> "Steven J. Serenska" < sjs@RemoveTheseWords
Banksurance.com> wrote in
message news:429b91b1$1@foru
ms-1-dub...
>
JOINs. I am using SQLA 9.0.2.3044.[color=darkred]
>
> <snip>
>
subject line above for humorous purposes. Can[color=darkred]
looking at to discover why performance suffers in[color=darkred]
lengthy and highly specific to my application.[color=darkred]
>
>
> Before you start your application, run the following two statements
in ISQL:
> call sa_server_option( 'request_level_loggi
ng', 'SQL');
> call sa_server_option( 'request_level_log_f
ile',
'<drive\path\filename.txt>');
>
> Now run the application, and note where you are (what the retrieval
arguments are) when it gets "slow".
>
> call sa_server_option( 'request_level_loggi
ng', 'None');
> call sa_server_option( 'request_level_log_f
ile', '');
>
> In that .txt file, you'll see all the SQL that the server was asked
to process. What you can do at this point, is find
> the "slow" queries, cut them to the clipboard, paste them back into
ISQL, and select Get Plan. It will show you exactly
> what access plan it chose to process the query. Compare the slow
plan to the fast plan, and see if that doesn't
> illuminate the problem. You might also take the Index Consultant for
a spin - it can recommend additional indexes that
> might help.
>
> You may need to run CREATE STATISTICS on some (or all) of the tables
involved in the query.
>
|