Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
 Разница между QueryHash и QueryPlanHash  [new]
сосо павлиашвили
Guest
QueryHash используется для определения bucket в хэш таблице cach store? А QueryPlanCache используется для поиска по bucket'у?

QueryHash расчитывается по тексту запроса, а QueryPlanCache по мимо запроса еще и по параметрам таким как DbId, UserId и т. п..? Запутался чуток.
16 авг 13, 00:14    [14716089]     Ответить | Цитировать Сообщить модератору
 Re: Разница между QueryHash и QueryPlanHash  [new]
Glory
Member

Откуда:
Сообщений: 104751
Understanding the Query Hash and Query Plan Hash
16 авг 13, 09:56    [14716774]     Ответить | Цитировать Сообщить модератору
 Re: Разница между QueryHash и QueryPlanHash  [new]
сосо павлиашвили
Guest
Glory,

ссылку прочитал, но неясности остались.

В двух базах DB2, DB3 выполнен скрипт

create table z(id int);
go

select *
from z;


Потом таким скриптом получил выборку какие планы знает сервер для каждого из запросов:

+ plan_handle, cache_key1, ..., cache_keyN

declare @fields nvarchar(max) = '';

select @fields += ',' + d.attribute
from
(
	select distinct t3.attribute
	from
		sys.dm_exec_cached_plans t1
			outer apply
		sys.dm_exec_plan_attributes(t1.plan_handle) t3
	where t3.is_cache_key = 1
) d;

set @fields = stuff(@fields, 1, 1, '');

declare @sql nvarchar(max) =
	'
	select *
	from
		(
			select t1.plan_handle, t1.bucketid, t1.pool_id, t2.text, t3.attribute, t3.value
			from
				sys.dm_exec_cached_plans t1
					outer apply
				sys.dm_exec_sql_text(t1.plan_handle) t2
					outer apply
				sys.dm_exec_plan_attributes(t1.plan_handle) t3
		) d
		pivot(min(value) for attribute in (' + @fields + ')) w
	order by w.text
	';

exec(@sql);



plan_handlebucketidpool_idtextacceptable_cursor_optionscompat_leveldate_firstdate_formatdbiddbid_executeis_replication_specificlanguage_idmerge_action_typeobjectidoptional_clr_trigger_dbidoptional_clr_trigger_objidoptional_spidparent_plan_handlerequired_cursor_optionsset_optionsstatususer_id
0x06000600ECB6210530F30C7201000000010...173772select * from z;01101260021086095596000NULL0434701
0x060007005E609D1CF0BEB47801000000010...151442select * from z;011012700210480075870000NULL0434701


Везде где читал, написано, что когда текст запроса пришел на сервер, нему считается QueryHash и далее пишут обтекаемо о том, что он используется как ключ в хэш таблице для cach store (в данном случае), по этому ключу определяют bucket, где находится план запроса.

Но если посмотреть в приведенной выше таблицы, bucketid у обоих планов разный. Получается QueryHash это только часть ключа, который используется для лукапа хэш таблицы. А полный ключ это QueryHash + все_атрибуты из представления sys.dm_exec_plan_attributes (они развернуты пивотом в колонки для удобства), для которых IsCacheKey = 1? Со всеми вытекающими, в зависимости от совпадения QueryHashe+атрибуты при лукапе мы найдем или не найдем существующий план?
17 авг 13, 11:47    [14721800]     Ответить | Цитировать Сообщить модератору
 Re: Разница между QueryHash и QueryPlanHash  [new]
сосо павлиашвили
Guest
тут с query_hash и query_plan_hash

+

declare @fields nvarchar(max) = '';

select @fields += ',' + d.attribute
from
(
	select distinct t3.attribute
	from
		sys.dm_exec_cached_plans t1
			outer apply
		sys.dm_exec_plan_attributes(t1.plan_handle) t3
	where t3.is_cache_key = 1
) d;

set @fields = stuff(@fields, 1, 1, '');

declare @sql nvarchar(max) =
	'
	select *
	from
		(
			select t1.plan_handle, t4.query_hash, t4.query_plan_hash, t1.bucketid, t2.text, t3.attribute, t3.value
			from
				sys.dm_exec_cached_plans t1
					outer apply
				sys.dm_exec_sql_text(t1.plan_handle) t2
					outer apply
				sys.dm_exec_plan_attributes(t1.plan_handle) t3
					left join
				sys.dm_exec_query_stats t4 on t1.plan_handle = t4.plan_handle
		) d
		pivot(min(value) for attribute in (' + @fields + ')) w
	order by w.query_hash
	';

exec(@sql);




plan_handlequery_hashquery_plan_hashbucketidtextacceptable_cursor_optionscompat_leveldate_firstdate_formatdbiddbid_executeis_replication_specificlanguage_idmerge_action_typeobjectidoptional_clr_trigger_dbidoptional_clr_trigger_objidoptional_spidparent_plan_handlerequired_cursor_optionsset_optionsstatususer_id
0x06000600ECB62105B05C077401000000010...0x16649FF3014756820xD867FD2B9C7CEEFD17377select * from z;01101260021086095596000NULL0434701
0x06000700ECB62105F046077401000000010...0x16649FF3014756820xD867FD2B9C7CEEFD13605select * from z;01101270021086095596000NULL0434701
17 авг 13, 12:56    [14721850]     Ответить | Цитировать Сообщить модератору
 Re: Разница между QueryHash и QueryPlanHash  [new]
Glory
Member

Откуда:
Сообщений: 104751
сосо павлиашвили
Но если посмотреть в приведенной выше таблицы, bucketid у обоих планов разный.

Одинаковые таблицы в разных базах - это разные объекты. Вон же виден objectid
А аттрибуты соединения/параметры влияют на определение повторного использования плана к тому же объекту(объектам)
19 авг 13, 10:39    [14724259]     Ответить | Цитировать Сообщить модератору
 Re: Разница между QueryHash и QueryPlanHash  [new]
jfdjfjfjf
Guest
Glory
сосо павлиашвили
Но если посмотреть в приведенной выше таблицы, bucketid у обоих планов разный.

Одинаковые таблицы в разных базах - это разные объекты. Вон же виден objectid
А аттрибуты соединения/параметры влияют на определение повторного использования плана к тому же объекту(объектам)


objectid здесь это вот это

objectid
int
One of the main keys used for looking up an object in the cache. This is the object ID stored in sys.objects for database objects (procedures, views, triggers, and so on). For plans of type "Adhoc" or "Prepared", it is an internal hash of the batch text.


и во второй таблице оно одинаково, а dbid разный. хэши одинаковы.

думаю не трудно запилить тест когда таблица в одной db но один и тот же запрос выполнять с различием одного из параметров в приведенной таблице. и плана уже будет два.

вобщем вопрос был о том, что представляет собой ключ для хеш таблицы в cache store в котором хранятся планы запросов. это явно не один только QueryHash. если бы это был только QueryHash планы бы попали в один и тот же bucketid. хэш таблица то одна и таже для всех баз. отсюда (из структуры ключа хэштаблицы) и вылезают все правила переиспользования планов, какие параметры на это влияют и т. п..
19 авг 13, 16:07    [14726432]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить