Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: the_foe w Styczeń 22, 2021, 20:07:47
-
Czy ktoś ma doświadczenie w uzytkowaniu GT z duża ilością dokumentów? Mam ok. 100 tysięcy faktur i widok całości konsumuje ok 15 sekund.Na ogól jadę na filtrze z ostatniego miesiąca, wtedy działa gładko (ok. 5-10 tysiecy faktur), ale dość często potrzebuje faktury sprzed roku i wtedy muli. Czy to norma, wydaje mi się ze 100 tysięcy to powinno być na luzie. Pytam czy warto kogoś wzywać, czy ten typ tak ma?
-
Zważając na ilość danych można napisać tyko: "to zależy..."
-
Czy ktoś ma doświadczenie w uzytkowaniu GT z duża ilością dokumentów?
Oczywiście, jest wielu użytkowników GT/Navireo, którzy gromadzą duże liczby dokumentów, większe niż opisywane przez Ciebie.
Mam ok. 100 tysięcy faktur...
To nie jest jeszcze duża ilość.
...i widok całości konsumuje ok 15 sekund.Na ogól jadę na filtrze z ostatniego miesiąca, wtedy działa gładko (ok. 5-10 tysiecy faktur), ale dość często potrzebuje faktury sprzed roku i wtedy muli. Czy to norma, wydaje mi się ze 100 tysięcy to powinno być na luzie.
Dla porównania wyświetlenie 100 tys. FS:
- baza 930 tys. FS na 3,25 mln dokumentów - 4s
- baza 830 tys. FS na 2,8 mln dokumentów (kilkuletni sprzęt) - 4s
Praktycznie nic nie optymalizowane w tym obszarze, gdyż nikt nie zgłaszał problemów.
Pytam czy warto kogoś wzywać, czy ten typ tak ma?
To zależy, jeśli Ci to przeszkadza i znajdziesz kogoś kto nie będzie chciał tylko zmieniać sprzętu na nowszy to dlaczego nie.
-
Dzięki za info.
4 sek to też podejrzanie dużo, ale patrząc na strukturę bazy to chyba zamulanie jest nie do przeskoczenia.
Ktoś kompaktował bazę, czy to w ogole ma sens, bo chyba przecież mechanizm powinien to robić na bieżąco ? Może sie coś posypać przez takie ręczny "maintaning" ?
-
Dzięki za info.
4 sek to też podejrzanie dużo
To jak nazwiesz swój wynik - 10x mniej danych i 3x wolniej ?
ale patrząc na strukturę bazy to chyba zamulanie jest nie do przeskoczenia.
Jakie struktury są niby tak problematyczne, co to jest "zamulanie", czego konkretnie nie da się przeskoczyć ?
Ktoś kompaktował bazę, czy to w ogole ma sens, bo chyba przecież mechanizm powinien to robić na bieżąco ?
Z jednej strony potrafisz określić wydajność programu na podstawie samej struktury bazy danych, a jednocześnie nie wiesz czym jest kompaktowanie bazy danych ? :o Mam sens tylko w jednym przypadku - usunięcia z bazy danych dużych ilości danych... Oczywistym powinno być też to, że serwery SQL nie wykonują na bieżąco operacji, które mogą obniżyć ich wydajność typu właśnie kompaktowanie, sprawdzanie fizycznej spójności, czy odbudowa indeksów. W prawdzie kompaktowanie można włączyć w Microsofcie, ale domyślnie jest wyłączone.
Może sie coś posypać przez takie ręczny "maintaning" ?
Jest to przecież operacja dostępna dla każdego użytkownika w programie serwisowym, więc nie, nic się nie posypie.
-
Ktoś kompaktował bazę, czy to w ogole ma sens, bo chyba przecież mechanizm powinien to robić na bieżąco ? Może sie coś posypać przez takie ręczny "maintaning" ?
Kompaktowanie nie przyśpiesza, może co najwyżej spowolnić..
Nie, żaden mechanizm nie powinien tego robić na bieżąco. NB co to w ogóle miałoby znaczyć "kompaktowanie na bieżąco"?
Nie na sprawnej bazie nic się nie posypie.
-
Zamiast kompaktowania zrób lepiej odbudowę indeksów.
Wysłane z mojego CLT-L29 przy użyciu Tapatalka
-
Pierwszy krok to audyt SQL i jego konfiguracji. Tu można wiele zrobić prawidłowo zarządzając zasobami, kwestia sprawdzenia indeksów i ich selektywności, lokalizacji pliku tempdb i wiele innych.