День добрый всем.
После перехода на 15.5 столкнулись с таким вот интересным поведением сервера. Иногда происходит слет плана оптимизации процедуры. (бывает на разных процедурах). В результате колво логических чтений может возрасти на 2-3 порядка. Так как таких процедур дергается много - сервер пригружается очень сильно. Достаточно просто перекомпилить ее (правда удается не сразу изза того что она используется) - все возвращается в норму.
Сегодня утром поймали на одной из процедур. Она используется для заполнения локального кеша арма - выгребает изменения справочников. Процедура работает по таблицам справочников и их взаимосвязей. Изменения по этим таблицам идут весьма нечасто. То есть вариант съехавшей статистики из-за большого одномоментного изменения данных в одной из таблиц отпадает.
Привожу примеры.
Вот выборка из мон_дб по съехавшему вызову

Результаты
SPIDInstanceID KPID ServerUserID BatchID SequenceInBatch SQLText 12330111359073684211"exec dbo.Cache_CompanyDebtParams 8196791'2011.09.07 07:42:02.283'"

SPIDInstanceIDKPIDDBIDProcedureIDPlanIDBatchIDContextIDLineNumberCpuTimeWaitTimeMemUsageKBPhysicalReadsLogicalReadsPagesModifiedPacketsSentPacketsReceivedNetworkPacketSizePlansAltered RowsAffectedErrorStatusHashKeySsqlIdProcNestLevelStatementNumberDBNameStartTimeEndTime 12330111359073641850538695249533421100014000005120000011biplane09.09.2011 7:27:17.09009.09.2011 7:27:17.0901233011135907364185053869524953342113000000005120000012biplane09.09.2011 7:27:17.09009.09.2011 7:27:17.09012330111359073641850538695249533421140014000005120000013biplane09.09.2011 7:27:17.09009.09.2011 7:27:17.0901233011135907364185053869524953342112730001880005120000014biplane09.09.2011 7:27:17.09009.09.2011 7:27:17.09312330111359073641850538695249533421129889130380324925080005120300015biplane09.09.2011 7:27:17.09309.09.2011 7:28:46.00612330111359073641850538695249533421158000010005120000016biplane09.09.2011 7:28:46.00609.09.2011 7:28:46.0061233011135907364185053869524953342116200540200405120300017biplane09.09.2011 7:28:46.00609.09.2011 7:28:46.00612330111359073641850538695249533421179000000005120000018biplane09.09.2011 7:28:46.00609.09.2011 7:28:46.006123301113590736400421010052000005120000000biplane09.09.2011 7:27:17.09009.09.2011 7:28:46.010

Затем просто перекомпилировал ее и вызвал опять

SPIDInstanceID KPID ServerUserID BatchID SequenceInBatch SQLText 1218026214800391"exec dbo.Cache_CompanyDebtParams 8196791'2011.09.07 07:42:02.283'"

И
SPIDInstanceIDKPIDDBIDProcedureIDPlanIDBatchIDContextIDLineNumberCpuTimeWaitTimeMemUsageKBPhysicalReadsLogicalReadsPagesModifiedPacketsSentPacketsReceivedNetworkPacketSizePlansAltered RowsAffectedErrorStatusHashKeySsqlIdProcNestLevelStatementNumberDBNameStartTimeEndTime 121802621480041962539094145912916303804753501020480300015biplane09.09.2011 11:01:07.25309.09.2011 11:01:07.416121802621480041962539094145915800002000020480000016biplane09.09.2011 11:01:07.41609.09.2011 11:01:07.4161218026214800419625390941459162005404402020480300017biplane09.09.2011 11:01:07.41609.09.2011 11:01:07.41612180262148004196253909414591790000400020480000018biplane09.09.2011 11:01:07.41609.09.2011 11:01:07.416121802621480040090100520000020480000000biplane09.09.2011 11:01:07.25009.09.2011 11:01:07.42012180262148004196253909414591000140000020480000011biplane09.09.2011 11:01:07.25309.09.2011 11:01:07.2531218026214800419625390941459130000400020480000012biplane09.09.2011 11:01:07.25309.09.2011 11:01:07.25312180262148004196253909414591400140400020480000013biplane09.09.2011 11:01:07.25309.09.2011 11:01:07.2531218026214800419625390941459127000017100020480000014biplane09.09.2011 11:01:07.25309.09.2011 11:01:07.253

Вызов один и тотже. как видите логических чтений стало почти на 3 порядка меньше.
В процедуре стоит форсплан и хинты на индексы. Что еще покрутить чтобы такого не было - даже не знаю.
Может ктото сталкивался? Потому как возникает нередко. И несколько глупо ловить нагрузку, искать что поломалось и просто перекомпиливать.

Adaptive Server Enterprise/15.5/EBF 18661 SMP ESD#4/P/x86_64/Enterprise Linux/asear155/2545/64-bit/FBO/Thu Jun 16 06:45:54 2011

MasterZivOn 09.09.2011 13:19, MichaelTim wrote:

Что вы понимаете под "слет плана оптимизации процедуры" ?



То, что вместо 54к логических чтений происходит 32 млн.
Время выполнения улетает в космос.
План используется неправильный.

komradMichaelTim,

попробуйте убрать форсплан


ну уже заметил что 15.5 нередко не обращает никакого внимания на форсплан :(
12.5.4 так никогда не поступала. Указан форсплан - джоинит таблицы в порядке.
15-шка както к этому порхладнее относится.

komradMichaelTim,
второй вариант : использовать abstract query plans
Ну этот вариант я тоже уже думал. Но прописывать везде абстрактные планы....... Както уж совсем :(
Надеялся всеже что можно както иным путем решить. Вот и обратился - сталкивался ктоот с этим или нет