Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Report is taking too long
- Thread starter gsai
- Start date
1) go to SQL view of the report and check to see if you have any cross joins.
2) Try running the report during off peak hours to see if it still errors.
3) Take the SQL from the report and query your database directly to make sure it's the data retrival that is causing the issue. If the SQL takes faster to execute against the DB directly then it's your Analytical Engine that might be causing problems.
2) Try running the report during off peak hours to see if it still errors.
3) Take the SQL from the report and query your database directly to make sure it's the data retrival that is causing the issue. If the SQL takes faster to execute against the DB directly then it's your Analytical Engine that might be causing problems.
If you can get your DBA to review the SQL, they'll probably be able to advise on the most efficient tables/joins to use.
Try to hit Indexed fields in your attribute ID's (again, check with your DBA if you're unsure which are indexed).
Try to keep attributes simple (ie, don't complicate the functions used on the database elements if you can help it).
Avoid using too many report-end formats, view filters, etc.
Try to hit Indexed fields in your attribute ID's (again, check with your DBA if you're unsure which are indexed).
Try to keep attributes simple (ie, don't complicate the functions used on the database elements if you can help it).
Avoid using too many report-end formats, view filters, etc.
PacmanUser
Technical User
Keep the report simple
1) Simple attributes, avoid using consolidations or custom groups because they cause multi pass sql sentences and will take up to 3 or 4 times more than the expected
2) Simple Metrics: avoid use metrics with filters in its definition. Each metric with filter in it will generate a diferrent sql pass, is better to use the cross-tab option when you can.
3) When designing a report remember that size of the report is multiply by the number of elements an attribute has that is located on the page-by section, try eliminate o reduce it using filters or prompts.
4) View the Sql to see what fact tables the report is reading an consider maybe generat and aggregate fact table to a higher level so report runs faster.
5) Talk to DBA to see the possibility to generate Partitions over the fact tables you are working.
6) Talk to the final user and try to understand what he is looking for, if the report is generating more than 10,000 lines consider redesigning it (to many information to analyze)
Post your results!! hope this help you!!
1) Simple attributes, avoid using consolidations or custom groups because they cause multi pass sql sentences and will take up to 3 or 4 times more than the expected
2) Simple Metrics: avoid use metrics with filters in its definition. Each metric with filter in it will generate a diferrent sql pass, is better to use the cross-tab option when you can.
3) When designing a report remember that size of the report is multiply by the number of elements an attribute has that is located on the page-by section, try eliminate o reduce it using filters or prompts.
4) View the Sql to see what fact tables the report is reading an consider maybe generat and aggregate fact table to a higher level so report runs faster.
5) Talk to DBA to see the possibility to generate Partitions over the fact tables you are working.
6) Talk to the final user and try to understand what he is looking for, if the report is generating more than 10,000 lines consider redesigning it (to many information to analyze)
Post your results!! hope this help you!!
- Status
Similar threads
- Locked
- Question