Exam 1z0-083 topic 1 question 151 discussion

C correct

E, tested in practice

I think D is correct. FLASHBACK TABLE directly supports recovery from TRUNCATE, provided the table is not dropped and that UNDO data is available. If Flashback Data Archive was enabled for the table before the truncation, C could be valid

I don't understand how C is chosen by the community. Flashback Data Archives definition: "A flashback data archive provides the ability to track and store all transactional changes to a “tracked” table over its lifetime " While documentation is super clear about the Truncate case, that its only solution is Flashback Database. So the only correct answer is E

C Or E, both with arguements!!!

c Ref: 19.9.6 DDL Statements on Tables Enabled for Flashback Data Archive Flashback Data Archive supports only these DDL statements: ALTER TABLE statement that does any of the following: Adds, drops, renames, or modifies a column Adds, drops, or renames a constraint Drops or truncates a partition or subpartition operation TRUNCATE TABLE statement RENAME statement that renames a table https://docs.oracle.com/en/database/oracle/oracle-database/12.2/adfns/flashback.html#GUID-D01864A9-C642-4EDF-9EB0-796020A26F2D:~:text=NO%20FLASHBACK%20ARCHIVE%3B-,19.9.6%20DDL%20Statements%20on%20Tables%20Enabled%20for%20Flashback%20Data%20Archive,-Flashback%20Data%20Archive

I think the correct answer is C because, FLASHBACK DATA ARCHIVE is the only flashback option that if it is enabled can flashback some DDLs as TRUNCATE (here the reference https://docs.oracle.com/en/database/oracle/oracle-database/19/adfns/flashback.html#GUID-D01864A9-C642-4EDF-9EB0-796020A26F2D) FLASHBACK TABLE can also flashback truncate ONLY IF RESTORE POINT for Table was created

C or E could be correct

C is correct

@ObserverPL, I think that question assume recover only data from truncated table, so "flashback database" recover data with possible damages in other place. Of course it works, but the "flashback archive" be able to do that without any damages. @Neil107 there are no condition of that we should do as quickly as possible.

FLASHBACK DATA ARCHIVE tested https://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/4421812.pdf SELECT ... AS OF TIMESTAMP... SELECT ... VERSIONS BETWEEN TIMESTAMP and TIMESTAM SELECT * FROM t1 VERSIONS BETWEEN SCN 14759823 AND 14761165 SELECT * FROM t1 AS OF SCN 14759823; truncate SELECT * FROM t1 AS OF SCN 14761249; SELECT current_scn, TO_CHAR(SYSTIMESTAMP, 'YYYY-MM-DD HH24:MI:SS') FROM v$database;

Sorry guys!. It seems my post doesn't get posted. A retry seems to repeat my post.

It's E. Even with FLASHBACK DATA ARCHIVE, truncation of a table is possible, but will be a slow process.A retention time has to be specified. Refer to page 799 of the 12c All-in-one-exam-guide

It's E. Even with FLASHBACK DATA ARCHIVE, truncation of a table is possible, but will be a slow process.A retention time has to be specified. Refer to page 799 of the 12c All-in-one-exam-guide

It's E. Even with FLASHBACK DATA ARCHIVE, truncation of a table is possible, but will be a slow process.A retention time has to be specified. Refer to page 799 of the 12c All-in-one-exam-guide

correct : E Backup and Recovery Workshop - typical scenario for Flashback Database is truncate table. You may use FBDA but in different way (not flashing back): insert into t1_recovered select * from t1 as of timestamp sysdate – 1/24;

I'm with RinD. Go with C Database Development Guide