From tim@sagelogix.com Sun, 29 Jun 2003 07:33:44 -0700 From: Tim Gorman Date: Sun, 29 Jun 2003 07:33:44 -0700 Subject: Re: TSPITR or PITR Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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).