Performance - navigation attributes

Hi,
we have a very bad performance with our reports, because we use many navigation attributes. So I want to disable those we don't need.
My question is: Do I have to delete the nav flag in the InfoObject where this navigation attribute was created or is it the same effect for a better query performance when i only disable the navigation attribute in the InfoCube and in the MultiCube (and keep it in the InfoObject active)?
thx
Robert

Hi Robert,
You only need to remove the nav attr from being used in your queries. If it is difficult to control that (due to many users creating their own queries) then you can uncheck the Nav Attr in the cube or mulitprovider. No need to change it at the InfoObject level.
Hope this helps...

Similar Messages

Poor Performance with Webi on top of BW - Large Navigational Attributes

We have recently developed a reporting model based on having a BW cube of approx 20 million records. This has 2 very large line item dimensions (one 14 million records, on 6 million records) that both have navigational attributes stored against them.
We need the design to be like this because the attributes change monthly and we do not wish to do a complete drop and reload of cube data each month (this takes 10-12 hours).
When we build a Universe on top of the cube and try Webi reporting the performance is dreadful - many reports time out completely. This happens whether or not the large line item dimensions are selected in the query. The BW query is very simple just 2 key figures and approx 30 Navigational Attributes as default values. No filters are applied.
For example a query that just contains Calander Year and one key figure either times out after 10 minutes or fails.
Our source of the data is Oracle tables and the same query runs in 2 1/2 minutes and the query runs in RSRT in approx 5 minutes with no problems so it is definately a problem with BOBJ to MDX to BW.
We are on BW7.01 SP5 and XI3.1 SP2. SAP have recommend going to SP3 and using query stripping to help with this but I doubt if this will work.
We have tried building aggregates, splitting into yearly cubes etc but nothing seems to help.
My question is do the large navigational attributes mean Webi simply can't cope with this?
Thanks

Thanks for the suggestions.
Although this did not directly help I've now found a solution.
We had a calculated key figure in the query that doing a count of records on a huge navigational attribute. This was causing all queries to run very slowly (even if the key figure wasn't selected in Webi).
Removing it solved the problem. Will have to find another way to do the count key figure.
Thanks

Performance issue... navigational attribute used

hi ,,
if navigational attrributes are used sytem performnce incerases or decreases ?
if so why?
regards
snigdha

Hi
Navigational attributes require additional table joins at runtime (in comparison to dimension characteristics) but usually the decision for dimension characteristics or navigational attributes is based on business requirements rather than on performance considerations. If your aggregates contain navigational attributes, a change run must be scheduled every time this master data is loaded.
Dimensional attributes generally have a performance advantage over navigational attributes for query operations. Fewer tables are joined to access the values of dimensional attributes than navigational attributes; therefore less overhead is seen during query execution. The requirements should be carefully analyzed to determine whether a certain attribute needs to be navigational or if dimensional or display attribute

Navigational attribute in Cube

Hi Gurus,
I want to understand one point before I am going to perform a small enhancement.
I need to set a navigational attribute in a cube(before it is not checked on "I/O") meaning make this navigational attribute behave as a char., but this cube contains data already, my question is :
can I make this change ? if yes any other additional effort?
Thanks in advance

Hi Ryan,
The attr needs to be marked and activated as Navigational Attr in the parent char first. Then you can mark it as nav attr in the cube (which contains the parent char). Does not matter if the cube contains data...you can do this activity in a cube with data. Remember to reactivate the cube's update rules and any multiproviders that it is a part of after you make this change.
Hope this helps...

How to add Navigation attributes values via ABAP while creation of CVC

Hi,
I have a requirement like, I have to add navigational attributes to the cvc record while CVC creation ( /sapapo/mc62 transaction).
There were two scenarios: 1. Usually when they load master data from BW side those navigation attributes available and when we do CVC creation it's automatically picks those values. If NOT then i have to bring Market segment and Business unit navigational attributes values from ECC via RFC function module by passing MPN and End customer division as a input.
I am facing problem when BW side if business unit and Market segment were blank.
Do we have any Function modules available to add navigational attributes data and should update corresponding master data tables.
Please help me step by step process on this.
Thanks
Ravi
Edited by: REDDY KALLURI on Jan 22, 2011 10:30 PM

Michael,
Are you intending this as a commercial solution or a work around?
To take an existing equivalent, one would build a view in the database tailored for each grid in an Oracle Forms application. Or a separate query layered over tables for each form/grid in a Delphi or Access application? Even if it is ninety nine percent the same over half a dozen forms/grids?
And now you've added a whole slew of "slightly different" rowSetInfos to maintain.
So if you wanted to add a column that needs to appear everywhere... you've just increased the workload multi-fold?
That would be a management nightmare, wouldn't it? Not to mention yet more performance cost and a slower system?
Hmmmm..... I'm not sure I like where this is headed... someone needs to do some convincing...
null

Attributes are not displaying in Navigational Attributes area of DSO.

Hi Experts,
I have created a DSO and have included Info Objects 0SOLD_TO & 0SHIP_TO. In the Navigational Attributes area, its attributes are not getting displayed even though the attributes are in the info object.
What are the steps needed to perform for it to display there?
Waiting for your reply,
Thanks in advance,
With Kind Regards,
Shreeem

Hi Shreem,
If you want attributes of any master objects in navigational attributes section, you have make them navigational attributes while defining base info object.
Please follow the below steps.
1) goto RSA1, search for 0SOLD_TO & 0SHIP_TO info objects and open them
2) goto edit mode of info object and goto attributes section.
3) here you will find for every object "DIS" --- this means these attributes are display attributes.
4) If you want to change any attribute to NAV, then click on "Pencil Mark".
5) Now you can see text NAV instead of DIS for that attribute.
activate the info object and goto DSO, now you will see that attribute in navigational attribute folder.
Regards,
Venkatesh

