Forum Użytkownikow Subiekt GT
InsERT GT => Subiekt GT => Wątek zaczęty przez: browarnicy w Kwiecień 09, 2021, 15:43:53
-
Komputer na którym jest Baza Danych to:
Windows 7 Profesional
Intel Core i5 - 2400
RAM 4G
Dysk systemowy SSD
Baza przeniesiona na zewnętrzny HDD
Problem oczywiście z wielkością Bazy. W programie serwisowym "Odbudowa indeksów i statystyk" nic nie daje, tak samo "kontrola danych", a "kompaktowanie" kończy się komunikatem że jest nieudane, z tym że rozmiar bazy podskakuje o 4-5G. Ratowałem się odzyskaniem bazy z kopii, ale i tak po ostatniej aktualizacji ma już 40G. Na bazie program chodzi bez zastrzeżeń, baza ma jakieś 10 lat i potrzebuje ją zmniejszyć. Na bazie działa Subiekt GT, korzystamy głównie z modułów sprzedażowych i zakupowych. Bez żadnych dodatków obciążających baze, typu maile czy zdjęcia.
Czy jest możliwość sprawdzenia co powoduje taki rozrost tej bazy? Same dokumenty zakupu, sprzedaży, lista towarów i kontrahentów nie powinna ważyć 40G. Ma ktoś pomysł???
-
Oczywiście że można się dowiedzieć co powoduje rozrost bazy. Odpowiedniki zapytaniami do bazy można tę informację wyciągnąć.
Zakładając że nie ma binariów (zdjęcia, e-maile, biblioteka dokumentów) te 40GB to naprawdę dużo, ale to zależy od tego ile jest tych dokumentów, ile mają pozycji.
Na początek jednak brak tu 2 podstawowych informacji:
- jaki to serwer SQL (2008R2/2014/itp to jedno ale jaka edycja - Express/Standard/Enterprise)
- co dokładnie (który plik) zajmuje 40GB i skąd ta informacja.
-
SQL Server Express v.12.04237.0
Wielkość pliku NazwaPodmiotu to 739 392kB, a NazwaPodniotu_log to 42 670 912kB (informacja po otwarciu folderu z plikami bazy) W programie SSMS v.18.8 jak daje właściwości bazy danych to pokazuje 42 392MB. Więc wielkość potwierdzona.
-
W programie SSMS na bazie danych wybierz Tasks->Shrink->Files , potem w File Type wybierz Log i sprawdź ile da się zwolnić miejsca (pole Available free spaces), jak dużo to potwierdź OK.
-
No właśnie jak podaje kolega Chris to raczej nie problem z bazą, tylko jej administracją. Skoro to i tak darmowa wersja, to najprościej ustawić model recovery na simple, to logi nie będą tak przyrastać. W przeciwnym razie trzeba skonfigurować backupy i przycinanie logu. I tego co kolega Chris radzi chyba nie da się zrobić jak się wcześniej nie zrobi backupu logu, albo nie zmieni modelu recovery na simple i nie wykona pełnego backupu...
-
Procedura @Chris'a pomogła o tyle, że z 42G przycięło do 38G. W polu "Available free spaces" było napisane że jest wolne 38G (90%) ale przycięło tylko 4G. Teraz jak wchodzę tam to jest nadal sporo wolnego miejsca (log zajmuje 38G a wolnego miejsca jest ok.34G), ale ponowne zatwierdzenie już niczego nie zmienia. Wydaje mi się, że zredukowało tylko ostatni skokowy przyrost bazy danych związany chyba z ostatnią aktualizacją i konwersją bazy. Wcześniej próba wykonania kompaktowania w programie serwisowym kończyła się niepowodzeniem, a baza log skokowo się powiększała. To wygląda jakby cofnęło tylko ostatni taki błąd a z wcześniejszymi nie jest w stanie sobie poradzić.
Kolego @Artwi, jeszcze spróbowałbym twoje sugestie ze zmianą modelu recovery, ale coś nie mogę tego znaleźć. Możesz podać ścieżkę dostępu i sposób postępowania tak jak @Chris?
-
Zobacz, że w tym miejscu, które wcześniej opisałem, jest opcja "Reorganize files before releasing unused space". Warto sprawdzić czy rozwiąże Twój problem.
-
Możesz podać ścieżkę dostępu i sposób postępowania tak jak @Chris?
Prawoklik na bazę > Properties > Options > Recovery model > Simple > OK, potem pełny backup i tak jak podał kolega Chris.
-
Po zmianie Recovery model z full na simple po wejściu na Shrink->Files okazało się iż wolnego miejsca w pliku log jest 99% więc zrobiłem klik OK. w ten sposób udało się zmniejszyć log do 0,5MB z czego 0,17MB to wolne miejsce ;D Mam rozumieć, że plik log zawiera nikomu niepotrzebne dane skoro go zredukowało niemal do zera? Na pierwszy rzut oka wszystkie dane są zachowane, jest pełna historia dokumentów i wszystko hula.
Jeśli chodzi o plik główny to ma ok. 700MB w tym jakieś 15% wolnego miejsca, ale już chyba nie będę tego pomniejszać tym sposobem żeby nie przedobrzyć. No chyba, że uważacie iż jest to bezpieczne i warto zrobić. Ja już jestem zadowolony z redukcji bazy danych o 42GB :)
Wielkie dzięki
-
Mam rozumieć, że plik log zawiera nikomu niepotrzebne dane skoro go zredukowało niemal do zera? Na pierwszy rzut oka wszystkie dane są zachowane, jest pełna historia dokumentów i wszystko hula.
Nie, nie należy tak rozumieć. Przy niedarmowej wersji jest opcja recovery full, która na podstawie ostatniego backupu bazy i logu pozwala przywrócić bazę danych do do dowolnego punktu w czasie od ostatniego backupu bazy do ostatniego poprawnego wpisu w logu (bez backupu logu!), a nie tylko do ostatniego backupu bazy. W tym celu log opisuje KAŻDĄ zmianę w bazie i dlatego się tak rozrasta. By się tak nie rozrastał a były zachowane opcje recovery full, należy oprócz bazy, robić również kopie logu, np. kilka razy dziennie, jeśli to jest potrzebne, z opcją przycinania logu (by zawierał wpisy tylko od ostatniego backupu logu), wtedy wszystko jest małe, szybkie i jest opcja przywracania w czasie.
W wersji darmowej MS SQL przywracanie jest tylko simple, więc recovery można ustawić na simple i wtedy w logu mało co jest zapisywane, ale... gdyby było ustawione recovery full, to można byłoby w razie potrzeby pliki z darmowej bazy przenieść do pełnej i tam odzyskać do punktu w czasie. Dlatego najlepiej jest mieć poprawnie, tj. z logami i ich przycinaniem, ustawiony buckup full nawet w darmowej wersji. Z drugiej strony z praktyki wiem, że jak w bazach księgowych coś się pokićka przy czymś innym niż aktualizacja, to zwykle księgowe orientują się po... paru tygodniach/miesiącach i nie da się wtedy przywracać z backupu (choć backup jest przydatny, by zobaczyć co tam było, gdy było dobrze), tylko trzeba naprawiać bazę... Dlatego akurat w takich zastosowaniach model simple + ups + baza na macierzy z redundancją i jak się da, to serwer z pamięciami serwerowymi (z kontrolą parzystości) i najlepiej system plików z kontrolą poprawności danych w 99% pewnie styka...
-
Tak czytam i zaczynam się gubić w tych zabezpieczeniach stosowanych do bazy. Może krótko napiszę jak ja sobie z tym radzę i proszę o ewentualne sugestie co poprawić.
Komputer główny Windows 7 (serwer) podpięty do UPS. Każdorazowo po aktualizacjach po konwersji bazy danych do nowszej jest tworzona kopia tych dwóch plików baz. Ja je odpinam i przekopiowuję na dysk zewnętrzny w celu archiwizacji. Dodatkowo na koniec dnia jest robiona archiwizacja danych przy zamykaniu Subiekta. Tyle z mojej inicjatywy.
Teraz po tych zabawach z bazą, na bazie log jest zmienione na simple. Mam zmienić z powrotem na Full?
Tak wczytuję się co piszesz i zastanawiam się czy nie mówisz o zaawansowanych zabezpieczeniach większych systemów serwerowych dużych firm. U mnie to mała firma z Subiektem na 3 stanowiska...