Kategoria: RMAN

Podczas recovery: RMAN-03002, ORA-00283, ORA-19764: database id does not match database id in control file

Opublikowano przez Wiech

Recovery interrupted!
Recovered data files to a consistent state at change 1234567890
Media Recovery failed with error 19764
ORA-00283: recovery session canceled due to errors
ORA-19764: database id 67890 does not match database id 12345 in control file
Slave exiting with ORA-283 exception
ORA-10877 signalled during: alter database recover logfile '/arch/file_arch_1234321.arch’…

Włączenie Archivelog-ów

Opublikowano przez Wiech

— standalone

— weryfikacja:

show parameter recovery_file_dest;

— gdzie mają archlogi lecieć (czy lokalnie czy ASM) oraz ile mają użyć miejsca (ew. jeszcze format log_archive_format)

alter system set log_archive_dest_1=’LOCATION=/u01/baza/arch’ scope=both;

alter system set log_archive_dest_1=’location=+ASMARCH’ scope=spfile;

alter system set db_recovery_file_dest_size=200G scope=both;

— kładziemy bazę, montujemy, archivelog mode, open

shutdown immediate
startup mount


…

Zapytania RMANowe w DB wykonują się za długo (łapią słaby plan zapytania, podatne 11.2 i 12.1)

Opublikowano przez Wiech

Przykładowe zapytania:
select * from v$rman_status;
SELECT MEDIA FROM V$BACKUP_PIECE_DETAILS WHERE SESSION_KEY=:B3 AND SESSION_RECID=:B2 AND SESSION_STAMP=:B1 AND DEVICE_TYPE = 'SBT_TAPE’ AND ROWNUM = 1 (cloudcontrolowe – dzięki Sławek)

to patchujemy DB, jak już nie ma dotępnych patchy bo np. mamy zbyt starą DB i nie chcemy się bawić w requesta patchy to:

exec dbms_stats.DELETE_TABLE_STATS(’SYS’,’X$KCCRSR’); — sam delete nie zadziała – trzeba przeliczyć statystyki również
exec dbms_stats.LOCK_TABLE_STATS(’SYS’,’X$KCCRSR’);


…

RMAN – ściąga

Opublikowano przez Wiech

Jeżeli robimy bckp bez trybu arch, to niestety odpalamy bazę w mouncie i dopiero wtedy FULL + INCrementale

Jeżeli mamy w trybie arch, to na spokojnie możemy robić full + inc + arch w trybie open ale! jeżeli mamy tabele, indexy nologging to dupa – lepiej na czas migracji (o ile chcemy 1:1 bez utraty danych) włączyć force logging-a: ALTER DATABASE force logging; – weryfikacja select name, force_logging from v$database; i dopiero teraz full, inc teoretycznie powinien dociągnąć od ostatniego scn-a, ale komu chce się bawić i sprawdzać pliki które są w nologgingu i od jakiego scn-a są, no ale w razie czego to weryfikujemy:

SELECT file#, name, unrecoverable_change# FROM v$datafile where unrecoverable_change# > 0;

jeżeli nie zweryfikujemy to niestety możemy zostać zbluzgani przy pierwszym lepszym select (który odnośi się akurat do nolooginngowej tabeli albo indexu), oczywiście jeżeli został zmodyfikowany po full-u i nawet kolejnych incrementalach (będzie komunikat o tym, że należy zrobić recovery pliku, ale nie ma na bckp)

— bckp full

$ORACLE_HOME/bin/rman target /
connect catalog rman/x@rcat;
run


…

RMAN-06094: datafile 1 must be restored

Opublikowano przez Wiech

Podczas odtwarzania DB do innej lokalizacji (powiedzie się), ale przy próbie przesunięcia o kilka scn-ów w 12.1.0.2 może być błąd:

Starting recover at 2022-04-28 10:25:30
released channel: ch1
released channel: ch2
RMAN-00571: ====================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS
RMAN-00571: ====================================
RMAN-03002: failure of recover command at 04/28/2022 10:25:31
RMAN-06094: datafile 1 must be restored


…

DB 19 – recovery catalog

Opublikowano przez Wiech

Przygotowanie home-a, rozpakowanie instalek, patchy itp. (użyszkodnik: oracle)

mkdir -p /u01/app/oracle/product/19/dbhome_1
unzip /u01/install/V982063-01-19.3_DB.zip -d /u01/app/oracle/product/19/dbhome_1/
mkdir -p /u01/app/oracle/product/19/dbhome_1/patch/RU
unzip /u01/install/p33192793_190000_Linux-x86-64_patch_RU_DB_19.13.zip -d /u01/app/oracle/product/19/dbhome_1/patch/RU
rm -rf /u01/app/oracle/product/19/dbhome_1/OPatch/*
unzip /u01/install/p6880880_210000_Linux-x86-64 -d /u01/app/oracle/product/19/dbhome_1/

Instalacja (aplikowanie RU) i tworzenie DB:

cd /u01/app/oracle/product/19/dbhome_1
./runInstaller -applyRU patch/RU/33192793
./dbca


…

RMAN-03002, RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

Opublikowano przez Wiech

— Podczas 2giego przebiegu odtwarzania możemy mieć bląd:

sql statement: alter session set nls_date_format = „DD-Mon-YYYY HH24:MI:SS”
executing command: SET until clause

RMAN-00571: =====================================
RMAN-00569: ====== ERROR MESSAGE STACK FOLLOWS ========
RMAN-00571: =====================================
RMAN-03002: failure of allocate command at 10/23/2020 14:50:07
RMAN-20207: UNTIL TIME or RECOVERY WINDOW is before RESETLOGS time

— wysypał się bo robiliśmy juz open resetlogs i przy kolejnym przebiegu wracamy do momentu z przed open resetlogs…