Witam,
jestem nowy na forum i nie mogę znaleźć informacji odnośnie mojego problemu - a wydaje mi się że pewnie powinien się już przewinąć :) Jeśli tak to proszę o informację i z góry przepraszam za duplikowanie tematów.
Chodzi mi mianowicie o wytyczne dotyczące sposobu tworzenia procedury składowanej w MS SQL która mogłaby przetwarzać się równolegle. Jakieś praktyczne wskazówki na przykład :)
Wyobraźcie sobie procedurę wywołującą w sobie wielokrotnie jakąś inną procedurę (nazwijmy ją PROC_B) z parametrem @id (leci sobie po kolei dla @id zawartych w cursorze) - PROC_B coś tam sobie liczy, wywołuje jakieś funkcje, coś tam zmienia w bazie dla tego @id itd. a na koniec zwraca komunikat (b. ważne) odnośnie wyniku przetworzenia @id. W sumie trwa to ok. 2 sek dla jednego wykonania (dla jednego ID). Tyle, że wykonań potrzeba ponad 10 tyś. A wiadomo - jak coś leci po kolei z cursora to kolejne wykonanie jest dopiero po zakończeniu poprzedniego.
Optymalizacja procedury PROC_B wywoływanej dla @id coś tam pewnie jeszcze pomoże - ale nie zmieni faktu że operacja jest mocno długotrwała.
Zaobserwowałem, że podczas przetwarzania wykorzystywany jest tylko jeden rdzeń serwera mającego ich trochę :) - za to obciążony jest w 100% - więc pomyślałem że może warto by było wykorzystać nieco więcej niż jeden na raz. Baza jest MS SQL 2008 Std więc wielordzeniowość obsługuje, operacji dyskowych wiele nie ma więc pole do przyspieszenia całkiem spore.
Problem mam "tylko" taki że nigdy nie pisałem z myślą o wielowątkowości i nie bardzo mogę znaleźć jakieś materiały w temacie. W programowaniu całkiem laikiem nie jestem ale za fachowca też uchodzić nie mogę a szkoły kończyłem gdy o wielu rdzeniach to jeszcze nikt dobrze nie myślał :) Może ktoś mądrzejszy powie jak podejść do tematu?
Teoretycznie wyznaczanie zakresu @id (to co jest w kursorze) mogę przenieść do aplikacji klienckiej pisanej w Delphi - i teoretycznie mogę wówczas uruchamiać kilkanaście połączeń do bazy i wrzucać równolegle kilkanaście wywołań PROC_B dla różnych @id - ale jakieś takie to rozwiązanie mało eleganckie się wydaje - z aplikacji nijak nie poznam ani ilości rdzeni serwera (czyli maksymalnej ilości równolegle przetwarzanych zapytań - swoją drogą z poziomu SQL-a można coś takiego wydobyć?) ani nie pozbędę się narzutu komunikacyjnego (czy to ADO czy inne kontrolki całkiem bezstratne nie są) - a wreszcie pomysł na aplikację był taki żeby była maksymalnie mała od strony końcówki - w przyszłości może być potrzeba przepisania jej np. do dostępnej przez Web-a.
Macie jakieś pomysły?
Pozdrawiam
Artur