Вы видите разницу между таблицей, созданной с помощью CxTAS (CTAS, CETAS или CRTAS), и CREATE TABLE.
Когда вы запускаете CREATE TABLE, значения количества строк и количества страниц фиксируются, поскольку таблица пуста. Если память не изменяет, фиксированные значения составляют 1000 строк и 100 страниц. При создании таблицы с помощью CTAS они не фиксируются. Фактические значения известны команде CTAS, поскольку она только что создала и заполнила таблицу одной командой. Следовательно, метаданные правильно отражают размер таблицы при использовании CxTAS. Это хорошо. Оптимизатор на основе затрат APS / SQLDW может сразу же сделать более точные оценки для создания плана MPP на основе размера таблицы, когда таблица была создана с помощью CxTAS, а не таблицы CREATE.
Очень важно иметь точное представление о размере стола.
Представьте, что у вас есть таблица, созданная с помощью CREATE TABLE, а затем с помощью INSERT в указанную таблицу вставляется 1 миллиард строк. База данных оболочки по-прежнему считает, что в таблице 1000 строк и 100 страниц. Однако это явно не так. Причина этого в том, что в настоящее время атрибуты размера таблицы не обновляются автоматически.
Теперь представьте, что запущен запрос, требующий перемещения данных в этой таблице. Все может пойти наперекосяк. Теперь вы, скорее всего, увидите, что движок делает неправильный выбор плана MPP (обычно используя BROADCAST, а не SHUFFLE), поскольку он, помимо прочего, не понимает размер таблицы.
Что вы можете сделать, чтобы улучшить это?
Вы создаете по крайней мере один объект статистики на уровне столбца для каждой таблицы. Вообще говоря, вы будете создавать объекты статистики для всех столбцов, используемых в JOINS, GROUP BY, WHERE и ORDER BY в ваших запросах. Я объясню основной процесс генерации статистики через мгновение. Я просто хочу подчеркнуть, что призыв к действию здесь заключается в том, чтобы убедиться, что вы создаете и поддерживаете свои объекты статистики.
Когда CREATE STATISTICS выполняется для столбца, на самом деле происходят три события.
1) Информация уровня таблицы обновляется на узле CONTROL.
2) Объект статистики на уровне столбца создается для каждого распределения на узлах COMPUTE.
3) Объект статистики уровня столбца создается и обновляется на узле CONTROL.
1) Информация на уровне таблицы обновляется на узле CONTROL.
Первым шагом является обновление информации на уровне таблицы. Для этого APS/SQLDW выполняет DBCC SHOW_STATISTICS (table_name) WITH STAT_STREAM для каждого физического распределения; объединение результатов и их сохранение в метаданных каталога базы данных оболочки. Количество строк хранится в sys.partitions, а количество страниц — в sys.allocation_units. Sys.partitions виден вам как в SQLDW, так и в APS. Однако в настоящее время sys.allocation_units не виден конечному пользователю. Я указал это место для тех, кто знаком с внутренним устройством SQL Server, для информации и контекста.
В конце этого этапа метаданные, хранящиеся в базе данных оболочки на узле CONTROL, были обновлены как для количества строк, так и для количества страниц. Теперь нет разницы между таблицей, созданной с помощью CREATE TABLE, и CTAS — обе знают размер.
2) Объект статистики на уровне столбца создается для каждой раздачи на узлах COMPUTE
Объект статистики должен быть создан в каждом распределении на каждом узле COMPUTE. При создании объекта статистики были созданы важные подробные статистические данные (в частности, гистограмма и вектор плотности) для столбца.
Эта информация используется APS и SQLDW для создания планов SMP на уровне распространения. Планы SMP используются APS/SQLDW только на ФИЗИЧЕСКОМ уровне. Поэтому на данный момент статистические данные не находятся в месте, которое можно использовать для создания планов MPP. Информация распространяется и недоступна своевременно для оптимизации на основе затрат. Поэтому необходим третий шаг...
3) Объект статистики на уровне столбца создается и обновляется на узле CONTROL
После того, как данные ФИЗИЧЕСКИ созданы в распределениях на уровне ВЫЧИСЛЕНИЙ, они должны быть объединены и храниться ЛОГИЧЕСКИ, чтобы упростить оптимизацию плана MPP на основе затрат. База данных оболочки на узле CONTROL также создает объект статистики. Это ЛОГИЧЕСКОЕ представление объекта статистики.
Однако статистика базы данных оболочки еще не отражает статистическую информацию на уровне столбцов, ФИЗИЧЕСКИ хранящуюся в дистрибутивах на узлах COMPUTE. Следовательно, объект статистики в базе данных оболочки на узле CONTROL необходимо ОБНОВИТЬ сразу же после его создания.
Для этого используется DBCC SHOW_STATISTICS (table_name, stat_name) WITH STAT_STREAM.
Обратите внимание, что у команды есть второй параметр. Это изменяет набор результатов; предоставление APS/SQLDW всей информации, необходимой для построения ЛОГИЧЕСКОГО представления объекта статистики для этого столбца.
Я надеюсь, что это каким-то образом объясняет то, что вы видели, а также то, как создаются статистические данные и почему они важны для Azure SQL DW и для APS.
person
JRJ
schedule
31.12.2015
