can't increase sga_target parameter (merged 4) [message #426754] |
Mon, 19 October 2009 07:20 |
Tlg13team
Messages: 100 Registered: June 2008 Location: MGL
|
Senior Member |
|
|
hi all,
I have a server. this server ram size 15GB. Already installed oracle 10g in that server before I use. That server sga_target parameter value is 1136M. I try increase that vaule. I using belowe commands:
alter system set sga_max_size=4096M scope=spfile;
alter system set sga_target=4096m;
I can't start oracle instance after increase that value. I give below error message: ORA-27102: out of memory.
What is wrong I do? please help me.
|
|
|
Re: can't increase sga_target parameter (merged 2) [message #426761 is a reply to message #426754] |
Mon, 19 October 2009 07:45 |
ThomasG
Messages: 3212 Registered: April 2005 Location: Heilbronn, Germany
|
Senior Member |
|
|
oracle ~ $ oerr ORA 27102
27102, 00000, "out of memory"
// *Cause: Out of memory
// *Action: Consult the trace file for details
So have a look at the trace file for the details of the error.
Depending on the OS version (which you didn't tell us) you might not be able to address 4 gigabytes.
|
|
|
Re: can't increase sga_target parameter (merged 2) [message #426809 is a reply to message #426761] |
Mon, 19 October 2009 19:51 |
Tlg13team
Messages: 100 Registered: June 2008 Location: MGL
|
Senior Member |
|
|
hi Heilbronn,
# uname -a
Linux localhost.localdomain 2.6.18-92.1.10.el5xen #1 SMP Tue Aug 5 08:46:32 EDT 2008 i686 i686 i386 GNU/Linux
#below trace log file:
.......
ALTER SYSTEM SET sga_max_size='4096' SCOPE=SPFILE;
Mon Oct 19 20:20:57 2009
ALTER SYSTEM SET sga_max_size='4096M' SCOPE=SPFILE;
Mon Oct 19 20:21:37 2009
Shutting down instance (abort)
License high water mark = 3
Instance terminated by USER, pid = 26309
Mon Oct 19 20:21:39 2009
Starting ORACLE instance (normal)
Mon Oct 19 20:22:21 2009
Starting ORACLE instance (normal)
Mon Oct 19 20:23:05 2009
Starting ORACLE instance (normal)
Mon Oct 19 20:23:15 2009
Starting ORACLE instance (normal)
Mon Oct 19 20:24:14 2009
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes = 150
__shared_pool_size = 285212672
__large_pool_size = 16777216
__java_pool_size = 16777216
__streams_pool_size = 0
nls_language = AMERICAN
sga_target = 1191182336
control_files = /home/oracle/oradata/MREP/control01.ctl, /home/oracle/oradata/MREP/control02.ctl, /home/oracle/oradata/MREP/control03.ctl
db_block_size = 8192
__db_cache_size = 855638016
compatible = 10.2.0.1.0
db_file_multiblock_read_count= 16
db_recovery_file_dest = /home/oracle/flash_recovery_area
db_recovery_file_dest_size= 8489271296
undo_management = AUTO
undo_tablespace = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain =
dispatchers = (PROTOCOL=TCP) (SERVICE=MREPXDB)
job_queue_processes = 10
background_dump_dest = /home/oracle/admin/MREP/bdump
user_dump_dest = /home/oracle/admin/MREP/udump
core_dump_dest = /home/oracle/admin/MREP/cdump
audit_file_dest = /home/oracle/admin/MREP/adump
db_name = MREP
open_cursors = 300
pga_aggregate_target = 392167424
PMON started with pid=2, OS id=26478
PSP0 started with pid=3, OS id=26480
MMAN started with pid=4, OS id=26482
DBW0 started with pid=5, OS id=26484
LGWR started with pid=6, OS id=26486
CKPT started with pid=7, OS id=26488
SMON started with pid=8, OS id=26490
RECO started with pid=9, OS id=26492
CJQ0 started with pid=10, OS id=26494
MMON started with pid=11, OS id=26496
Mon Oct 19 20:24:15 2009
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=26498
Mon Oct 19 20:24:15 2009
starting up 1 shared server(s) ...
Mon Oct 19 20:24:16 2009
ALTER DATABASE MOUNT
Mon Oct 19 20:24:20 2009
Setting recovery target incarnation to 2
Mon Oct 19 20:24:20 2009
Successful mount of redo thread 1, with mount id 568876272
Mon Oct 19 20:24:20 2009
Database mounted in Exclusive Mode
Completed: ALTER DATABASE MOUNT
Mon Oct 19 20:24:20 2009
ALTER DATABASE OPEN
Mon Oct 19 20:24:20 2009
Beginning crash recovery of 1 threads
parallel recovery started with 7 processes
Mon Oct 19 20:24:20 2009
Started redo scan
Mon Oct 19 20:24:21 2009
Completed redo scan
220 redo blocks read, 79 data blocks need recovery
Mon Oct 19 20:24:21 2009
Started redo application at
Thread 1: logseq 8675, block 1220566
Mon Oct 19 20:24:21 2009
Recovery of Online Redo Log: Thread 1 Group 4 Seq 8675 Reading mem 0
Mem# 0 errs 0: /disk1/oraclets/oraredo/log04a.rdo
Mem# 1 errs 0: /disk1/oraclets/oraredo/log04b.rdo
Mon Oct 19 20:24:21 2009
Completed redo application
Mon Oct 19 20:24:21 2009
Completed crash recovery at
Thread 1: logseq 8675, block 1220786, scn 10393969719
79 data blocks read, 79 data blocks written, 220 redo blocks read
Mon Oct 19 20:24:21 2009
Thread 1 advanced to log sequence 8676
Thread 1 opened at log sequence 8676
Current log# 3 seq# 8676 mem# 0: /home/oracle/oradata/MREP/redo03.log
Successful open of redo thread 1
Mon Oct 19 20:24:21 2009
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Mon Oct 19 20:24:21 2009
SMON: enabling cache recovery
Mon Oct 19 20:24:22 2009
Successfully onlined Undo Tablespace 1.
Mon Oct 19 20:24:22 2009
SMON: enabling tx recovery
Mon Oct 19 20:24:22 2009
Database Characterset is WE8ISO8859P1
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=23, OS id=26520
Mon Oct 19 20:24:27 2009
db_recovery_file_dest_size of 8096 MB is 0.00% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Mon Oct 19 20:24:27 2009
Completed: ALTER DATABASE OPEN
Mon Oct 19 22:24:29 2009
Thread 1 advanced to log sequence 8677
Current log# 1 seq# 8677 mem# 0: /home/oracle/oradata/MREP/redo01.log
[Updated on: Mon, 19 October 2009 19:53] Report message to a moderator
|
|
|
|
Re: can't increase sga_target parameter (merged 4) [message #426816 is a reply to message #426754] |
Mon, 19 October 2009 23:21 |
balakrishnay
Messages: 54 Registered: September 2009 Location: Pune
|
Member |
|
|
Hi Tlg13team,
Is it working or still you have problem .If you still have a problem you need to check SHMMAX if your server is linux and depends on your OS.
First you need allocate half of the memory to oracle then you can utilize that by setting sga_max_size & sga_target these parameters.
Regards
Bala
|
|
|
Re: can't increase sga_target parameter (merged 4) [message #426867 is a reply to message #426816] |
Tue, 20 October 2009 02:40 |
Tlg13team
Messages: 100 Registered: June 2008 Location: MGL
|
Senior Member |
|
|
Hi all,
The oracle instance works fine after I set sga_target=1136M.
BUT, I went increase that value and I have still a problem.
I'm running on CentOS.
About SHMMAX parameters value below:
#cat shmmax
4294967295
#cat shmall
268435456
#cat shmmni
4096
# ulimit -l
32
# ipcs -lm
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 4194303
max total shared memory (kbytes) = 1073741824
min seg size (bytes) = 1
# free
total used free shared buffers cached
Mem: 15730688 15667204 63484 0 182228 14978772
-/+ buffers/cache: 506204 15224484
Swap: 14614512 96 14614416
What should these be set to optimally?
|
|
|
|
Re: can't increase sga_target parameter (merged 4) [message #426875 is a reply to message #426870] |
Tue, 20 October 2009 03:15 |
ThomasG
Messages: 3212 Registered: April 2005 Location: Heilbronn, Germany
|
Senior Member |
|
|
Does the kernel have hugemem support? (doesn't seem so, according to this there should be "hugemem" in the kernel name then.)
From here :
Quote:
To use large memory system, Linux hugemem kernel can be employed. This will allow you to create SGA of up to 3.6 GB. The hugemem kernel allows 4GB/4GB split of the kernel and user space address. A 32-bit computer splits the available 4 GB address space into 3 GB virtual memory space that can be used to run user-defined processes and a 1 GB space for the kernel. However, for a larger SGA, you must use hugemem kernel.
But even with hugemem support, you seem to be limited to 3.6GB on a 32bit system. Without it the limit would be 2GB
|
|
|
Re: can't increase sga_target parameter (merged 2) [message #427288 is a reply to message #426809] |
Wed, 21 October 2009 14:51 |
|
Tlg13team wrote on Tue, 20 October 2009 04:51hi Heilbronn,
# uname -a
Linux localhost.localdomain 2.6.18-92.1.10.el5xen #1 SMP Tue Aug 5 08:46:32 EDT 2008 i686 i686 i386 GNU/Linux
Hi,
Do you use Xen kernel, don't you? What for?
I advice you read this:
www.redhat.com/f/pdf/rhel/Oracle-10-g-recommendations-v1_2.pdf
|
|
|