Migration of Oracle 7.3.4 database under HPUX 10.2 to Oracle 8.0.6 database.

[Rosalyn Bush]

We are having trouble migrating from 7.3.4 to 8.0.6. The application running does fine under 7.3.4 with respect to performance. As soon as we go to 8.0.6 we have performance issues in loading data to the database. Anyone having problems with this? If so, what did you do?

[Steve Slade]

Rosalyn,

We have upgrade from 7.3.4 to Oracel 8.0.5.2.2, under 10.20 and have found no problems. Can you give some more information with regards to what you are experiencing? I am assuming that you are refering to SQL_LOADER in your initial statement.

[CHRIS ANORUO]

You should have a minimum of 1Gb RAM, 3 processors (PA 8200 CPU), SWAPSPACE , above 2.5Gb. Kernel parameters retuned to accommodate the upgrade. See attached documents.

[Rosalyn Bush]

Steve:
We are not upgrading to Oracle 8.0.5, but going to 8.0.6. This is on a K-class machine by HP. We currently have 8.0.6 running on a smaller K-class machine with only 2 cpu's compared to the larger one with 6 cpu's. We get slow response on the smaller K-class machine due to memory constraints. But on the larger one, which we expected to see some improvements, we got none. We have also tried splitting the database off onto another even larger machine (N-class), and we still have the performance problems. Thanks for your offer to help.

[Rosalyn Bush]

Chris:
I forwarded your attached notes to our DBA's. I believe for the most part that they have reviewed these things....I think that somewhere we have a pointer that is pointing to the wrong Oracle Home directory or something like that that may be causing the access to the database problems. They just bought Quest monitoring tools, but I don't know how helpful that has been. Do you have a suggestion for some monitoring tools that may give us better insight as to the performance degradation? Thanks for your help.

[Rosalyn Bush]

Steve:
I wasn't referring to SQL_Loader, in my ignorance of these things, it may be using it in the application. I am guessing that the database access is having trouble because it uses a version of SQLPLUS to access it. As far as technical knowledge of these things, I have none...our DBA's are struggling to find out why we are having these problems. We have taken benchmarks on our smaller machine on 7.3.4 and 8.0.6 and very little difference shows up in our load to the database. However, when we did it on the larger machine, 7.3.4 zips right along, and 8.0.6 loads at a snails pace. We think it may be pointing to the wrong version of Oracle or SQL.
Thanks for your help.

[Alan Riggs]

We just completed an upgrade to 8.0.6 in our development environment and will be upgrading production this weekend.

We have not seen any performance degredation to date (K580 6CPU systems). I will pass this on to our DBA, though, and post again if we see any similar issues.

[Dave Chamberlin]

I would suggest two things - first try to identify the performance bottleneck using top or glance, etc. GlancePlus (gpm) is especially useful for this. How much RAM do you have? If there is free memory and the system crawls, you may have an IO problem. If you are doing a lot of swapping, you may need more RAM. You should also use SAM to look at your kernel parameters - there will be differences between 8.x and 7.x. Search the forums for "kernel" should lead you to posts covering that topic.
Second thing - are there a lot of batch jobs running in the database? Going to a box with more CPUs is not a guarantee that the database will respond better to users. In fact batch jobs may be running so well, that they are causing a I/O bottleneck, that will make the system slower than it was before.

[Dave Chamberlin]

I would suggest two things - first try to identify the performance bottleneck using top or glance, etc. GlancePlus (gpm) is especially useful for this. How much RAM do you have? If there is free memory and the system crawls, you may have an IO problem. If you are doing a lot of swapping, you may need more RAM. You should also use SAM to look at your kernel parameters - there will be differences between 8.x and 7.x. Search the forums for "kernel" should lead you to posts covering that topic.
Second thing - are there a lot of batch jobs running in the database? Going to a box with more CPUs is not a guarantee that the database will respond better to users. In fact batch jobs may be running so well, that they are causing a I/O bottleneck, that will make the system slower than it was before.

[Dave Chamberlin]

I would suggest two things - first try to identify the performance bottleneck using top or glance, etc. GlancePlus (gpm) is especially useful for this. How much RAM do you have? If there is free memory and the system crawls, you may have an IO problem. If you are doing a lot of swapping, you may need more RAM. You should also use SAM to look at your kernel parameters - there will be differences between 8.x and 7.x. Search the forums for "kernel" should lead you to posts covering that topic.
Second thing - are there a lot of batch jobs running in the database? Going to a box with more CPUs is not a guarantee that the database will respond better to users. In fact batch jobs may be running so well, that they are causing a I/O bottleneck, that will make the system slower than it was before.