Files
DBAdmin/inbox/023-sqlmig-migracja-sql-server-2008-r2-2022-fnksqlserver.md
T
2026-06-15 09:43:36 +00:00

12 KiB
Raw Blame History

title, description, tags, status, timeFrame, collaborators, type
title description tags status timeFrame collaborators type
[023-SQLMIG] Migracja SQL Server 2008 R2 → 2022 (FNKSQLSERVER) null
DNB
SqlServer
migracja
2008R2
Archived null null Project

[023-SQLMIG] Migracja SQL Server 2008 R2 → 2022 (FNKSQLSERVER)

Link do Jira: https://dnbenterprise.atlassian.net/browse/DBEMGT-576

October 22, 2025 Środowisko testowe jest już oddane do zespołu AO

Migracja testowa - niestety nie ma możliwości eksportu danych bazy danych i ich zaimportowanie więc opcja export - do zmigrowania została opcja przy użyciu SQL Server 20214 jako instancja pomiędzy wersjami. - wykonałem backup i restore na instancję SQL Server 2014, a następnie wykonałem backup i restore na instancję 2022 - przewidywany czas migracji produkcyjnej to ~4H

September 24, 2025 -> wczoraj okazało sie, że brałem pod uwagę nie ten serwer co potrzeba więc muszę od nowa zajmować się analizą, dzisiaj mamy spotkanie statusowe to na pewno poinformuję o tym.

Podsumowanie (Summary)

Migracja baz danych z instancji FNKSQLSERVER na serwerze NNE-DGS-SQL05 (SQL Server 2008 R2) na docelowe środowisko nowszego SQL Server. Planowana migracja testowa w przyszłym tygodniu.

Tytuł zadania (Suggested)

Migracja baz z instancji FNKSQLSERVER (NNE-DGS-SQL05, SQL Server 2008 R2) — testowa

Opis (Description)

Na serwerze NNE-DGS-SQL05 działają dwie instancje: default oraz FNKSQLSERVER. Analiza dotyczy instancji FNKSQLSERVER, na której znajdują się bazy:

  • NNDAccessList

  • NNOLoad2

  • NNOCameo2

  • NNSecurity

Dodatkowo należy uwzględnić instancję default, gdzie znajduje się baza:

  • NNSecurity

Istnieją dwie możliwe ścieżki migracji:

  1. Export/import przy użyciu narzędzi typu Data Export (np. Export Data Tier) — bezpośredni transfer obiektów i danych.

  2. Backup/restore — wymaga dodatkowych etapów pośrednich ze względu na bardzo starą wersję serwera:

    • migracja z SQL Server 2008 R2 -> SQL Server 2014

    • następnie z SQL Server 2014 -> SQL Server 2022 (docelowo)

      (backup/restore możliwy do wykonania, ale wymaga etapów pośrednich i testów kompatybilności)

Planuję wykonać migrację testową w przyszłym tygodniu.

Zakres

  • Testowa migracja baz: NNDAccessList, NNOLoad2, NNOCameo2, NNSecurity (FNKSQLSERVER)

  • Weryfikacja dodatkowo bazy NNSecurity na instancji default

  • Testy integralności danych i działania aplikacji zależnych

  • Przygotowanie planu produkcyjnej migracji po wynikach testu

Kroki do wykonania (Proposed steps)

  1. Przygotowanie środowiska testowego (docelowa instancja SQL Server 2022 lub pośrednia 2014 jeśli wybieramy backup/restore).

  2. Wykonanie pełnego backupu wszystkich baz z FNKSQLSERVER (oraz NNSecurity z default) i zabezpieczenie kopii.

  3. Testowa migracja:

    • Opcja A (export/import): wyeksportować schematy i dane, zaimportować do docelowej instancji; zweryfikować logi błędów.

    • Opcja B (backup/restore): przywrócić na SQL 2014 -> przetestować -> następnie przenieść na SQL 2022; sprawdzić kompatybilność i poziomy zgodności (compatibility level).

  4. Weryfikacja integralności danych (CHECKSUM/DBCC), testy funkcjonalne aplikacji, porównanie liczby wierszy/kluczy.

  5. Testy wydajnościowe i sprawdzenie indeksów/statystyk.

  6. Dokumentacja znalezionych problemów i decyzja o metodzie produkcyjnej.

  7. Przygotowanie okna migracji produkcyjnej, plan rollbacku i komunikacja z właścicielami aplikacji.

Wymagane zasoby i uprawnienia (Prerequisites)

  • Dostęp administratorski (backup/restore, import/export) do źródłowego serwera i docelowej instancji.

  • Wolne miejsce dyskowe na kopie zapasowe i na docelowej instancji.

  • Dostęp do SQL Server 2014 (pośredni) jeśli wybieramy backup/restore z etapami migracji.

  • Kontakt i potwierdzenie testów z właścicielami aplikacji/systemów korzystających z baz.

  • Lista loginów i mapowanie kont użytkowników (logins → users).

