LINUX.ORG.RU

Oracle inside


0

0

Очень такая скромно требовательная к ресурсам СУБД. Обратите внимание на эффективное распределение памяти. :) Да, это не MySQL конечно, но MySQL'у зато есть куда расти. Опен-сурс форева ;)



Проверено: Demetrio ()
Ответ на: комментарий от just

> 400 метров в SGA? Рекомендую почитать документацию по файловым
> системам ramfs и tmpfs. Потом попробуй используя их сделать SGA
> больше.

Первое: сэр, вы с дуба рухнули, по ходу дела. Oracle использует
SYSV shared memory, которая никаким образом не завязана на tmpfs.
RTFM, "крутой" вы наш :-)

Второе: Linux позволяет делать shm-сегменты любого размера в
пределах размера виртуальной памяти.

И третье - вам надо срочно лечиться от самомнения:

[root@viking pfile]# /etc/autoload/oracle start
/dev/raw/raw3:  bound to major 253, minor 1
/dev/raw/raw5:  bound to major 253, minor 4
/dev/raw/raw7:  bound to major 253, minor 6
/dev/raw/raw8:  bound to major 253, minor 7
/dev/raw/raw9:  bound to major 253, minor 8
/dev/raw/raw1:  bound to major 253, minor 0
/dev/raw/raw2:  bound to major 253, minor 2
/dev/raw/raw4:  bound to major 253, minor 3
/dev/raw/raw6:  bound to major 253, minor 5

SQL*Plus: Release 9.2.0.1.0 - Production on Fri Aug 20 22:29:13 2004

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.

SQL> Connected to an idle instance.
SQL> ORACLE instance started.

Total System Global Area  873534320 bytes
Fixed Size                   451440 bytes
Variable Size             536870912 bytes
Database Buffers          335544320 bytes
Redo Buffers                 667648 bytes
Database mounted.
Database opened.
SQL> Disconnected from Oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.1.0 - Production
[root@viking pfile]# uname -r
2.6.8.1
[root@viking pfile]#

А теперь идите, почитайте умных книжек :-)

P.S.: хотите, вышлю вам конфиг от этого инстанса и конфиг
"ванильного" ядра 2.6 под это дело? Недорого, всего $1500 :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

Ну что, 800-метрового SGA достаточно для осознания вами степени нетюнингованности вашего Oracle?

Больше, вы уж извините, подымать лень - у меня на игрушечной системе 512 RAM + 512 swap :-) Но если будет желание посмотреть - подыму еще 700 метров свопа и попробую поднять SGA для начала до 1GB.

Больше этого подымать не стану, и не просите - у меня нет дискспейса под свап, а в выходные идти на работу добавлять памяти (даже ради обламывания такого агрессивного типа как вы) мне лень :-)

no-dashi ★★★★★
()
Ответ на: комментарий от ansi

> A что дo 9.2.0.4 проапдейтить в лом?

Ага, лень-матушка :-) У нас вообще 8i используется, а видимая "девятка" - это моя игрушка, собачка для опытов :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

У нас так-же. 9-ка как-то не пошла у Оракла, у кокого ни спросишь сидят на 8i

ansi ★★★★
()
Ответ на: комментарий от no-dashi

> P.S.: хотите, вышлю вам конфиг от этого инстанса и конфиг > "ванильного" ядра 2.6 под это дело? Недорого, всего $1500 :-)

Больной какой-то ;) На Ванилла ядре я могу SGA до 2,7Gb дотянуть. Это не ванилла ядро. Сходи на работу, добавь памяти до 4 гиг, поставь RHAS 3 и потом маши пальцами во всех направлениях. И насчет твоих 800 мег SGA очень смешно. Вот что у "афтора" оракл говорит. [oracle@oraclebk oracle]$ sqlplus

SQL*Plus: Release 9.2.0.5.0 - Production on Sat Aug 21 10:50:10 2004

Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.

Enter user-name: system Enter password:

Connected to: Oracle9i Enterprise Edition Release 9.2.0.5.0 - Production With the Partitioning, OLAP and Oracle Data Mining options JServer Release 9.2.0.5.0 - Production

SQL> show sga

Total System Global Area 2131826192 bytes Fixed Size 452112 bytes Variable Size 520093696 bytes Database Buffers 1610612736 bytes Redo Buffers 667648 bytes SQL>

just
() автор топика
Ответ на: комментарий от SandySandy

> А что мешает поднять ядро на 2.6 ветку ?

Принципы им мешают - типа "У нас же RHEL, мы теперь ничего не пересобираем"!

Странно все это - народ берет RHEL за поддержку оракловского SGA > 2GB, а у этого он более 400 МБ не умеет :-) Ладно, в понедельник redhat'овское ядро поставлю, проверю. Но что-то мне подсказывает, что все будет корректно работать :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

> Принципы им мешают - типа "У нас же RHEL, мы теперь ничего не >пересобираем"! Да нет дело не в принципах. По некоторым причинам- не можем. Хотя что Оракл неплохо работает на 2,6 и AIO там включается через опенсурсную либу тоже знаем.

>Странно все это - народ берет RHEL за поддержку оракловского SGA > 2GB, >а у этого он более 400 МБ не умеет :-) Ладно, в понедельник >redhat'овское ядро поставлю, проверю. Но что-то мне подсказывает, что >все будет корректно работать :-)

Да давай конечно, я же жду скрина. :) Тут то он умеет, но для 4 гиг больше чем 2,1 никак не выставить, иначе - unable to attach. А нам не нужен мертвый Оракул ;) Фишка ramfs что она не должна сваппиться- все равно оракловый небольшой сваппинг в системе присутсвует. И в топе он вот так показывает распределение памяти, но SGA на самом деле как сам видишь-не 400 мег, но оно меньше чем было бы c ванилла. Только не забудь еще проапгрейдить Оракл до 9.2.0.5, а то у тебя староватый ;) И про raw- в принципе юзается AIO и теоретически на скорости это тоже сказывается наверное ;) Уж больно неудобно с raw что либо доставать ;)

just
() автор топика
Ответ на: комментарий от just

> все равно оракловый небольшой сваппинг в системе присутсвует..

Если у тебя/вас свопит Оракул то его надо настраивать. По тому как свопить ему не положено. А судя по твоему скрину так оно и есть, и SGA тебе надо бы уменьшить. Какой толк от твоих "Database Buffers 1610612736 bytes " если твои Buffers на диске лежат?

Да и SHMMAX я бы покрутил, оно всегда лучше когда Оракул память одним большым куском у оси оттяпывает и не дробит как у тебя

ansi ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.