Dual Stack system copy problems on windows

[Former Member]

Hello Gurus,

I recently noticed while trying to do an OS Migration that our BI Production[ ABAP+Java ]  stack is not in synch with our BI Development & BI Quality.

Before I joined , the earlier consultant had built the BI Development system as a Pure ABAP stack, Though at the DB level I can see both the ABAP and Java schemas. Also luckily / unluckily for us, the Java stack is not used at all in the BI team.

Kindly note that once the BI DEV /QA systems are in sych with  the BI Prod , we intend to perform the Dual Stack Splitting using the Dual Stack Split Tool [SWPM]  before we perform an OS Migration, so eventually we would be only doing a ABAP stack OS Migration  and since the Java stack is anyways not used, reinstall a fresh Java stack on the Migrated OS .

Here are the details for the Platform

BI Prod     -  ABAP+JAVA Stack

OS- Windows Server 2003

DB - Oracle 11.2.03 [ Upgraded 6 months back]

BI Dev     -   ABAP Stack

OS - Windows 2003

DB -  11.2.0.3

Since this particular BI  Dev system is technically incorrectly built , Would like to rebuild this correctly to simulate the Dual Stack Split.

Please suggest if I am following the right approach or alternatively suggest a new method

1.  Java Add On on existing ABAP BI  DEV system  -  May not work as the existing Java schema at the OS level may get dropped ,

Also a Java Add On to an existing ABAP system may not be the same as a BI Dual stack system.

2. Perform a BI DEV  rebuild as a dual stack system using a BI Prod Backup .-  Backup Restore from BI Prod & Java Stack Export from BI Prod.

The System copy Tool [SWPM] does not support the windows 2003 OS , as it is lets you install /create new systems only on newer OS [win 2008  / win 2012] . So I tried using the old SAP system Copy tool  - NW2004s(7.0) _Installation Master [ predecessor of SWPM], this works fine on the Windows 2003 and however this installer doesn’t recognize the Oracle 11g Oracle Home which I installed and only gives an option for the Oracle 10.2

This means we are in a sort of deadlock  - 

new  SWPM tool – doesn’t work on the old Windows 2003 OS [ after OS rebuild on SBQ]

old BI_Inst_Master tool -  Works with the OS windows 2003 , but doesn’t recognize  the Oracle 11.2  , only gives option for Oracle 10.2 .

Additionally is our Migration approach of first Splitting the Dual stack system and then only Migrating the ABAP stack and then reinstalling the Java stack on the migrated OS feasible ?

Appreciate your help and patience.

Cheers

Prashant

[Matt_Fraser · Accepted solution]

Hi Prashant,

At first glance, I think I would probably approach this in a multi-step fashion. Your end-goal is to have a consistent landscape with split ABAP and Java stacks, right? And since your current DEV system was built by system copy from PRD, it probably doesn't hurt much if you overwrite it again with a new system copy. Is that right?  If so, then:

1. Set up three new servers (new DEV, new QAS, new PRD) with new OS, since Windows 2003 is running out of support anyway.
2. Using backup/export of PRD as the source, use SWPM system copy to install new DEV and QAS as dual-stack systems, just like PRD. After confirming all goes well, do the same to migrate PRD onto the new PRD server. Now all of your landscape is consistent (dual-stack) and on updated OS.
3. Use dual-stack split tool to separate Java stack from DEV, then QAS, then PRD, as you normally would and had been planning to do.

This way you get to test the dual-stack split properly, rather than going straight for it in PRD and possibly encountering risks.

I would not attempt to install a Java add-on to your existing DEV/QAS systems, as this would not end up looking like your dual-stack PRD system. Besides I'm not sure installing a Java add-on is a supported process anymore, anyway.

Regards,

Matt

[Former Member · Accepted solution]

Hi Matt,

Thanks for the quick and very detailed response, your approach sounds very good and logical , however I have a question regarding the step 2 i.e Using backup/export of PRD as the source, use SWPM system copy to install new DEV and QAS as dual-stack systems, just like PRD  on the new OS.

This is in my mind an OS migration and there are 2 points to consider

1. If are are using a Backup /Restore Method , then can the Oracle DB backup taken on windows 2003 be restored on windows 2008  , I am a apprehensive about this as there might be incosistencies.

2. If we use the R3load method of Export/Import, we need to export and Import both the ABAP & Java schemas , which would involve running the JMIGMON.

Since our Java schema is not used[empty]  , we do not want to do a Java stack OS  Migration and instead prefer to just install a new Java stack once we have migrated on the current OS.

How do we tackle this.

Is there an installer that supports the Backup Restore System copy of NW 7.0  on Win 2003 /Oracle 11g  [ upgraded] .

Regards

Prashant

[Matt_Fraser · Accepted solution]

Good morning Prashant,

