Re: Oracle Myths

> Nope, and for damn good reasons. I've heard horror stories of people who
> haven't used it the right way. I sure wouldn't want to support the
results in
> any other way than enforcing it as strictly as we do! :)

hmm from what I have seen it's pretty easy to extract data with DUL - the result will be same
no matter who's in front of the keyboard - the only difficult thing about DUL is setting the
platform specific parameters. And DUL only does reads - so it's not like it'll damage the DB
even more ... BBED on the other hand is shipped with Oracle on the NT platform and *will* let
you change the blocks directly, being able to corrupt data quite easely without deep knowledge of
oracle block structures ... I can't imagine what those horror stories would be, I can only imagine
the relieve of the IT departement recovering whatever data they can get.

btw Pete - you working for Oracle and all - why did Oracle ship BBED with Oracle on NT and didn't
bother to document it - they even password protected it ... is this a *bug* and it shouldn't be there in
the first place ? :-)

"Pete Sharman" <peter.sharman_at_oracle.com> wrote in message news:ac61le0cfv_at_drn.newsguy.com...
> In article <pYtF8.83579$Ze.12960_at_afrodite.telenet-ops.be>, "koert54"
says...
> >
> >> Once again, DO NOT use DUL without Oracle Support doing it for you.
> >>
> >
> >There's no other way ! It seems to me Oracle is very protective about
this
> >tool ... they won't let you
> >anywhere near DUL ! :-)
>
> Nope, and for damn good reasons. I've heard horror stories of people who
> haven't used it the right way. I sure wouldn't want to support the
results in
> any other way than enforcing it as strictly as we do! :)
>
> >
> >"Pete Sharman" <peter.sharman_at_oracle.com> wrote in message
> >news:ac5n8p02n4n_at_drn.newsguy.com...
> >> In article <%6qF8.83117$Ze.12985_at_afrodite.telenet-ops.be>, "koert54"
> >says...
> >> >
> >> >- System does not have hard coded block locations ...
> >> >- sql.bsq does not contain any unusual create table statements - there
> >are
> >> >however a lot of tables that
> >> >take part in clustered tables
> >> >- dul can extract the data from the system tablespace based on object
> >ID -
> >> >which is part of the block header - for example
> >> >obj$ is always objectid 18 in Oracle 8.0 & 8.1, tab$ is the first
table
> >in
> >> >clustertable with id 2, etc
> >> >- there's nothing magic about dul unload data coming from datafiles
from
> >> >another platform, if you know the platform's
> >> >characteristics (little/big endian) and the Oracle specifics on that
> >> >platform (structure of dba etc)
> >> >
> >> >https://sourceforge.net/projects/jdul/
> >>
> >> And just a reminder to make things 100% clear - DUL is a tool that MUST
be
> >used
> >> by Oracle only. It's completely unsupported outside this environment.
> >It's a
> >> tool that was written to get as much information as we could from a
> >corrupt
> >> database in much the same way as OS vendors have tools to try to
recover
> >corrupt
> >> disks. When an Oracle person uses DUL, you are almost certain to still
> >end up
> >> with a logically corrupt database i.e. not all transactions can be
> >recovered.
> >> You will need to manually re-enter data, but at least you'll have SOME
of
> >your
> >> corrupted database recovered.
> >>
> >> Once again, DO NOT use DUL without Oracle Support doing it for you.
> >>
> >> >
> >> >
> >> >"Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message
> >> >news:m7kF8.47092$UV4.7228_at_rwcrnsc54...
> >> >> The system tablespace has some special characteristics. For
example,
> >> >there
> >> >> are a bunch of segments that start at explicit hard coded block
> >locations.
> >> >> Why do I believe that to be true? If you look in sql.bsq you will
see
> >some
> >> >> unusual create table statements. They have some undocumented
> >parameters.
> >> >> (which I suggest NO ONE use) Also when we had an Oracle consultant
> >come
> >> >out
> >> >> to use the DUL (Data Unloader Tool - and I was involved in the
> >aftermath
> >> >of
> >> >> this database reconstruction, not one I knew about until someone
from
> >> >> another department asked me to recover their unbacked up,
nonarchivelog
> >> >mode
> >> >> database) on a database of ours. It can read the actual data files
> >with
> >> >out
> >> >> the Oracle binaries right from the raw files. It does not even have
to
> >> >run
> >> >> on the same OS that the files were created on. (eg Oracle NT data
files
> >> >can
> >> >> be DUL extracted on a Sun box without Oracle present) It needs some
> >> >> configuration files to tell it which file is the system tablespace
and
> >the
> >> >> other database files, but it reads the schema etc right out of the
> >system
> >> >> datafile. So I suspect that the system tablespace has not been
changed
> >> >due
> >> >> to this and other reasons.
> >> >>
> >> >> I could be wrong.
> >> >>
> >> >> Jim
> >> >> "Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message
> >> >> news:3CE52C02.39AFD7B_at_exesolutions.com...
> >> >> > Ed Stevens wrote:
> >> >> >
> >> >> > > On 17 May 2002 03:23:23 -0700, p_byrne76_at_hotmail.com (Pascal
Byrne)
> >> >> wrote:
> >> >> > >
> >> >> > > >"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> wrote
in
> >> >> message news:<3ce21b71$0$8510$ed9e5944_at_reading.news.pipex.net>...
> >> >> > > >> PCTIncrease should be as small as possible but non-zero to
> >minimize
> >> >> > > >> tablespace fragmentation.1% is a good value (from my OCP
course
> >> >notes
> >> >> though
> >> >> > > >> not necessarily given by the tutor!)
> >> >> > > >
> >> >> > > >I've seen this quoted in a recent paper by Michael R. Ault
(author
> >of
> >> >> > > >"Oracle8i Administration and Management"). The reason given was
> >that
> >> >> > > >SMON will not coalesce free space if PCTINCREASE is zero. Is
this
> >> >> > > >definitly a myth?
> >> >> > > >
> >> >> > > >-Pascal
> >> >> > >
> >> >> > > I can't say for sure, but my bet is that this falls into the
> >catagory
> >> >of
> >> >> "not a
> >> >> > > myth, but so what?" It's my understanding that with proper
> >tablespace
> >> >> > > definition and management, tablespace fragmentation is itself a
> >> >> non-issue.
> >> >> > > Whether my understanding of that "fact" is correct or not, the
real
> >> >> point I'm
> >> >> > > tryng to make is that in some cases, the basic "statement of
truth"
> >> > in
> >> >> this
> >> >> > > case it is "SMON will not coalesce free space if PCTINCREASE is
> >> >zero.")
> >> >> may
> >> >> > > still be true, but other features/functions make it a non-issue.
> >Kind
> >> >> of like
> >> >> > > the old story of the housewife who always cut an inch off the
end
> >of a
> >> >> ham
> >> >> > > before putting it in the baking pan.
> >> >> > > --
> >> >> > > Ed Stevens
> >> >> > > (Opinions expressed do not necessarily represent those of my
> >> >employer.)
> >> >> >
> >> >> > My best guess would be that it was valid back before 8i and before
> >LMT.
> >> >> >
> >> >> > Then I always created my tablespaces with PCTINCREASE 1 and my
tables
> >> >with
> >> >> PCTINCREASE 0.
> >> >> >
> >> >> > But why oh why oh why does Oracle, itself, continue to create the
> >system
> >> >> tablespace with the defaults it does? Is it due to optimization
> >> >> > or just a reluctance to change it?
> >> >> >
> >> >> > Daniel Morgan
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >> HTH. Additions and corrections welcome.
> >>
> >> Pete
> >>
> >> SELECT standard_disclaimer, witty_remark FROM company_requirements;
> >>
> >
> >
>
> HTH. Additions and corrections welcome.
>
> Pete
>
> SELECT standard_disclaimer, witty_remark FROM company_requirements;
>
Received on Sat May 18 2002 - 13:06:59 CDT