TL;DR – co najczęściej ratuje sytuację

• Backup/restore zamiast kopiowania plików (to najbezpieczniejszy standard).
• Test odtworzenia kopii – backup, którego nie da się odtworzyć, to „ładny plik”, nie zabezpieczenie.
• Zgodność wersji SQL – nie przywrócisz bazy z nowszego SQL na starszy.
• Loginy i mapowanie użytkowników – po migracji często „działa serwer, nie działa aplikacja”.
• CHECKDB i plan naprawy – jeśli baza jest uszkodzona, najpierw diagnoza, potem decyzja: restore vs repair.

1) Migracja to nie „kopiuj–wklej”: 3 poprawne metody przeniesienia bazy

A. Backup + Restore (zalecane)

Najbezpieczniejsza metoda. Daje kontrolę, weryfikację i przewidywalny proces. Pozwala też łatwiej przenieść bazę między serwerami, podmienić ścieżki plików i wykryć problemy na etapie odtwarzania.

B. Detach/Attach (MDF/LDF)

Szybkie, ale bardziej ryzykowne. Działa dobrze, gdy: masz komplet plików (MDF + LDF), wiesz co robisz i kontrolujesz uprawnienia/ścieżki. Częsty problem po attach: brak loginów lub uprawnień.

C. Kopiowanie plików „na żywca”

Najgorszy nawyk. Jeśli kopiujesz MDF/LDF bez poprawnego zatrzymania usług i kontroli transakcji, prosisz się o kłopoty (niespójność, recovery, błędy logu). Jeśli już – to wyłącznie świadomie i w kontrolowanych warunkach.

2) Zgodność wersji SQL – pułapka numer 1

W SQL Server działa zasada: z nowszej wersji przywrócisz na nowszą lub taką samą, ale nie na starszą. Przykład: backup z SQL 2019 nie wstanie na SQL 2017.

Jeśli migrujesz środowisko, upewnij się, że docelowy SQL jest co najmniej tej samej generacji i ma aktualne poprawki.

3) Loginy, uprawnienia i „działa baza, nie działa aplikacja”

Po odtworzeniu bazy bardzo często problemem nie jest baza, tylko warstwa uwierzytelniania: loginy na SQL są serwerowe, a użytkownicy w bazie są bazodanowi. Po migracji SID-y potrafią się rozjechać.

• Objaw: aplikacja nie może się zalogować / brak uprawnień / błędy zapisu.
• Rozwiązanie: mapowanie użytkowników do loginów, weryfikacja ról, czasem odtworzenie loginów i haseł.

4) Archiwalne bazy danych – jak przechowywać mądrze

Archiwum to nie „baza rzucona na stary komputer”. Dobre podejście:

• osobna instancja SQL (lub osobny serwer) pod archiwa,
• odczytowy dostęp (read-only),
• backup archiwów i procedura „jak to odtwarzamy, gdy dysk padnie”,
• nie mieszanie archiwów z produkcją (mniej ryzyka, mniej pomyłek).

To szczególnie ważne, gdy archiwum jest potrzebne do kontroli, korekt lub wyjaśnień „sprzed lat”.

5) Awarie i uszkodzenia: SUSPECT / RECOVERY PENDING / błędy zapisu

Najczęstsze powody problemów z bazą: awaria zasilania, twardy restart serwera, błędy dysku, brak miejsca na dysku, przerwane aktualizacje, antywirus blokujący pliki bazy, problemy z kontrolerem/RAID.

Co robię najpierw (zanim „naprawiam”)

1. Sprawdzam logi SQL i stan dysku (SMART / event log / miejsce na dysku).
2. Wykonuję kopię „na zimno” (jeśli to możliwe) – żeby nie pogorszyć sytuacji.
3. Uruchamiam diagnostykę spójności (CHECKDB) i analizuję zakres uszkodzeń.
4. Dopiero potem decyzja: restore z backupu vs naprawa (repair) vs odzysk selektywny.

Ważne: „Naprawa” w SQL bywa operacją, która usuwa uszkodzone fragmenty danych. Dlatego w środowiskach biznesowych najczęściej bezpieczniej jest odtworzyć z poprawnego backupu.

6) Wydajność: kiedy „system zwolnił”, a winna jest baza

Typowe powody spowolnień w SQL:

• brak maintenance (indeksy, statystyki),
• zbyt mało RAM lub źle ustawione limity pamięci SQL,
• wolny dysk (IO) / brak SSD / przeciążony storage,
• autogrowth ustawiony źle (np. małe przyrosty),
• blokady i długie transakcje,
• zbyt mały tempdb lub nieoptymalne ustawienia.

Zwykle da się to poprawić bez rewolucji: diagnoza, kilka zmian w konfiguracji i porządek w utrzymaniu.

7) Jak przygotować się do migracji – lista dla IT (i mniej zaawansowanych informatyków)

• Wersja SQL (źródłowa i docelowa) + tryb uwierzytelniania.
• Wielkość bazy (MDF/LDF) i wolne miejsce na dysku.
• Model recovery (SIMPLE/FULL) i strategia backupów.
• Lista loginów/użytkowników (kto i jak się łączy).
• Okno serwisowe (kiedy można zrobić przerwę).
• Plan testów po migracji (logowanie, dokumenty, raporty, archiwum).

8) Pomoc praktyczna – kiedy warto zadzwonić

Jeśli masz którykolwiek z tematów: migracja, przeniesienie na nowy serwer, archiwa, odzyskiwanie po awarii, naprawa bazy, spowolnienia – da się to ogarnąć, tylko trzeba zacząć od diagnozy.

Żeby przyspieszyć rozmowę, przygotuj 3 informacje: co chcesz osiągnąć (np. „przenieść”, „uratować”), jakie środowisko SQL oraz jaki jest objaw/błąd (1–2 zdania lub screen komunikatu).

Kontakt: Piotr Zając
Telefon: 535 505 359

PS. Nie ma dla mnie „nie da się”. Są tylko: diagnoza, plan i działanie.