32bit oracle 擴展SGA原理
2024-08-29 13:39:23
供稿：網友
32bit Oracle由于位數限制，使得oracle進程只能訪問4g(2的32次方)以下的虛擬內存地址，在很多時候這是一個很讓人頭疼的問題，因為空著許多內存而不能使用，而默認情況下SGA不能超過1.7g。比如我們的linux下有8g內存，卻有部分空著不能用干著急。 這個時候我們就要考慮怎樣擴展oracle的SGA。那么首先，如何識別32bit的oracle呢？我們可以通過如下查詢得到 sys@OCN> select * from v$version; BANNER
----------------------------------------------------------------
Oracle9i EnterPRise Edition Release 9.2.0.4.0 - ProdUCtion
PL/SQL Release 9.2.0.4.0 - Production
CORE 9.2.0.3.0 Production
TNS for Linux: Version 9.2.0.4.0 - Production
NLSRTL Version 9.2.0.4.0 - Production 假如是64bit oracle，在查詢結果中一定會顯示 64bit 字樣，沒有出現，則一定是32bit oracle .當然，在os上通過file oracle 也能看到 [oracle@ocn2 bin]$ cd $ORACLE_HOME/bin
[oracle@ocn2 bin]$ file oracle
oracle: setuid setgid ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked (uses shared libs), not stripped
[oracle@ocn2 bin]$ 在某些os上，比如AIX上，64bit oracle 會正常顯示信息，32bit則不正常顯示。 在確認了32bit oracle之后，我們要明白，通常情況下我們的OS進程只能訪問4g以下的空間，redhat linux AS 2.1 或者AS3.0版本例外，他們可以提供VLM(Very large memory)功能支持，使得通過轉換可以使用36bit來標志內存地址，那么就是2的36次方理論上最大可支持64g內存訪問。在oracle中，則是通過將內存當作文件來訪問的，虛擬一個 /dev/shm 的文件系統，這個文件系統是完全由內存組成的，這樣將突破4g的限制。那回過來我們看看，既然進程可以訪問4g以下內存為何通常SGA又是1.7g呢。 在OS中，規定了一個進程在應用程序中，能訪問的虛擬內存空間為0--3g,而3g--4g這段虛擬地址空間是保留給kernel使用的。要注重我們這里強調的是虛擬地址空間，并沒有說物理地址空間，也就是說，假設有8g的內存，這0--3g的虛擬地址空間可能出現在8g內存的3g--8g部分內存段，并不是說是物理內存的0--3g段。而在這0--3g的虛擬地址中，oracle又是如何來使用的呢，這是固定好了地址的。 +++++++++++++++ 4g
+ -------------------------+
+------------------------- +
+------------------------- +
+++++++++++++++ 3g: kernel
+ ------------------------- +
+ ------------------------- +
+------------------------- +
+++++++++++++++ 2g: process stack
+ -------------------------+
+------------------------- +
+++++++++++++++ 1.25g: SGA起點
+++++++++++++++ 1g: oracle 共享庫裝載起點
+ -------------------------+
+ -------------------------+
+ -------------------------+
+++++++++++++++ 0g: oracle program(可執行代碼)裝載起點
在這段虛擬地址的分配中，1.25g是sga的起點，而進程的私有空間的分配(stack部分)卻是從靠近3g處開始的。也就是實際上SGA和進程私有空間是共用了1.25g---3g這部分的，由于進程私有空間非凡小，通常我們習慣性地認為SGA可以達到1.7g。進程私有空間有0.05g足夠了。從oracle一啟動開始，或者從任何一用戶進程登陸開始，所有虛擬地址的分配都已經固定好了，只有用戶私有空間還可以擴展。我們來看一下數據庫啟動后pmon進程(實際上任何一個進程都是一樣的)的虛擬地址分配情況。由于我一臺機器上跑著2個數據庫，所以我們看其中一個，先看看數據庫SGA相關信息 [root@ocnsb1 root]# su - oracle
[oracle@ocnsb1 oracle]$ sqlplus "/ as sysdba" SQL*Plus: Release 9.2.0.4.0 - Production on Mon Jul 26 11:37:23 2004 Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved. Connected to:
Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Real application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production select">sys@OCN>select INSTANCE_NAME from v$instance ; INSTANCE_NAME
----------------
roocn1 show">sys@OCN>show sga Total System Global Area 437327188 bytes
Fixed Size 451924 bytes
Variable Size 301989888 bytes
Database Buffers 134217728 bytes
Redo Buffers 667648 bytes
sys@OCN> exit">sys@OCN>exit
Disconnected from Oracle9i Enterprise Edition Release 9.2.0.4.0 - Production
With the Partitioning, Real Application Clusters, OLAP and Oracle Data Mining options
JServer Release 9.2.0.4.0 - Production
[oracle@ocnsb1 oracle]$ ipcs ------ Shared Memory Segments --------
key shmid owner perms bytes nattch status
0x73a32bdc 131072 oracle 640 457179136 50
0x84cc76ac 163841 oracle 640 1379926016 90 ------ Semaphore Arrays --------
key semid owner perms nsems status
0x8df96364 622592 oracle 640 64
0x53609d64 753665 oracle 640 504 ------ Message Queues --------
key msqid owner perms used-bytes messages [oracle@ocnsb1 oracle]$ 我這里的共享內存段只有一個，并且就是SGA的大小(shmid為131072)。這是因為shnmax設置太大的緣故 [oracle@ocn2 kernel]$ more /proc/sys/kernel/shmmax
3221225472
[oracle@ocn2 kernel]$ 接下來我們看看PMON信息，首先要找到pmon進程號，然后去 /proc/pid/maps 中看該進程的虛擬地址分配信息 [oracle@ocnsb1 oracle]$ ps -efgrep pmon
oracle 13655 1 0 Jul24 ? 00:00:00 ora_pmon_roocn1
oracle 13926 1 0 Jul24 ? 00:00:00 ora_pmon_ocn1
oracle 31435 31092 0 11:51 pts/3 00:00:00 grep pmon
[oracle@ocnsb1 oracle]$
[oracle@ocnsb1 oracle]$ more /proc/13655/maps
08048000-0a4ba000 r-XP 00000000 08:05 681621 /opt/oracle/products/9.2.0/bin/oracle
0a4ba000-0ad54000 rw-p 02471000 08:05 681621 /opt/oracle/products/9.2.0/bin/oracle
0ad54000-0ae07000 rwxp 00000000 00:00 0 這部分是oracle program裝載信息，我們可以看到空間使用了0--0ae07000 ，這部分大小不足256MB 40000000-40016000 r-xp 00000000 08:02 448102 /lib/ld-2.2.4.so 這是oracle 共享庫裝載的起點，0x40000000 正好是1g 40016000-40017000 rw-p 00015000 08:02 448102 /lib/ld-2.2.4.so
40017000-40018000 rw-p 00000000 00:00 0
40018000-40019000 r-xp 00000000 08:05 308464 /opt/oracle/products/9.2.0/lib/libodmd9.so
40019000-4001a000 rw-p 00000000 08:05 308464 /opt/oracle/products/9.2.0/lib/libodmd9.so
4001a000-40026000 r-xp 00000000 08:05 308345 /opt/oracle/products/9.2.0/lib/libskgxp9.so
40026000-4002a000 rw-p 0000b000 08:05 308345 /opt/oracle/products/9.2.0/lib/libskgxp9.so
4002a000-40038000 r-xp 00000000 08:05 308461 /opt/oracle/products/9.2.0/lib/libskgxn9.so
40038000-40039000 rw-p 0000d000 08:05 308461 /opt/oracle/products/9.2.0/lib/libskgxn9.so
40039000-4004d000 rw-p 00000000 00:00 0
4004d000-4032c000 r-xp 00000000 08:05 308455 /opt/oracle/products/9.2.0/lib/libjox9.so
4032c000-4043c000 rw-p 002de000 08:05 308455 /opt/oracle/products/9.2.0/lib/libjox9.so
4043c000-4043e000 rw-p 00000000 00:00 0
4043e000-40441000 r-xp 00000000 08:02 448115 /lib/libdl-2.2.4.so
40441000-40442000 rw-p 00002000 08:02 448115 /lib/libdl-2.2.4.so
40442000-40443000 rw-p 00000000 00:00 0
40443000-40465000 r-xp 00000000 08:02 448117 /lib/libm-2.2.4.so
40465000-40466000 rw-p 00021000 08:02 448117 /lib/libm-2.2.4.so
40466000-40475000 r-xp 00000000 08:02 448147 /lib/libpthread-0.9.so
40475000-4047d000 rw-p 0000e000 08:02 448147 /lib/libpthread-0.9.so
4047d000-40490000 r-xp 00000000 08:02 448120 /lib/libnsl-2.2.4.so
40490000-40491000 rw-p 00012000 08:02 448120 /lib/libnsl-2.2.4.so
40491000-40493000 rw-p 00000000 00:00 0
40493000-40494000 r-xp 00000000 08:02 352330 /usr/lib/libaio.so.1
40494000-40495000 rw-p 00000000 08:02 352330 /usr/lib/libaio.so.1
40495000-405ca000 r-xp 00000000 08:02 448111 /lib/libc-2.2.4.so
405ca000-405cf000 rw-p 00134000 08:02 448111 /lib/libc-2.2.4.so
405cf000-405d3000 rw-p 00000000 00:00 0
405d3000-405d4000 r-xp 00000000 08:02 146106 /lib/libredhat-kernel.so.1.0.1
405d4000-405d5000 rw-p 00000000 08:02 146106 /lib/libredhat-kernel.so.1.0.1
405d5000-405f9000 rw-p 00000000 00:00 0
405fa000-40604000 r-xp 00000000 08:02 448136 /lib/libnss_files-2.2.4.so
40604000-40605000 rw-p 00009000 08:02 448136 /lib/libnss_files-2.2.4.so
40605000-40685000 rw-p 00000000 08:02 69445 /dev/zero
40685000-406c6000 rw-p 00000000 00:00 0
共享庫消耗了不到20MB的空間 50000000-6b000000 rw-s 00000000 00:04 131072 /SYSV73a32bdc (deleted) 這是SGA的起點，0x50000000 表示1.25g 6b000000-6b001000 r--s 1b000000 00:04 131072 /SYSV73a32bdc (deleted)
6b001000-6b0a2000 rw-s 1b001000 00:04 131072 /SYSV73a32bdc (deleted)
6b0a2000-6b0a3000 r--s 1b0a2000 00:04 131072 /SYSV73a32bdc (deleted)
6b0a3000-6b400000 rw-s 1b0a3000 00:04 131072 /SYSV73a32bdc (deleted) sga虛擬空間分配到這里，通過計算16進制數，正好和我們的SGA大小吻合,131072就是我們在ipcs查看的時候的 shmid bffe5000-bffee000 rwxp ffff8000 00:00 0
bfff0000-bfff1000 r-xs 00000000 08:02 69304 /dev/vsys 由于0xc0000000正好是3g(16進制數c=12,4*3=12,0x40000000表示1g),則這里表示進程私有空間的分配的起點。查看oracle任何一個用戶登陸進程也將發現這樣的虛擬地址分配。在這里我們很輕易看出來，oracle program 和共享內存庫所占用的空間很小，沒有必要給那么大，實際上，oracle program 給256M足夠安全，而共享庫給50M也足夠安全了，也就是從理論上來講，我們可以把oracle program所需要壓縮在0x10000000以下，共享庫所需要內存壓縮在0x12000000以下，這樣SGA的起點就可以提升到0x12000000(0.3g)。而原來是從0x5000000(1.25g)開始的，只有大約1.7g分配給SGA,現在從0.3g開始分配SGA則可以接近2.7g，比如分配2.65g內存給SGA。要實現這個功能，我們需要重新編譯oracle program，降低共享庫虛擬內存分配的地址和SGA的分配起點位置。0x4000000這個共享庫裝載的起點，是由進程的mapped_base來決定的 [oracle@ocnsb1 oracle]$ more /proc/13655/mapped_base
1073741824 這個大小是1G，則意味著共享庫的裝載從虛擬地址的1g位置開始，假如要降低這個地址，需要在oracle啟動之前，也就是用root用戶把將啟動oracle的進程的mapped_base降低到256M，這樣oracle啟動之后的產生的進程都將繼續這個值。 su - root echo 268435456 > /proc//mapped_base 當然我們也可以通過一些shell來實現oracle用戶登陸之后自動降低mapped_base的功能，這個在Google上就能找到了，或者參考 http://www.puschitz.com/TuningLinux...aceForLargerSGA 中文章內容如下 Giving Oracle Users the Privilege to Change the Base Address for Oracle's Shared Libraries Without Giving them root access As shown above, only root can change the base address "mapped base" for shared libraries. Using sudo we can give Oracle users the privilege to change "mapped base" for their own shells without giving them full root access. Here is the procedure: su - root # E.g. create a script called "/usr/local/bin/ChangeMappedBase" # which changes the "mapped base" for the parent process, # the shell used by the Oracle user where the "sudo" program # is executed (forked). Here is an example: #/bin/sh
# Lowering "mapped base" to 0x10000000 echo 268435456 > /proc/$PPID/mapped_base # Make sure that owernship and permissions are correct chown root.root /usr/local/bin/ChangeMappedBase chmod 755 /usr/local/bin/ChangeMappedBase # Allow the Oracle user to execute /usr/local/bin/ChangeMappedBase via sudo echo "oracle ALL=/usr/local/bin/ChangeMappedBase" >> /etc/sudoers
Now the Oracle user can run /usr/local/bin/ChangeMappedBase to change "mapped base" for it's own shell: $ su - oracle $ cat /proc/$$/mapped_base; echo 1073741824 $ sudo /usr/local/bin/ChangeMappedBase PassWord: # type in the password for the Oracle user account $ cat /proc/$$/mapped_base; echo 268435456 $
When /usr/local/bin/ChangeMappedBase is executed the first time after an Oracle login, sudo will ask for a password. The password that needs to be entered is the password of the Oracle user account. Changing the Base Address for Oracle's Shared Libraries Automatically During an Oracle Login The procedure in the previous section asks for a password each time /usr/local/bin/ChangeMappedBase is executed the first time after an Oracle login. To have "mapped base" changed automatically during an Oracle login without a password, the following can be done: Edit the /etc/sudoers file with visudo: su - root visudo
Change the entry in /etc/sudoers from: oracle ALL=/usr/local/bin/ChangeMappedBase
to read: oracle ALL=NOPASSWD: /usr/local/bin/ChangeMappedBase
Make sure bash executes /usr/local/bin/ChangeMappedBase during the login process. You can use e.g. ~oracle/.bash_profile: su - oracle echo "sudo /usr/local/bin/ChangeMappedBase" >> ~/.bash_profile
The next time you login to Oracle, the base address for shared libraries will bet set automatically. $ ssh oracle@localhost oracle@localhost's password: Last login: Sun Apr 6 13:59:22 2003 from localhost $ cat /proc/$$/mapped_base; echo 268435456 $ SGA起點從1.25g降低到0.3g則需要重新編譯oracle program。必須要強調的是，SGA的起點是和共享庫的起點mapped_ase相關的，SGA的起點至少得大于共享庫的起點0.05g以上才是安全的，否則數據庫將不能啟動或者崩潰。 關閉oracle
su - oracle
cd $ORACLE_HOME/rdbms/lib 修改共享庫裝載地址的文件定義 genksms -s 0x12000000 > ksms.s
編譯好目標文件 make -f ins_rdbms.mk ksms.o 重新編譯oracle可執行文件
make -f ins_rdbms.mk ioracle 至于 redhat linux AS 2.1以上版本 oracle的VLM的使用則也是比較簡單的了,參考
http://www1.ap.dell.com/content/top...c=cn&l=zh&s=bsd
http://otn.oracle.com/global/cn/pub...note_rhel3.Html 當然，internet上還有更多文章可以供參考。 在這里我要指出一個問題，也是我們在實踐中碰到的一個問題，那就是，若SGA分配的很大，但沒有使用VLM，幾乎很靠近3g的時候，大約只留下20m左右。這樣當一個進程進行hash join，由于我們的pga_aggregate_target設置為1g，oracle默認單個進程使用PGA可以達到pga_aggregate_target * 5% = 50M，則使得在進行hash join的時候出錯 ORA-04030: out of process memory when trying to allocate 254476 bytes (hash-join subh,kllcqas:kllsltba) 我們調整pga_aggregate_target減小到400M則該查詢執行成功。因為沒有使用VLM的情況下單個進程的內存分配空間必須在3g以下，而PGA的分配也屬于這個范疇。假如使用VLM則PGA已經被分配到4g以上部分的虛擬地址，不再有這個問題。在此不再對VLM進行過多的闡述，因為使用也比較簡單，從原理上來講就是通過os擴展32bit 到36bit,oracle使用文件來治理內存，并支持進程訪問4g以上部分的虛擬內存。linux上這種用法得到推廣的根本原因是因為其64bit oracle很少被使用，其他如sunOS/hp unix/AIX 等都廣泛使用64bit oracle了，這些方法也就失去價值了。
