instalacja oracle 11gr2 na fed1
nie można było uruchomić bazy danych
skopiowałem orahome/base/admin/orcl/pfile/init.ora.8883224234 do base/db11gr2/dbs/initfed1orcl.ora
przy uruchomianiu dostałem komunikaty:
~~~~~~~~~~~~~~~~~~~~~~~~~
ORA-00845 MEMORY TARGET not supported on this system
ORA-00845: MEMORY_TARGET not supported on this system
Problem Description
While creating a startup database using dbca the database creation GUI gives error message in a pop up window,
ORA-00845: MEMORY_TARGET not supported on this system
from where you can ignore the error message.
The similar scenario also occur whenever you try to start your database then startup shows error message like below.
SQL> STARTUP
ORA-00845: MEMORY_TARGET not supported on this system
Cause of the Problem
•Starting from Oracle 11g the automatic memory management feature is now defined with parameter MEMORY_TARGET and MEMMORY_MAX_TARGET.
•On linux file system the shared memory need to be mounted on /dev/shm directory on the operating system.
•And the size of /dev/shm needs to be greater than MEMORY_TARGET or MEMMORY_MAX_TARGET.
•The AMM (Automatic Memory Management) now in 11g manages both SGA and PGA together by MMAN process.
•The MEMORY_TARGET parameter in 11g comes for (SGA_TARGET+PGA_AGGREGATE_TARGET) which was in 10g.
•And MEMORY_MAX_TARGET parameter in 11g comes instead of SGA_MAX_TARGET parameter which was in 10g.
•The ORA-00845:can arises for the following two reasons on linux system.
1)If the shared memory which is mapped to /dev/shm directory is less than the size of MEMORY_TARGET or MEMORY_MAX_TARGET.
or,
2)If the shared memory is not mapped to /dev/shm directory.
Solution of the Problem
Make sure /dev/shm is properly mounted. You can see it by,
#df -h or #df -k command.
The output should be similar like
$ df -k
Filesystem Size Used Avail Use% Mounted on
…
shmfs 1G 512M 512M 50% /dev/shm
We see here for /dev/shm we have assigned 1G memory. Now if you set MEMORY_TARGET more than 1G then above ORA-845 will arise. For example if you have MEMORY_TARGET or MEMORY_MAX_TARGET set to 12G then you can mount shared memory to 13g like below.
As a root user,
# mount -t tmpfs shmfs -o size=13g /dev/shm
In order to make the settings persistence so that it will affect after restarting machine add an entry in /etc/fstab similar to the following:
shmfs /dev/shm tmpfs size=13g 0
~~~~~~~~~~~~~~~~~~~~~~
wykonałem:
# mount -t tmpfs shmfs -o size=13g /dev/shm
~~~~~~~~~~~~~~~~~~~~~~~~~~~
przy kolejnym sql>startup otrzymałem błąd:
ORA-01102:cannot mount database in EXCLUSIVE mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The Oracle docs note this on the ora-01102 error:
ORA-01102 cannot mount database in EXCLUSIVE mode
Cause: Some other instance has the database mounted exclusive or shared.
Action: Shut down the other instance or mount in a compatible mode.
ORA-01102 occurs when you are mounting (opening) a database, typically because another instance is already opened in parallel (exclusive) mode.
To resolve ORA-01102, you should try opening the base, which causing the error, in parallel mode after shutting down other instances. If these steps leave ORA-01102 unresolved, you may need to try restarting OracleService<SID>
Oracle DBA Forums contains a good explanation of how ORA-01102 may also be thrown under false pretenses:
Question:
Chris Pena asked what the following error regards
SQL> startup force pfile=’/apps/oracle/product/10.2.0/db_1/dbs/inittest01.ora’
ORACLE instance started.
Answer (by Burleson):
The docs note:
ORA-01102: cannot mount database in exclusive mode
Cause: An instance tried to mount the database in exclusive mode, but some other instance has already mounted the database in exclusive or parallel mode.
Action: Either mount the database in parallel mode or shut down all other instances before mounting the database in exclusive mode.
The ORA-01102 is a “false” error in this regard (assuming that you are not using data guard), and this note may be helpful:
********************************
http://www.orafaq.com/forum/t/40030/0/
database is started in EXCLUSIVE mode by default. Therefore, the
ORA-01102 error is misleading and may have occurred due to one of the
following reasons:
- there is still an “sgadef<sid>.dbf” file in the “ORACLE_HOME/dbs”
directory
- the processes for Oracle (pmon, smon, lgwr and dbwr) still exist
- shared memory segments and semaphores still exist even though the
database has been shutdown
- there is a “ORACLE_HOME/dbs/lk<sid>” file
The “lk<sid>” and “sgadef<sid>.dbf” files are used for locking shared memory.
It seems 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. Now the database can start.
POSSIBLE SOLUTION:
Verify that the database was shutdown cleanly by doing the following:
1. Verify that there is not a “sgadef<sid>.dbf” file in the directory
“ORACLE_HOME/dbs”.
% ls $ORACLE_HOME/dbs/sgadef<sid>.dbf
If this file does exist, remove it.
% rm $ORACLE_HOME/dbs/sgadef<sid>.dbf
2. 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
command “kill”. For example:
% kill -9 <Process_ID_Number>
3. Verify that no shared memory segments and semaphores that are owned
by “oracle” still exist
% ipcs -b
If there are shared memory segments and semaphores owned by “oracle”,
remove the shared memory segments
% ipcrm -m <Shared_Memory_ID_Number>
and remove the semaphores
% ipcrm -s <Semaphore_ID_Number>
NOTE: The example shown above assumes that you only have one
database on this machine. If you have more than one
database, you will need to shutdown all other databases
before proceeding with Step 4.
4. Verify that the “$ORACLE_HOME/dbs/lk<sid>” file does not exist
5. Startup the instance
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
faktycznie w katalogu base/db11gr2/dbs
był plik lkORCL, który usunąłem po wcześniejszym zamknięciu bazy danych
przy kolejnym
sql> startup
dostałem błąd:
ORA-00205: Error in identifying control file, check alert log for more info
ale baza się otworzyła tylko nie zamontowała.
sprawdzam gdzie jest alert log:
sql> show parameter dump_dest
i szukam user_dump_dest
w logu jest komunikat:
ORA-00210: cannot open the specified control file
ORA-00202: control file:
‘/home/oracle/orahome/base/flash_recovery_area/orcl/control02.ctl’
ORA-27086: unable to lock file – already in use
zrobiłem kopię obu control files i skasowałem oryginały a potem znowu skopiowałem kopie pod oryginalne nazwy.
to rozwiązało problem i baza się uruchamia ale teraz wszystkie pliki dbf są zablokowane.
trzeba było wykasować plik base/db11gr2/dbs/lkORCL i przeładować system i wykonać komendę zaraz po uruchomieniu:
# mount -t tmpfs shmfs -o size=4g /dev/shm
instaluje oracle na winxp3
global databse name xp3orcl.winxp3
sid: xp3orcl
netca – oracle network configuration assistant
dbca – oracle database configuration assistant