Błąd Konwersji baz do wersji 1_79_HF2

[Dariusz Kamiński 0]

Witam.

Podczas dzisiejszej konwersji baz (zbiorcza w Biuro GT) do wersji 1_79_HF2 uwaliło mi ponad połowę baz. Nie jest to wina komputera bo przeszło przez wszystkie bazy i losowo (lub pod jakimś nieznanym mi warunkiem) jedne bazy przechodziły prawidłowo a inne uszkadzało.

Problem też raczej nie leży po stronie baz bo po przywróceniu z kopii i ponownej konwersji wszystko jest ok.

Co może być przyczyną takiego zachowania? Od "zawsze" robię aktualizację w ten sposób i nigdy nie było takiego problemu. Mam nadzieje że nie wiąże się to z kończącym się wsparciem dla Windows Server 2012?

 

Serwer Dell z Windows Server 2012, 64 GB ram, pełna wersja SQL 2016, konwersja robiona na serwerze, podczas konwersji wszystkie końcówki odłączone.

Z góry dziękuję za dyskusję.

[Daniel Kozłowski 1 171]

33 minuty temu, Bożena Kamińska napisał:

Co może być przyczyną takiego zachowania?

Zamiast zgadywać należy zacząć od przejrzenia logów z konwersji.

[Dariusz Kamiński 0]

Czy o taki log chodzi (z uwalonej bazy), jeżeli inny to proszę o wskazanie o który chodzi.

[Dariusz Kamiński 0]

Podczas zbiorczej konwersji w Biurze GT mimo zaznaczonej opcji kompaktowania bazy strasznie urosły pliki "*.log" co spowodowało zapchanie dysku (130 baz zapchało 15GB)

Robiąc konwersję z poziomu programu serwisowego również mocno rośnie *.log

Szkoda że z poziomu Biura GT nie ma możliwości zrobienia zbiorczego kompaktowania.

 

Edytowane 17 Lutego przez Dariusz Kamiński
podmiana załącznika

[Dariusz Kamiński 0]

[Paweł B 20]

12 godzin temu, Dariusz Kamiński napisał:

Podczas zbiorczej konwersji w Biurze GT mimo zaznaczonej opcji kompaktowania bazy strasznie urosły pliki "*.log" co spowodowało zapchanie dysku (130 baz zapchało 15GB)

 

15GB to jest tyle co nic. Jeśli to cała wolna przestrzeń na dysku, na którym są przechowywane bazy danych to polecam zastanowić się nad dołożeniem dodatkowego dysku lub wymianą obecnego na pojemniejszy.

[Daniel Kozłowski 1 171]

14 godzin temu, Dariusz Kamiński napisał:

Podczas zbiorczej konwersji w Biurze GT mimo zaznaczonej opcji kompaktowania bazy strasznie urosły pliki "*.log" co spowodowało zapchanie dysku (130 baz zapchało 15GB)

Robiąc konwersję z poziomu programu serwisowego również mocno rośnie *.log

Cytat z listy zmian do wersji 1.79 HF2:

Cytat

Wyłączono kompaktowanie bazy danych dla konwersji zbiorczej wywoływanej z programu Biuro GT.

--

14 godzin temu, Dariusz Kamiński napisał:

Szkoda że z poziomu Biura GT nie ma możliwości zrobienia zbiorczego kompaktowania.

Pojawi się taka możliwość.

--

Godzinę temu, Paweł B napisał:

15GB to jest tyle co nic.

Prawda.

 

Godzinę temu, Paweł B napisał:

Jeśli to cała wolna przestrzeń na dysku, na którym są przechowywane bazy danych to polecam zastanowić się nad dołożeniem dodatkowego dysku lub wymianą obecnego na pojemniejszy.

Moim zdaniem nie ma czego modernizować, sprzęt o wieku około 10 lat nie powinien być już od kilku lat wykorzystywany w biurze rachunkowym, to strata czasu na aktualizacje i bieżącą pracę oraz większe ryzyko wystąpienia awarii sprzętu, zamiast przesadzać z pamięcią ram i serwerem sql należało zmienić sprzęt. 

[Paweł B 20]

19 minut temu, Daniel Kozłowski napisał:

Moim zdaniem nie ma czego modernizować, sprzęt o wieku około 10 lat nie powinien być już od kilku lat wykorzystywany w biurze rachunkowym, to strata czasu na aktualizacje i bieżącą pracę oraz większe ryzyko wystąpienia awarii sprzętu, zamiast przesadzać z pamięcią ram i serwerem sql należało zmienić sprzęt. 

