I marked 1.1.3 as latest release, hope that fixes the problem. ... View more

You should upgrade to the latest version of DB Connect. There is a specific fix that works around a JDBC deadlock issue, which might be what you're experiencing. ... View more

The database server returns an error message: 'to_date' is not a recognized built-in function name Looks like the to_date function does not exist in the database server version you're using. ... View more

DB Connect uses a SimpleDateFormat to parse the timestamp. SimpleDateFormat only support milli-seconds precision, the timestamp in your case seems to too precise (nano-seconds). There are 2 ways to work around this: 1) Parse the timestamp up to the seconds (ie. reduce the precision): yyyy-MM-dd HH:mm:ss , which should work 2) Use a custom SQL statement and convert the LOG_ENTRYDATE column to TIMESTAMP (eg. using the TO_TIMESTAMP function: http://docs.oracle.com/cd/B19306_01/server.102/b14200/functions193.htm) ... View more

In order to use database inputs, the recommendation is to install DB Connect on a (dedicated) heavy forwarder. This forwarder should be configured to forward the data to all indexers using load-balancing. In order to use reporting features, such as lookups, ad-hoc queries or dboutput, DB Connect needs to be install on the search heads as well. Setup on search heads with pooling enabled requires some additional steps, see: http://splunk-base.splunk.com/answers/68598/java-access-bridge-not-running-with-search-head-pooling/72263 ... View more

The limit highly depends on the environment. Both the type operating system and especially the limit on max. open file descriptors and hardware such as available memory will be a limiting factor. The database server might limit the number of connections per host or user as well. In general pool.maxActive count being higher than the number of available threads will not have any effect since DB Connect will only use/open 1 connection per thread. There are 2 thread-pools for DB Connect: bridge: 10 threads for commands (ie. dbquery, dbinfo, dboutput) dbmon: 5 threads for database inputs These thread-pool sizes can be configured in java.conf. For example: [bridge] threads = 20 [dbmon] threads = 50 [dbx] pool.maxActive = 70 This would give a total of 70 available threads, so setting the max. size of the connection pool to 70 is a reasonable choice. ... View more

For the initial run (when there is no checkpoint value) of the database input, the part in the double-curly brackets is omitted (ie. {{...}} ). For any subsequent run (when there is a checkpoint value), the part is included (without the curly brackets them-selfes) and the rising column placeholder is replaced. In your example it would result in: ... where Wave_Number > ? In your case you can't use the column alias Wave_Number in the WHERE clause (the WHERE clause is actually evaluated before the SELECT clause). You could probably wrap you whole SQL statement in another, outer SELECT statement like this: SELECT * FROM ( <your SQL> ) as inner_table {{WHERE $rising_column$ > ?}} Using a HAVING-clause instead of WHERE would probably work as well: <your SQL> {{HAVING $rising_column$ > ?}} Otherwise I'd suggest not to use a column alias. ... View more