nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

OBIEE 12.2.1.3 Agent failed to deliver report

Joe_obieeoas

Hi Gurus,

We have an agent configured on top of a report. This agent runs at 8 am every morning based on a condition that the count of an item should be greater than 0.

Ours users update these counts every weekday,, for ex: if they update the count to 10 units on monday, then on tuesday morning the users should receive a report on monday counts as saying 10 units.

Last friday also they updated the same way and they are supposed to get the report delivere d on saturday morning. But they did not.

This report has a function as follows which gives previous day -- TIMESTAMPADD(SQL_TSI_DAY,-1,CURRENT_DATE). Based on this they should get the report on saturday morning with the friday counts. But they did not.

Today (tuesday) when they replaced -1 with -4 in above function, then they received friday report.

When they reached out to me, i looked into the scheduler logs but nothing is found.

Please share any insights on this.

Thanks.

Find more posts tagged with

Accepted answers

All comments

Gianni Ceresa

Hi,

There aren't tons of options...

The first thing you should check is if the agent did execute correctly every day (or at least Tuesday-Saturday based on your description), then you should check the condition query: seeing a function is one thing, what the analysis really does can be quite different. Look at what the analysis really does as query and try to identify what could make it not work correctly based on your expected behavior.

There isn't much else that can be said as it's all based on your own custom things: data, analysis, settings etc.

Joe_obieeoas

Hi Gianni,

Agree with you but i did checked the "condition" for this agent and the users are sure that they have counts updated last friday and this agent delivered report on all previous saturdays as well, only this time it did not. And this morning the report with yesterday's counts is delivered as it normally does.

Thanks..

Gianni Ceresa

If they are sure (I never fully trust people: historically people lied more about things they didn't do or did wrongly than a server), maybe you have a cache issue?

If you have cache enabled your condition could have perfectly missed the updates because it never really sent a query to the database. If you have logs on you can have a chance to find out, maybe even usage tracking did capture that.

Joe_obieeoas

This being a production environment logging is disabled for all users and don't think stale data (cache) might cause the agent to fail. But as you said people may not be true always.

As we have limited options to further investigate this, wondering how to proceed further..

Thank you.

Gianni Ceresa

production environment logging is disabled

Why? Exactly because it's a prod environment you need logs to be able to analyze issues without messing around with things trying to reproduce something you don't really know what it was.

Without logs, you just have no way to investigate anything, you can only validate that the condition analysis produce a physical query matching the business rule and that you don't have anything (cache) not letting the query to be sent to the database.

Other than that you can't do anymore without logs.

Joe_obieeoas

Agree, so you mean logging should be enabled (set a minimum of 2) for ALL users in prod ?

Cache -- ideally should it be turned ON in prod ?

Please specify..

Thanks in advance.

Gianni Ceresa

You should have usage tracking enabled, mainly because it does asynchronous inserts and therefore doesn't impact your performance. That gives you already a number of information on what your prod server does (or better: what users do with it).

And yes, I would also go with log enabled. If you have a concern about logging too much and filling a disk and making you server unavailable you can enable logging and monitor the log files over a few days to best turn the rotation and retention logic of the logs.

Cache depends fully on your usage of the system: cache ON is often a quick answer to performance problems, knowing it doesn't fix anything in reality, it just does cache things. What most people do forget when enabling cache is to also fully define the rules of how to purge cache and when.

I always turn cache OFF by default and try to fix any performance issue by tuning queries etc. Then, after a bit, if the business rules are fully set and agreed by everybody (things like no intra-day loading or updates, all data always and only change once per day etc.) and there is a clear defined logic for purging the cache (like the ETL doing the data loading also call for a cache purge and refresh), cache can be safely turned ON.

People generally forget about the downsides of cache: your queries aren't hitting the database anymore if some conditions aren't met. You can update the data in the database as much as you want but cache will prevent your users from seeing it.

Aiswarya G

Test the Agent in non Prod Environment for positive and Negative, You have flexibility to enable full blown logging as well. Also, Agent ran for TIMESTAMPADD(SQL_TSI_DAY,-1,CURRENT_DATE) Failed, and TIMESTAMPADD(SQL_TSI_DAY,-4,CURRENT_DATE) passed means issue with the agent when it is fired or with data points. Hence, Logging is necessary to identify for the sporadic cases.