Nie zwróciłem uwagi na wersję OS. Sprzęt w takim wieku to chyba tylko nadaje się do pełnienia roli zapasowej.

 

[Dariusz Kamiński 0]

2 godziny temu, Paweł B napisał:

Nie zwróciłem uwagi na wersję OS. Sprzęt w takim wieku to chyba tylko nadaje się do pełnienia roli zapasowej.

 

Skoro działało i to całkiem dobrze, to po co zmieniać.  Wiem że 15GB miejsca wolnego na dysku to jest mało. Ale do tej pory wystarczało a wcześniejsze aktualizacje nie zapychały dysku.

Koniec wsparcia dla Win 2012 "wymusza" wymianę systemu a zarazem sprzętu co pewnie w niedługim czasie nastąpi. Niemniej jednak do tego czasu obecny będzie służył.

2 godziny temu, Daniel Kozłowski napisał:

Moim zdaniem nie ma czego modernizować, sprzęt o wieku około 10 lat nie powinien być już od kilku lat wykorzystywany w biurze rachunkowym, to strata czasu na aktualizacje i bieżącą pracę oraz większe ryzyko wystąpienia awarii sprzętu, zamiast przesadzać z pamięcią ram i serwerem sql należało zmienić sprzęt. 

Jaka jest różnica przy aktualizacji "starego" i "nowego". Czas i nakład pracy jest taki sam. Nawet bym twierdził że im młodszy system tym więcej wychodzi aktualizacji. 
A ryzyko awarii zawsze występuje bez względu czy to nowy czy stary serwer, dlatego drugi backupowy sprzęt stoi w pogotowiu.

[Paweł B 20]

14 minut temu, Dariusz Kamiński napisał:

Skoro działało i to całkiem dobrze, to po co zmieniać.  Wiem że 15GB miejsca wolnego na dysku to jest mało. Ale do tej pory wystarczało a wcześniejsze aktualizacje nie zapychały dysku.

To ile urosną logi zależy od ilości i rodzaju wykonanych operacji a chyba oczywistym powinno być, że każda aktualizacja bazy robi coś innego niż poprzednia.

 

A jaki jest wiek sprzętu zapasowego? Bo jak zbliżony...

Edytowane 18 Lutego przez Paweł B

[Daniel Kozłowski 1 171]

16 minut temu, Dariusz Kamiński napisał:

Skoro działało i to całkiem dobrze, to po co zmieniać. 

Co zmieniło w praktyce 64GB pamięci RAM i pełny serwer SQL ? Po co była ta zmiana ? Przy takiej ilości podmiotów, a nawet większej nie zauważyłem problemów na edycji express.

 

18 minut temu, Dariusz Kamiński napisał:

Jaka jest różnica przy aktualizacji "starego" i "nowego". Czas i nakład pracy jest taki sam. Nawet bym twierdził że im młodszy system tym więcej wychodzi aktualizacji. 

Nie poruszamy w tym wątku aktualizacji systemu operacyjnego tylko aktualizację programów InsERT i o tym pisałem, nie odnosiłem się też tylko i wyłącznie do czasu traconego na aktualizacje.

 

12 minut temu, Dariusz Kamiński napisał:

A ryzyko awarii zawsze występuje bez względu czy to nowy czy stary serwer, dlatego drugi backupowy sprzęt stoi w pogotowiu.

Nie napisałem przecież, że nowszy sprzęt wyeliminuje ryzyko awarii tylko je zmniejszy.

[Dariusz Kamiński 0]

15 godzin temu, Paweł B napisał:

To ile urosną logi zależy od ilości i rodzaju wykonanych operacji a chyba oczywistym powinno być, że każda aktualizacja bazy robi coś innego niż poprzednia.

Nie jest problemem, że po konwersji urosły logi tylko to że mimo zaznaczonej opcji "kompaktuj bazę" owo kompaktowanie nie zostało wykonane. Poprzednie aktualizacje nie miały tego problemu.

 

15 godzin temu, Daniel Kozłowski napisał:

Co zmieniło w praktyce 64GB pamięci RAM i pełny serwer SQL ? Po co była ta zmiana ? Przy takiej ilości podmiotów, a nawet większej nie zauważyłem problemów na edycji express.

Na serwerze jest również "duża" baza subiekta stąd pełny SQL

