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 all the extensions.
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.
We ship with everything 'on.' That can be easily rectified in the preferences.
I suggest you turn off everything but the ‘SearchBar.’ 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
Ok, so the first item is purely subjective. On my WIN7x64 machine SQL Developer is loading in a little less than 10 seconds versus about 30 seconds. I’m not guaranteeing this benefit, but try it for yourself and see how it goes.
For the primary benefit, you will notice the main menu items are scaled down. 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.)
‘Lite’ Mode
Stuff Turned Off
Default Installation
SQL Developer Default Interface
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.
BUT.
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.
Oracle looks better but Windows will run leaner
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.
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 jeff.d.smith@oracle.com 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 Java 6/1.6 JDK’ will be me replied with ‘try that and get back to me.’
With more than 2,500,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!
Twitter
RSS
GooglePlus
Facebook
Jul 12, 2012 @ 07:15:11
I just read your nice blog and tested to supress some sql developer extensions in sql dev 3.1. It really opens faster but unfortunately there are some curious dependencies. If you uncheck “data miner” your are no more able to open existing “data models” and if you uncheck “scheduler” cut and paste of a table into the sql workspace does not work any longer. It looks like some more work to do
Roland
Jul 12, 2012 @ 08:57:30
I tested the Modeler with disabled Data Miner extension and it worked just fine for me.
Here’s what I tried:
What are you seeing?
Also, what do you means ‘cut and paste of a table’?
Jul 16, 2012 @ 06:12:35
hi Jeff,
I run my tests again, here my results (unchecking data miner was not the reason, sorry):
1) data model does not open after disabling an extension
Preferences–Extensions–Unchecked ‘version support’, restart SD and try to open an existing data model produces an error: “SEVERE 33 0 oracle.ide.IdeCore Exception firing mainWindowOpened to oracle.dbtools.crest.fcp.DataModelerAddin$1@1d0462″
–> enable version support again and the data model opens again
2) drag & drop does not work after disabling “SQL dev scheduler” extension
when you drag and drop a table from the directory navigation tree into a sql worksheet you get normally a pre generated SQL “… select a,b from table” pasted into the sql worksheet. But when you have the scheduler-extension disabled this does not work any more.
–> enable “scheduler ext.” and its works again
I checked and unchecked each extension one by one to avoid side effects, quite boring because it takes about 4 min to open a data model with 10 small tables each time
Roland
Jul 16, 2012 @ 08:43:04
Your previous comment stated you disabled DataMiner, not Version Support. Version support is tightly integrated with the modeler, so I”m not surprised there’s a conflict there.
Firing up the VM now to check out your scheduler issue.
Jul 16, 2012 @ 09:13:53
I just tested your 2nd scenario, and it’s actually working for me.
Here’s what I have:
SQL Developer 3.1.07
JDK 1.7.0_05
Oracle 11.2.0.3
Windows 7 64 Bit
I disabled ONLY the ‘Oracle SQL Developer – Scheduler’ extension. Re-started SQL Developer. Connected to my db. Dragged 2 tables into the worksheet. Got the pop-up dialog asking me what I wanted. I selected the ‘Join’, and it splat the expected SQL to my worksheet.
What does your scenario look like exactly?
Jul 17, 2012 @ 04:30:07
I made all tests again and I think I found the dependencies:
The code for d&d functionality must rely on the “scheduler” or “migration core” extension.
here how I tested:
1. all ext. checked = ok
2. all ext. unchecked = not ok
3. check at least “scheduler” or “migration core” = ok
Roland
my environment:
SQL Developer 3.1.07
JDK 1.7.0_05
Oracle 11.2.0.2.0
Windows Vista 32 Bit
Jan 18, 2013 @ 08:02:36
Just for your records. SQL Dev 3.2 start time w/ extensions on my laptop (8GB + SSD HDD) 13 secs. No extensions 8 secs.
Jan 18, 2013 @ 09:35:42
You went from not so bad, to pretty fast. Some users will say it takes upwards of a minute to start and by disabling migrations and modeling extensions they can get down to 20 seconds or so…btw, in next version we are completely changing up how java classes are loaded up and such, with hopefully end result of an even meaner and leaner (faster) SQL Developer.
Jan 20, 2013 @ 18:25:04
BTW: I have found over the weekend that many feature that I was interested in are extensions dependent (e.g. DBA Sections, Table Data Import/Export etc). IMHO: It may not be a good idea to switch off extensions.
I wonder if you have a good list of extensions along with a short description that would be kind of “core” part of SQL Developer? I would immagine at least extensions written by Oracle folks would be part of the list
Jan 20, 2013 @ 18:58:19
A matrix would be helpful I think…on the topic I generally advise folks to at least disable the Migrations and TimesTen extensions. And remember, that’s only IF you notice SQL Developer taking too long to start up.
Feb 14, 2013 @ 20:06:53
Thanks for these tips!
It would be helpful to mention that the “SQL History Limit” setting is under Tools, Preferences, then: Database, Worksheet, SQL History Limit.
Feb 18, 2013 @ 11:18:35
I take it you had a hard time finding this preference?
Feb 18, 2013 @ 11:50:52
Right!