| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: High Water Mark ?
Jonathan Lewis wrote:
>
> Hmm !
>
> No wonder so many DBA's come up
> with daft ideas these days - they've
> taken the OCP exams.
>
> 1) Minimising contention by moving data
> from one tablespace to another. I wonder
> what contention (realistically) could be
> affected by moving objects between tablespaces ?
>
> 2) If you move an object from one tablespace to another
> then you have to create a new object - so the HWM
> is set to zero when you create the object - so no
> method will get data in 'below the hwm'.
>
> 3) No doubt the exam is out of date, but where is
> the option for 'alter table move ?' Which could
> be done in 8.1, and is likely to be the 'best' option.
>
> 4) No excuse for missing 'CREATE TABLE AS SELECT
> NOLOGGING' as an option. To do so suggests that
> all the other options might be a good idea. CTAS also
> allows for a parallel activity.
>
> 5) Of course, since you have to recreate the object to
> get it into the second tablespace all the access rights
> disappear unless you take the export / import option:
> but dependencies get broken until you recompile
> everything in sight and that doesn't get fixed by import.
>
> 6) Where's the bit that caters for the PK/FK constraints
> when you get to dropping the old copy of the data -
>
> 7) Not to mention recreating the FK constraints to point
> to the new copy of the object afterwards.
>
> 8) Of course, the question only asks about loading
> the data, not about how you would extract the data
> to have it ready for loading. So SQL*Loader conventional
> path is no more unreasonable than the rest of the answers
>
> 9) Although direct load import does not exist, English grammar
> allows option (D) to mean use direct export, conventional
> import, so (D) is no more unreasonable than the rest of
> the answers.
>
> 10) Option (E) (which I understand from other posters is
> the notional correct answer) is as defective
> as all the others - if you decide to export / import why
> aren't you doing a direct export and conventional import ?
>
> 11) And its incomplete of course - how do you deal with an
> import that has to move an object from one tablespace
> to another anyway: import tends to put things back where
> they came from
>
> 12) And if you do the export /import, would you do it with
> compress extents = y or n ?
>
> In short -
> A bloody stupid question with a ridiculous choice
> of answers that does nothing to check the real-life
> skills of a potential DBA.
>
> --
>
> Jonathan Lewis
> Yet another Oracle-related web site: http://www.jlcomp.demon.co.uk
>
> yewpc_at_rnd.celcom.com.my wrote in message <81l2jp$m0g$1_at_nnrp1.deja.com>...
> >hi,
> > I have a quenstion on one of the question in OCP8 Database
> >Administartion (accessement test)
> >"You need to minimize resource contention by moving some of the data in
> >the HR_DATA tablespace to the HR_DATA2 tablespace. Which method would
> >you use to load this data below the high water mark ?
> >A. direct-load insert
> >B. SQL*Loader direct path
> >C. SQL*Loader conventional path
> >D. Export and Import utilities using direct mode
> >E. Exportand Import utilities using conventional mode
> >
> >The answer is E. but why ?
> >Can anyone tell me how each of the above method change the high water
> >mark ?
> >Actually what is high water mark ? what is it purpose ? what dictionary
> >i can use to query about it ?
Yeh - but you get a really nice little cutesy certificate, with quaint little italic writing, and ... wait for it... free, yes FREE access to technet.oracle.com...Oh hold on - its free for everyone..
Gee wow !
And most importantly, you can then become obsessed with having "Joe Blow, OCP, DBA, RTFM, NERD, blah blah blah" in your signature...
Signed
Someone-who-is-tired-of-agents-saying-Must-have-OCP
:-)
Connor
--
"Some days you're the pigeon, and some days you're the statue." Received on Mon Nov 29 1999 - 04:28:37 CST
 |
 |