Updated November 19. 2018
The ‘Holy Grail’ of software tools is the environment where things are made easy, but not at the expense of usability or simplicity. You use a tool because it makes something ‘easier’, but some software products are anything but.
SQL Developer is fairly scaled down. You have a few toolbars, several menus, and 2 driving windows – the Worksheet and the Browser. But what if it could be even simpler? SQL Developer is asked to be the database IDE. We serve many masters, yet a majority of our users simply look to the tool to be a GUI replacement of SQL*Plus.
What if you as a user could ‘slim’ down SQL Developer? Less menu items, fewer widgets to load? A leaner, meaner SQL Developer?
Well, you can do that today.
Disable Extensions: Versions 1 – 3.2
This question came up at my presentation at RMOUG, and I didn’t have a great answer. Fortunately my boss was there and he had a really good answer: simply go into the preferences and disable all the extensions.
Disable Feature: Versions 4.0 and Higher
On the Tools menu, select ‘Features’ – and turn off things you don’t use. Like Migrations – this is a BIG feature that MOST of you won’t need to use.
This looks quite a bit different than before, but it’s the same concept.
Once you make a change here you will need to re-start SQL Developer to make the changes take effect. You will see two primary advantages:
- Faster load time
- Simplified UI
You should see a faster start time with disabled features – but it depends on your machine and how many of the ‘big’ features you disable. On my WIN7x64 machine SQL Developer is loading in about 17 seconds with everything turned on, and in 10 seconds with most things off including the Start/Welcome Page. I did leave on the Data Modeler, because I think folks like the ‘Model’ tab when looking at Tables, and that requires the Data Modeler extension.
For the primary benefit, you will notice the main menu items are skinnier – no items for Source Control, the Data Modeler, Migrations, or Data Miner. These are not ‘bad’ things, but chances are you rarely use these features. You can in fact turn them off (and turn them on, as required.)
On my Mac – I didn’t even try turning things off. I have like a 7 second load time with everything on.
Simplified UI – ‘Lite’ Mode
Further Optimize Your SQL Developer Experience
There are a few more techniques and preferences you can exploit to get SQL Developer running faster and using less system resources. Note that I run SQL Developer ‘out of the box’ with no tweaks and it runs just fine. However what works for many people won’t necessarily be right for everyone. Here are a few changes you can make in a few moments to dramatically affect SQL Developer’s performance.
Set Look and Feel Preference to Host OS
Look and Feel is a Java property that controls how the application’s GUI ‘widgets’ are drawn and behave. You can let the host OS control this, or you can implement your own themes. SQL Developer ships with an ‘Oracle’ Look and Feel theme. I think it’s nicer than what Windows gives out of the box for Java applications.
It costs more, CPU to be specific. It takes more work for the tool to run if it’s controlling the ‘look and feel’ instead of just farming that out to the operating system. Now the funny or weird part here is that I’ve heard a few OS X folks tell me they see the exact opposite behavior. So, if you see SQL Developer running slow or it chewing up the CPU, try switching this preference and restarting the application.
Or if you’re on a Mac
Close Grids and Files When You’re Done with Them
This is hopefully common sense. Having data loaded in a grid consumes memory. Lots of rows = lots of memory. Close the grids when you’re done. When you close a grid it forces the JVM to do garbage collection. This is fancy talk for saying that the java application will release memory back to the java virtual machine. This will also keep your DBAs happy – leaving grids open with un-fetched results (you queried a billion row table but only got the first page) leaves processes and other system resources tied up.
Don’t Set Your SQL History Limit to Some Obscenely High Value
Like 30,000. That’s too high. I think the default (100) is too low. Mine is currently set to 500. Just know that what you set it to affects memory. The SQL History data is read into memory at start up. The more you save, the more it costs.
Still Experiencing SQL Developer Performance Issues?
Drop me a line at [email protected] or leave a comment here. We’ll do our best to get your issue sorted out. Keep in mind I’ll ask you to try the above tips first, then ask you what version of SQL Developer you’re running and what JDK you’re using. Answers including anything BUT ‘Latest version and Oracle Java 8/1.8 JDK’ will be me replied with ‘try that and get back to me.’
With more than 5,000,000 active users today, Oracle SQL Developer is bound to be running in some environments that cause performance issues. We won’t be satisfied until everyone has a good of an experience with it as we do!