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

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
>
Received on Wed Nov 01 2000 - 16:03:01 CST