This is worth a post, despite my dearth of time to post lately … just had an interesting one and found the perfect blog article to resolve my issue, so definitely need to send a shoutout to the author, Andy Black.
In a nutshell, v11 of GG now uses the same sort of “delete only when applied” method that logicals do. v10 does not. If you create an extract and don’t delete it, it thinks the archive logs are still needed and won’t delete them when you do an rman backup. I did have the extract enabled for a bit, I think that is also needed to create this situation, not just an unused extract.
This of course can provide no end of confusion if you have a primary database with both dataguard and goldengate running, and you don’t know GG v11 made this change. I was so confused as to why my logicals weren’t telling the primary that they were long done with these logs. Turns out GG was the holdup.
Andy provides more than enough info to fix the problem, and I also left a comment there about a specific situation and how to fix it (quick ref – make sure to dblogin before you delete an extract, or it will leave a record in db_capture and you’ll end up with RMAN-08137 issues).
Gotta love Oracle / DBA work, learn something new every day.
UPDATE 12/14: we had the same problem but in a restored non-prod copy of the database. Even after installing goldengate and trying to use ggsci to remove the extract, it wouldn’t budge from dba_capture. So I put in an oracle SR. They came back with this oracle article (1351352.1) and this DBMS to remove things manually from dba_capture – DBMS_CAPTURE_ADM.DROP_CAPTURE. I used the following:
select 'exec DBMS_CAPTURE_ADM.DROP_CAPTURE ('''||capture_name||''');' from dba_capture;
then run whichever bits of the output need to be removed.