This issue arose at a customer today, and I’ve seen it happen in the past, so I thought it worthwhile making a quick note.
A situation had arisen which had caused the overnight ETL execution to be delayed. Once this had completed the users complained that the dashboard was missing some data. This was tracked down to a shared filter which contained a restriction using the variable LAST_REFRESH_DT. When we checked this value of this variable we found it was two days behind.
This had happened because of the way repository variables are refreshed in OBIEE. They are not refreshed as part of the ETL, they are refreshed on the initialization block.
So in this case, at midnight every night. That clearly is no good if our ETL starts anything later than midnight as we miss the update on w_day_d.
We need to set it to something that is a factor of the latest expected finish time of the ETL, and the latest time the end users are willing to wait for the refresh. And as the latter always has to be after the expected finish time, then we can use that. Let’s say it’s 8am. We should therefore change the time on the schedule o 8am to ensure the refresh of the variable (not just this one, but in theory any repository variable) is done after the warehouse refresh has completed. If there are any exceptional circumstances we need to be aware of these and deal with them accordingly.
There is of course the option for changing this to an hourly refresh instead, however this similarly needs a change from the default. It’s more about being aware of the issue and knowing that there needs to be some planning in place that is a function of your ETL schedule and end user expectations.
That’s all – short and sweet! 🙂