Part of a DBA’s daily work involves cleaning up logs and anything else on the disks that may not belong there or is no longer needed. With ever-increasing security requirements for systems and increasingly sophisticated monitoring, it naturally stands out when unknown files suddenly appear somewhere and/or remain there longer than expected.
A customer asked us what those PARLOG files were that had been sitting in one of the archive log destination directories for over a week. All backups had actually run smoothly, and the customer couldn’t recall the Recovery Manager ever throwing an error.
That's why I'd like to shed some light on the matter.
What are PARLOG files and when are they created?
PARLOG files are “partitional (archive) log” files. They are created during hot-clone operations on pluggable databases (PDBs). Like “regular” archive log files, they contain redo data.
However, as the name suggests, they do not contain the complete redo stream that is stored in the archived redo logs.
The PARLOG files contain only a portion of this data—namely, the portion that is actually required to recover the hot clone in the new CDB. In other words, the portion needed to restore and recover the newly created PDB (a hot clone operation can take hours, depending on the size of the database) to a consistent state.
As a result, they are smaller (over the duration) than normal archived redo log files, which, in a multitenant environment, naturally contain redo data for all PDBs and the CDB.
Normally, you don't see these files at all. Once a clone operation is complete (whether successful or not), they are deleted from the root container. In this case, the hot clone was aborted, and for unknown reasons, the database “forgot” to delete the parlog files.
So what can be done to prevent these files from remaining in the archive log destinations indefinitely?
Since these are (albeit smaller) archived redo log files, one might think they could be managed in Recovery Manager. However, running a “List” command shows nothing.
An attempt to catalog these redo logs and then delete them fails because the root container does not accept the files as separate archived redo logs (which is understandable, since not all redo data is included).
As you can see in the Alert.log, the header of these files is different from that of normal archive logs.
The only valid way to remove orphaned Parlog files is therefore to delete them using operating system commands after the process has completed.
Incidentally, the names of the Parlog files are generated by the database itself and cannot be changed, even if the (correct) archived redo logs follow a different naming convention.
