In day 4, we learn about a bit about SAP BW extraction and loading and how to improve performance. So basically, the rule of thumb for extraction and loading is that, for full data load, you have to delete the index first before loading, and recreate it after that. Because, it will be much slower to extract and load data when indexing exist.

For, incremental loads, again depends on how much the difference is, if it's more than 20% of the original data, then you might as well just delete the index.

Also, when you do BW extraction and loading, bear in mind that the more "customized" rules you have, be it routines or just formula, either in transfer or update rules, the more will it affect performance.

Another thing, for loading, you should also 'tweak' the package size in the infopackage scheduler. This package size will determine the size of each packet transmitted during extraction.

On day 3 of SAP BW 360 - Performance and Administration, we learn about aggregrates.
What the heck is an aggregrates? Well, in short, it's just another mini
cute little infocube, which further aggregrates the bigger infocube.

Well it means that, let say you have A,B,C and D characteristics. So, in the minicube, it will combine, for example, A,B characteristics only. Which means that, if the infocube has like 5 Million records, the minicube might contain, say 10K records. When you're querying the cube for A,B characteristics, instead of reading the whole 5 million records, it will query the smaller mini infocube reading 10K records. Which results in better query performance.

Yeah,yeah, it's good and all, but, aggregrates takes extra storage space, and maintenance could be hell. Considering you have to run the 'attribute change run' to propagate any changes of master data to the aggregrates mini cube.

So how do you know which characteristics are a good candidate for aggregrates? The answer my friend lies in the power of SAP BW Statistical Information! After the BW is in production for quite sometime, BW will gather some useful statistics which you can use to tune performance. This also includes which characteristics combination is used the most. This characteristics combination, is a good candidate for aggregrates. So, you can let the system propose to you which aggregrates to create, but you have to ensure that the statistical information of each cube is activated.

Or for a truly 'SAP BW Master', you can use your awesome power of foresight to predict which characteristics is a good candidate for aggregration!

In day 2, we learn about connection source system to SAP BW. In short, if possible, use DB Connect. When connecting to some 'arcane' source system, use UD Connect.

But, the most important of all, is that we learn that to design a good Infocube , you must design it to become a "balanced" star schema cube. What that means is that the cube must have the following traits:

• Small dimensions
• Few dimensions
• Only as many details as necessary
• Hierarchies only if necessary
• Time-dependent structures only if necessary
• Avoid MIN,MAX aggregation for key figures in huge Infocubes
• Balance the permutation, or 'cardinality' of each dimension. Each dimension must be 'balanced'.

There. Bottomline is, designing infocube is an 'art'. Not exactly an exact science.

We also learn about transporting in SAP BW. You click 'here', click 'this', package blah blah blah, anyway, again, the bottomline is, becareful about transporting, because there's a 'feature' call BEx transport that has the habit of automatically transporting objects that has been flagged 'transportable'. What it means that, it is possible that any changes you did to a query object that has already been made transportable(especially global objects) in the development server, there's a highly probability that the changes will propagate to the QA server or even the PROD server. Which means 'hell' is coming through!

So that's it folks. I'll continue with Day 3 update.

Sorry for this late entry. Yeah2, I know I'm suppose to post a daily update of the training, but it seems that the instructor has the habit of not allowing us to surf while 'listening' to his/her teachings.

Anyway, in Day 1, we learn overview of performance, some 'boring' SAP BASIS stuff (I nearly fall asleep during this time) and some more stuff. In general, what we learn is that, to be a good BW consultant, you must have a little bit of functional, application, technical, and a little bit of ABAP. He also reminds us that there's no such thing as an all-knowing 'superman' SAP BW consultant. To be that, you have to ammassed an awful lot of knowledge which is simply not possible for mere mortals.

So, a good SAP BW implementation, must consist of many people with different skill set as mentioned above.

Also, in Day 1, we learn about the evolution of BW underlying architecture. It seems that SAP BW has evolved a lot. From having a Basis 4.6C to Web AS 6.40. From ITS to IGS.
Basically, to make it short. With that kind of evolution, SAP BW is most probably a 'mutant'.

K. I guess that's about it. I'll post later, since our last day training is about to start.

Tomorrow, I'll be attending the BW 360 performance training. Finally, I'll some stuff about BW process chain yada yada. I'll try to update the blog daily on what I learn the whole of next week. So, stay tune for more.

In other unrelated notes, I'm at the stage where I no longer like going all "ga-ga" over SAP like I used too. I think it's just another tool, and like any other software, it has it's flaws and shortcomings. Like all things in life, when you've become used to it, the 'magic' that you felt the first time, will cease to exist.
SO that's that.