🚀 go-pugleaf

Szanowna Grupo,
podobno nie umarłaś, więc może będziesz miała sugestię, skąd biorą się 
osierocone archivelogi podczas klonowania bazy.

Regularnie wykonuję klony bazy produkcyjnej, używam do tego rmana i 
poniższego skryptu (nieistotne części wyciąłem):
run {
duplicate target database to CLONEDB
FROM ACTIVE DATABASE
PASSWORD FILE
SPFILE
SET ....
DB_FILE_NAME_CONVERT=....
LOGFILE
   GROUP 1 (
      ....
   ) SIZE 100M,
....
;
}

Przed tym robię zawsze backup archivelogów z bazy CLONEDB (backup ten 
kasuje archivelogi i oczywiście DROP DATABASE CLONEDB.

Podczas operacji duplicate, rman kopiuje z bazy źródłowej pliki danych i 
archivelogi. Przykładowo, kopiuje taki plik:
input archived log thread=1 sequence=666 ...
output file name=+DYSK/archivelog/2015_01_16/thread_1_seq_666
channel ORA_DISK_1: archived log copy complete, elapsed time: 00:00:01

A potem oczywiście aplikuje go do docelowej bazy, podczas etapu "set 
until scn 666666; recover clone database delete archivelog;":
starting media recovery
archived log for thread 1 with sequence 666 is already on disk as file 
+DYSK/archivelog/2015_01_16/thread_1_seq_666
archived log file name=+DYSK/archivelog/2015_01_16/thread_1_seq_666 
thread=1 sequence=666
media recovery complete, elapsed time: 00:00:02
Finished recover at 2015.01.16 16:21:57
Oracle instance started

Wszystko jest świetnie, użytkownicy zadowoleni z nowej bazki. Problem 
jest w tym, że ten archivelog 'thread_1_seq_666' zostaje na dysku. A 
ponieważ w rmanie zmieniła się inkarnacja (jest nowa), a plik 
thread_1_seq_666 należy do poprzedniej, nie jest skatalogowany w ramach 
bieżącej inkarnacji i w związku z tym nigdy nie jest kasowany podczas 
backupu. Od czasu do czasu muszę to kasować ręcznie.

Jakieś sugestie co zrobić z tymi osieroconymi plikami? Nie chciałbym 
tego robić na pałę, czyli kasować po prostu stare pliki z dysku, 
wolałbym przekonać rmana, żeby je skasował po wykorzystaniu.

-- 
Grych