Move from K260 to N4000 - peripherals

[Don Bentz]

We have a K260 running HPUX 11.0 with 2 AutoRAID boxes. We will be replacing it with an N4000 with an FC60 with 3 SC10 enclosures. We will probably run the 64 bit version on the new machine. The K260 is running Oracle Financials on a 7.3.4 database. I think I might be able to attach the AutoRAID boxes to the new server, import the volume groups and bring up the database. I know this may seem perhaps a simplistic and naive plan. Any feedback would be greatly appreciated.

[A. Clay Stephenson]

Don, I don't think it's going to be quite that easy. Even moving the oracle executables from one 10.20 K box to another 10.20 K box almost always requires a relink of the oracle executables (oracle, sqlplus, svrmgrl at a minimum).
I think you will need to install the 11.0 version of 7.3.x (if memory serves me only the 32-bit version is available but that should be fine.)
The good news is that the data will be compatible provided that exactly the same pathnames are used.
A fallback position would be to consider going to 8.0.6 or 8.1.6 or 8.1.7 although there you would have to do a full export on the old box and a full import on the new box.
When I was my oracle moves I was fortunate enough to have a dedicated sandbox environment to test everything before doing the real thing.

[A. Clay Stephenson · Accepted solution]

Don, I'm an idiot I somehow misread your K-260 as a 10.20 box. Yes, I think it will work though you will probably have to relink. Again, when you import your volume groups and mount the filesystems make sure that you keep the same filesystem mountpoints.

[boley janowski]

Hey Don,

I assume the AutoRAID boxes are useing either single-ended scsi, or Fast-Wide-Dif scsi of some type, anyway the 50 or 68 pin type of conncetors to the k-box, the N-box you will be getting will have an ultra-2 scsi connector, you will either need a cable that can cross over to the ultra-2 type or you will need to order a card for the N-box that will allow you to connect to the type you are already useing, unless your using fiber with the AutoRAID boxes, inwhich case you'll need to have a free fiber channel to plug you autoRAID into. However if you can get the connection you should be able to import the volume groups and move the data as you need. Keep in mind that the ORACLE 7.3.4 database was desupported at the beginning of this year and unless you have a killer contract with them any problems you have with oracle and need support will cost you dearly. If possible I would look into upgradeing oracle before, i dont recall but you may run into some issues with the 64bit version of hpux and such an old version of oracle. Good luck.

[Don Bentz]

CLay, Boley. Thanks for your responses. They were both helpful. Clay - We figured we'd have to relink but our thought was that if we could bring up the database on the new machine, we could then move datafiles around at our leisure and minimize the impact on the user community.
Boley - Your input regarding the connections is very valuable. Thanks again.

[Tony Willis_1]

We recently went from a K580 to an N4000/550.
We decided to to "clean up" the entire system.
Only active users.
Increase throughput.
Try different Physical extent sizes and stripping configurations.
Increase SGA size.
Restore Oracle to the new system, instead of moving.
Kernel tuning.
Result was 45% oracle performance improvement on average.
We spent three weeks loading, removing, starting over, but,
the results and user positive comments made it worth the effort.

Sometimes the only time people clean their garage is when they move.

I have two great DBA's(ex-SA) and life is good.
Do GOOD.

[Alexander M. Ermes]

Hi there.
What we have done in this kind of situation :
Create new databases ( 64-bit )on the new system
( 8.0.5 )
Move the application over ( is it 10.7 char mode ? )
Relink the application and set links to the old paths ( 7.3.4 ).
Rgds
Alexander M. Ermes

[Don Bentz]

Tony - Yes, I agree it is a good idea to "clean up". We hope to get the machine in several months before we need to come up in production and will be doing tuning/testing/etc, but once the testing is done we need to take a new copy of the production database and get down to business as quickly as possible. Did you measure these performance improvements from your original configuration on the N4000 rather than the gains over the K580? Thanks very much for your input.

[Dave Wherry]

Don,
We did a similar move a little more than a year ago. We had a K570 on 10.20, SAP on a 7.3.4 oracle database that was about 150GB. This was on 2 Nike arrays. We had the same concerns of extended downtime.

We brought in a V2500 and an XP256. We connected the XP to the K570 and moved all of the database files over to the XP by mirroring the logical volumes. All on-line. Once the data was on the XP we saw an immediate performance gain.

The V2500 of course came in with UX 11.0. We did a cold install of the Oracle executables and cleaned up all of the user space. As others said it is a great opportunity to clean up.

We then vgexport'ed the database volume groups on the K and vgimport'ed them onto the V. That process of moving the database took about 10 minutes. We went from 10.20 to 11 and the import was seemless. You're going from 11 to 11. Should be easy. The key of course is that the database and executables are in different volume groups. We did not bring over any old executables from the K.

If you do not want to deal with the connectivity issues of your old disks you could build the new N box. Do an off-line backup of your database and restore it onto the N. Bring this new database up in recovery mode. Keep copying transaction logs from the K over to the N and applying them to the database. When you are ready for the cut-over, down the old database. Bring over the last logs and apply them. On an N this should only take a couple of minutes. You're up and running with minimal downtime.

[Don Bentz]

Dave, thanks for your thoughts, specifically the last section. The other ideas would be good if I wasn't already painted into a corner on the K260 (no available I/O slots). But the restore/recover using redo_logs idea is certainly a winner. Thanks again.