ORA-27029: skgfrtrv: sbtrestore returned error ORA-19511: Error received from media manager layer…

— gdy podczas recovery wyskoczy:

RMAN-00571: =================================================
RMAN-00569: =========== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: =================================================
RMAN-03002: failure of recover command at 06/24/2022 14:30:32
ORA-19870: error while restoring backup piece bk_x_x_x
ORA-19507: failed to retrieve sequential file, handle=”bk_x_x_x”, parms=””
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
The function mm_retrieve_rs_info() failed with the error: RPC send operation failed; peer = 10.0.0.1:8550, errno = There is no process to read data written to a pipe. (1:5:32)

— oznacza, że zaliczyliśmy timeouta/zewrało połączenie – po prostu niefart, ale się nie przejmujemy i ponawiamy jeszcze raz recovera

GATHER_FIXED_OBJECTS_STATS (x$, v$…)

— jeżeli wolno działają nam zapytania na x$, v$ itp. to warto sprawdzić kiedy były przeliczane statystyki:

select operation, start_time from DBA_OPTSTAT_OPERATIONS order by start_time;

— przeliczenie statystyk:

exec dbms_stats.gather_fixed_objects_stats;

Włączenie Archivelog-ów

— 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


sshd error: Could not load host key

err np. w /var/log/messages:

sshd[*]: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
sshd[*]: error: Could not load host key: /etc/ssh/ssh_host_ecdsa_key
sshd[*]: error: Could not load host key: /etc/ssh/ssh_host_ed25519_key

— sprawdzamy jakie klucze są dostępne i generujemy brakujące:

ls -la /etc/ssh/ssh*key
-rw-r—– 1 root ssh_keys 963 Nov 23 2017 /etc/ssh/ssh_host_key
-rw-r—– 1 root ssh_keys 1679 Nov 23 2017 /etc/ssh/ssh_host_rsa_key

ssh-keygen -t dsa -f /etc/ssh/ssh_host


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

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’);


TEMP recreate

Corrupt Block Found
TSN = 2, TSNAME = TEMP
RFN = 5, BLK = 2168258, RDBA = 23139778
OBJN = -1, OBJD = 23139776, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =

Dumping diagnostic data in directory=[cdmp_], requested by (instance=1, osid=), summary=[incident=*].
Corrupt Block Found
TSN = 2, TSNAME = TEMP
RFN = 5, BLK = 2168258, RDBA = 23139778
OBJN = -1, OBJD = 23139776, OBJECT = , SUBOBJECT =
SEGMENT OWNER = , SEGMENT TYPE =

tworzymy nowego tbs-a:

CREATE TEMPORARY TABLESPACE TEMP2 TEMPFILE '/data/temp201.dbf’ SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 65500M TABLESPACE GROUP ” EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

ustawiamy jako defaulta:

ALTER DATABASE DEFAULT TEMPORARY TABLESPACE TEMP2;

ubijamy sesje, które mają dane jeszcze w temp (ew. restart DB) i dopiero wtedy można zdropować starego temp-a

SELECT b.tablespace,b.segfile#,b.segblk#,b.blocks,a.sid,a.serial#,
a.username,a.osuser, a.status, 'ALTER SYSTEM KILL


RMAN – ściąga

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