Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 ну вот и паразитные компиляции пойманы!  [new]
Crimean
Member

Откуда:
Сообщений: 13147
репро:

use master
go

create database a1
go

use a1
go

create table dbo.users( id int )
go

insert into dbo.users( id ) values( 1 )
insert into dbo.users( id ) values( 2 )
insert into dbo.users( id ) values( 3 )
go

create function dbo.f1( @id int )
returns int
as
begin
return 1
end
go

create procedure dbo.p1
as
set nocount on

create table #a 
(
id int
)

insert into #a ( id )
select top 1 dbo.f1( id ) from dbo.users

return 1
go

exec dbo.p1
go

alter function dbo.f1( @id int )
returns int
as
begin
return 1
end
go

exec dbo.p1
go

use master
go

drop database a1
go

это делаем под трасом, ловим рекомпиляции
ловим их 2 раза, первый раз ясен пень типа 3 поскольку # используются
а вот второй раз - типа 1 - с какого перепугу?

зы

2008 р2, долго я их ловил, регулярно мелькали в трасе, но не мог за хвост ухватить. очень вероятно, что это не единственное проявление этих паразитов
22 июн 11, 16:06    [10855699]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
Maxx
Member [скрыт]

Откуда:
Сообщений: 24290
красиво,треба будет пасматреть када посвободнее будет

А вообще,конечно...хорошо что у наденым делятся,спасибо
22 июн 11, 16:12    [10855800]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
Crimean,

ммм...я видимо что-то не понял, т.к. не в курсе изначальной темы.
запустил репро, у меня получилось:
в первый раз sp:recompile - 3 deffered compile.
после альтера sp:recompile - 1 schema changed.

А как должно быть?
22 июн 11, 16:31    [10856072]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31960
Crimean
ловим их 2 раза, первый раз ясен пень типа 3 поскольку # используются
а вот второй раз - типа 1 - с какого перепугу?
Так alter function-же делается.

Тип - это имеется в виду EventSubClass?
22 июн 11, 16:42    [10856271]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
Crimean
Member

Откуда:
Сообщений: 13147
а в первый раз вообще функция с нуля создается и база с нуля но это никого не парит почему-то, ага?
я бы понял если бы ОБА РАЗА были компиляции, связанные с UDF или второй раз - тот же тип 3 или другой тип
но вылизывать код в процессе искоренения типа 1 я честно устал, а он лезет косвенно от смены планов функции, судя по всему
22 июн 11, 17:14    [10856672]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
step_ks
Member

Откуда:
Сообщений: 936
Crimean
а в первый раз вообще функция с нуля создается и база с нуля но это никого не парит почему-то, ага?
я бы понял если бы ОБА РАЗА были компиляции, связанные с UDF или второй раз - тот же тип 3 или другой тип

как вариант - в первый раз потенциально были возможны 2 причины - 1 и 3, и сервер решил перекомпилиться по 3, что и показал в трассе. Не две же причины ему одновременно показывать (хотя было бы неплохо). А второй раз пошло по 1, т.к. create table не изменился.
22 июн 11, 22:55    [10858305]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31960
step_ks
Crimean
а в первый раз вообще функция с нуля создается и база с нуля но это никого не парит почему-то, ага?
я бы понял если бы ОБА РАЗА были компиляции, связанные с UDF или второй раз - тот же тип 3 или другой тип

как вариант - в первый раз потенциально были возможны 2 причины - 1 и 3, и сервер решил перекомпилиться по 3, что и показал в трассе. Не две же причины ему одновременно показывать (хотя было бы неплохо). А второй раз пошло по 1, т.к. create table не изменился.
+1

Какая разница, какое сообщение в профайлере?

