Любой x32 процесс теоретически может адресовать 4Г оперативки. Но, по умолчанию, Вынь дает процессу половину - 2Г. Шаманство с ключом /3G при загрузке позволит процессу адресовать эти 3Г, но жуткими раками.
Но это все неинтересно, главное то, что теоретический предел оперативки для ораклового процесса (даже недостижимые 4Г) для ЦФТ-шных баз ой как мало! Например, у нас сейчас на RBO один буферный Кеш составляет 4 гигабайта, правда используется по статистике не более чем на 80%.
Любой x32 процесс теоретически может адресовать 4Г оперативки. Но, по умолчанию, Вынь дает процессу половину - 2Г. Шаманство с ключом /3G при загрузке позволит процессу адресовать эти 3Г, но жуткими раками.
Но это все неинтересно, главное то, что теоретический предел оперативки для ораклового процесса (даже недостижимые 4Г) для ЦФТ-шных баз ой как мало! Например, у нас сейчас на RBO один буферный Кеш составляет 4 гигабайта, правда используется по статистике не более чем на 80%.
Так что, либо Winx64, либо платформу посерьезнее!
Задам вопрос по другому.... Как можно винде сказать, чтобы она ограничила себя скажем только 2-мя гигами памяти ? а остальное отдала под процессы оракла..
я честного говоря незнаю... _________________ всегда есть как минимум 2 выхода
Скажем, ничего кроме оракла больше не запускать после старта операционки.
Однако был у меня веселый случай на внедрении. Тогда еще ORACLE вращался на Win2003, и я, мастерски изголившись, "попал" с распределением ОЗУ в 2G для процесса oracle.exe... База "завелась" и работала. Однако запрос
Код:
select * from objects (IBS)
вываливался с ошибкой, типа "выход за пределы адресного пространства".
Скажем, ничего кроме оракла больше не запускать после старта операционки.
Однако был у меня веселый случай на внедрении. Тогда еще ORACLE вращался на Win2003, и я, мастерски изголившись, "попал" с распределением ОЗУ в 2G для процесса oracle.exe... База "завелась" и работала. Однако запрос
Код:
select * from objects (IBS)
вываливался с ошибкой, типа "выход за пределы адресного пространства".
будете смеятся он описанная ситуация 1 в 1 с нашей....
у нас кроме Оракла на сервере ничего не запущено... _________________ всегда есть как минимум 2 выхода
Не буду смеяться.
Вам осталось докупить смокинг для Вашего лимузина... _________________ IT-Команда предлагает свои услуги:
http://www.cftclub.ru/viewtopic.php?t=909
Любой x32 процесс теоретически может адресовать 4Г оперативки. Но, по умолчанию, Вынь дает процессу половину - 2Г. Шаманство с ключом /3G при загрузке позволит процессу адресовать эти 3Г, но жуткими раками.
Но это все неинтересно, главное то, что теоретический предел оперативки для ораклового процесса (даже недостижимые 4Г) для ЦФТ-шных баз ой как мало! Например, у нас сейчас на RBO один буферный Кеш составляет 4 гигабайта, правда используется по статистике не более чем на 80%.
Ну собственно - для widows это кривость платформенная - так как к сожалению в нем оракл в виде целевого процесса - а все оракловые процессы как его нити, а вот в *nix все "правильно" - каждая сессия свой процесс, ну и соответсвенно ограничения для процесса 32 битного - 2 ^32 = 4Гбайта - а на деле 2 системе 2 процессу, вот кэш буферов можно сделать по-более через AWE(до 3 гигов отстегнуть на процесс оракл и гиг оставить на систему) - да и то только для кэша буферов, еще есть возможность отображения большого объема памяти через PAE, расширеная адресация памяти, - но тут скорость уже не не то лишние операции добавляются по преобразованию 32 разрядной в 36 разрядную адресацию и говорят не очень рекомендует мелкософт включать её. В отношении винды - imho , не очень удобно работать с ИБСО - с точки зрения администрирования.
Как вариант выхода из такой ситуации предложу "могучее" и "быстрое" дисковое хранилище.
И тогда, хай Оракл вертится в 2Гб, - дисковая подсистема вытащит! _________________ IT-Команда предлагает свои услуги:
http://www.cftclub.ru/viewtopic.php?t=909
Нет ни одного хранилища которое сравнится по скорости со статической(статическая ISM - в данном контексте не выгружаемая в область подкачки - как DISM) разделяемой памятью, при равных объемах логическое чтение шустрее физического(хотя есть ряд исключений - например когда чтобы получить консистентную версию блока данных нам нужно считывать и "намазывать" вектор изменения из undo например) - хотя есть ряд решений с гигантским кэшем и хорошей батарейкой для него, но не зря Оracle любит память ибо пока что, увы нет ничего более шустрого. В общем и целом - большие и сверхбольшие базы данных удел 64 битных *nix-ов.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете голосовать в опросах
Домен cftclub.ru не связан с ЗАО "Центр Финансовых Технологий" и ни в коей мере не нарушает авторских и иных прав
Владелец может не разделять мнения Участников и не несет ответственности за их публикации
Powered by phpBB