Právě probíhá výměna hardwaru pro stávající 3uzlový cluster RAC. Tento systém je také primární pro 2uzlovou pohotovostní databázi RAC. Pro výměnu hardwaru mám v plánu dočasně rozšířit cluster na konfiguraci 6 uzlů, 3 staré servery a 3 nové servery. Jakmile budu mít instance spuštěné na novém hardwaru a mé aplikace se připojí k novým instancím, odstraním staré instance a vyřadím staré servery a vrátím se ke konfiguraci se 3 uzly.
Po rozšíření clusteru na všech šest uzlů jsem minulý víkend spustil nové instance na nových uzlech. Abych si usnadnil život, právě jsem pro tuto práci využil DBCA. Po spuštění DBCA jsem se rozhodl pracovat na databázi RAC a poté jsem zvolil Instance Management a poté Přidat novou instanci. Když jsem procházel průvodcem, nechal jsem DBCA, aby se za mě postarala o všechny detaily. Zní to jednoduše.
Dnes ráno jsem dostal svou obvyklou archivní zprávu o zpoždění. Vypadá podobně jako následující:
INSTANCE_NAME APPLY_LAG CURR_TIME
---------------- -------------------- -------------------
orcs1 +01 21:40:47 2012-12-03 08:00:01
Posílám to do mé schránky dvakrát denně. Rychlý pohled mi pomůže určit, zda můj pohotovostní režim přijímá a aplikuje transakce z primárního. Nastavil jsem všechny své pohotovostní databáze na čtyřhodinové zpoždění aplikace. A můj primární má ARCHIVE_LAG_TARGET nastavený na jednu hodinu. To znamená, že zpoždění aplikace bude nejméně 4 hodiny, ale nemělo by být delší než 5 hodin. Jak vidíme výše, máme dvě pohotovostní databáze, které výrazně překročily maximální 5hodinové zpoždění aplikace. Nahoře mám pohotovostní režim se zpožděním aplikace 1 den 21 hodin! Takže jsem hned věděl, že je něco špatně. A nebylo třeba raketového vědce, aby věděl, že přidání nové instance do primární pravděpodobně přispělo k problému.
Jak jsem řekl na začátku tohoto příspěvku, mám 2uzlový pohotovostní systém RAC. Jedna instance je „použití instance“ a druhá instance tam sedí relativně nečinně. V protokolu výstrah instance aplikace jsem viděl následující chybové zprávy:
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)
Vzhledem k tomu, že mám pohotovostní databázi nastavenou na STANDBY_FILE_MANAGEMENT=AUTO, dává první část zpráv smysl. Když přidáte novou instanci do databáze RAC, musíte poskytnout tabulkový prostor Undo pouze pro tuto instanci a také musíte poskytnout online skupiny redo log věnované vláknu této instance. DBCA mi konkrétně položila otázky týkající se struktury souborů zpět a znovu. V obsahu protokolu výstrah výše vidíme, že pohotovostní režim úspěšně přidal datový soubor 342, což je můj tabulkový prostor Zpět. Pohotovostní režim však nedokázal přidat online protokoly opakování. Pokud chcete, aby pohotovostní režim mohl automaticky přidávat online redo logy, musíte zadat parametry OMF, což se zdráhám. Protože přidání souboru redo log souboru online vedlo k chybě, pohotovostní režim zastavil obnovu média. Pohotovostní režim stále přijímá protokoly.
Na Metalink nebo hledáním na Googlu jsem toho moc nenašel, jak tento problém vyřešit, ale zde jsou kroky, které jsem podnikl, abych znovu zprovoznil Media Recovery. V pohotovostní databázi (udělal jsem to na instanci aplikace, ale měla by být životaschopná v jakékoli instanci v pohotovostní databázi 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
To by neměl být šok, protože víme, že Managed Recovery bylo přerušeno. Ale pro úplnost jsem tento krok zařadil. Pokud musíte přidat protokoly opakování do pohotovostního režimu, který aktuálně provádí transakce, budete potřebovat tento krok.
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.
Výše uvedené je přesně to, co bylo spuštěno na primární. Je třeba přidat protokol opakování do pohotovostního režimu přesně jako na primární. Opakujte pro každou skupinu redo log přidanou na primární. Protože jsem do své primární databáze RAC přidal 3 instance, musím sem přidat tři vlákna.
4. alter system set standby_file_management='AUTO' scope=memory;
System altered.
5. alter database recover managed standby database disconnect from session;
Database altered.
Spusťte řízenou obnovu. Nyní by mělo být vše v pořádku a můžeme ověřit v protokolu výstrah instance aplikace:
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
Můžeme také ověřit, že se zpoždění aplikace zkracuje. V pohotovostním režimu zadejte následující:
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';
Základní informace o tom, jak spravovat online protokoly opakování pro vaši fyzickou pohotovostní databázi, najdete v Metalink note 740675.1 Online protokoly opakování v pohotovostním režimu.