Naprawdę nigdy nie zaleca się reorganizacji i zmniejszania.
Jeśli możesz przenieść aplikacje, które baza danych obsługuje w trybie offline, możesz przyspieszyć proces i zmniejszyć fragmentację indeksów, usuwając wszystkie indeksy i ograniczenia klucza podstawowego / obcego przed zmniejszeniem (oznacza to, że będzie mniej danych do przenoszenia, ponieważ tylko strony danych zostaną przetasowane, a nie nieistniejące już strony indeksu, co przyspieszy proces), a następnie ponownie utworzą wszystkie indeksy i klucze.
Ponowne odtworzenie indeksów po zmniejszeniu oznacza, że nie powinny one być znacznie pofragmentowane, a ich zniknięcie podczas zmniejszania oznacza przebudowanie ich nie pozostawi wielu małych „dziur” w przydziale stron w plikach, które mogą zaprosić do fragmentacji później.
Inną opcją, jeśli możesz wyłączyć aplikacje, jest migracja wszystkich danych do nowej bazy danych o tej samej strukturze. Jeśli proces kompilacji jest solidny, powinieneś być w stanie szybko zbudować tę pustą bazę danych, jeśli nie, utwórz ją z bieżącej bazy danych (przywróć kopię zapasową bieżącej bazy danych, skróć / usuń całą zawartość tabel i wykonaj pełne zmniejszanie).
Nadal możesz chcieć upuścić wszystkie indeksy w miejscu docelowym i odtworzyć je później, ponieważ może to być o wiele bardziej wydajne przy zmianie dużej ilości indeksowanych danych (w tym przypadku 100%). Aby przyspieszyć proces kopiowania, umieść pliki danych docelowej bazy danych na różnych fizycznych dyskach do źródła (chyba że używasz dysków SSD, w którym to przypadku nie musisz martwić się o ograniczenie ruchów głowy), możesz je przenieść po zakończeniu do lokalizacji źródłowej.
Ponadto, jeśli utworzysz miejsce docelowe jako nowe (zamiast pustego miejsca na kopię źródła), utwórz go z początkowym rozmiarem, który będzie zawierał wszystkie bieżące dane plus wzrost o kilka miesięcy - dzięki temu dane będą znowu trochę szybsze, ponieważ nie będzie od czasu do czasu przydzielać nowej przestrzeni.
Może to być lepsze niż użycie funkcji zmniejszania, ponieważ migracja danych do świeżej bazy danych replikuje zamierzone działanie operacji zmniejszania, ale potencjalnie przy znacznie mniejszej fragmentacji (co jest niezamierzoną konsekwencją reorganizacji i zmniejszenia). Zmniejszenie po prostu pobiera bloki z końca pliku i umieszcza je w pierwszej przestrzeni bliżej początku, nie próbując utrzymać powiązanych danych razem.
Podejrzewam, że wynik będzie również bardziej wydajny pod względem przestrzennym, ponieważ prawdopodobnie później będzie mniej stron częściowo wykorzystywanych. Zmniejszenie spowoduje po prostu przenoszenie częściowo używanych stron, przenoszenie danych z większym prawdopodobieństwem spowoduje powstanie pełnych stron, szczególnie jeśli wstawisz do miejsca docelowego w kolejności klucza / indeksu klastrowanego (gdzie tabela ma jeden) i utworzysz inne indeksy po migracji wszystkich danych.
Oczywiście, jeśli nie możesz w ogóle przełączyć aplikacji w tryb offline, po prostu zmniejszanie jest jedyną opcją, więc jeśli naprawdę musisz odzyskać miejsce, idź z tym. W zależności od danych, wzorców dostępu, wielkości wspólnego zestawu roboczego, ilości pamięci RAM serwera itd. Dodatkowe fragmentowanie wewnętrzne może nie być aż tak znaczące.
W przypadku operacji kopiowania równie dobrze działałby SSIS lub podstawowy T-SQL (opcja SSIS może być mniej wydajna, ale potencjalnie łatwiejsza w utrzymaniu później). Jeśli utworzysz relacje FK na końcu wraz z indeksami, możesz zrobić proste „dla każdej tabeli, skopiuj” w obu przypadkach. Oczywiście jednorazowo reorganizacja kurczenia się + jest prawdopodobnie w porządku, ale lubię straszyć ludzi, aby nigdy nie brali pod uwagę regularnych skurczów! (Wiem, że ludzie planują je codziennie).