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
