Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / IBM DB2, WebSphere, IMS, U2, etc Новый топик    Ответить
 Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
DB2 9.7, W2008R2
Запускаю непосредственно из командного центра сервера.

CREATE PROCEDURE SEDR_CheckContent ()
Specific SEDR_CheckContent
        DYNAMIC RESULT SETS 1
P1: BEGIN
        -- Declare cursor
        DECLARE cursor1 CURSOR WITH RETURN for 

+ Тут сам запрос, но подозреваю, что он не имеет значения
          with Content_pachka_file (pachka_file) as
                        ( Select distinct pachka_file from zanas.sedr_content ),
                        Content_NumberInMassive (MaxNumberInMassive) as
                        ( Select Max(NumberInMassive) from zanas.sedr_content ),
                        Content_KodReg (KodReg) as
                        ( Select distinct KodReg from zanas.sedr_content ),
                        Content_Year (Year) as
                        ( Select distinct Year from zanas.sedr_content ),
                        Content_Month (Month) as
                        ( Select distinct Month from zanas.sedr_content ),
                        short_EDocExchange as
                        (select * from PAYEDOC."EDOCEXCHANGE"
                                where NumInArray<=(select * from Content_NumberInMassive)
                        ),  
                        short_EDocPacket as
                        (select * from PayEDoc.EDocPacket
                                where --( ra in (Select * from Content_KodReg))
                                 ( month in (Select * from Content_Month))
                --                and ( year in (Select * from Content_Year))
                --                and ( Right(SysNumber,5) in (Select * from Content_pachka_file))
                        )
                Select pf.*, sb.npd, sb.snils ,sb.longname, sb.shortname,
                        sb.secondname,  sb.account, sb.sum, sb.numberinmassive
                from
                (Select distinct n.ra,n.year,n.month,RIGHT(n.sysnumber,5) as n_pachka,n.filename,
                                e.rn,e.persnum,m.family,m.name,m.father,e.rschet,e.numinarray
                        FROM short_EDocExchange e
                        left join short_EDocPacket n
                                on n.recid=e.packetid
                        left join  PAYSUM."RECIPIENT" m
                                on m.man_id=e.id and m.info_type=1000)  pf
                Left join zanas.sedr_content sb
                        on n_pachka=sb.pachka_file and pf.numinarray=sb.numberinmassive
                                and pf.ra=sb.kodreg and sb.year=pf.year and sb.month=pf.month
                where not sb.account=trim(pf.rschet) or  not trim(pf.rn)=sb.npd; 

        -- Cursor left open for client application
        OPEN cursor1;
END P1


Запускаю сам запрос (то, что под спойлером) - 3 минуты.
call ZANAS. SEDR_CheckContent; - 2 часа с лишним.

Куда копать, дорогая редакция?
17 июл 17, 14:30    [20650360]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4615
Честный чайник,

Найдите параметры запроса (pkgschema, pkgname, pkgversion, sectno) по его тексту в результатах запроса:
select s.pkgschema, s.pkgname, p.pkgversion, s.sectno, p.alter_time, s.text
from syscat.routines r
join syscat.routinedep d on d.btype='K' and r.routineschema=d.routineschema and r.specificname=d.specificname
join syscat.statements s on s.pkgschema=d.bschema and s.pkgname=d.bname
join syscat.packages p on s.pkgschema=p.pkgschema and s.pkgname=p.pkgname and s.unique_id=p.unique_id
where r.routineschema='ZANAS' and r.specificname=upper('SEDR_CheckContent');

И получите план запроса в explain таблицы с помощью процедуры EXPLAIN_FROM_CATALOG, подставив туда эти параметры.
Получите планы обоих запросов и прикрепите здась вывод db2exftm для соответствующего плана.
17 июл 17, 16:26    [20650927]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
Mark Barinstein,
Я сделал это, хоть и не сразу вспомнил как.

Кстати, кто-нибудь знает, где есть описание, как db2exftm пользоваться и вообще средствами анализа быстродействия?
"Учебник по наглядному объяснению" как и IBM-овский хелп внятным признать не получается.

