Categories
- All Categories
- 15 Oracle Analytics Sharing Center
- 15 Oracle Analytics Lounge
- 208 Oracle Analytics News
- 41 Oracle Analytics Videos
- 15.7K Oracle Analytics Forums
- 6.1K Oracle Analytics Idea Labs
- Oracle Analytics User Groups
- 76 Oracle Analytics Trainings
- 14 Oracle Analytics Data Visualizations Challenge
- Find Partners
- For Partners
Schedule Refresh in OBIEE 11.1.1.9 analytics ( No Prompts for such reports )
Hi Expertise,
Anyone help me in Getting reports auto refresh before certain time.?
My need of this requirement is, There are some reports where the reports are taking more than 30 min on time to open the report for particular date.
for that, I am trying to refresh the reports with all data by using auto refresh, then after that If the users tries to open the report, then it should publish within seconds.
Does OBIEE has this feature in 11.1.1.9? If so, please provide me the links, I am not able to find after googling.
I have tried this by scheduling concept which we can do it through agents. What I have done is ....
Created an agent,
selected the analysis (report) ,
kept scheduling Daily for one time
didn't applied any condition
Saved and run that agent.
It took me 30 min to run the agent, then it populated as agent is been run successfully.
After opening that report, I populated within 2 sec of time. Now the problem is when I tried with other reports , It is not able to repeat the same functionality...
Is this the procedure correct, If not please try to correct me. or does we have any other approach to achive such scenarios, so that before the user opens the report, the particular report should be refreshed already and ready for opening in fraction of seconds...
The ultimate AIM of this approach is, while opening the report, the query should not hit the DB,
Please enlighten me,
Santhosh S.
Answers
-
i think approach is correct. before the user execting the query you are executing using agent and cached the result. I did the same way for my requirement.
Please check is second query is cached or not. if cached it is hitting the cached query or not. work on cache management properly
0 -
thanks for the reply,
Can you advice any other approaches rather than this please.
0 -
BI Server caching will do what you're wanting. It's worth pointing out that if your query takes 30+ minutes to run you've got serious problems in your stack, in the design and/or implementation of it. Caching will "paper over the cracks" but you should be trying to fix the performance problems at root, not sweep them under the carpet.
This article lays out your options for maintaining the BI Server cache, including seeding it (which is what you're asking about). But don't forget to purge it when the data changes.
Now the problem is when I tried with other reports , It is not able to repeat the same functionality...
This doesn't explain the actual problem that you faced. "It doesn't work" could mean a dozen things. The process is pretty much correct, although it's worth setting the destination for the agent as the BI Server cache.
0 -
Thanks for the reply @rmoff , I was reading your blogs from two days regarding performance tuning like, Performance and OBIEE - part VII - Optimising OBIEE performance ("Tuning") - Rittman Mead Consulting and Performance and OBIEE - part VI - Analysing results - Rittman Mead Consulting .
yes we have been facing the issue from DW also, for that our team is already been worked on it and managed to fetch the results within 20 min of time, but still BI team needs get the results faster and faster upto below 5 to 10 min.
The thing I am unable to understand is whether to implement cache or not.?
when enabling cache I am getting the stale data, so Is there any approach of purging the cache after the ETL is done and followed by refreshing the report with fresh data and saving it in cache.0 -
whether to implement cache or not.?
Yes. No. Maybe. It Depends
- Yes: In a well-implemented OBIEE solution, I would tend to implement caching as "the icing on the cake". Everything else working nicely, caching can give you that final burst of speed.
- No: if you've already got performance problems, if you implement caching as your only performance fix, you're asking for trouble. OBIEE is an ad-hoc tool, so whilst you might 'fix' slow pre-built reports with caching, anything that doesn't get a cache hit is still going to suck massively. Plus, you end up with more and more complex cache purge/seed routines to try and keep the house of cards from tumbling down.
- Maybe: If you've got performance problems, you've identified their cause and are in the process of fixing them and need a short term workaround then caching can save your bacon. But you are taking on technical debt that will come back to haunt you if you don't pay it off (by fixing performance at root, instead of relying on caching)
Is there any approach of purging the cache after the ETL is done and followed by refreshing the report with fresh data and saving it in cache.
Yes - all described in detail here: OBIEE BI Server Cache Management Strategies
0 -
Robin has it cornered. The line between "Icing on a cake" and "icing on a huge, steaming pile of dung" is a thin one.
yes we have been facing the issue from DW also, for that our team is already been worked on it and managed to fetch the results within 20 min of time, but still BI team needs get the results faster and faster upto below 5 to 10 min.
As said this should give you an idea about where the real problem lies. Think about it: Is it worth investing days of work into a solution which will require effort and maintenance and constant extension (because you won't just forever stay with the analyses you have now) and which does NOT actually solve your issues?
Or is it worth investing time and effort into a sound and global solution the real underlying issue?
Let's put it like this (if you're a lurker here you know that now comes one of my awesome comparisons): Is it worth investing into four lawnmower engines plus pedals for each passenger which you hook up to your old Honda Civic in order for it to go faster...or isn't it just better to chiptune and supercharge that nice little engine?
0