Cześć, mam pytanie gdyż muszę zaktualizować kolumne na bazie gdzie jest 9 milionów wierszy. Zakładam, że zwykły update zablokuje bazę.
Stąd mam pytanie, bo plan jest by zrobić jakiś sprytny WHILE i update puszczać po np. 5k wierszy. Natomiast chciałbym to wszystko zawrzeć w transakcję - czy wtedy ma to sens? Czy jeżeli zrobię transakcję, a w niej ten cały WHILE który będzie robił update po 5k wierszy to będzie to jakieś upsrawienie? Czy ostatecznie i tak wszystkie updaty pójdą na commicie transakcji więc żaden uzysk?
- Rejestracja:około 6 lat
- Ostatnio:17 dni
- Postów:46

- Rejestracja:ponad 2 lata
- Ostatnio:około 12 godzin
- Postów:1583
CSharpBeginner napisał(a):
Stąd mam pytanie, bo plan jest by zrobić jakiś sprytny WHILE i update puszczać po np. 5k wierszy.
Dobry pomysł ale w tym kontekście powinieneś zastosować horizontal partitioning
Czy jeżeli zrobię transakcję, a w niej ten cały WHILE który będzie robił update po 5k wierszy to będzie to jakieś upsrawienie? Czy ostatecznie i tak wszystkie updaty pójdą na commicie transakcji więc żaden uzysk?
Ogólnie zserializowana transakcja nie da dużego uzysku (wszystkie te locki, checki na na consistency i narzut z powodu transaction snapshots). Ale możesz otworzyć pulę połączeń do bazy (np. w liczbie rdzeni) i zrównoleglić te transakcje. To powinno dać sporego boosta do czasu.
W połączeniu z partycjonowaniem nawet sporego.

- Rejestracja:prawie 7 lat
- Ostatnio:około 12 godzin
- Postów:12
While w jednej transakcji raczej nie ma sensu. Sugerowałbym update wykonać w pętli, w kawałkach np po 100000 rekordów, każdy update na osobnej transakcji , wykorzystując klauzulę
OUTPUT INSERTED.Id , wrzucająca id zaktualizowanego rekordu do jakiejś tabeli logującej, aby w razie przerwania takiej pętli można pomijać rekordy które były już uaktualnione. Jeżeli wszytko musi być w jednej transakcji ze względów biznesowych, to należało by poprosić o udostępnienie czasu w oknie serwisowym.

- Rejestracja:ponad 14 lat
- Ostatnio:około 8 godzin
- Postów:2062
Ja bym sprawdził na testowej instancji bazy ile to trwa bo taki milion to może być chwila albo godziny zależny co tam w tej bazie siedzi
Podzielenie procesu na kilak tysiecy zapytań spowoduje że bedzie wiecej komunikacji klient-serwer wiec pewnie potrwa to dłużej
jezeli commit jest na poczatku i na koncu to w sumie to niewiele to zmieni podczas sukcesu operacji
- Rejestracja:prawie 10 lat
- Ostatnio:około godziny
- Postów:2363
Marius.Maximus napisał(a):
Ja bym sprawdził na testowej instancji bazy ile to trwa bo taki milion to może być chwila albo godziny zależny co tam w tej bazie siedzi
Warto srpawdzić, ale pamiętać, że na testowej bazie nie masz produkcyjnego workloadu, więc wartość testów w tym, że możesz wykryć, że na nieobciążonej bazie testowej taki update trwa o wiele za długo (albo wystąpią inne problemy). To, że na testowej będzie szybko nie musi przenieść się na bezproblemową operację na bazie produkcyjnej, w przypadku której, może się sporo wydarzyć, np. lock escalation na całą tabelę, deadlocki, blokady odczytów, czy jak coś pójdzie nie tak, bardzo długi rollback.
Do tego warto się zastanowić, co to za kolumna, która jest aktualizowana, np. część klucza głównego, kolumna z constraintem, czy indeksem i jaki będzie efekt update'u na inne systemy, np. na replikację w środowisku produkcyjnym (czy jest synchroniczna, asynchroniczna, fizyczna, logiczna - konsekwencje mogą być różne).

- Rejestracja:ponad 2 lata
- Ostatnio:około 12 godzin
- Postów:1583
Marius.Maximus napisał(a):
Ja bym sprawdził na testowej instancji bazy ile to trwa bo taki milion to może być chwila albo godziny zależny co tam w tej bazie siedzi
IT to nie jest nauka eksperymentalna.


