Re: Oracle data file format

"Jim Kennedy" <kennedy-family_at_attbi.com> wrote in message news:<xaKM8.137999$352.6880_at_sccrnsc02>...
> "Jeremiah Wilton" <jwilton_at_speakeasy.net> wrote in message
> news:Pine.LNX.4.44.0206081526410.20524-100000_at_grace.speakeasy.net...
> > On 8 Jun 2002, Rauf Sarwar wrote:
> >
> > > What I don't understand is why people like to experiment with their
> > > databases when Oracle has provided tools like exp/imp to move
> > > databases between platforms and versions. Shortest distance between
> > > WinNT/2000 <--> Unix <--> Linux etc is via exp/imp. Any other route
> > > will be at one's own risk.
> >
> > I think people experiment because they are curious and intelligent. I
> > think the goal of doing experiments like this is to increase knowledge
> > and unrestanding of computing architectures and data storage
> > internals. Every top-level Oracle person I know got where they are by
> > experimenting with unsupported procedures and poking their nose where
> > Oracle never intended.
> >
> > This kind of violent response to simple experimentation just tells me
> > that there are a lot of uninnovative and self-satidfied DBAs still out
> > there.
> >
> Wrong. We actually have some idea of how the thing works and understand the
> technical reasons. We are highly innovative, but knowledgable enough that
> we try NOT to do things that are going to break. Also one wants to be very
> careful with a production system - there is a database with valuable data
> and we take the responsiblity seriosly and do not have so cavalier attitude
> about it. On real systems we actually care about the data and are not so
> quick to just try it; it might work.
>
> Any tool that would allow you to copy and then "fix up" so it would work on
> a cross platform environment would end up being no faster than export. Why?
> The data blocks would each and everyone need to be read in one format and
> written in another. It would have to take care of the situation where the
> resulting write made the data larger than the block and create a chained
> row. (hence creating a performance problem ) The problem goes beyond bin
> and little endian systems, different systems have different byte alignment
> and so forth.
>
> There are other ways to do it other than export (eg sqlplus copy) or a link
> and pl/sql code or java code. While it would be difficult to prove, export,
> import is probably fastest on cross platform massive data migration.
>
> If I had to migrate a large system with minimal down time I would do it
> another way.
>
> Jim
>
> > Export is dreadfully slow compared to file copy. In any environment
> > with scale and availability commensurate with real commerce, the
> > downtime and unreliability associated with moving a database via
> > export/import is unacceptable. That is why our friend whose nickname
> > begins with "x$" wanted to build a cross-platform datafile muncher.
> >
> > --
> > Jeremiah Wilton
> > http://www.speakeasy.net/~jwilton
> >
> > > Sybrand Bakker <postbus_at_sybrandb.demon.nl> wrote in message
> news:<a544gu8u780pfqar6isgdp51sud8m9ru09_at_4ax.com>...
> > > > On Sat, 08 Jun 2002 06:30:36 GMT, "Jim Kennedy"
> > > > <kennedy-family_at_attbi.com> wrote:
> > > >
> > > > >Bad idea. Just use export and import.
> > > > >Jim
> > > > >"Yong Huang" <yong321_at_yahoo.com> wrote in message
> > > > >news:b3cb12d6.0206070941.72956f15_at_posting.google.com...
> > > > >> But more interesting is the test of reusing the same datafile
> between
> > > > >> WindowsWhatever and Intel Linux (has to be Intel Linux, not Sparc
> e.g.
> > > > >> due to byte ordering). Can anyone do this test? If that succeeds
> which
> > > > >> I doubt, then we can try Windows and True64.
> > > > >>
> > > > >> In any case, all these are unsupported. Somebody I know had a plan
> to
> > > > >> write a program to directly modify datafiles to support
> cross-platform
> > > > >> datafile move. Not sure about his progress. That's even more
> > > > >> un-supported!
> > > > >>
> > > > >> Yong Huang
> > > > >
> > > >
> > > >
> > > > Not only that: unprofessional advice. Will Mr. Yong Huang assume
> > > > responsibility if someone following this advice screws up or does he
> > > > have a very good lawyer?
> > > > There is also no difference between 'unsupported' and 'even more
> > > > unsupported'. If I would know the e-mail address of the Oracle Legal
> > > > Affairs department I would forward this post so they can sue him.
> > > >
> > > >
> > > > Regards
> > > >
> > > >
> > > > Sybrand Bakker, Senior Oracle DBA
> > > >
> > > > To reply remove -verwijderdit from my e-mail address
> > >
> > >
> > >
> > >
> >

I second Jim's view point and would like to add this to it.

I am a cautious person and do not like to muck around with my Production databases when the expected uptime is required to be at 99.9%. I like to do things in Production whatever is thoroughly tested and proven and comes from the horses mouth...in this case Oracle. This is what my company pays me for to keep the system up and running at 99.9% of the time. Now this does not mean that new technology should not be tested. I do it all the time BUT I always advise to do it in test environment. If one has to do it in Production...better take a backup or it will bite you in the rear end.

When an advise is given in a forum like this where a question is posed by a junior DBA or Software Developer...then it is incumbent upon the person giving advise is to use best practices.

If someone out there can develop a tool to replace exp/imp and is thoroughly tested and proven, then more power to them and I will consider using it, until then, I have no choice but to stick with what works best i.e. exp/imp. Received on Wed Jun 12 2002 - 10:50:48 CDT