SQL сервер 2016 R Услуга: sp_execute_external_script возвращает 0x80004005 ошибки

Question

Я запустить некоторый R код после запроса 100M записей и получить следующее сообщение об ошибке после процесса проходит в течение более 6 часов:

Msg 39004, Level 16, State 19, Line 300 
A 'R' script error occurred during execution of 'sp_execute_external_script'  
with HRESULT 0x80004005. 

HRESULT 0x80004005 по-видимому, связан с Windows с подключением, разрешениями или ошибкой «Unspecified».

Я знаю из регистрации в моем R-коде, что процесс никогда не достигает сценария R вообще. Я также знаю, что вся процедура завершается через 4 минуты на меньшее количество записей, например, 1M. Это заставляет меня думать, что это проблема масштабирования или проблема с данными, а не ошибка в моем R-коде. Я не включил код R или полный запрос по причинам собственности.

Однако, я бы ожидал, что ошибка диска или памяти отобразит ошибку памяти 0x80004004, если это так.

Один ключ я заметил в SQL ERRORLOG является следующее:

SQL Server received abort message and abort execution for major error : 18 
and minor error : 42 

Однако время этой строки журнала не совпадает с прерыванием процесса, хотя это происходит после того, как она началась. К сожалению, в Интернете мало что известно о «большой ошибке 18».

SQL Trace при запуске из SSMS показывает, как клиент регистрируется и выходит из системы каждые 6 минут или около того, но я могу только предположить, что это нормальное поведение в режиме keepalive.

продезинфицировать sp_execute_external_script вызов:

 EXEC sp_execute_external_script 
        @language = N'R' 
        , @script = N'#We never get here 
           #returns name of output data file' 
        , @input_data_1 = N'SELECT TOP 100000000 FROM DATA' 
        , @input_data_1_name = N'x' 
        , @output_data_1_name = N'output_file_df' 
        WITH RESULT SETS ((output_file varchar(100) not null)) 

сервера Технические характеристики: 8 ядер 256 GB RAM SQL Server 2016 CTP 3

Любые идеи, предложения или отладочных подсказок было бы весьма признателен!

ОБНОВЛЕНИЕ: Набор уровень_трассировки = 3 в rlauncher.config, чтобы включить более высокий уровень регистрации и повторно запускали процесс. Журнал показывает процесс очистки, который выполнялся, удаляя файлы сеанса, в то время, когда весь процесс завершился с ошибкой через 6,5 часов.

[2016-05-30 01: 35: 34,419] [00002070] [00001EC4] [Информация] SQLSatellite_LaunchSatellite (1, A187BC64-C349-410B-861E-BFDC714C8017, 1, 49232, nullptr) завершено: 00000000

[2016-05-30 01: 35: 34,420] [00002070] [00001EC4] [Info] < SQLSatellite_LaunchSatellite, dllmain.cpp, 223

[2016-05-30 08: 04: 02,443] [00002070] [00001EC4] [Info]> SQLSatellite_LauncherCleanUp, dllmain.cpp, 309

[2016-05-30 08: 04: 07,443] [00002070] [00001EC4] [Предупреждение] сессия A187BC64-C349-410B-861E-BFDC7 14C8017 очистки ждать не удалось с 258 и ошибки 0

[2016-05-30 08: 04: 07,444] [00002070] [00001EC4] [Info] Session (A187BC64-C349-410B-861E-BFDC714C8017) вход 2 выхода файлы

[2016-05-30 08: 04: 07.444] [00002070] [00001EC4] [Warning] TryDeleteSingleFile (C: \ PROGRA ~ 1 \ MICROS ~ 1 \ MSSQL1 ~ 1.MSS \ MSSQL \ EXTENS ~ 1 \ MSSQLSERVER06 \ A187BC64-C349-410B-861E-BFDC714C8017 \ Rscript1878455a2528) не удалось с 32

