Re: Oracle Myths

So
> does the block header have the object ID and Oracle just scans the start
of
> the system tablespace until it finds objectid 1 etc. so it can find the
data
> dictionary so it can work?

That's how I do it - I see no other way ... I first create a block map for each distinct object id that I find - then if I want to
unload obj$, I iterate over the blocks containig that specific objectid and decode the rowdictionary-> rows -> columns It's a bit more trickier for tab$ & col$ (c_obj#) and user$ (c_user#) - these are part of clustered
tables and you need to iterate the clustered table's blocks and extract the correct table data... and
a block from c_obj# can contain up to 15 tables if I'm not mistaken ... this also means that, although tab$
and col$ have different objectid's they refer to the same clustered table c_obj# by means of the data objectid
(see second column of obj$)

"Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message news:XbvF8.17296$Bw6.499_at_rwcrnsc51.ops.asp.att.net...
> Absolutely. The Oracle person did NOT leave a copy of DUL with me. It is
> NOT something that Oracle even lends to a customer. The process took more
> than one day and before he left for the evening he removed the tool from
my
> disk drive. That was standard operating procedure. I expected it and it
> wasn't a problem for me. I just thought it was pretty neat that it could
> read multiple files from different OS's and that the program was rather
> small (on NT it was under 300K and Solaris a little bigger - Now if MS had
> written it it would have needed a DVD... ;-) ). We were able to recover
a
> limited amount of data. This was not a limitation of the tool rather the
> non-technical person who upgraded the database according to the vendor's
> instructions dropped all the original data so there was nothing to
recover.
>
> Ahh, I found what I meant. You are correct sql.bsq has standard create
> statements in it. I had once looked at the contents of the Bootstrap$
table
> and it had some extra statements in the create statements in its rows
create
> table storage clause -> objno 17 extents(file 1 block 59) for example.
So
> does the block header have the object ID and Oracle just scans the start
of
> the system tablespace until it finds objectid 1 etc. so it can find the
data
> dictionary so it can work?
>
> Jim
>
> "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;
> >
>
>
Received on Sat May 18 2002 - 11:35:09 CDT