<div>
dbua &nbsp;- &nbsp;the database upgrade assistant should walk you through most of it.<br />
<br />
The 10g upgrade guide is a must read as well.<br />
<br />
After upgrading, download the patches to get up to 10.2.0.4 before using the db.<br />
<br />
Or, upgrade to 11g, but don't stay on 10.2.0.1
</div>


<div>
just curious...why should not nutrino stay on the 10.2.0.1 db?
</div>


<div>
There are some questions. &nbsp;I was the 8i dba several years ago but then moved on to do more applications and pl/sql and less dba database maintenance. &nbsp; So please bare with me if I ask stupid questions.<br />
First when migrating the old name server will still have the database name and therefore it seems to me <br />
1. step one install oem on new machine.<br />
2. Now here is the tricky part or maybe not the new machine upgrade application must see the still active database or the production database being migrated must be taken out of the old oem name server and entered on the new oem on the new server. &nbsp;At this point the upgrade assistant should be able to see the old database to pull in. &nbsp;<br />
Once the database is migrated then the front end applications shiould be able to see it. &nbsp;At this point there will be an oem on the old server for non migrated databases and and oem on the new server for migrated databases, I am just guessing.<br />
<br />
Other questions on oracle 8i we put the index on a seperate drive than the data. Is this stlll the practice <br />
or under 10g is putting the index and data in the same table space more common. &nbsp;Again maybe a stupid question but just asking.<br />
<br />
It seems the upgrade process particularly when there are 7 databases for different uses, is a bit more involved. &nbsp;We have erp databases (different sub companies), web site database, datawarehouse ect.<br />
<br />
Also is it still the practice to have totally seperate databases? &nbsp;Again I have been out of the dba admin role and more in the application role.<br />
<br />
<br />
<br />

</div>


<div>
There are many, many bugs and performance issues in 10.2.0.1 that have been corrected in 10.2.0.4<br />
<br />
I wouldn't use oem for it at all until after the upgrade. &nbsp;<br />
I suggest you take a backup of your 8i db, &nbsp;restore it on the new server, possibly creating new control file if you need to move files around on the new server. &nbsp;<br />
Then run dbua to upgrade the db on the new server.<br />
<br />
You can also avoid the upgrade process altogether if you want.<br />
Take an export of your 8i db.<br />
Create an empty 10g db, upgrade it to 10.2.0.4 &nbsp;then import your 8i dump files.<br />
<br />
<br />
<br />
It was never a useful practice to separate data from indexes, not in 8i, not in 10g.<br />
Generally, in 10g, yes, &nbsp;You put all your data and indexes into one tablespace, with omf (oracle managed files). &nbsp;Relieves you of the tedium of file maintenance. &nbsp;Just make sure you have space on the server itself, and let Oracle manage the details of the files. &nbsp;Exceptions maybe for extremely large files or to segregate applications within the db, &nbsp;so each schema may get its own tablespace.<br />
<br />
Creating separate databases is sometimes necessary for vendor support.<br />
Or if the applications make extensive use of public grants and public synonyms (particularly the latter) then you may get namespace collisions if you combine. &nbsp;Other than that, it's generally easier and less resource intensive to manage one large db with multiple applications than multiple db's AND multiple applications.<br />
<br />

</div>


<div>
Thank you StStuber.<br />
But for your first suggestion, In order to restore it on the new server I would have to install 8i on the new server restore the database then install 10g on the same server?<br />
<br />
I can try the export, create an empty 10g, tried it once just to become familiar with 10g, upgrade to 10.2.04 then do an import but I saw some web notices about people having problems with importing into 10g from an 8i database, that is why I was interested in the upgrade utility.<br />
<br />
As for index table spaces, I can see your point, thank you, but from metalink it used to be at least ok at some time for some people to suggest a seperate table space. &nbsp; However I can see with new servers this may not be a good option, else why use clustered indexes as I recall. From metalink:<br />
25-Oct-02 16:42 <br />
Subject: Re : Index space usage <br />
Hi <br />
Usually Bitmap index requires less space when compared with BTree index. <br />
Its better to keep indexes in a seperate tablespace. <br />
Rebuild indexes, run the below query before and after index rebuild and note any substantial change in the size. <br />
<br />

</div>


<div>
yes, you would have to have 8i on the new server in order to do the restore there.<br />
<br />
The import/exports can be made easier by pre-creating your users and tablespaces for each user in the 10g &nbsp;db. &nbsp;That way the import won't try to create your tablespaces to look like they did on the old server.<br />
<br />
Also, versions matter.<br />
Do your export with the 8i exp &nbsp;and the import with the 10g imp.<br />
<br />
If you do it and get errors, post them here and we'll try to help<br />
<br />
As for metalink articles. &nbsp;I'm sure you can find lots and lots of places from reputable sources that recommended (and might still recommend) separating data from indexes, but it simply doesn't make sense to do so. &nbsp;In a multi-user environment you can't predict what data is being used by N-different people, so the thought of keeping the data and indexes apart inorder to reduce disk head movement doesn't apply. &nbsp;The heads have to move for my io away from there locations for your io which again is different from the 3rd users io and that's regardless of if the io is indexes or data. &nbsp;If the goal is to reduce contention for the same blocks, then it doesn't matter either because if we are running the same/similar queries and need the same blocks we'll collide whether they are indexes or tables. &nbsp;So separating them doesn't help there either.<br />
<br />
In a single user environment it still doesn't make sense &nbsp;because index and data reads are serialized. &nbsp;First, read the index then read the table. &nbsp;So you'll never get collisions.<br />
<br />
And lastly, any &quot;possible&quot; benefit from segregating them in the past is largely negated by modern storage systems with raid stripes and SAN's exposing virtual volumes. &nbsp;Putting object X on &quot;disk1&quot; and object Y on &quot;disk2&quot; doesn't really mean anything anymore, because &quot;disk1&quot; and &quot;disk2&quot; aren't really individual disks anymore, they are stripe sets and may infact share the same hardware anyway.
</div>


<div>
Thank you.<br />
I will test a few things out and then award you the points.<br />
<br />
Oh for 8i we actually set up seperate physical drives.<br />
<br />
But everything you stated is well taken and understood.<br />

</div>


<div>
<div class="content wysiwyg-content">
We have several databases all oracle 8i<br />
All our oracle 8i databases are on 2 windows 2000 machines<br />
We are using 8I OEM NAMES DATABASE.<br />
&nbsp;<br />
Our goal is to migrate all oracle databases one OR 2 at a time<br />
to<br />
Oracle 10g (10.2.0.1.0) on one windows 2003 server.<br />
<br />
What would be the best steps to follow for the migration or a good document to follow.
</div>
</div>


We have several databases all oracle 8i
All our oracle 8i databases are on 2 windows 2000 machines
We are using 8I OEM NAMES DATABASE.
 
Our goal is to migrate all oracle databases one OR 2 at a time
to
Oracle 10g (10.2.0.1.0) on one windows 2003 server.

What would be the best steps to follow for the migration or a good document to follow.

Oracle, 10g standard addition, 10.2.0.1.0

Oracle is an object-relational database management system. It supports a large number of languages and application development frameworks. Its primary languages are SQL, PL/SQL and Java, but it also includes support for C and C++. Oracle also has its own enterprise modules and application server software.