SQL DW Внутренняя загрузка данных таблицы занимает много времени

Я столкнулся с проблемами при загрузке данных между внутренними таблицами SQL DW, и я пытаюсь загрузить только 50 записей, которые есть в моем источнике, но оператор Insert занимает очень много времени и не выполняется успешно [Он продолжает работать более 60 минут]

Немного статистики по этому поводу • Исходная таблица (скажем, S1) имеет 50 записей, 105 столбцов, столбцовое хранилище, циклическое распределение на DWU 100 [DDL этой таблицы приведен ниже] • Целевая таблица (скажем, T1) была создана с теми же 105 столбцами, Columnar Store, Round robin Distribution на DWU 100 • Выбрать 5 лучших * из S1 работает • Выбрать * из S1 работает • Вставить в T1, поскольку выбор * из S1 работает долгое время без ответа [более 60 минут] • Вставить в T1 как выбрать верхние 5 * из S1, работал один раз и не работал после этого • Вставить в T1 как выбрать верхние 5 all_columns_listed из S1, работает всегда и выполняется за ‹1 минуту • Вставить в T1 как выбрать верхние 30 all_columns_listed из S1, работает всегда и выполняется за ‹1 минуту • Вставить в T1 как выберите 50 лучших all_columns_listed из S1, выполняется более 25 минут

Я не могу понять, что может происходить в фоновом режиме - когда выполняется вставка в T1, поскольку выполняется select * from S1;

Что-то не так с DMS? или это потому, что у нас 105 столбцов?

Все вышеперечисленные операции были опробованы путем масштабирования до DWU 200 - но все равно безуспешно.

Все вышеперечисленные операции были опробованы на совершенно другой базе данных, но безуспешно.

Есть ли еще что-нибудь, что можно проверить на том, что происходит? Как с этим справиться?

Также я попытался запустить приведенный ниже оператор, чтобы увидеть - есть ли какие-либо другие активные запросы - которые могут приостановить мой оператор вставки или подождать ... но я мог видеть - только мой запрос активно выполнялся в БД ... выберите * из " sys "." dm_pdw_exec_requests ", где status = 'Выполняется' заказ по submit_time desc

Если вы загружаете данные в пустую таблицу, вам следует подумать об использовании _1_ (CTAS), а не _2_, чтобы DW мог полностью распараллелить операцию между узлами.


person Aravind    schedule 27.10.2016    source источник


Ответы (1)


https://azure.microsoft.com/en-us/documentation/articles/sql-data-warehouse-develop-ctas/ объясняет CTAS и https://saldeloera.wordpress.com/2012/10/15/pdw-performance-tip-ctas-vs-insert-select/ есть более полное сравнение.

нет .. Это не пустая таблица. Целевая таблица (T1) будет нашей основной таблицей, в которой мы будем делать добавочные данные из исходной таблицы (S1). Для целей тестирования - я попытался использовать CTAS как создать таблицу T2 WITH (HEAP, DISTRIBUTION = ROUND_ROBIN) как select * FROM S1, и оператор выполняется более 15 минут [опять же, S1 имеет только 50 записей], а также заметил, что это единственный активный запрос, выполняемый на сервере базы данных 200 DWU.