Variable on navigation attribute

Hi Friends,
Is it possible to create variable on navigation attribute?if possible we will face any kind of issues?give me u r ideas related to this
Thanks in advance,
kumar

You can create variable on a characteristic info object that is present in the cube and not on nav attribute.
Also, nav attributes are a performance dampener. If you can, try to put the characterstic in a dimension of the cube.
Ravi Thothadri

Navigational Attribute Clarification

Hi all,
I have gone thru the forum for this concept.
Still i have little bit confusion on this.
Wat i understood is, Nav Attr behaves like a characterstic in Reporting, wat my doubt is instead of creating Nav Attr why don't we go for Creating that as a characterstic.
If we create a field as a navigational attribute from where it fetches the data during the reporting.
If i created a fiels as a characterstic from where it fetches the data during reporting.
Please
Regards,
Madhu

Hi,
A NAV is already a characteristic.
I believe that your question is more: why don't we store the characteristic directly in the InfoProvider instead of reporting on a NAV.
Suppose you sell articles (the basic char; CAMCORDER XYZ)
Suppose each article has an attribute "STATUS" = LIVE or DISCONTINUED.
Now you load your sales in a sales cube; you post the selling date, the article ID and it's status. When the article has been just listed (in JAN) to your shop it has the status LIVE, so you'll post something like
JAN__CAMCORDER XYZ__LIVE__$100
Now the status is set to discontinued by a buyer in FEB. Still you sell the remaining pieces:
FEB_CAMCORDER XYZ_DISC_$2000
Interesting to see that your cube can tell the turn over of this CAMCORDER depeding on its status over time.
Now the buyers might be interested to report only on LIVE articles.
Obviously filtering a query on STATUS = LIVE will still show $100 turn over in JAN, even if the article is now discontinued.
This is when the NAV enters into the into the game. If you enable the attribute STATUS as NAV of MATERIAL in your provider and filter you query ON MATERIAL__STATUS = LIVE, the CAMCORDER XYZ won't show up anymore.
just adding: during reporting, the X table of your basic char will give the SID of your NAV. Reporting with NAV add joins between tables, which can impact performance if not tuned properly.
hoping this clear you doubts...
Olivier.
Edited by: Olivier Cora on Apr 9, 2008 10:10 AM

Line Item Dimension and Navigational attribute

Hi Gurus,
Can somebody tell me how line item Dimensions and navigational attributes works technically?
What are the pros and cons for them?
Regards
Alex

Hi Alex,
You will use navigational attributes based on how you want to track and report history. Let me explain with an example.
Customer Bubba is assigned Sales Group XYZ in Jan 2007. In July the Sales Group on the Customer Master record is changed to ABC. Your are looking at the sales report.
1). If you want to see all the sales made to Customer Bubba at the time of reporting (current) then you will use navigational attributes You will create 0SALESGRP as the navigational attribute of 0CUSTOMER . Then all sales to the customer will show up under Sales Group ABC.
2). If you want to see all the sales made to the customer at the time the actual transaction occured then you will add Sales Group as a characteristic of the InfoCube. Then sales from Jan - June 2007 will show under Sales Group XYZ and from July - Present will show under Sales Group ABC.
Performance issue occurs because navigational attribute is stored outside of the dimension table of the cube and is stored in separate master data tables. So query has to perform additional table read. So essentially there are advantages and disadvantages of usng navigational attributes. It is business requirement that will drive the use of navigational attribute.
Hope this helps!!!. Please assign points.