К сообщению приложен файл (procedure_query.zip - 14Kb) cкачать
18 июл 17, 12:29    [20653405]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Добрый Э - Эх
Guest
Честный чайник,

Честный чайник,

чем и как мерял время исполнения "запроса" и "процедуры"?
Когда мерил "голый запрос" - уверен, что замерил момент окончания выполнения запроса, а не момент первого фетча и возврата первой порции данных?

З.Ы.
переписать запрос с нуля - не предлагать? на первый взгляд он выглядит не самым лучшим образом.
18 июл 17, 12:42    [20653473]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4615
Честный чайник,

Что непонятного или невнятного в описании db2exfmt?

По планам, что бросается в глаза:
В плане запроса используются индексы, созданные 2017-07-14.
В процедуре самая старшая дата сбора статистики 2017-05-31. Дату связывания пакета вы можете видеть в запросе выше. Есть предположение, что этих индексов не было, когда пакет последний раз пересвязывался, т.е. когда планы перестраивались.

Воспользуйтесь процедурой REBIND_ROUTINE_PACKAGE для этой процедуры и приведите опять план запроса из каталога.
18 июл 17, 14:59    [20654366]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
Mark Barinstein,
Mark Barinstein
По планам, что бросается в глаза:
В плане запроса используются индексы, созданные 2017-07-14.
В процедуре самая старшая дата сбора статистики 2017-05-31. Дату связывания пакета вы можете видеть в запросе выше. Есть предположение, что этих индексов не было, когда пакет последний раз пересвязывался, т.е. когда планы перестраивались.

Дык, запрос-то один и тот же. Что сам по себе, что в процедуре. Т.е., похоже, что изменились какие-то настройки db2, в результате чего пакет пересвязываться перестал и эти безобразия возникли.
Процедура с запросом работала полгода нормально. А на днях стала тормозить.
Я полез смотреть и выяснилось, что запрос извлечённый из процедуры так нормально и работает, а процедура выделывается.
Индексы 14 июля я насоздавал, в основном, на всякий случай, они для меньшей стороны джойна и, по идее, влияют не сильно. Но вот сам факт, что в одном случае они используются, а в другом нет, безусловно, важен. Из индексов, которые могут существенно повлиять новый только IDX_..._INFO_TYPE.
Mark Barinstein
Воспользуйтесь процедурой REBIND_ROUTINE_PACKAGE для этой процедуры и приведите опять план запроса из каталога.

Заработало. Ну, т.е., скорость после ребинда стала нормальная, чего пишет в разъяснении попозже стану пытаться читать.

Спасибо! Но есть, вопрос: И чего это у нас такое могло настроиться, что прекратило ребиндиться? Я, естественно, ничего не делал - тупо не умею. Но комплекс рассылается головной организацией и регулярно обновляется (иногда не 1 раз в неделю). Видимо, наши супер-разработчики чего-то подправили после 31го мая...
Mark Barinstein
Что непонятного или невнятного в описании db2exfmt?

Ну возьмём описание прямо из knowledge center (тут) :
+ db2exfmt
db2exfmt - Explain table format command

You use the db2exfmt tool to format the contents of the EXPLAIN tables. This tool is located in the misc subdirectory of the instance sqllib directory. This tool uses the statistics from the EXPLAIN snapshot, if the snapshot is available.
Authorization

To use the tool, you require read access to the explain tables being formatted.
Command syntax

Read syntax diagramSkip visual syntax diagram
>>-db2exfmt--+-----+--+-------------+--+-------------+---------->
'- -1-' '- -d--dbname-' '- -e--schema-'

>--+--------+--+---------------------------+--+-----+----------->
'- -f--O-' | .-----------. | '- -l-'
| V | |
'- -g--+---+----+-------+-+-'
'-x-' +-O-----+
+-I-----+
+-C-----+
'-+-T-+-'
'-F-'

.- -t-.
>--+-----------+--+--------------+--+-------------+--+-----+---->
'- -n--name-' '- -o--outfile-' '- -s--schema-'

>--+-----------------------+--+----------------+---------------->
'- -u--userID--password-' '- -w--timestamp-'