person David Bick    schedule 27.10.2016
comment
Привет, Аравинд. Вы знаете, какой класс ресурсов вы используете? Если вы используете учетную запись администратора по умолчанию, то вы используете наименьший класс ресурсов. Если эти столбцы достаточно велики, возможно, вам не хватает памяти. Если это тот случай, когда вы используете небольшой класс ресурсов, попробуйте сделать пользователя большего класса ресурсов и повторите попытку. azure.microsoft.com/en-us/documentation/articles/ - person Aravind; 27.10.2016
comment
Привет, я пробовал с 100DWU - smallrc, largec и xlargerc - не повезло, также попробовал с 200DWU - smallrc, largec, xlargerc - не повезло S1 (источник) 50 записей, 105 столбцов - person hirokibutterfield; 27.10.2016
comment
Статистика таблицы two_part_name [S1] table_row_count 50 table_reserved_space_GB 0,004752 table_data_space_GB 0,001152 table_index_space_GB 0 table_unused_space_GB 0,0036 - person Aravind; 27.10.2016
comment
Какие у вас разрешения на этом сервере? Может быть, что-то очень интенсивное работает, но вы не видите этого из-за ваших разрешений? Подумайте о том, чтобы подать заявку в службу поддержки через портал. Новый вариант запроса поддержки. - person Aravind; 27.10.2016
comment
Я тоже пробовал запускать эти операторы с учетными данными администратора, но все та же проблема. Я пробовал запускать эти операторы в течение последних 2 дней - в разное время [просто чтобы убедиться, что какие-либо операции резервного копирования или системы не конфликтуют с загружаемыми мной данными] - person wBob; 27.10.2016
comment
Если вы разместите фактический код, который вы используете, то мы сможем что-то обнаружить. В противном случае дайте нам знать, как у вас обстоят дела с обращением в службу поддержки. - person Aravind; 28.10.2016
comment
S1 [исходная таблица] DDL приведен выше. S1 и T1 [Целевая таблица] DDL - это одна и та же вставка в T1. Select * from S1 - это мой SQL, который работает долгое время [S1 имеет 50 записей] - person wBob; 28.10.2016
comment
Я не могу воспроизвести это локально. Я настроил ваши таблицы, как описано, и смог вставить 50 записей из одной таблицы в пустую на моем складе за 2 секунды при 400 DWU. Пожалуйста, опубликуйте точную инструкцию INSERT, которую вы выполняете. Просто несколько замечаний о вашей таблице, _1_ без какой-либо длины по умолчанию имеет длину 1. Как уже было предложено, рассмотрите возможность создания заявки в службу поддержки через портал Azure. Эта опция доступна в разделе склада. - person Aravind; 30.10.2016
comment
вставить в T1 select * from S1 - это мой оператор Insert, который я выполняю. Сейчас я работаю с командой Microsoft, похоже, это проблема DMS. [DMS зависает] - person wBob; 30.10.2016
comment
Было бы здорово, если бы вы могли обновить сообщение, когда у вас будет ответ от MS, так как это поможет другим с той же проблемой. Даже опубликуйте его как ответ и отметьте, что он ответил сам, если хотите:) - person Aravind; 31.10.2016
comment
Я слышал, что это дефект, над исправлением которого работает Microsoft. В нашем случае размер строки ›32 КБ, следовательно, служба перемещения данных не смогла переместить данные между распределениями, и поэтому она зависла .. - person wBob; 31.10.2016
comment
Интересно, что я не смог воспроизвести это своим запросом. Как вы думаете, почему это так? - person Aravind; 04.11.2016
comment
S1 DDL приведен ниже CREATE TABLE S1 (
col1 [uniqueidentifier] NOT NULL,
col2 nvarchar NULL,
col3 [uniqueidentifier] NULL,
col4 nvarchar NULL,
col5 nvarchar NULL, < br> col6 [десятичный] (26, 6) NULL,
col7 [десятичный] (26, 6) NULL,
col8 [десятичный] (26, 6) NULL,
col9 [десятичный] (26 , 6) NULL,
col10 [decimal] (27, 6) NULL,
col11 [decimal] (27, 6) NULL,
col12 [decimal] (26, 6) NULL,
col13 [десятичный] (25, 6) NULL,
col14 [десятичный] (25, 6) NULL,
col15 datetimeoffset NULL,
col16 nvarchar NULL,
col17 datetimeoffset NULL,
col18 [smallint] NULL,
col19 [decimal] (25, 6) NULL,
col20 [decimal] (25, 6) NULL,
col21 [decimal] (26, 6) NULL,
col22 [десятичный] (26, 6) NULL,
col23 datetimeoffset NULL,
col24 [decimal] (25, 6) NULL,
col25 [decimal] (25, 6) NULL,
col26 [int] NULL,
col27 [десятичный] (25, 6) NULL,
col28 datetimeoffset NULL,
col29 [десятичный] (25, 6) NULL,
col30 [десятичный] (25, 6) NULL,
col31 datetimeoffset NULL,
col32 datetimeoffset NULL,
col33 datetimeoffset NULL,
col34 datetimeoffset NULL,
col35 datetimeoffset NULL,
col36 datetimeoffset NULL,
col37 [decimal] (25, 6 ) NULL,
col38 [decimal] (25, 6) NULL,
col39 datetimeoffset NULL,
col40 [int] NULL,
col41 nvarchar NULL,
col42 [smallint] NULL, < br> col43 [smallint] NULL,
col44 [decimal] (25, 6) NULL,
col45 [decimal] (25, 6) NULL,
col46 [decimal] ] (25, 6) NULL,
col47 [decimal] (25, 6) NULL,
col48 [decimal] (25, 6) NULL,
col49 datetimeoffset NULL,
col50 [decimal] (25, 6) NULL,
col51 [decimal] (25, 6) NULL,
col52 [decimal] (25, 6) NULL,
col53 [decimal] (25, 6) NULL, < br> col54 [десятичный] (25, 6) NULL,
col55 [десятичный] (25, 6) NULL,
col56 datetimeoffset NULL,
col57 [десятичный] (25, 6) NULL,
col58 [десятичный] (25, 6) NULL,
col59 [десятичный] (25, 6) NULL,
col60 [десятичный] (25, 6) NULL,
col61 [десятичный] (25, 6) NULL,
col62 [десятичный] (25, 6) NULL,
col63 datetimeoffset NULL,
col64 [десятичный] (25, 6) NULL,
col65 [десятичный] (25, 6 ) NULL,
col66 [десятичный] (25, 6) NULL,
col67 [десятичный] (25, 6) NULL,
col68 [десятичный] (2 5, 6) NULL,
col69 [десятичный] (25, 6) NULL,
col70 datetimeoffset NULL,
col71 [десятичный] (25, 6) NULL,
col72 nvarchar NULL,
col73 nvarchar NULL,
col74 datetimeoffset NULL,
col75 datetimeoffset NULL,
col76 datetimeoffset NULL,
col77 datetimeoffset NULL,
col78 datetimeoffset NULL,
col79 nvarchar NULL,
col80 nvarchar NULL,
col81 nvarchar NULL,
col82 nvarchar NULL,
col83 nvarchar NULL,
col84 nvarchar NULL,
col85 nvarchar NULL,
col86 nvarchar NULL,
col87 nvarchar NULL,
col88 nvarchar NULL,
col89 [бит] NULL,
col90 nvarchar NULL,
col91 nvarchar NULL,
col92 datetimeoffset NULL,
col93 [десятичный] (25, 6) NULL,
col94 nvarchar NULL,
col95 nvarchar NULL,
col96 [десятичный] (25, 6) NULL,
col97 [десятичный] (25, 6) NULL,
col98 [десятичный ] (25, 6) NULL,
col99 [decimal] (25, 6) NULL,
col100 [decimal] (25, 6) NULL,
col101 datetimeoffset NULL,
col102 nvarchar NULL,
col103 nvarchar NULL,
col104 nvarchar NULL,
col105 nvarchar NULL,
col106 nvarchar NULL,
col107 datetimeoffset NULL,
col108 datetimeoffset NULL,
col109 varchar NULL
)
С
(
РАСПРЕДЕЛЕНИЕ = ROUND_ROBIN, HEAP
) - person wBob; 15.11.2016