I’ve been using this version for 2+ years, and suddenly every single query I submit hangs for 21 seconds before getting exectued. SELECT * FROM DUAL - 21 seconds. When I “Spool SQL to screen”, no entries are added for the full 21 seconds, and then, after the 21 second delay, as if nothing were wrong:
Session:
Timestamp: 14:54:13.810
select * from dual
And the results show up in the data grid. Is there anything I can do? I’ve actually uninstalled and re-installed, and even with all default options, this behavior persists.
Desperate for any pointers or troubleshooting advice; this maddening behavior is almost making TOAD unworkable.
Related question: after uninstalling/reinstalling, is there a way to recover my prior TOAD options/configurations/connections?
Did you install a new Oracle home and do you have “threaded query” option enabled? If so, the delay may be in making a new connection to the DB for the threaded
query.
I’ve seen long connection times when my Oracle homes get wonky. When that happens I usually delete them all and then install only the ones I need.
I’ve been using this version for 2+ years, and suddenly every single query I submit hangs for 21 seconds before getting exectued. SELECT * FROM DUAL - 21 seconds. When I “Spool SQL to screen”,
no entries are added for the full 21 seconds, and then, after the 21 second delay, as if nothing were wrong:
This (basically) nailed it. I had not made any changes to my sole Oracle client - at least none that I was aware of. However, as soon as I installed a new client and pointed TOAD to that for Oracle home, all performance issues were resolved.
Now, as to that related question: any ideas on how/whether my configuration/connections from the uninstalled TOAD 11.6.1 might be retrievable? I see two folders of interest:
\AppData\Roaming\Quest Software\Toad for Oracle\11.6_uninstalled
\AppData\Roaming\Quest Software\Toad for Oracle\11.6
The former definitely has all the user settings I want to use. Just want to make sure I revert to those files in a way that doesn’t break anything. Can I simply copy the contents from the former directory to the latter, overwriting any conflicts, and restarting Toad?
And… a much easier solution - I just renamed the “11.6” directory to “11.6_bkp”, and renamed “11.6_uninstalled” to “11.6”. Fired TOAD up, and I am 100% recovered.
Thanks for the rapid response on the client issue - such a breath of fresh air to have Toad firing on all cylinders!
One final footnote on this post - Previous to my client-reinstall, anytime a connection between TOAD and an Oracle database broke (e.g. disconnected Putty tunnel, database shutdown, etc.), the reconnect session for that connection would cause TOAD to hang for about 10 - 15 minutes. I’d lived with this for ages because it was rare and because it never seemed to happen at a good time to really troubleshoot. Frankly, I’d always assumed it was a TOAD “feature” whereby TOAD was working really, really, really hard to get that connection restored.
I just wanted to mention that using a new client also completely resolved that issue. Toad now gracefully detects connection issues in a matter of seconds. So, FWIW, it seems that CGW (client gone wonky) should be considered as a possible cause for anyone who is experiencing that particular symptom as well.
Thanks for that last comment, Kevin. A lot of the time when we hear about Toad “taking forever to come back” after a lost connection, we can’t reproduce it in-house. We’ve tried unplugging network cables, disconnecting and reconnecting VPNs, shutting down and bouncing databases, etc. I’ve always suspected that the Oracle client is largely responsible for these kinds of things. It’s nice to hear that at least in this case, it is.
A new client as in you uninstalled and reinstalled the same client, or did you install a different client? Which client is it that is working - full or instant client? I've had this problem as well and would love to know how to solve it.
Reply by John Dorlon
Thanks for that last comment, Kevin. A lot of the time when we hear about Toad "taking forever to come back" after a lost connection, we can't reproduce it in-house. We've tried unplugging network cables, disconnecting and reconnecting VPNs, shutting down and bouncing databases, etc. I've always suspected that the Oracle client is largely responsible for these kinds of things. It's nice to hear that at least in this case, it is.
I don’t know about Kevin, but for me, it seems like the problem has been some combination of instant and non-instant, 32 and 64 bit, and I don’t know exactly what that combination is. I think maybe installation order has something to do with it (or which one comes first in the path). When it happens I remove them all and reinstall only what I need. It doesn’t seem to matter which one I reinstall, and I suspect that I could reinstall all of them if I did it in the “right” order (whatever that is)
407-515-4452