rp7410 server with oracle 3.0F and oracle 7.3.3.4

[Ashraf_1]

Hi all,

We would like to purchase a new rp7410 server and move our SAP 3.0F database to it instead of the existing K360 server. Anybody knows if this possible or not and what does it need?

With best regards,
Ashraf

[Pete Randall]

Ashraf,

Of course it's possible - it's just a question of how much work it's going to take to get there.

The rp7410 is going to be running 11i, so my first question would be if your SAP and Orcale installations will need to be upgraded to newer versions as well. Since I use neither SAP nor Oracle, I'll leave it to someone else to answer that question.


Pete

[T G Manikandan]

What OS are you running?

[Massimo Bianchi · Accepted solution]

HI,
i moved a SAP 3.1i/Oracle 7.3.4 from a cluster Vclass/K570 to a two partition rp7410.

Oracle 7.3.4 is unsupported, as all we know, but works on 11.00 and 11.11 with no problem.

I implemented it with SAP in memory windows.

THe only problem i found was some shared memory not cleanly released, but we worked around with some cleanipc and ipcrm scripting.

You cannot fresh install the oracle 734, you must copy an existing working oracle.

Any other doubt ?

Massimo

[Steven E. Protter]

It would be a good idea to keep the old server running while you do the following:

Migrate the application to the highest, most stable version of oracle that you can.

Your database support clock is ticking and this is the perfect time to plan and execute a migration.

SEP

[Ashraf_1]

Thanks All ,

"Massimo",

What are the files that you copied when you moved oracle 734?

Regards,
Ashraf

[Massimo Bianchi]

Hi,

mine was a SAP/Oracle, so all oracle binaries were under

/oracle/SID

that is the oracle_home, obviously excuding the sapdata. We were moving to the new architecture, so i copied all with SAP/Oracle down.

But if you need a reference list, simply exclude

sapdata*
origlog*
mirrlog*
sapcheck
sapreorg
saptrace
saparch
sapbackup

from what you are going to copy.

Check also if you have:
-/etc/listener.ora
-/etc/tnsnames.ora (they were used in earlier release of SAP/Oracle)
-/etc/oratab
-/var/opt/oracle/??? (used for orainventory)
- where is the real tnsnames.ora, if there is a TNS_ADMIN variable.
- if $ORACLE_HOME/network/admin files are link to anything outside the oracle_home

More at OS level:
- /dev/async file, do you use aync I/O ? old and new server ? permission and ownership
- setprivgrp MLOCK on dba group, source and destination server ?

list may also be longer, but i put out the major things we encountered clonig those server.


A simple tar/fbackup worked it out, keeping the same userid/gid.

Remember that, once copied, you will no longer be able to add any patch, because the orainst do not work under 11i. So, if you need to add some bugfix (if aby comes out) you must have the original server under hand.

When i did that work we were aware of all these limitations, but it was an intermediate solution, before going to 817 (and not to 92).

Massimo