Do you by chance have enough RAM on your server? Also, If you have multiple application open that are overwhelming your memory - that might cause this issue.
I resolve my issue by closing some of the other apps that I have open.
Since replacing SQL Developer did not fix it, you might try replacing your JAVA?
In these cases the culprit is almost always the application running up against the Java Virtual Machine's -Xmx limit and the garbage collection overhead that ensues. You can verify if that is the case by...
1. Edit C:\Users\<your_userid>\AppData\Roaming\sqldeveloper\4.1.5\product.conf. Check the value assigned to -Xmx.
2. Keep Windows Task Manager open.
3. See how much Working Set (Memory) sqldeveloper.exe or sqldeveloper64.exe uses in the Processes tab.
4. This Working Set value will over-report how much memory the JVM uses, but it gives you a rough idea.
5. If you are not doing anything in SQL Developer but see it using CPU, that means the garbage collector is working.
If you have sufficient physical RAM on your machine, it may help to increase the -Xmx value. It may help to override the default garbage collection algorithm and go with something like the G1GC: http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html
On the other hand, you may be partly responsible. Do you leave query results tabs open, perhaps spread over multiple connections? Maybe, over time, the result sets are also getting bigger. Keep that in mind. Everything consumes memory.
Thank you Gary, I will try what you have suggested. I just finished reading an archived article you posted on SQL Developer freezing and was trying not to use any keyboard shortcuts - very frustrating. I really like the product, but this is seriously making me look around for alternatives
For the 4.1.3 and higher releases, the feature that caused the hang when using shortcut keys got disabled so you should not worry about that. I would still bet this is a memory / garbage collection issue.
One additional tidbit: Task Manager will show substantial less memory use if SQL Developer is running on a 32-bit version of the JDK. So if you do not require a JVM limit of more than 1.2 to 1.5 GB, you could run with the 32-bit JDK even if you have a 64-bit OS as most do nowadays.
Ok, in product.conf there is are values of :
# Examples: -Xmx83886080
and values of:
# AddVMOption -Xmx800m
# Add32VMOption -Xmx800m
# Add64VMOption -Xmx800m
in Task Manager sqldeveloper64W.exe is showing 734,216 and it doesn't appear to be changing when sqldeveloper is idle
I'm not sure what I'm seeing in the product.config - is the # a comment symbol?
Yes, you can remove the # to uncomment it. I believe the default is 800M. Look at the Performance tab of Task Manager to see how much physical memory is available.
I discussed this with one of our DBAs. We changed to the following
and SQL Developer would not even launch.
There is only one other person having this problem, the only thing we seem to have in common is OnBase by Hyland development tools. After dinking around with these tools and SQL Developer, I find that I loose function in the result pane when OnBase's Unity Client is open; Close Unity Client (most specifically make sure the residual icon in the system tray is closed) and restart SQL Developer and everything is fine. Open Onbase Unity Client and I can't get into the result pane. I don't have to ANYTHING but OPEN this Onbase Unity Client.
We changed to the following AddVMOption -Xmx1600m ... SQL Developer would not even launch.
Then it sounds like you are running 32-bit Windows, and the memory limit, if that were the problem, would need to be set lower.
Anyway, strange situations occasionally present themselves where the problem is a conflict with some other application, a corrupt Windows profile, or something of that nature. SQL Developer is just an (extra-)ordinary Java application, so maybe you can pursue the question of what is going on with OnBase Unity (thick client) with Hyland.
Alternatively, another option might be checking out Hyland's OnBase Cloud to avoid use of that thick client.
Thank you for your time and effort on this; we will pursue the issue with Hyland.