This isn't really an OS migration, just an OS upgrade, which you need to do anyway. For system copy purposes, it's much the same from Windows 2003 to 2008 or 2012, etc (except, of course, for ensuring that your OS, DBMS, and NetWeaver versions are all compatible per the PAM). So, you can definitely use the "Database-Specific System Copy" procedure as described in the "ABAP+Java" System Copy Guide.

This means you will basically use database backup/restore for the ABAP/database portion of the system copy, and then use export/import for the Java portion. You could use pure "database-independent" procedures for the entire thing, but this typically takes much longer and involves more downtime on the production/source system. However, if you also want to do something like distribute your database across a larger number of disks, then this might be the opportunity to do that. However, that's a different goal and a different discussion.

I understand you're trying to drop the Java portion of your dual-stack system. However, you must either do a full dual-stack system copy, or you must do a dual-stack split directly in production before doing the copy. As I don't recommend performing a critical operation like a dual-stack split in production without testing it first in DEV and QAS, I suggest the first option, which is to do a full dual-stack system copy to create new, consistent DEV and QAS systems. Then you can do the dual-stack split on DEV, then QAS, then finally PRD, in a safe, consistent, tested manner.

Simply doing a system copy of the database and leaving the Java export behind is not a recommended approach for splitting a dual-stack system. This exposes you to the potential for numerous inconsistencies in your target system. I realize this is what your predecessor did to create your current ABAP-only DEV and QAS systems, but those systems still have a Java schema in the database, as you pointed out, and while they could no doubt be cleaned up, it's much safer to use the SAP-supported method of the dual-stack split tool.

So, to address your questions directly:

1. I'm not an Oracle expert (I work with SQL Server on Windows), but I am a Windows expert (or at least, I work in Windows a lot). I am quite sure that an Oracle backup taken on Windows 2003 can be restored on Windows 2008 without any issue. What will matter here is the version of Oracle, more than the version of Windows.
2. You won't be using the R3load method for the ABAP schema, but you will be using it for the Java schema, even though your Java schema is essentially empty. This is the best way to ensure consistency in the target system. The Java system export and import doesn't take very long compared to exporting an ABAP system. The SWPM System Copy tool will walk you through the procedure when you choose "database-dependent dual-stack" as your options.
   1. Once the system copy is complete, you can use Dual Stack Split tool to split off the Java schema, and then either eliminate, reinstall, or use the resulting separated Java system as you see best.
3. You already pointed out that the old, deprecated system copy tool does not support Oracle 11g, and the current SWPM tool doesn't support Windows 2003 (are you sure about this? I thought it did, but I'm not certain, so will go with your findings). So, I recommend installing a new system with Windows 2008 or 2012, then using SWPM to copy onto that. Windows 2003 is running out of support anyway, so you will need to do this very soon regardless. Might as well be now.

Regards,

Matt

[Former Member · Accepted solution]

Hi Matt,

Thank you for the very very detailed answer !! Appreciate you taking time out to post a very helpful answer. Sorry I took a long time to reply as I tried and implemented the whole thing before I replied.

Actually the purpose of this question was to build a BI   DEV system on Oracle 11g/Win 2003 as our earlier DEV system was a pure ABAP stack , i.e.  during the Import , my predecessor had chosen to import as a pure ABAP stack ( not a clean way to ensure an only ABAP stack).  Once the proposed DEV system was rebuilt as a Dual (ABAP+Java) stack in synch with the BI  Prod,  the plan was to that we would then take an export/import from the DEV and migrated to the newer OS [OS Migration].

But after going through your approach, we decided to abandon our approach in favor of your better approach as the end goal was to  have a dual Stack system built on the Upgraded Win 2008 OS  and your method helped us to do this in a single step rather than the 2 step approach which we had initially. Whether to split the dual stack or not was a step of the future.Your analogy was spot on , from a system copy perspective and an Oracle Backup/Restore perspective there isn't much difference when it comes to Backup on Win 2003 vs Win 2008.  As long as the DB versions /patches are identical, the Backup /Restore worked perfectly.

We followed the Backup/Restore procedure from the Database dependent method from the ABAP+Java System copy guide as we could not have a downtime for the Productive instance.

In addition to this , we took the Java stack Export as suggested , this only involved a 20 min downtime for the BI Prod Java stack , and this wasn't a problem a Java stack was is not being used.With regards to using the export/import method, you are right in saying that a DB export would redistribute the datafiles  and perhaps also achieve a DB reorg of sorts, but we are going in for a DB Migration to Sybase ASE (our ERP landscape is already migrated) within the next 2 months and this would be accomplished when I export/import our DB into the Target DB, so we are good with this DB size for now.