В любом случае есть перекомпиляция. Может, Crimean в курсе каких то тонкостей, но мне это непонятно :-(
22 июн 11, 23:36    [10858410]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
Crimean
Member

Откуда:
Сообщений: 13147
alexeyvg
Какая разница, какое сообщение в профайлере?
В любом случае есть перекомпиляция. Может, Crimean в курсе каких то тонкостей, но мне это непонятно :-(




подход - жесть.
возвращаясь к теме - откуда там смена схемы?
репро суррогатное. в продакшене лезет рекомпиляция типа 1. и чего мне с ней делать, если смены схемы нет?
23 июн 11, 10:51    [10859656]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
Crimean
Member

Откуда:
Сообщений: 13147
step_ks
как вариант - в первый раз потенциально были возможны 2 причины - 1 и 3


откуда там 1????
23 июн 11, 10:56    [10859704]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
step_ks
Member

Откуда:
Сообщений: 936
Crimean
step_ks
как вариант - в первый раз потенциально были возможны 2 причины - 1 и 3


откуда там 1????


может и ниоткуда, раз перекомпилил по 3.
Или я вас неправильно понял.
23 июн 11, 11:29    [10859972]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31960
Crimean
alexeyvg
Какая разница, какое сообщение в профайлере?
В любом случае есть перекомпиляция. Может, Crimean в курсе каких то тонкостей, но мне это непонятно :-(



подход - жесть.
То-есть, судя по аргументам, вы с подходом согласны?
Crimean
в продакшене лезет рекомпиляция типа 1. и чего мне с ней делать, если смены схемы нет?

Crimean
откуда там 1????
1 лезет, потому что есть смена схемы. Вы же сделали alter function, поменяли схему, чего же вы хотите???

Сменой схемы МС называет изменение объектов, на которые ссылается запрос.

Например, если поменять таблицу dbo.users, то тоже появится перекомпиляция, и тоже с нумером 1:
alter table dbo.users add name varchar(100)
go
exec dbo.p1
23 июн 11, 11:38    [10860045]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31960
Crimean
но вылизывать код в процессе искоренения типа 1 я честно устал, а он лезет косвенно от смены планов функции, судя по всему
Думаю, при смене планов функции тип 1 лезть не будет. По крайней мере, это нужно проверять, в вашем репро этого нет.
23 июн 11, 11:39    [10860066]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
SomewhereSomehow
Member

Откуда: Moscow
Сообщений: 2480
Блог
alexeyvg
Crimean
пропущено...



подход - жесть.
То-есть, судя по аргументам, вы с подходом согласны?
Crimean
в продакшене лезет рекомпиляция типа 1. и чего мне с ней делать, если смены схемы нет?

Crimean
откуда там 1????
1 лезет, потому что есть смена схемы. Вы же сделали alter function, поменяли схему, чего же вы хотите???

Сменой схемы МС называет изменение объектов, на которые ссылается запрос.

Например, если поменять таблицу dbo.users, то тоже появится перекомпиляция, и тоже с нумером 1:
alter table dbo.users add name varchar(100)
go
exec dbo.p1

Не, по-моему имелось ввиду, отуда там 1 вообще теоретически может быть в первый раз.

Я так понял что эти события все-таки отражают именно перекомпиляции (ну и отложенные). Потому как если избавиться от временной таблицы, и выполнить один раз (без альтер функшн), то никаких событий recompile вообще не будет. Если включить еще CasheMiss, CacheInsert,Show Plan XML,Show Plan XML For Query Compile, видно что сначала запись в кэше отсутсвует, потом появляется план, потом происодит запись в кэш, т.е. никаких рекомпиляций, если выполнение в первый раз.
Потом я добавил перед вставкой во временную таблицу "select * from dbo.users". Вижу во время выполнения:
SP:Starting--exec dbo.p1
...
SP:StmtStarting --select * from dbo.users
Show Plan XML --table scan
SP:StmtCompleted --тут он закончил обрабатывать инструкцию select * from dbo.users
SP:StmtStarting -- тут он доходит до insert into #a ( id ), определяет что нужна отложенная компиляция
SQL:StmtRecompile -- собственно компилирует, и тут как раз полне логично и законно показывает в причине 3-ку
ну и т.д.
Так что вроде к 3-ке никаких вопросов.
Дальше, когда изменяется функция, видимо считается что изменилась схема. Впринципе у меня это тоже не вызывает какого-то диссонанса в голове, вроде логично.
Так что, конечно на продакшене возможно все, но репро лично у меня вопросов не вызвало...
23 июн 11, 12:15    [10860421]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
Crimean
Member

Откуда:
Сообщений: 13147
хорошо, считаем, что в этом репро "1" означает смену UDF после формирования плана для нее
http://msdn.microsoft.com/en-us/library/ee343986.aspx
и спишем до уточнения репро мои сомнения на неудачный выбор названия для рекомпиляций типа 1
23 июн 11, 13:38    [10861336]     Ответить | Цитировать Сообщить модератору
 Re: ну вот и паразитные компиляции пойманы!  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31960
SomewhereSomehow
Потому как если избавиться от временной таблицы, и выполнить один раз (без альтер функшн), то никаких событий recompile вообще не будет.
Ну это понятно, первый раз перекомпиляция с типом три от insert ... exec.

Во второй раз перекомпиляция с типом один от альтер функшн.

Если убрать insert ... exec, то перекомпиляция с типом один от альтер функшн так и останется, как же иначе.

А если избавится и от insert ... exec, и от альтер функшн, то никаких перекомпиляций не будет, само собой.
23 июн 11, 14:01    [10861588]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить