Oracle12c R2 on Windows 10 starts only one of two instances. Manual start results in LRM-00109

Question

I have installed Oracle 12c R2 on my local Windows 10 (64 Bit) machine. For the installation I choose only to install the software.

After the installation I have used the tool that comes with the installation to create databases. After the first database was created and started I was able to connect to it without any problems.

But after I created a second database and restarted the machine only the newly created database was started.

The first database is not started on boot and I cannot start it using sqlplus. I get the error

SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: Parameterdatei 'D:\ORACLE\PRODUCT\12.2.0\DBHOME_1\DATABASE\INITDBNAME.ORA' konnte nicht ge┐ffnet werden

The said file does in fact not exist. But such a file does also not exist for the other database. The directory contains a SPFILE<DBNAME>.ORA though for both databases. As far as I know oracle uses this pattern SPFILE<DBNAME>.ORA when starting the database. If cant find said file it goes on to use INIT<DBNAME>.ORA.

I have created a INITDBNAME.ORA file and added the content:

SPFILE = 'D:\SPFILEDBNAME.ORA'

and tryed to start the database using startup pfile = 'D:\INITDBNAME.ORA' but the result was a

ORA-00205: Fehler beim Identifizieren der Kontrolldatei

error. Also confusing was that if the pfile was inside the Oracle Directory the command failed saying it cannot access the file.

EDIT After I have deleted both instances, rebooted and created both instances again I can currently access them both.

When I try to login to the first instance I get the following error:

ERROR:
ORA-01116: Fehler beim Íffnen der Datenbankdatei 5
ORA-01110: Datendatei 5:
'D:\ORACLE\ORADATA\INSTANCE\DATAFILE\O1_MF_UNDOTBS1_DPKMRD6L_.DBF'
ORA-27041: Datei kann nicht ge÷ffnet werden
OSD-04002: Datei kann nicht ge÷ffnet werden
O/S-Error: (OS 5) Zugriff verweigert

EDIT The Mirosoft Service Manager reports both inscantec as runngin.

Setting ORACLE_SID does not make any difference. After the installation of both instances I can connect via

sqlplus sys@instance1 as sysdba
or 
sqlplus sys@instance2 as sysdba

But this goes well only for a short time. After couple of minutes it starts to throw ORA-01110 when I connect to the first instance.

The data files are not missing. They are in the location in which Oracle reports them missing.

Answer 1

I ran into the same problem. The database did not start with the service. First I checked the setting for the service using the Oracle Administration Assistant for Windows and configured the DB to start with the service start (by the way, I prefer the database to shut down immediately when the service is shut down).

But enabling the database to open at service start didn't solve the problem. Next I found that the folder %ORACLE_HOME%\database was read-only, and I did not succeed to clear this attribute using the properties dialog in the Windows Explorer. The attrib program showed no R flag, though...

It was not possible to start up the database as SYSDBA from sqlplus either - I got the same LRM-00109 error. So I copied the SPFILE to an INIT<INSTANCE>.ora file and edited it. Startup wasn't possible either, except when I used

startup open pfile='(ORACLE_HOME)\database\init(Instance).ora'

I finally changed the service from running as a virtual account to running as Local System - that works...

The Oracle version I use is 12.2.0.1 - I guess there is some problem with it.

Answer 2

I have found the problem which was that the databases started by the Windows service manager were started with a user that appears not to have sufficient permissions.

This is confusing since I have selected the default setting while installing to use Oracles virtual user. This virtual user seems not to have write permission to some files of the database.

I have changed the user by which the services are started from Oracles virtual user to the Windows "Local System" option. Since that both databases are running seemingly fine.