Skip to Content

Background:

I love problem solving. I solve several problems every month as a part of my job. I have not been doing a good job in documenting the solutions I found. I have decided to change and start contributing to SDN community. In this blog, I would like to explain my thoughts on how I am planning to do that.

Title of Blog:

                      AHA! Moments Series 

Frequency:

I expect to release at least one blog every week. However  this largely depends on whether I solved problems during the week and time.

Format:

The format of this blog will be as follows:

AHA! Moment: This will explain the lesson learnt. This could be iI will try to keep this very short. This would be a “do’s/don’t’s” type of statement.

Why: This section will give details why the moment was AHA! moment.

Example: This section will describe an example used to come up with AHA! Moment.

AHA! Moment:

After initiating source system upgrade, don’t move transports or make changes to source system and any system connected to it.

Why:

Recently we experienced inconsistencis for BW objects in one of production source systems (ECC6) after upgrade. And it took more than a week to discover the cause for inconsistencies

Example:

1) ECC6 System Name: R3P (Production System)

2) BW system Name   : PBW (Production System)

3) R3P is source system for PBW.

We upgraded R3P. This took more than a week and we used “Downtime Minimized” approach. We decided not to move any transports in ECC6 landscape soon after upgrade started.

After upgrade, we tried to load master data for one of extractors. PBW displayed an error stating that the transfer structure was inactive in the source system R3P. Further analysis in R3P showed that some metadata tables contained data for inactive extractor and other metadata tables didn’t have enrties.

We checked upgrade logs and found that around 500 tables were dropped in original schema and replaced them with tables from shadow instance. These tables in shadow instance were created before downtime minimized phase started. For few days, we had two copies of 500 tables, one in primary instance and other in shadow instance. During that time, BW landscape moved a transport to activate extractors in PBW. This transport indirectly created transfer structures in R3P system and added new entries in primary instance. During downtime-minimized phase, some of tables touched by BW transport were replaced by the tables in shadow instance. This caused the inconsistencies.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Gokul Muthuswamy
    Good job on the blog series.

    My experience on this though is vastly different, we have gone through the same downtime minimized approach for say 3 version upgrades and probably about 10 sp level upgrades over 4 years and we never encountered issues, as in case the ECC system is the first one to come up and we usually allow transports to go thru, if the queues have been cleared then I guess we shouldnt be having ne issues.

    (0) 
    1. Bala Prabahar Post author
      Thank you Gokul.

      I never experienced this issue as well;this time, however, we were forced to postpone downtime phase for 2 weeks. In other words, we started the upgrade – uptime portion ran for 2 days, we were planning to continue with downtime phase immediately after that;however, due to reasons beyond our control, a mandatory freeze was introduced all of a sudden for 2 weeks; As a result, we notified the team not to move any transports in R/3 landscape for the following two weeks;continued with “downtime” phase two weeks later. During that two weeks freeze, BW team moved transports in BW landscape. One of the transports activated tr structures in R/3 system.

      (0) 

Leave a Reply