Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
dziwne zachowanie TQuery
48 views
Skip to first unread message
Maciek Sanocki
Mar 7, 2018, 12:34:58 PM3/7/18
to
Cześć
mam następujący problem:
w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
query zwraca ~1000 rekordow
jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
liste twa ~100sek
kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
trwa ~3sek, a przetworzenie kolejne ~5sek.
Pytanie jak przyspieszyć tego sql?
I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
tego query?
---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus
mam następujący problem:
w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
query zwraca ~1000 rekordow
jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
liste twa ~100sek
kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
trwa ~3sek, a przetworzenie kolejne ~5sek.
Pytanie jak przyspieszyć tego sql?
I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
tego query?
---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus
Roman Tyczka
Mar 7, 2018, 3:01:47 PM3/7/18
to
On Wed, 7 Mar 2018 18:34:58 +0100, Maciek Sanocki wrote:
> mam następujący problem:
> w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
> sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
>
> query zwraca ~1000 rekordow
> jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
> przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
> liste twa ~100sek
> kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
> trwa ~3sek, a przetworzenie kolejne ~5sek.
> Pytanie jak przyspieszyć tego sql?
> I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
> tego query?
Jaka baza, jaka biblioteka dostępowa? Ile jest rekordów w tej tabeli? I czy
> mam następujący problem:
> w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
> sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
>
> query zwraca ~1000 rekordow
> jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
> przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
> liste twa ~100sek
> kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
> trwa ~3sek, a przetworzenie kolejne ~5sek.
> Pytanie jak przyspieszyć tego sql?
> I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
> tego query?
w jakimś narzędziu bazodanowym to zapytanie SQLowe wykonuje się też długo?
--
pozdrawiam
Roman Tyczka
wloochacz
Mar 7, 2018, 3:47:22 PM3/7/18
to
W dniu 2018-03-07 o 21:01, Roman Tyczka pisze:
> jaka biblioteka dostępowa?
> Ile jest rekordów w tej tabeli?
Bez znaczenia.
> I czy w jakimś narzędziu bazodanowym to zapytanie SQLowe wykonuje się też długo?
Na pewno :D
Ty lepiej Maciek pokaż to zapytanie.
A na ślepo, to dodaj na końcu (jeśli to faktycznie MSSQL)
option(recompile)
I to poczytaj:
https://stackoverflow.com/questions/20864934/option-recompile-is-always-faster-why
--
wloochacz
> On Wed, 7 Mar 2018 18:34:58 +0100, Maciek Sanocki wrote:
>
>> mam następujący problem:
>> w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
>> sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
>>
>> query zwraca ~1000 rekordow
>> jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
>> przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
>> liste twa ~100sek
>> kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
>> trwa ~3sek, a przetworzenie kolejne ~5sek.
>> Pytanie jak przyspieszyć tego sql?
>> I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
>> tego query?
>
> Jaka baza,
MSSQL?
>
>> mam następujący problem:
>> w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
>> sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
>>
>> query zwraca ~1000 rekordow
>> jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
>> przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
>> liste twa ~100sek
>> kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
>> trwa ~3sek, a przetworzenie kolejne ~5sek.
>> Pytanie jak przyspieszyć tego sql?
>> I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
>> tego query?
>
> Jaka baza,
> jaka biblioteka dostępowa?
> Ile jest rekordów w tej tabeli?
> I czy w jakimś narzędziu bazodanowym to zapytanie SQLowe wykonuje się też długo?
Ty lepiej Maciek pokaż to zapytanie.
A na ślepo, to dodaj na końcu (jeśli to faktycznie MSSQL)
option(recompile)
I to poczytaj:
https://stackoverflow.com/questions/20864934/option-recompile-is-always-faster-why
--
wloochacz
Roman Tyczka
Mar 7, 2018, 3:54:15 PM3/7/18
to
On Wed, 7 Mar 2018 21:46:40 +0100, wloochacz wrote:
>>> mam następujący problem:
>>> w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
>>> sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
>>>
>>> query zwraca ~1000 rekordow
>>> jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
>>> przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
>>> liste twa ~100sek
>>> kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
>>> trwa ~3sek, a przetworzenie kolejne ~5sek.
>>> Pytanie jak przyspieszyć tego sql?
>>> I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
>>> tego query?
>>
>> Jaka baza,
> MSSQL?
Co prawda napisał "sql serwera", ale to niekoniecznie musi być SQL Server
>>> mam następujący problem:
>>> w Query jest zapytanie w postaci select sum(kol1), sum(kol2 ) ...
>>> sum(kolx), typ from tabelka where data>dat1 and data<data2 group by typ
>>>
>>> query zwraca ~1000 rekordow
>>> jesli czyszcze casche sql serwera wykonanie query trwa ~20sek,
>>> przetworzenie query, czyli zrobienie obiektow z pol i wrzucenie ich na
>>> liste twa ~100sek
>>> kazde następne wykonanie tego query, jak juz plan wykonania jest w cache
>>> trwa ~3sek, a przetworzenie kolejne ~5sek.
>>> Pytanie jak przyspieszyć tego sql?
>>> I ważniejsze, dlaczego jest taka duża różnica w czasie przetwarzania
>>> tego query?
>>
>> Jaka baza,
> MSSQL?
;-)
>> jaka biblioteka dostępowa?
>> Ile jest rekordów w tej tabeli?
> Bez znaczenia.
możesz przybliżyć szczegóły?
--
pozdrawiam
Roman Tyczka
wloochacz
Mar 7, 2018, 4:30:27 PM3/7/18
to
W dniu 2018-03-07 o 21:54, Roman Tyczka pisze:
/ciach/
> Liczba rekordów jest bez znaczenia dla funkcji agregującej? Ciekawa teoria,
> możesz przybliżyć szczegóły?
Przeczytaj posta...
Wg Ciebie liczba rekordów zmiana się przy każdym odpaleniu tego samego
zapytania na tej samej bazie danych po czyszczeniu cache?
Ciekawa teoria, możesz przybliżyć szczegóły?
--
wloochacz
/ciach/
> Liczba rekordów jest bez znaczenia dla funkcji agregującej? Ciekawa teoria,
> możesz przybliżyć szczegóły?
Wg Ciebie liczba rekordów zmiana się przy każdym odpaleniu tego samego
zapytania na tej samej bazie danych po czyszczeniu cache?
Ciekawa teoria, możesz przybliżyć szczegóły?
--
Maciek Sanocki
Mar 7, 2018, 4:58:14 PM3/7/18
to
W dniu 2018-03-07 o 22:30, wloochacz pisze:
z jakiegos powodu nie widzę posta od Roman Tyczka, ale doprecyzuję
liczba rekordow jest oczywiscie stala za kazdym razem,
nie wiem tylko dlaczego po oczyszczeniu caschu
przejscie przez query za pomoca while not query.eof ...
twa wielokrotnosc tego tego co bez czyszczenia caschu.
To ze po oczyszczeniu caschu query wykonuje się dluzej to oczywistosc
wynikajaca z tego ze nie ma wtedy planu wykonania, za kazdym nastepnym
ten plan juz jest.
liczba rekordow jest oczywiscie stala za kazdym razem,
nie wiem tylko dlaczego po oczyszczeniu caschu
przejscie przez query za pomoca while not query.eof ...
twa wielokrotnosc tego tego co bez czyszczenia caschu.
To ze po oczyszczeniu caschu query wykonuje się dluzej to oczywistosc
wynikajaca z tego ze nie ma wtedy planu wykonania, za kazdym nastepnym
ten plan juz jest.
wloochacz
Mar 7, 2018, 7:42:16 PM3/7/18
to
W dniu 2018-03-07 o 22:58, Maciek Sanocki pisze:
/ciach/
> liczba rekordow jest oczywiscie stala za kazdym razem,
> nie wiem tylko dlaczego po oczyszczeniu caschu
> przejscie przez query za pomoca while not query.eof ...
> twa wielokrotnosc tego tego co bez czyszczenia caschu.
> To ze po oczyszczeniu caschu query wykonuje się dluzej to oczywistosc
> wynikajaca z tego ze nie ma wtedy planu wykonania, za kazdym nastepnym
> ten plan juz jest.
No to teraz podaj szczegóły, o które pytał Roman;
Jaka baza danych?
Jak się z nią łączysz?
Jakie komponenty?
Dane ściągasz paczkami z serwera czy wszystko od razu (FetchAll)?
Pokaż zapytanie i może nawet to otwieranie i iterację.
Po co czyścisz cache, przecież po coś on jest prawda?
--
wloochacz
/ciach/
> liczba rekordow jest oczywiscie stala za kazdym razem,
> nie wiem tylko dlaczego po oczyszczeniu caschu
> przejscie przez query za pomoca while not query.eof ...
> twa wielokrotnosc tego tego co bez czyszczenia caschu.
> To ze po oczyszczeniu caschu query wykonuje się dluzej to oczywistosc
> wynikajaca z tego ze nie ma wtedy planu wykonania, za kazdym nastepnym
> ten plan juz jest.
Jaka baza danych?
Jak się z nią łączysz?
Jakie komponenty?
Dane ściągasz paczkami z serwera czy wszystko od razu (FetchAll)?
Pokaż zapytanie i może nawet to otwieranie i iterację.
Po co czyścisz cache, przecież po coś on jest prawda?
--
wloochacz
Mak
Mar 8, 2018, 1:27:24 AM3/8/18
to
W dniu 08.03.2018 o 01:42, wloochacz pisze:
baza SQLSerwer 2008
do laczenia uzywam blibow ( wlasne firmowe komponenty ) ale jak
probowalem zwyklego TQuery bylo to samo
liczba rekordow w tabelce 2200 ale na rzeczywistej bazie klienta moga
byc miliony
czasy wykonania w narzedziach bazodanowych sa wlasciwie takie same jak w
programie,
kawalek kodu:
tq:=TBQuery.create(nil);
try
tq.databasename:='PETER';
tq.sql.add('SELECT SUM(BETRAG) AS UMNETTO,
SUM(BETRAG+NACHLASSSUMME) AS UMBRUTTO, SUM(STATISTIKMENGE) AS SMENGE,');
tq.sql.add('SUM(DECKUNGSBEITRAG) AS DB, TYP, DATUM, NRBELEGTYP
FROM AVK120 WHERE ');
tq.sql.add('DATUM>=:DAT_FROM AND DATUM<:DAT_TO AND NRBELEGTYP
IN (20,21,31,40,41,241) ');
tq.sql.add('GROUP BY TYP, NRBELEGTYP, DATUM ');
tq.parambyname('DAT_FROM').asdatetime:=dfrom;
tq.parambyname('DAT_TO').asdatetime:=dto;
tq.open;
tq.FetchAll;
tq.First;
while not tq.eof do
begin
details:=TDataDetails.create(tq.FieldByName('DATUM').asdatetime,tq.fieldbyname('NRBELEGTYP').asinteger,tq.FieldByName('TYP').AsInteger,
tq.fieldbyname('UMNETTO').asfloat,tq.FieldByName('UMBRUTTO').asfloat,
tq.fieldbyname('SMENGE').asfloat,tq.FieldByName('DB').asfloat);
tmplist.Add(details);
tq.Next;
end;
finally
tq.free;
end;
cache czyszcze wylacznie dla testow
generalnie sytuacja jest taka, ze rano klent pierwszy raz odpala program
i wczytanie i pokazanie danych zajmuje 2min, kazde nastepne odpalenie to
ok 10sek, 95% czasu przypada na powyzszy kawalek kodu, z czego wiekszosc
nie na same zapytanie a na petle z tworzeniem obiektow
do laczenia uzywam blibow ( wlasne firmowe komponenty ) ale jak
probowalem zwyklego TQuery bylo to samo
liczba rekordow w tabelce 2200 ale na rzeczywistej bazie klienta moga
byc miliony
czasy wykonania w narzedziach bazodanowych sa wlasciwie takie same jak w
programie,
kawalek kodu:
tq:=TBQuery.create(nil);
try
tq.databasename:='PETER';
tq.sql.add('SELECT SUM(BETRAG) AS UMNETTO,
SUM(BETRAG+NACHLASSSUMME) AS UMBRUTTO, SUM(STATISTIKMENGE) AS SMENGE,');
tq.sql.add('SUM(DECKUNGSBEITRAG) AS DB, TYP, DATUM, NRBELEGTYP
FROM AVK120 WHERE ');
tq.sql.add('DATUM>=:DAT_FROM AND DATUM<:DAT_TO AND NRBELEGTYP
IN (20,21,31,40,41,241) ');
tq.sql.add('GROUP BY TYP, NRBELEGTYP, DATUM ');
tq.parambyname('DAT_FROM').asdatetime:=dfrom;
tq.parambyname('DAT_TO').asdatetime:=dto;
tq.open;
tq.FetchAll;
tq.First;
while not tq.eof do
begin
details:=TDataDetails.create(tq.FieldByName('DATUM').asdatetime,tq.fieldbyname('NRBELEGTYP').asinteger,tq.FieldByName('TYP').AsInteger,
tq.fieldbyname('UMNETTO').asfloat,tq.FieldByName('UMBRUTTO').asfloat,
tq.fieldbyname('SMENGE').asfloat,tq.FieldByName('DB').asfloat);
tmplist.Add(details);
tq.Next;
end;
finally
tq.free;
end;
cache czyszcze wylacznie dla testow
generalnie sytuacja jest taka, ze rano klent pierwszy raz odpala program
i wczytanie i pokazanie danych zajmuje 2min, kazde nastepne odpalenie to
ok 10sek, 95% czasu przypada na powyzszy kawalek kodu, z czego wiekszosc
nie na same zapytanie a na petle z tworzeniem obiektow
Mak
Mar 8, 2018, 2:10:02 AM3/8/18
to
> A na ślepo, to dodaj na końcu (jeśli to faktycznie MSSQL)
> option(recompile)
>
> I to poczytaj:
> https://stackoverflow.com/questions/20864934/option-recompile-is-always-faster-why
>
>
wloochacz
Mar 8, 2018, 7:09:47 AM3/8/18
to
W dniu 2018-03-08 o 07:58, Mak pisze:
Na zdrowie.
Tylko bardzo Cię proszę, zrozum jak to działa i nie dodawaj na pałę
wszędzie jak popadnie ;-)
--
wloochacz
Tylko bardzo Cię proszę, zrozum jak to działa i nie dodawaj na pałę
wszędzie jak popadnie ;-)
--
wloochacz
Mak
Mar 8, 2018, 7:17:04 AM3/8/18
to
W dniu 08.03.2018 o 13:09, wloochacz pisze:
doksztalce sie :-)
co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie ta
pilna ), bo program w zaleznosci od klienta dziala na roznych wersjach
ms sql, oracla i informixa
co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie ta
pilna ), bo program w zaleznosci od klienta dziala na roznych wersjach
ms sql, oracla i informixa
wloochacz
Mar 8, 2018, 9:08:08 AM3/8/18
to
W dniu 2018-03-08 o 13:17, Mak pisze:
/ciach/
> doksztalce sie :-)
> co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie ta
> pilna ), bo program w zaleznosci od klienta dziala na roznych wersjach
> ms sql, oracla i informixa
Nie widzę związku, ponieważ Twój problem to problem ściśle powiązany z
konkretną daną bazą danych.
PS.
Działa na różnych bazach i jest tak napisany?
Głębokie wyrazy współczucia...
I jak sobie poradzisz z tym option(recompile), bo to dyrektywa ważna
tylko dla MSSQL?
--
wloochacz
/ciach/
> doksztalce sie :-)
> co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie ta
> pilna ), bo program w zaleznosci od klienta dziala na roznych wersjach
> ms sql, oracla i informixa
konkretną daną bazą danych.
PS.
Działa na różnych bazach i jest tak napisany?
Głębokie wyrazy współczucia...
I jak sobie poradzisz z tym option(recompile), bo to dyrektywa ważna
tylko dla MSSQL?
--
wloochacz
Maciek Sanocki
Mar 8, 2018, 12:41:14 PM3/8/18
to
> W dniu 2018-03-08 o 13:17, Mak pisze:
> /ciach/
>
>> doksztalce sie :-)
>> co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie ta
>> pilna ), bo program w zaleznosci od klienta dziala na roznych wersjach
>> ms sql, oracla i informixa
> Nie widzę związku, ponieważ Twój problem to problem ściśle powiązany z
> konkretną daną bazą danych.
bazie danych ( w sensie zawartosci tabelek czoywiscie )
>
> PS.
> Działa na różnych bazach i jest tak napisany?
> Głębokie wyrazy współczucia...
>
> I jak sobie poradzisz z tym option(recompile), bo to dyrektywa ważna
> tylko dla MSSQL?
sql, jak rozwiazac to z oraclem? nie wiem jeszcze, ale na to akurat mam czas
wloochacz
Mar 9, 2018, 4:16:38 AM3/9/18
to
W dniu 2018-03-08 o 18:41, Maciek Sanocki pisze:
Ja się na Oracle nie znam i nie będę się wypowiadał.
>> PS.
>> Działa na różnych bazach i jest tak napisany?
>> Głębokie wyrazy współczucia...
> ale o co Tobie tu chodzi?
Uuuu... nie dogadamy się.
Takie klepanie jest przede wszystkim MEGA upierdliwe w utrzymaniu oraz...
A szkoda gadać.
Ale rozumiem Cię - o co mi chodzi, przecież działa.
>> I jak sobie poradzisz z tym option(recompile), bo to dyrektywa ważna
>> tylko dla MSSQL?
> rozpoznaje do jakiej bazy jestem podlaczony i odpowiednio modyfikuje
> sql,
Ale jak, tak aby coś na kształt może?
case dbConnKind of
dbOra = 'SQL for Oracle'
dbMSSQL = 'SQL for MSSQL'
dbInfX = 'SQL for Informix'
end;
I jeśli to coś podobne, to naprawdę nikt się nie zastanawiał nad tym jak
zrobić to lepiej/inaczej?
Tylko mi nie pisz w stylu "o co ci chodzi? przecież 80% SQL jest
identyczne, a więc w czym problem".
jak rozwiazac to z oraclem? nie wiem jeszcze, ale na to akurat mam
> czas
Pisałem jak wyżej...
--
wloochacz
>
>> W dniu 2018-03-08 o 13:17, Mak pisze:
>> /ciach/
>>
>>> doksztalce sie :-)
>>> co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie
>>> ta pilna ), bo program w zaleznosci od klienta dziala na roznych
>>> wersjach ms sql, oracla i informixa
>> Nie widzę związku, ponieważ Twój problem to problem ściśle powiązany z
>> konkretną daną bazą danych.
> nie, taki sam efekt jest jak sie podlacze do oracla na takiej samej
> bazie danych ( w sensie zawartosci tabelek czoywiscie )
Hmmm... może i tak.
>> W dniu 2018-03-08 o 13:17, Mak pisze:
>> /ciach/
>>
>>> doksztalce sie :-)
>>> co prawda to rozwiazuje tylko polowe mojego problemu ( na szczescie
>>> ta pilna ), bo program w zaleznosci od klienta dziala na roznych
>>> wersjach ms sql, oracla i informixa
>> Nie widzę związku, ponieważ Twój problem to problem ściśle powiązany z
>> konkretną daną bazą danych.
> nie, taki sam efekt jest jak sie podlacze do oracla na takiej samej
> bazie danych ( w sensie zawartosci tabelek czoywiscie )
Ja się na Oracle nie znam i nie będę się wypowiadał.
>> PS.
>> Działa na różnych bazach i jest tak napisany?
>> Głębokie wyrazy współczucia...
> ale o co Tobie tu chodzi?
Takie klepanie jest przede wszystkim MEGA upierdliwe w utrzymaniu oraz...
A szkoda gadać.
Ale rozumiem Cię - o co mi chodzi, przecież działa.
>> I jak sobie poradzisz z tym option(recompile), bo to dyrektywa ważna
>> tylko dla MSSQL?
> rozpoznaje do jakiej bazy jestem podlaczony i odpowiednio modyfikuje
> sql,
case dbConnKind of
dbOra = 'SQL for Oracle'
dbMSSQL = 'SQL for MSSQL'
dbInfX = 'SQL for Informix'
end;
I jeśli to coś podobne, to naprawdę nikt się nie zastanawiał nad tym jak
zrobić to lepiej/inaczej?
Tylko mi nie pisz w stylu "o co ci chodzi? przecież 80% SQL jest
identyczne, a więc w czym problem".
jak rozwiazac to z oraclem? nie wiem jeszcze, ale na to akurat mam
> czas
--
wloochacz
0 new messages