SolMan 3.1 (32bit) to 4.0 (64bit) Upgrade on Windows/Oracle - Advice needed

[Former Member]

Hello all,

I post this here as I can no longer find an Upgrade forum - I'm sure there used to be one!!!

We currently run SolMan v3.1 on aged 32bit hardware and we plan to upgrade this to SolMan v4 on a new 64bit infrastructure. As part of this task, we would also like to move from Windows 2000 to Windows 2003 x64 and from Oracle 9.2 to Oracle 10.2

The current situation is that the new server is built to Windows 2003 x64 level only. Nothing else is installed on the new server at this time. My plan was to install Oracle 9.2 and SolMan 3.1 and then take a system copy of the existing database and then upgrade it to SolMan v4 and Oracle 10.2 (leaving the old system as-is for recovery reasons, should we run into problems).

Has anyone any experience of doing this in a Windows and Oracle environment who could help me with getting this right?

Many thanks,

Arwel Owen.

[Former Member · Accepted solution]

Hi Arwel,

That is the way I see it. You may need to download some fixes to the installation tools for SAPINST to install on Oracle 10. Check the OSS notes. Apart from that, just follow the SAPINST instructions. It offers you the option of installing your own export.

Shehryar,

32 bit to 64 bit of same OS is homogeneous copy.

Cheers, Barry.

[Former Member · Accepted solution]

Hi Barry,

We've started the process and have run into a slight problem (I think we both suspected we might ;o))

Here's an update on where we'e at:

We have installed Oracle 10.2 and applied 10.2.0.2 Patchset 1, which all seemed to finish correctly. We are now installing Solution Manager (v3.1), but SAPinst crashes out at the stage where we specify the SAP system directories and transport host. The error message is:

<b>ERROR: MDB-06168. Oracle is not installed on this host. Install Oracle before continuing.</b>

My guess is that for some reason SAPinst does not recognise this version of Oracle. Have you any idea how to get around this?

Many thanks,

Arwel.

[Former Member]

Hi Arwel,

Have you downloaded the latest SAPINST for your kernel version ?

OSS note 857734 does say that you need Solution Manager 3.2 SR1 to install directly on Oracle 10, but I thought the only difference between Solman 3.1 and 3.2 was content, and not the underlying technology.

Is it WAS 6.40 you are installing on ?

Cheers, Barry.

[Former Member]

Hello Barry,

I tried to download the latest SAPinst (6.20), but failed miserably to find it. Plenty of SAPinst 6.30 SAPinsts, but no 6.20. I'll try again this morning. If you can find a link to it, let me know.

I was consdiering last night whether I should try installing SolMan 3.2 (because it's supported with Oracle 10, as you say), under the assumption that the only difference is content. If the latest SAPinst version doesn't work, I'll try this approach.

The last thing I tried last night was to take copies of KEYDB.XML and ORADBPAR.XML and edit them so that they also contained entries for AMD64 and (Oracle) 102; not just I386 and 920 in an attempt to force the install to recognise the processor and Oracle version. This didn't work either.

Fortunately, this is only a test install, so the time constraints aren't too important, which gives us the opportunity to try all options. If all else fails, we'll start again using Oracle 9 as a basis as first intended.

Thanks for your help,

Arwel.

[Former Member]

Hi Arwel,

As long as it is just the Oracle release that is changing, and not the OS or RDBMS, then it is classed by SAP as a homogeneous system copy.

Cheers,

Barry.

[Former Member]

Hi Barry,

Thanks for clarification. So does this mean that a change from 32-bit windows to 64-bit windows is not an OS change???

It is very correct that as far as R3load/JLoad are being used and not Oracle specific procedures (as outlined in System Copy guides for NW2004s), its a homogeneous system copy. But what about a change from 32 to 64 bit?

[Former Member]

Hello Barry,

Just to confirm that I've understood this correctly, I intend on the following sequence to get from SolMan 3.1 (32bit) on Server A to SolMan 4 (64bit) on Server B.:

Install Windows Server 2003 x64 on Server B (already done)

Install Oeacle 10.2 (64bit) on Server B

Install a vanilla SolMan 3.1 install on Server B (assuming it'll allow installation on Oracle 10.2 - it's officially not supported on SAP's PAM).

Export the source database using R3load on Server A

Import the source database using R3load on Server B

Upgrade SolMan 3.1 to SolMan 4 (64bit)

.... and job's a good 'un??

Would you agree?

Arwel.

Message was edited by:

Arwel Owen

[Former Member]

Hi Arwel,

Its a straightforward process, as long as you use SAPINST/R3load for the export and import, not native Oracle tools. Not only does the DB not need to be at the same release, it does not even need to be the same RDBMS. You could export from Oracle and import into SQLServer or MaxDB using the same tools. The process is described in the system copy guides. I have migrated several systems form Oracle 8 to Oracle 9, and one from Oracle 9 to Oracle 10, and it works a treat.

Basically R3load creates a OS/DB independent DB export, in exactly the format that SAP provide the exports on CD/DVD for new installations. They are the same tools as SAP themselves use to create installation exports.

Best Regards,

Barry.

[Former Member]

Hi Arwel,

Your plan is sound and there are no pitfalls that I can see. The only thing you may consider is, rather than install Oracle 9.2 and upgrade to Oracle 10, you could install Solman 3.1 and Oracle 10, then use the R3load method to export the source system DB contents and import them to the target DB. This will save you an Oracle upgrade and also tidy up the DB at the same time.

Best regards,

Barry.

[Former Member]

Hello Barry,

I've ran exports/imports in the past but only between the same version of Oracle. Have I understood you correctly in that you're saying that I should be able to export an Oracle 9 database and then import directly it into Oracle 10? If so, is this just a straight export/import or are there any additional steps involved?

Many thanks,

Arwel.

[Former Member]

This seems to be a heterogeneous system copy process and a case for migration. I'd suggest checking with SAP about their recommendations in such cases, especially for Production systems.

For more information, please check out https://websmp104.sap-ag.de/systemcopy -> Explanation of Terms, https://websmp104.sap-ag.de/systemcopy -> Procedures, and https://websmp104.sap-ag.de/systemcopy -> Media Library.

Regards

Message was edited by:

Shehryar Khan