Muszę zmniejszyć bazę danych o ok. 1 TB w dół do około 700 GB (co pozostawia ponad 200 GB na rozwój bez rozszerzenia). Mam skrypt, który zapętli i zmniejszy bazę danych o ustalony przyrost (na przykład 1 GB). Jest to bardzo pomocne na wypadek, gdybyś musiał przerwać w dowolnym momencie, ponieważ postęp nie został utracony, operacja całkowitego skurczu może trwać 4-5 dni. Pytanie brzmi: czy zmniejszenie pliku bazy danych w przyrostach w porównaniu do jednego strzału (wykonanie jednego pliku skurczowego dbcc) spowoduje większą fragmentację, czy nie? Dzięki!!
Odpowiedzi:
2 dla odpowiedzi № 1(Jest to oparte na MS SQL Server. Twój przebieg może się różnić w zależności od innych RDBMS.)
Podejrzewam, że gdyby wszystko inne było równenie narażajcie się na większą fragmentację poprzez, błahostka, fragmentację procesu kurczenia się. Gdy pliki zostaną zmniejszone, SQL może wymagać przeniesienia danych wewnętrznych, ze stron, które zostaną usunięte, na puste strony, które nie zostaną usunięte. Wydaje się prawdopodobne, że gdyby bloki A, B i C zostały przeniesione do X, Y i Z, a następnie usunięte z pliku bazy danych, wówczas wykonanie tego w trzech krokach wygenerowałoby tyle fragmentacji, co wykonanie w trzech krokach.
Problem, który widzę, dzieje się, jeśli pierwszy„skurczył się” blok A, a zanim zacząłeś pracę nad blokiem B, załadowano więcej danych, co spowodowało, że baza danych zapisała dane w bloku D - sekcji, która była wcześniej pusta i docelowa dla ewentualnego skurczenia? Co gorsza, jeśli dodanie nowych danych wymagało odtworzenia bloku A, który musiałbyś wtedy ponownie skurczyć?
Jest to próba opisania na wysokim poziomiecoś, co znam tylko z wyglądu. Podejrzewam, że wielokrotne obkurczanie mogłoby wygenerować więcej fragmentacji, choćby z powodu dodatków do bazy danych między sesjami obkurczania. Im mniej sesji, tym lepiej.
0 dla odpowiedzi nr 2
Aby uzyskać bardziej szczegółowe informacje na temat „Dlaczego NIE powinieneś SHRINK bazy danych lub nie naciskać przycisku zmniejszania”, skorzystaj z poniższych łączy.
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx http://sqlinthewild.co.za/index.php/2007/09/08/shrinking-databases/
HTH, K.