I really don’t want to turn this blog into an accumulation of issues and flaws. But as I explained many times before, the blog for me is also a way to dump information I likely will need the sooner or later again.
Recently I blogged about another RMAN issue in Oracle 12.2.0.1 with traces. This was fixed with the July 2018 RU for Oracle 12.2.0.1. But the issue below about which Piero Ferraz from Brazil alerted me (thanks!!!), happens in exactly this RU.
RMAN Backup Gives RMAN-06091: No Channel Allocated for Maintenance
This issue gets introduced with the July 2018 RU for Oracle 12.2.0.1 and is in Oracle 18.3.0 as well. It is fixed generically in Oracle 19c but you will need to apply a one-off fix right now if you get hit by this issue.
In MOS Note: 2428682.1 – RMAN Backup Gives RMAN-06091: No Channel Allocated For Maintenance (of An Appropriate Type) After Applying July 12.1.0.2.180717 (DBPSU/BP/RU) you’ll find this “explanation”:
After applying July 2018 (DBPSU/BP/RU) Patch RMAN script may fail with ” RMAN-06091: NO CHANNEL ALLOCATED FOR MAINTENANCE (OF AN APPROPRIATE TYPE) “
RMAN-8031: released channel: t1 RMAN-571: =========================================================== RMAN-569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-571: =========================================================== RMAN-3002: failure of delete command at 07/24/2018 08:26:03 RMAN-6091: no channel allocated for maintenance (of an appropriate type)
The issue got logged as Bug 28391990 but the fix got superseded by Bug 28432129 which has then the complete patch. You can download patch 28432129 from MOS.
Basically the issue happens during deletion of archivelog or datafile copies. Or when you do a crosscheck. A disk channel is expected. And if no disk channel is defined, it fails. The fix allows other channels to be used for the deletion as well as far as my understanding goes.
Piero sent me his output:
opat lspatches 28163133; Database Jul 2018 Release Update: 12.2.0.1.180717 (28163133) 28163190; OCW JUL 2018 RELEASE UPDATE 12.2.0.1.180717 (28163190) sent command to channel: c1 sent command to channel: c1 sent command to channel: c1 sent command to channel: c1 released channel: c1 RMAN-00571: ====================================================== ============= RMAN-00569: ============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: ====================================================== ============= RMAN-03002: failure of crosscheck command at 07/30/2018 19:33:48 RMAN-06091: no channel allocated for maintenance (of an appropriate type) Recovery Manager complete. no rows selected no rows selected no rows selected no rows selected
Important Links
- MOS Note: 2428682.1 – RMAN Backup Gives RMAN-06091: No Channel Allocated For Maintenance (of An Appropriate Type) After Applying July 12.1.0.2.180717 (DBPSU/BP/RU)
- Bug 28391990 – RMAN-06091: NO CHANNEL ALLOCATED FOR MAINTENANCE
- RMAN Backup generates traces in Oracle 12.2.0.1
- FloraB’s Blog Post: Issues encountered after applying the July 2018 12.1.0.2 BP
Addition Sep 3, 2018
Thanks for the hint to Kay Liesenfeld: The issue is in 12.1.0.2 and 11.2.0.4 as well. You may have recognized this from the MOS note’s title pointing to 12.1.0.2. I haven’t. Sorry – and thanks for the hint, Kay!
–Mike
Hey Mike,
there is the same issue with 12.1. and 11.2.0.4. databases and PSU/RU July 2018.
Regards
Kay.
Thanks for the hint, Kay!
Ooops, still not fixed.
Installed 12.2.0.1 vanilla, then Jul 2018 RU. In Aix.
Tried cold backup, same problem.
Anyways, not a biggie. The event avoid the issue, good enough for me.
Hello Mike,
simple question in this context: in the README of patch 28432129 they say ‘RAC Rolling Installable’ but when I proceeded as normal and performed “opatch apply” on our RAC opatch neither recognized that it’s a RAC nor asked me to stop the instance (“Is the local system ready for patching?”. As the result the patch was ‘successfully’ applied on only one node with running services for this Oracle home. Im sure this patch contains really minor changes so there is no problem at all but I’m in doubt if my patch procedure was wrong or is the README of this patch incorrect?
Thx & regards
Axel D.
Alex,
you are right, the readme is quite … outdated? …
This would be the correct command:
opatchauto
https://docs.oracle.com/cd/E91266_01/OPTCH/GUID-F2FA9E4B-3028-4597-A6BA-8CF78D1B86D5.htm#OPTCH585
It does distribute the patch to the nodes, it does the RAC rolling etc.
Sorry for the inconvenience. I mailed the owner of the readme to add the correct references and information (as the note in the header for Rolling Upgrades is outdated as well).
Cheers, and thanks for alerting us.
Mike
Hi Mike!
This workaround was the only one that worked for us after applying Jul 2018 RU.
https://taliphakanozturken.wordpress.com/2018/04/02/rman-03002-and-rman-06091-errors-when-deleting-obsolete-backups/
Regards
Jocke.
Hi Mike,
this was the only way for us to solve this problem;
https://taliphakanozturken.wordpress.com/2018/04/02/rman-03002-and-rman-06091-errors-when-deleting-obsolete-backups/
We added “allocate channel for maintenance type disk;” and now all works OK.
we need to add the tape channel and the disk channel. (if TAPE is defined as DEFAULT ! )
allocate channel for maintenance type ‘SBT_TAPE’ PARMS=”SBT_LIBRARY=/opt/commvault/Base/libobk.so,BLKSIZE=262144,ENV=(CV_mmsApiVsn=2,CV_channelPar=ch1)” TRACE 0;
— before ——
RMAN> delete obsolete;
RMAN-Aufbewahrungs-Policy wird f▒r den Befehl angewendet
RMAN-Aufbewahrungs-Policy ist auf ein Recovery-Fenster von 14 Tagen festgelegt
Die folgenden veralteten Backups und Kopien werden gel▒scht:
Typ Schl▒ssel Abschlusszeit Dateiname/Handle
——————– —— —————— ——————–
Backupset 560 2018-12-27 16:02:23
Backup-Piece 673 2018-12-27 16:02:23 +BKUP/IFPRD_HA1/AUTOBACKUP/2018_12_27/s_995990541.1543.995990543
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: Fehler bei Befehl delete bei 01/11/2019 20:17:43
RMAN-06091: Kein Kanal f▒r Wartung (entsprechenden Typs) zugewiesen
—— After ————
allocate channel for maintenance device type disk;
delete obsolete;
RMAN-Aufbewahrungs-Policy wird f▒r den Befehl angewendet
RMAN-Aufbewahrungs-Policy ist auf ein Recovery-Fenster von 14 Tagen festgelegt
Die folgenden veralteten Backups und Kopien werden gel▒scht:
Typ Schl▒ssel Abschlusszeit Dateiname/Handle
——————– —— —————— ——————–
Backupset 560 2018-12-27 16:02:23
Backup-Piece 673 2018-12-27 16:02:23 +BKUP/IFPRD_HA1/AUTOBACKUP/2018_12_27/s_995990541.1543.995990543
M▒chten Sie die obigen Objekte wirklich l▒schen (geben Sie YES oder NO ein)? YES
Backup Piece gel▒scht
Backup-Piece Handle=+BKUP/IFPRD_HA1/AUTOBACKUP/2018_12_27/s_995990541.1543.995990543, RECID=1, STAMP=995990541
1 Objekte gel▒scht
I hope it helps. ( it is a German DB but the messages are pretty much explanatory themselves )
Hi Mike,
the patch 28432129 on linux x86_64 on top of 12.1.0.2 DBBP Oct 2018 resolves on my environment. You know if are there plans to include this patch in future DBBP patches on 12.1 linux x86_64? I see that on windows the fix is now included in bundles, accordingly to the note 28432129.8.
Regards,
Federica
Federica,
as far as I see it will included in all April 2019 bundles (12.1.0.2, 12.2.0.1, 18c)
Cheers,
Mike
On AIX, Bug fix 28432129 does NOT resolve the issue. There is an open bug that Oracle does not intend to fix for the 12c versions specifically about that issue. Just a hint for anyone using AIX – If you use tape for backups, you will need to go old-school with your maintenance rman cmdfile or script. It is safest in a tape subsystem environment to allocate one of each type of channel below WITHOUT a run block. It took me a couple of weeks to dig through documentation to find the appropriate combination. I have pasted below what works for me on any OS, bugfix applied or not:
connect target /
connect catalog rman/****@rcvcat
allocate channel for maintenance device type sbt parms …….;
allocate channel for maintenance device type disk;
crosscheck backup;
report obsolete;
delete noprompt obsolete;
delete noprompt expired backup;
exit
Hi Tony,
thanks for the information. Can you share the bug number with me? I did check the original bug 28432129 but can’t find a reference that this issue is still broken on AIX.
Cheers,
Mike
Hey Mike,
I’ve done some digging and was unable to find the bug I previously referenced. I thought I had favorited the Oracle doc that contained it but, alas I didn’t. From memory, the second bug basically said: “..still an issue even after applying patch 28432129..” and the doc said that no new bug patch would be released in versions 11 or 12, and that the issue itself would first be resolved in version 18.
Sorry about the lack of explicit details.
– Tony
Thanks Tony,
It also works for Linus server.
Regards
Paul
I hit this one recently as well. 12.2 with Jul RU.
I then added two channels to the RMAN configuration, rather than doing it via commands.
One is for disk, one for tape.
After that, all was well and all crosschecks and deletes worked fine.
Go figure?
The same happens when you try to restore/recover.
It seems to happen everytime RMAN tries a “implicit crosscheck”.
For me, it just worked after this command >> “allocate channel for maintenance device type disk;” right before i submit the RMAN run block.
Thiago C.
Rio de Janeiro / Brazil
Bom dia, Thiago!
Obrigado – and sorry for the inconvenience!
Mike