>--+--------------+--+--------------+--+-----+-----------------><
'- -#--sectnbr-' '- -v--srcvers-' '- -h-'

Command parameters

db2exfmt
If no options are specified, then the command enters interactive mode and you will be prompted to make entries.
-1
Use defaults -e % -n % -s % -v % -w -1 -# 0

If Explain schema is not supplied, the contents of the environment variable $USER, or $USERNAME will be used as a default. If this variable is not found, the user will be prompted for an Explain schema.
-d dbname
Name of the database containing packages.
-e schema
Explain table SQL schema.
-f
Formatting flags. In this release, the only supported value is O (operator summary).
-g
Graph plan.

x
Turn OFF options (default is to turn them ON).

If only -g is specified, a graph, followed by formatted information for all of the tables, is generated. Otherwise, any combination of the following valid values can be specified:

O
Generate a graph only. Do not format the table contents.
T
Include total cost under each operator in the graph.
F
Include first tuple cost in graph.
I
Include I/O cost under each operator in the graph.
C
Include the expected output cardinality (number of tuples) of each operator in the graph.

Any combination of these options is allowed, except F and T, which are mutually exclusive.
-l
Respect case when processing package names.
-n name
Name of the source of the explain request (SOURCE_NAME).
-s schema
SQL schema or qualifier of the source of the explain request (SOURCE_SCHEMA).
-o outfile
Output file name.
-t
Direct the output to the terminal.
-u userID password
When connecting to a database, use the provided user ID and password.

Both the user ID and password must be valid according to naming conventions and be recognized by the database.
-w timestamp
Explain time stamp. Specify -1 to obtain the latest explain request.
-# sectnbr
Section number in the source. To request all sections, specify zero.
-v srcvers
Source version of source of Explain request (default %)
-h
Display help information. When this option is specified, all other options are ignored, and only the help information is displayed.

Usage notes

You will be prompted for any parameter values that are not supplied, or that are incompletely specified, except in the case of the -h and the -l options.

If an explain table SQL schema is not provided, the value of the environment variable USER is used as the default. If this variable is not found, the user is prompted for an explain table SQL schema.

Source name, source SQL schema, and explain time stamp can be supplied in LIKE predicate form, which allows the percent sign (%) and the underscore (_) to be used as pattern matching characters to select multiple sources with one invocation. For the latest explained statement, the explain time can be specified as -1.

If -o is specified without a file name, and -t is not specified, the user is prompted for a file name (the default name is db2exfmt.out). If neither -o nor -t is specified, the user is prompted for a file name (the default option is terminal output). If -o and -t are both specified, the output is directed to the terminal.


Смотрим, например про опцию '-1':
-1
Use defaults -e % -n % -s % -v % -w -1 -# 0

If Explain schema is not supplied, the contents of the environment variable $USER, or $USERNAME will be used as a default. If this variable is not found, the user will be prompted for an Explain schema.
-d dbname

ОК, я понял, что рекомендовано использовать значения по умолчанию и что будет, если схему не указать, а вот это "-e % -n % -s % -v % -w -1 -# 0" о чём, вообще? Каждый интеллигентный человек обязан знать, что за умолчательные значения подразумеваются под "-e % -n % -s % -v % -w -1 -# 0" ? Про конкретный "-1" можно прочитать ниже в usage notes, а остальные при чём? Я догадываюсь, что это про другие опции, но почему тут? Где какие-то общие слова о том, как данная утилита вписывается в методику добычи данных? Я понимаю, что есть ссылки в related concept, а там ещё скидки и ещё, но везде описаны конкретные свойства рассматриваемых предметов, а не их взаимодействие с другими.
В результате, как запускать db2exfmt -d <база> -1 -o <файл куда> узнал из вашего сообщения здесь на форуме. За что вам большое спасибо, а IBM - фи. ;)
В "учебнике" по "наглядному объяснению" - такая же фигня, в первом же уроке указание воспользоваться опцией EXPLSNAP о которой можно прочитать в Administrative API Reference. Т.е., вместо объяснений призыв идти читать хелп. Кстати, "по опции EXPLSNAP" _ЧЕГО_ никто указать не потрудился. Учебники обычно как-то по-другому устроены.

