Measure sql execution time in a Java Application - java

Is there a easy way to measure execution time of all sql statements that are executed by JDBC and print the result to the output?
Some may advise me to use AOP to do this but I'm trying to avoid this if possible. Is there another way?

If you are not running the application in an application server that provides you a DataSource, you would find the log4jdbc project to be useful. The jdbc.sqltiming logger provided by the project will allow you to record the execution of the SQL statements executed.
You could use this in an application that relies on DataSources, by wrapping the connection returned from the DataSource in a ConnectionSpy object. This would require changes in your codebase.
There are of course, other options available the time of writing this:
the P6Spy project that can still be used in most application servers. Although certainly dated (and considered abandoned by some), it is by no means obsolete.
the JAMon API allows for monitoring of execution time for SQL commands executed. This would require using the JAMon API to monitor the connection.

Ironically, when viewing your question the advert on the right was for the Appdynamics Lite Java Performance tool.

We use three different ways to show execution time.
We use built in Sql Server tools to show execution time/frequency/io/etc. I don't do this myself so I don't know what the exact tool is.
We use AviCode to track execution time over a defined limit.
We run all of our sql calls through a library that automatically metrics all sql calls.
We use these different methods because they each provide a different view of the execution. When there is a problem we look at all of them to make sure they agree.
Do you have something like this available in your environment?

Check this out. They mention using Sql Recorder with JDBC. It might work for you.
Anything better than P6Spy?

If you want to check execution time take by your java application then print date then execute the statement and again print the date you can see the diffrence. Like
System.out.println(new Date());
stmt.executeUpdate();
System.out.println(new Date());
If you want to see the time taken by SQL server, execute query in SQL Query analyzer, on right hand side below corner of the window you will find the time taken to execute the query.
Thanks

Related

how to hack mysql jdbc driver to change every sql to execute in program

this is what i want to do, a little hard to explain.
in a special project (i want to hijack every sql executed).
In more detail, what I am doing is to analyze all slow sql in all tests written by our qa.
we have slow sql analyze tool which analyze db and list all slow sql passed to db (executed in any way).
But the problem is that i can't find which test case use the sql, as the sql itself doesn't contain the info who create it. (there are tens of thousands of test cases, forget to refactor test case...)
what i am plan to do is write a java agent for our test executer, when test run , our test executor knows which test is run and can put such info in java system property (no currency test execution in one java process , so no issue), the java agent will need to HACK jdbc to change all executed sql (executed in jdbc mysql driver in anyway...), the change is to add comment to sql so that it contains the test case info .
for example, original sql is "select c1 from db.tb" , will need to change it to "select /test case XXX/ c1 from db.tb", you can see that i only added comment to sql to link sql with test case.
the problem is that there can be so many different sql execution way, select/update, PreparedStamement, or non-PreparedStatement.
I need to find a common place (one may be not enough, but as least as possible), I prepare to use javasist bytcode instrument wrapped in a javaagent to hack to change the sql. (get test info from system property and add comments in sql).
The problem is that I didn't find a good place to hack , anyone who is really good at jdbc/mysql jdbc implementation , please help.
thanks

Notify Java application of changes in Apache Derby database

I have a Java application that can save and retrieve data from an Apache Derby database using JDBC. I would like to update the view of every user when changes are made in the database.
I tried using a for-loop that polls the database every few seconds, but that uses loads of processor time as expected. I've also heard about TimeTask and ScheduledExecutorService. I'm not sure how they work but i imagine they are a better alternative to the for-loop. However they would also have to check the database, which i find less ideal than having the database notify of changes.
I've read about database Triggers, which i think might be the best solution? However, all the examples i find for apache derby only seem to trigger other changes in the database and not the Java application.
Is it possible to use a trigger to execute a method in the Java application? If so, how? or perhaps there is another approach to solving the problem that I don't know of?

Best place to put SQL statements in Java

I know there are pros and cons to each approach, but is there a best practice on where to put the SQL statements? I've always put them inside of the Java classes, but I came on to a project where they are injected via Spring string constructors. The reason is that if the SQL statements are in an application context, you don't have to remove all of the " and + to get the SQL to copy/paste on the server. I don't think that's a good reason, but that's what I stepped in to for the moment.
I know this can also be done with properties.
So my question is should the SQL statements go in the application context, Java file, properties file, or some place I'm not thinking of?
Update:
From the replies I got, it seems that prepared statements are the best place for SQL statements. But what about SQL statements that are generated on the fly dynamically? The code will have many different strings that will all be concatenated together to make a query depending on what is passed in. If we have a method with 6 input parameters that could be passed in (or not), I would need an incredible amount of prepared statements to account for all the possibilities.
I've considered using an ORM tool such as Hibernate, but I'm working with an iSeries database and the tables are not well constructed. Perhaps someday I can rewrite Hibernate in and write out the 900 line SQL statements... but one step at a time.
Agree with Thiharas answer, but why not go one step further and save them in .sql files within the application. With each query having its own file it becomes easier to manage.
That is of course if an ORM framework like Hibernate will not be suitable for your application.
There's no rule about where is the best place : it's somehow like "where's the best place to put my keys at home".
If your project needs require you to have the SQL accessible from outside the app, then why not putting them in properties files. In that case, you may want to check that changes in the Sql are still compatible with your app by doing some JUnit tests.
Stored procedures are good because of their execution speed, but bad because they split your app configuration in two places. In addition they are tightly coupled with the database software (which again depending on the project can be a good or bad thing)
Hope my answer helped you asking your self the right questions in your own context.
Best Regards,
Zied
That's not the only reason. When the SQL statements are out side of the Java code you can change it without having to re compile and deploy your application. If the queries are periodically loaded from the files (say once every 8 hours) then you don't even have to do a server restart. That will be very beneficial for the people doing production application support.
Also regarding the first reason you don't consider a good reason; when you have to debug a big assed SQL statement and need to paste it in a query executor removing all + and '"' signs I'm sure you will change your mind :-)

