Question: I am currently using a CSV file to data drive the jmeter test. ("CSV Data Set Config")

Is there a way i can use a SQL or oracle DB to input the data for the jmeter script instead of using a CSV?

Example: connect to db with username and passwords (test data) and use that within the Jmeter script to login with. (this is a very simple example but i would be getting data from the DB for different parts of the application and using that as an input - well that's what I am trying to get working)

As i have a lot of data and use different DB's on the back-end of the application. 

Any other suggestions welcome.

Jmeter version: 3.0
Application:Web based application

Answer: 
JMeter provides [JDBC Connection Configuration](http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Connection_Configuration) where you can set your database hostname, port, credentials, etc. and the following test elements to execute SQL queries:

* [JDBC Request](http://jmeter.apache.org/usermanual/component_reference.html#JDBC_Request)
* [JDBC PreProcessor](http://jmeter.apache.org/usermanual/component_reference.html#JDBC_PreProcessor)
* [JDBC PostProcessor](http://jmeter.apache.org/usermanual/component_reference.html#JDBC_PostProcessor)

You will also need to download JDBC driver for [MS SQL Server](https://learn.microsoft.com/en-us/sql/connect/jdbc/microsoft-jdbc-driver-for-sql-server) or for [Oracle](http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html) and add it to [JMeter Classpath](http://jmeter.apache.org/usermanual/get-started.html#classpath). 

See [The Real Secret to Building a Database Test Plan With JMeter](https://www.blazemeter.com/blog/real-secret-building-database-test-plan-jmeter) article for more information.
There are many very good reasons not to consider this path. For most who have considered this option, the path is to use the same database as the application under test. This introduces a query load which is not present in production and because the queries are likely non optimized and supported by indexes you then have a high likelihood of distorting the application under test just by asking hundreds or thousands of additional agents to query the database of the application.

Most performance testing tools of any maturity will pull the data file into RAM at the beginning of the test to avoid the distortion effect associated with drive read head contention for hundreds/thousands of threads all attempting to read from a file, potentially in different areas of a file. Some of this can be mitigated if you have a drive with a small SSD cache and the data files are small enough to fit in the cache, or an SSD in total. You will still incur the interrupt overhead of the wait for a ring 0 event for a read. It is for this same reason that it is recommended that log writes be minimized during testing.

While disk is expensive to have to hit every time for a parameter value, network is orders of magnitude more expensive. Just food for thought. If you must go this route please consider a queue solution not installed on the same infrastructure as your application under test. RabbitMQ is one I prefer because of its native web interface for queries. Heck, you could even use the queue solutions from Amazon, Cloud Azure, IBM Public cloud and others as you would likely never approach the non-free tier even with a significant number of tests per month. If you need to reuse data then popping data off the queue at the beginning of the iteration and pushing it back onto the same queue at the end of the iteration will ensure some degree of randomness is inserted into the reuse order as virtual users take slightly different times to run. If you are looking at unique data then you can just terminate after you have *n* number of tries against the queue and find no more unique data available for processing.