ORA-12709: error while loading create database character set

Problem Description
While mounting oracle database it fails with ORA-12709 like below.

SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-12709: error while loading create database character set

Cause of the Problem
The error ORA-12709 is returned due to incorrect setting of environmental variable NLS_LANG
or ORA_NLS33.

Solution of the Problem
Check your NLS_LANG environmental variable by,
$echo $NLS_LANG.
If it is set to wrong value and your database character set is WE8ISO8859P1 then set by,
$export NLS_LANG=American_America.WE8ISO8859P1

Note that, For Oracle7 V7.3.2 version ORA_NLS33 environmental parameter is called ORA_NLS,
for Oracle7 V7.3.3 and V7.3.4 it is called ORA_NLS32,
for Oracle8 it is called ORA_NLS33 because of NLS libraries version.

When using both Oracle8 V8.x and Developer/2000 V1.6.1 in the same Oracle Home, ORA_NLS33 needs to be set to $ORACLE_HOME/ocommon/nls/admin/datad2k
The environmental variable along with database version is given below.
RDBMS 7.2.x -> ORA_NLS
RDBMS 7.3.x -> ORA_NLS32
RDBMS 8.0.x -> ORA_NLS33
RDBMS 8.1.x -> ORA_NLS33
RDBMS 9.X.X -> ORA_NLS33
RDBMS 10.X -> ORA_NLS10

After you set both parameters correctly login as sys user.

$ sqlplus '/ as sysdba'

SQL*Plus: Release 9.2.0.8.0 - Production on Sun Sep 26 00:40:18 2010

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.


Connected to:
Oracle9i Enterprise Edition Release 9.2.0.8.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production

Shutdown and Startup the database.

SQL> startup force;
ORACLE instance started.

Total System Global Area 320300808 bytes
Fixed Size 734984 bytes
Variable Size 285212672 bytes
Database Buffers 33554432 bytes
Redo Buffers 798720 bytes
Database mounted.
Database opened.
SQL>

ORA-29760: instance_number parameter not specified

Problem Description
Using sql*plus whenever I do startup it fails with ORA-29760 like below.

SQL> startup nomount
ORA-29760: instance_number parameter not specified

Similarly, whenever I start my database using srvctl it returns same error like following.

$ srvctl start database -d didar
PRKP-1001 : Error starting instance didar1 on node node1
CRS-0215: Could not start resource ora.node1.didar1.inst.

If you look for imon_didar.log file inside $ORACLE_HOME/log/node1/racg there is showed that startup has failed with 'ORA-29760: instance_number parameter not specified'.

Cause of the Problem
Cause 01:
The database and instance names have been defined in lowercase in the cluster registry (OCR). That's why "srvctl start database" is being passed the argument 'test'.

However, if you look for spfile or pfile you will see that the instance names have been defined in uppercase.

DIDAR1.instance_number=1
DIDAR2.instance_number=2

Cause 02:
You are using sql*plus and within your pfile/spfile it is set proper name that is in lower case. But your environmental variable value of ORACLE_SID contains uppercase database SID "DIDAR". In such case, ORA-29760 will also be reported whenever you try to startup your database.

Solution of the Problem
srvctl is case sensitive. So you need to ensure that the instance and database definitions set in the spfile/pfile are the same case as those in the OCR and as are used in the srvctl commands.
Before going into solution be sure that your ORACLE_SID reflects the correct case so that the instance can be accessed using SQL*Plus. If your ORACLE_SID environmental variable is set to uppercase but inside pfile/spfile it is set to lowercase then you might face the problem.

If they are not then either:

Solution 01
If you use spfile, then

SQL> create pfile from spfile;

Edit the pfile to alter all definitions to the correct case

SQL> create spfile from pfile=[location of pfile here];

SQL> startup

Solution 02
modify the definitions in the OCR:

srvctl remove instance -d didar -i didar1

srvctl remove instance -d didar -i didar2

srvctl remove database -d didar

srvctl add database -d DIDAR -o $ORACLE_HOME

srvctl add instance -d DIDAR -i DIDAR1 -n [node1]

srvctl add instance -d DIDAR -i DIDAR2 -n [node2]

