SQL Server - Wymuś DB w pamięci?

Mamy rozbudowany serwer Windows 2008 x64 (4 x 4 rdzeniowy procesor, 32 GB pamięci RAM) z uruchomionym SQL Server 2005 64-bitowym. Mamy małą (6 GB), ale bardzo ważną bazę danych, do której dostęp jest nieco powolny, dopóki strony nie zostaną buforowane w pamięci (użycie jest bardzo losowe we / wy, więc szanse są bardzo niskie, że dana strona jest w pamięci, a użytkownicy końcowi narzekać na początkową powolność). Dyski są wystarczająco szybkie (lokalny SAS 15K), ale myślę, że aplikacja jest dość niezdarnie napisana (jest to rozwiązanie COTS), więc zastanawiam się, czy istnieje sposób na „wymuszenie” bazy danych w pamięci w SQL Server 2005 (2008 nie jest obsługiwany przez dostawcę, więc nie powinniśmy jeszcze tego robić), aby uniknąć początkowego bluesa wypełniającego pamięć podręczną?

Moja obecna metoda polega na tym, że uruchamiam SELECT * z każdej tabeli w skrypcie, aby uzyskać strony danych w pamięci, ale niektóre obiekty (indeksy, wyszukiwanie pełnotekstowe itp.) Nie są buforowane przez tę metodę (i modyfikują skrypt, aby przesłuchiwał indeksy i napisz odpowiednie klauzule WHERE, aby buforować kompleks boil-the-ocean).

Nie, nie ma sposobu, aby zmusić bazę danych do buforowania, niestety. Twoja metoda brutalnej siły jest prawdopodobnie najprostsza. Możesz być w stanie podejść bliżej, używając skryptów defragmentujących indeks z ustawieniem bardzo niskiego progu, np. Powiedz, że przebuduj indeks, jeśli jest on fragmentowany w 1%, jak poniżej:

http://sqlserverpedia.com/wiki/Index_Maintenance

To potrwa dłużej i będzie wymagało więcej zapisów na dysku, ale przyniesie efekt uboczny defragmentacji indeksów i aktualizacji statystyk, co i tak jest dobrym pomysłem.

Ok - nie mogę komentować odpowiedzi Brenta (jeszcze, ponieważ nie mam wystarczającej liczby powtórzeń) - ale jeśli zamierzasz przejść defragmentację, niekoniecznie odbuduj indeks - ponieważ spowoduje to zbudowanie nowych indeksów, być może powiększenie bazy danych, jeśli nie ma wystarczającej ilości wolnego miejsca, i zagwarantowanie, że twoja kolejna kopia zapasowa dziennika będzie miała co najmniej rozmiar indeksów, a Twój dziennik może zawierać również mnóstwo rekordów dziennika (w zależności od modelu odzyskiwania). Jeśli zamierzasz wykonać defragmentację, zrób ALTER INDEX ... REORGANIZE, który nie wymaga żadnego wolnego miejsca (cóż, jednej strony 8k), ale odczyta poziom liścia do pamięci i działa tylko na pofragmentowanym strony. Poziomy inne niż liście powinny pojawić się szybko po niektórych zapytaniach i (w zależności od rozwinięcia) dane powinny być znacznie mniejsze niż poziom liści.

Dlaczego obiekty bazy danych są w pierwszej kolejności usuwane z pamięci podręcznej? Czy ponownie uruchamiasz usługi SQL, czy wyłączasz bazę danych / online? A może są wypychane przez buforowanie z innych baz danych?

Pozdrowienia,

SCM.

Jeśli baza danych jest tak mała, rozważ umieszczenie jej na dysku SSD?

Miałem kilka scenariuszy, że aktualizacja statystyk za pomocą FULLSCAN w tabelach kluczy zmusiła dane do buforowania i sprawiła, że ​​moje kolejne pliki DML wokół tych tabel były znacznie szybsze. I nie było to wynikiem nieaktualnych statystyk, ponieważ nie spowodowało żadnych zmian w planach wykonania.

Dlaczego nie zainstalujesz drugiej instancji SQL Server z tylko tą bazą danych i nie ustawisz minimalnej pamięci dla tej instancji na 6 GB?

To zagwarantuje, że twoje inne bazy danych nigdy nie będą gromadziły pamięci z twojej „małej, ale bardzo ważnej” bazy danych.

Oznacza to również, że możesz przełączyć drugą instancję w tryb offline, a mały DB pozostanie w pamięci.

Użyłbym profilera do sprawdzenia twojej sql. Porównaj odczyty „logiczne” z odczytami „fizycznymi”. Serwer SQL jest inteligentny i użyje potrzebnej pamięci RAM, aby uzyskać najbardziej efektywne wyniki.

Sprawdź także, czy Twoje autostaty są aktualne.

Bez większego pojęcia o rodzaju zapytania i rozmiarach tabeli db brzmi to nieco dziwnie.