Develop Reference

how to find out the slow queries in mysql (mostly in Mariadb)

I have few questions:
1) I am newbie to performance testing as a starting assignment I have to investigate the slow queries in MariaDb version : 10.0.17-MariaDB MariaDB Server .
I tried with these settings in the /etc/my.cnf.d/server.cnf
[mysqld]
long_query_time=1
log-slow-queries=/var/log/mysql/log-slow-queries.log
And after doing that I could no start the database. I get a simple
starting MySQL.... [FAILED] message.
I came across Slow query log overview for mariadb which made a little sense :(
Can any one provide me a tutorial of how it should be done.
2) In my application we already use Hibernate for data layer, Does it even make sense to find out the slow query log in the above mentioned way ?
3) How can i achieve the same thing in the mongodb.? like to list out the most frequently used queries, Slow queries ?
Any help would be appreciated.

Converting comment to answer:
When mysql won't start, as first thing you should check mysql error log (probably /var/log/(mysql/)mysqld.log) for exact error.
In your case "log-slow-queries" is starting option name (and deprecated too), you should use slow_query_log with boolean value and slow_query_log_file for filename.
slow_query_log=1 means ENABLE logging
long_query_time=1 means IF ENABLED log queries longer than 1 second
then there is
- log_queries_not_using_indexes=0/1 which, if enabled, will log even queries faster than 1s if they are not using indexes to locate rows
All these and other can be found with descriptions in MySQL manual
For MongoDB there seems to be profiler which is described in answers to this question How to find queries not using indexes or slow in mongodb

How to deploy application updates to a production Spring/Hibernate Application?

Up until this point, I've been using Spring in a development mode of sorts with hbmddl2 properties which drop all the tables and start again when I deploy the application to glassfish. It works well as a development config, since I know exactly what my database is going to contain when I run my app.
However, this isn't appropriate for an application with a rolling release cycle and I'm not exactly sure how to proceed in changing it so it would be suitable in a production environment. Googling it just gives me resources on how to update Spring or Hibernate itself, but nothing on maintaining a server. I'm getting the feeling I'm going to have to start creating XML object property mappings for Hibernate, but I think that's a little over the top when all I want to do is update a schema with new tables and new columns with default values.
Thanks in advance for any answers, I'm completely stuck on this.

This question is a matter of opinion so is is very broad.
There is no best way or right way of doing it.
Updating/upgrading/versioning etc. a production database is always a risk based activity where the key is to mitigate the risk as much as possible.
Here is a example answer to your question Best Practice for Updating a Production Database manually.
This is one of those areas where you gotta do your research and find the best deployment/upgrade method for you. At the end of the day you are going to be accountable for any user/customer data in your database so you have to be comfortable with the approach.

Hibernate multiple users, dynamically changing

There are technically two questions here, but are tightly coupled :)
I'm using Hibernate in a new project. It's a POS project.
It uses Oracle database.
We have decided to use Hibernate because the project is large, and because it provides (the most popular) ORM capabilities.
Spring is, for now, out of the question - the reason being: the project is a Swing client-server application, and it adds needless complexity. And, also, Spring is supposed to be very hungry on the hardware resources.
There is a possibility to throw away Hibernate, and to use JDBC. Why? The project requirement is precise database interaction. Meaning, we should have complete control over the connections, sessions and transactions(and, yes, going as low as unoptimized queries).
The first question is - what are your opinions on using the mentioned requrement?
The second question revolves around Hibernate.
We developed a simple Hibernate pilot project.
Another project requirement is - one database user / one connection per user / one session per user / transactions are flexibile(we can end them when we want, as sessions).
Multiple user can log in the application at the same time.
We achived something like that. To be precise, we achived the full described functionality without the multiple users requirement.
Now, looking at the available resources, I came to a conclusion that if we are to have multiple users on the database(on the same schema), we will end up using multiple SessionFactory, implementing a dynamic ConnectionProvider for new user connections. Why?
The users hashed passwords are in the database, so we need to dynamically add a user to the list of current users.
The second question is - can this be done a little easier, it seems weird that Hibernate doesn't support such configurations.
Thank you.

If you're pondering about weather to use Hibernate or JDBC, honestlly go for JDBC. If your domain model is not too complex, you don't really get a lot of advantages from using hibernate. On the other hand using JDBC will greatly improve performance, as you have better control on your queries, and you get A LOT less memory usage from not habing all the Hibernate overhead. Balance this my making an as detailed as possible first scetch of your model. If you're able to schetch it all from the start (no parts that are possible to change wildly in throughout the project), and if said model doesn't look to involved, JDBC will be your friend.
About your users and sessions there, I think you might be mistaking (tho it could just be me), but I don't think you need multiple SessionFactories to have multiple sessions. SessionFactory is a heavy object to initialize, but once you have one you can get multiple hibernate session objects from it which are lightweight.
As a final remark, if you truly stick with an ORM solution (for whatever reason), if possible chose EclipseLink JPA2 implementation. JPA2 has more features over hibernate and the Eclipselink implementation is less buggy then hibernate.

