Re: TSPITR or PITR

2003-06-29 Thread M Rafiq
In this given simple situation the best option is B. Besides in OCP test, 
they just ask for best option of given options. Sometime in practice all of 
them may be wrong but still you have to select 'least' wrong.

While doing ONLINE DBA test due to job search or even in OCP practice test 
questions, I have encountered this situation but what to do. Select whatever 
you think is the best.

Regards
Rafiq


Reply-To: [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Date: Sat, 28 Jun 2003 23:09:19 -0800
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).
_
MSN 8 with e-mail virus protection service: 2 months FREE*  
http://join.msn.com/?page=features/virus

--
Please see the official ORACLE-L FAQ: http://www.orafaq.net
--
Author: M Rafiq
 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).


Re: TSPITR or PITR

2003-06-29 Thread Hemant K Chitale


I agree that we really can't differentiate between options A, B and D -- they
are all Incomplete Database Recoveries.  However, option C IS different.
Since we are much more likely to know the "wall clock time" as to when the
table was dropped than the SCN, B makes more sense than A. B also makes
more sense than D because B is quite explicit.
[My reading of the OCP Exam Guides is that you may well be presented
with more than 1 correct answer but you must select the "best" or "most 
appropriate"
answer].

If we take C :
You would have recovered that one table to the point-in-time before it was 
dropped.
However, other tables, still in your database, are as-of the *current* 
point-in-time.
Now, if the recovered table was not an important table OR you did not have
multi-table transactions [who doesn't ?] you could very well carry on.
But if you've already seen a number of transactions proceeding in the database
after the table was dropped ... meaning that this table is "inconsistent" 
with the
rest of the database 
Oh!  But, of course, multi-table transactions wouldn't have proceeded after the
table was dropped.  So, as long as some silly developer or "analyst" hasn't 
updated
data directly in other tables, no other table is inconsistent with this 
one, right ?

Another point-of-view is that TSPITR has more restrictions than complete
database recovery.  Therefore, where possible, complete database recovery
is the preferred option.  Wwhat if the "dropped table"  has varray columns, 
nested
tables, snapshots etc --- then TSPITR can't be used.  Given the limited 
information
in the question C is not the "best answer".

I have been doing point-in-time recoveries and where necessary have done
single table / tablespace recoveries [again, like you, using the old methods
without the advantage of looking up the sys.tspitr% views but not for important
and production databases].
Whether it is an OCP question [where you must choose the "best answer" out
of more than one possible answers]  or real-life,  TSPITR should not be the 
first
option unless you have complete information about the table and how you are
going to recover the table into your production database or you *cannot* do
a full database recovery [e.g. damagement  or other constraints don't allow 
you the time].

There will be situations where you can or must do TSPITR.  There will be
situations where you would prefer to do a Full [albeit Incomplete] Database 
Recovery.

Hemant

At 07:09 AM 29-06-03 -0800, you wrote:
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 ar

Re: TSPITR or PITR

2003-06-29 Thread Tim Gorman
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).


Re: TSPITR or PITR

2003-06-29 Thread Hemant K Chitale
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: Hemant K Chitale
 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).