August 5, 2008 at 12:26 am
maruf24 (8/4/2008)
i hav used exists but there is no use same result......... shud i do 1 thing to check the appication.... some one might changed the coding as it run through java....
Heh... I'm thinking you've just identified the source of the performance problem... 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 5, 2008 at 11:46 am
Hey Again,
I'm out of the office today, but I'll try to post my code tomorrow.
Cheers,
-Matthew
August 5, 2008 at 9:31 pm
Wat i hav found tht there is some change in java code as i m a dba ...
..... i dnt no wat are the changes has been made but wat i think due to this.... the query is taking time performance issue ..... bcoz i hav done each and every thing from the database side still no progress ... and now i hav to send a mail to my manager .... abut this slowness as he is askin for the reason.
August 6, 2008 at 3:09 am
Hi
If the table gets updated a lot the index might get fragmented. I had a similar problem once which got resolved when ran update statistics on the table. Try to update the statistics or even rebuild the indexes.
Also the Database Tuning Advisor can come in quite handy as it can suggest new indexes.
August 6, 2008 at 7:40 am
maruf24 (8/5/2008)
Wat i hav found tht there is some change in java code as i m a dba ........ i dnt no wat are the changes has been made but wat i think due to this.... the query is taking time performance issue ..... bcoz i hav done each and every thing from the database side still no progress ... and now i hav to send a mail to my manager .... abut this slowness as he is askin for the reason.
This problem has been ongoing for at LEAST 6 days now. Had you simply hired a professional tuner to remote in and check things out the problem would likely have been identified (and if a database/server problem solved) in a matter of hours. You would gain the benefit of learning what and how from the pro as well. Please tell your manager that for me.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
August 6, 2008 at 8:51 pm
This issue has been resolved as there was a change in java code .... the code has been revert back .... not required a professional we hav to belive in our self ....
Thkz for each n every 1.. who has commented on this...
Special Thkz to.....
GilaMonster
WiltsDBA
TheSQLGuru
Jeff Moden
August 6, 2008 at 11:49 pm
Thank you for the feedback... glad you solved it. 🙂
--Jeff Moden
Change is inevitable... Change for the better is not.
August 7, 2008 at 1:15 am
Can you post the actual Query, instead of trying to mask the table and column names? It just makes things worse. Here's an attempt at fixing it, but since it's missing a paren somewhere, I don't know if I'm on the right track.
SELECTt3.id
,t3.aaa
,t3.colname
,t1.id
,t1.ttt
,t1.c_f_name
,t2.cmd
FROM table3 t3
INNER JOIN table1 t1
ON t3.colname=t1.colname
INNER JOIN table2 t2
ON t1.colname = t2.colname
AND t3.colname = t2.colname
AND t2.colname = '365464'
WHERE t1.id = '354'
AND t1.colname='A'
AND t3.colname =123
The LIKE clause, in this case, isn't providing any real difference than an equi-join would end up giving you. So, why not just put it in the JOIN clause? As for the rest of it...it's hard to tell, because there aren't any aliases on the two colname columns at the end of the query...and as we all know, 'A' does not equal 123, so, that would never return a record. So, I deduced that they were from different tables...and not from table 2, because that was already being checked with the LIKE condition.
Again, sending the real query would've probably helped....and none of what I've done will likely help. We need more info, like a query plan and the actual query, and maybe some DDL...and number of records in each table...and blah, blah, blah... 🙂
August 16, 2008 at 12:07 pm
Your query would return ambiguous column "colname", also like '365464' is the same as = '365464'.
Try the WITH (NOLOCK) hint. If more than one user at a time is querying these tables SQL Server will put locks on the tables while it internally creates temp tables to speed execution. So some are waiting for others queries to finish and the tables to unlock. It is often faster to create a temp table yourself to replace the sub-select (use select distinct to avoid duplication in the result set) with an inner join on the temp table:
select distinct colname
into #tmp
from table2
where colname = '365464'
August 16, 2008 at 3:35 pm
Joe Torre (8/16/2008)
It is often faster to create a temp table yourself to replace the sub-select
Being a bit of a skeptic, let's see the test you did that proves that. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
August 16, 2008 at 3:55 pm
Joe Torre (8/16/2008)
If more than one user at a time is querying these tables SQL Server will put locks on the tables while it internally creates temp tables to speed execution. So some are waiting for others queries to finish and the tables to unlock.
Not exactly.
SQL does indeed put locks on data that is being selected (but it's not necessarily at a table level unless a lot of the table is affected by the query). If the query is just a select, then shared locks are placed and shared locks are compatible with other shared locks. They'll only block exclusive or update locks which are taken when the data is modified.
Not all queries require the query processor to create work tables. Generally it's queries that include sorts/distinct sorts and/or hashes (joins or aggregates). Easiest way to tell, run the query with STATISTICS IO on and see if there's a reference to a table named WorkTable. Straight selects are unlikely to require any form of internal temp table.
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 11 posts - 31 through 40 (of 40 total)
You must be logged in to reply to this topic. Login to reply