[2016-05-30 08: 04: 07.445] [00002070] [00001EC4] [Внимание] TryDeleteSingleDirectory (C: \ PROGRA ~ 1 \ MICROS ~ 1 \ MSSQL1 ~ 1.MSS \ MSSQL \ EXTENS ~ 1 \ MSSQLSERVER06 \ A187BC64-C349-410B-861E-BFDC714C8017) не удалось с 32

[2016-05-30 08: 04: 08,446] [00002070] [00001EC4] [Info] сессия A187BC64-C349-410B-861E-BFDC714C8017 удалены из MSSQLSERVER06 пользователя

[2016-05-30 08: 04: 08,447] [00002070] [00001EC4 ] [Информация] SQLSatellite_LauncherCleanUp (A187BC64-C349-410B-861E-BFDC714C8017) завершено: 00000000

Похоже, что единственный способ разрешить мой длительный процесс, чтобы продолжить это: а) Продлить время работы Cleanup ожидания, чтобы задание закончить б) Отключить процесс очистки Работа

Я до сих пор не удалось найти значение, которое устанавливает время ожидания очистки работы в службе MSSQLLaunchpad. Хотя в rlauncher.config существует флаг JOB_CLEANUP_ON_EXIT, установка его в 0 не влияет. Кажется, что служба перезагружает его до 1 при перезапуске.

Опять же, любые предложения или помощь были бы высоко оценены!

Answer 1

По умолчанию SQL Server считывает все данные в R-память в виде кадра данных перед началом выполнения сценария R. Исходя из того факта, что скрипт работает с 1M строками и не может начинаться с 100M строк, это потенциально может быть ошибкой Out of Memory. Для решения проблем с памятью, (кроме увеличения памяти на машине/уменьшении размера данных), вы можете попробовать один из этих решений

1. Увеличения выделения памяти для выполнения процесса R с помощью sys.resource_governor_external_resource_pools настройки max_memory_percent. По умолчанию SQL Server ограничивает выполнение процесса R до 20% памяти.
2. Streaming execution for R script вместо загрузки всех данных в память. Обратите внимание, что этот параметр может использоваться только в случаях, когда вывод сценария R не зависит от чтения или просмотра всего набора строк.

Предупреждения в RLauncher.log об очистке данных произошли после того, как выполнение R-сценария можно безопасно игнорировать и, вероятно, не является основной причиной сбоев, которые вы видите.

Answer 2

Невозможно решить эту проблему в SQL, я просто избегал службы SQL Server Launchpad, которая прерывала обработку и вытаскивала данные из SQL с помощью R RODBC-библиотеки. Притяжение заняло чуть более 3 часов (вместо 6+ с использованием sp_execute_external_procedure).

Это может повлиять на работу службы SQL Launchpad и предполагает, что память не была проблемой.

Answer 3

Попробуйте использовать свой сценарий в RTM для SQL Server 2016. С CTP3 было выполнено множество функциональных и рабочих исправлений.

Для получения дополнительных сведений о том, как получить RTM-запрос SQL Server 2016 SQL Server 2016 is generally available today blogpost.

Answer 4

У меня была почти такая же проблема с RTM-CU1 для SQL Server 2016. Мой запрос завершился с ошибкой 0x80004004 вместо 0x80004005. И он провалился с 10 000 000 записей, но это может быть связано только с 16 ГБ оперативной памятью и/или разными данными.

Я обошел его, используя список полей вместо «*». Даже если в списке полей содержатся все поля из источника данных (довольно сложное представление в моем случае), запрос, содержащий список полей, всегда успешный, тогда как «SELECT TOP x * FROM ...» всегда терпит неудачу для некоторого большого x ,

Answer 5

У меня была аналогичная ошибка (0x80004004), и проблема заключалась в том, что одна из строк в одном из столбцов содержала «очень» специальный символ (я говорю «очень», потому что другие специальные символы не вызывать эту ошибку).

Так что, когда я заменил «Folkel чистый Telefinans» с «Folkel а чистый Telefinans», проблема ушла.

В вашем случае, возможно, хотя бы одно из значений в последних 99M строках содержит что-то вроде этого символа, и вам просто нужно его заменить. Я надеюсь, что Microsoft решит эту проблему в какой-то момент.