Print Thread
Very bad recovery file bug
#44371 08/09/12 02:52 PM
Joined: Aug 2012
Posts: 6
G
Gronon Offline OP
Member
OP Offline
Member
G
Joined: Aug 2012
Posts: 6
Hello,
When PL/SQL developer crashes the recovery file loads a version of my programs that is older than what is saved to disk. This has resulted in lost work for me until I figured out what was happening.
if I click the save button the recovery file should be up to date!

Also, if a thread hangs up because an oracle process is taking forever it should not hang up the entire PL/SQL instance. especially when it is running in multi user mode. The combination of this and the above problem really causes me and my coworkers lot of headaches. Enough so that we are starting to consider other options unless you can reassure us this will get fixed.

Re: Very bad recovery file bug
Gronon #44372 08/09/12 02:53 PM
Joined: Aug 2012
Posts: 6
G
Gronon Offline OP
Member
OP Offline
Member
G
Joined: Aug 2012
Posts: 6
And just FYI, we have about 25 licenses for this product.

Re: Very bad recovery file bug
Gronon #44376 08/10/12 09:18 AM
Joined: Aug 2011
Posts: 339
T
Member
Offline
Member
T
Joined: Aug 2011
Posts: 339
Very good points.

Re: Very bad recovery file bug
T-Gergely #44378 08/10/12 09:39 AM
Joined: Aug 1999
Posts: 22,219
Member
Offline
Member
Joined: Aug 1999
Posts: 22,219
We'll check out the recovery file issue.

Can you give an example of the hang-up situation? Are you using Dual-Session or Multi-Session mode (Tools > Preferences > Oracle / Connection)? This should normally prevent any hang-ups, because all database activities occur in background threads.


Marco Kalter
Allround Automations
Re: Very bad recovery file bug
Marco Kalter #44380 08/10/12 02:46 PM
Joined: Aug 2012
Posts: 6
G
Gronon Offline OP
Member
OP Offline
Member
G
Joined: Aug 2012
Posts: 6
I am using Multi-Session mode. This usually happens if I have a long running query and PL/SQL won't let me kill it by either clicking the stop button or using the 'terminate running query' dialog. After a couple attempts of terminating the execution the whole PL/SQL window will fade to white and show the windows wait cursor. Sometimes if I issue an alter system kill command on the oracle process it will come back but sometimes it will be permanently locked up and I have to use task manager to close the whole thing down.
I generally have 10 to 15 PL/SQL sub windows open of all different types. My machine has 8 GBs of Ram so memory shouldn't be an issue.

An example of when this last happened: A developer wanted help with a query against a large table (50+ GBs). I foolishly ran it without checking it first and realized too late that his query was too vague for the amount of data and it would take a long time to return. I attempted to stop the query in PL/SQL but after clicking the stop button 3 times the entire program faded to white. I could not recover the program by terminating the oracle process.

I am running on 64 bit windows 7.

Re: Very bad recovery file bug
Gronon #44393 08/13/12 04:40 PM
Joined: Aug 2012
Posts: 6
G
Gronon Offline OP
Member
OP Offline
Member
G
Joined: Aug 2012
Posts: 6
I have more information on the PL/SQL Dev window being unresponsive. I just tried to compile a package that was in use by another developer. The whole PL/SQL Dev window faded to wait with a busy cursor. I was about to terminate the process in task manager when it finally came back after several minutes with an "ORA-00060 deadlock detecked while waiting for resource". I would have been ok with the package window freezing up because I could continue to work until it came back but the entire window with my 15 sessions hung up at the same time. The other sessions were not dependant on the package that was deadlocked.

Any help would be appreciated.

Re: Very bad recovery file bug
Gronon #44400 08/14/12 09:46 AM
Joined: Aug 1999
Posts: 22,219
Member
Offline
Member
Joined: Aug 1999
Posts: 22,219
To prevent that you need to wait for compilation locks you can enable the "Background compilation" option (Tools > Preferences > Program Window):

[quote]When enabled, compilation is performed in a background thread, using a separate session. This way you can continue other work while the compilation occurs. It will lead to an extra database session for each Program Window though. Note that this preference is only effective if the Session Mode preference (see Oracle - Connection) is set to Multi Session.[/quote]


Marco Kalter
Allround Automations
Re: Very bad recovery file bug
Marco Kalter #47139 05/29/13 08:17 AM
Joined: Jun 2011
Posts: 14
L
Member
Offline
Member
L
Joined: Jun 2011
Posts: 14
i also have such problem!! restart of the application didn't going successfully (old versions of edited files, old state of db objects). after starting we must manually analyze state of opened windows by recovery. very strange behavior, because time of recovery files and time of hang is different.. last situation have such difference in 50 minutes..

Version 10.0.3.1701

Last edited by longman; 05/29/13 08:17 AM.
Re: Very bad recovery file bug
longman #47493 07/19/13 08:38 PM
Joined: Aug 2007
Posts: 53
Phoenix
J
Member
Offline
Member
J
Joined: Aug 2007
Posts: 53
Phoenix
This problem has existed for a very long time, and I (like you) didn't realize that the auto-recovery didn't retain the last saved file contents.

Every time I recover from a crash, I always compare all windows (with the last saved version of the file) to see what has changed, and close all open windows.

The reason I close all open windows is because I seem to recall that, for a file that may have been changed outside of PL/SQL Developer, you may not get the "<filename> timestamp has changed" prompt for a file that was opened from the recovery area (one that has "Recovery file loaded" in the status bar). Note that I haven't verified that this is still a problem with the latest PL/SQL Developer version, but I'm guessing that it still is.

I would think that saving a file to disk would cause PL/SQL Developer to immediately also update the window's current text information in its recovery file, but no. It is an annoying situation, but that just seems to be the way it is (sigh).


Moderated by  support 

Link Copied to Clipboard
Powered by UBB.threads™ PHP Forum Software 7.7.4
(Release build 20200307)
Responsive Width:

PHP: 7.1.33 Page Time: 0.066s Queries: 15 (0.031s) Memory: 2.5356 MB (Peak: 3.0394 MB) Data Comp: Off Server Time: 2024-05-16 07:01:18 UTC
Valid HTML 5 and Valid CSS