16 godzin temu, Paweł B napisał:

A jaki jest wiek sprzętu zapasowego? Bo jak zbliżony...

Wiek nie ma tutaj znaczenia - jest w pełni kompatybilny, systematycznie włączany i aktualizowany, po to by można było szybko "uruchomić biuro" i ma działać do wymiany lub naprawy głównego serwera co pewnie przy dzisiejszej logistyce nie powinno trwać dłużej niż 7, max 14 dni. 

 

15 godzin temu, Daniel Kozłowski napisał:

nie poruszamy w tym wątku aktualizacji systemu operacyjnego tylko aktualizację programów InsERT i o tym pisałem, nie odnosiłem się też tylko i wyłącznie do czasu traconego na aktualizacje.

Ponawiam pytanie: Jaka jest różnica przy aktualizacji Insert na serwerze "starym" a "nowym".

 

16 godzin temu, Dariusz Kamiński napisał:

Moim zdaniem nie ma czego modernizować, sprzęt o wieku około 10 lat nie powinien być już od kilku lat wykorzystywany w biurze rachunkowym

Jaki wg Was jest optymalny wiek dla serwera pracującego w biurze rachunkowym? Oczywiście pytaniem pomijam dyski.

 

[Daniel Kozłowski 1 171]

10 minut temu, Dariusz Kamiński napisał:

Nie jest problemem, że po konwersji urosły logi tylko to że mimo zaznaczonej opcji "kompaktuj bazę" owo kompaktowanie nie zostało wykonane. Poprzednie aktualizacje nie miały tego problemu.

Najwyraźniej ciągle nie zapoznał się z listą zmian w programie, włącznie z tą cytowaną przeze mnie w tym wątku.

 

10 minut temu, Dariusz Kamiński napisał:

Na serwerze jest również "duża" baza subiekta stąd pełny SQL

Takie to jest właśnie cedzenie istotnych informacji - nie wiadomo z czego wynika rozmiar tej bazy danych, ogólnie skoro to duża baz danych to też może się nie skonwertować ze względu na tak małą ilość miejsca na dysku.

 

12 minut temu, Dariusz Kamiński napisał:

Ponawiam pytanie: Jaka jest różnica przy aktualizacji Insert na serwerze "starym" a "nowym".

Przecież wyjaśniałem to w swojej wypowiedzi, wystarczy przeczytać:

19 godzin temu, Daniel Kozłowski napisał:

Moim zdaniem nie ma czego modernizować, sprzęt o wieku około 10 lat nie powinien być już od kilku lat wykorzystywany w biurze rachunkowym, to strata czasu na aktualizacje i bieżącą pracę oraz większe ryzyko wystąpienia awarii sprzętu, zamiast przesadzać z pamięcią ram i serwerem sql należało zmienić sprzęt.

poza tym ciągle ignoruje Pan inny aspekt:

19 godzin temu, Daniel Kozłowski napisał:

Moim zdaniem nie ma czego modernizować, sprzęt o wieku około 10 lat nie powinien być już od kilku lat wykorzystywany w biurze rachunkowym, to strata czasu na aktualizacje i bieżącą pracę oraz większe ryzyko wystąpienia awarii sprzętu, zamiast przesadzać z pamięcią ram i serwerem sql należało zmienić sprzęt. 

--

15 minut temu, Dariusz Kamiński napisał:

Jaki wg Was jest optymalny wiek dla serwera pracującego w biurze rachunkowym? Oczywiście pytaniem pomijam dyski.

Nic się nie zmieniło "od zawsze" - sprzęt na gwarancji producenta, czyli w praktyce około 5 lat.

 

--

W dniu 17.02.2024 o 18:23, Dariusz Kamiński napisał:

Z góry dziękuję za dyskusję.

Na koniec, gdyż dalsza teoretyczna dyskusja bez poznania specyfikacji sprzętowej, aktualnej wydajności serwera, czasów operacji jak aktualizacja programów, codziennego zakresu i sposobu korzystania z programów przez ich użytkowników - nie ma sensu. To tylko moje sugestie, nie mam potrzeby nikogo do nich przekonywać.

[Dariusz Kamiński 0]

Znalazłem przyczynę błędu więc można uznać temat za zamknięty.

 

[Wojciech Olanin 3]

U Pana przez brak opcji kompaktowania bazy danych rozmiar wzrósł o 15 GB, a u nas przy ponad 1000 podmiotach aż o 300 GB.