Migrate Central instance from 32-bit to 64-bit

[Former Member]

Hi All,

We have SAP in Distributed Environmnet( Central Instance running on 32-bit windows & Database instance is running on 64-bit AIX).

Since there are lots of memory dumps , we have decided to upgrade Central instance from 32-bit to 64-bit windows.

We don't want to disturd database instance as it is alredy running on 64-bit.

Please share your thoughts to accmplish this task.

Thanks in advance

regards

Venu

[Former Member]

Ah ... during this migration, it'd also be nice to migrate your CI to a virtual name. This way, for future migrations, you won't have to change the profiles.

If you decide not to migrate to a virtual name, then make sure you adjust the default and instance profiles to reference the new server name for CI.

If you decide to migrate to virtual name ...

1. Assign 2nd static IP to your server.

2. Insert your virtual name in the following registry and reboot:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0 > create new multi string variable with name "BackConnectionHostNames" and put as value the virtual name.

yourHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters > create new multi string variable with name "OptionalNames" and put as value the virtual name.

3. Adjust the c:\windows\system32\drivers\etc\hosts to include mapping of 2nd static IP to the virtual name.

4. Map your virtual name to the secondary static IP in WINS.

5. Make sure you rebooted the server. Log into the server and do a "net view virtualname" and "net view physicalname", both should be successful. Do not continue until this is successful, most problems are caused by DNS vs WINS, some corporations need the mapping in DNS and not WINS, some the otherway around.

6. Change the user variable to include SAPLOCALHOST and SAPLOCALHOSTFULL, set both to the virtual name.

7. Adjust the start and instance profile of the CI to include SAPLOCALHOST and SAPLOCALHOSTFULL.

8. Cycle the SAP NT services to make sure the new user variables are adapted.

9. Adjust all default and profiles to adapt to the new CI.

10. Adjust STMS to use new CI name.

And, you can also migrate DB to a virtual name as well using the same registry entries. Except DB name doesn't require it's own IP, so it can share the same IP as the physical server. Adjust the user environment variables and SAP profiles afterwards to adapt to new virtual name.

[Former Member]

1. Install and prep the 64bit windows environment. (e.g. make sure the sys user has the proper access).

2. Copy the sys user environment variable from 32bit to 64bit environment.

3. Copy the \usr\sap directory from old 32bit to 64bit environment.

4. Replace the kernel directory with 64bit version from service.sap.com.

5. Run the sapstartsrv.exe in the kernel directory to create the SAP NT service.

6. Run this to create SAPOSCOL: sc
64bitservername create "SAPOSCOL" binPath= "drive:\pathtokernel\saposcol.exe service"

7. Adjust the CI instance profile to limit heap and extended memory per work process. Because you are now 64bit, if you don't change these parameters you'd end up w/ a single user being able to allocate ALL The memory on the server, bringing it down to it's knees. Here's what we have:

dialog instances (1.5 GB max per process):

abap/heap_area_dia = 500000000

ztta/roll_extension = 1000000000

batch instances (4 GB max per process):

abap/heaplimit = 50000000

abap/heap_area_dia = 2000000000

abap/heap_area_nondia = 2000000000

abap/heap_area_total = 16000000000

8. Start the new CI and login as SAP*

9. Run slicense and get the hardware key. Get new license from service.sap.com/licensekey

10. Install license.

11. Run RZ10 > import profiles.

12. Adjust RZ03 and 04 as needed.

13. Adjust SMLG, RZ12, SM13, SM61 as needed.

14. Reset hostname buffer (entire system, using transaction SM51) in all up and down stream systems.

Done.

PS. Yes, I do this in my dreams.

[markus_doehr2]

Just to add:

> 2. Copy the sys user environment variable from 32bit to 64bit environment.

You miss the registry... I would not "copy" but rather "install" a clean instance and adapt it. Windows is a bit different here than on *NIX where you can really just copy everything over

Markus

[Former Member]

> Just to add:
> 
> > 2.  Copy the sys user environment variable from 32bit to 64bit environment.
> 
> You miss the registry... I would not "copy" but rather "install" a clean instance and adapt it. Windows is a bit different here than on *NIX where you can really just copy everything over 
> 
> 
> Markus

Nah, registry is automatically updated when you cycle the SAP NT service.

PS. To the original poster - When you run sapstartsrv.exe, make sure you check the box to use user environment variables.

[markus_doehr2]

> Nah, registry is automatically updated when you cycle the SAP NT service.

The CONTENT of the keys - yes - but not the permissions...

Markus

[Former Member]

> > Nah, registry is automatically updated when you cycle the SAP NT service. 
> 
> The CONTENT of the keys - yes - but not the permissions...
> 
> 
> 
> Markus