Solution 03
In the pfile add instance_number=1 value.
$ vi newpfile.ora
SPFILE='+DATA/DIDAR/spfileDIDAR.ora'
instance_number=1

SQL> connect sys as sysdba
Enter password:
Connected to an idle instance.

SQL> startup pfile='/opt/app/oracle/product/10.2.0/db_1/dbs/newpfile.ora'

SQL> alter system set instance_number=1 scope=spfile;

SQL> shutdown immediate;

SQL> startup

Database startup fails with ORA-00064

Problem Description
Case 01: After it is set SGA_TARGET to 100G with a total of about 300G physical memory on the server "startup" fails with
ORA-00064: object is too large to allocate on this O/S (1,15429280) errors

Case 02: The parameter OPEN_LINKS_PER_INSTNACE is set to 1000 and then startup of the instance causes ORA-00064.

Case 03: After it is set high value of PROCESSES parameter, whenever you try to startup the instance it fails with ORA-00064.

Case 04: "db_files" initialization parameter on 64bit versions of Oracle is set to a higher value and now startup does not work.

Cause of the Problem
As it is already discussed in the post startup migrate fails with ORA-00064 while upgrading to 10.2.0.2 with DBUA the problem happened due to lower default value of oracle hidden parameter _ksmg_granule_size.

The calculation is,
- sga_max_size <= 1024M then _ksmg_granule_size = 4M - sga_max_size > 1024M and <128g then _ksmg_granule_size = 16M - sga_max_size > 128G and <256g then _ksmg_granule_size = 32M - sga_max_size > 256G and <512g then _ksmg_granule_size = 64M

Solution of the Problem
Solution 01: The issue is fixed in Oracle 10.2.0.4.3 (Patch Set Update) and 10.2.0.5 (Server Patch Set). So applying patch will solve the problem.

Solution 02: Disable NUMA optimization on the system
To do this set two hidden parameters like below.
_enable_NUMA_optimization=FALSE
and
_db_block_numa=1

Solution 03: Increase granule size on the system (_ksmg_granule_size)
_ksmg_granule_size=32M

Solution 04: If your PROCESSES initialization parameter has higher value then reduce the value. For example make it less than 1500. Also set the DB_FILES parameter to lower value.

startup migrate fails with ORA-00064 while upgrading to 10.2.0.2 with DBUA

Problem Description
It was tried to upgrade an oracle database from version 9.2.0.7 to 10.2.0.2 using oracle database upgrade assistant. After invoking DBUA ORA-00064: returns. If you also issue startup upgrade from sql*plus it also fails like below.

SQL> startup upgrade
ORA-00064: object is too large to allocate on this O/S (1,7614720)

Cause of the Problem
1. The oracle PROCESSES initialization parameter is set to high value. For example, if you set 'Processes' parameter to a high value (for example > 14000), the instance startup fails with ORA-00064.

2. Low value of granule size.

The oracle hidden parameter "_ksmg_granule_size" is set based on the oracle sga size.
The calculation is,
- sga_max_size <= 1024M then _ksmg_granule_size = 4M
- sga_max_size > 1024M and <128g then _ksmg_granule_size = 16M
- sga_max_size > 128G and <256g then _ksmg_granule_size = 32M
- sga_max_size > 256G and <512g then _ksmg_granule_size = 64M

Now if you set high value of a parameter(for example DB_CACHE_SIZE, SHARED_POOL_SIZE, LARGE_POOL_SIZE, JAVA_POOL_SIZE) that exceeds the value of the granule size that was calculated based on the size of the sga.

If your SGA size is over 1G then you will manually have to set the parameter _ksmg_granule_size. Note that the default setting of _ksmg_granule_size is 4M and low value of _ksmg_granule_size can prohibit the database startup if your memory value is over 1G.

3. "db_files" initialization parameter on 64bit versions of Oracle is set to a higher value.

4. The ORA-00064 error could be occurred even though the big "_ksmg_granule_size" was configured in init.ora file as because during DBUA in 10.2.x it strips out the oracle hidden parameter while opening oracle database.

Solution of the Problem
Solution 01:
Reduce the value of the oracle "PROCESSES" initialization parameter.

For example, open oracle parameter file with editor and put following line
PROCESSES = 1500