Ryzyka (Risks)

  • Problemy ze zgodnością funkcji/wersji (np. deprecated features).

  • Potencjalne przerwy w działaniu aplikacji przy migracji produkcyjnej.

  • Niekompatybilne procedury składowane/CLR/agent jobs.

  • Brak miejsca na kopie zapasowe lub problemy z transferem dużych baz.

Kryteria akceptacji (Acceptance criteria)

  • Wszystkie bazy zostały poprawnie przeniesione na środowisko testowe.

  • DBCC CHECKDB bez krytycznych błędów.

  • Aplikacje zależne poprawnie się łączą i przechodzą testy funkcjonalne (lista testów dołączona).

  • Porównanie danych (row counts, kluczowe zapytania kontrolne) nie wykazuje niezgodności.

  • Dokumentacja wyników testu i rekomendacja metody migracji produkcyjnej.

Zależności (Dependencies)

  • Dostęp do środowisk docelowych (SQL 2014/2022).

  • Zgoda właścicieli aplikacji na okno testowe i produkcyjne.

  • Potwierdzenie miejsca na kopie i transferu danych.

Harmonogram

  • Planowana migracja testowa: przyszły tydzień (konkretna data do ustalenia).

  • Czas trwania testu: zależny od rozmiaru baz — przewidywany wstępny czas: kilka godzin na migrację + czas na weryfikację.

Dalsze kroki (Next steps)

  • Ustalenie daty i okna czasowego testu.

  • Przydzielenie odpowiedzialnych (DBA, właściciele aplikacji).

  • Wykonanie backupów pre-migracyjnych i przygotowanie środowiska docelowego.

Jira — gotowe zadanie do wklejenia Tytuł

Migracja testowa baz z instancji FNKSQLSERVER (NNE-DGS-SQL05, SQL Server 2008 R2) — NNDAccessList, NNOLoad2, NNOCameo2, NNSecurity

Opis (description)

Na serwerze NNE-DGS-SQL05 działają dwie instancje:

FNKSQLSERVER (analiza dotyczy tej instancji) — bazy: NNDAccessList, NNOLoad2, NNOCameo2, NNSecurity default — baza: NNSecurity

Celem zadania jest wykonanie testowej migracji powyższych baz na docelowe środowisko (SQL Server 2022), weryfikacja poprawności danych i działania aplikacji oraz wypracowanie końcowego planu migracji produkcyjnej.

Wybrane opcje migracji:

Opcja A — export/import (narzędzia typu Data Export / Export Data Tier) — bezpośredni transfer schematów i danych. Opcja B — backup/restore z etapami pośrednimi (2008 R2 -> 2014 -> 2022) — wymaga przywrócenia na SQL 2014, a następnie migracji na SQL 2022.

Planowana migracja testowa: proponowany termin — wtorek 23.09.2025, 02:0006:00 CET (do potwierdzenia).

Priorytet

Wysoki — wersja źródłowa 2008 R2 jest przestarzała.

Acceptance criteria Bazy NNDAccessList, NNOLoad2, NNOCameo2, NNSecurity (FNKSQLSERVER) przeniesione do środowiska testowego. NNSecurity z instancji default uwzględniona/weryfikowana. DBCC CHECKDB wykonane i brak krytycznych błędów. Aplikacje zależne łączą się i przechodzą zestaw krytycznych testów funkcjonalnych. Row counts i kluczowe zapytania porównawcze nie wykazują niezgodności. Dokumentacja wyników testu oraz rekomendacja metody produkcyjnej (Export/import vs Backup/Restore). Subtasks / checklist (do wklejenia jako checklist / sub-tasky)

Przygotowanie (owner: DBA) — est. 4h

Potwierdzenie okna testowego z właścicielami aplikacji Przydzielenie uprawnień admina do źródłowego i docelowego serwera Rezerwacja miejsca na dysku na kopie zapasowe Przygotowanie listy loginów i mapowania (spis logins → users)

Backup / Export (owner: DBA) — est. 2-3h

Wykonanie pełnych backupów (FULL) wszystkich baz z FNKSQLSERVER Archiwizacja kopii zapasowych (test restore będzie wykonywany na środowisku testowym) (jeśli export/import) Wygenerowanie skryptów schema + data export

Przygotowanie środowiska testowego (owner: Infra/DBA) — est. 2h

Utworzenie instancji docelowej (SQL Server 2022) lub instancji pośredniej (SQL 2014) jeśli będzie backup/restore Przygotowanie kont, uprawnień, przestrzeni dyskowej

Testowa migracja (owner: DBA) — est. 4-6h

