Oracle sql developer restoring windows висит

At present I cannot run it (SQL Developer 4.1) because it hangs on «Restoring Editors» while starting. I suppose I’ve done it by exiting it before by killing sql developer process because it was hanged on fetching objects to Schema Browser so long…
Maybe I would clean some temporary files but can’t find any.
Any ideas?

# listener.ora Network Configuration File: C:appDevRocketsproduct21chomesOraDB21Home1NETWORKADMINlistener.ora
# Generated by Oracle configuration tools.

DEFAULT_SERVICE_LISTENER = XE

SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(SID_NAME = CLRExtProc)
(ORACLE_HOME = C:appDevRocketsproduct21cdbhomeXE)
(PROGRAM = extproc)
(ENVS = «EXTPROC_DLLS=ONLY:C:appDevRocketsproduct21cdbhomeXEbinoraclr.dll»)
)
)

LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)

# tnsnames.ora Network Configuration File: C:appDevRocketsproduct21chomesOraDB21Home1NETWORKADMINtnsnames.ora
# Generated by Oracle configuration tools.

XE =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = XEPDB1)
)
)

LISTENER_XE =
(ADDRESS = (PROTOCOL = TCP)(HOST = localhost)(PORT = 1521))

ORACLR_CONNECTION_DATA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
(CONNECT_DATA =
(SID = CLRExtProc)
(PRESENTATION = RO)
)
)

В настоящее время я не могу запустить его (SQL Developer 4.1), потому что он зависает при запуске «Восстановление редакторов». Полагаю, я сделал это, выйдя из него раньше, убив процесс разработчика sql, потому что он так долго зависал при получении объектов в Schema Browser … Может быть, я бы очистил некоторые временные файлы, но не могу их найти. Есть идеи?

1. Удалить файлы истории из C:UsersUserAppDataRoamingsqldeveloper

2. Перезагрузите ПК

В моем случае решение было довольно странным. После двух дней борьбы за решение этой проблемы не повезло. Внезапно на своем Mac я стал искать разработчика sql, а не sqldeveloper. Он открыл приложение sqldeveloper (не уверен, чем оно отличается от того, что я пытался открыть), щелкнул его и, бум, он открылся. Я предполагаю, что в моей системе есть копия этого приложения, которую я должен был открыть, а не пытаться открыть переустановленное приложение. Примечание. Я переустановил приложение после того, как оно начало работать некорректно.

В моем случае, когда я изменил Tools --> Preferences --> Environment -> Look and Feel на Windows, проблема решена.

В моем случае проблема была связана с проблемой совместимости с Windows. Итак, я выбрал свою версию для Windows, и она перестала случайным образом вылетать после запуска

Просто запустите sqldeveloper от имени администратора. Работает нормально!

Удалите папки c: Users USERNAME AppData Roaming SQL Developer system4.1.3.20.78 system_cache *. SQLDeveloper воссоздает его после запуска.

Удаление файлов из c: Users MY_USER AppData Roaming SQL Developer SQL History и c: Users MY_USER AppData Roaming SQL Developer System … Действительно помогло мне решить проблемы с подключением

Database upgrade time.

I'm running an upgrade from Oracle9i to 10g. So far it's going well. I'm at the part where my old database is being converted to 10g. The DB is around 16GB's in size and right now I'm going on 9 hours of "conversion". The progress bar is at 85%.
Does this sound about right for the size of DB I have?
The load on the box doing the upgrade is very low and there is almost no CPU activity (as observed by top). If I physically go and look at the server itself, the hard drive is completely inactive for the most part.
Just seems like a DB upgrade would be a bit more processor or disk I/O intensive!
Anyways, appears it should be done in the next few hours at the rate it's going.
Thanks. 

Just a follow up on this. It's been nearly two and a half hours, and the progress bar is still stuck at 85% :-(
Guess it's hung.
Don't see any reference in the manual on what to do if this fails, so I guess my only option is to abort the upgrade and start it over again.
Good thing this is a test run on a test server. :-)

catupgrd script for upgraging to 10.2.0.3

Hello -
Everytime I have run the catupgrd script (migrating from 8i to 10g, or applying the 10.2.0.3 patch set) it has never run more than 25 minutes. However, I just recently upgraded a database where it took an hour and eighteen minutes to run. Has anyone ever seen the script run this long? It is just updating the data dictionary. Correct?
Thanks! 

Has it ended anyway? Or an error was displayed? It looks like a potential performance issue. When upgrading most of the activity impacts the physical I/O access to the tablespace SYSTEM and SYSAUX. Shared Pool also receives an strong load. Concurrence and other factors such as available memory, redo log distribution might have affected the upgrade process. 

It did end, and ran without errors. However, in this one environment it took an hour and eighteen minutes to run. It has always only taken around 25 minutes to run. Could it be that the console output to the screen would have slowed it down? When I run this, I minimize the ssh2 window, so the output is not displayed on the screen. However, the person that ran this script may have had the window up all of the time, and that could have slowed down the completion time?
Thanks! 

It could be, displaying the output to the screen slows down the process. However a general check could be advisable. 

Thanks for the response. I also did some testing, and see a long slow-down when running with the console open.
Thanks!

Export hanging up

