🚀 go-pugleaf

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
w jakimś narzędziu bazodanowym to zapytanie SQLowe wykonuje się też długo?

--
pozdrawiam
Roman Tyczka

W dniu 2018-03-07 o 21:01, Roman Tyczka pisze:
> 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?

> 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 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
;-)

>> jaka biblioteka dostępowa?
>> Ile jest rekordów w tej tabeli?
> Bez znaczenia.

Liczba rekordów jest bez znaczenia dla funkcji agregującej? Ciekawa teoria,
możesz przybliżyć szczegóły?

--
pozdrawiam
Roman Tyczka

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

W dniu 2018-03-07 o 22:30, wloochacz pisze:
> 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?
>
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.

---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

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

W dniu 08.03.2018 o 01:42, wloochacz pisze:
> 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?
>
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:ßrom;
     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

> 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
>
>
dodalem, pomoglo, wielkie dzięki

W dniu 2018-03-08 o 07:58, Mak pisze:
>
>
>> 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
>>
>>
> dodalem, pomoglo, wielkie dzięki
Na zdrowie.
Tylko bardzo Cię proszę, zrozum jak to działa i nie dodawaj na pałę
wszędzie jak popadnie ;-)

--
wloochacz

W dniu 08.03.2018 o 13:09, wloochacz pisze:
> W dniu 2018-03-08 o 07:58, Mak pisze:
>>
>>
>>> 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
>>>
>>>
>> dodalem, pomoglo, wielkie dzięki
> Na zdrowie.
> Tylko bardzo Cię proszę, zrozum jak to działa i nie dodawaj na pałę
> wszędzie jak popadnie ;-)
>
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

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

> 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 )


>
> PS.
> Działa na różnych bazach i jest tak napisany?
> Głębokie wyrazy współczucia...
ale o co Tobie tu chodzi?

>
> 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, jak rozwiazac to z oraclem? nie wiem jeszcze, ale na to akurat mam czas

>


---
Ta wiadomość została sprawdzona na obecność wirusów przez oprogramowanie antywirusowe Avast.
https://www.avast.com/antivirus

W dniu 2018-03-08 o 18:41, Maciek Sanocki pisze:
>
>> 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.
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