DBA, która martwi się reorganizacją lub przebudową indeksów może spowodować utratę danych?

Mamy kilka baz danych z fragmentacją indeksu, która wynosi> 95%. Co najlepsze, mogę powiedzieć, że indeksy nigdy nie zostały odbudowane, a tym bardziej zreorganizowane. W latach.

(Mówiąc uczciwie, wydaje się, że te tabele mają włączoną automatyczną aktualizację statystyk. Ponadto, uczciwie, dokłada starań, aby tworzyć kopie zapasowe: pełne dzienniki i dzienniki trx co godzinę.)

Kiedy zapytałem, DBA powiedział, że niechętnie odbudowuje lub zmienia indeksy. Kiedy zapytałem dlaczego, tak naprawdę nie był w stanie tego wyrazić. W końcu powiedział, że martwi go potencjalna utrata danych. Na przykład jedna z baz danych jest używana przez naszą aplikację księgową Great Plains Dynamics i wydawał się bardzo zaniepokojony.

Nie jestem DBA, ale z tego, co przeczytałem, jego lęk wydaje mi się ... trudny do zrozumienia.

Nie jestem pewien, co dalej. Sugestie, jak powinienem postępować?

sql-server maintenance

— Greg Hendershott
źródło

O ile baza danych nie zostanie mocno uderzona 24/7, a świat skończy się, jeśli przejdzie w tryb offline, nie ma usprawiedliwienia dla takiego zachowania. Co tydzień piszę zmiany w statystykach i statystyki w ponad 12 000 bazach danych. Przez 16 lat miałem tylko jeden uszkodzony z powodu złego kontrolera.

— Brain2000

Odpowiedzi:

Odbudowanie indeksu bazy danych nie powinno spowodować utraty danych. Prawdopodobnie spowoduje to jednak znaczny spadek wydajności, ponieważ przebudowywane indeksy zwykle nie będą dostępne do użycia do czasu zakończenia odbudowy. Z tego powodu należy to zrobić poza godzinami pracy, gdy zagrożone systemy są bezczynne.

Paranoja to dobra rzecz w DBA - jeśli martwią się utratą danych, kazałbym im wykonać odpowiedni test kopii zapasowych (przywrócić je do osobnego systemu i upewnić się, że wszystkie dane są dostępne), a jeśli są Nadal zaniepokojone byłoby wykonanie pełnej kopii zapasowej przed odbudowaniem indeksów.

— voretaq7
źródło

+1 dla Paranoi to Dobra Cecha DBA

— Joel Coel

Całkowicie rozumiem i doceniam zdrową paranoję. Zmierz dwa razy, wytnij raz. Gdzie jestem flummoxed jest ten wydaje się o braku zrozumienia zamiast ostrożnością. I zamiast „ostrożnie ustalmy sposób, aby spróbować”, to „tak się nie stanie”. Możemy (powiedzmy) spoolować testową instancję EC2 z kopią danych, ponownie uporządkować indeksy, czas, delta wiersze tabeli wyników, aby potwierdzić, że żadne dane nie zostały uszkodzone. Tego rodzaju plan byłby ostrożnością ... w przeciwieństwie do bezczynności?

— Greg Hendershott

Przypomnienie, że reorganizacja indeksu jest zawsze dostępna online (wszystkie indeksy są dostępne podczas defragmentacji), a przebudowę indeksu można również wykonać online ( WITH (ONLINE=ON)o ile indeks nie zawiera kolumn BLOB

— Remus Rusanu

@Greg Tak, mentalność „Nie dotykajmy tak indeksów, które są tak rozdrobnione, że prawdopodobnie HURTING wydajność” mnie też do cholery dezorientuje - okazjonalne REINDEXjako „konserwacja zapobiegawcza” w tabelach, w których zawartość indeksu bardzo się zmienia, jest całkiem ładna powszechne w moim doświadczeniu (jeśli indeks jest w większości statyczny, to mniej ważne)

— voretaq7

@Remus dobra wskazówka - Zmniejsza to wpływ na wydajność (nadal będziesz mieć wysoki dysk I / O, co spowolni niektóre, ale przynajmniej rzeczy, które użyłyby indeksu, mogą go nadal używać zamiast uciekać się do skanowania sekwencyjnego )

— voretaq7

Nie ma ryzyka utraty danych w wyniku przebudowy lub defragmentacji indeksów.

— mrdenny
źródło

Chyba że masz już pewien stopień uszkodzenia danych lub nie działa sprzęt. Ale w obu przypadkach fragmentacja indeksu jest najmniejszym z twoich zmartwień!

— db2

Ale to nie byłaby korupcja z powodu odbudowy indeksu, ale z jakiegoś innego problemu.

— mrdenny

Reorganizacja indeksów zajmie mniej czasu i mniej wysiłku ze strony serwera SQL, więc można to zrobić w instancjach typu weekend. Jeśli to, co mówisz, jest prawdą, nawet reorganizacja indeksów, które nigdy nie były, może mieć większy wpływ na serwer. Odbudowanie indeksów wymaga znacznego wysiłku od serwera SQL, ponieważ są one upuszczane i odbudowywane. Wykonanie przebudowy w ciągu tygodnia nie jest warte ryzyka, że serwer będzie zajęty indeksami i nie będzie obsługiwał osób z niego korzystających.

Zgadzam się z voretaq7, jeśli martwi go praca z indeksami, wypróbuj go na serwerach programistycznych lub testowych, aby zobaczyć, jak zareagują.

— RateControl
źródło

Innym podejściem może być jawne DROP INDEXi ponowne CREATE INDEX- nie jestem pewien co do SQL Server, ale wiem, że PostgreSQL czasami lepiej usuwa indeks i zaczyna od zera niż próbuje go odbudować ( REINDEX).

— voretaq7

Jestem pewien, że upuszczanie i odtwarzanie nie jest konieczne na SQL Server.

— Justin Dearing

@Justin Jestem pewien, że masz rację (w rzeczywistości z moich dni Sybase pamiętam, że zachowanie reindeksowania jest efektywne upuszczanie / tworzenie, więc nie ma dziwactwa blokującego indeks jak w Postgresie)

— voretaq7

Reorganizacja indeksów może zająć mniej czasu. To, co potrwa dłużej, będzie zależeć od stopnia fragmentacji indeksu.

— mrdenny