[SQL] Postęp wykonywania

0

Czołem
Chciałbym zapytań czy istnieje sposób na sprawdzenie jaki jest postęp ( procent ) wykonania kwerendy która uzupełnia tabelę.
zęby oszacować ile czasu zostało do końca
Bo czekam już z godzinę i nie wiem czy mam to 'Kill'ować czy może za 5 minut się zrobi .

[MS SQL]

0

Jeżeli wykonuje się ponad minutę, o zabić dopóki jaja nie złożyło i dostroić zapytanie.
Niektórzy uważają że ma być poniżej 300 ms, ale bez przesady, jak puścisz ładną muzyczkę to użyszkodnik jakoś przecieka minutę.

1

Czyli rozumiem, że to są jakieś upadaty? Zobacz czy nie masz jakiś loków na bazie i ci czasem całość nie wisi. Jak masz dużo rekordów do zupdatowania, to najlepiej robić to w paczkach wówczas widać ile poszło a ile jeszcze jest do zrobiebnia.

0

Niestety operacje DML bardzo często działają bardzo nieefektywnie. W związku z tym podstawowym sposobem jest puszczanie operacji podzielonej na mniejsze części. Dalsza optymalizacja jest możliwa, ale zależy już bardziej od konkretnego silnika. Przykładowo w niektórych bazach zamiast INSERT można korzystać z polecenia IMPORT czy COPY w różnych bazach różnie się to może nazywać. Oprócz tego można korzystać z jakiś narzędzi ETL z których niektóre są optymalizowane do szybkich operacji DML.

0

Odpowiadając na Twoje pytanie - NIE.

Niestety żadna baza (a co za tym idzie aplikacja do połączenia z bazą, której używasz) nie jest w stanie podać Ci wcześniej (zanim tego nie wykona) czasu wykonania. W przypadku insertów można spróbować obchodzić temat na kilka sposobów w zależności od dystrybucji bazy. Można spróbować z COPY jak podał przedmówca, w oracle można spróbować z external table itp. ale czas wykonania uzależniony jest od wielu czynników.
W wielu systemach logika oparta jest o wyzwalacze (triggery) i np dla rekordu A insert pójdzie w ułamku sekundy, a dla rekordu B z innymi danymi uruchomi bloki kodu na wyzwalaczu, który będzie zajmował więcej czasu. Ponadto zdarza się, że duże obciążenie bazy może również wpłynąć na czas wykonania operacji. Do tego na bazie testowej na środowisku testowym czas może się różnić od bazy produkcyjnej ze względu np na zasoby sieciowe lub sprzętowe ... długo by to tym gadać.

Najprościej rzecz ujmując jeśli chcesz mieć "w miarę" rzeczywisty postęp to albo napiszesz swoją aplikację gdzie ilość linii w pliku (= ilości insertów) będzie stanowić twoje 100% i po każdej iteracji pętli robisz wyświetlanie postępu lub przenosisz inserty do T-SQL i robisz to samo tyle, że dodajesz np Print (@VariableName).

Możliwości jest sporo ale sama baza z siebie takich informacji nie udziela.

0

@woolfik zajrzałes do linku który podałem? Taką informację z SQL Servera można uzyskać...

0

@Panczo: tak widziałem ale tam jest takie magiczne zdanie:
The query progress information and execution statistics are periodically updated while query execution is in progress

Co oznacza, że ten czas jest oparty o pewne statystyki. Tworząc zapytanie przekazujesz do bazy zestaw instrukcji, tam interpreter musi to zinterpretować i dobrać odpowiedni plan zapytania czyli co skąd oczytać - wiem, że to wiesz ale może pytacz nie wie. Dopiero w kolejnym kroku baza kieruje się do wskazanych miejsc i pobiera dane. Nie ma tu nigdzie ani czasu przesyłu danych po sieci - pomijamy jeśli baza stoi lokalnie - ani ile danych (ich rozmiar) faktycznie twoje zapytanie zwróci. Te informacje są dopiero po faktycznym zebraniu całego zakresu danych. Zatem takie "live" będzie dopiero przy fizycznym odczycie danych.

Wg mnie działa to tak: Najpierw baza sprawdza co z których obszarów pamięci ma pobrać, ile rekordów, ich adresy i to przekażą do statystyk, następnie pobierają dane poprzez np fizyczny odczyt dysku i aktualizują na tej podstawie statystyki zwracane w tym LQS.

Prosty przykład. Masz tabelę z polem typu BLOB. Pobierasz 10 rekordów. Statystyka ci pokazuje 1,2,3,4..... i przez następne 5 min nic. Bo się okazało, że pierwsze 4 rekordy mają małego BLOB'a, a rekord nr 5 ma załadowanych 10GB plik....

Jeśli się mylę, to mnie popraw.

1

Nie wiem czy rozumiemy tak samo przytoczone przez ciebie zdanie, bo ono opisuje mechanizm w jaki SSMS aktualizuje statystyki pokazywane użytkownikowi.

Jakbyś podejrzał profilerem co robi pod spodem:

  1. Puszczane jest zapytanie
  2. SMS pobiera plan wykonania
  3. Cyklicznie pyta bazę o widok sys.dm_exec_query_profiles i na tej podstawie oblicza procent wykonania (w uproszczeniu wylicza procent na podstawie aktualnie przetwarzanego rekordu i oczekiwanej liczby rekordów)

Jak to zrobić bez ssms masz tu: https://docs.microsoft.com/en-us/sql/relational-databases/system-dynamic-management-views/sys-dm-exec-query-profiles-transact-sql?view=sql-server-2017

Nie wiem jak to jest dokładne, ale testując dla własnych potrzeb (i dla zabawy, nigdy nie używałem produkcyjnie) dość dokladnie sie to sprawdza.

Prosty przykład. Masz tabelę z polem typu BLOB. Pobierasz 10 rekordów. Statystyka ci pokazuje 1,2,3,4..... i przez następne 5 min nic. Bo się okazało, że pierwsze 4 rekordy mają małego BLOB'a, a rekord nr 5 ma załadowanych 10GB plik....

To jest oczywiste, my mówimy o tym ile serwer już zrobił i nigdy na tej podstawie nie estymował czasu ukonczenia, w opisywanym przypadku progres zatrzymałby się na 4% i czekał na przemielenie tych 10 GB...

OP pyta o to jak sprawdzić ile się wykonało, żeby sobie estymować czas ukończenia...

1 użytkowników online, w tym zalogowanych: 0, gości: 1