Proces SQL obciąża tylko jeden rdzeń

2 minuty z google i wiedziałbyś że licencje na MSSQL ograniczają ilość procesorów. Im droższa licencja tym więcej można ich obsługiwać. Ale nie widziałem zeby ograniczały użycie większej ilości rdzeni. Jesteś pewien że w ustawieniach nigdzie nie ma opcji z tym związanych?

Szukałem, to nie tak, że od razu płacze ludziom na forum ;).

Maximum Number of Processors Supported by the Editions of SQL Server:
http://msdn.microsoft.com/en-us/library/ms143760.aspx

Moja wersja obsługuje 2xCPU fizyczne, wersja Express przykładowo obsługuje 1xCPU fizyczne.
Jednak Microsoft twierdzi, że 4 rdzenie w Quad Core to jest 1 CPU, więc teoretycznie mój problem nawet w wersji Express nie powinien występować.

EDIT:
W ustawieniach, jest ustawione:
Automatically set processor affinity mask for all processors.
Automatically set I/O affinity mask for all processors.

Ale Maximum worker threads: 0
...i tu jest chyba pies pogrzebany
Dobra, chwilka MSDN powinna wyjaśnić ten bałagan w ustawieniach ;)

EDIT2:
Max worker threads na 0 w SQL 2005 oznacza, że SQL sam sobie używa tyle wątków ile potrzeba.
select count(*) from sys.dm_os_threads daje 53
select max_workers_count From sys.dm_os_sys_info daje 256.
... więc teoretycznie tutaj jest OK.

a mozesz podac przyklad zapytania? Jak masz zrobiona baze tempdb? Zalecane jest zeby plikow mdf + ndf bylo tyle ile procesorow.
Jesli w zapytaniu masz np opcje WITH MAXDOP() to moze byc odpowiedz na Twoje problemy.

Niektóre zapytania szybciej wykonują się na jednym wątku niż na wielu (dodanie WITH MAXDOP(1) przyspiesza zapytanie).
Do wykonania zapytania nie wystarczy CPU, ale też dysk.

Wiele CPU przydaje się głównie wtedy, gdy baza ma wykonywać wiele zapytań jednocześnie.

Sprawdź plan zapytania i spróbuj je zoptymalizować. Ewentualnie dodaj potrzebne indeksy.

Jeżeli masz wykorzystane tylko 25% procesora to znaczy, że nie procesor jest wąskim gardłem. Najbardziej prawdopodobnie odczyty z dysku są wąskim gardłem. Może pomóc:

• załadowanie danych do RAMu
• użycie szybszego dysku (np. SSD)
  Poza tym zależy jakie zapytania pchasz do bazy: jeżeli zapytania trwają długo (rzędu minut lub godzin) i przeglądają większą część rekordów to raczej trudno takie coś zrównoleglić w tradycyjnej bazie.

@__krzysiek85 - max dop wcale niczego nie przyspiesza :) bo? max dop to obluga na ilosci procesorow.
Max dop uzywa sie dla query ktorych wynika dzialania nie moze byc wynikiem pracy na wielu np rdzeniach (np sumowanie wartosci narastajaco - running values).

Niby jak zaladowac dane do RAMu? to przeciez robi silnik bazodanowy :)
SSD - niby fajnie ale trzeba uwazac - odpowiednia konfiguracja macierzy jest tutaj chyba lepsza :)
Niby czemu? dla baz produkcyjnych serwery sa ustawione na recovery mode = full (czesty zapis do ssd mija sie z celem :( niestety)

Niby jak zaladowac dane do RAMu? to przeciez robi silnik bazodanowy

W niektórych silnikach (np. Berkeley DB) da się wymusić, żeby część lub całość rekordów była załadowana do RAMu.