Kashif

I’ve seen you publish some lists on your blog in the past, so I was wondering if you have a list of interview questions you have asked ETL developers? I’m trying to come up with a list that is not too tool-specific (we use DataStage ourselves), and I’m debating if it should be Oracle-heavy. Thoughts on that?

Thanks.

Kashif

I think it has nothing to do with the table stats. It’s purely that truncate is DDL, and I hypothesise that the optimizer just doesn’t know that kind of DDL and so has to re-parse cursors to ensure that the table can still support the cached query.

The change in data object id signifies that the objects segments have been discarded. So, although the objects stats have not been affected - they would no longer reflect the data stored in the table. And in some senses this is really a new object ( as far as cached cursors are concerned ).

I expect that the optimizer avoids making any assumptions about the state of the object before the truncate by invalidating referencing cursors.

Just did a quick search of various sources.

They are hardly the most convincing of articles - their style and spelling and grammatical mistakes detracting from their authority, but from Metalink note 62143.1 “Understanding and Tuning the Shared Pool”:

”
Avoid Invalidations

Some specific orders will change the state of cursors to INVALIDATE. These orders modify directly the context of related objects associated
with cursors. That’s orders are TRUNCATE, ANALYZE or DBMS_STATS.GATHER_XXX on tables or indexes, grants changes on underlying objects. The associated cursors will stay in the SQLAREA but when it will be reference next time, it should be reloaded and reparsed fully, so the global performance will be impacted.
”

and also metalink note 123214.1 - “Truncate - Causes Invalidations in the LIBRARY CACHE”.

http://www.freelists.org/archives/oracle-l/03-2008/msg00493.html

Very funny!

***********************************************

In this scenario you just truncated a table in production that you
meant to truncate in development. Now what do you do?

1) Shout OHHH SH**! (fill in the ‘*’ with whatever letters you think
are appropriate)

2) After you’ve gotten over the initial shock of this monumental mistake,
do a

Shutdown immediate;

3) Stop, think and immediately tell your manager or coworkers what you did.

4) Curse a coworker who had nothing to do with YOUR mistake. It won’t
help the situation, but now you can feel bad for two stupid mistakes.

5) Apologize for cursing your coworker and accept FULL responsibility
for YOUR mistake.

6) Now that you are rational, calmly discuss with your
manager/coworkers the best course of action. If it is decided to
proceed with a point-in-time recovery, then continue with the
following steps.

7) Backup the controlfile in case you have to restart the recovery:

Alter database backup controlfile to
‘$ORACLE_HOME/dbs/$ORACLE_SID_backup.ctl’;

8) Check the alert log for the exact time you started the “shutdown
immediate”.

9) Think about how much time may have passed between step 1 and 2,
then decide on a safe point-in-time before the truncate occurred.

10) Run ‘rman’.

RMAN> connect target /
RMAN> restore database;
— After restore completes
RMAN> exit

11) Run ’sqlplus “/ as sysdba’

SQL> recover database until time ‘YYYY-MM-DD:HH24:MI:SS’;
SQL> alter database open resetlogs;
–shutdown may take a while to apply undo from recovery.
SQL> shutdown immediate;
SQL> Startup restrict;

12) Check to make sure everything looks OK.

13) If everything looks good, then open the database to the users:

SQL> shutdown immediate;
SQL> startup;

14) Thank your coworkers for all their help and be grateful you still
have a job.