Scheduler tables in OBIEE 11g



Oracle BI Scheduler is a server that manages and schedules jobs. When a user creates and schedules an agent, Oracle BI Presentation Services gathers information about the agent such as its priority, the intended recipients, and the devices to which content should be delivered. Presentation Services packages this information and other characteristics into a job, then informs Oracle BI Scheduler when to execute the job.

Agents can run in parallel on different threads. The number of agents that can run in parallel depends on the size of the Scheduler thread pool (a configurable setting) and the number of threads used up by each agent. Queueing might occur if too many agents are triggered at the same time.

Oracle BI Scheduler uses a single back-end database to store pertinent information about a job, its instances, and its parameters.

The details about the scheduler tables are mentioned below :

S_NQ_JOB - This table is used by Scheduler to store information about scheduled jobs. That means when you create a new agent from OBIEE, an entry corresponding to it get created in S_NQ_JOB table. This table is stored in the BI_PLATFORM schema, therefore to access it; you should have access to BI_PLATFORM schema.

Some of the columns in the table are mentioned below 

Column Name
Description
JOB_ID
It is unique identifier for each agent
NAME
Name of Agent
NEXT_RUN_TIME_TS
Next scheduled runtime of agent
LAST_RUN_TIME_TS
Last runtime of the agent

S_NQ_INSTANCE – This table stores information about scheduled job instances. For a job in the S_NQ_JOB table, there will be multiple entries in the S_NQ_INSTANCE table based on the agent run.

Column Name
Description
JOB_ID
Identifier for the job populated from S_NQ_JOB
INSTANCE_ID
Unique identifier for each instance
STATUS
Shows the status of the agent
0 - Completed
1 - Running
2 - Failed
3 - Cancelled
5 - Timed out
BEGIN_TS
Start of the instance
END_TS
End of instance
EXIT_CODE
Number of e-mails sent by an Agent job, after the job is completed

Relation with  S_NQ_JOB
S_NQ_JOB.JOB_ID = S_NQ_INSTANCE.JOB_ID

S_NQ_ERR_MSG - This table stores error messages for Scheduler job instances that do not complete successfully. 

Column Name
Description
JOB_ID
Same as in S_NQ_JOB & S_NQ_INSTANCE
INSTANCE_ID
Same as S_NQ_INSTANCE
ERROR_MSG_TXT
Displays the error message in agent failure. This message is same as the message in Agent.log file.

Relation with  S_NQ_INSTANCE
S_NQ_INSTANCE.JOB_ID  =  S_NQ_ERR_MSG.JOB_ID
AND  S_NQ_INSTANCE.INSTANCE_ID  =  S_NQ_ERR_MSG.INSTANCE_ID
 
S_NQ_JOB_PARAM - This table holds information about Scheduler job parameters for scheduled jobs.
Relation with  S_NQ_JOB
S_NQ_JOB.JOB_ID = S_NQ_JOB_PARAM.JOB_ID

8 comments:

  1. Thanks
    Could you pleas share the table structure of the schedulder tables.

    ReplyDelete
  2. This comment has been removed by the author.

    ReplyDelete
    Replies
    1. Please connect to the DEV_BIPLATFORM schema to see the structure of the scheduler tables. It is gonna be a long comment to post the structure here.

      Delete
  3. I was digging out these tables but unable to find information regarding "Run As" we select on General tab while creating the agent. Any idea?

    ReplyDelete
  4. Thanks for your info.
    Can I change the execution status of the registered agent by changing the table column value?

    ReplyDelete
  5. When OBIEE Agent is executed, a report is generated and should be saved in any of the path before it is delivered to email or any other devices. Any idea where this report is saved and whether it can be exposed to Front end OBIEE Catalog folder, so that users can view the job history?

    ReplyDelete
  6. to Arul,
    In my server, this is the temporary file can be saved into this folder:
    D:\oramw\instances\instance1\tmp\OracleBISchedulerComponent\coreapplication_obisch1

    Likely, you will need to accommodate the "D:\oramw" to your installation.

    One way to Save the results of an agent is to use the "Actions" tab of the agent. You can invoke there a server script.

    Cheers.
    Marcelo Finkielsztein

    ReplyDelete
  7. After migrating to AWS , the agents are running twice instead of once and one of them fails. Do you have any idea why this is happening ?

    ReplyDelete