Ошибка вставки в Vertica с кодом ОШИБКИ 4534 при запуске из RStudio

Question

Я выполняю запрос на вставку в Vertica DB, и он работает нормально, когда запускается из клиента SQL (SQuirrel). Но когда я пытаюсь вызвать тот же запрос из RStudio, он возвращает следующую ошибку:

Ошибка в .local (conn, Statement, ...): выполнить запрос на обновление JDBC ошибка в dbSendUpdate ([Vertica] ОШИБКА VJDBC: получение по v_default_node0005: Не удалось получить сообщение от v_default_node0008 [])

SQL-запрос выглядит примерно так:

insert into SCHEMA1.TEMP_NEW(
       SELECT C.PROGRAM_GROUP_ID,
              C.POPULATION_ID,
              C.PROGRAM_ID,
              C.FULLY_QUALIFIED_NAME,
              C.STATE,
              C.DATA_POINT_TYPE,
              C.SOURCE_TYPE,
              B.SOURCE_DATA_PARTITION_ID AS DATA_PARTITION_ID,
              C.PRIMARY_CODE_PRIMARY_DISPLAY,
              C.PRIMARY_CODE_ID,
              C.PRIMARY_CODING_SYSTEM_ID,
              C.PRIMARY_CODE_RAW_CODE_DISPLAY,
              C.PRIMARY_CODE_RAW_CODE_ID,
              C.PRIMARY_CODE_RAW_CODING_SYSTEM_ID,
              (C.COMPONENT_QUALIFIED_NAME)||('/2') AS SPLIT_PART,
              Count(*) AS RECORD_COUNT 
       from (SELECT DPL.PROGRAM_GROUP_ID,
                    DPL.POPULATION_ID,
                    DPL.PROGRAM_ID,
                    DPL.FULLY_QUALIFIED_NAME,
                   'MET' AS STATE,
                    DPL.DATA_POINT_TYPE,
                    DPL.IDENTIFIER_SOURCE_TYPE AS SOURCE_TYPE,
                    DPL.IDENTIFIER_SOURCE_DATA_PARTITION_ID AS DATA_PARTITION_ID,
                    DPL.PRIMARY_CODE_PRIMARY_DISPLAY,
                    DPL.PRIMARY_CODE_ID,
                    DPL.PRIMARY_CODING_SYSTEM_ID,
                    DPL.PRIMARY_CODE_RAW_CODE_DISPLAY,
                    DPL.PRIMARY_CODE_RAW_CODE_ID,
                    DPL.PRIMARY_CODE_RAW_CODING_SYSTEM_ID,
                    DPL.supporting_data_point_lite_id,
                    DPL.COMPONENT_QUALIFIED_NAME,
                    COUNT(*) AS RECORD_COUNT                           
                    FROM SCHEMA2.TABLE1 DPL
                    WHERE DPL.DATA_POINT_TYPE <> 'PREFERRED_DEMOGRAPHICS'
                    AND DPL.DATA_POINT_TYPE <> 'PERSON_DEMOGRAPHICS'
                    AND DPL.DATA_POINT_TYPE <> 'CALCULATED_RISK_SCORE'
                    AND DPL.DATA_POINT_TYPE <> '_NOT_RECOGNIZED'
                    AND DPL.POPULATION_ID NOT ILIKE '%ARCHIVE%'
                    AND DPL.POPULATION_ID NOT ILIKE '%SNAPSHOT%'
                    AND DPL.PROGRAM_GROUP_ID = '<PROGRAM_GROUP_ID>'
                    AND PROGRAM_GROUP_ID IS NOT NULL
                    AND DPL.IDENTIFIER_SOURCE_DATA_PARTITION_ID IS NULL
                    AND DPL.PRIMARY_CODE_RAW_CODE_ID IS NOT NULL
                    AND DPL.PRIMARY_CODE_ID IS NOT NULL
                    AND EXISTS (SELECT 1
                                FROM SCHEMA2.TABLE2 MO
                                WHERE MO.STATE = 'MET'
                                AND MO.POPULATION_ID NOT ILIKE '%ARCHIVE%'
                                AND MO.POPULATION_ID NOT ILIKE '%SNAPSHOT%'
                                AND DPL.PROGRAM_GROUP_ID = MO.PROGRAM_GROUP_ID
                                AND DPL.PROGRAM_ID = MO.PROGRAM_ID
                                AND DPL.FULLY_QUALIFIED_NAME = MO.FULLY_QUALIFIED_NAME
                                AND DPL.OUTCOME_SEQUENCE = MO.MEASURE_OUTCOME_SEQ
                                AND MO.PROGRAM_GROUP_ID = '<PROGRAM_GROUP_ID>')
             GROUP BY 1,
                      2,
                      3,
                      4,
                      5,
                      6,
                      7,
                      8,
                      9,
                      10,
                      11,
                      12,
                      13,
                      14,
                      15,
                      16) AS C
       Left Join            

             (SELECT DISTINCT SOURCE_DATA_PARTITION_ID,
                              supporting_data_point_lite_id  
              FROM SCHEMA2.TABLE3 DPI
              where DPI.SOURCE_DATA_PARTITION_ID is not null
              AND EXISTS (SELECT 1
                          FROM (SELECT DPL.supporting_data_point_lite_id 
                                FROM SCHEMA2.TABLE1 DPL
                                WHERE DPL.DATA_POINT_TYPE <> 'PREFERRED_DEMOGRAPHICS'
                                AND DPL.DATA_POINT_TYPE <> 'PERSON_DEMOGRAPHICS'
                                AND DPL.DATA_POINT_TYPE <> 'CALCULATED_RISK_SCORE'
                                AND DPL.DATA_POINT_TYPE <> '_NOT_RECOGNIZED'
                                AND DPL.POPULATION_ID NOT ILIKE '%ARCHIVE%'
                                AND DPL.POPULATION_ID NOT ILIKE '%SNAPSHOT%'
                                AND DPL.PROGRAM_GROUP_ID = '<PROGRAM_GROUP_ID>'
                                AND PROGRAM_GROUP_ID IS NOT NULL
                                AND DPL.IDENTIFIER_SOURCE_DATA_PARTITION_ID IS NULL
                                AND DPL.PRIMARY_CODE_RAW_CODE_ID IS NOT NULL
                                AND DPL.PRIMARY_CODE_ID IS NOT NULL
                                AND EXISTS (SELECT 1
                                            FROM SCHEMA2.TABLE2 MO
                                            WHERE MO.STATE = 'MET'
                                            AND MO.POPULATION_ID NOT ILIKE '%ARCHIVE%'
                                            AND MO.POPULATION_ID NOT ILIKE '%SNAPSHOT%'
                                            AND DPL.PROGRAM_GROUP_ID = MO.PROGRAM_GROUP_ID
                                            AND DPL.PROGRAM_ID = MO.PROGRAM_ID
                                            AND DPL.FULLY_QUALIFIED_NAME = MO.FULLY_QUALIFIED_NAME
                                            AND DPL.OUTCOME_SEQUENCE = MO.MEASURE_OUTCOME_SEQ
                                            AND MO.PROGRAM_GROUP_ID = '<PROGRAM_GROUP_ID>')) SDP                                       
                          WHERE DPI.supporting_data_point_lite_id = SDP.supporting_data_point_lite_id)) AS B 
       on C.supporting_data_point_lite_id = B.supporting_data_point_lite_id 
       group by 1,
                2,
                3,
                4,
                5,
                6,
                7,
                8,
                9,
                10,
                11,
                12,
                13,
                14,
                15)  

