October 26, 2005 at 1:38 pm
can you check in the execution plan of the prod server for hash joins and tables scan
October 26, 2005 at 6:34 pm
Just went through this moving a database from SQL 7 on an old machine to SQL 2000 on a new machine with much more memory. Queries that were instantaneous on old machine took 10+ seconds on new machine. It's a packaged app, could not rewrite query(s). Comparing the execution plans between 7 & 2000, it was apparent that SQL 2000 didn't have a clue.
Workaround - dropped memory in new server from 4 Gb to 1 Gb, runs like a champ while vendor fixes their stuff. If you are dealing with your own database/queries, you can adjust indexing and possibly rewrite the query to give SQL 2000 a fighting chance at generating a proper execution plan.
October 27, 2005 at 1:52 am
Derek here again. Having read the good input from all so far, I would now tend to take an old fashioned approach. You say select count(*) uses 100% cpu. Well to me SQL is taking all the CPU all the time. So I would look very closely at the server configs and sql configs as discussed. Apart from that, try running different types of extremely simple queries like select * from table (NOLOCK) where x = y. In other words is every SQL query using up 100% CPU for everything. My understanding is that SQL uses tempdb when it is has not enough memory to handle it's requests. I would try and break the problem down by gathering more and more info from various senarios. When no query is running how much cpu have you, how big is tempdb etc etc... I hope this is of help. That's my lot, rgds Derek
October 27, 2005 at 5:38 am
Try to use MAXDOP(1) queryhint. Maybe you're experiencing multiprocessors problems
from BOL:
MAXDOP number
Overrides the max degree of parallelism configuration option (of sp_configure) only for the query specifying this option. All semantic rules used with max degree of parallelism configuration option are applicable when using the MAXDOP query hint. For more information, see max degree of parallelism Option.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
October 27, 2005 at 1:58 pm
MAXDOP doesnt work...
LIST OF INDEXES ON BOTH DATABASES FOR THE BIGGEST TABLE - INVOICE_FACT:
1. Clustered - day_sqn, sales_org_sqn
2. sales_org_sqn
3. inv_nbr, doc_typ_sqn, inv_lin_nbr
4. ord_sqn
5. sold_to_cus_sqn
6. pro_sqn
7. sal_typ_sqn
8. sal_typ
9. trans_typ_sqn
I checked the estimated execution plan on both the databases...
I found a major difference - the one that works uses clustered index
and the one that breaks doesnt use it...
I dont know how to publish the whole execution plan here - its huge.
October 28, 2005 at 1:53 am
can you affort a dbcc dbreindex ?
Indexdefrag does not optimize as well as dbreindex.
Check the execution plan against this query :
select a14.cbl_sqn cbl_sqn,
a17.CG_des CG_des,
a13.pro_typ_sqn pro_typ_sqn,
0 XKYCGT,
sum(a11.inv_qty) WJXBFS1
--into #ZZT090005WKPO000
from dbo.invoice_FACT a11
join dbo.day a12
on a11.day_sqn = a12.day_sqn
and a11.kit_flg in ( 'C','S', 'N')
and a11.sal_typ_sqn = 2
and a11.doc_typ_sqn in (4, 6, 84, 12009, 76, 12019, 90, 103, 104, 105)
and a11.sales_org_sqn = 1
and a12.fis_mth_sqn in (197, 196, 195, 194, 193, 192, 191, 190, 189, 188, 187, 186)
join dbo.product a13
on a11.pro_sqn = a13.pro_sqn and
a11.sales_org_sqn = a13.sales_org_sqn
and a13.pro_typ_sqn in (6, 8)
join dbo.CBL_Title a14
on (a12.fis_yr_sqn = a14.fis_yr_sqn and
a13.tit_sqn = a14.tit_sqn)
join dbo.customer_level_6 a15
on (a11.sales_org_sqn = a15.sales_org_sqn and
a11.sold_to_cus_sqn = a15.cus_sqn)
join dbo.CG_customers_relation a16
on (a15.cus_lev4_sqn = a16.cus_lev4_sqn)
join dbo.CG_keycusFY05 a17
on (a16.CG_sqn = a17.CG_sqn)
--where
group by a14.cbl_sqn,
a17.CG_des,
a13.pro_typ_sqn
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
October 28, 2005 at 9:01 am
DBREINDEX was also run on the table (as DBREINDEX updates statistics and DEFRAG doesnt).
October 28, 2005 at 11:52 pm
RESOLVED:
This is how I resolved it...
No new indexes - no change in anything.
I copied over only the tables involved in the query
to production database - renamed it and ran the query in
production. It works. I dropped the old tables and am using
the new copied over tables now.
Thanks everyone for their time
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply