Таблица усекается, но статистика остается в хранилище данных SQL Azure

У меня есть серия таблиц, похожих на кэш, используемых в приложении, которое я оцениваю на предмет перехода к хранилищу данных SQL Azure.

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

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


azure-sqldw
person Steve    schedule 21.12.2016    source источник
comment
какой вариант использования? Когда вы отслеживаете таблицу, все, что остается, - это схема. Нет данных, следовательно, нет статистики. Когда таблица будет регидратирована, будет новая статистика в зависимости от того, что было загружено. Не могли бы вы подробнее рассказать о своем сценарии использования, в котором, по вашему мнению, важно сохранять старую статистику?   -  person SQLmojoe    schedule 22.12.2016
comment
Таблицы, подобные кешу, загружаются постепенно в течение дня, поскольку выбор пользователя в пользовательском интерфейсе преобразуется в операции с базой данных. Поэтому, если бы я собирал статистику до дня пользователей, они не были бы репрезентативными, так как таблица была бы TRUNCATEd за ночь. Сбор статистики в каждом отчете, скорее всего, будет излишним (и, вероятно, вызовет конкуренцию за блокировку). Я думал, что прочитал, где можно подделать статистику, которую мне придется изучить, если я буду использовать TRUNCATE. Я, вероятно, могу просто использовать DELETE и принять ведение журнала, чтобы статистика оставалась неизменной.   -  person Steve    schedule 22.12.2016
comment
Нет возможности подделывать статистику. QO использует статистику (и другие вещи), чтобы разработать лучший план в разумные сроки. Предоставление фальшивой статистики как бы сводит на нет цель обеспечения качества обслуживания, основанного на затратах. Шансы на получение приличного плана с использованием фальшивой статистики такие же, как и на получение приличного плана без статистики. Кроме того, создание и обновление статистики никогда не приводит к конкуренции за блокировку. Это может привести к блокировке, но это не то же самое, что конкуренция за блокировку.   -  person SQLmojoe    schedule 22.12.2016

Ответы (1)


arrow_upward
1
arrow_downward

Нет, вы не можете вести статистику после TRUNCATE. По моему опыту, повторная выборка ключевых столбцов (без использования «ПОЛНОГО СКАНИРОВАНИЯ») в любом случае не займет так много времени. В конце концов, это система MPP.

При повторной блокировке вы должны знать, что уровень изоляции транзакции по умолчанию для хранилища данных SQL Azure - «Чтение без фиксации», поэтому конкуренция за блокировку не является проблемой.

В настоящее время метод подделки статистики недоступен в хранилище данных SQL Azure.

person wBob    schedule 22.12.2016