|
|
Genesis32 и Access |
|
На самом разнообразном железе Access с одной таблицей и базой в два гига ИМХО вы присочинили мальца. Даже Oracle такие таблицы тяжело ворочает уже... |
|
 |
|
|
Ограничение Access как у любого приложения: Адресное пространство процесса - 4 Гб. Из него 2 Гб - область памяти самого приложения + 2 Гб - область памяти системы. В 9х если превысил нижние 2 Гб, приложение затыкается полностью. В NT начинает после превышения тормозить. (Ну не хочет система делиться своей памятью) А все остальное от лукавого! |
|
|
Vel
|
|
|
|
|
Да память вообще непричем тут. У вас таблица на диске лежит. Узкое место не менеджер памяти и лимит адресного пространства в 32-разрядном адресном пространстве. Узкое место дисковая подсистема. И потом таблицы БД целиком не проецируються в память у провайдеров данных как вы себе это в принципе представляете вообще Запустите профайлер на SQL сервере ради интереса сделайте select к большой таблице и посмотрите расход памяти он весьма далек будет от размера таблици Единственный приемлимый выход это фрагментированный массив неиндексированных таблиц в виде дерева с иерархией во времени таблица за сутки таблица за месяц по таблицам за сутки таблица за год по таблицам за месяц Это фрагментирует данные и ускоряет выборку... из наших систем (Российских) такую архитектуру поддерживает Delta |
|
|
|
|
Вообщето тема называется Genesis32 и Access! Причем здесь <Запустите профайлер на SQL сервере ради интереса >? Тогда используйте SQL. Ёще раз повторяюсь, Access тормозит когда размер базы превышает 2 Гб!!! |
|
|
Vel
|
|
|
|
|
Вы сами в дебри полезли Просто в серверных СУБД есть штатные средства контроля производительности в Access нет поэтому я вам предложил посмотреть, что бы сориентироваться. Если сильно нужно можем провести небольшой тест но тут как со временем будет. ИМХО можно достаточно объективно оценить если допустим на одной и той же машине (у меня тестовый сервер PowerEge 2800 Dell RAID 5) один и тот же массив данных побить на таблицы и одной таблицей. ориентируемся на 2 гига. Я пишу на C# фиксируем время начала обращения вычитаем из времени завершения и сравним... Используем сохраненный запрос (параметрический), что бы по максимуму использовать провайдера Access. Только это будет не оперативно |
|
|
|
|
разбивайте по таблицам будет меньше тормозить
Еще обратите внимание на общесистемные вещи. Тип файловой системы я полагаю у вас NTFS проверьте объем сободного места и уровень фрагментации системной партиции и партиции БД резерв желательно иметь на NTFS 25%. При уровне фрагментации более 10-15% процентов многие клиенты БД уже затыкаються по тайм аутам при работе с большими файлами. |
|
|
|
|
уже разбил. Прошло 5 дней - пока все работает нормально. Хотя 5 дней - это, конечно, не показатель. |
|
|
|
Ответить 
|
Страница <12 |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
посмотрите так же план выполнения. А если массив не индексирован с целью ускорения записи то вообще выборка будет тупить это нормально в общем то. если одну и ту же базу поднять на RAID 0 или 5 и на IDE одном диске там и ходить никуда не надо все так видно невооруженным глазом. 
а принципы то они везде одинаковые если что 
но зато результативно. Заморочимся?