Masowe kompaktowanie baz danych

[Wojciech Olanin 3]

Dzień dobry,

 

W InsERT GT od wersji 1.79 HF1 zostało wyłączone kompaktowanie baz danych, wykonywane przez Biuro GT przy konwersji.

Przez co rozmiar baz danych SQL z łącznie ok. 450 GB na serwerze, teraz wzrósł do ok. 750 GB, co daje wzrost aż o 300 GB, co jest niemałym problemem przy serwerze w którym dyski są o pojemności 960 GB.

W jaki sposób mogę przeprowadzić masowe kompaktowanie baz danych? W programie serwisowym mogę to wykonać jedynie pojedynczo dla każdego podmiotu, nie widzę opcji zaznaczenia wielu podmiotów, co przy ponad 1000 podmiotach wykonanie ręcznie jest niemożliwe dla każdego z nich.

[Paweł Szczygieł 36]

Proponuję rozwiązanie oparte o polecenia SQL z poziomu joba SQL agenta.

 

[Wojciech Olanin 3]

Tylko dlaczego InsERT tak utrudnia i mam samemu dorabiać coś, co funkcjonowało i było (jest) w ofercie programu.

Ogromny wzrost cen, do tego opcja która od lat była dostępna (i w zasadzie nadal jest, tylko mimo jej zaznaczenia nie działa) i dobrze się to sprawdzało.

 

Czy InsERT nie przewidział jakie mogą być skutki wyłączenia tej opcji, szczególnie na dużych instalacjach i nie dania użytkownikowi wyboru z niej skorzystania, jak było cały czas?

[Paweł Szczygieł 5]

Kompaktowanie bazy danych nie jest zalecaną czynnością - stanowi w praktyce operacje shrinkdatabase. Taka operacja zalecana jest w określonych sytuacjach i nie zalaca sie jej wykonywać jako standardowa czynność.

[Jacek Izydorczyk 1 336]

2 godziny temu, Wojciech Olanin napisał:

Tylko dlaczego InsERT tak utrudnia i mam samemu dorabiać coś, co funkcjonowało i było (jest) w ofercie programu.

InsERT nie ma na celu nikomu niczego utrudniać. Od okolic wersji 1.79 pojawiły się problemy z wielowątkową zbiorczą konwersją baz danych - w niektórych środowiskach etap kompaktowania powodował przerywanie konwersji i pozostawienie użytkownika z wieloma uszkodzonymi bazami. Ponieważ problemu nie udało się na szybko rozwiązać, została podjęta decyzja o wyłączeniu kompaktowania baz danych przy zbiorczej konwersji, dorównując jednocześnie ten proces do konwersji indywidualnej wykonywanej bezpośrednio z Rachmistrza/Rewizora/Subiekta - tam już od dawna kompaktowanie nie jest wykonywane. Zdaję sobie sprawę, że to wylanie dziecka z kąpielą, bo teraz problemy mają Ci, którzy mają mało miejsca na dysku, ale cóż... teraz przynajmniej wiadomo dlaczego nie działa. Pytanie tylko, ilu ma lepiej a ilu ma gorzej.

 

Niebawem w Biurze GT pojawi się osobna operacja zbiorcza do kompaktowania baz danych. Niewiele to jednak zmieni dla całego procesu, ponieważ i tak potrzebny będzie bufor w postaci miejsca na dysku do wykonania konwersji, a dopiero później będzie można to miejsce odzyskać.

 

Z uwagi na to, w jaki sposób odbywa się konwersja baz danych i że ona sama w sobie powoduje, że bazy podczas konwersji puchną, osobiście uważam, że kompaktowanie powinno pozostać jako opcjonalny element konwersji, ale jego ewentualnie niepowodzenie nie powinno być przeszkodą do formalnie prawidłowego zakończenia konwersji. Przyrost wielkości bazy danych przy konwersji z 1.78 -> 1.79 i tak jest niewielki w porównaniu z tym, jakie te przyrosty mogą być - to wszystko zależy od tego, których tabel dotyczy konwersja.

 

Ja na ten moment obchodzę problem w taki sposób, że równolegle do zbiorczej konwersji puszczam w kółko skrypt kompaktujący bazy, które zostały już skonwertowane.

Edytowane 24 Lutego przez Jacek Izydorczyk

[Andrzej Kubik 1 095]

Warto też pamiętać że te "napuchnięte" GB nie są stracone. Bazy rozrastające się w miarę dodawania nowych dokumentów będą wykorzystywać te wolne GB nie zwiększając swojego rozmiaru, dopóki będzie to możliwe.