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


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


DB 19 – recovery catalog

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


ERR replikacji danych (Data Guard) + move forward czyli aplikowanie intrementala

— objawy: wysypała się replikacja Data Guarda (DB 11.2.0.4), brak błędow (wisi od kilku dni), rozwiązanie: zaaplikowanie incrementala (bo „uszkodzonego” archa brak – ale to wyjdzie później)

Można śmiało zastosować opis do popularnego błędu w przypadku większego GAP-a bądź braku archów:
ORA-16724: cannot resolve gap for one or more standby databases

OGG-01004 ORA-14300, pominięcie transakcji + widoczne całe zapytanie

— W Oracle Golden Gate czasem wysypie nam się proces i nie wiemy na jakim zapytaniu (przeważnie wartości widoczne są jako a1, a2, a3 itd.) – rozwiązań może być dużo np.: trzeba poszerzyć kolumnę, format daty jest niepoprawny albo cokolwiek innego czyli może to być też śmietnik i tak jak w moim przypadku po prostu pominiemy tą transakcję:

ZFS Clon DB przy użyciu SNAP-a (baza testowa w kilka minut)

— Cel: Utworzenie clona bazy danych przy użyciu mechanizmow ZFS czyli tak, aby po clonie baza zajmowała jak najmniej miejsca (w naszym przypadku praktycznie 0 tuż po utworzeniu snapa bieżącej bazy danych) – śmiało można użyć taki sposob dla baz testowych (w chwile mamy bazę testową z zasobem na którym zajmowane są jedynie różnice, ale trzeba brać pod uwagę też przyrost biężącej bazy)
— Baza zrodłowa (istniejąca na ZFS): DBZRODLOWA, baza docelowa: DBTESTOWA…