[ VladoMNE @ 01.04.2009. 09:04 ] @
Pozdrav,

imam dvije baze prva (produkcija) a druga (restore od produkcije). Razlika izmedju ove dvije baze su veoma male, u tabelama koja pretrazuje store procedura mozda u 1-5 redova.

Kad izvrsavam istu proceduru na test bazi izvrsi je za 23 sekunde (vrati 15 redova) a kad to isto uradim na produkciji treba 3minuta i 46 sekundi (vrati 16 redova). Izvrsavao sam proceduru i u vecernjim satima kad procedukcija nije opterecenja ali opet sporo izvrsava (mala razlika u odnosu kad je opterecena).


Uporedjivao sam u profileru sve isto radi samo sto duration kod produkcije mnogo veci. Ne znam do cega moze biti ? Ima li ko ideju ?





[ mmix @ 01.04.2009. 12:51 ] @
Za pocetak uporedi actual execution planove da vidis da li je query optimizer odradio identican posao (minimum dal skenira iste objekte i bar u pribliznom obimu). Mozes i da ih okacis ovde (.sqlplan). Query optimizer na dve razlicite baze (cak iako je jedna restore druge) moze drugacije da odradi posao u zavisnosti od trentunih statistika.

btw, to sto radi sporije van daytime opterecenja ne mora da znaci mnogo, dovoljan ti je jedan ocajno uradjen pozadinski proces koji drzi pesimisticke lockove da ti zagorcava zivot.

ako ti nije frka daj i query, mozda nesto moze da ti se optimizuje, mozda imas mnogo OR ili kompozitnih operacija ili drugih zezalice koje forsiraju full table scanove (za to bi vec morao da nam okacis actual execution plan sa prod-a)
[ VladoMNE @ 02.04.2009. 13:44 ] @
Citat:

Za pocetak uporedi actual execution planove da vidis da li je query optimizer odradio identican posao (minimum dal skenira iste objekte i bar u pribliznom obimu). Mozes i da ih okacis ovde (.sqlplan). Query optimizer na dve razlicite baze (cak iako je jedna restore druge) moze drugacije da odradi posao u zavisnosti od trentunih statistika.


Mozes li malo vise da mi kazes o ovome posto nisam bas potpuno upoznat.

Sto se tice procedure ne smijem da je mijenjam jer to rade na vecem nivou.
[ mmix @ 02.04.2009. 14:46 ] @
Citat:
CrAzYBoY_LuD: Mozes li malo vise da mi kazes o ovome posto nisam bas potpuno upoznat.
Sto se tice procedure ne smijem da je mijenjam jer to rade na vecem nivou.


http://www.elitesecurity.org/t...Actual-Execution-Plan-uputstvo

Medjutim, ako ti nemas nikakvu kontrolu nad bazom onda je to malo problematicno. Sta god da bude resenje tvog problema nesto ces morati da dodas/izbacis/promenis na bazi ili aplikativnom nivou, makar to bio novi indeks. Ako je sve to van tvojih ruku onda je dzaba, eventualno mozes da se naoruzas za razgovor sa onima koji mogu da menjaju...
[ Radudzoni @ 06.04.2009. 12:32 ] @
[quote] Ima li ko ideju ?
[/google]
Imam ja.. Mozda :-)

Imao sam slicne probleme da se neki upiti "uspore" sa nekih par sekundi na vise minuta, a pritom se kolicina podataka promeni jako malo ili nimalo
i nasli smo problem sa indexima... doduse oni su bili takvi i ranije ali je potrebno da se uradi "reindeksiranje" baze (mi ga zovemo tako, pa kako god da je pravilno)
Elem evo koda za Storku
Code:
CREATE PROCEDURE [dbo].[spREINDEX] AS

DECLARE @TableName varchar(255) 

DECLARE TableCursor CURSOR FOR 
SELECT table_name FROM information_schema.tables 
WHERE table_type = 'base table' 

OPEN TableCursor 

FETCH NEXT FROM TableCursor INTO @TableName 
WHILE @@FETCH_STATUS = 0 
BEGIN 
--PRINT "Reindexing " + @TableName 
DBCC DBREINDEX(@TableName,' ',90) 
FETCH NEXT FROM TableCursor INTO @TableName 
END 

CLOSE TableCursor 

DEALLOCATE TableCursor


Nisam verovao da ce ovo da pomogne, ali pomoglo je... :-)
[ VladoMNE @ 10.04.2009. 11:18 ] @
Nama se jednom nedeljno reindexiraju tabele... ne znam sto bi moglo bit...