Solution 02:
Increase Oracle hidden parameter value of "_ksmg_granule_size" directly to 16M (16777216) or 32M (33554432)

- open oracle parameter file with editor and put following line
_ksmg_granule_size=16777216
or
_ksmg_granule_size=33554432

- Start up gradation manually.

Solution 03:
- Increase SGA size bigger than 1024M to affect granule size. Open oracle parameter file with and editor and put following line
sga_max_size = 1028M

Solution 04:
- Run DBUA with -initParam flag.

$ dbua -initParam "_ksmg_granule_size"=16777216
or
$ dbua -initParam "_ksmg_granule_size"=33554432

ORA-01102: cannot mount database in EXCLUSIVE mode

Problem Description
While I start oracle database instance it fails with following error.
Connected to an idle instance.
ORACLE instance started.
Total System Global Area 877574740 bytes
Fixed Size 651436 bytes
Variable Size 502653184 bytes
Database Buffers 263840000 bytes
Redo Buffers 10629120 bytes
ORA-01102: cannot mount database in EXCLUSIVE mode

Problem Investigation
After you hit ORA-01102 error you should immediately check your database alert log for further analysis. Following is the sample example error messages generated in the alert log after you hit ORA-01102.

Alert log Error Message Version 01
ALTER DATABASE MOUNT
Wed Oct 22 03:40:21 2009
scumnt: failed to lock /dba/oracle/product/920/dbs/lkARJU exclusive
Wed Oct 22 03:40:21 2009
ORA-09968: scumnt: unable to lock file
Linux Error: 11: Resource temporarily unavailable
Additional information: 26165
Wed Oct 22 03:40:29 2009
ORA-1102 signalled during: ALTER DATABASE MOUNT

Alert log Error Message Version 02
ALTER DATABASE MOUNT
Mon Mar 6 15:31:21 2009
scumnt: failed to lock /apps/oracle/product/9.2/dbs/lkARJU exclusive
Mon Mar 6 15:31:21 2009
ORA-09968: scumnt: unable to lock file
Compaq Tru64 UNIX Error: 13: Permission denied
Additional information: 1246156
Mon Mar 6 15:31:21 2009
ORA-1102 signalled during: ALTER DATABASE MOUNT...

Cause of the Problem
This ORA-01102 error indicates an instance tried to mount the database in exclusive mode, but some other instance has already mounted the database in exclusive or parallel mode. By default a database is started in EXCLUSIVE mode. The real cause of ORA-01102 would be found in the alert log file where you will find additional information. The common reasons causing error ORA-01102 are as follows.

1) The processes for Oracle (pmon, smon, lgwr and dbwr) still exist. You can search them by ps -ef |grep YOUR_DB_NAME_HERE.

2) Shared memory segments and semaphores still exist even though the database has been shutdown.

3) There exists a file named "$ORACLE_HOME/dbs/lk{db_name}" where db_name is your actual database name.

4) A file named "$ORACLE_HOME/dbs/sgadef{sid}.dbf" exists where sid is your actual database SID.

5) You have two databases in your host. Now starting anyone of these causes error ORA-01102 if the other one is already started. If one is shutdown, the other database can be started successfully. This happened as while starting up, both the databases are trying to lock the same file. This is obvious if within the parameter files for these databases have the same entries for control_files and db_name. For example you have two databases named dba1 and dba2. Now inside the spfile/pfile of both databases that is inside initDBA1.ora and initDBA2.ora (in case of pfile) you have the similar entries like below.

...
*.control_files='xxx/control01.ctl','xxx/control02.ctl','xxx/control03.ctl'
*.db_name=DBA1
...

Solution of the Problem
1) Verify that there are no background processes owned by "oracle"
$ ps -ef | grep ora_ | grep $ORACLE_SID

If background processes exist, remove them by using the Unix "kill" command.
For example to kill a process ID number 7818 issue,
$ kill -9 7818

2) Verify that no shared memory segments and semaphores that are owned by "oracle" still exist.
Verify by command,
$ ipcs -b

If there are shared memory segments and semaphores owned by "oracle", remove the shared memory segments.
To remove shared memory segment issue,
$ ipcrm -m Shared_Memory_ID_Number
where Shared_Memory_ID_Number must be replace by shared memory id number.

