История следующая. Имеется конфа 8.1 на основе УТ 10.3 переписанная сильно. В данный момент база весит 105 гигов. Из них регистр сведений Установка цен номенклатуры 29 гигов. Документ установка цен номенклатуры 12 гигов. (Размеры таблиц оценивал вот это штукой http://infostart.ru/public/59489/) База обрезанная. Регистр сведений Установка цен номенклатуры сейчас растет примерно по гигу в неделю. На сервере всего 44 гига оперативы. Я руководству упорно говорю что срочно надо докупать еще памяти. В ответ мне задается вопрос "А все ли нас оптимально настроено?" Потому 2 вопроса
1. Как себя будет чувствовать sql, если у него одна таблица не будет целиком влезать в оперативу?
2. Какие оптимальные настройки для такой базы, где 1/3 почти занимает 1 таблица, если они конечно есть?

Непонятно, как соотносится таблица, данные которой хранятся на диске и читаются порциями, размер оперативной памяти и самочувствие SQL?

и ведь устраиваются такие на жирные места, получают атстатыщщ...

Почему-то многие считают, что объем ОЗУ на сервере как-то должен коррелировать с объемом данных.. На самом деле, он скорее должен коррелировать со скоростью их изменения.

ндээ... что-то не ладно в датском королевстве

>>сейчас растет примерно по гигу в неделю
с чего хоть? для интереса

честно говоря вопрос руководства считаю адекватным, стоит проанализировать почему таблица цен номенклатуры больше чем таблицы остатков и партий.

Оптимизировать значит нужно, раз так растет. Пойди ежедневно одну и туже цену повторяют или у Вас там инфляция такая что каждый день новая цена?
(1) +1.
Таблица растет от того, что: данные + индексы выстраивать нужно. Оперативка при нормальных индексах здесь не нужна.
ИМХО право руководство.

(0) задается вопрос "А все ли нас оптимально настроено?"
Так говори, что всё :)
Память лишней не бывает, если сервер позволяет больше воткнуть.

(+2) да уж

(0) главный ответ тебе такой: в регистре цен обычно используется СрезПоследних
так что вся таблица практически никогда не нужна !

Типов цен 150 и каждый день их меняют. Номенклатуры на остатках 8000. Вот так и грузим каждый день. В конце недели я удаляю дублирующие цены

+1 к вопросу руководства, что-то здесь не так.

Но если отвечать в лоб на вопрос в (0), то:
1) оперативка не обязательно должна быть больше или равна размеру базы. Просто если вся база лежит в оперативке - база как правило (есть исключения, но редкие) работает быстрее, потому что нет операций чтения с диска. Иначе - будет читаться с диска по мере необходимости.
2)
2.1) Для больших таблиц, в которых чаще всего нужны данные по последним разрезам, если купленная версия скуля поддерживает партиционирование, то для оптимизации можно использовать партиционирование. Что это такое - см. гугл.
2.2) Провести анализ, что творится с таблицей. Чаще всего большая часть места занимают не данные, а индексы. Редкоиспользуемые индексы можно раскидать по разным дискам, или вообще удалить, или просто перестроить (они могут ужаться).

Судя по (11), неадекватные конторы принимают на работу неадекватных сотрудников.

(11) Маразм. Зачем удалять? Лучше не грузить сразу, раз они дублируются. Удаляете-то хоть совсем, или пометкой на удаление? :)

(14) кстати да.... ведь SQL скорее всего физически в таблице регистра не удаляет данные, а лишь помечает что они удалены

(14) а они наверняка не срезом последних пользуются, а выборкой на дату.
теоретически так быстрее.

честно говоря не думаю что нужно грузить все 150 типов цен. Наверняка можно использовать динамические местами.

И такой вопрос зачем нужна история цены ? Она вам точно нужна ?

Про цены я уже давно ругаюсь, но маркетологи говорят, что это необходимо...

А какова периодичность регистра сведений "Цены номенклатуры" - может она в секундах ?

(16) Надо анализировать. Если действительно по большей части номенклатуры цены изменяются каждый день - то да. А если наоборот, изменения относительно редки - то все же быстрее будет СрезПоследних при условии, что цена будет записываться только при изменении.

Как вариант оптимизации: удалить из регистра цен все ресурсы, кроме "Цена" и измерение "ХарактеристикаНоменклатуры", если не используется.

(19) см. (17), согласна - ваши маркетологи наверняка же не забивают все 150 типов цен ручками? Есть наверняка формула, связывающая цены.

в общем постановка методологии учета страдает ...
от того и регистры пухнут ....

думаем, анализируем, задаём вопросы, думаем ...

Периодичность "По позиции регистратора"...
(23) Сравниваются цены конкурентов. Потом каким-то макросом по каким-то правилам создается файлик с нашими ценами и я уже просто перегружают экселевский файлик

(26) с такой постановкой ваше задние больше напоминает не техническое, а спиритическое ....
Тогда переходим к статистическому заданию: напишите обработку которая рассчитает коэффициенты вариации и дисперсию между всеми этими типами цен. Глядишь 150 превратятся в 30. Тем более что статистических данных, судя по размеру регистра, у Вас предостаточно!

(27)Предложения снизить количество типов цен я уже не раз озвучивал. В ответ услышал что все нужны...