Доступ к DB2 через StarSQL - Эффективность.Выходные параметры или выберите запрос

Question

Я работаю над кодом, который запрашивает старую базу данных DB2, работающую на старом добром MainFrame.Запрос должен быть написан на StarSQL Цель этого - радикально сократить использование MIP текущего запроса, который передается через Command.Text.

Тем, кто неЗнайте, вы платите (много) на основе загрузки ЦП (MIP) на мэйнфреймах, поэтому вы хотите, чтобы все работало как можно более эффективно.Вы на самом деле не хотите говорить «Select * From TableA» и передавать это как CommandType.Text в базу данных, потому что для этого потребуется скомпилировать этот оператор, а затем вернуть результаты.Вам нужно сохранить это как процедуру (которая уже скомпилирована) и выделить * для нужных столбцов.

Итак, мой вопрос.Я не могу ответить на этот вопрос сам, потому что наш гуру из MainFrame в отпуске ...

У меня есть процедура, которая возвращает ~ 30 столбцов.Было бы более эффективно возвращать их через запрос Select или возвращая их в качестве выходных параметров.Это через хранимую процедуру.

Меня не беспокоит длина кода C #, а эффективность этого взорванного мэйнфрейма.

Мне нужно принять во внимание такие вещи, как:

SELECT PHNS.CLNT_INTERNL_KY as CLNT_INTRNL_KY

Использует дополнительное использование ЦП для применения этого имени столбца к этому столбцу, но будет ли эффективнее сохранить его в качестве выходного параметраиспользуя курсоры?

Если вам нужна какая-либо другая информация, дайте мне знать.

Приветствия,

(Там может быть тег StarSQL на тегах, но, увы, яне 1500 баллов ...)

Answer 1

Многие API запросов не разрешают использовать хранимые процедуры, но если у вас есть эта опция, использование хранимой процедуры может сэкономить некоторое время процессора, анализируя и оптимизируя запрос один раз во время компиляции, а не во время каждого выполнения. Если нет, вы все равно можете извлечь выгоду из кэширования, которое имеет место для динамических операторов SQL. Планы доступа для динамических операторов временно хранятся в кэше пакетов, поэтому, если один и тот же побайтовый идентификатор (включая маркеры параметров и литеральные значения) встречается достаточно скоро, DB2 будет использовать план доступа из кэша пакетов вместо оптимизировать его с нуля снова и снова.

Использование хранимых процедур может сэкономить значительное количество времени компиляции для операторов, которые выполняются очень часто с различными литеральными значениями. В тех случаях, когда входные параметры являются необязательными или могут значительно различаться (например, гибкий поиск), хранимая процедура может создать нежелательный план доступа во время компиляции, поскольку она не знает, какие параметры будут заполнены во время выполнения. В этих ситуациях хранимой процедуре может потребоваться повторная оптимизация запроса во время выполнения с помощью политики REOPT, но такой подход, очевидно, отнимает экономию предварительной компиляции.

Я бы порекомендовал использовать функцию DB2 EXPLAIN, чтобы определить реальные затраты на рабочую нагрузку вашего запроса (компиляция, сканирование и сортировка). Если запрос сканирует значительное количество строк, затраты ЦП на оценку каждой строки могут быстро превысить затраты на оптимизацию динамического запроса. Запросы, которые выдают SELECT *, часто не позволяют оптимизатору использовать индекс, который может удовлетворить тот же запрос с меньшим количеством операций ввода-вывода. Предикаты фильтрации и объединения в предложении WHERE (или их отсутствии) также могут помешать оптимизатору выбрать индекс.