AIX to Linux OS Migration for Java Stack Only

[Former Member]

I have spent some time surfing SDN and SAP's information on OS/DB Migrations but I haven't found everything that I'm looking for. If I have overlooked a relevant thread, please point me to it.

Our Project: We are considering the migration of Java ASs from AIX to Linux. We have no plans whatsoever to move or change the DB platform or DB server OS. We have no plans to move any of our ABAP ASs. All of the Java ASs under consideration are standalone systems (i.e., not part of a dual-stack system).

Question #1. The following statement on SAP's OS/DB Migration FAQs leaves me with more questions than answers: "Java-only components may be migrated without the restrictions that apply to the OS/DB migration of an ABAP system. Further, Java components are not covered by the SAP OS/DB Migration Check." Obviously this says that the normally required SAP OS/DB Migration Check is not relevant. But what is the first sentence telling me exactly?

Question #2. For anyone who has undertaken such a migration personally, what other caveats do we need to consider? During the migration? After the migration? This is our early adoption of Linux as a SAP platform so anything specific you can share regarding SAP Java AS on Linux (on VMWare) is a plus.

Thanks in advance.

[former_member189725 · Accepted solution]

I would suggest you the following method .

1. Start sapinst and select :database and central instance for AS JAVA system.

2. Check "Use database specific method"

3. Prepare the target host and import udding sapinst.

4. Select "database specific method". This would basically import the filesystem contents which are persitent such as the SDM repository . Make sure you enter the database specific inputs in sapinst same as the source system so that the db can be connected and the migration toolkit can change all the relevent entries of the source system with the target.

Hope this answers you the process.

For standalone java systems , migration check service from SAP is not available as per my experience , but you can always raise an OSS message to confirm from SAP if there is one .

[nicholas_chang · Accepted solution]

Hi,

In addtion to Marcus and Raj, you can try dualstack split tool. From the tool, it allows you to export your JAVA (file content) with option either "move" or "keep" database. Technology use is same as system copy, where jload will use to export db.

Although dualstack split is mainly for dual stack, since it works like system copy, logically it should able to run only on just JAVA stack. You can download and play with it, is like a sapinst.

Bear in mind that dualstack split support NW7 SP14 above -> NW EHP3.

Cheers,

Nicholas Chang

[Former Member · Accepted solution]

I want to make sure I understand your recommendation to use the DB-specific migration. Since we are not migrating our DB to another DBMS platform, OS platform or even another AIX node, your recommendation is basically a way to re-install a Java AS on the target system and then reuse the existing DB. We would need to manually re-deploy any custom built applications, correct? Thanks for this reply.

[Former Member · Accepted solution]

Also a very interesting approach. Though not in the scope of this project, our Solution Manager systems are dual stack and this is important imformation for us when it comes to splitting that system. I will look into this option to see if there is any advantage over the other two suggested methods. Appreciated.

[markus_doehr2 · Accepted solution]

> your recommendation is basically a way to re-install a Java AS on the target system and then reuse the existing DB.

Exactly this does not work in the Java case because parts of the engine are stored in the database and parts on filesystem. If you "install" a new system and put then an old/different database underneath the system will not work.

Another approach could be: install a new system including the database on a Linux with the export you've done on AIX. Then "just" redirect the JDBC data sources (and TNSNAMES) to point to the old/original database.

Markus

[nicholas_chang · Accepted solution]

Hi Samuel,

In Dualstack split notes, it specially state that it doesn't support "split" on solman and PI.

However, if you download and play with DualStack Split, you will know is possible just to export the JAVA Schema and sdmkits, its file system contents.

There is not much info on dualstack split tool, however, below is the overview:

1) DualStack split works in seperate sequence - Export the Java schema and its file system, with option "Move Database" or export just the JAVA file system contents with option "Keep Database"

2) Once exported, Dual stack split will not automatically delete your JAVA schema. You can install/ import the exported dump to JAVA target server.

3) If every works well on your target, now, you can delete JAVA database (here is the real splitting) from your dual-stack with DualStack Split tool again.

Hope it helps.

Cheers,

Nicholas Chang

[nicholas_chang · Accepted solution]

Hi Markus,

Exactly this does not work in the Java case because parts of the engine are stored in the database and parts on filesystem. If you "install" a new system and put then an old/different database underneath the system will not work.

>> correct me if i'm wrong, it will works if sapadmin knows how, what and where to change the necessary setting, eg: node ID and etc?

Cheers,

Nicholas Chang.