I just ran into an unusual situation. I've got an automated job that runs overnight. The first step is to export the data out of the cubes before I run manipulations on the data. This way I've got a fall back position. This job has been successfully running for months.<BR><BR>Last night, one of the exports hung up on me and never moved past that step. I checked to make sure that there was no one on the server at that time and no file system back up was running. Any ideas as to what could cause an export to lock up and what can I do to make sure it doesn't happen again in the future?<BR><BR>Running Essbase 6.5.7 on Win2K Service Pack 4.<BR><BR>Thanks,<BR><BR>Jeff Baumert<BR>Sr. Programmer/Analyst<BR>Citizens Communicaitons<BR>jeffrey.baumert#frontiercorp.com 

Of the top of my head - a block was locked and the export couldn't move past this point .... ran out of disk space ... network error during export (more difficult to prevent recurrence) ... I've known virus scans to cause problems.<BR><BR>Its quite often difficult to find out the reasons for one-off fails like this. Is this a one off or has this happened before?<BR> 

One-off unfortunately. We just had two clean runs this past weekend<BR><BR>Plenty of disk space and as far as I know no one was on the system. Though it may not hurt to add a step to unlock any blocks in the system before going forward.<BR><BR>I'll have to check to see if an automated virus scan was running.<BR><BR>Thanks for your advice,<BR><BR>Jeff 

We had a similiar issue where sporadically(and mean sporadically) our nightly tape backups were causing the data export to fail. It took some time with Hyperion Tech support and some 3rd party utilities to determine that the backup had a lock on a page or index file and carpped out the export.<BR>We then changed the tape backup to exclude certain Essbase files and we haven't had a problem since. 

Backups used to cause us all sorts of headaches at my last place if they overran but for us if the backup hadn't finished, the essbase server hadn't been restarted so not a hope of much happening really. Put in a check before the Essbase jobs ran to check that backup done, if not, checked again 10 mins later and so on ... and never had the problem again.<BR>

Database effects of changing OS time

Hi all,
Does anyone know or have any links to articles that specfiy whether changing the OS time (putting it back in time) will effect the database in any way? Mainly I would just like to know whether or not the database will continue to run normally.
I believe that doing this shouldn't cause any problems and the only things that might be problems are doing point in time recovery.
My Oracle versions are: 9.2.0.6 and 10.2.0.2
OS: Solaris 10
I appreciate your thoughts.
Thanks,
Dave 

The first thing that comes to my mind are all the queries that are dependant on SYSDATE or SYSDATETIME will be affected. So you might want to do a complete impact analysis before you change the server date. 

If the amount of time you are going back isn't too long (say, 10 minutes - you'll know best what your maximum downtime window is), then you could shutdown all Oracle-related stuff and wait for the server's time to go past the time it was when you shutdown the Oracle-related stuff. Else, you need to be very careful about anything that relies on dates, as Lost_in_Transit said. 

Hi,
"Following a time change where the clocks go back in time there is a window where INCOMPLETE recovery using TIME BASED recovery is affected."
In addition, try take a research about "How Does Daylight Savings Time Affect The Database?" or take a look at Note:1013279.6 from Oracle Metalink.
Cheers
Legatti 

Thanks for your comments.
Aside from potential application problems, it shouldn't actually stop the database itself from being started and running etc. then?
Dave 

If you wait for the new server time to progress past the time when the DB was shutdown, then no issues, as the DB then never "knows" that anything happened with the server time.

wrong os pid

OK, here's one I never expected to see. First some background:
hp-ux 10.2.0.4 Itanium.
An app connects to Oracle with beq connections. I watch Oracle with the activity screen in dbconsole, where it gets real obvious when someone goofs up the parameters to a report, making a runaway process that takes over a cpu for a long time. I don't bother with any resource limits because sometimes it is legitimate. I also have a cron that kills off any production Oracle processes in the middle of the night that aren't supposed to be on then. This has worked fine for years. I keep a file of what is being killed, and another file of all the processes. Since I can look at the SQL in dbconsole and am familiar with the app, I can usually tell if it is something dumb the user has done and is too embarrassed to fess up to, or something possibly legit. The app creates two connections to two different schemata, so a typical goof is the user X'ing out of the client, which they are told not to do, the app can't really tell Oracle to stop that way if Oracle if off processing a request.
Yesterday I noticed one, but I was busy with some other stuff and just let it go, thinking the autokill would get it.
This morning I saw it was still running. After first thinking it must obviously be some case I missed in the autokill, I killed it with dbconsole. The session screen show last call elapsed 21 hours, logged on 1 day 5 hours, obviously the right thing to kill. I didn't notice right away that instead of the usual message of marked for kill, it said ora-30 user session id does not exist. It says OS process id is 6572. But the cpu usage went down as expected.
Looking at my kill log, I see the session with the expected huge processing time, but the process id is 6574. Looking at the list of all processes, there is the 6574, but no 6572.
wtf? 

Possible OS bug ? How long has the server been up (i.e. when was it last re-booted) ?
Srini 

schavali wrote:
Possible OS bug ? How long has the server been up (i.e. when was it last re-booted) ?
Srini66 days for server and oracle, but wow, I'd believe an Oracle dbconsole or sysstat bug before an hp-ux bug... more likely is some app specific bug that somehow twisted itself into this, but I have no clue about that.

Вопрос

В настоящее время я не могу запустить его (SQL Developer 4.1), потому что он зависает на «Восстановлении редакторов» при запуске. Я предполагаю, что я сделал это, выйдя из него раньше, убив процесс sql developer, потому что он завис на получении объектов в Schema Browser так долго…
Может быть, я бы почистил временные файлы, но не могу их найти.
Есть идеи?

Похожие сообщества
8