Re: Oracle Myths

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 - 12:05:50 CDT