Re: Oracle Myths

In article <7LwF8.83809$Ze.13075_at_afrodite.telenet-ops.be>, "koert54" says...
>
>> 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.

Well, if you had an idiot in front on the keyboard ... ;)
>
>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 ? :-)

Yes, I work for Oracle - how did you guess? ;) Unfortunately, I don't work in Development and I suspect only the creator of that utility can explain the reasoning behind it - I certainly can't. Of course, you could always log it as a bug if you like :)

>
>"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;
>>
>
>

HTH. Additions and corrections welcome.

Pete

SELECT standard_disclaimer, witty_remark FROM company_requirements; Received on Sat May 18 2002 - 17:10:26 CDT