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.