Заменены только имя схемы и имена таблиц. Все остальные детали такие же.

Может кто-нибудь помочь мне исправить ошибку.

Answer 1

Эта ошибка означает, что некоторые связи между узлами, которые произошли во время обработки вашего запроса, по какой-то причине потерпели неудачу.

Существует множество возможных причин, по которым это может произойти.Иногда это может быть вызвано плохой сетью или другими проблемами среды.Если v_default_node0008 был отключен, например, во время выполнения этого запроса, вы можете увидеть это сообщение.В других случаях это может быть признаком ошибки Vertica, и в этом случае вам придется обратиться в службу поддержки и / или к администратору.

Обычно при выполнении плана запроса поток управления происходит изснизу вверх.На самых низких уровнях плана различные сканирования считываются из проекций, и, когда нет данных для подачи операторам выше сканирования, они останавливаются, что приводит к остановке соседних операторов до тех пор, пока, в конечном счете, не станет корневым оператором.останавливается и запрос завершается.

Иногда возникает необходимость завершить запрос сверху вниз.Когда у вас есть много узлов, каждый из которых передает данные между несколькими потоками для обслуживания вашего запроса, для Vertica может быть сложно детализировать все атомарно.Если поток, отправляющий данные, останавливается до того, как поток, получающий данные, ожидал этого (поскольку получатель еще не осознал, что план еще не остановлен), он может записать это сообщение об ошибке.Обычно, когда это происходит, это безобидно;вы увидите это в vertica.log, но он не доходит до приложения.Если один из них попадает в приложение, то это, вероятно, ошибка Vertica.

Так когда же это может произойти?

Один из распространенных сценариев - когда у вас есть предложение LIMIT.Разные сканы, производящие строки в разных узлах, не могут координировать напрямую, поэтому они должны быть указаны операторами, находящимися выше в плане, когда будет достигнут предел.

Это также происходит, когда запрос отменяется.Отмена может произойти по многим причинам - по запросу приложения, из dba, выполняющей interrupt_statement по вашему запросу, или через политику пула ресурсов.Например, если вы превысили RUNTIMECAP для своего пула ресурсов, запрос автоматически отменяется, если он превышает настроенный порог времени выполнения.

Могут быть и другие, но это наиболее распространенные случаи.Не всегда будет очевидно, что с вами происходят ограничения или отмены.Запрос может быть переписан так, чтобы включать ограничение на разных этапах, и политика приложения и / или администратора базы данных может влиять на вещи под прикрытием.

Хотя это не решит вашу проблему напрямую, мы надеемся, что она даст вам дополнительный контекст и идеи для дальнейшего устранения неполадок.Вероятно, проблема будет очень специфичной для вашего варианта использования, среды и данных и может быть ошибкой.Если вы не можете добиться прогресса, я бы посоветовал обратиться в службу поддержки Vertica, поскольку они будут более подготовлены, чтобы помочь вам разобраться в этом дальше.