Since we were considering various prospective methods , we did consider performing a                 1. Java Add On on the BI Landscape ( which is on Win 2003 and is an older release and the (SAPINST) installer still supports the Java Add On option(newer SWPM doesnt support a Java ON) . However this posed some problems as it was an Inconsistent way of building a dual stack as there was already a Java schema in the DB, so a Java add on would either drop the existent schema and recreate a new one or alternatively there would be a conflict that the schema already exists and possible errors during installation.                                                                                           2. BI DEV rebuild on Win 2003 via a Backup Restore from BI Prod and then export/import this to the new upgraded Win 2008 .  But in this approach the old Installater [SAPINST]  on Win 2003 doesnt have an option for Oracle 11g and only prompts you to install a Oracle 10 G  DB version [It doesnt seem to detect an already installed 11g either], so one needs to install the system via backup restore as a 10 g system and then upgrade [ bad idea, too much work  as source system BI Prod was already upgraded to 11g]. Also Unfortunately the newer Installer [SWPM] has a OS version mismatch .

Also we didnt want to perform a critical operation like a DSS in production without testing it in DEV and QAS first.

Once the BI DEV system was built from a Backup/Restore of the BI Prod system and the Java stack was imported as well during the System build from the BI Prod Java Export , we had a Dual stack system .

I then split the Dual stack system and we now have 2 instances, a BI pure ABAP stack and a shiny new Java Stack with a small database ( we decided to move the DB instead of an MCOD).

I have 1 further question, as we are drawing up plans for the BI Migration from Oracle to Sybase ASE, I would like to only perform the ABAP DB migration as we did for the ERP landscape and leave out the Java stack, and instead install a fresh Java stack on Sybase ASE which will connect to the migrated Backend ABAP system.  Is this a feasible DB Migration plan, I am not sure if doing a java stack DB migration is worth the trouble and time(as it is unused).

I learnt from this experience that sometimes the obvious /easiest approach isn't always the correct method.

Thank you for showing me the way.

Cheers !!

Prashant

[Matt_Fraser · Accepted solution]

Hi Prashant,

Thanks for getting back with the result of how it all worked, as that's the best validation, no? I'm really glad it worked out for you, and it seems you have a good foundation now for the migration and other work you have planned.

With regard to whether you need to keep/migrate your existing (new) split-off Java instance, or whether you can just install a fresh, clean, new one on Sybase ASE, I can't say for sure, but given that you haven't been using the Java instance to this point, presumably there's no customization or significant configuration in it that you need to keep. Therefore, I would expect there is no reason you couldn't just abandon the old one and install a fresh new one when you're ready on the new DB platform. In fact, I think that's a better idea, as it's much more likely to be clean and well-functioning when installed fresh with the latest tools, versions, etc.

Regards, and happy holidays!,

Matt

[Former Member · Accepted solution]

Hi Matt,

I agree without validations, we couldnt have confirmed our concept. Thanks for all the help.

At the moment, since our Java stack [which was newly split off from the dual stack]  tallies with the original source BI Prod Java stack in terms of  number of objects in the schema level, so I take this as a good enough sign . The BI functional team confirms that there is indeed no usage of the Java stack, so we can safely say that the newly built Java is good too.

Will have to wait till the Sybase migration to check if the newly installed Java only stack can integrate seamlessly into the migrated ABAP only BI stack  and we might have to select the same usage [ as AS JAVA, BI JAVA and EP CORE] to ensure Java stacks here and on the migrated DB are the same.

But I too feel, Java migrated will un neccessarily complicate things when its actually not needed and installing a fresh Java only stack to connect to the migrated ABAP may the best course of action, but time will tell

Thanks again for all your help and time.

Merry Christmas and a Happy New year ahead !!

Cheers,

Prashant

[Reagan]

Hello Prashant

As the Java stack is not used (by the BI team) then there is no point in doing a stack split. Like Matt said this not a migration. What you can do is setup the target server and install the Oracle 11G database software. Start the sapinst on the target server for the target system installation and instead of doing an export and import you can do backup and restore. During the target system creation using sapinst select the option for database specific option. There is no issue in restoring the database backup taken on Windows 2003 to Windows 2008. What matters is the Oracle version. As you have the source system on 11.2.0.3 you should install the same patch set on the target server and restore the database. To get rid of the Java stack from the database you may drop the Java schema after the restore on the target system.

Reagan

[Former Member]

Hello Reagan,

Thanks for your helpful answer. This did cross my mind, when I first rebuilt the BI DEV on Win 2008 and saw the Java schema at the DB level, my gut instinct was to drop this schema altogether.

While I agree with you that there is no point in doing a Dual Stack split, however we are slated to upgrade to BI 7.4  in Jan and we don't want to miss out on features due to the lack of our Java stack, so we would like to keep the stack , however we'd like to keep it as an isolated stack not directly affecting our BI ABAP stack.

And thanks for the approach regarding the system copy via Backup/restore on Win 2008. It worked like a charm like Matt and you suggested.

Thanks a lot for helping out.

Cheers

Prashant