[markus_doehr2 · Accepted solution]

> >> correct me if i'm wrong, it will works if sapadmin knows how, what and where to change the necessary setting, eg: node ID and etc?

...if the sapadmin knows, which part are synchronized from the filesystem to the database and vice versa and acts accordingly, maybe. Never done it this way because it requires too much manual editing which is not supported officially. It may leave things behind that later during upgrades/SP installations will cause problems (burned child dreads the fire), so I go for the "official" way to avoid any discussions with the support in case of an error.l

Markus

[Former Member]

Thanks to all for helpful insights. We have decided to attempt a migration on our own and we'll see how it goes.

[markus_doehr2]

Normal operating system/database migrations require a certified consultant to be on-site since a lot can go wrong when just "the defaults" are used. Those consultants have specific knowledge about databases and the migration process itself, that's why it is a requirement, to have them if you migrate ABAP systems (http://service.sap.com/osdbmigration).

For Java systems this is different, here is not so much the database and the migration time a factor but the JDK used.

If you haven't changed the default JDK on your AIX system now to the SAP JDK you are using the IBM JDK. The JDK you will use on Linux is the SAP JDK which has its roots in the Sun JDK (vs. the AIX/IBM JDK).

If you migrate now an instance from AIX to Linux the Java parameters will change. This means that you can do the installation but it will not come up after having done so. You will need then to start configtool and adapt the parameters according to the newest note version for the Sun/LInux JDK.

So basically you will have to do the following:

- start the newest sapinst on the source system (AIX) and start the system copy process for a Java instance, do NOT select the "database specific method"

- after the export is done you will have to delete the schmema on the database that held the data for the Java instance

- you start then sapinst on the target (Linux) system and select the system copy option. You will have to configure the database connection to the "old" database

- the installation will create a schema, import the database content and install the Java instance

- you will need to adapt the parameters as decribed above manually until the instance can be started

Be aware of the fact, that later you need to backup database and Java instance (/usr/sap) at the same time on the two machines, otherwise you risk an inconsistency because a Java instance does not store everyting in the database but also on filesystem.

Having a separate database server on a separate operating system makes things in case of recovery quite complex (though not impossible). Since JDBC is used to connect to the database it's technically irrelevant where the database resides, however, having two separate boxes makes things not easier.

If you want to migrate to Linux I would migrate the whole instance including the database. Databases on Java stacks are pretty small usually and don't require much database tuning or special handling.

Markus

[Former Member]

Is an OS Migration Consultant required for a Java AS migration? Yes for ABAP AS but for Java AS? I think Java AS only qualifies as "abnormal", but I can't yet determine if an OS Migration Consultant is required.

For the Java landscapes under consideration, both are already running the SAP JDK or will be before we undertake the migration. Both are very small systems, barely 10% over the initial install size. I'm relieved to hear that the migration assistance is more in support of the JDK change than OS/DB work.

Thank you for the process description. I am also going to reply to the next response in this thread to better understand why the follow-on suggestion was to use the DB-specific migration approach. I suspect your recommendation is the safeguard approach that will work regardless of backend changes. Again, much appreciated.

The concern regarding DB and filesystem recovery is noted. There is no good solution for this currently, even on a single OS instance. As a former UNIX admin, there is no good way to duplicate the point-in-time recovery capabilities of a DB at the filesystem level. (Yes, filesystem snapshots help solve the problem.) Fortunately for us, we do very few (3 or 4 per year) deployments to our Java AS systems and 99% of the data used by the Java AS is transient, non-critical (Landscape Data in SLD) or configuration settings.

We are planning to keep our DB servers on AIX because: 1) Oracle licensing on VMWare is out of scope for this project; 2) We have all the necessary infrastructure and knowledge for hosting Oracle DBs on AIX in-place; and 3) We recover very little resources compared to the effort to migrate the DB to another OS platform.

[Former Member]

Great information presented here. But does anyone know if an OS Migration Consultant is required for a Java AS migration? If so, is that mainly for SAP support during the migration? Or is this something that would cause SAP to not support your system post-migration?

[nicholas_chang]

I dont think it required for JAVA migration, as the database and its file system contents usually small. If everything goes well, export & import will just take less than 1 hour (however, it still vary on the resources & db size)

I just completed my blog on Java Migration with dual-stack split or sapinst. You can have a read if interested.

hope you find it needful,

Cheers,

Nicholas Chang

Edited by: Nicholas Chang on Jan 17, 2012 6:10 AM