OS/DB Migration from Windows to Solaris

[Former Member]

Hi there,

I am afresh when it comes to OS/DB migration in SAP system landscape. We have ECC6.0 with Oracle 10g running on Windows Server 2003. We are in the process of procuring SUN Servers and we have to migrate ECC6.0 to Solaris 10. I know about the OS/DB Migration Analysis Check with SAP and I am aware that in this scenario, we have to perform a Heterogeneous System Copy.

I have formulated a strategy (theoritically) and just need to confirm whether it will work (I have already done System Copies using both Homogeneous as well as Heterogeneous Methods):

1. Perform an export of source database using Heterogeneous System Copy.

2. Install Solaris 10 on the new hardware (target server).

3. Install Oracle 10g on the target server.

4. Perform an import on the target server using Heterogeneous System Copy.

Your help will be highly appreciated.

Regards.

Herbinger

[Former Member · Accepted solution]

Hi Wolfgang,

I would install Solaris first, then Oracle software on Solaris server and do then export and import. But nevertheless your approach would work.

Regards

Ralph

[markus_doehr2 · Accepted solution]

I would install Solaris first, then Oracle software on Solaris server and do then export and import.

The only OS where Oracle is installed BEFORE the installation is Windows. On all other *nix operating system you need to start with sapinst, provide the Oracle DVD paths when requested. They are unpacked into a staging area. SAPINST creates the users and environment and then stops to install the database using a special script with a response file (RUNINSTALLER - in capitals - not runInstaller!). This will install the database software.

I would do it like this:

- install the very latest dboraslib.dll, R3load, R3szchk and R3ldctl on the source system

- start sapinst and select "Lifecycle Management - system copy"

- select the "load based" export

- provide enough space (about 10 % of the source systems size)

- use max. 2 R3load processes per CPU, split the export into smaller packages (faster). You may need to repeat that to find out the optimal package size and number of parallel R3loads

- then start sapinst on the target system (after having adapted the Solaris parameters according to note 724713 - parameter settings for Solaris 10), also select here "Lifecycle Management - system copy"

- select "advanced options" in the R3load dialog (on the page where you enter the migration key)

- check that R3load has the load option "-loadprocedure fast" set

- provide all necessary other information to sapinst until it stops to install the database

- install the database software using RUNINSTALLER (will be version 10.2.0.1)

- after that install the latest patchset 10.2.0.4

- install all interim patches according to note 1137346 - Oracle Database 10g: Patches for Release 10.2.0.4

- download the very latest patches for R3load and dboraslib.so from the SMP for Solaris and install them

- and then continue with sapinst

- sapinst will create the database, execute the Oracle scripts and starts loading

- during the load rename the file "startsap" (to e. g. startsap.orig) in the executable directory to prevent the system from starting

- after sapinst stopped because of being unable to start the system, step into the profile directory and set the parameter rdisp/wp_no_btc to 0 so no jobs will be started when the system starts

- rename startsap.orig back to startsap

- continue with sapinst (retry)

- after sapinst finished logon to the system (you will get a dump START_CALL_SICK because of the missing batch processes, ignore it)

- execute program BTCTRNS1 to suspend all jobs until you´re finished with configuring the database

- stop the system

- adapt the Oracle parameters according to Note 830576 - Parameter recommendations for Oracle 10g, make sure you set all events and FIXCONTROL parameters and also the memory related parameters

- take a full offline backup of the database

- during the backup update your kernel to the latest one and also install all the other patches (dw* etc.) that were created after the full package SAPEXE and SAPEXEDB

- when the backup is finished start Oracle and the system

- execute program BTCTRNS2 to re-schedule all jobs

- DONE

Markus

[Former Member · Accepted solution]

Hi Mark,

Thanks, that was really helpful and much appreciated for sequence of steps.

Regards..

Raju

[markus_doehr2 · Accepted solution]

You're welcome.

Be aware of the fact, that if you follow the procedure alone without a certified migration consultant and you will have problems, you'll be on your own.

See http://service.sap.com/osdbmigration

Markus

[Former Member · Accepted solution]

Hi Markus,

I appreciate your crystal-clear approach while answering the question.

Thanks again.

Regards.

Wolfgang.

[Former Member]

Your approach is good, by the way, is Solaris a must or is just one of the options you have?

I don't have good experience with SUN but this was probably a salesperson error.

[markus_doehr2]

I don't have good experience with SUN but this was probably a salesperson error.

I could say: I don´t have good experiences with Windows - even if 50 % of the SAP customers use it there are good (technical) reasons to not do so

No everyone is happy with "clicking" (I prefer scripting) and the 4-weekly security updates and further reboots, the necessity of having a firewall in front of the systems (and so more work) or even running virus scanners on the SAP database servers (which is a total no-go for us).

We were running our SAP systems for a long time on Windows before we migrated to Linux and Solaris and our necessary outages due to OS updates/problems were drastically reduced.

I´m not trying to start a flamewar which OS is "better", it´s just the fact, that not everyone is jumping onto the Wintel bandwagon just people think they are "used to it" and it´s "easy".

If you have a 64bit machine you can even install Solaris x86_64 in parallel to Windows and see yourself

Markus