Re: Upgrade to 8.1.6 - Advice sought from DBA's

In our last gripping episode Liz Reen <lizr_at_geologist.com> wrote:
> In article <39F43B9B.61E2_at_yahoo.com>, connor_mcdonald_at_yahoo.com
 says...
> > jane_ballard_at_my-deja.com wrote:
> > >
> > > Platform: Windows NT, service pack 4.
> > > Database 8.0.5 for oracle
> > > Upgrade 8.1.6 for oracle.
> > >
> > > Sent via Deja.com http://www.deja.com/
> > > Before you buy.
> >
> > Certainly if you can put up with the down time, then an
 export/import is
> > a great way to go, mainly because :
> >
> > a) you can optimize your sql.bsq in 8.1.6 using the 8.0.5
 dictionary as
> > a source
> > b) your indexes will all be rebuild which will make them quicker
> > c) you can take this opportunity to turn compression on your indexes
> > which should improve your range scans
> > d) your data will be packed better by the reload process
> > e) you can change any pctfree/pctused settings as you go
> > f) you can move to locally managed tablespace (which are
 fantastic!),
> > which immediately "solves" any fragmentation issues that you may
 have
> > had.
> >
> > Many of us DBA's have to do the plain 'ol migrate option simply
 because
> > the database can't be down,
>
> If you can't be down, now is the time to convince management that you
> need a development/test server. You are assuming that the code which
> works on 8.0 will work on 8.1. Not always true. You are running NT,
 so
> another server is not so expensive. It would be another story if you
> were running on a million dollar server. (HP N class with EMC drives
> comes to mind as an example.)
>
> > if there is insufficient space or time to do
> > it...but with a little careful planning you'll be able to reload
 your
> > data in a very close to optimal fashion, and never have to reorg
> > again...ever.
>
> You will not have to reorg ever if your data does not change and you
 get
> right the first time. Tuning is a process not a one shot deal. If
 you
> had a development box and a chance to load the data several times,
 you
> could come up with the optimal solution. What is optimal for a 1000
 row
> table may not be so good when it grows to 100,000 or 1,000,000 rows.
>
> Liz
>
> >
> > Have fun!
> >
> > HTH
> >
>

Wise words from a wise DBA.

--
David Fitzjarrell
Oracle Certified DBA


Sent via Deja.com http://www.deja.com/
Before you buy.