IBM-овские хелпы традиционно написаны людьми которые всё понимают для людей которые тоже всё понимают, но немного забыли. По такому хелпу можно вспомнить, чего забыл, но крайне сложно узнать что-то новое.
19 июл 17, 12:03    [20657010]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
Добрый Э - Эх
чем и как мерял время исполнения "запроса" и "процедуры"?
Когда мерил "голый запрос" - уверен, что замерил момент окончания выполнения запроса, а не момент первого фетча и возврата первой порции данных?

Вот так мерял:

SELECT Current TimeStamp from sysibm.sysdummy1;
call ZANAS.SEDR_CheckContent;
SELECT Current TimeStamp from sysibm.sysdummy1;

+ результат
------------------------------ Введенные команды ------------------------------
SELECT Current TimeStamp from sysibm.sysdummy1;
call ZANAS.SEDR_CheckContent;
SELECT Current TimeStamp from sysibm.sysdummy1;
------------------------------------------------------------------------------
SELECT Current TimeStamp from sysibm.sysdummy1

1
--------------------------
2017-07-19-13.02.18.292000

1 записей выбрано.


call ZANAS.SEDR_CheckContent


Набор результатов 1
--------------

RA YEAR MONTH N_PACHKA ....
----------- ------ ------ ------------------------------ ....
1 2017 7 18461 P.......34.XML 193835 012-112-712 12 Иванова...

1 записей выбрано.

Статус возврата = 0

SELECT Current TimeStamp from sysibm.sysdummy1

1
--------------------------
2017-07-19-13.04.31.346000

1 записей выбрано.

Если я правильно понимаю политику партии, это возврат первой порции.
Но там данных мало - возвращает только ошибки, в норме результат пустой.
Для тестирования я сам одну запись попортил.

Добрый Э - Эх
переписать запрос с нуля - не предлагать? на первый взгляд он выглядит не самым лучшим образом.

Запрос, безусловно, переписать можно. Если бы он делался на сторону, то просто обязательно переписать. Но пока он за 3 минуты справляется пусть в таком виде остаётся - удобнее корректировать и тестировать, по каким полям выбирать.
Фишка же не в кривости запроса, а в том, что он как запрос работает нормально, а из процедуры работать перестал.
Именно в таком кривом виде я его в декабре внедрил и он до недавнего времени вполне работал. А на днях стал дико тормозить. Причём, только из процедуры тормозить.
19 июл 17, 12:19    [20657069]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
Файл с расшифровкой забыл приложить.

К сообщению приложен файл (procedure2.txt - 37Kb) cкачать
19 июл 17, 13:02    [20657328]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4615
Честный чайник
Заработало. Ну, т.е., скорость после ребинда стала нормальная, чего пишет в разъяснении попозже стану пытаться читать.

Спасибо! Но есть, вопрос: И чего это у нас такое могло настроиться, что прекратило ребиндиться? Я, естественно, ничего не делал - тупо не умею. Но комплекс рассылается головной организацией и регулярно обновляется (иногда не 1 раз в неделю). Видимо, наши супер-разработчики чего-то подправили после 31го мая...

Если администраторы/разработчики не знают следующего, то это очень плохо.

Статические планы запросов, таких как в вашем примере, никогда сами не перестраиваются после сбора статистики или после добавления индексов. В этом отличие статических запросов от динамических.
Администраторы должны сами за этим следить, надо или не надо перекомпилировть статические планы после таких операций.
20 июл 17, 15:25    [20661865]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Mark Barinstein
Member

Откуда: Москва
Сообщений: 4615
Честный чайник
ОК, я понял, что рекомендовано использовать значения по умолчанию и что будет, если схему не указать, а вот это "-e % -n % -s % -v % -w -1 -# 0" о чём, вообще? Каждый интеллигентный человек обязан знать, что за умолчательные значения подразумеваются под "-e % -n % -s % -v % -w -1 -# 0" ? Про конкретный "-1" можно прочитать ниже в usage notes, а остальные при чём? Я догадываюсь, что это про другие опции, но почему тут? Где какие-то общие слова о том, как данная утилита вписывается в методику добычи данных? ...

