Skip to Content

Periodically, I look at SAP Early Watch reports.  Not cover to cover, too often, but more like drilling into specific sections, sometimes comparing one version to an older one to see trends that don’t seem to be easy to find in other ways, or to confirm a trend I spotted in another tool.  Last week, I looked at one section and saw an SAP note number and text that was unfamiliar.  The bad part was, it was a low number, meaning I should have seen it sometime in the past decade.

The note (17750) is titled “Workload: Time profile also for night hours”.  The Early Watch report text simply mentions, ” 24-hour monitoring can be enabled by implementing SAP Note 17750.”.  10 or so words in a 30 page technical report.  Should I have seen this earlier?  Before I answer that, I’ll talk about implementing it, and a later note that simplifies the matter.

For years, I’ve privately griped about the automated condensing of early morning and late evening hour transaction metric data into more-than-one hour bucket.  It’s collected frequently, then squished into unrecognizable and hard to trend data.  I could show you spreadsheet tricks I used to spread the data back out, but I won’t bother, since you either already know about this note, or the later one, or you don’t but you’ll apply it as soon as you can.

Our Basis team applied the note Monday in a sandbox system.  The next day, I could see that it worked as advertised.

 

Before

Interval Number of Steps T Response Time (s) Ø Response Time (ms)
19–20 306 287 936.6
20–21 307 319 1,040.40
21–24 937 936 998.6

 

You see how there are 3 hours worth of steps, and response time, between 9PM and Midnight?  It’s worse between Midnight and 6 AM.

 

After

 

Interval Number of Steps T Response Time (s) Ø Response Time (ms)
19–20 309 299 966.3
20–21 308 324 1,052.5
21–22 311 313 1,005.5
22–23 308 291 945.1
23–24 320 316 986.6

 

Problem number one solved.  The second problem is transporting this through multiple landscapes, because viewing sandbox data is nice, but production is where the, um, stuff is produced.  Before going further I thought I should check on SCN to see who else knows about this.  According to a query on the note number, there is one wiki page and 4 forum posts.  Not so much.

 

When I looked at the wiki page (search for it yourself), it looks very much like the other note I found (910897) “ST03N: Configuration of the time profile”.  Not much use for a wiki page that is less authoritative than the official note, to me.  That’s a blog for another day.  The newer note covers making the change via a menu program, rather than transporting a change, so 7.x systems are easier to customize, or repair, depending on how you view this change.

 

Of the 4 forum posts, 3 were relevant, two of which were marked answered, the latter of which incorporating a later “pile-on” message to the thread that wasn’t actually answered.  But I digress.  Could I have learned about the fix to cover 24 hours uniformly from any of these?  I doubt it, though if I was motivated and had plenty of SCN search tricks in my bag I might have.

 

Back to the question: should I have noticed this clause before?  I have paper copies of Early Watch reports going back quite a while, but the earliest I have in an online folder is from 2005.  Not in that one (phew).  Skip ahead to 2007 – not there either (double phew).  Jump one year to 2008. Urp, there it is.  I missed this little fix for over 3 years?! Wow, some obervationalist.

 

For illustration, here are the paragraphs in the “DB Load Profile” section of the report.

 

2007

 

The following table or diagram shows the DB load caused by Dialog, RFC, and Background tasks over different time frames.
The data given in the table represents the average number of database processes occupied by each task type in the database during the given time frames.
These statistics are calculated as a weekly average, which means the average values over six working days with a unit of one hour. Periods between 00:00-06:00 and 21:00-24:00 contain an average value per hour.
By comparing the load profiles for dialog and background activity, you have an overview of the amount of background activity during online working hours.

 

2008

 

The following table or diagram shows the DB load caused by dialog, RFC, and background tasks over different timeframes.
The data provided in the table represents the average number of database processes occupied by each task type in the database during the specified timeframes.
These statistics are calculated as a weekly average, which means the average values over six working days with a unit of one hour. Periods between 00:00-06:00 and 21:00-24:00 contain an average value per hour. 24-hour monitoring can be enabled by implementing SAP Note 17750.
By comparing the load profiles for dialog and background activity, you can gain an overview of the volume of background activity during online working hours.

 

2011

The following diagram shows the DB load caused by dialog, RFC, and background tasks over different time frames.
The data provided in the table represents the average number of database processes occupied by each task type in the database during the specified time frames.
These statistics are calculated as a weekly average, which means the average values over six working days with a unit of one hour. Periods between 00:00-06:00 and 21:00-24:00 contain an average value per hour as these are not considered core business hours. The disk space of the time profile is reduced by the default creation of these time blocks.
24-hour monitoring can be enabled by implementing SAP Note 17750. With 24-hour monitoring, the time profile returns the workload of the system or application server on an hourly basis rather than returning an average value per hour for periods between 00:00-06:00 and 21:00-24:00.
By comparing the load profiles for dialog and background activity, you can get an overview of the volume of background activity during online working hours.

 

Viewed side-by-side (or top-to-bottom), it’s possible to see the differences among the text blocks quite easily, which is why it is important to keep older copies of these reports and look back sometimes.  An acorn could fall on your head.

To report this post you need to login first.

4 Comments

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

  1. David Hull
    I can empathize with you – a search of my EarlyWatch Alert reports shows this OSS note is referenced in many of them (not on any NetWeaver-based systems, though), yet I had not previously seen it, either. Part of the problem with being around the SAP environment so long, as we both have, is that you get so used to things, both good and bad, you don’t think to look for the changes.

    I don’t know that I will implement this change, as I’ve never needed finer-grained access to hours of low utilization, but it’s certainly a good find that may be applicable to others that have high utilization during these time periods.

    Cheers,
    David.

    (0) 
    1. Jim Spath Post author
      David:

        I checked reports on our 7.x system as you suggested, and the boilerplate there does not describe how to switch to full hourly samples, meaning the fork to newer text was done on the older code (4.7 and earlier) and not pulled up into the current branch.  I’ve opened a ticket with SAP. Now to wonder how long the DRQ will take.

        I’ve wanted this for years, as we have 24 hour operations, and trying to find peak hours with mashed up data was challenging.

      Jim

      (0) 
      1. Bala Prabahar
        Jim,

        Is the source same for both ST06 and EarlyWatch report? I assume yes. If so, st06 shows actual values for all 24 hours on 7.x systems. Would that explain why “how to switch to full hourly samples” is missing? I assume full hourly samples is default behavior in 7.x systems.

        Bala

        (0) 
        1. Jim Spath Post author
          Bala:  No, not ST06. ST03.  SAP transaction metrics, not system level metrics.

          I will either expand this blog, or post a new one, after the fix sits in production for at least a week, and I’ll add images.

          Jim

          (0) 

Leave a Reply