Re: TSPITR or PITR

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).