I am trying to run through a trace log to improve one of our databases here,
however, the calls originate inside a read only database, goto another
database on the same server before they finally end up in the destination
database that i want to tune.
How can i get the advisor to travel through these other two databases?
Right now, it doesn't even recognize any of the statements because none of
them affect any databases it knows about.
BryanHi Bryan
I assume that you have selected all these databases/tables on the general
tab? In which case I would try look at the query plans when run manully from
management studio or possibly try and unravel what the queries and run them
directly and then look at the query plans.
John
"Bryan Aldrich" wrote:
> I am trying to run through a trace log to improve one of our databases her
e,
> however, the calls originate inside a read only database, goto another
> database on the same server before they finally end up in the destination
> database that i want to tune.
> How can i get the advisor to travel through these other two databases?
> Right now, it doesn't even recognize any of the statements because none of
> them affect any databases it knows about.
> Bryan|||Yes, I even tried by selecting all of the databases involved in this trace
file. I even selected Master to see if it would execute the sp_ExecuteSQL
calls, but it didn't. It analyzes the originating database just fine. I see
the sp_ExecuteSQL call go through, but it logs it as "not referencing any
tables".
I'm hoping for some sort of automated solution because it can be difficult
to always recreate the exact parameters that make it to this database.
Bryan
"John Bell" wrote:
[vbcol=seagreen]
> Hi Bryan
> I assume that you have selected all these databases/tables on the general
> tab? In which case I would try look at the query plans when run manully fr
om
> management studio or possibly try and unravel what the queries and run the
m
> directly and then look at the query plans.
> John
> "Bryan Aldrich" wrote:
>|||Hi Bryan
Without knowing exactly what you are doing it is difficult to really
recommend anything other than the manual approach, any automated tuning
should be taken as advice that should be reviewed rather than something whic
h
is an absolute necessity. I would also recommended that you have a system
which can be benchmarked and any changes compared so that you can be sure
that it is a positive change before implementing it on a live environment.
John
"Bryan Aldrich" wrote:
[vbcol=seagreen]
> Yes, I even tried by selecting all of the databases involved in this trace
> file. I even selected Master to see if it would execute the sp_ExecuteSQL
> calls, but it didn't. It analyzes the originating database just fine. I se
e
> the sp_ExecuteSQL call go through, but it logs it as "not referencing any
> tables".
> I'm hoping for some sort of automated solution because it can be difficult
> to always recreate the exact parameters that make it to this database.
> Bryan
> "John Bell" wrote:
>|||Of course, I have a complete development environment with which I can test
with. I capture a trace from production and then analyze it on our
development environment.
It appears that I will have to manually create some queries that resemble
production that are issued directly against this database before I will be
able to use any sort of automated approach.
Thanks for your assistance.
Bryan
"John Bell" wrote:
[vbcol=seagreen]
> Hi Bryan
> Without knowing exactly what you are doing it is difficult to really
> recommend anything other than the manual approach, any automated tuning
> should be taken as advice that should be reviewed rather than something wh
ich
> is an absolute necessity. I would also recommended that you have a system
> which can be benchmarked and any changes compared so that you can be sure
> that it is a positive change before implementing it on a live environment.
> John
>
> "Bryan Aldrich" wrote:
>