Java scheduling Vs SQL scheduling

Here is my requirement:
a date is inserted in to a db table with each record. Two weeks
before that particulate date, a separate record should be entered to a
different table.
My initial solution was to put up a SQL schedule job, but my client insisted on it being handled through java.
What is the best approach for this?
What are the pros and cons of using SQL schedule job and Java scheduling for this task?
Ask yourself the question: to what domain does this piece of work belong? If it's required for data integrity, then it's obviously the DBMS' problem and would probably best be handled there. If it's part of the business domain rather than the data, or might require information or processing that's not available or natural to the DBMS, it's probably best made external.
I'd say, use the best tool for the job. Having stuff handled by the database using whatever features it offers is often nice. For example, a log table that keeps "snapshots" of status updates of records in another table is something I typically like to have a trigger for, taking that responsibility out of my app's hands.
But that's something that's available in practically any DBMS. There's the possibility that other databases won't offer the job scheduling capacities you require. If it's conceivable that some day you'll be switching to a different DBMS, you'll then be forced to do it in Java anyway. That's the advantage of the Java approach: you've got the functionality independently of the database. If you're using pure JDBC with standard SQL queries, you've got a fully portable solution.
Both approaches seem valid. Consider what induces the least work and worries. If it's done in Java you'll need to make sure that process is running or scheduled. That's some external dependency. If it's in the database, you'll be sure the job is done as long as the DB is up.
Well, first off, if you want to do it in Java, you can use the Timer for a simple basic repetitive job, or Quartz for more advanced stuff.
Personally I also think that it would be better to have the same entity (application) deal with all related database actions. In other words, if your Java app is reading/writing to/from the db, it should be consistent and also deal with scheduled reading/writings. And as a plus, this way you can synchronize your actions easier, like, if you want to make sure that a scheduled job is running, has started, has finished, you can do that a lot easier if all is done in Java as compared with having a different process (like the SQL Scheduler) doing it.

SQL server stub for java

I have a java application that is using MSSQL server through the JDBC driver. Is there some kind of stub that I can use for testing? For example I want to test how my application handle cases of connection errors, SQL server out of disk, and other exceptions. It's pretty hard and complex to simulate this with real SQL server.
Thanks
You could write unit tests against your DAOs or repositories returning mock Connection objects using a mock library such as https://mocquer.dev.java.net/.
You'd need a really clean and decoupled application architecture though in order to make this work correctly and provide you with actual test coverage.
You could (assuming the system is architected in a way to make this easy) create your own versions of the DB Access classes (I assume you are using teh statement/preparedstatement interfaces), which would hold the real DB calls and that you can modify to do exactly what you want.
I've done this - it takes a day or so of really boring work.
I don't think there's something like that.
You'd be better off setting up your own database and testing on your machine/lan.
All I know there is out there, is:
freeSQL
db4free
Both support MySQL, but none MS-SQL. I do think that has to do with licensing issues and limitations. So I'm afraid you won't find a similar service for MS-SQL db.
Answering myself with an option I thought of, I'll be glad to hear your inputs on it.
After crawling around, I got to HyperSQLDB, a java-implemented database.
How feasible do you think is to take the source code of HSQLDB, and adding another layer to it, so I can control it and inject pre-defined behaviors to it.
For example, I'll make it run all queries slowly, I'll make it disconnect, etc.
Do you think this idea is worth pursuing? Is it doable in a reasonable amount of time?
If you use something other than MS-SQL, you may cause more testing problems due to incompatibilities and lack of functionality (e.g., transactions) than you solve. So I'm with Carl - use a shim.
If you were looking for unit-test coverage of ordinary behavior, I might think differently.
I haven't used them personally, but the stuff you're talking about sounds like a really good fit for a mocking framework, such as Mockito(docs) or PowerMock. They appear to provide good support for the kind of failure injection you're after. Can someone with experience with either of them (or similar) weigh in? See also How to stub/mock JDBC ResultSet to work both with Java 5 and 6?
execute procedure sp_who2 it will generate the all the current connections and process in your db you can see a column named spid corresponding to each db connection. just type: kill <<spid>> and execute it to terminate any users..etc. but if the spid is less than 50 it means it is a system process and dont kill it. This can help you replicate connection drops.
you can also say ALTER DATABASE dbname SET SINGLE_USER WITH ROLLBACK_IMMEDIATE this will drop all connections to the said db immediately.
Select ##MAX_Connections as Max_Connections would give you the max connections which can be made to a database (you can set it to a low number to test connection unavailability).
to replicate query timeout.. set the query timeout to a very low number & execute a fairly large query.
to create disk space error, simply redice the size of the db file & do not allow it to grow... then insert data to the database (you'll get an exception).
altert database xxx (file= maxsize= filegrowth=)

Categories