Exam 1z0-083 topic 1 question 111 discussion

A and E in my opinion - in 19c (new feature) FlashBack Logs are deleted fully automatically once they reach retention, there is no wait for space pressure. If you lower the retention manually then flashback logs are deleted immediatelly.

for 19c, I think B and C are correct. https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/maintaining-rman-backups.html#GUID-26C1A1E8-5555-4399-9DD1-39BA90E45A0C

Not A because there might not be a space pressure, so nothing to delete. so space wont always be released.

A and B A - Flashback logs that are beyond the retention period are automatically deleted. Automatically deleting flashback logs simplifies the management of the fast recovery area and improves the performance of flashback database. https://docs.oracle.com/en/database/oracle/oracle-database/21/haovw/oracle-flashback-best-practices.html#GUID-3E255563-B001-4AC1-A2E0-1884BF58D6C0 B word with "might be" or "may be" >> The oldest flashback logs may be deleted if there is space pressure in the FRA where the flashback logs are stored. https://docs.oracle.com/en/database/oracle/oracle-database/21/haovw/oracle-flashback-best-practices.html#GUID-3E255563-B001-4AC1-A2E0-1884BF58D6C0

Honestly this question is so annoying but taking a look of documentation A is absolutely true with this statement "When the retention target is reduced, flashback logs that are beyond the retention period are deleted immediately." from https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/maintaining-rman-backups.html#GUID-26C1A1E8-5555-4399-9DD1-39BA90E45A0C but i cannot decide between B or C

I Belive the correct anwers are B and C. Starting with Oracle Database Release 19c, the management of space in the fast recovery area is simplified. Oracle Database monitors flashback logs in the fast recovery area and automatically deletes flashback logs that are beyond the retention period. When the retention target is reduced, flashback logs that are beyond the retention period are deleted immediately. https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/maintaining-rman-backups.html#GUID-26C1A1E8-5555-4399-9DD1-39BA90E45A0C

SGA_TARGET Sets the maximum SGA size for the PDB. The SGA_TARGET setting in the PDB is enforced only if the SGA_TARGET initialization parameter is set to a nonzero value in the CDB root. The SGA_TARGET setting in the PDB must be less than or equal to the SGA_TARGET setting in the CDB root.

A E are correct for 19c i believe.

I think it's B and not E because of the "might". When you have guaranteed restore point for flashback, oracle can not delete those logs... what it can automatically delete if normal flashback log even if the flashback retention policy is still active. "Files in the fast recovery area are not eligible for deletion or reuse if they are required to satisfy a guaranteed restore point. " https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/using-flasback-database-restore-points.html#GUID-D0FAAADC-6185-4F8D-A557-18346EE3BDFF

I think AE can be the right answer but the word BEFORE confuses me. if db has insufficient space always delete flashback logs, before that moment it deletes only flashback older than retention target.

A,E With Oracle Database 19c, flashback logs beyond the retention period are proactively deleted without degrading the flashback performance and before there is space pressure.

Doc ID 2465562.1 Starting with Oracle Database Release 19c, the management of space in the fast recovery area is simplified. Oracle Database monitors flashback logs in the fast recovery area and automatically deletes flashback logs that are beyond the retention period. When the retention target is reduced, flashback logs that are beyond the retention period are deleted immediately. In scenarios where a sudden workload spike causes a large number of flashback logs to be created, the workload is monitored for a few days before deleting flashback logs that are beyond the retention period. This avoids the overhead of recreating the flashback logs, if another peak workload occurs soon after. I think is AB

I think it's BC.

https://docs.oracle.com/en/database/oracle/oracle-database/19/bradv/maintaining-rman-backups.html#GUID-26C1A1E8-5555-4399-9DD1-39BA90E45A0C Starting with Oracle Database Release 19c, the management of space in the fast recovery area is simplified. Oracle Database monitors flashback logs in the fast recovery area and automatically deletes flashback logs that are beyond the retention period. When the retention target is reduced, flashback logs that are beyond the retention period are deleted immediately. The COMPATIBLE initialization parameter must be set to 19.0.0 or higher for flashback logs to be automatically deleted. In scenarios where a sudden workload spike causes a large number of flashback logs to be created, the workload is monitored for several days before deleting flashback logs that are beyond the retention period. This avoids the overhead of recreating the flashback logs, if another peak workload occurs soon after. Not convinced with the always. Looks like BC can be right

AE: Doc ID 2465562.1 The COMPATIBLE initialization parameter must be set to 19.0.0 or higher Oracle Database monitors flashback logs in the fast recovery area and automatically deletes flashback logs that are beyond the retention period. When the retention target is reduced, flashback logs that are beyond the retention period are deleted immediately. In scenarios where a sudden workload spike causes a large number of flashback logs to be created, the workload is monitored for a few days before deleting flashback logs that are beyond the retention period. This avoids the overhead of recreating the flashback logs, if another peak workload occurs soon after.

I change my answer, A-E are correct. Space il always reclaimed before sapce pressure.

A -- B for me. E-- I am not convinced about 'always reclaimed proactively'. If database can't delete file in the FRA for some parameters, for example 'backup retention policy', FRA fills up in any case.