Securefile Logging Confusion

Question

I'm trying to understand the recoverability implications of setting the LOGGING clause for Securefiles, but the documentation is not helping. The exact documentation from Oracle® Database SecureFiles and Large Objects Developer's Guide is below.
"LOGGING/NOLOGGING/FILESYSTEM_LIKE_LOGGING
Specify LOGGING if you want the creation of a database object, as well as subsequent inserts into the object, to be logged in the redo log file. LOGGING is the default.
Specify NOLOGGING if you do not want these operations to be logged.
For a non-partitioned object, the value specified for this clause is the actual physical attribute of the segment associated with the object. For partitioned objects, the value specified for this clause is the default physical attribute of the segments associated with all partitions specified in the CREATE statement (and in subsequent ALTER ... ADD PARTITION statements), unless you specify the logging attribute in the PARTITION description.
FILESYSTEM_LIKE_LOGGING means that SecureFiles only log the metadata. This option is invalid for BasicFiles. This setting is similar to the metadata journaling of file systems, which reduces mean time to recovery from failures. The LOGGING setting for SecureFile LOBs is similar to the data journaling of file systems. Both the LOGGING and FILESYSTEM_LIKE_LOGGING settings provide a complete transactional file system by way of SecureFiles.
For SecureFile LOBs, the NOLOGGING setting is converted internally to FILESYSTEM_LIKE_LOGGING.
FILESYSTEM_LIKE_LOGGING ensures that data is completely recoverable after a server failure.
Note:
For LOB segments, with the NOLOGGING and FILESYSTEM_LIKE_LOGGING settings it is possible for data to be changed on disk during a backup operation, resulting in read inconsistency. To avoid this situation, ensure that changes to LOB segments are saved in the redo log file by setting LOGGING for LOB storage."
Is Filesystem_like_logging a recoverable operation? (The 4th paragraph says it reduces mean time to recover, but the last Note implies that Securefiles are essentially NOLOGGING, which is also implied by the 5th paragraph…but the 6th paragraph says that the data is completely recoverable).

Answer 1

I've been thinking about this a bit too. Here's what I think happens.
If you have LOGGING set, everything goes to redo, everything is fully recoverable. No problem.
If you have NOLOGGING set, in the event of recovery, there's no data in the redo, so, those blocks will get ORA-26040 "data block was loaded using the NOLOGGING option". The only way to fix this type of corruption is to truncate the segment, and reload.
That much, I think I'm clear on. This new FILESYSTEM_LIKE_LOGGING option, is where I'm a bit foggy. I'm speculating that FILESYSTEM_LIKE_LOGGING means that the metadata is written to redo after the LOB data is written to the securefiles area. So, the metadata is logged, i.e. "the lob data is over here in this securefiles area". But, the LOB itself is not logged. So, if there's a failure, and you do recovery, clean up is a bit simpler, in that you can identify LOBs that are "missing" and selectively delete them, rather than having to resort to truncation of the entire segment.
This seems to be supported by the 11gR1 Concepts manual:
http://download.oracle.com/docs/cd/B28359_01/server.111/b28318/intro.htm#CNCPT1918
which has this to say:
"File System-like Logging: Modern file systems have the ability to keep a running log of the file system metadata. Putting this metadata into a running log (called a journal) that is flushed in a lazy fashion increases performance and removes the need for file system checking operations like fsck. SecureFiles' file system-like logging provides this same high performance journaling. File system-like logging also allows for +soft corruptions+, so that if an error is found on a block, SecureFiles returns a block with the LOB fill character. This allows the application to detect the error by seeing known invalid data and to recover either through deletion of the LOB (something that is not possible with the original implementation of LOBs) or by other means."
Finally, the 11gR2 Securfiles and Large Objects Developer's Guide:
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e10645/adlob_tables.htm#ADLOB45293
Seems to suggest that doing bulk loads w/ FILESYSTEM_LIKE_LOGGING is a good idea.
That brings me to another thought, though. Clearly, NOLOGGING is for direct load only. What about FILESYSTEM_LIKE_LOGGING? Is that only going to work for direct load? Or any type of DML?
So, I think I understand it, sort of... :-) Clearly, this feature needs more documentation and explanation.
I need to play around a bit more, maybe set up a test case or two, before I'll be convinced I understand how it works....
Hope that helps,
-Mark