W ostatni weekend przeprowadzałem migrację produkcyjnej bazy (RAC one Node, rozmiar około 63TB) do wersji 19c (19.9.0.0.201020). Ach cóż to był za weekend. Z racji procesów, które za dnia powinny otrzymywać odpowiedź z tejże bazy, czas startu zaplanowałem na godzinę 22:00.
Tego dnia wcześniej, zgodnie z zaleceniami przy każdej migracji zebrałem statystyki słowników, oczyściłem kosz (recyclebin), zweryfikowałem liczbę i ilość obiektów w statusie invalid. Zweryfikowałem również czy baza standby jest zsynchronizowana, oraz – czy mam dostępny aktualny backup (lub dwa wstecz). Korzystnie jest zabezpieczyć gdzieś zapisy audit log i usunąć je przed migracją – znacznie powinno to skrócić czas migracji. Może tylko zdarzyć się psikus gdy korzystasz z danych audytu, aby np. blokować konta osób nielogujących się od pewnego czasu, lub raportujesz z audytu jakieś określone czynności – rozważ czy po usunięciu wpisów będziesz potrafił zapewnić ciągłość procesu.
Pierwszą czynnością po upewnieniu się, że aplikacje zostały wyłączone i dr zsynchronizowany – było wyłączenie replikacji redo i archivelogów z primary do standby, wyłączenie konfiguracji i wyłączenie bazy standby (gdybym tego nie zrobił – alert.log zawierałby masę błędów z transportu archów z primary).
dgmgrl /
edit database <primarydbname> set state = 'TRANSPORT-OFF';
edit database <standbydbname> set state = 'APPLY-OFF';Dalej – zrestartowałem bazę primary a przedtem wykluczyłem z niej dwa parametry, jakie były potrzebne dla konfiguracji DR – są one problemem dla narzędzia autoupgrade.jar (nie potrafi z nimi wykonać restartu bazy w fazie prefixup)
alter system set local_listener = '';
alter system set listener_networks = '';Później uruchomiłem narzędzie:
java -jar autoupgrade.jar -config config.cfg -mode deploydokumentacja autoupgrade.jar
deploy to opcja która najpierw analizuje, potem robi fixup przed migracją, potem robi migrację i na koniec kilka czynności postupgrade. Cwane narzędzie – lecz nie bez wad.
Narzędzie gdy przychodzi do migracji bazy w rac (u mnie rac one node) – najpierw konwertuje ją do standalone, później migruje, a na koniec z powrotem konwertuje bazę do rac.
Proces upgrade trwał u mnie 2h 30 min – z tego najdłuższa część to był upgrade timezony – 2x 40 minut czekania, bez żadnych wpisów do logu, tylko wpis na konsoli upg> że proces od 20 minut nie daje znaku życia. No jest stresik.
I to nie jest tak że trwał tyle, bo statystyki słownikowe długo się liczyły w procesie – nie – policzone świeżo przed upgradem.
Po zakończeniu działania narzędzia – a zatem po upgrade mówię – sprawdzam: czy moja baza jest bazą rac one node – czyli sprawdźmy, czy zrelokuje się na drugi node.
srvctl relocate database -db orcl -node node2 -timeout 5i co? i nic. Wisi. Nie 5 minut, nie 10. Przerwałem.
Co jest?
inna opcja – wyłączyłem bazę na node1 i sprawdzę czy włączę ją na node 2 z node1
srvctl start database -db orcl -node node2Włączyła się – ale – uwaga – z sid=orcl1 – tak jak ta na node1.
Przyznam się – trochę spanikowałem – jest już godzina 1 w nocy – ja nie wiem o co chodzi – może ta wersja na mój os ma bug dot klastra? Drązymy dalej.
porównuję parametry przed migracją – z bazy 12.1 z tymi jakie mam na bazie 19c – i co widać? proces konwersji autoupgrade.jar – zgubił wytłuszczone parametry, jakie dodać trzeba gdy masz bazę pracującą w klastrze.
orcl1.instance_number=1
orcl2.instance_number=2
orcl1.log_archive_format="%t_%s_%r.dbf"
orcl2.log_archive_format="%t_%s_%r.dbf"
orcl1.log_archive_trace=0
orcl2.log_archive_trace=0
orcl1.thread=1
orcl2.thread=2
orcl1.undo_tablespace=undo1
orcl2.undo_tablespace=undo2
Rada – nie ufać narzędziu – jest spoko – o wielu rzeczach pamięta za Ciebie – ale przed migracją spróbuj zrobić upgrade bazy w możliwie podobnej konfiguracji.
Kolejnym krokiem była migracja standby.
Zakładam, że nowy oracle home masz już założony – dobrze jest mieć spójną wszędzie lokalizację, taką samą na wszystkich hostach – ja stosuję/u01/app/<oracle-soft-owner>/product/<wersja w formie x.x.x.x_psu>
Zmień w /etc/oratab (lub /var/opt/oracle/oratab zależnie od wersji systemu operacyjnego) ścieżkę do nowego oracle home na wszystkich hostach standby
Zmień w konfiguracji listenera wpisy statyczne – nowy oracle home we wpisach dot bazy standby na wszystkich hostach standby
skopiuj spfile z primary – lub utwórz z primary pfile, skopiuj na standby site, zweryfikuj sga (czy dr uciągnie), zweryfikuj ścieżki controlfile – standby może je mieć inaczej, passwordfile z primary (choć akurat ten drugi się nie zmienia w trakcie migracji).
zapisz sobie ustawienia serwisu – usuń serwis bazy wersji 12, utwórz taki sam w wersji 19 binariów.
wystartuj serwisem bazę standby
na primary ponów transport logów, na standby ich aplikację:
dgmgrl /
edit database <primarydbname> set state = 'TRANSPORT-ON';
edit database <standbydbname> set state = 'APPLY-ON';I tyle – u mnie działa…
W moim upgrade przestawienie parametru compatible na 19 zostawiłem sobie na kolejny termin.