To remove the semaphores issue,
$ ipcrm -s Semaphore_ID_Number
where Semaphore_ID_Number must be replaced by your Semaphore ID Number.

3) Verify that file $ORACLE_HOME/dbs/lk{db_name} does not exist where db_name is your actual database name.

4) Verify that file "$ORACLE_HOME/dbs/sgadef{sid}.dbf" does not exist where sid is your actual database SID.

5) If you see you have several databases in your machine and both of them uses have same entry in the parameter control_files and db_name then use correct values belonging to the individual databases.

In the sql*plus nomount stage you can issue,
show parameter db_name;
show parameter control_files;
in order to verify the entry.

6) From alert log if you see error like "Compaq Tru64 UNIX Error: 13: Permission denied" then ensure that in the file/directory oracle has permission and ensure that oracle is owner of the file. With chmod and chown you can change permission and ownership respectively.

Note that The "lk{db_name}" and "sgadef{sid}.dbf" files are used for locking shared memory. It may happen that even though no memory is allocated, Oracle thinks memory is still locked. By removing the "sgadef" and "lk" files you remove any knowledge oracle has of shared memory that is in use. So after removing those two file you can try to startup database.

Related Documents
http://arjudba.blogspot.com/2009/05/ora-27100-shared-memory-realm-already.html
http://arjudba.blogspot.com/2008/11/ora-01033-oracle-initialization-or.html
http://arjudba.blogspot.com/2008/09/database-startup-fails-with-ora-27302.html
http://arjudba.blogspot.com/2008/09/database-startup-fails-with-ora-00444.html
http://arjudba.blogspot.com/2008/05/database-startup-fails-with-errors-ora.html
http://arjudba.blogspot.com/2008/04/ora-01034-ora-27101-shared-memory-realm.html

ORA-27100: shared memory realm already exists

While you connect to database, if ORA-27100 is signalled with ORA-01034 then have a look at the post http://arjudba.blogspot.com/2008/04/ora-01034-ora-27101-shared-memory-realm.html

However if you merely see ORA-27100 error upon startup then proceed with this post.

Problem Description
When you try to startup your database instance even you issue startup nomount ORA-27100 is reported.

SQL> startup nomount
ORA-27100: shared memory realm already exists

Similarly, if you try to shutdown your oracle instance then ORA-27100 is reported.

SQL> shutdown immediate
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist

Restarting the service also does not help any. And even in some cases, rebooting the server does not help as well.

Current Changes in the Server
We had sga_max_size to 600M and then we change it to 1G. After that whenever we restart oracle database above message rises.

Cause of the Problem
Some changes are made in sga_max_size or sga parameters. After that database is abnormally shut down whenever you issue startup, ORA-27100 is received as a result of changes made to parameters affecting the SGA size.

Solution of the Problem
In most cases, ORA-27100 can be resolved by simply restarting Windows. However if avaialibility is too important and you can't afford the time of starting windows then,
- Move/ Rename database spfile so that next time starting database service can invoke old pfile to startup.

- Start the database service. Make sure pfile exist with old sga parameter settings.

- Now the service will start the database using pfile , with old SGA settings.
and you have started your database successfully.

- Create a new spfile from pfile.

Related Documents
http://arjudba.blogspot.com/2008/05/startup-fails-with-oracle-error-ora.html
http://arjudba.blogspot.com/2008/09/database-startup-fails-with-ora-27302.html
http://arjudba.blogspot.com/2008/07/database-startup-fails-with-error-ora.html
http://arjudba.blogspot.com/2008/08/startup-fails-with-ora-01261-parameter.html

http://arjudba.blogspot.com/2008/09/database-startup-fails-with-ora-00444.html
http://arjudba.blogspot.com/2008/05/database-startup-fails-with-errors-ora.html

ORA-01033: ORACLE initialization or shutdown in progress

Error Description
While connecting to database user get the error,
ORA-01033: ORACLE initialization or shutdown in progress

Cause of The Problem
SYSDBA used issued STARTUP command to the database and while starting up database, connecting to database as normal user will get the error ORA-01033.

