BW Performance & troubleshooting role

Question

Dear SDN!
I would like to know is it advisable for an rather inexperienced certified BW person to be deployed solo to a major customer who needs someone experienced to look into the cause of the BW performance and other problems experienced by users and within the system itself?
I reckon this calls for skills in BW360, not part of BW solution scope. As you know my technical background, I may be able to provide some value but as this is BW, and performance characteristic is different than R/3, would it be advisable to be gungho and accept such an assignment solo? Client has its BW support but not able to solve the problems.
Also, what are usually the causes for BW performance issues and cause customers to be unhappy? Appreciate also if you experts could advice on what are the functional aspects to look into or that I should know when handling such issues.
My gut feeling is I don't feel comfortable about this assignment as I would be deployed overseas on contract.
I have mentioned in interview that I am looking for a junior bw role and prefers functional activities. But this is what I get. Being alone in a faraway land without own company people to leverage on seems daunting to me.
Seeking your advice / comments.
bworbust

Answer 1

Hi ,
Before you prepare to travel my suggestion is to go thruogh the implementations that had already gone live because it gives you enough experience to handle the things .You are a certified professional use that experience in the implementations and dont forget that we(SDNer's) are always there to help you.
Regarding the performance issues some of our Experts wrote..
INDEXEs  : The indexes that are created in the fact table for each dimension allow you to easily find and select the data
see http://help.sap.com/saphelp_nw04/helpdata/en/80/1a6473e07211d2acb80000e829fbfe/content.htm
COMPRESSION :  when you load data into the InfoCube, each request has its own request ID, which is included in the fact table in the packet dimension.
This (besides giving the possibility to manage/delete single request) increases the volume of data, and reduces performance in reporting, as the system has to aggregate with the request ID every time you execute a query. Using compressing, you can eliminate these disadvantages, and bring data from different requests together into one single request (request ID 0).
This function is critical, as the compressed data can no longer be deleted from the InfoCube using its request IDs and, logically, you must be absolutely certain that the data loaded into the InfoCube is correct.
see http://help.sap.com/saphelp_nw04/helpdata/en/ca/aa6437e7a4080ee10000009b38f842/content.htm
PARTITIONS :  by using partitioning you can split up the whole dataset for an InfoCube into several, smaller, physically independent and redundancy-free units. Thanks to this separation, performance is increased when reporting, or also when deleting data from the InfoCube.
see http://help.sap.com/saphelp_nw04/helpdata/en/33/dc2038aa3bcd23e10000009b38f8cf/content.htm
Additionally you can see a lot in service.sap.com/bw -> Performance.
You can also find the detailed hardware and tests in a white paper on www.sap.com/bi -> Brochures and Whitepapers -> Scalability with SAP Business Information Warehouse
Hope it helps you......
Regards
Lisa