It cost me the best part of two days' detective work to fix a problem with the Oracle DB Control service. Symptoms include:
Background: For a client project, we needed a local copy of the client's schema and stored procedures. I found it remarkably straightforward to install the Oracle product and a default database instance named orcl. However, attempting to import the client's exported schema and stored procs caused a rash of errors and then the SYSTEM user's password had been corrupted too. My suggestion: use the deprecated exp and imp tools instead. They're much more straightforward to use, AND the wonderful DDL Wizard is able to convert the exported file to DDL and PL/SQL that you can run in SQLPlus instead of overwriting your database contents willy-nilly.
Solution: I wish there was one. The problem appears to occur in the final phase of the database configuration assistant - after creating and configuring the database it tries to start up the console service for it and fails, for as-yet unfathomable reasons. Could it be to do with the fact that we also run MS SQL Server on the same box? Yet this was fine before I tried to reinstall Oracle. (As I eventually learned, I need not have redone the entire installation, because the database configuration assistant is quite good at deleting the database instance and creating a new one - in fact, this is what the installer invokes anyway).
Luckily the whole thing runs on a virtual machine, so I am going to get the previous week's VM backup image restored. Luckily we hadn't been doing a lot of work on that machine in the meantime.
My grateful thanks to the many bloggers who came up with possible solutions - none of which worked for me:
- "CONFIG: Waiting for service 'OracleDBConsoleorcl' to fully start" in cfgtoollogs\dbca\orcl\cloneDBCreation.log
- "The oracleDBconsoleorcl service could not be started"
- "[Orion Launcher] ERROR app.ContextInitializer contextInitialized.272 - Integration Class not found: oracle.sysman.ias.ias.IASIntegration" in emoms.log
Background: For a client project, we needed a local copy of the client's schema and stored procedures. I found it remarkably straightforward to install the Oracle product and a default database instance named orcl. However, attempting to import the client's exported schema and stored procs caused a rash of errors and then the SYSTEM user's password had been corrupted too. My suggestion: use the deprecated exp and imp tools instead. They're much more straightforward to use, AND the wonderful DDL Wizard is able to convert the exported file to DDL and PL/SQL that you can run in SQLPlus instead of overwriting your database contents willy-nilly.
Solution: I wish there was one. The problem appears to occur in the final phase of the database configuration assistant - after creating and configuring the database it tries to start up the console service for it and fails, for as-yet unfathomable reasons. Could it be to do with the fact that we also run MS SQL Server on the same box? Yet this was fine before I tried to reinstall Oracle. (As I eventually learned, I need not have redone the entire installation, because the database configuration assistant is quite good at deleting the database instance and creating a new one - in fact, this is what the installer invokes anyway).
Luckily the whole thing runs on a virtual machine, so I am going to get the previous week's VM backup image restored. Luckily we hadn't been doing a lot of work on that machine in the meantime.
My grateful thanks to the many bloggers who came up with possible solutions - none of which worked for me:
- drop and reconfigure the repository
- work around Windows's tendency to use different hostnames depending on network connectivity
2 comments:
Looking for answers to some other problems in the same technological field, I came across a reference that this non-starting console was actually a well known problem. The answer may be an upgrade to 10.2.0.5 or later.
The suggestion is that the console process has actually started successfully, so everything works, but it doesn't report this back correctly to the process that started it. I find this theory plausible because everything appears to work fine even with the apparently missing console (a.k.a. database control) service.
Interesting article... Thanks for sharing your views and ideas...
Oracle Training in Chennai
Post a Comment