There may be the scenario that SHUTDOWN command waits a long time.
Solution of The Problem
Scenario 01:
Based on the situation STARTUP may take fewer minutes. As a normal user what more you do is to wait few minutes and try again. You will succeed if database is open state.

Here is the waiting result.
C:\Documents and Settings\Queen>sqlplus arju/a

SQL*Plus: Release 10.2.0.1.0 - Production on Fri Nov 7 17:34:23 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

ERROR:
ORA-01033: ORACLE initialization or shutdown in progress


Enter user-name: arju
Enter password:
ERROR:
ORA-01033: ORACLE initialization or shutdown in progress
Enter user-name: arju
Enter password:

Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options

At third attempts I became succeed.

Scenario 02:
If you have SYSDBA privilege then connect to database as SYSDBA and see the status of the database.
SQL> conn / as sysdba
Connected.
SQL> select open_mode from v$database;
select open_mode from v$database
*
ERROR at line 1:
ORA-01507: database not mounted

SQL> select open_mode from v$database;
select open_mode from v$database
*
ERROR at line 1:
ORA-01507: database not mounted

SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

SQL> select open_mode from v$database;

OPEN_MODE
----------
MOUNTED

SQL> select open_mode from v$database;

OPEN_MODE
----------
READ WRITE

As we can see that database gradually became usable state. Someone issued STARTUP and it take some times to be in READ WRITE state.

Scenario 03:
If shutdown takes more times suppose SHUTDOWN NORMAL then issue,
SHUTDOWN ABORT;
and later normal startup,
STARTUP;

Database startup fails with ORA-27302: failure occurred at: sskgpsemsper

Error Description
Whenever I try to start my database it fails with ORA-27302: failure occurred at: sskgpsemsper as following.
RMAN> STARTUP FORCE NOMOUNT PFILE='/backup03/webkey/testinitdb.ora';

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 09/23/2008 00:45:51
RMAN-04014: startup failed: ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpsemsper

Cause of the problem
The error may mislead you. Though it indicates No space left on device but whenever I issue df -h on my OS there is enough space. The problem happened because of short of semaphores setting in the OS.

Solution of the problem
Solution 1)
Increase number of semaphores on operating system. You set semmns 32767 .
To make the setting permanent make an entry in /etc/sysctl.conf file on linux system.
sem = semmsl semmns semopm semmni
kernel.sem = 256 32768 100 228
The details is in How to configure(modify,see) Kernel Parameters in Linux

Solution 2)
Change the initialization parameter processes to a lower one in the initialization file and then startup the database. In my initialization file processes was set to 555. Whenever I start my database it fails with above error. I then reduced it to by 55 and it started my database successfully.
CREATE PFILE='1.pfile' FROM SPFILE;
edit pfile and set Processes parameter to lower value
STARTUP PFILE='1.pfile';

If you use spfile to startup your database you can use a trick to start your database which is discussed on,
http://arjudba.blogspot.com/2008/09/how-to-avoid-of-recreating-pfile-or.html.

Related Documents
Startup fails with ORA-27102: out of memory Solaris-AMD64 Error

Database Startup fails with ORA-00444, ORA-07446

Problem Description
When I start my database my instace fails with ORA-00444 and ORA-07446 as follows.
SQL> startup
ORA-00444: background process "MMAN" failed while starting
ORA-07446: sdnfy: bad value '' for parameter .

Cause of The Problem
Database startup event is logged into alert log file. And alert log file is defined by the background_dump_dest parameter inside the initialization parameter. While starting up the instance if instance fail to write into the alert log file then instance crushes and fail to startup.

Solution of The Problem
There may be different scenario whenever oracle fails to write alert log contents. Suppose the partition reside alert log file is full. In that case delete/move unnecessary file from the alert log partition directory.

There may be the case the the directory defined by the background_dump_dest does not exist in the OS.

In both case you may also like to change the background_dump_dest location inside the pfile.

If you have spfile then,
1.create pfile='/oradata2/1.pfile' from spfile;
2.vi /oradata2/1.pfile
3.Modify the background_dump_dest to a valid location and in a patition where there is sufficient space available.
4.start the database isntance.
startup pfile= /oradata2/1.pfile';
5.create spfile again.
create spfile from pfile= /oradata2/1.pfile';