db2exfmt это всего лишь утилита, которая позволяет достать готовый(ые) план запроса(ов) из explain таблиц. Каждый интеллигентный человек должен понимать, как туда данные попадают. Для этого такой человек по-хорошему должен прочитать про Explain facility.

Вкратце об этом, если лень читать.
Для того, чтоб получать планы запросов, надо (ну, db2expln может и без них, но это исключение) создать комплект EXPLAIN таблиц. Таких комплектов в базе может быть несколько, по одному в схеме. В один из этих комплектов таблиц и будет падать очень подробная информация о плане, каким бы образом вы его не запросили (из GUI, командной строки, автоматически, при вызове одной из процедур, и т.д.). После этого вы можене либо в графическом, либо в текстовом виде отформатировать эти планы. Можене напрямую обращаться к этим таблицам запросами (иногда это удобно).
В каждом комплекте таблиц может быть несколько планов, план однозначно идентифицируется полями:
EXPLAIN_REQUESTER, EXPLAIN_TIME, SOURCE_NAME, SOURCE_SCHEMA, SOURCE_VERSION
Если вы посмотрите на описание ключей db2exfmt, то вы обнаружите, что они для того, чтоб указать именно нужный план по этим параметрам в нужном наборе (по схеме) таблиц, если надо.
Удобный ключ -1 - для наиболее часто используемого случая, когда я хочу получить самый свежий из полученных планов.

Вот и всё.
20 июл 17, 15:42    [20661928]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
CawaSPb
Member

Откуда: Питер/Москва/Wroclaw
Сообщений: 763
Абалдеть! Марка достали :)
20 июл 17, 18:36    [20662554]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
Mark Barinstein
Вкратце об этом, если лень читать.

Читать, естественно, лень. Всем. Это нормально. Все хотят читать поменьше и искать, что нужно читать, побыстрее, а знаний за потраченное время получать побольше. И как-то так исторически сложилось, что в IBM-овских источниках находить информацию быстро не очень получается. Я вычитал всё, что вы в паре абзацев написали, но медленно. Когда вы отвечали на конкретный вопрос, вы объяснили гораздо лучше и компактнее, чем в документации. Т.е., на выискивание я потратил гораздо больше времени, чем если бы сначала прочитал ваше изложение для ленивых. И у меня такое ощущение, что люди, которые в IBM документацию пишут, они не думают о том, какие вопросы интересуют "неграмотного" читателя, они какие-то свои стандарты явно соблюдают, но эти стандарты не о том, как хорошо объяснить тому, кому объяснения реально нужны. И проверяют документацию, судя по всему, не на чайниках. Т.е., вот лично у меня такое ощущение, что никому даже в голову не приходит на чайниках проверять. А было бы полезно. А то чайник потыкается-потыкается, да и уйдёт к конкурентам.
21 июл 17, 06:50    [20663283]     Ответить | Цитировать Сообщить модератору
 Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
Честный чайник
Member

Откуда:
Сообщений: 75
Mark Barinstein
Статические планы запросов, таких как в вашем примере, никогда сами не перестраиваются после сбора статистики или после добавления индексов. В этом отличие статических запросов от динамических.
Администраторы должны сами за этим следить, надо или не надо перекомпилировть статические планы после таких операций.