So, as far as Hibernate goes, I still dont know if the only way to dynamicaly change database users(change database connections) was to create multiple session factories, but I presume it is.
We have lowered our requriements, and decided to use Hibernate, use only one user on the database(one connection), one session per user(multiple sessions/multiple "logical" users). We created a couple of Java classes to wrap that functionality. The resources how this can be done can be found here.
Why did we use Hibernate eventually? Using JDBC is more precise, and more flexibile, but the effort to once again map the ResultSet values into objects is, again, the same manual ORM approach.
For example, if I have a GUI that needs to save a Page, first I have to fetch all the Page Articles and then, after I save the Page, update all the Articles FK to that Page. Notice that Im speaking in nouns(objects), and I dont see any other way to wrap the Page/Articles, except using global state. This is the one thing I wouldnt like to see in my application, and we are, after all, using Java, a OO language.
When we already have an ORM mapper that can be configured(forced would be the more precise word to use in this particular example) to process these thing itself, why to go programming it?
Also, we decided to user google Guice - its much faster, typesafe, and could significantly simplify our development/maintence/testing.

points for executing performance tests on an application

What can be the pin points when executing performance test on an application in Java, which uses Hibenate as ORM Tool and Oracle 11G as database.
I am also thinking of bench-marking the applcation. So for that what should i do.
Thanks

The key things are:
1) as far as practical test the application using real-world usage scenarios - this can be rather complicated in practice - I've used Perl scripts based on www::mechanize and http::recorder for this in the past.
2) failing that ab or jmeter
3) record as mauch as possible (you don't mention what webserver you are using - if its apache, add %D in the logs)
4) make sure you saturate the system - you want to make sure you're getting some major garbage collections (or prove its homoeostatic - which is a very rare thing for a Java program)
5) analyse the webserver and gc logs.

The first place to start is to agree what is acceptable performance. Without that agreement, anything else is premature.
Different application types will have different pain points. Mix of read and writes, concurrent updates (especially on the same data - eg selling concert tickets or airplane seats), data volumes.

Not sure to what extent your app "uses Oracle 11G as database" or even what type of environment you have (i assume typical oltp), but from the Oracle side you can do several things (to name a few):
From an overall db standpoint, look into AWR (Automatic Workload Repository, formerly statspack). I believe this is built into Enterprise Manager as well.
SQL Trace + tkprof.
If using any pl/sql, DBMS_HPROF (Hierarchical profiler).
If using any pl/sql, log significant actions to log tables (via autonomous transactions), recording timestamps of each entry, action taken, etc. Roll your own or use an existing framework (there are several out there). Just make sure its flexible (can change level of logging output).

Have Hibernate log all executed SQL.
Check this link for configuration properties and set hibernate.show_sql to true. Once you can see what's being executed, check any unusual statements and profile them if you suspect they're slower than expected.
Afterwards checking their execution plan and tweaking them to be more optimized will help your application, and your database.

Not sure if using different technologies (e.g. Hibernate in your case) would change the way you would perform the performance test of an application.
There are standrard tools to run the performance test and they should be applicable with the technologies being used by your application too.
Making show_sql true would definitely help in looking at the queries and analyzing them further, but may not help in overall performance test of you application.
Look at the following post Java benchmarking tool for benchmarking tools.
Hope this helps.

How to diagnose performance problems with SQL Server Views and JDBC

I have a view defined in SQL server 2008 that joins 4 tables together. Executing this view in SQL Server Management Studio takes roughly 3 seconds to run and returns about 45,000 records. My application is written in Java using hibernate to simply do a "from MyViewObject" query in HQL. When this is run, the execution time is consistently around 45 seconds. I have also tried simply using JDBC to run this query and received the same level of performance, so I've assumed it has nothing to do with hibernate.
My question: What can I do to diagnose this problem? There is obviously something different between how Management Studio is running the query vs how my application is running the query but I have not been able to come up with much.
The only thing I've come up with as a potentially viable explanation is an issue with the jtds library that contains the driver for SQL Server in Java.
Any guidance here would be greatly appreciated.
UPDATE
I went back to trying pure JDBC and tried adding the selectMethod and responseBuffering attributes to my connection string but didn't get any improvements. I also took my JDBC code from my application and ran it from a test program containing nothing but my JDBC code and it ran in the expected 3 seconds. So to me this seems environmental for the application.
My application is a Google Web Toolkit(GWT) based app, and the JDBC code is being run in my primary RPC Servlet. Essentially, the RPC method receives the call and immediately executes the JDBC code. Nothing in this setup gives me much indication of why the performance is terrible though. I am going to try the JDBC 3.0 driver and see if that works any better, but it doesn't feel like that will fix the issue to me quite yet.
My goal for the moment is to get my query working live with JDBC and then switch it back over to Hibernate so I can keep the testing simple enough. Thanks for the help so far!
UPDATE 2
I'm finally starting to zero in on the source of the problem, though still no idea what the actual issue is. I opened up the view in SQL Server and copied the SQL statement (rather large) exactly into my code and executed it using JDBC instead of pulling the data from the view and most of the performance issues are gone. It seems that some combination of GWT, SQL Server Views and JDBC is not working properly here. I don't see keeping a very large hand-written query in my code as a long term solution, but it does offer a bit more insight.

<property name="hibernate.show_sql">true</property>
setting this will show you the SQL query generated by hibernate. Analyze the query and make sure you are not missing a relationship.
reply for Update 1 and 2:
Like you mentioned, ran the query on your sql query and it seems like it is fast. So another thing to remember about hibernate is that it creates the object that is returned by your query (of course this depends if you initialize lazy obj. Dont remember what it is called). How many objects does your query return? also you can do a simple bench on where the issue is.
For example, before running the query, sysout the current time and then sysout the current time after. do these for all the places that you suspect is slowing your application down.

To analyze the problem you should look up you manual for tools that display the query or execution plan. Maybe you're missing an index on a join column.