Выборка через некоторые вьюшки стали как-то безумно тормозить на ровном месте. Причем -- что важно! -- если взять текст view, и пересоздать с другим именем, то запрос через этот новый view исполняется мгновенно! (Разница -- 10 минут против 0.5 секунды). То есть view идентичен, но имеет другое имя. Мы в ступоре. Что это может быть?

План запроса анализировать нереально (для меня) -- он огромен. Да и по сути два одинаковых по тексту view должны давать одинаковый план. Не дают. Почему???

Немного бэкграунда:

DB2 8.x on AIX.

Есть кучка legacy views. Эти вьюшки используются приложением, коннектящимся к БД как юзер CBB. Схема же используется -- DB2IBBP. Схема CBB выставлена как alias для DB2IBBP.

Во view через раз таблицы то указаны с полной схемой (DB2IBBP.USER), то без схемы (например, просто CONTRACT). Для вторых, понятно, подставляется схема CBB. Поскольку CBB -- alias для DB2IBBP, то идем к тем же самым таблицам всё равно. Собственно, вся байда началась с попыток проставить везде полную схему, и с обнаружения, что новые вью работают во много раз быстрее. Но когда стали разбираться, и убрали квалификацию обратно, то новые вью по-прежнему работают быстро!

Шайтан-арба какая-то...

Mark BarinsteinДа уж... Вы рассказываете о DB2 действительно удивительные вещи:

Ну, ничего удивительного -- я ж всё-таки жабокодер, а не DBA, мне позволительны некоторые пробелы. Однако суть от этого не меняется -- берется текст существующего view, создается его копия с другим именем -- и копия работает в сотни раз быстрее. Any ideas?

Про статистику -- это runstat? Гоняли вчерась. Безрезультатно.

Mark BarinsteinПокажите оба плана запроса

Мне тут вежливо намекнули, что выкладывать план запроса и тем более текст самих view -- есть нарушение NDA, и лучше бы мне этого не делать. Но приглашенный DBA-аналитик ковырял проблему, говорил с IBM, и результат -- это, похоже, баг в оптимизаторе DB2:


During my investigation on slow response time reported by Vlad & Ujwal on SQL query, it has been identified that DB2 view CBB_GLOBALSTATUS is giving better response time when a query is calling a duplicate copy of this view and its dependent views, which is not correct way of doing it. I have discussed this matter with IBM and provided all required material (DB2 instance/database environment info) to IBM LAB. This kind of bug in DB2 is not reported by other users of UDB DB2 V8.1 FP11.

IBM support has created our database in their environment and replicate the problem. They has also tested this under FP14 but results are the same. It seams like that it is DB2 optimizer issue. I have been told by IBM that optimizer issues some time takes a bit longer( about a week) to find out the solution.

Чтобы закрыть тему -- есть такая песня, но by design. Не надо, типа, на одни и те же таблицы слишком много раз ссылаться.

IBM
Hi Om, as discussed, the nested use of the same view in a query causes a "common subexpression" (CSE). DB2 may or may not decide to use the CSE when applying the query predicates to produce the result set, depending on the various rules employed in optimizing the query. CSE's may be computed once and the same result set is used for other references. On the other
hand, DB2 may choose to reference the view separately. DB2 will choose
based on the various Optimizer and Query Rewrite rules. Based on these guidelines, DB2 chose to compute the CSE once for all references in this case. Unfortunately, this fell under an exception case which did not produce desirable results.

A rough guideline to use is if a CSE is referenced by more than 3 times or the total number of references to tables in the FROM clauses of the CSE is greater than 9. The view (or common subexpression, if you will) for this case in question is DB2IBBP.CBB_TO_BE_APPROVED_USER. It is referenced in the query 3 times (1 time directly in the FROM clause, 2 times from the view CBB_TO_BE_APPROVED_CONTRACT via view CBB_GLOBALSTATUS). So this condition is still okay (not more than 3 times).

However, CBB_TO_BE_APPROVED_USER has 14 references to tables. Count all the tables in the FROM clauses of the view definition including the FROM clauses of those subqueries in the output columns. And if any FROM clause references a view, further expand the view to all the tables in that view.
This exceeds the 9 references threshold.

Creating the replica views, DB2IBBP.CBB_TO_BE_APPROVED_USER_new and DB2IBBP.CBB_USER_new, and either changing DB2IBBP.CBB_GLOBALSTATUS view to use the new views or changing the query itself, provided the relief to this situation.

In summary, DB2 is working as designed. However, you can officially submit a redesign of this code component by submitting a Design Change Request
(DCR) with your IBM representative.

Regards,

Kheng M. Wah
<емыл вырезан -- зачем хорошего человека спаммить?>