Spletna stran uporablja piškotke za boljšo uporabniško izkušnjo in spremljanje statistike obiskov (Google Analytics).
Z nadaljno uporabo spletne strani ali klikom na "Strinjam se", se strinjate z uporabo piškotkov.
Piškotki in njihova uporaba

Reševanje katastrofe in Oracle

Objavil Blaž Kristan 18.2.2014 @ 08:45

Na razpolago sem imel le dve datoteki - backupset s full backupom baze in autobackup controlfile-a in spfile-a. Niti tega nisem vedel katera (pod)verzija Oracla je bila nameščena na originalnem računalniku.

Ker je šlo za starejšo verzijo 10.2, sem iz Oraclove strani naložil najnovešo različico te verzije (10.2.0.4 instalacijo ter patch 10.2.0.5) in jo namestil na računalnik brez večjih težav.

Ker je šlo za Windows 2008 R2, ki ga instalacija 10.2.0.4 še ne pozna, sem moral namestitveni program pognati s prameterom -ignoreSysPrereqs

setup.exe -ignoreSysPrereqs

Izbral sem namestitev zgolj programskih datotek, brez kreiranja baze, in počakal, da si namestitev konča. Sledila je obnovitev podatkovne baze.

Oracle ima ukazno orodje RMAN, ki je božji dar za reševanje takih katastrof. Najprej pa si seveda pripravimo okolje v ukazni vrstici, kjer bomo opravili praktično vse delo.

set oracle_home=C:\oracle\ora102
set oracle_sid=DBSID
set NLS_DATE_FORMAT=YYYY-MM-DD:HH24:MI:SS
set path=%oracle_home%\bin;%path%

Nato najprej kreiramo instanco, to je servis pod katerim deluje baza.

oradim.exe -new -sid DBSID -startmode manual -srvcstart demand -spfile
orapwd.exe file=%oracle_home%\database\PWDDBSID.ora password=dbapw force=y

Če slučajno iz nekega razloga ne deluje jo še zaženemo:

net start OracleServiceDBSID

Ker smo jo nastavili, da se NE starta avtomatsko (parametra startmode in srvcstart) do treba bazo vedno ročno dvigovati, kar pa bomo popravili čisto na koncu, ko bo baza uspešno obnovljena.
Sledi kreiranje začasne ORA INIT datoteke (pfile). Začasne zato, ker običajno autobackup vsebuje ustrezno spfile. Razlog, da moramo kreirati začasno pfile je v tem, da sem velikokrat naletel na težavo, ko se Oracle instanca ni startala zaradi težav z alokacijo RAM pomnilnika. In to kljub ukazu STARTUP FORCE NOMOUNT.

starting Oracle instance without parameter file for retrieval of spfile
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 02/20/2014 10:13:21
RMAN-04014: startup failed: ORA-03113: end-of-file on communication channel

Razloga še vedno ne vem, pomaga pa zgolj to, da nastavimo:

*.db_name=DBSID
*.sga_target=2G

SGA_TARGET nastavimo na vrednost, ki ustreza količini RAM pomnilnika v računalniku.

Ko je vse to pripravljeno, lahko začnemo z obnovo podatkovne baze. Zaženemo RMAN.

rman target / nocatalog

Prva stvar, ki jo restavriramo, je spfile, vendar pa moramo v ta namen startati instanco (ni dovolj, da Windows servis deluje). Zadeva najbolje deluje, če poznamo ID baze. V kolikor ga ne, vpišemo katerokoli številko za DBID, vendar moramo kasneje pred mountanjem baze izvesti restart RMANa.

SET DBID 2263870536
STARTUP FORCE NOMOUNT
RESTORE SPFILE to pfile 'C:\oracle\home\database\initDBSID.ora' FROM 'x:\backup\file.BKP';
SHUTDOWN IMMEDIATE;

Sledi edititranje tako dobljene ORA INIT datoteke (initDBSID.ora). Pozorni moramo biti na parametre, ki določajo velikost pomnilnika (SGA in PGA), da niso preveliki, in v primeru, da diskovni pogoni niso enaki kot v originalnem strežniku, popravimo poti v parametrih (controlfile, razni _dest parametri, ...). Nato iz pfile kreiramo spfile in startamo instanco za restavriranje controlfile-ov.

startup nomount [pfile='initDBSID.ora'];
SQL "create spfile from pfile[='initDBSID.ora']";
restore controlfile from 'x:\backup\file.BKP';
alter database mount;

