Здравствуйте, MasterZiv, Вы писали:

MZ>Может
Надо будет потестить.

S>>2) Понятно, что разбивка наиболее эффективна, когда происходит по первому полю ключа индекса.
S>>Если это поле не первое, либо вообще не включено в индекс, то будут просматриваться индексы всех разделов.
MZ>Нет, могут быть просмотрены только нужные разделы. Например, если в запросе фильтр по диапазону дней (3 дня скажем), то можно
MZ>просмотреть только 3 партиции.
Не совсем понял. Допустим индекс создан по (guid), я разбиваю его по (date) и она неявно добавляется в ключ (date, guid). Чисто технически искомый guid может оказаться в любом разделе, если дата поиска не указана явно.

S>>Влияет ли на производительность количество разделов, если они находятся на одном хранилище (в одной или нескольких файловых группах)? Имеет ли смысл уменьшать количество разделов, т.е. будет ли это влияние сколь-нибудь значимым (сервер на 4-х Ксеонах, памяти >0.5ТБ) или им можно пренебречь?
MZ>Количество разделов следует увеличивать, чем их больше, тем более выгодно их иметь.
Можешь пояснить?

S>>3) Цель разбивки — вывести архивные данные в отдельные файлы и сжать разделы, уменьшив объём файла содержащего оперативные данные.
MZ>Сомнительная цель. То же можно сделать индексами.
Можешь пояснить?

S>>4) С точки зрения архитектуры всего этого: имеет ли смысл делать отдельные схемы разбиения (partition scheme и/или partition function) для разных индексов, даже если они будут разбиваться одинаковым способом?
MZ>не понял.
т.е. стоит ли для каждой таблицы создавать свою partition function/scheme или использовать общую? (таблицы 1С и достаточно однотипны).