Opcja A: export/import — zaimportować schematy, dane; sprawdzić błędy importu Opcja B: backup/restore — przywrócić na SQL 2014 → przetestować → przywrócić / podnieść do SQL 2022 Wykonać DBCC CHECKDB na każdej przywróconej bazie Zaktualizować compatibility level (jeśli wymagane) i przetestować

Weryfikacja danych i testy aplikacyjne (owner: Tester / Właściciel aplikacji) — est. 4h

Porównanie liczby wierszy (SELECT COUNT(*) dla tabel krytycznych) Uruchomienie kluczowych zapytań/reportów i porównanie wyników Integracyjne testy aplikacji (logowanie, kluczowe funkcje)

Weryfikacja logins / permissions (owner: DBA) — est. 1h

Odtworzenie loginów i mapowanie użytkowników (sp_help_revlogin lub ręczne) Test połączeń aplikacji pod odpowiednimi kontami

Optymalizacja po migracji (owner: DBA) — est. 2h

Rebuild/ Reorganize indeksów jeśli potrzebne Update statistics Sprawdzenie planów zapytań (opcjonalnie)

Dokumentacja i rekomendacja (owner: DBA + Właściciel aplikacji) — est. 2h

Spis napotkanych problemów i rozwiązań Rekomendacja metody migracji produkcyjnej Gotowy plan produkcyjny (okno, rollback, lista odpowiedzialnych)

Komunikacja (owner: Project Manager) — est. 0.5h

Powiadomienie zainteresowanych o terminie testu, ryzykach i czasie przestoju (jeśli dotyczy) Kryteria testów (smoke tests) Połączenie do bazy: SELECT 1 DBCC CHECKDB('<db_name>') Porównanie row counts: SELECT COUNT(*) FROM <kluczowa_tabela> Uruchomienie 5 najważniejszych raportów / procesów batch Test logowania aplikacji i podstawowych funkcji (login, zapis danych, odczyt)

Przykładowe zapytania:

CHECKDB: DBCC CHECKDB('NNDAccessList') WITH NO_INFOMSGS; Row count: SELECT COUNT(*) AS cnt FROM dbo.; Przydatne skrypty / komendy (do wykonania przez DBA) Backup: BACKUP DATABASE [NNDAccessList] TO DISK = N'\backup\NNDAccessList_FULL.bak' WITH INIT, COPY_ONLY; Restore: RESTORE DATABASE [NNDAccessList] FROM DISK = N'\backup\NNDAccessList_FULL.bak' WITH MOVE 'NNDAccessList_Data' TO 'D:\MSSQL\Data\NNDAccessList.mdf', MOVE 'NNDAccessList_Log' TO 'L:\MSSQL\Log\NNDAccessList.ldf', RECOVERY; Sprawdzenie compatibility level: SELECT name, compatibility_level FROM sys.databases WHERE name = 'NNDAccessList'; Skrypt do przeniesienia logins (sp_help_revlogin) — skrypt Microsoft (uruchomić na źródle, skopiować wynik na docelowy serwer).

(Uwaga: nazwy plików MDF/LDF i logical names sprawdzić w RESTORE FILELISTONLY)

Ryzyka i mitigacje (skrót) Brak zgodności funkcji między 2008 R2 a 2022 — testować wszystkie procedury składowane i funkcje; przy identyfikacji problemów przygotować zmiany. Duże bazy → czas migracji dłuższy — przygotować szybkie łącze/diski i testować przepustowość. Loginy/rozbieżności SID → użyć sp_help_revlogin lub ręczne mapowanie. Brak miejsca na kopie — zabezpieczyć miejsce przed migracją. Zasoby / wymagane uprawnienia DBA (wykonanie backup/restore lub export/import) Administrator środowiska (przydzielenie instancji SQL Server 2022/2014) Właściciel aplikacji / tester do testów funkcjonalnych Dostęp admina do źródłowego serwera (NNE-DGS-SQL05) i docelowego Proponowany harmonogram (szczegóły) Dzień -3 (przygotowanie): uzgodnienie okna, przydzielenie uprawnień, backupy pre-migracyjne Dzień 0 (test migration): wtorek 23.09.2025, 02:0006:00 CET — migracja testowa, DBCC, pierwszy cykl testów Dzień 0+1 (weryfikacja): dzień pracy — testy aplikacyjne i raportowanie wyników Dzień 2 (dokumentacja): finalne raporty, decyzja o metodzie produkcyjnej

Jeśli chcesz, mogę:

przygotować checklistę w formacie, który bezpośrednio wklei się do JIRA (np. lista subtasków z opisami), wygenerować gotowe subtasks (tytuł + opis + estimate + przypisanie placeholder) w formie tekstu do wklejenia, zarezerwować proponowany termin lub zmienić datę — podaj preferowane dni/godziny i osoby odpowiedzialne.