Not sure if this is the right forum to post this in - please move it to the most appropriate if it is not.
We have a new XIR3 installation and have built several universes and reports.
I’m going to be demonstrating the functionality of them next week but because the underlying data isn’t particularly efficient the queries take a couple of minutes. This is too long to wait during a demonstration.
The only reason i have for wanting to refresh a report is to demonstrate the prompt functionality - everything else can run off the most recent instance.
So, am wondering if there’s anything I can do to tweak things (thinking cache) so that the prompt comes up quicker without having to wait for the LOV to be generated which takes approx 1 1/2 mins which is a just too long - would really need it to be about 30 seconds. I’ve been on 3 BO training courses so far (Universes, Report writing and Admin Security) but the one that would have the answers to what i’m after (Admin Servers) is not for 2 weeks.
The data in our data warehouse is not real time (refreshed once a day in the morning) so having more caching would be beneficial anyway.
If there is no means of doing this then I am left with 2 options:
Break the universe to link to bring data from a static table rather than the multiple tables and views currently making up the existing structure
Create a new universe based on the current data and recreate the report to point to that.
I have 3 days before the demo so whatever is going to work best.
If it helps I have access to the CMC, server and file storage of the BO Server and can rdp into it to change things as required.
Thanks for the link - there are some useful tips however they’re not really options that i can put into place at this time.
Most of the hints relate to best practice of data warehouse and universe design which i agree are things that would have a significant impact on performance.
However, this is something that requires significant amount of time from our dba and developers which are not possible at this point in time. They are certainly things we want to do but cannot do.
In the meantime, i’m looking for a quick performance improvement which would mean that running queries would not hit the data tables and instead run off a cached version of the data.
I do not know if this is possible but is something that we achieved with great effect with our Oracle OBIEE installation by running in cached mode.
I’ve managed to slightly improve things by creating indexes on key tables but the problem is that we are running a lot of the universe using views which cannot be indexed. The reason for this is due to the limitation in Business Objects whereby a universe can only point to a single database. Because we have more control on this database and have referenced to it using database links to do the universe design it has an impact on performance.
Another thing i have done is to hard code the LOVs into the query using custom sql which seems to help but it still means the overall query takes over 1 minute which isn’t ideal for the demo.
If anyone has any suggestions on how the caching can be modified so that the demo can be run in such a way that the base tables are not hit too much that would be awesome.
I suspect this may not be possible and i will be forced to go to a backup strategy of generating a universe which does not have these performance issues as a temporary measure but would prefer not to from a workload and tidyness perspective.
This really depends on who the audience is. If you’re doing a C-level demo to show off your new BOE purchase - guess what - they really won’t care what you’re querying off of - txt files, Oracle, R/3 tables - whatever. The goal in this case should be to instill confidence in your management team that what you have is a solid BI platform to build upon despite the fact you’re still working through optimization and data preparation issues.
If the audience is technical, you should focus on a narrow slice of your installation that does perform relatively well - and demonstrate functionality with a few very technical benefits of BO.
If it’s a user demonstration, again, it might be a mix of both.
As far as data speed: as you said options are limited and that later on, with more time, you can tune things as they ought to be - but for now I would dump your working data set into a wide, flat table with one or two hierarchies and use it just for this sole purpose. Tuning and analysis takes time, patience and testing - and it sounds like you need this ready in a pinch…
(BOB member since 2002-08-20)