Jestem w trakcie wymiany sprzętu dla istniejącego 3-węzłowego klastra RAC. Ten system jest również podstawową dla 2-węzłowej rezerwowej bazy danych RAC. Aby wymienić sprzęt, planuję tymczasowo rozszerzyć klaster do konfiguracji 6-węzłowej, 3 stare serwery i 3 nowe serwery. Gdy już uruchomię instancje na nowym sprzęcie i moje aplikacje będą się z nimi łączyć, usunę stare instancje i wycofuję stare serwery, powracając do konfiguracji z trzema węzłami.
Po rozszerzeniu klastra na wszystkie sześć węzłów, w miniony weekend uruchomiłem nowe instancje na nowych węzłach. Aby ułatwić sobie życie, po prostu wykorzystałem DBCA do tej pracy. Po odpaleniu DBCA wybrałem pracę na bazie danych RAC, a następnie wybrałem Instance Management, a następnie Add New Instance. Przechodząc przez kreatora pozwoliłem DBCA zająć się za mnie wszystkimi szczegółami. Brzmi prosto.
Dziś rano dostałem swój zwykły raport o lagach w archiwum. Wygląda podobnie do następującego:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Wysyłam to do mojej skrzynki odbiorczej dwa razy dziennie. Szybki rzut oka pomaga mi określić, czy moja rezerwa odbiera i stosuje transakcje z bazy. We wszystkich moich rezerwowych bazach danych ustawiłem czterogodzinne opóźnienie. A moja podstawowa ma ARCHIVE_LAG_TARGET ustawioną na jedną godzinę. Oznacza to, że opóźnienie zastosowania wyniesie co najmniej 4 godziny, ale nie powinno przekraczać 5 godzin. Jak widać powyżej, mamy dwie rezerwowe bazy danych, które znacznie przekroczyły maksymalne 5-godzinne opóźnienie stosowania. Powyżej mam tryb gotowości z opóźnieniem 1 dzień i 21 godzin! Więc od razu wiedziałem, że coś jest nie tak. I nie trzeba było naukowca rakietowego, by wiedzieć, że dodanie nowej instancji do pierwotnej prawdopodobnie przyczyniło się do problemu.
Jak powiedziałem na początku tego postu, mam 2-węzłowy system gotowości RAC. Jedna instancja to „instancja aplikacji”, a druga instancja jest tam stosunkowo bezczynna. W moim dzienniku alertów wystąpienia aplikacji zobaczyłem następujące komunikaty o błędach:
Sat Dec 01 14:25:40 2012
Recovery created file /u01/app/oracle/oradata/orcl/data04/undotbs04.dbf
Successfully added datafile 342 to media recovery
Datafile #342: '/u01/app/oracle/oradata/orcl/data04/undotbs04.dbf'
No OMF destination specified, unable to create logs
Errors with log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
MRP0: Background Media Recovery terminated with error 1264
Errors in file /u01/app/oracle/diag/rdbms/orcs/orcs2/trace/orcs2_pr00_29759.trc:
ORA-01264: Unable to create logfile file name
Recovery interrupted!
Sat Dec 01 14:25:51 2012
Recovered data files to a consistent state at change 192271576009
Sat Dec 01 14:25:51 2012
MRP0: Background Media Recovery process shutdown (orcs2)
Ponieważ moja rezerwowa baza danych jest ustawiona na STANDBY_FILE_MANAGEMENT=AUTO, pierwsza część wiadomości ma sens. Kiedy dodajesz nową instancję do bazy danych RAC, musisz zapewnić przestrzeń tabel Undo tylko dla tej instancji, a także musisz podać grupy dzienników ponownego wykonania online dedykowane dla wątku tej instancji. DBCA specjalnie zadało mi pytania dotyczące struktur plików cofania i ponawiania. W powyższej zawartości dziennika alertów widzimy, że tryb gotowości pomyślnie dodał plik danych 342, który jest moim obszarem tabel Cofnij. Ale stan gotowości nie był w stanie dodać dzienników przeróbek online. Jeśli chcesz, aby standby mógł automatycznie dodawać logi przeróbek online, musisz określić parametry OMF, czego niechętnie robię. Ponieważ dodanie pliku dziennika ponownego wykonywania w trybie online spowodowało błąd, tryb gotowości wstrzymał odzyskiwanie nośnika. Tryb gotowości nadal odbiera logi.
Nie znalazłem zbyt wiele na Metalink ani przez wyszukiwanie w Google, jak rozwiązać ten problem, ale oto kroki, które podjąłem, aby przywrócić i uruchomić Media Recovery. W rezerwowej bazie danych (zrobiłem to na instancji aplikacyjnej, ale powinno być możliwe na każdej instancji w rezerwowej bazie danych RAC):
1. alter database recover managed standby database cancel;
alter database recover managed standby database cancel
*
ERROR at line 1:
ORA-16136: Managed Standby Recovery not active
Nie powinno to być szokiem, ponieważ wiemy, że zarządzane odzyskiwanie zostało przerwane. Ale dla kompletności zawarłem ten krok. Jeśli musisz dodać dzienniki ponawiania do stanu gotowości, który aktualnie stosuje transakcje, będziesz potrzebować tego kroku.
2. alter system set standby_file_management='MANUAL' scope=memory;
System altered.
3. alter database add logfile thread 4 group 40 '/u01/app/oracle/oradata/orcl/redo01/redo40.log' size 536871424;
Database altered.
Powyższe jest dokładnie tym, co zostało uruchomione na podstawowym. Musisz dodać dziennik ponawiania w trybie gotowości dokładnie tak, jak w przypadku podstawowym. Powtórz tę czynność dla każdej grupy dzienników ponawiania dodanej na podstawowej. Ponieważ dodałem 3 instancje do mojej podstawowej bazy danych RAC, muszę dodać tutaj trzy wątki.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Rozpocznij zarządzane odzyskiwanie. Wszystko powinno być teraz w porządku i możemy zweryfikować w dzienniku alertów instancji Apply:
alter database recover managed standby database disconnect from session
Attempt to start background Managed Standby Recovery process (orcs2)
Mon Dec 03 13:32:38 2012
MRP0 started with pid=47, OS id=13232
MRP0: Background Managed Standby Recovery process started (orcs2)
started logmerger process
Mon Dec 03 13:32:44 2012
Managed Standby Recovery not using Real Time Apply
Mon Dec 03 13:32:49 2012
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Mon Dec 03 13:32:49 2012
Completed: alter database recover managed standby database disconnect from session
Mon Dec 03 13:32:50 2012
Media Recovery Log /u01/app/oracle/admin/orcs/arch/1_87840_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/2_88542_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/3_89914_677462342.dbf
Media Recovery Log /u01/app/oracle/admin/orcs/arch/4_1_677462342.dbf
Możemy również sprawdzić, czy opóźnienie w stosowaniu jest coraz krótsze. W trybie gotowości wydaj następujące:
select i.instance_name,d.value as apply_lag,
to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') as curr_time
from v$instance i,v$dataguard_stats d
where d.name='apply lag';
Aby uzyskać dodatkowe informacje na temat zarządzania dziennikami ponawiania online dla bazy danych fizycznego trybu gotowości, zobacz notatkę Metalink 740675.1 Dzienniki ponawiania online w trybie gotowości.