Sure - but this would only be a problem if the SAP sys admin is not an O/S admin right? Majority of the people out there have the SAP Admin as the O/S admin, it's just easier. Unless you really want to lock down the O/S level security. As for the permissions being, ok, then just add it back in?

Bottomline = I just really really hate using SAPINST, it's really really bad and I've had a lot of bad experiences with it

[markus_doehr2]

> Majority of the people out there have the SAP Admin as the O/S admin, it's just easier.

Oh - really.. the security guys would tell me other things if I would dare to run an application with administrative rights. "Easier" or not - that's out of question, security is rarely convenient

> Bottomline = I just really really hate using SAPINST, it's really really bad and I've had a lot of bad experiences with it

Early versions of sapinst were bad - yes - but the new versions (SR2 and above) are really really good - they have only a very few issues. Most of the issues caused by sapinst are not correctly configured operating systems, at least that's my experience.

SAPINST does a bit more also, it will add OPS$-users (and permissions) to the database, configure the SQL*NET, install the database client... If you know what's necessary then it's certainly a way to go doing everything by hand. If not, then, well - that can become a frustrating experience...

Markus

[Former Member]

> 
> Early versions of sapinst were bad - yes - but the new versions (SR2 and above) are really really good - they have only a very few issues. Most of the issues caused by sapinst are not correctly configured operating systems, at least that's my experience.
> 
> SAPINST does a bit more also, it will add OPS$-users (and permissions) to the database, configure the SQL*NET, install the database client... If you know what's necessary then it's certainly a way to go doing everything by hand. If not, then, well - that can become a frustrating experience...
> 
> 
> 
> Markus

completely agree on the stability of newer SAPINST, but having being burned before and now having a way to manually do a lot of this stuff (and quickly as well - What I mentioned above about moving CI can be done in about 15 minutes. ), I find myself still leaning against using SAPINST. However, I'll have to use another wonderful tool by SAP shortly, sapup, for our 4.7 > ERP 6 upgrade this weekend ... cross your fingers and wish me luck!

While we are talking about installations, have you tried the TREX install for ... I believe version 6? Lol ... oh my, no amount of asprin in this world can cure the headache is causes.

[markus_doehr2]

I find myself still leaning against using SAPINST. However, I'll have to use another wonderful tool by SAP shortly, sapup, for our 4.7 > ERP 6 upgrade this weekend ... cross your fingers and wish me luck!

The new upgrade tools are very good too! Our upgrade to ERP 6.0 last year in november was the easiest one I made (we initially started in 1996 with 2.2D).

>> While we are talking about installations, have you tried the TREX install for ... I believe version 6? Lol ... oh my, no amount of asprin in this world can cure the headache is causes.

yes - but what´s worse than sapinst is TREXAdmin.sh )

Markus

[markus_doehr2]

- Install a 64 OS

- install a "new CI" on that system and adapt the parameters according to the old one

Markus

[Former Member]

Hi Markus,

Thanks for your reply.

I am worrying about database which is 500GB in size.

1) While installing new CI on new 64-bit machine, what would be the status of old CI?

2) How the new CI will communicate with existing Database instance which is running on another server? Do I need to setup any parameters?

3) If install new Dialog server on 64-bit , does it resolve memory dumps eventhough CI is running on 32-bit windows?

Thanks in advance

Regards

Venu

[markus_doehr2]

> I am worrying about database which is 500GB in size.

> 1) While installing new CI on new 64-bit machine, what would be the status of old CI?

The easiest way of installing a "new CI" would be to install a dialog instance and configure it to also run message + enqueue server.

You have, of course, to shut down the old CI.

> 2) How the new CI will communicate with existing Database instance which is running on another server? Do I need to setup any parameters?

Certainly, the CI must know how to communicate with the system.

> 3) If install new Dialog server on 64-bit , does it resolve memory dumps eventhough CI is running on 32-bit windows?

Since I don't know any of your memory dumps I can't tell.

Markus

[Former Member]

Hi,

Below are the dumps , sap suggesting to go for 64-bit.

1)STORAGE_PARAMETERS_WRONG_SET,

2)TSV_TNEW_PAGE_ALLOC_FAILED

If I install dialog server on 64-bit does it resolve above issues when CI is running on 32-bit.

Regrads

Venu

[markus_doehr2]

Those are indeed typical errors on 32bit platforms. However, those errors may also occur on 64bit platforms if the amount of memory needed is higher than configured.

The reason for those dumps should be analyzed (why is so much memory allocated). If someone does e. g. a "select * from mseg into itab_mseg" that problem can occur on a 64bit system as well.

Do those dumps occur in standard programs?

Markus