Startup fails with ORA-01261: Parameter db_recovery_file_dest destination string cannot be translated

Problem Description
While I start my database with my initialization parameter it fails with oracle error ORA-01261 and ORA-01262 as below:
RMAN> startup force pfile='/oradata2/arjudbapfile.ora';

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 08/28/2008 15:04:27
RMAN-04014: startup failed: ORA-01261: Parameter db_recovery_file_dest destination string cannot be translated
ORA-01262: Stat failed on a file destination directory
Linux Error: 2: No such file or directory

Cause of The Problem
The linux error No such file or directory indicates all what you need to do. It may be the case that,

-You might not start your database with proper or recently updated pfile/spfile. May be you changed your location of your db_recovery_file_dest and that initialization parameter that you used to startup the database has not reflected yet.

-The directory location specified by the db_recovery_file_dest parameter is not on your system.
Solution of The Problem
If you start your database with pfile edit it and change the location of db_recovery_file_dest parameter to a valid one. Be sure oracle has proper permission on the directory from OS.

However if you start your database with an spfile then,
-Create pfile='1.ora' from spfile;
-Edit pfile 1.ora and change the location of db_recovery_file_dest parameter.
-Create spfile from pfile='1.ora';
-Start your database.

RMAN-04014: startup failed: ORA-07446: sdnfy: bad value

Problem Description
While performing disaster recovery to a new host, you need to start the database in nomount sate(in fact to restore control file) but database could not start in nomount state because it fails with RMAN-04014, ORA-07446.

RMAN> startup force pfile='/oradata2/arjudbapfile.ora';

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of startup command at 08/28/2008 15:03:44
RMAN-04014: startup failed: ORA-07446: sdnfy: bad value '/oracle/app/oracle/product/10.2.0/db_1/admin/arjudba/udump' for parameter user_dump_dest.

Cause of The Problem
The path /oracle/app/oracle/product/10.2.0/db_1/admin/arjudba/udump as shown in output does not exist. Oracle itself does not create any path if a path does not exist. So, you have to change the value of user_dump_dest in the initialize parameter.

Solution of The Problem
If you use pfile to start your database then edit the pfile with any editor (for example vi on unix) and either change the location of user_dump_dest or remove the parameter user_dump_dest from pfile. And then perform startup.


If you like to use spfile then first create pfile from spfile, then edit the pfile and then create spfile from the pfile, like.

1.Create pfile from spfile.
SQL> create pfile='1.pfile' from spfile='/oracle/app/oracle/product/10.2.0/db_1/dbs/spfilearju.ora';

2.Edit the pfile.
SQL>!vi 1.pfile

Remove the entry of user_dump_dest or add valid entry.

3.Create spfile from pfile.
SQL>create spfile from pfile='1.pfile';

4.start the database.
SQL>STARTUP NOMOUNT

Database Startup Fails With Errors ORA-01078 And ORA-27046 Or ORA-01078

Error Description:
-----------------------
Database startup fails with error

SQL> startup
ORA-01078: failure in processing system parameters
LRM-00109: could not open parameter file '......'

or,

SQL> startup
ORA-01078: failure in processing system parameters
ORA-01565: error in identifying file '.......'
ORA-27046: file size is not a multiple of logical block size
OSD-04012: file size mismatch (OS 2558)

Cause of The problem:
------------------------------
The error can be happened in many scenarios.

1)The ORACLE_SID environmental variable is set improperly.

2)The error occurred as database could not find the spfile and pfile on the default location or specified location.(if startup pfile= is specified)

3)The spfile exists in default location but it is corrupted and hence reported ORA-01078.

4)If spfile exists in non-default location and we started by STARTUP pfile= where inside pfile it holds the location of spfile=location then error reported ORA-1078 along with ORA-27046. This scenario is explained in How to start your database with non-default spfile.

Solution of The problem;
------------------------------
At first check whether your environment variable ORACLE_SID is set properly or not. On unix it is case sensitive. So dbase and Dbase is not same.

Is there is no way to repair or modify an spfile so try to solve the problem in following order.

1)If you have good backup of spfile then restore it. From RMAN you can easily do it if you have autobackup of controlfile. It is described in How to restore spfile by RMAN

