Здравствуйте.

Есть таблица, содержащая поле (timestamp DATETIME) по которому идёт партиционирование. У этой таблицы есть уникальные некластерные индексы, не содержащие в ключе поля timestamp. Если я правильно понял, наличие поля в таком индексе нужно для:

This restriction enables SQL Server to investigate only a single partition to make sure no duplicate of a new key value already exists in the table.

Повлияет ли на использование индекса включение этого поля в конце списка ключевых полей (в сравнении с изменением его типа на неуникальный)? Ведь в принципе это даже на размер индекса повлиять не должно (поле timestamp было в ключе исходного кластерного индекса).

Второй вопрос — обновляются ли некластерные индексы при пересоздании кластерного в новой схеме партиционирования с флагом DROP_EXISTING = ON и неизменившимся ключом? Имеет ли смысл DROP'ать некластерные индексы при таком преобразовании перед пересозданием кластерного?

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

S>Есть таблица, содержащая поле (timestamp DATETIME) по которому идёт партиционирование. У этой таблицы есть уникальные некластерные индексы, не содержащие в ключе поля timestamp.

А сами эти интексы партиционированы?

S>Повлияет ли на использование индекса включение этого поля в конце списка ключевых полей (в сравнении с изменением его типа на неуникальный)? Ведь в принципе это даже на размер индекса повлиять не должно (поле timestamp было в ключе исходного кластерного индекса).

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

S>Второй вопрос — обновляются ли некластерные индексы при пересоздании кластерного в новой схеме партиционирования с флагом DROP_EXISTING = ON и неизменившимся ключом? Имеет ли смысл DROP'ать некластерные индексы при таком преобразовании перед пересозданием кластерного?

При обновлении кластерного индекса может изменится физическое положение записей. Соотвественно, нужно обновить ссылки на на записи в индексах.

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

S>Здравствуйте.

S>Есть таблица, содержащая поле (timestamp DATETIME) по которому идёт партиционирование. У этой таблицы есть уникальные некластерные индексы, не содержащие в ключе поля timestamp. Если я правильно понял, наличие поля в таком индексе нужно для:

Так какого типа поле timestamp DATETIME?

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

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

S>>Есть таблица, содержащая поле (timestamp DATETIME) по которому идёт партиционирование. У этой таблицы есть уникальные некластерные индексы, не содержащие в ключе поля timestamp.
IT>А сами эти интексы партиционированы?
Нет, потому и спрашиваю.

S>>Повлияет ли на использование индекса включение этого поля в конце списка ключевых полей (в сравнении с изменением его типа на неуникальный)? Ведь в принципе это даже на размер индекса повлиять не должно (поле timestamp было в ключе исходного кластерного индекса).

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

Не уверен что все запросы фильтруют по timestamp, но запрос не включающий ts должен запустить параллельный scan или seek на всех разделах? (Само собой если оптимизатор не решит что нет более выгодного решения)

S>>Второй вопрос — обновляются ли некластерные индексы при пересоздании кластерного в новой схеме партиционирования с флагом DROP_EXISTING = ON и неизменившимся ключом? Имеет ли смысл DROP'ать некластерные индексы при таком преобразовании перед пересозданием кластерного?

IT>При обновлении кластерного индекса может изменится физическое положение записей. Соотвественно, нужно обновить ссылки на на записи в индексах.

Ээээээ... некластерные индексы при наличии кластерного используют не абсолютные ссылки, а ключ кластерного индекса. Потому и возник вопрос.

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

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

S>>Здравствуйте.

S>>Есть таблица, содержащая поле (timestamp DATETIME) по которому идёт партиционирование. У этой таблицы есть уникальные некластерные индексы, не содержащие в ключе поля timestamp. Если я правильно понял, наличие поля в таком индексе нужно для:

BE>Так какого типа поле timestamp DATETIME?

DATETIME timestamp — название поля. Я просто решил выпендриться и записать это в стиле SQL.

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

IT>>А сами эти интексы партиционированы?
S>Нет, потому и спрашиваю.

Понятно. Я в конце концов все свои подобные индексы партиционировал.

