[ Pobierz całość w formacie PDF ]
system always points to the current running process which in this example is the cat process:
# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 3 (Taroon Update 6)
# cat /proc/self/maps
00a23000-00a38000 r-xp 00000000 08:09 14930 /lib/ld-2.3.2.so
00a38000-00a39000 rw-p 00015000 08:09 14930 /lib/ld-2.3.2.so
00b33000-00c66000 r-xp 00000000 08:09 69576 /lib/tls/libc-2.3.2.so
00c66000-00c69000 rw-p 00132000 08:09 69576 /lib/tls/libc-2.3.2.so
00c69000-00c6c000 rw-p 00000000 00:00 0
00ee5000-00ee6000 r-xp 00000000 08:09 32532 /etc/libcwait.so
00ee6000-00ee7000 rw-p 00000000 08:09 32532 /etc/libcwait.so
08048000-0804c000 r-xp 00000000 08:09 49318 /bin/cat
0804c000-0804d000 rw-p 00003000 08:09 49318 /bin/cat
099db000-099fc000 rw-p 00000000 00:00 0
b73e7000-b75e7000 r--p 00000000 08:02 313698 /usr/lib/locale/locale-archive
b75e7000-b75e8000 rw-p 00000000 00:00 0
bfff8000-c0000000 rw-p ffffc000 00:00 0
#
# cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 2)
# cat /proc/self/maps
00b68000-00b7d000 r-xp 00000000 03:45 1873128 /lib/ld-2.3.4.so
00b7d000-00b7e000 r--p 00015000 03:45 1873128 /lib/ld-2.3.4.so
00b7e000-00b7f000 rw-p 00016000 03:45 1873128 /lib/ld-2.3.4.so
00b81000-00ca5000 r-xp 00000000 03:45 1938273 /lib/tls/libc-2.3.4.so
00ca5000-00ca6000 r--p 00124000 03:45 1938273 /lib/tls/libc-2.3.4.so
00ca6000-00ca9000 rw-p 00125000 03:45 1938273 /lib/tls/libc-2.3.4.so
00ca9000-00cab000 rw-p 00ca9000 00:00 0
55
Chapter 16. Growing the Oracle SGA to 2.7/3.42 GB in x86 Red Hat Enterprise Linux 3, 4 and 5 Without VLM
08048000-0804c000 r-xp 00000000 03:45 1531117 /bin/cat
0804c000-0804d000 rw-p 00003000 03:45 1531117 /bin/cat
08fa0000-08fc1000 rw-p 08fa0000 00:00 0
b7df9000-b7ff9000 r--p 00000000 03:45 68493 /usr/lib/locale/locale-archive
b7ff9000-b7ffa000 rw-p b7ff9000 00:00 0
bffa6000-c0000000 rw-p bffa6000 00:00 0
ffffe000-fffff000 ---p 00000000 00:00 0
#
The outputs show that the mapped base is already very low in Red Hat Enterprise Linux 3, 4 or 5. In
the above example shared libraries start at 0xa38000 (decimal 10715136) in Red Hat Enterprise Linux
3 and 0xb68000 (decimal 11960320) in Red Hat Enterprise Linux 4 and 5. This is much lower than
0x40000000 (decimal 1073741824) in Red Hat Enterprise Linux 2.1:
# cat /etc/redhat-release
Red Hat Linux Advanced Server release 2.1AS (Pensacola)
# cat /proc/self/maps
08048000-0804c000 r-xp 00000000 08:08 44885 /bin/cat
0804c000-0804d000 rw-p 00003000 08:08 44885 /bin/cat
0804d000-0804f000 rwxp 00000000 00:00 0
40000000-40016000 r-xp 00000000 08:08 44751 /lib/ld-2.2.4.so
40016000-40017000 rw-p 00015000 08:08 44751 /lib/ld-2.2.4.so
40017000-40018000 rw-p 00000000 00:00 0
40022000-40155000 r-xp 00000000 08:08 47419 /lib/i686/libc-2.2.4.so
40155000-4015a000 rw-p 00132000 08:08 47419 /lib/i686/libc-2.2.4.so
4015a000-4015f000 rw-p 00000000 00:00 0
bffea000-bffee000 rwxp ffffd000 00:00 0
#
The above mappings show that the Mapped Base Address does not have to be lowered in Red Hat
Enterprise Linux 3 or 4 to gain more SGA space.
16.3. Oracle 10g SGA Sizes in Red Hat Enterprise Linux 3, 4
or 5
The following table shows how large the Oracle 10g SGA can be configured in Red Hat Enterprise
Linux 3, 4 or 5 without using a shared memory file system. Shared memory file systems for the SGA
are covered at Section 14.8, Huge Pages and Shared Memory File System in Red Hat Enterprise
Linux 3 Configuring Very Large Memory (VLM).
Red Hat 10g Database Default Max Supported Comments
Enterprise Version Supported SGA SGA without
Kernel Type without VLM VLM
smp kernel (x86) 10g Release 1 Up to 1.7 GB Up to 2.7 GB 10g R1 must
be relinked to
increase the SGA
size to approx 2.7
GB
hugemem kernel 10g Release 1 Up to 2.7 GB Up to 3.42 GB 10g R1 must
(x86) be relinked to
increase the SGA
size to approx
3.42 GB
56
Lowering the SGA Attach Address in Oracle 10g
Red Hat 10g Database Default Max Supported Comments
Enterprise Version Supported SGA SGA without
Kernel Type without VLM VLM
smp kernel (x86) 10g Release 2 Up to ~2.2 GB (*) Up to ~2.2 GB (*) No relink of 10g
R2 is necessary
but the SGA
Attach Address is
a little bit higher
than in R1
hugemem kernel 10g Release 2 Up to ~3.3 GB (*) Up to ~3.3 GB (*) No relink of 10g
(x86) R2 is necessary
but the SGA
Attach Address is
a little bit higher
than in R1
Table 16.1. Table showing how large SGA can be configured in Red Hat Enterprise Linux
(*) When performing test scenarios with 10g R2 the database was not able to start up if sga_target
was larger than 2350000000 bytes on a smp kernel, and if sga_target was larger than 3550000000
bytes on a hugemem kernel.
In Oracle 10g R2 the SGA size can be increased to approximately 2.7 GB using the smp kernel and
to approximately 3.42 GB using the hugemem kernel. The SGA attach address does not have to be
changed for that. To accommodate the same SGA sizes in Oracle 10g R1, the Section 16.4, Lowering
the SGA Attach Address in Oracle 10g must be lowered.
Note
Lowering the SGA attach address in Oracle restricts the remaining 32 bit address space
for Oracle processes. This means that less address space will be available for e.g. PGA
memory. If the application uses a lot of PGA memory, then PGA allocations could fail even
if there is sufficient free physical memory. Therefore, in certain cases it may be prudent
not to change the SGA Attach Address to increase the SGA size but to use Chapter 17,
Using Very Large Memory (VLM) instead. Also, if the SGA size is larger but less than
4GB to fit in memory address space, then the Chapter 17, Using Very Large Memory
(VLM) solution should be considered first before switching to the hugemem kernel on a
small system, unless the system has lots of physical memory. The hugemem kernel is not
recommended on systems with less than 8GB of RAM due to some overhead issues in
the kernel, see also Section 2.2, 32 bit Architecture and the hugemem Kernel . If larger
SGA sizes are needed than listed in the above table, then Chapter 17, Using Very Large
Memory (VLM) must obviously be used on x86 platforms.
16.4. Lowering the SGA Attach Address in Oracle 10g
Starting with Oracle 10g R2 the SGA attach address does not have to be lowered for creating larger
SGAs. However, Oracle 10g R1 must be relinked for larger SGAs.
The following commands were executed on a 10g R1 database system:
# ps -ef | grep "[o]ra_ckpt"
oracle 3035 1 0 23:21 ? 00:00:00 ora_ckpt_orcl
57
Chapter 16. Growing the Oracle SGA to 2.7/3.42 GB in x86 Red Hat Enterprise Linux 3, 4 and 5 Without VLM
# cat /proc/3035/maps | grep SYSV
50000000-aa200000 rw-s 00000000 00:04 262144 /SYSV8b1d1510 (deleted)
#
The following commands were executed on a 10g R2 database system:
# ps -ef | grep "[o]ra_ckpt"
oracle 4998 1 0 22:29 ? 00:00:00 ora_ckpt_orcl
# cat /proc/4998/maps | grep SYSV
20000000-f4200000 rw-s 00000000 00:04 4390912 /SYSV950d1f70 (deleted)
#
The output shows that the SGA attach address in 10g R2 is already lowered to 0x20000000 vs.
0x50000000 in 10g R1. This means that Oracle 10g R2 does not have to be relinked for creating
larger SGAs. For 10g R1 the SGA attach address must be lowered from 0x50000000 to e.g.
0xe000000. You could also set it a little bit higher like 0x20000000 as its done by default in 10g
Release 2.
The following example shows how to lower the SGA attach address to 0xe000000 in 10g R1 (see also
Metalink Note:329378.1):
su - oracle
cd $ORACLE_HOME/rdbms/lib
[[ ! -f ksms.s_orig ]] && cp ksms.s ksms.s_orig
genksms -s 0Xe000000 > ksms.s
make -f ins_rdbms.mk ksms.o
make -f ins_rdbms.mk ioracle
For a detailed description of these commands, see Lowering the SGA Attach Address for Shared
Memory Segments in Oracle 9i.
You can verify the new lowered SGA attach address by running the following command:
$ objdump -t $ORACLE_HOME/bin/oracle |grep sgabeg
0e000000 l *ABS* 00000000 sgabeg
$
Now when 10g R1 is restarted the SGA attach address should be at 0xe000000:
# ps -ef | grep "[o]ra_ckpt"
oracle 4998 1 0 22:29 ? 00:00:00 ora_ckpt_orcl
# cat /proc/4998/maps | grep SYSV
[ Pobierz całość w formacie PDF ]