Raport Specjalny – IT@BANK 2023 | Technologie – APEX.IT | Pięć dni w pięć godzin

Raport Specjalny – IT@BANK 2023 | Technologie – APEX.IT | Pięć dni w pięć godzin
Udostępnij Ikona facebook Ikona LinkedIn Ikona twitter
Ogromna baza danych, zawierająca ponad 100 TB danych, czeka na replikację. Licznik obiektów ID w bazie danych jest przepełniony. Przy okazji wykonywania replikacji, pion IT chce również uporządkować struktury i odbudować indeksy. Cały proces nie może zająć więcej niż pięć godzin, a tradycyjne metody, nawet przy wykorzystaniu dysków krzemowych i sieci 10 GB Fibre Channel, oznaczają czas nie krótszy niż pięć dni. Co robić?

Jak do tego scenariusza podeszła firma DBPlus, opowiada Przemek, Software Manager w DBPlus. – Dostaliśmy telefon od CTO banku – ich system wymagał migracji bazy danych z powodu przepełnionych wewnętrznych liczników zdarzeń. Nie byłoby w tym nic niezwykłego, gdyby nie to, że na cały proces nie mogli poświęcić więcej niż 5 godzin! Dlatego, że w ciągu 28 lat naszej działalności, nieraz ścieraliśmy się z zadaniami o podobnej skali, zdecydowaliśmy się zrobić wszystko, co w naszej mocy, żeby sprostać wymaganiom klienta.

Na samym początku, nasz klient zajął się stworzeniem bazy danych, zgodnej z ich bazą produkcyjną, zadbał o optymalizację połączenia sieciowego między bazami danych (w tym przypadku nie było potrzeby wprowadzania żadnych zmian w infrastrukturze), oraz zapewnił możliwie jak najbardziej niezależną przestrzeń dla plików ARCHIVE_LOG bazy źródłowej.

Kluczowym elementem całego procesu była instalacja DBPlus Replikator na dedykowanym serwerze. Gdyby nie to narzędzie, cała operacja mogłaby rozbić się o liczne przeszkody, takie jak niekompatybilność systemów, błędy synchronizacji, problemy z transferem dużej ilości danych czy potencjalne konflikty wersji baz danych. Wprowadziłoby to dodatkowe komplikacje i co ważniejsze – spowolniłyby cały proces.

Używając swojego narzędzia, byliśmy w stanie zapewnić nieprzerwane działanie systemu podczas synchronizacji 99% danych i obiektów. Potrzebowaliśmy jedynie pięciogodzinnego okna serwisowego, które pozwoliłoby nam na replikację finalnego 1%.

Replikacja ponad 100 tabel, składających się na imponujące 99% całkowitej objętości danych, rozpoczęła się dwa tygodnie przed finalną migracją, nie miała jednak łatwego startu. Już na samym początku pojawiło się blisko pięciodniowe opóźnienie, wynikające z konieczności stworzenia kopii zapasowej i odtworzenia bazy na nowym serwerze.

Mimo początkowych trudności, w ciągu trzech dni opóźnienie zostało zniwelowane. Replikacja, początkowo opóźniona o kilka dni, zaczęła funkcjonować z minimalnymi opóźnieniami w zakresie od kilkuset milisekund do kilku minut. Ten stan utrzymywał się przez kolejne półtora tygodnia, aż do dnia ostatecznej migracji.

Nie obyło się oczywiście bez wyzwań. Jednym z problemów, z którym przyszło nam się zmierzyć, był brak unikalnych kluczy w niektórych tabelach. Unikalne klucze są niezbędne do prawidłowej replikacji tabel, więc musieliśmy znaleźć sposób, by je zaimplementować. Tutaj niezastąpieni pracownicy banku znowu wykazali się inicjatywą, dodając do tych tabel specjalne kolumny, które symulowały klucz główny. Dzięki kolumnie z sztuczną wartością numeryczną, generowaną przez triger „before insert”, zapewniliśmy spójność przenoszonych danych.

Jednak to nie były jedyne wyzwania, przed którymi stanęliśmy. W trakcie migracji zauważyliśmy, że optymalizator Oracle nie zawsze wybierał najbardziej efektywny plan działania. W efekcie musieliśmy poświęcić dodatkowy czas na optymalizację zapytań na bazie docelowej. Niekiedy wpłynęło to nawet na prędkość replikacji.

Kiedy 99% danych i obiektów było już zsynchronizowane, przyszedł czas na bardziej techniczne aspekty. Klient sam zajął się kopiowaniem binariów, tworzeniem nowych indeksów i szeregiem modyfikacji, w tym zmianą SID.

Ostatecznym krokiem było ustalenie z działem biznesowym okna czasowego na replikację pozostałego 1% danych. Po dograniu do bazy danych pozostałych tabel i obiektów, to właśnie wtedy, po niecałych pięciu godzinach, dokonało się końcowe przełączenie użytkowników na nową bazę.

Cały proces replikacji, mimo swojej złożoności, przebiegł sprawnie. Oczywiście, za każdym krokiem stały godziny testowania, zarówno pod kątem funkcjonalności aplikacji, jak i wydajności całego środowiska. Dzięki temu, mogliśmy być pewni, że każdy etap został wykonany prawidłowo, a ryzyko ewentualnych błędów zostało zminimalizowane. W retrospekcji, ten projekt stał się dla nas dowodem na to, że z odpowiednim podejściem i narzędziami, a przede wszystkim sprawną współpracą, nawet najbardziej skomplikowane zadania stają się osiągalne.

Źródło: Miesięcznik Finansowy BANK