2)You can get your pfile at the location $ORACLE_HOME/admin/$ORACLE_SID/pfile/. A typical file name is init.ora.418200821147. From that location first copy to another location like in /oradata2/pfile and then edit the pfile as necessary and try to make a spfile from that.
$SQL / as sysdba
$CREATE SPFILE FROM PFILE='/oradata2/pfile';

3)If the spfile backup does not exist then look at the database alert log file which is located in $ORACLE_HOME/admin/$ORACLE_SID/bdump. In the alert log file the list of non-default parameters listed. So create a pfile from spfile and later create spfile.

4)If you have corrupted spfile then from that, using binary utilities like strings available on unix open that and create pfile. And then create spfile from that. Like,

i)Follow either a or b part.

a)$strings /oracle/app/oracle/product/10.2.0/db_1/dbs/spfiledbase.ora >/export/home/pfile.ora

Now edit the /export/home/pfile.ora if any wrong character and then create spfile from that.
SQL>!vi /export/home/pfile.ora
SQL>create spfile from pfile='/export/home/pfile.ora';
SQL>startup

b)$strings /oracle/app/oracle/product/10.2.0/db_1/dbs/spfiledbase.ora
copy the usable contents inside it Open another file and paste contents into it.

SQL>!vi /export/home/oracle/test.txt

Create spfile from pfile.

SQL> create spfile from pfile='/export/home/oracle/test.txt';
File created.

Then start the database.

Related Documents:

http://arjudba.blogspot.com/2008/04/how-to-know-my-database-start-with.html

http://arjudba.blogspot.com/2008/04/pfile-and-spfile-in-oracle.html
http://arjudba.blogspot.com/2008/04/how-to-start-your-database-with-no.html

ORA-01034: ,ORA-27101: shared memory realm does not exist

Error Description:
-----------------------
Whenever you try to connect to database it returns message,

ORA-01034 : ORACLE not available
ORA-27101 : shared memory realm does not exist

Cause of the Problem:
--------------------------
This problem happens whenever ORACLE_SID or ORACLE_HOME is not properly set. Or for normal users whenever oracle database is not started. For remote users there may be a problem in listener.

Solution of the Problem:
----------------------------
A)For Local Connections:
----------------------------
1)Verify the ORACLE_SID and ORACLE_HOME is set properly. You can check the variable in UNIX by,

SQL> !echo $ORACLE_SID
data1

SQL> !echo $ORACLE_HOME
/oracle/app/oracle/product/10.2.0/db_1

If it is set incorrectly then set on UNIX by

$ export ORACLE_SID=db_name_here (on ksh,sh)
$ setenv ORACLE_SID=db_name_here (on csh)

Remember that ORACLE_SID is case sensitive on UNIX.

2)Verify the database instance is running.

On UNIX you can verify by,
SQL>!ps -ef |grep smon

It will return a row as ora_smon_your_database_name

If it does not return such row then your database is not started. So, start it after setting proper sid.

$sqlplus / as sysdba
$startup

On windows system press CTRL+ALT+DEL and see the process and look for oracle.exe. If it is not present there then from right click my computer>select manage>services>and select oracle database service and start it.
B)For Remote Connections:
-------------------------------
1)Verify the ORACLE_HOME is set correctly for all listed Oracle databases. If the ORACLE_HOME points to the different oracle version software, but the database was created using a different version, then this error can occur.

2)Review the listener.ora file and it is properly set. Like if you set ORACLE_HOME path inside listener ended by slash(/) then the error will come.

Incorrect:
(ORACLE_HOME = /oracle/app/oracle/product/10.2.0/)
Correct:
(ORACLE_HOME = /u01/app/oracle/product/10.2.0)

3)If listener.ora use SID then verify that you have set properly ORACLE_SID. Also be sure about listener services by issuing lsnrctl services.

4)Verify the database is running on server machine while you connect as normal user.

Other links
http://arjudba.blogspot.com/2008/07/database-startup-fails-with-error-ora.html
http://arjudba.blogspot.com/2008/05/startup-fails-with-oracle-error-ora.html
http://arjudba.blogspot.com/2008/05/database-startup-fails-with-errors-ora.html