Loading Hierarchy levels as Navigational Attributes of 0MATERIAL.

Hello Guys, 
bit of background about the issue: 
I am loading 0MATERIAL hierarchy from ECC using 0MATERAIL_LKLS_HIER Data source.(IS Retail). this job runs very fast.
We have a 8 level hierarchy in ECC/BI and the lowest level of hierarchy is 0MATERAIL. I am also loading 0MATERIAL_ATTR from ECC. While loding 0MATERAIL_ATTR into BI, i need to populate each hierarchy level of an artcile as navigation attributes of 0MATERIAL. 
For this requiremetn i wrote a start routine in the update rules and reading hierarchy levels and node names from /BI0/HMATERIAL table. the problem is the performance of the extractor is very very poor. It runs for more than 10 hours every day and it is causing many problems for our transactional data loads. 
Here is the code i am using in my start routine. 
I need suggestions on improving the performance of this extractor asap. are there any other best practices to load Article hierarchy levels as attributes apart from using ABAP lookups?? any help will be appreciated. 
TYPES: BEGIN OF TY_HIER, 
 MATERIAL TYPE /BI0/OIMATERIAL, 
 HIER_LEVEL1 TYPE RSSHNODENAME, 
 HIER_LEVEL2 TYPE RSSHNODENAME, 
 HIER_LEVEL3 TYPE RSSHNODENAME, 
 HIER_LEVEL4 TYPE RSSHNODENAME, 
 HIER_LEVEL5 TYPE RSSHNODENAME, 
 END OF TY_HIER. 
DATA: GT_HIER TYPE STANDARD TABLE OF TY_HIER, 
 WA_HIER TYPE TY_HIER. 
DATA: LT_MAT_HIER TYPE STANDARD TABLE OF /BI0/HMATERIAL, 
 WA_MAT_HIER TYPE /BI0/HMATERIAL, 
 wa_hier TYPE ty_hier. 
DATA: l_nodename TYPE rsshnodename. 
* Retrieving the whole hierarchy table into an internal table 
SELECT * FROM /BI0/HMATERIAL INTO TABLE LT_MAT_HIER. 
* Looping at the data package 
LOOP AT DATA_PACKAGE. 
 WA_HIER-MATERIAL = DATA_PACKAGE-MATERIAL. 
* Sort internal table for binary search 
 Sort LT_MAT_HIER by iobjnm nodename. 
 READ TABLE LT_MAT_HIER 
 INTO WA_MAT_HIER WITH KEY IOBJNM = '0MATERIAL' 
 NODENAME = DATA_PACKAGE-MATERIAL 
 binary search. 
 Sort LT_MAT_HIER by nodeid. 
 WHILE WA_MAT_HIER-TLEVEL > 1. 
 READ TABLE LT_MAT_HIER 
 INTO WA_MAT_HIER WITH KEY NODEID = WA_MAT_HIER-PARENTID 
 binary search. 
* IF SY-SUBRC = 0. 
 SHIFT WA_MAT_HIER-NODENAME BY 3 PLACES LEFT. 
 CASE WA_MAT_HIER-TLEVEL. 
 WHEN '07'. 
 CONTINUE. 
 WHEN '06'. 
 WA_HIER-HIER_LEVEL5 = WA_MAT_HIER-NODENAME. 
 WHEN '05'. 
 WA_HIER-HIER_LEVEL4 = WA_MAT_HIER-NODENAME. 
 WHEN '04'. 
 WA_HIER-HIER_LEVEL3 = WA_MAT_HIER-NODENAME. 
 WHEN '03'. 
 WA_HIER-HIER_LEVEL2 = WA_MAT_HIER-NODENAME. 
 WHEN '02'. 
 WA_HIER-HIER_LEVEL1 = WA_MAT_HIER-NODENAME. 
 WHEN OTHERS. 
 CONTINUE. 
 ENDCASE. 
 ENDWHILE. 
 APPEND WA_HIER TO GT_HIER[]. 
 CLEAR WA_HIER. 
ENDLOOP. 
SORT GT_HIER BY MATERIAL.
 
Thanks in advance 
Cheers 
POPS 

Any other thoughts guys...
is there a standard function module where we can specify the lowest level article detail as input and request for level 1 - 5 values ??

Selection of charateristic value by using a navigational attribute

Hello all.
I'm working on BW 2004s with the integrated planning. I have this case: 0material has a navigational attribute - 0customer.
I have a variable on the navigational attribute (ocustomer) which prompts the user to select a customer. on the next step I would like to allow the user to forecast the values for the customer's relevant materials. this issue has a problem - since a BEx query acts as a filter - and if there's no suitable data in the cube - I won't be able to see the values in the rows so the user can perform planning.
Do any of you experts have a suggestion regarding a solution to that issue?
Thanks,
Tomer.

