Ошибка при выборе представления расчета через переменные

Я столкнулся с одной интересной проблемой при чтении из представления расчета через переменные... код выглядит следующим образом:

do begin
declare lv_ww nvarchar(6);
declare lv_quarter nvarchar(6);

select "WORKWEEK","QUARTER" INTO lv_ww,lv_quarter from "ABC"."TABLE1";

select count(*) from "_SYS_BIC"."CID" (PLACEHOLDER."IP_SNAPSHOTWW" => :lv_ww,PLACEHOLDER."IP_QUARTER" => :lv_quarter);
end;

Я получаю сообщение об ошибке хранилища столбца, ошибке таблицы поиска, сбое оператора плана в строке выбора счетчика (*). так что в основном проблема с памятью, потому что она занимает более 15 ГБ памяти.

Теперь, когда я жестко закодирую значения для lv_ww = '202114' и lv_quarter = '2021Q2'

do begin
declare lv_ww nvarchar(6) default '202114';
declare lv_quarter nvarchar(6) default '2021Q2';

select count(*) from "_SYS_BIC"."CID" (PLACEHOLDER."IP_SNAPSHOTWW" => :lv_ww,PLACEHOLDER."IP_QUARTER" => :lv_quarter);
end;

Он отлично работает и занимает всего 0,012 ГБ.

Примечание. lv_ww и lv_quarter при расчете из TABLE1 прекрасно подходят и дают нам значения как (lv_ww = 202114 и lv_quarter = 2021Q2)

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


hana hana-sql-script hana-studio
person Saurav    schedule 10.04.2021    source источник
comment
Никаких решений, это сильно зависит от дизайна вашего представления. Вам нужно использовать PlanViz, чтобы увидеть точные параметры, переданные в представление расчета, и проверить, применяются ли они в соответствующем месте и с переданными значениями. В HANA Studio: правая кнопка мыши -> Объяснить -> Визуализировать. Затем проверьте, фильтруются ли узлы, как вы ожидаете.   -  person astentx    schedule 10.04.2021

Ответы (1)


arrow_upward
0
arrow_downward

Тот же ответ, который я дал здесь:

Хорошо, я бы рискнул и сказал: разное время выполнения/память, вероятно, связано с разными планами выполнения. А поскольку разница между операторами заключается в том, что значение выбора НЕ ИЗВЕСТНО во время компиляции запроса в первом случае, но ИЗВЕСТНО в другом случае, это, вероятно, причина для разных планов выполнения.

Вы можете проверить эту теорию!

Одним из способов решения этой проблемы может быть использование функции SQLScript BIND_AS_VALUE (https://help.sap.com/viewer/de2486ee947e43e684d39702027f8a94/2.0.05/en-US/0b2958ee0426496f9c084c92b14993f1.html)

person Lars Br.    schedule 10.04.2021