RE: sga attach linux hugemem /proc/#/maps

I cannot explain your findings, but I have played with this many times and found it to be dangerous and unreliable. Its better to use 64 bit Red Hat 4 and Oracle 64 bit, and if needed turn on hugepages.

-----Original Message-----

From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Michael McMullen Sent: Thursday, September 25, 2008 11:12 AM To: 'Oracle-L'
Subject: sga attach linux hugemem /proc/#/maps

cat /etc/redhat-release
Red Hat Enterprise Linux ES release 4 (Nahant Update 4)

Uname -a
Linux xxxxxxx01 2.6.9-67.0.7.ELhugemem #1 SMP Wed Feb 27 04:59:22 EST 2008
i686 athlon i386 GNU/Linux

SQL*Plus: Release 10.2.0.3.0 - Production on Thu Sep 25 10:59:54 2008

Due to a corporate reorg I'm helping out a group that used to have 3 dba's
and is now down to one. No documentation/build books to check out. The developers have asked me to look at a problem. I've thinked they've side tracked me because I don't have access to their metalink CSI# yet and haven't been able to check out their tar. They've asked me to verify the SGA
is attached properly because they set up hugemem.

I've been following note #211424.1 and it looks like it's o.k.

That note led me to note #270382.1
This article will assist you on verify the current SGA attach address

b. If an instance is running, check it's attach address:

      i. Get the pid of its PMON process. For example:

         $ ps -ef | grep ora_pmon_EMR920W3
         emrdbms  20355     1  0 01:28 ?        00:00:00

     ii. Now check the map address of the SysV shared memory segment using

         the pid of the PMON process found above:

         $ grep deleted /proc/20355/maps
      	 50000000-50400000 rw-s 00000000 00:04 156663874  /SYSV00000000
(deleted)
      	 (...)

         Again, the first number (50000000) shows the hex address where 
         the SGA will be attached.

I get multiple entries. I've checked other databases on other servers running both the same redhat version and I only get one entry. This database
does have multiple _pool_size parameter set and I just now noticed that they
must have alter system privs and are changing things on the fly. This has
now officially moved to not my responsibility but anyways can anyone explain
why there are multiple entries in /proc/#/maps. The server was rebooted yesterday.

grep delete /proc/6371/maps

12000000-1f200000 rw-s 00000000 00:06 622597     /SYSV8695b0a8 (deleted)
20000000-21000000 rw-s 00000000 00:06 65536      /SYSV00000000 (deleted)
21000000-8e000000 rw-s 00000000 00:06 196609     /SYSV00000000 (deleted)
8e000000-c5000000 rw-s 00000000 00:06 327682     /SYSV00000000 (deleted)
c5000000-e0000000 rw-s 00000000 00:06 458755     /SYSV00000000 (deleted)
e0000000-ee000000 rw-s 00000000 00:06 589828     /SYSV00000000 (deleted)

--

http://www.freelists.org/webpage/oracle-l

--

http://www.freelists.org/webpage/oracle-l Received on Thu Sep 25 2008 - 21:37:15 CDT