Sunday, January 15, 2012

ORA-00845: MEMORY_TARGET not supported on this system

I have seen this error under two different circumstances and thought it would be helpful to note it down how I got it solved.

Case 1:
I already had the database installed. Oracle 11.2.0.2.0, RHEL 5, single instance. Then I installed Grid Infrastructure and created several ASM disk groups. Everything was just fine until server got rebooted. When the server was up, ASM instance was automatically up and running. When I tried to start the database instance, I got the following.

ORA-00845: MEMORY_TARGET not supported on this system

Solution to this particular problem is painfully explained in the web. But for non-ASM instance scenarios!
The reason here is that, now we have database instance plus an ASM instance, means oracle needs more memory!

I already had a shared file system, but to increase it's size, I did unmount it and mounted again with a larger size.



# umount tmpfs
# mount -t tmpfs shmfs -o size=<size>m /dev/shm
Then I tried to startup the database, but eventually found out that ASM instance had been crashed mysteriously ( I guess umount might have released the memory which was allocated to ASM, hence crashed )

So, then I tried to startup the ASM instance, but effort was in vain, until I execute this command,

crsctl start resources -all

Then everything seems to be fine and I could start the database instance.


Case 2:
My oracle database was in ASMM (Automatic Shared Memory Management) mode and I wanted to enable AMM (Automatic Memory Management).


alter system set memory_max_target=1G scope=spfile;
shutdown immediate;
startup;
Then I got our beloved error again.  (Yes, this system is not so generous to give 1G to oracle, It was a VMware 1G guest in 2G windows host)


Unfortunately I realised that I hadn't created a spfile so that there is no way that I can revert it back just in case. But fortunately I had enabled autobackup and had taken several database backups. So spfile is luckily available in FRA.


So I deleted renamed current spfile and logged in to RMAN to start the database with default parameters. 

rman target /
startup;
Chaos! system did not mount as control files locations are not known. But it's ok for the moment. Then I tried to restore the spfile

RMAN>restore spfile from autobackup;
RMAN-06495: must explicitly specify DBID with SET DBID command
Now how to find dbid? I could have found it by querying v$database if database was mounted. But it was not. chicken egg problem!
Luckily there are other ways too. This can be obtained using existing backups. here is how,

strings file_name |grep MAXVALUE, (In case of SYSTEM datafile)
strings file_name |grep MAXVALUE (In case of UNDO datafile)

So, Then suddenly everything seemed to be easy.


RMAN>set dbid=xxxxxxx
RMAN>restore spfile from autobackup;


SQL>shutdown immediate;
SQL>startup;

No comments:

Post a Comment