S>Не уверен что все запросы фильтруют по timestamp, но запрос не включающий ts должен запустить параллельный scan или seek на всех разделах? (Само собой если оптимизатор не решит что нет более выгодного решения)

Если индекс не партиционированный, то вроде всё работает как обычно и деградация производительности неизбежно наступает с ростом объёма данных. Тоже самое происходит, если все индексы/таблица партеционированы, но фильтр по ts в запросах не используется. Даже если это поле завязано через джоины с другими таблицами, но явно не указано в фильтре, то оптимизатор всё равно не может разобраться. По крайней мере это справедливо для SQL Server 2012. Так что, исходя из моего личного опыта, единственный правильный способ использования партиционирования — это всегда использовать соответсвтующее поле в фильтре для всех партиционированнх таблиц. Иначе после (для моего железа) 150M записей в таблице начинается деградация. А с фильтром даже миллиарды записей никак на производительность не влияют.

S>Ээээээ... некластерные индексы при наличии кластерного используют не абсолютные ссылки, а ключ кластерного индекса. Потому и возник вопрос.

Ну может быть. Я в таких дебрях не разбирался. Хотя, если у меня кластерный индекс содержит 15 полей, то как-то это не очень.

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

S>DATETIME timestamp — название поля. Я просто решил выпендриться и записать это в стиле SQL.

Вообще-то странный тип для партиционирования. Непонятны сценарии использования.

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

IT>Если индекс не партиционированный, то вроде всё работает как обычно и деградация производительности неизбежно наступает с ростом объёма данных. Тоже самое происходит, если все индексы/таблица партеционированы, но фильтр по ts в запросах не используется. Даже если это поле завязано через джоины с другими таблицами, но явно не указано в фильтре, то оптимизатор всё равно не может разобраться. По крайней мере это справедливо для SQL Server 2012. Так что, исходя из моего личного опыта, единственный правильный способ использования партиционирования — это всегда использовать соответсвтующее поле в фильтре для всех партиционированнх таблиц. Иначе после (для моего железа) 150M записей в таблице начинается деградация. А с фильтром даже миллиарды записей никак на производительность не влияют.

Надо будет потестировать. Когда я экспериментировал, вроде сканирование всех разделов шло параллельно. Формально скорость снижается, но насколько — надо смотреть.

S>>Ээээээ... некластерные индексы при наличии кластерного используют не абсолютные ссылки, а ключ кластерного индекса. Потому и возник вопрос.

IT>Ну может быть. Я в таких дебрях не разбирался. Хотя, если у меня кластерный индекс содержит 15 полей, то как-то это не очень.

Тогда все 15 полей попадут во все некластерные индексы автоматически.
Поясню — если все эти 15 полей находятся в ключе кластерного индекса. Что весьма странный сценарий. А вот запихивать в ключ длинное текстовое поле точно не стоит.

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

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

S>>DATETIME timestamp — название поля. Я просто решил выпендриться и записать это в стиле SQL.

IT>Вообще-то странный тип для партиционирования. Непонятны сценарии использования.

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

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

S>Надо будет потестировать. Когда я экспериментировал, вроде сканирование всех разделов шло параллельно. Формально скорость снижается, но насколько — надо смотреть.

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

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

S>Данные добавляются с таймштампом, таблица используется для агрегирования данных за определённый период времени. Плюс, поскольку задним числом (за достаточно большой период времени) добавления данных нет, уменьшается время обслуживания базы.

А просто date в качестве типа для этого поля не подойдёт?

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

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

S>>Данные добавляются с таймштампом, таблица используется для агрегирования данных за определённый период времени. Плюс, поскольку задним числом (за достаточно большой период времени) добавления данных нет, уменьшается время обслуживания базы.

IT>А просто date в качестве типа для этого поля не подойдёт?

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

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

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

S>>Надо будет потестировать. Когда я экспериментировал, вроде сканирование всех разделов шло параллельно. Формально скорость снижается, но насколько — надо смотреть.

IT>Потестируй. Для простых запросов может и будет распараллеливать. Даже наверняка. Для более сложных у оптимизатора может крышу сорвать в любой момент. К тому же, если деградация есть, то с ростом объёма данных она будет только усугубляться. Пол года может будет всё работать приемлемо, а потом начнётся.

