Matrim написал(а):

создать ramdisk и хранить на нем базы
корявое решение, это должен делать кэш os/субд

Мне тоже такое сразу в голову пришло.
Сразу вопросы: как обстоят дела с сохранением данных при выключении и при загрузке? Имеется ли функционал на сохранение данных в случае поступления сигнала с безперебойника?

На лекциях по СУБД помнится говорили что еще MS SQL 2000 умеет базы в нарезать и полностью работать только с оперативой. Соответственно при выключении ПК автоматом сохраняет базы на жестком, а при загрузке подсасывает обратно в оперативу.

Хендерсон в книге "Microsoft SQL Server: структура и реализация. Профессиональное руководство" пишет, что в mssql сервере реализовано пять классов диспетчеров памяти (какие-то для разных задач, какие-то вступают в действие при определенных условиях, например при полном исчерпании определенного блока памяти), всё это реализовано на низких уровнях и отвязано от средств самой ос для предельной оптимизации под СУБД.
После прочтения глав что-то особо желание мутить конструкцию с рамдиском отпало, такое ощущение, что соорудить лучше чем это работает внутри СУБД не получится.
Но я упорный и попробую пару вечеров погонять в разных режимах БД на рамдиске, посмотрим даст ли это что-нибудь.

XuMiX написал(а):

пуск-программы-ммскуль-конфигурация чотатам-там есть

Понятное дело, что через Configuration Studio. Другой вопрос, что mssql упорно не стартовал после включения одного из этих протоколов.
Shared Memory заработал (дал кстати некислый прирост по сравнению с tcp) только после апгрейда до mdac 2.81, на 2.8 и ниже его по определению включить нельзя.

XuMiX написал(а):

а зачем?

Ну сам-то как думаешь?

Да пока только пытаюсь сообразить в каком направлении копать.
Сам не специалист по СУБД mssql и как-то не шибко охота в ближайшие годы им становиться.

Предпочтительны конечно способы эээ "попроще", чтобы поменьше шаманить внутре СУБД, как можно меньше трогать то, что и так пока более мене работает, а то ведь как следствие обычно подкручу настройки, которые плохо понимаю, то что раньше нормально работало будет работать либо хуже либо возможны глюки. Придется либо заново возвертать или
как было под ноль либо за учебники садиться, а магические особенности винды сам знаешь иногда проявляются в самые неподходящие моменты.

Ну вот результат перехода с TCP на Shared memory уже неплохой.

Например: тестовое приложение для замера производительности потоком/потоками поливает insert и update запросами со случайными данными табличку/таблички в БД. На боевом приложении так не погоняешь.

Замер на shared memory
200 000 транзакций запрос insert 2 поля
Время выполнения 1182812500 тиков (118,28125 сек)

Замер на tcp
200 000 транзакций запрос insert 2 поля
Время выполнения 1582343750 тиков (158,234375 сек)

Прирост 33,778%
В среднем с разными параметрами кол-во транзакций, потоков, полей, таблиц дают примерно такие же результаты +~29-34%.

При проведении тестов было замечено как свопится винт, поэтому сразу пошли аналогии о переносе БД в оперативу.

В решаемой задаче данные буферные и не требуют сохранения на века, а актуальны только в течении нескольких часов пока идут вычисления, потом уже не нужны после получения результата. Общий размер такой буферной БД наверно максимум может полгига. Но и соответственно данные во время прогонов из-за перебоев питания терять нельзя.

Поиск информации о том как в самой СУБД создать БД чисто в оперативе без работы с винтом как-то пока результатов не дал, но пока и не так упорно искал :)
Что посоветуешь?

Исправлено okyl (07.01.09 23:26)