Audyt bazy znalazł 165 GB balastu (39%) bez zatrzymywania pracy.
Bazy danych i SQLBól klienta
Baza robocza 1C na MS SQL Server (13 filii) urosła do 418 GB. Dyski się kończą, kopie zapasowe trwają godzinami, wszystko wyraźnie zwalnia. Standardowa rada od IT: „kupcie mocniejszy serwer”. Przy tym nikt nie mógł powiedzieć, co dokładnie zajmuje miejsce — baza wygląda jak czarna skrzynka z tysiącem tabel systemowych.
Co zrobiono
Zdalna diagnostyka tylko do odczytu w godzinach pracy z zerowym przestojem — na infrastrukturze legacy (Windows Server 2008 R2 / SQL Server 2014), gdzie nowoczesne narzędzia po prostu się nie uruchamiają
Skrypty PowerShell do inwentaryzacji po katalogach systemowych SQL Server: dokładny rozmiar, liczba wierszy i profil wzrostu każdej grupy tabel
Krypticzne wewnętrzne nazwy tabel 1C zestawione z biznesowym sensem — w raporcie napisano „historia wersji obiektów”, a nie „_ConfigVersions”
Każdy pożeracz miejsca sklasyfikowany: bezpiecznie czyścić / usunąć z bazy / pozostawić i zoptymalizować
Wynik
165 GB — 39% bazy — można zwolnić, nie tracąc żadnego dokumentu:
109 GB przestarzałych wersji obiektów (+ polityka przechowywania, aby nie rosły znowu)
38 GB martwych kolejek rejestracji zmian od dawno usuniętych węzłów wymiany
16 GB załączonych plików, którym miejsce na woluminie plików, a nie w bazie
Znaleziono główny dźwignię wydajności: podsumowania rejestrów ważą 3,3 razy więcej niż same ruchy — plan przerejestrowania zmniejsza zarówno rozmiar, jak i czas zapytań
Wydano: pełną inwentaryzację CSV + priorytetowy krokowy plan czyszczenia
Zakup nowego serwera odwołany
Stos
PowerShell · T-SQL (DMV, katalogi systemowe) · MS SQL Server · wnętrza 1C · konto tylko do odczytu
Baza robocza 1C na MS SQL Server (13 filii) urosła do 418 GB. Dyski się kończą, kopie zapasowe trwają godzinami, wszystko wyraźnie zwalnia. Standardowa rada od IT: „kupcie mocniejszy serwer”. Przy tym nikt nie mógł powiedzieć, co dokładnie zajmuje miejsce — baza wygląda jak czarna skrzynka z tysiącem tabel systemowych.
Co zrobiono
Zdalna diagnostyka tylko do odczytu w godzinach pracy z zerowym przestojem — na infrastrukturze legacy (Windows Server 2008 R2 / SQL Server 2014), gdzie nowoczesne narzędzia po prostu się nie uruchamiają
Skrypty PowerShell do inwentaryzacji po katalogach systemowych SQL Server: dokładny rozmiar, liczba wierszy i profil wzrostu każdej grupy tabel
Krypticzne wewnętrzne nazwy tabel 1C zestawione z biznesowym sensem — w raporcie napisano „historia wersji obiektów”, a nie „_ConfigVersions”
Każdy pożeracz miejsca sklasyfikowany: bezpiecznie czyścić / usunąć z bazy / pozostawić i zoptymalizować
Wynik
165 GB — 39% bazy — można zwolnić, nie tracąc żadnego dokumentu:
109 GB przestarzałych wersji obiektów (+ polityka przechowywania, aby nie rosły znowu)
38 GB martwych kolejek rejestracji zmian od dawno usuniętych węzłów wymiany
16 GB załączonych plików, którym miejsce na woluminie plików, a nie w bazie
Znaleziono główny dźwignię wydajności: podsumowania rejestrów ważą 3,3 razy więcej niż same ruchy — plan przerejestrowania zmniejsza zarówno rozmiar, jak i czas zapytań
Wydano: pełną inwentaryzację CSV + priorytetowy krokowy plan czyszczenia
Zakup nowego serwera odwołany
Stos
PowerShell · T-SQL (DMV, katalogi systemowe) · MS SQL Server · wnętrza 1C · konto tylko do odczytu