Mam kilka tabel z ilością rzędów od 5M do 1,5G
Każda tabela ma swoje pole BLOB, którego rozmiar waha się od 100 bajtów do 30 MB i które są przechowywane jako „duże typy wartości poza wierszem” = ON
Tabele są przechowywane w różnych aplikacjach z 3-4 plikami na różnych dyskach @ różnych jednostkach LUN @ bardzo szybkiej sieci SAN
Każdego dnia te tabele rosną do wielkości 5-100 Gb i przy rzędach 600k - 1,5M
Po pewnym czasie , który wynosi od 2 tygodni do 6 miesięcy, niektóre wiersze są usuwane lub przenoszone do archiwizacji DB, więc - nie ma żadnych wierszy w tabelach roboczych starszych niż 6 miesięcy.
Aktualna konfiguracja serwera:
- Mechanizm serwera SQL to 2008 R2 SP1 Enterprise @ 24 rdzenie, @ 64 GB pamięci RAM
- SQL Server działa z dodatkowymi flagami startowymi:
-T 3640; (Eliminuje wysyłanie do klienta komunikatów DONE_IN_PROC dla każdej instrukcji w procedurze składowanej. Jest to podobne do ustawienia sesji USTAW NOCOUNT WŁĄCZONY, ale po ustawieniu flagi śledzenia każda sesja klienta jest obsługiwana w ten sposób)
-T 1118; (Przełącza przydziały w tempDB z 1pg na raz (dla pierwszych 8 stron) w jednym zakresie.)
-T 2301; (Umożliwia zaawansowane optymalizacje, które są specyficzne dla zapytań wspomagających podejmowanie decyzji. Ta opcja dotyczy przetwarzania wspomagającego podejmowanie decyzji dla dużych zestawów danych)
-T 1117; (Zwiększa wszystkie pliki danych naraz, w przeciwnym razie idzie po kolei).
-MI; (Zwiększa liczbę zakresów przydzielonych dla każdego pliku w grupie plików. Ta opcja może być pomocna w przypadku aplikacji hurtowni danych, które mają ograniczoną liczbę użytkowników skanujących indeks lub dane)
-T 834; (Powoduje, że SQL Server używa alokacji dużych stron systemu Windows dla pamięci przydzielonej dla puli buforów, http://msdn2.microsoft.com/en-us/library/aa366720.aspx , http://support.microsoft. com / kb / 920093 )
- SQL Server używa rozszerzeń dużych stron
- SQL Server wykorzystuje opcję szybkiej inicjalizacji plików
- AUTOSHRINK jest WYŁĄCZONY dla wszystkich baz danych
Problem polega na tym, że począwszy od pewnego czasu przestoju serwera (od kilku dni do miesięcy) GHOST CLEANUP
proces odmawia wykonania wymuszonych porządków i po prostu wykonuje swoją zwykłą pracę - czyści kilka stron w ciągu kilku sekund ( which is seen thru Extended Events
), co nie jest odpowiednie , ponieważ nie jest w stanie wyczyścić wszystkich usuniętych wierszy
Problem utrzymuje się od czasów SQL Server 2005 RTM Enterprise
Jak próbowałem rozwiązać problem:
- Próbowano wymusić operacje SCAN na indeksach klastrowych tabel
- Próbowano wymusić operacje SCAN, które obejmowały całą zawartość kolumny BLOB w indeksach klastrowych tabel
- system sp_clean_db_free_space & sp_clean_db_file_free_space
- ręcznie dbp cleanpage (@dbid, @fileid, @page) dla wszystkich plików i stron w DB
- indeks klastrowany odbudowuje i reorganizuje
- odtwarzanie bazy danych
DBCC FORCEGHOSTCLEANUP
Po uruchomieniu zapytania:
select * from sys.dm_db_index_physical_stats(db_id(), object_id('ProblemTable'), 1, 0, 'detailed')
Widzę miliony i dziesiątki milionów rekordów duchów, ale tylko dla typu jednostki alokacji LOB_DATA
Jedyne rzeczy, które pomagają:
- zatrzymanie serwera za pomocą polecenia SHUTDOWN lub zrestartowanie całego hosta - pomaga, po ponownym uruchomieniu proces GHOST CLEANUP działa kilka godzin i faktycznie czyści wszystkie widmowe rekordy
- DBCC SHRINKFILE z opcją EMPTYFILE - przeniesienie wszystkich danych z jednego pliku do innego lub nowo utworzonych plików czyści rekordy duchów tylko w tym pliku - problem polega na tym, że naprawdę nie znoszę operacji zmniejszania. I zajmuje to 3-4 dni na JEDEN plik
pytanie - czy istnieje jakiś programowy (preferowany) lub konserwacyjny sposób na wymuszenie GHOST CLEANUP bez przestoju serwera, ponieważ przestój serwera kosztuje zbyt dużo, a nawet jest nie do przyjęcia - wynosi od tysięcy do dziesiątek tysięcy $ za godzinę
Problemy zostały zauważone, podobnie jak moje są tutaj:
- http://support.microsoft.com/kb/932115
- http://www.sqlservercentral.com/Forums/Topic496244-149-1.aspx
I to samo jest tutaj: