In more detail: I'm monitoring a table named dba_scheduler_job_run_details. I had to define my monitor as follows in the $SPLUNK_HOME/etc/apps/[your app name]/local/inputs.conf file. Note that I had to specify a SQL query for my monitor to get things back in the needed format. [dbmon-tail://your_db_name/scheduler_job_run_details] host = db_host index = oracle_dbx output.format = kv output.timestamp = 0 output.timestamp.format = yyyy-MM-dd HH:mm:ss output.timestamp.parse.format = yyyy-MM-dd HH:mm:ss query = select \r\n to_char(log_date,'YYYY-MM-DD HH24:MI:SS') log_date,\r\n log_id,\r\n owner,\r\n job_name,\r\n status,\r\n error# return_code,\r\n to_char(req_start_date,'YYYY-MM-DD HH24:MI:SS') req_start_date,\r\n to_char(actual_start_date,'YYYY-MM-DD HH24:MI:SS') actual_start_date,\r\n to_char(run_duration) run_duration,\r\n instance_id,\r\n session_id,\r\n to_char(cpu_used) cpu_used,\r\n additional_info\r\nfrom dba_scheduler_job_run_details {{WHERE $rising_column$ > ?}} sourcetype = job_run_details tail.rising.column = LOG_ID interval = auto table = scheduler_job_run_details My rising column is LOG_ID. I did not specify a timestamp column in the monitor, but made sure that the appropriate field was returned as the first column in my results. The actual query (without all the extra \r\n codes inserted by Splunk for line breaks) looks like this: select to_char(log_date,'YYYY-MM-DD HH24:MI:SS') log_date, log_id, owner, job_name, status, error# return_code, to_char(req_start_date,'YYYY-MM-DD HH24:MI:SS') req_start_date, to_char(actual_start_date,'YYYY-MM-DD HH24:MI:SS') actual_start_date, to_char(run_duration) run_duration, instance_id, session_id, to_char(cpu_used) cpu_used, additional_info from dba_scheduler_job_run_details {{WHERE $rising_column$ > ?}} Can't explain why this works, but it does. It is important to note that it can't be configured correctly (as of DBX v. 1.0.6) through the UI. The monitor must be set up through edits of the inputs.conf file for whatever application needs the data. ... View more

In my case, I'm monitoring a table named dba_scheduler_job_run_details. I had to define my monitor as follows in the $SPLUNK_HOME/etc/apps/[your app name]/local/inputs.conf file. Note that I had to specify a SQL query for my monitor to get things back in the needed format. [dbmon-tail://your_db_name/scheduler_job_run_details] host = db_host index = oracle_dbx output.format = kv output.timestamp = 0 output.timestamp.format = yyyy-MM-dd HH:mm:ss output.timestamp.parse.format = yyyy-MM-dd HH:mm:ss query = select \r\n to_char(log_date,'YYYY-MM-DD HH24:MI:SS') log_date,\r\n log_id,\r\n owner,\r\n job_name,\r\n status,\r\n error# return_code,\r\n to_char(req_start_date,'YYYY-MM-DD HH24:MI:SS') req_start_date,\r\n to_char(actual_start_date,'YYYY-MM-DD HH24:MI:SS') actual_start_date,\r\n to_char(run_duration) run_duration,\r\n instance_id,\r\n session_id,\r\n to_char(cpu_used) cpu_used,\r\n additional_info\r\nfrom dba_scheduler_job_run_details {{WHERE $rising_column$ > ?}} sourcetype = job_run_details tail.rising.column = LOG_ID interval = auto table = scheduler_job_run_details My rising column is LOG_ID. I did not specify a timestamp column in the monitor, but made sure that the appropriate field was returned as the first column in my results. The actual query (without all the extra \r\n codes inserted by Splunk for line breaks) looks like this: select to_char(log_date,'YYYY-MM-DD HH24:MI:SS') log_date, log_id, owner, job_name, status, error# return_code, to_char(req_start_date,'YYYY-MM-DD HH24:MI:SS') req_start_date, to_char(actual_start_date,'YYYY-MM-DD HH24:MI:SS') actual_start_date, to_char(run_duration) run_duration, instance_id, session_id, to_char(cpu_used) cpu_used, additional_info from dba_scheduler_job_run_details {{WHERE $rising_column$ > ?}} Can't explain why this works (it's NOT intuitive at all, especially based on the UI), but it seems to be doing fine so far. ... View more