В Oracle 9i управлението на паметта в PGA се автоматизира с параметъра PGA_AGGREGATE_TARGET. Това беше огромно улеснение, защото практически е невъзможно администратора да дебне коя сесия има нужда от памет и да раздава правосъдие, а задаването на големи области за сортиране „за всеки” води до препълване на паметта. За това се задаваха някакви измислени стойности на sort_area_size тип “one-size-fits-all”, което никога не е оптимално. С параметъра PGA_AGGREGATE_TARGET нещата доста се улесняват, защото СУБД се грижи за това който има нужда от повече памет – да получи повече (докато има).
Oracle 10g представи подобно улеснение и за споделената памет (SGA). С наличието на параметъра SGA_TARGET, параметрите за различните пулове (Shared pool, Java pool, Streams pool, Large pool, Swimming pool) и кеша за данни (db_cache_size, db_keep_cache_size, db_recycle_cache_size, db_*k_cache_size) също започват да се преливат помежду си. Това премахва още една голяма част от натоварването на DBA.
Oracle database 11g представя нова, логична стъпка напред в управлението на паметта: параметрите MEMORY_TARGET и MEMORY_MAX_TARGET. Целта е да се зададе на БД „за теб има ХХХХ МВ памет, оправяй се”. И след като алгоритмите за автоматично разпределяне на паметта между различни по вид, размер и нужда области са оптимизирани в продължение на 2 версии, всичко би трябвало да е лесно. Поне на пръв поглед…
Е, лесно е, поне под windows. Управлението на паметта на Oracle под Windows е много лесно, защото всичко е един голям процес и адресното пространство е едно. Но нещата не стоят точно така под Linux/UNIX.
Под Linux всеки процес (независимо дали е background или foreground) се реализира от процес на ниво ОС. Неговото парче памет (неговата част от PGA) си е лично негово, private. Но споделената памет (SGA) е обща. Версиите на Oracle до 10g включително реализират SGA като един (в повечето случаи) голям shared memory segment, който се map-ва към всички други процеси. За съжаление, както отбелязва Tanel Poder, управлението на споделената памет не е толкова гъвкаво и няма начин при нужда да се смалява shared memory сегмента, за да се отпусне повече памет за PGA. За това във версия 11g на Oracle Database, SGA паметта се заема от /dev/shm, което е
the Linux’es POSIX-oriented SHM implementation, where everything, including shared memory segments, is a file.
Тук, обаче, има един практически проблем. Някои database-ориентирани хора (като мен) нямат точна представа за какво служи това устройство /dev/shm и, по-важно, как се променя размера му. Моята тестова инсталация показа 768 MB налични в /dev/shm и всеки опит да променя параметъра MEMORY_MAX_TARGET на по-висока стойност завършваше с удар през пръстите:
ORA-00845: MEMORY_TARGET not supported on this system
Между другото, това съобщение изобщо не обяснява къде е проблема. За щастие в alert log файла има много по-добрo описание на драмата:
WARNING: You are trying to use the MEMORY_TARGET feature. This feature requires the /dev/shm file system to be mounted for at least XXXXXXX bytes. /dev/shm is either not mounted or is mounted with available space less than this size. Please fix this so that MEMORY_TARGET can work as expected. Current available is XXXXXXX and used is XXXXXXX bytes.
memory_target needs larger /dev/shm
За съжаление никъде не се споменава как да се промени размера на /dev/shm. Няма го дори и в installation guide – нещо, което ме учудва. Свикнал съм installation guide да е достатъчно подробен.
Tanel Poder предлага едно временно решение:
# umount tmpfs
# mount -t tmpfs shmfs -o size=1300m /dev/shm
# df -k /dev/shm
Filesystem 1K-blocks Used Available Use% Mounted on
shmfs 1331200 0 1331200 0% /dev/shm
Недостатък на това решение е, че промяната се изгубва след рестарт на ОС. За да се монтира винаги с този размер, трябва да се промени съответния ред във файла /etc/fstab:
# cat /etc/fstab
…
tmpfs /dev/shm tmpfs size=1200m 0 0
…
Тази промяна трябва да се направи от потребителя root. Предложеното решение е тествано на Oracle Enterprise Linux 5. До колкото ми е известно, нещата стоят така и на другите supported дострибуции.
