The instance name is available in the v$instance table. I would recommend creating a view with the instance name either hard-coded or joined from v$instance as a separate column along with the audit data columns. Then have Splunk select from your view instead of the audit trail table or view. ... View more

Hopefully you have resolved this since it has been a few months from your original post, but just in case, is the database user that Splunk connects as able to see the tables? In other words, if you connect to tha account with a different tool like SQL*Plus or SQL*Developer, can you see the tables you expect? This sounds like a permissions issue. ... View more

Sounds like you have installed on an indexer. You should be able to configure DB Connect to see whatever databases you need to from there. Each database will need its own identity and connection info, but then you should be able to run queries or inputs against any of them. If you can use dbxquery to select the data in real-time (not a scheduled input), then it won't count against your Splunk license, either. ... View more

Your query includes bind variables which need values. That's what the "Missing IN or OUT parameter" error means. There's an example of building a parameterized query here http://docs.splunk.com/Documentation/DBX/3.0.2/DeployDBX/Commands. It should look something like this: dbxquery query="select * from actor where actor_id > ? and actor_name = ?" connection="mysql" params="3,BOB" You'll have to replace every ":p_" parameter (e.g. :p_to_date, :p_ledger_id, etc.) with a question mark and list out every occurrence of every value, in order. Given the size of your query that might be tricky. At the very least I believe that you will have to build a custom dashboard/report interface with fields to provide those values. ... View more

This will depend somewhat on what version of Oracle you are running. Oracle 11g can write audit records to text or xml files or syslog, or keep them in the database where you can index them using Splunk DBConnect. Starting with Oracle 12c, audit records are only stored in a new unified audit trail table and no longer written to external files, so DBConnect will be your only option. In general Splunk doesn't have any limit on the amount or size of data ingested. If you can read the file or run the SQL query Splunk can index the results. That said, if you have any concerns about bumping into your Splunk license limit, I would advise reading audit records from syslog or Oracle's .aud text files and avoiding XML. The XML tags make it easy for Splunk to identify fields, but will consume twice as much of your license pulling in those extra characters. If you are running SQL queries, consider which columns from the audit tables you want to include; you can save overhead on your license if you can exclude some of them. It's a little dated (DB Connect is on version 3.0 now), but the following add-on can explain the basics of pulling in data from a variety of Oracle related sources. Log File Analysis for Oracle 11g. ... View more

Enterprise Manager can generate notifications to Splunk using SNMP, OS commands (like a shell script) or PL/SQL (using the UTL_TCP package). OEM can also receive SNMP traps generated by Splunk. Is this what you had in mind? ... View more

We use DBConnect 2 on Oracle extensively and have never noted the behavior you are describing. We monitor our database performance extensively, and query against some extremely large tables, so we would notice if a full table scan was taking place on a regular basis. ... View more

The JDBC interface only allows simple DML commands: primarily SELECT. It does not allow for the execution of stored procedures or maintain session state between command executions. If you need to do something like this, then use a pipelined function to return the entire table, and include the dbms_session call as part of the function. You can then select from the function as follows: select your_function() from dual; There is information on pipelined functions here. ... View more

You can use LDAP to lookup the connect string by installing an Oracle Client on your Splunk system and altering the connect string prototype in the DB Connect db_connection_types.conf file to use a JDBC-Thick (OCI) connection instead of JDBC-Thin, something like this: jdbcUrlFormat = jdbc:oracle:oci:@TNSALIAS This would allow you to use TNSNAMES, say to define a connection string with SOURCE_ROUTE, enable strong network encryption, or to use LDAP resolution instead of tnsnames.ora. ... View more

You can also find it here: https://splunkbase.splunk.com/app/1538/ ... View more

By default Splunk uses JDBC-Thin drivers, and doesn't require the full Oracle client. It can also use JDBC-Thick connections, using the full OCI client, but you would have to install it yourself and would presumably know the version. ... View more

Sounds like the bottleneck is probably on the Splunk server, not in the database. What is the resource usage (CPU, memory, etc.) like on the Splunk server while the query is running? Is there anything else running on the Splunk server (like McAfee) that might interfere with DBX's Java processing? ... View more

By default DBX uses JDBC Thin connections, which do not support SSL. To do what you want would require that you be using Oracle Database Enterprise Edition with the Advanced Security Option. You would need to install a full Oracle client on the heavy forwarder and configure it to connect to the database with SSL, then configure DBX to use a JDBC Thick connection through the Oracle client. If you are not running Oracle Enterprise Edition with the Advanced Security Option then there is no way to use SSL. ... View more

I get it; I work in an environment where these sort of questions come up all the time. We can't change the way Oracle does auditing, but we can enforce policy that ensures user actions are auditable as much as possible. I would advise the following: Since you're using *NIX, you can remove the password on the oracle OS account and use "sudo" to authorize individual users to access the account through "su - oracle" as root, which doesn't require a password. This will eliminate anyone sharing passwords from being able to access the account, and prevent remote network access to the account. Move user access to another system other than the database server, and limit db server access to the couple of system and database admins who really need it. That way "su - oracle" isn't even an option. Lock all shared database accounts like SYSTEM that shouldn't be connected to directly. If someone screams, tell them it's policy. Change the passwords on all shared database accounts that are connected to by users or applications, and set up proxy privileges to allow users to access them using their personal credentials. Configure Splunk to alert any time a restricted account is accessed; if the connection comes over the network you have a better chance of identifying the end user than if they are using one or more accounts on the server. ... View more

You're talking about changing the actual database audit data where the OS user is recorded, not just how Splunk reports on it. Unfortunately I don't think this is something that can be changed, as it is internal to the way Oracle records audit data. The problem I see is that under your current arrangement you effectively have users connecting to a group DB account from a group OS account, which makes accurate auditing pretty much impossible. A better policy would be to have users connect directly from their own accounts instead of using "su - oracle" first. The oracle OS account should really only be used for software maintenance and certain types of batch automation at most. That would allow the OS userid recorded in the audit trail to accurately reflect the true user. The same is true of the SYSTEM database account; it really shouldn't be used for much of anything. Consider granting necessary privileges (and ONLY the minimum necessary privileges) to individual user accounts, if possible, and locking the SYSTEM account entirely. If users really must connect to a group database account, then consider using proxy connections as described here. That way the XML audit trail will record the proxy username as well as the database account username, plus users don't have to know the actual password of the group account. ... View more

From the error message it appears that the database name is not being passed to the search. The search should contain something like database="dbname" not a null value for the database. I'm not sure what would cause this to happen, but you might want to check your database.conf file and make sure the connection is defined correctly. ... View more

The "index" parameter in your inputs.conf file should name the Splunk index in which your data will be stored; unless your index is named "true", you probably need something else here. Make sure you have created an index on the indexer to hold the data, and that it is named here. See this documentation for an example of what should be in inputs.conf. You should also have an "outputs.conf" file defined that tells the forwarder where to send its data. See the documentation here for more information on outputs.conf. ... View more

I believe that the UI only controls what is collected on the local indexing server or search head where it is installed. It does not configure distributed apps directly. If you configure the add-on as a distributed app you can change the inputs.conf file on your distribution server (one place) and push it out to all your remote forwarders that way. ... View more