Но что-то же произошло, после чего стал медленно работать запрос из процедуры.
Ещё раз поэтапно изложу:
  • В декабре я запрос до приемлемой скорости довёл, в процедуру ставил, морду нарисовал, которая его вызывает.
  • В районе 31 мая никто ничего специально не делал. "В процедуре самая старшая дата сбора статистики 2017-05-31.", но я никак на это не влиял, процедуру никто не трогал. Статистику никто не собирал.
  • 12-13 июня (за месяц до косяка, но после 31 мая) всё прошло как обычно, т.е. запрос из процедуры работал нормально.
  • 12-13 июля начали проверять реестры, соответственно, применять процедуру, и вот тут внезапно выяснилось, что она дико тормозит.
    14 го Я полез смотреть, что за безобразие, и, на всякий случай, прикрутил индексы на всё подряд оставшееся. Т.е., индексы от 14 июля на косяк никак не повлияли, они - результат попыток поправить. Да, они ускорили процесс, но когда их не было, запускаемый вручную запрос уже работал гораздо быстрее чем он же, но из процедуры. Точнее, из процедуры тот же самый запрос который благополучно функционировал полгода без изменений, стал выполняться гораздо медленнее. Без каких-либо осознанных действий с нашей стороны.
  • 21 июл 17, 07:14    [20663298]     Ответить | Цитировать Сообщить модератору
     Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
    Mark Barinstein
    Member

    Откуда: Москва
    Сообщений: 4615
    Честный чайник,

    Что было в p.alter_time от запроса выше?
    Не сейчас, а тогда, когда было плохо.
    21 июл 17, 08:24    [20663363]     Ответить | Цитировать Сообщить модератору
     Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
    Честный чайник
    Member

    Откуда:
    Сообщений: 75
    Mark Barinstein
    Что было в p.alter_time от запроса выше?
    Не сейчас, а тогда, когда было плохо.

    Дык, не посмотрел сразу, а теперь как?
    21 июл 17, 12:53    [20664491]     Ответить | Цитировать Сообщить модератору
     Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
    Mark Barinstein
    Member

    Откуда: Москва
    Сообщений: 4615
    Честный чайник
    Дык, не посмотрел сразу, а теперь как?
    Теперь никак без восстановления базы и наката ее по логам до предположительной точки во времени, когда перекомпиляция пакета могла произойти.

    Если статический план, который не перекомпилировали, неожиданно начинает давать сильно разное время выполнения, то это может объясняться либо блокировками от прарлельных пользователей, либо сиотно изменившимся распределением данных.
    Если не происходило ни того, ни другого, то, скорее всего, в базе были сделаны изменения, которые заставили план перекомпилироваться.
    Это может быть, например, изменение в структуре таблицы, удаление индексов, которые использовались планом. При перекомпиляции пакета значение этого поля изменяется.
    21 июл 17, 15:01    [20664981]     Ответить | Цитировать Сообщить модератору
     Re: Запрос тормозит, если запускать его из хранимой процедуры.  [new]
    Честный чайник
    Member

    Откуда:
    Сообщений: 75
    Mark Barinstein
    Если статический план, который не перекомпилировали, неожиданно начинает давать сильно разное время выполнения, то это может объясняться либо блокировками от прарлельных пользователей, либо сиотно изменившимся распределением данных.
    Если не происходило ни того, ни другого, то, скорее всего, в базе были сделаны изменения, которые заставили план перекомпилироваться.
    Это может быть, например, изменение в структуре таблицы, удаление индексов, которые использовались планом. При перекомпиляции пакета значение этого поля изменяется.

    Распределение сильно не менялось. Данные накапливаются, но, вроде, достаточно предсказуемо, насколько я себе предметную область представляю. Ну добавились за ещё один месяц - не принципиально. Блокировки от параллельных пользователей должны задевать те таблицы, которые в плане от 31 мая были задействованы, а в текущем варианте нет. Будем посмотреть...

    В первом выложенном плане имеется дата сбора статистики 31 мая. Т.е., ничего такого, что заставило бы план перекомпилироваться с мая не произошло. Т.е., задействованные поля и индексы в таблице не менялись. В июне запрос из процедуры точно работал, в июле - точно нет. А для запроса, исполняемого вручную, соответственно, план делается заново и он что-то такое учёл, чего не учёл для сохранённого плана для процедуры. Т.е., получается, что накопились статистические данные, которые "новый" запрос направили новым путём, а на сохранённый не повлияли, т.к. признаков резких изменений не было?
    24 июл 17, 12:00    [20669271]     Ответить | Цитировать Сообщить модератору
    Все форумы / IBM DB2, WebSphere, IMS, U2, etc Ответить