Недопустимое имя объекта - объект создан системой

Интересно, может ли кто-нибудь просветить меня относительно основной причины таких ошибок Azure SQL DW:

ErrorMsg: [Microsoft] [Драйвер ODBC 11 для SQL Server] [SQL Server] Недопустимое имя объекта «Distribution_8.dbo.Table_f8776198af014a96b157b84ce175aa1f_8»

Я предполагаю, что рассматриваемый объект является базовым хранилищем таблицы в определенном дистрибутиве, но почему Azure SQL DW может оказаться не в состоянии его найти?

Я видел, как это случалось раньше, и оно исчезло примерно через 20 минут без какого-либо вреда, но это довольно неудобно, и я хотел бы понять, почему это происходит.


azure azure-sqldw
person Matt Connolly    schedule 02.02.2016    source источник
comment
Вы находились в процессе масштабирования от одного DWU к другому и продолжали выполнять запросы или загрузки? Я, возможно, видел этот тип ошибки тогда. Если вы можете постоянно воспроизводить эту ошибку, я уверен, что Microsoft хотела бы получить ваше воспроизведение.   -  person GregGalloway    schedule 02.02.2016
comment
Спасибо, Мэтт, за сообщение. Можете ли вы поделиться, если вы были в операции масштабирования (изменить размер или приостановить)?   -  person Matt Usher    schedule 02.02.2016

Ответы (1)


arrow_upward
2
arrow_downward

Эта ошибка предполагает, что хранилище данных SQL находилось в середине процесса перемещения вещей, так что таблица фактически не существовала в том месте, где она должна была быть. Этого никогда не должно произойти, и вы не должны сами вызывать эту ошибку, даже если вы были в процессе изменения размера или паузы, поэтому стоит обратиться в службу поддержки по этому поводу, особенно если вы можете воспроизвести ошибку. Конечно, если бы вы были в процессе одной из этих вещей, я мог бы сказать: «Все ставки сняты», но тем не менее эта ошибка не должна произойти, и вы должны позвонить с кучей подробностей о том, что происходит. когда у вас была ошибка.

person Rob Farley    schedule 02.02.2016
comment
Спасибо за ответы. Это было сразу после операции масштабирования, но не во время нее. Я повышаю целевой уровень обслуживания со 100 DWU до 1000 DWU непосредственно перед запуском ETL, а затем снова снижаю его. Я выполняю масштабирование с помощью T-SQL с двухминутным WAITFOR, выдаваемым сразу после него, чтобы убедиться, что масштабирование завершено, прежде чем я выполню следующий запрос. Если это симптом масштабирования, то нет особых причин не увеличивать этот WAITFOR до 3, 4 или 5 минут, просто чтобы убедиться, что все чисто. - person Matt Connolly; 03.02.2016
comment
@MattConnolly, вы продолжаете использовать этот подход? Я считаю, что масштабирование может составлять 1-15 минут, поэтому я скептически отношусь к тому, что фиксированное время для масштабирования будет работать. Может быть, поспите 1 минуту, проверьте количество строк select * from sys.dm_pdw_nodes, а затем выполните цикл, пока DMV не укажет, что масштабирование завершено? Потом поспать еще несколько минут? Мысли? - person GregGalloway; 10.03.2016
comment
@GregGalloway звучит как хорошая идея, но моя компания перешла на AWS вместо Azure, поэтому сейчас я переношу данные из Azure SQL DW в Redshift и, к сожалению, больше никогда не буду рассматривать эту проблему. - person Matt Connolly; 14.03.2016