Silly me! With a bunch of years of production DBA experience encountering
problems exactly like this one (except it was someone else dropping the
important table) as well as problems far more complicated, I can't decide
what answer they are seeking here! What's more, I would have chosen the
wrong answer...
Forgive me, but how exactly are these test makers differentiating between
the phrases "change-based recovery" and "point-in-time recovery"? Or
"cancel-based recovery" and "point-in-time recovery"? My understanding is
that both change-based and cancel-based recovery are point-in-time
recoveries. That is, recoveries that were halted prior to the current
point-in-time, also known as "incomplete recoveries".
Since the only point-in-time recovery method that is missing from the list
is "time-based recovery", I have to assume the "point-in-time recovery" and
"time-based recovery" are one and the same, perhaps? Just semantics, I
guess, but in a multiple-choice test, misunderstanding the semantics is the
difference between right and wrong. Should be an essay question anyway...
---
The response of "tablespace point-in-time recovery" has been my choice each
time these situations have occurred, in real life. I haven't necessarily
used the mechanism that Oracle produced in Oracle8.0, mostly because the
times I encountered the situation were prior to Oracle8.0. But the idea is
that you restore a "clone" database (consisting of all tablespaces
containing rollback segments and the datafiles containing the table in
question) and recover that new "clone" database forward to the point-in-time
just prior to the DROP TABLE. Then export the table data from the "clone"
and import into the production database.
Therefore, my response on the test ("tablespace point-in-time recovery"),
coming from successful experience in production environments, would have
been marked incorrect on this test. C'est la vie (or more appropriately
"C'est la certification")...
on 6/29/03 4:34 AM, Hemant K Chitale at [EMAIL PROTECTED] wrote:
>
> No, TSPITR should not be the preferred method. Why not ? Because it
> doesn't guarantee that you have achieved consistency of data across objects.
> You must still export the "related objects" and bring them in.
>
> Suppose you have a transactions which updates tables in three different
> tablespaces. A TSPITR for one tablespace would have one table "older"
> than the other two.
> Similarly, indexes in a seperate tablespace are inconsistent with the data
> and must be recreated.
>
> TSPITR is to be used only when you cannot do a full recovery AND you
> can gaurantee that you can recover data consistency.
>
> Hemant
>
> At 11:09 PM 28-06-03 -0800, you wrote:
>> Hello list I came across the following question in the TMH exam guide
>> for 1z0-032:
>>
>> Chris, a DBA, while performing maintenance tasks accidentally drops a
>> very important table. What is the best method available for Chris to
>> recover this table if he is aware of the time when the table was
>> dropped?
>>
>> A . Change-based recovery
>>
>> B*. Point-in-time recovery
>>
>> C . Tablespace point-in-time recovery
>>
>> D . Cancel-based recovery
>>
>> Answer : Point-in-time recovery
>>
>> Wouldn't TSPITR be the best method available in general ?
>>
>>
>>
>>
>> --
>> Please see the official ORACLE-L FAQ: http://www.orafaq.net
>> --
>> Author: <[EMAIL PROTECTED]
>> INET: [EMAIL PROTECTED]
>>
>> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
>> San Diego, California -- Mailing list and web hosting services
>> ---------------------------------------------------------------------
>> To REMOVE yourself from this mailing list, send an E-Mail message
>> to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
>> the message BODY, include a line containing: UNSUB ORACLE-L
>> (or the name of mailing list you want to be removed from). You may
>> also send the HELP command for other information (like subscribing).
>
> Hemant K Chitale
> Oracle 9i Database Administrator Certified Professional
> My personal web site is : http://hkchital.tripod.com
>
--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: Tim Gorman
INET: [EMAIL PROTECTED]
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