Tomer,
As Andrew suggested what you would need is "Master Data" option as compared to "Posted Values" option.
Hope this helps.
Cheers
Srini

Navigation Attributes & Planning Characteristics

Hi,
We plan to maintain some of the characteristics as Navigation Attributes. We understand that there are performance issues if we use navigation attributes in planning area.
I have a query: If we do not navigate data based on navigation attribute in interactive planning, even then the performance be low or only when we select navigation attribute in interactive planning?
regards,
Mohit

By definition, nothing is stored in live cache against navigation attributes. So if you load a selection containing navigational attribute or drill down by navigational attribute, in theory this should be much faster vis a vis reading from live cache (not withstanding the general computing theory of memory resident processing). This statement (of mine) is contra positive to SAP warnings on performance when using navigational attributes. There are a dozen notes on this to scare users.
There is no definitive answer I guess... at least empirically. It depends eventually on the query size. When query is large, it is hard to blame navigational attributes alone (if you are using some). It can be more so because of transaction time (SQL>LC routine > SQL) in the live cache as well. Sometimes reading a simple relational table (if indexed) can be much faster than reading non-relational (live cache) tables.
I am not a techspert and authority on this. This response is based on my painful experiences. For me anything more than couple of seconds on interactive DP is a waste of time.
Thanks
Borat

Navigation attributes in APO DP

I am using APO DP V5.
I have a planning characteristics of product and customer. I also have a characteristic of 'product group'. I am trying to clarify the real difference between modelling this characteristic as a planning characteristic or as a navigation attribute of product.
Based on my testing, using product group as a navigation attribute, I can select by product group and apply fixing and disaggregation.
So, what is the 'added value' of modelling 'product group' as a planning characteristics?
Any feedback appreciated.
Thanks, Bob Austin

To quote OSS note 413526
When defining a planning area you have the option of using either basic
characteristics or navigation attributes. With regard to the design the
following aspects should be considered:
Navigation attributes:
===========================================================
The use of navigation attributes adversely affects performance during
data selection and during navigation in the interactive planning. The
number of used navigation attributes is important and not the different
specifications of a navigation attribute.
It is very easy to realign the planning objects since only the master
record table of the affected InfoObject has to be changed.
Navigation attributes can not be used as a characteristic during the
definition of a fixed aggregate.
During the disaggregation a navigation attribute can never represent the
lowest planning level.
Navigation attributes can not be used in the promotion planning, in
other words an 'assign object' is not possible for navigation attributes.
Basic characteristics:
===========================================================
In comparison with navigation attributes, the exclusive use of basic
characteristics improves the performance.
It is possible to realign the planning objects, but this is more
complicated.
Basic characteristics can be used during the definition of aggregates.
Both navigation attributes and basic characteristics can be used during the
data extraction.
It is therefore not possible to give a clear-cut recommendation for or
against navigation attributes.

Navigational attribute in aggregates

Pls. answer.
-How do you include the navigational attributes in aggregates. Aggregates are created over the characteristics(InfoObjects), how to include the Nav. attr. to aggregates?
-Does the usage of Nav attr in aggregates reduces the performance?
Thanks,
NN

Navigational attributes do drag down the time a little because of the extra read that needs to happen on the master data table. Even more evident is the increase in the run time of the Attribute Change Run (ACR) job. This would runner longer during the batch process after updates to master data, as the navigational attributes needs to be adjusted in the aggregates with latest values.
So avoid using navigational attributes in the aggreagtes if you can. Also avoid having both the base characteristic and its navigational attribute in the same aggregate. The last I heard this is a definite NO NO.
FYI, if you add the base characteristic...all the navigational attributes are inherently included as well. In other words, if I have 0SOLD_TO in my aggregate, I can run a query on the navigational attrbute 0SOLD_TO_0ZIPCODE which will still use the aggregate.
Hope this helps!

What the big impact change the navigational attribute

I do have infoset contained 3 DSO,
1 of the DSO have 0JOB which we need to set as Navigational Attribute..
The the most impact and precaution that I need to think before take this step..
i know that base on your experience .. hope that you could share with me ..
Point will be assign
thank you

Hi...
You can set 0JOB as navigational attribute....no probs...........
But........navigational attributes require additinal joins during query runtime........so it has an impact on the performance..........It will slow down the query performance.............moreover if u hav aggregates on the cube.......during attribute change run .....adjustment of aggregates will also slow down.........due to this we should always try to minimize number of navigational attributes..........u also consider how often the query will run.............
Hope this helps.......
Regards,
Debjani......

Performance - navigation attributes

Similar Messages

Maybe you are looking for