Kot že rečeno, če ne poznamo DBIDja, moramo pred ukazom alter database mount restartati RMAN.

Za vsak slučaj sem izvedel katalogiziranje vseh backupov, ki so se nahajali v mapi x:\backup.

catalog start with 'x:\backup';

V mojem primeru sem moral restavrirati bazo na druge diske kot so bili na originalnem strežniku. Disk Q: je zamenjal disk L: in sem zato izvedel še naslednje ukaze, da sem ustrezno popravil lokacije vseh datotek.

SQL "alter system set db_file_name_convert=''Q:\DBSID'',''L:\DBSID'' scope=spfile";
SQL "alter database rename file ''Q:\DBSID\REDO01.LOG'' to ''L:\DBSID\REDO01.LOG''";
SQL "alter database rename file ''Q:\DBSID\REDO02.LOG'' to ''L:\DBSID\REDO02.LOG''";
SQL "alter database rename file ''Q:\DBSID\REDO03.LOG'' to ''L:\DBSID\REDO03.LOG''";
run {
set newname for datafile  1 to 'L:\DBSID\SYSTEM01.DBF';
set newname for datafile  2 to 'L:\DBSID\UNDOTBS01.DBF';
set newname for datafile  3 to 'L:\DBSID\SYSAUX01.DBF';
set newname for datafile  4 to 'L:\DBSID\USERS01.DBF';
...
restore database;
switch datafile all;
}
recover database;

Sledi še odpiranje baze in zamenjava datoteke v TEMP tablespace-u.

alter database open resetlogs;
SQL "ALTER DATABASE TEMPFILE ''Q:\DBSID\TEMP01.DBF'' DROP";
SQL "ALTER TABLESPACE TEMP ADD TEMPFILE ''L:\DBSID\TEMP01.DBF'' SIZE 256M REUSE AUTOEXTEND ON NEXT 64M MAXSIZE 4096M";
SQL "alter system reset db_file_name_convert scope=spfile sid=''*''";
shutdown immediate;
startup;

Mene je pričakalo neprijetno sporočilo, da je potrebno bazo odpreti s parametrom UPGRADE, takoj ko sem jo poskusil odpreti. To pa zato, ker je bila originalna baza očitno starejše verzije (10.2.0.3). Posledično nisem uspel preimenovati TEMP datoteke, ki pa jo upgrade postopek potrebuje. :S

Sledil je skok v SQLplus, kjer sem zadevo rešil tako, da sem bazo startal v upgrade načinu in zamenjal TEMP datoteko, ter počistil parametre.

startup upgrade;
ALTER DATABASE TEMPFILE 'Q:\DBSID\TEMP01.DBF' DROP
ALTER TABLESPACE TEMP ADD TEMPFILE 'L:\DBSID\TEMP01.DBF' SIZE 256M REUSE AUTOEXTEND ON NEXT 64M MAXSIZE 4096M";
alter system reset db_file_name_convert scope=spfile sid='*';
shutdown immediate;

Sledil je upgrade baze s standardnim Oracle database upgrade assistant-om. Ki se je k sreči izvedel brez težav.

In čisto na koncu še popravimo, da se baza starta samodejno ob restartu računalnika.

oradim.exe -edit -sid DBSID -startmode auto -srvcstart system -spfile

Dodatna težava pri odpiranju baze

Ko sem na enem od testnih okolij poskušal pripraviti bazo kot kopijo originalne, me je pričakalo zanimivo sporočilo, ko sem želel odpreti bazo po uspešnem restore-u.

Podobnega sporočila še nikdar prej nisem videl, zato me je toliko bolj presenetilo. Glasilo pa se je:

RMAN> alter database open resetlogs;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 02/20/2014 07:57:27
ORA-00392: log 2 of thread 1 is being cleared, operation not allowed
ORA-00312: online log 2 thread 1: 'L:\DBSID\REDO2_1.LOG'
ORA-00312: online log 2 thread 1: 'M:\DBSID\REDO2_2.LOG'

Malo guglanja in rešitevje bila v obliki:

RMAN> SQL "ALTER DATABASE CLEAR LOGFILE GROUP 2";

Čudno, saj je bilo vse narejeno, kot se spodobi. Vključno z backupi.

Komentarji

* Komentarje mora odobriti admin.