Uważam, że jest to przydatne podczas usuwania z tabeli z dużą liczbą wierszy, aby usunąć wiersze w partiach powiedzmy 5000 (zwykle testuję, aby zobaczyć, która wartość działa najszybciej, czasami jest to 5000 wierszy, czasami 10 000 itd.) . Dzięki temu każda operacja usuwania może zakończyć się szybko, zamiast czekać długo, aż jedna instrukcja usunie 400 milionów rekordów.
W SQL Server 2005 coś takiego powinno działać (oczywiście najpierw przetestuj):
WHILE EXISTS ( SELECT * FROM giganticTable WHERE exp_date < getDate())
BEGIN
DELETE TOP(5000) FROM giganticTable WHERE exp_date < getDate()
END
Zobaczyłbym, jak usuwanie w partiach wpływa na rozmiar pliku dziennika. Jeśli nadal wysadza dzienniki, możesz spróbować zmienić model odzyskiwania na Proste , usuwając rekordy, a następnie przełączając się z powrotem na tryb Bulk Logged, ale tylko wtedy, gdy system toleruje utratę niektórych ostatnich danych. Zdecydowanie wykonałbym pełną kopię zapasową przed przystąpieniem do tej procedury. Ten wątek sugeruje również, że możesz skonfigurować zadanie tworzenia kopii zapasowej dzienników z określonym tylko obcięciem, więc może to być inna opcja. Mam nadzieję, że masz instancję, z którą możesz przetestować, ale zacznę od usunięcia wsadowego, aby zobaczyć, jak wpływa to na wydajność i rozmiar pliku dziennika.
