Доброго времени суток!Контора собирается приобрести пару серверов SUN Fire V245 (http://www.sun.com/servers/entry/v245/specs.xml).
Основной задачей на ближайшее время будет конфигурирование этих машиной под Oracle RAC, с хитрым конфигурированием как самой ОС, так и СУБД - предполагается что вся СУБД целиком будет сидеть в оперативной памяти (ибо необходимо добиться отклика системы в приделах 0.5 сек). Естественно это будет тестовая конфигурация - боевую планируется собирать на более серъёзных игрушках с минимуму 64 Гиг памяти, но начнём с этих.Собственно вопрос - кто использовал сабж под нагрузкой и кто пробовал подобные финты с поднятием ПО (или даже компонентов ОС и свопа) в оперативную память? Есть ли возможность монтировать виртуальные диски в память, копировать туда некие данные (по всей видимость там должны будут находиться некоторые тейблспейсы), а затем настроить периодический сброс этих данных на жёсткий диск?
>предполагается что вся СУБД целиком будет сидеть в оперативной памяти (ибо необходимо
>добиться отклика системы в приделах 0.5 сек).
> Есть ли возможность монтировать виртуальные диски в память, копировать
>туда некие данные (по всей видимость там должны будут находиться некоторые
>тейблспейсы), а затем настроить периодический сброс этих данных на жёсткий диск?База сама кэширует данные в пределах выделенной для нее памяти, и городить такой каскад буферов не следует. Лучше смотрите в сторону оптимизации оракла.
А еще лучше вопрос задайте на тематическом форуме www.sql.ru, там квалифицированного народу по-боле будет.
>[оверквотинг удален]
>>тейблспейсы), а затем настроить периодический сброс этих данных на жёсткий диск?
>
>База сама кэширует данные в пределах выделенной для нее памяти, и городить
>такой каскад буферов не следует. Лучше смотрите в сторону оптимизации оракла.
>
>
>А еще лучше вопрос задайте на тематическом форуме www.sql.ru, там квалифицированного народу
>по-боле будет.
>
>Соль ситуации в том что мне нужно чтобы данные гарантировано были кешированы, хотя в целом я с вами конечно согласен.
А на sql.ru я конечно отмечусь, как пароль вспомню...
>[оверквотинг удален]
>>
>>А еще лучше вопрос задайте на тематическом форуме www.sql.ru, там квалифицированного народу
>>по-боле будет.
>>
>>
>
>Соль ситуации в том что мне нужно чтобы данные гарантировано были кешированы,
>хотя в целом я с вами конечно согласен.
>
>А на sql.ru я конечно отмечусь, как пароль вспомню...Ни при каких условиях полностью закэшированная база не будет быстрей оптимизированной. Запросы оптимизировать надо, а не дурью маяться. Головой подумай - какая машина 64Гб в памяти тебе за полсекунды просмотрит...
Еще раз - гарантированное кэширование СУБД - бред дилетанта. Компрене ву?
>[оверквотинг удален]
>>Соль ситуации в том что мне нужно чтобы данные гарантировано были кешированы,
>>хотя в целом я с вами конечно согласен.
>>
>>А на sql.ru я конечно отмечусь, как пароль вспомню...
>
>Ни при каких условиях полностью закэшированная база не будет быстрей оптимизированной. Запросы
>оптимизировать надо, а не дурью маяться. Головой подумай - какая машина
>64Гб в памяти тебе за полсекунды просмотрит...
>
>Еще раз - гарантированное кэширование СУБД - бред дилетанта. Компрене ву?Умом я это понимаю - главное - убедить технического дирректора? Есть какие-нибудь статьи или статистика чтоб можно было носом ткнуть?
На СФ880 с 32 гб памяти помещали базу в /tmp
все летало
>>Еще раз - гарантированное кэширование СУБД - бред дилетанта. Компрене ву?
>
>Умом я это понимаю - главное - убедить технического дирректора? Есть какие-нибудь
>статьи или статистика чтоб можно было носом ткнуть?Расскажите ему про Oracle TimesTen In-Memory Database
С RAC помещать базу в память бред потомучто все заткнется на CacheFusion, лучше оптимизировать оракл.
Oracle RAC
+ASM
+NETAPP fabric-attached
+Sun Fire X4600 M2 32-core 256GB ram X480000000 tr/h