Update miliona rekordów w transkacji?

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?

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.

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.

Update po 5k wierszy w ramach jednej transakcji, to nadal jedna transakcja. Dlaczego chcesz 9mln wierszy aktualizować w jednej transakcji?

A jak ma wyglądać ten update?
Chcesz dodać 50Mb Blob na rekord, czy ustawić jakąś falge z true na false?
Bo może wcale nie ma się czego bać i chwilowy lock na 1 sek nie będzie zauważalny.

9 milionów to jakieś grosze, ja mam tabelki z 5 miliardami, możesz zrobić update, oczywiście możesz to robić w paczkach, za mało szczegółow podałeś na czym ci zalezy

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

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

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.