Тут интересно мнение olaf'а, но на мой взгляд, если индекс подходит, то оптимизатор задействует его в любом случае — с его точки зрения вряд ли важно партиционирован индекс или нет — сложность возрастает незначительно: исходная o(log(n)), новая — o(k*log(n/k))~o(log(n)), количество чтений возрастает — но ветки индекса и так в памяти обычно, а количество считываемых листьев сильно возрасти не должно. Так на так.

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

S>Не очень. А какая разница, если разделение на разделы происходит в любом случае по заданным границам?

Это так. Но как уже было сказано, чтобы запросы были эффективными нужно обязательно использовать соответствующее поле в фильтрах. С datetime это довольно проблематично. А без этого смысл в партиционировании не очень большой. Вставка данных будет работать побыстрее, компрессию можно будет наладить, ну ещё в простых запросах может быть распараллеливание будет немного помогать.

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

IT>Это так. Но как уже было сказано, чтобы запросы были эффективными нужно обязательно использовать соответствующее поле в фильтрах. С datetime это довольно проблематично.

Почему?

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

S>Тут интересно мнение olaf'а, но на мой взгляд, если индекс подходит, то оптимизатор задействует его в любом случае — с его точки зрения вряд ли важно партиционирован индекс или нет — сложность возрастает незначительно: исходная o(log(n)), новая — o(k*log(n/k))~o(log(n)), количество чтений возрастает — но ветки индекса и так в памяти обычно, а количество считываемых листьев сильно возрасти не должно. Так на так.

Индекс то задействует. Но одно дело задействовать весь индекс или все его партиции. Другое дело задейстовать гарантированно малую часть индекса. Разница может быть на порядки. 100 партиций — это уже два порядка. Если же эффекта никакого, то скорее всего это означает, что нет никакого эффекта от самого партиционирования.

У меня примерно так и было. Несколько месяцев база работала как часы, пока объём данных не достиг определённого объёма. Потом началась медленная, но уверенная деградация производительности. Хорошо, что вовремя спохватились и начали принимать меры.

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

IT>>Это так. Но как уже было сказано, чтобы запросы были эффективными нужно обязательно использовать соответствующее поле в фильтрах. С datetime это довольно проблематично.

S>Почему?

Мне так кажется Чтобы однозначто идентифицировать запись тебе нужен не только её ключ, но и timestamp.

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

IT>Мне так кажется Чтобы однозначто идентифицировать запись тебе нужен не только её ключ, но и timestamp.

Таймштамп может входить в ключ

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

IT>>Мне так кажется Чтобы однозначто идентифицировать запись тебе нужен не только её ключ, но и timestamp.
S>Таймштамп может входить в ключ

Если входит, то никаких проблем. Мне просто сложно представить такой сценарий. Ведь timestamp по идее генерируется самой базой.

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

S>Повлияет ли на использование индекса включение этого поля в конце списка ключевых полей (в сравнении с изменением его типа на неуникальный)? Ведь в принципе это даже на размер индекса повлиять не должно (поле timestamp было в ключе исходного кластерного индекса).
С учетом влияния тяпницы на мозг, ИМХО и ЕМНИП.

На размер не повлияет. А вот на некоторые запросы повлиять может. Timestamp будет включен в SARG

Порядок полей имеет значение. Если кластерный индекс вида clcol1, clcol2, clcol3, ts,
то сейчас у тебя некластерный имеет вид nc_col1, ..., nc_coln; clCol1, ... , ts.
При изменении вид будет nc_col1, ..., nc_coln, ts, clCol1, ... , clColm.

S>Второй вопрос — обновляются ли некластерные индексы при пересоздании кластерного в новой схеме партиционирования с флагом DROP_EXISTING = ON и неизменившимся ключом? Имеет ли смысл DROP'ать некластерные индексы при таком преобразовании перед пересозданием кластерного?
Нет, не имеет, и нет, не обновляются, т.к. в некластерных индексах хранится не ссылка на адрес, а фактическое значение кластерного индекса.
Партиционирование в этом плане ничего не меняет.