Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34621
Crimean,
если я тебя ни с кем не путаю, то ты уже не мальчик, и давно должен понимать, что то, что ты описал - нормальная ситуация.
оптимизаторы работают с некоторыми стохастическими эффектами, во всех СУБД.
ничего не поделаешь, NP полная задача, решаемая с эвристиками...
18 фев 16, 23:03    [18838281]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Ой, куда только не интегрировались:) Если серьезно, могу иногда пользуясь служебным положением действительно безвозмездно чего нибудь предложить в целях общих исследований. Главное объектвный анализ. А так то уже второй год лучшие партнеры MS по DB.
18 фев 16, 23:52    [18838482]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
Crimean
Member

Откуда:
Сообщений: 13148
MasterZiv,

мне нужно было подтверждение своим подозрениям. я его получил :) за что и спасибо
к сожалению, моих знаний недостаточно для "утверждений", только "подозрения"
как следствие - буду "педалировать" продвижение ресурс говернора как средства недопущения (минимизации) такого поведения
поскольку повлиять на загрузку сервера полноценно не могу
19 фев 16, 01:49    [18838689]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
Oleksii Kovalov
Member

Откуда:
Сообщений: 100
Crimean
другими словами, неоднократно наблюдаю, что некоторые запросы (даже с option( recompile )) получают радикально разные планы в практически одинаковых условиях. проблема всплывает, разумеется, когда запрос начинает работать нетипично долго. причем KILL процесса и перезапуск команды, зачастую, не приводит к воспроизведению ситуации. то есть повторный запуск "тут же" дает "обычное" (быстрое) а не "медленное" (аномальное) выполнение

Там случайно не было обмена hash join->loop join?
19 фев 16, 01:56    [18838694]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
Crimean
Member

Откуда:
Сообщений: 13148
Oleksii Kovalov,

там была замена чего угодно на loop. ибо только неуместный loop может работать "до новых веников", не забывая радостно накручивать потребление CPU (и, практически, не трогая диски) :) ну и "a lot of spools", конечно же, куда же без них. в результате то, что обычно выполняется 15 минут - могло крутиться часами без малейших шансов выполниться. если оставить без присмотра, конечно же. безсистемность данного явления сподвигла на тщательные наблюдения, в результате которых и появились подозрения
19 фев 16, 04:35    [18838718]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
Oleksii Kovalov
Member

Откуда:
Сообщений: 100
Crimean
Oleksii Kovalov,

там была замена чего угодно на loop. ибо только неуместный loop может работать "до новых веников", не забывая радостно накручивать потребление CPU (и, практически, не трогая диски) :) ну и "a lot of spools", конечно же, куда же без них. в результате то, что обычно выполняется 15 минут - могло крутиться часами без малейших шансов выполниться. если оставить без присмотра, конечно же. безсистемность данного явления сподвигла на тщательные наблюдения, в результате которых и появились подозрения

если не ошибаюсь, то это типичная картина для плана запроса при ограничении по доступной памяти
циклы "наименее ресурсоемкий" вариант, ему не нужна память, в отличие от хэшей или тех же слияний.
19 фев 16, 18:40    [18842787]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Думаю во вторник выложу скрипт показывающий данный эффект наглядно. Нужно еще проверить на разных версиях сервера.
27 фев 16, 14:22    [18871325]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Чувствую завтра задам просто какой то детектив! Сложнее всего было нагрузочно-функциональный тест создать. Вроде все готово, сам еще не исследовал плотно, доверяюсь словам коллег(но еще раз повторюсь нужно все перепроверять). Есть очень странное поведение MSSQL выражающееся в виде неожиданной деградации.
1 мар 16, 00:58    [18880059]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Собственно говоря как и обещал.

Скрипт «ТестоваяБаза» создают базу с тремя таблицами.

Таблица _Reference105 (некий справочник) и его табличная часть (_Reference105_VT1828). Отношение «один-ко-многим». Справочники могут быть заполнены, а могут быть и пустыми.(на результат не влияет)

Таблица очереди «queue», никак не связанна с первыми двумя таблицами. (эскалация на этой таблице отключена)



В скрипте «Синтетический тест по деградации скорости» в транзакции идет «прогонка» контрольных запросов к справочнику и его табличной части. После этого идет интенсивная вставка записей в таблицу «очереди».

После опять идут контрольные запросы к справочниками, на которых видно существенное «проседание» времени исполнения этих же запросов (планы запросов при этом не меняются).



Данная проблема устраняется или добавление индекса по полю _LineNo1829 (которое участвует в сортировке), или простым исключением сортировки.

Но почему такая разница в длительности «До» и «После» и чем это вызвано – не совсем понятно.

create database _Test;
GO

Use _Test;
Go

IF @@trancount > 0
	ROLLBACK
IF @@trancount > 0
	ROLLBACK

BEGIN TRAN


-- Создаем основную таблицу справочника
CREATE TABLE [dbo].[_Reference105] (
	[_IDRRef] [Binary] (16) NOT NULL ,
	[_Version] [timestamp] NOT NULL ,
	[_Marked] [Binary] (1) NOT NULL ,
	[_PredefinedID] [Binary] (16) NOT NULL ,
	[_ParentIDRRef] [Binary] (16) NOT NULL ,
	[_Folder] [Binary] (1) NOT NULL ,
	[_Code] [nchar] (9) NOT NULL ,
	[_Description] [nvarchar] (50) NOT NULL ,
	[_Fld1823] [ntext] NULL ,
	[_Fld1824RRef] [Binary] (16)  NULL ,
	[_Fld1825RRef] [Binary] (16)  NULL ,
	[_Fld1826RRef] [Binary] (16)  NULL ,
	[_Fld1827RRef] [Binary] (16)  NULL ,
	[_Fld521] [numeric] (7,0) NOT NULL)
	
-- Индексы к справочнику
CREATE  INDEX	_Referen105_ByPredefinedIDNotUniq_B on [dbo].[_Reference105](_Fld521,_PredefinedID)
CREATE  UNIQUE  INDEX	_Referen105_Code_SR  on [dbo].[_Reference105](_Fld521,_Code,_IDRRef)
CREATE  UNIQUE  INDEX	_Referen105_Descr_SR  on [dbo].[_Reference105](_Fld521,_Description,_IDRRef) 
CREATE  UNIQUE  INDEX	_Referen105_ParentCode_RLSR on [dbo].[_Reference105](_Fld521,_PredefinedID,_Folder,_Code ,_IDRRef) 
CREATE  UNIQUE  INDEX	_Referen105_ParentDescr_RLSR on [dbo].[_Reference105](_Fld521,_PredefinedID,_Folder,_Description ,_IDRRef) 
CREATE  UNIQUE CLUSTERED INDEX	_Reference105HPK on [dbo].[_Reference105](_Fld521,_IDRRef) 
	

-- Создаем табличную часть справочника (отношение "один-ко-многим" с основной таблицей справочника) 
CREATE TABLE [dbo].[_Reference105_VT1828] (
	[_Reference105_IDRRef] [Binary] (16) NOT NULL ,
	[_Fld521] [numeric] (7,0) NOT NULL ,
	[_KeyField] [Binary] (4) NOT NULL ,
	[_LineNo1829] [numeric] (5,0) NOT NULL,
	[_Fld1830RRef] [Binary] (16) NOT NULL, 
	[_Fld1831_TYPE] [Binary] (1) NOT NULL , 
	[_Fld1831_L] [Binary] (1) NOT NULL , 
	[_Fld1831_N] [numeric] (5,0) NOT NULL,
	[_Fld1831_T] [datetime]  NOT NULL,
	[_Fld1831_S] [nvarchar] (1024) NOT NULL,
	[_Fld1831_RTRef] [Binary] (4) NOT NULL ,
	[_Fld1831_RRRef] [Binary] (16) NOT NULL ,
	[_Fld1832] [ntext] NOT NULL,
	)
	
-- Создаем индексы к табличной части справочника	
CREATE  UNIQUE CLUSTERED INDEX	_Referen105_VT1828_IntKeyInd on [dbo].[_Reference105_VT1828](_Fld521,_Reference105_IDRRef,_KeyField) 	


-- Создаем таблицу "очереди". Таблица не имеет никакого отношения к справочнику и его табличной части. 
-- в данную таблицу в процессе теста будет происходить интенсивная вставка строк.

CREATE TABLE [dbo].[queue] (
[id] [Bigint] IDENTITY(1,1) Not Null , 
[type] [Binary] (16) Not Null,
[objid] [Binary] (16) Not Null, 
[data] [nvarchar] (4000) Not Null, 
[tranid] [varchar] (32) Not Null, 
[xtype] [int] Not Null, 
[oper] [char] (1) Not Null, 
[version] [int] Not Null, 
[level] [tinyint] Not Null
)

-- Индексы таблицы очередей
CREATE  UNIQUE INDEX indx_queue_id_objid_type_tranid on [dbo].[queue] (id,objid,type,tranid)
CREATE  UNIQUE INDEX indx_queue_tranid_id on [dbo].[queue] (tranid,id)
CREATE  INDEX indx_queue_tranid_INCL_type_objid_xtype_level on [dbo].[queue] (tranid)
CREATE  UNIQUE INDEX indx_queue_tranid_objid_id on [dbo].[queue] (tranid,objid,id)
CREATE  UNIQUE INDEX PK_queue on [dbo].[queue] (id)


-- Убираем эскалацию для таблицы очередей
ALTER TABLE [dbo].[queue] SET (LOCK_ESCALATION = DISABLE)
ALTER INDEX ALL on [dbo].[queue] SET (ALLOW_PAGE_LOCKS = OFF)


-- Добавляем несколько записей в основную таблицу справочника. Можно и не добавлять. Конечный результат не зависит от этого.
-- Аналогично с табличной частью, можно добавить записи , а можно и не добавлять. 

insert into [dbo].[_Reference105] values (0x89D900055DCFC5CA11DD88B4D5D080A6,default,0x00,0x00000000000000000000000000000000,0xA1000011D85708FF11DCB3B1D341D2DD,0x01,'00-000008','Склад №2','',0x00000000000000000000000000000000,0x80A84A2E249652EF49A3B953429E5065,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0)
insert into [dbo].[_Reference105] values (0x89D900055DCFC5CA11DD88B4D5D080AE,default,0x00,0x00000000000000000000000000000000,0xA1000011D85708FF11DCB3B1D341D2DD,0x01,'00-000009','Склад №3','',0x00000000000000000000000000000000,0x80A84A2E249652EF49A3B953429E5065,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0)
insert into [dbo].[_Reference105] values (0x99F5BCAEC5B8981711E28C6756340236,default,0x00,0x00000000000000000000000000000000,0xA1000011D85708FF11DCB3B1D341D2DD,0x01,'00-000002','Склад товаров по комиссии на закупку','',0x00000000000000000000000000000000,0x80A84A2E249652EF49A3B953429E5065,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0)
insert into [dbo].[_Reference105] values (0x9BFBBCAEC5B8981711E26C727604A780,default,0x00,0x00000000000000000000000000000000,0xA1000011D85708FF11DCB3B1D341D2DD,0x01,'00-000001','Склад комиссионных товаров','',0x00000000000000000000000000000000,0x80A84A2E249652EF49A3B953429E5065,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0)
insert into [dbo].[_Reference105] values (0xA0F40011D85708FF11DCAA22DE80B7CE,default,0x00,0x00000000000000000000000000000000,0xA1000011D85708FF11DCB3B1D341D2DD,0x01,'00-000005','Основной склад','',0x00000000000000000000000000000000,0x80A84A2E249652EF49A3B953429E5065,0x00000000000000000000000000000000,0x00000000000000000000000000000000,0)


IF @@trancount > 0
	COMMIT TRAN
IF @@trancount > 0
	COMMIT TRAN


Скрипт теста деградации скорости
Use _Test;
GO


IF @@trancount > 0
	ROLLBACK
IF @@trancount > 0
	ROLLBACK

BEGIN TRAN
	SET NOCOUNT ON
	declare @i_max int , @i int , @d1 datetime , @d2 datetime, @duration int, @x varchar(100)

	--------------------------------------
	-- Запросы "ДО"
	-- небольшой цикл контрольных запросов к табличной части справочника (используется в качестве эталона, для сравнения длительности 
	-- этих же этих запросов после интенстивной вставки записей в таблицу "очередь")
	
	set @i_max = 10
	set @i=1

	set @d1 = getdate()
	WHILE @i <= @i_max
	BEGIN	
		-- контрольный запрос:
		exec sp_executesql N'SELECT
							T1._Reference105_IDRRef,
							T1._LineNo1829,
							T1._Fld1830RRef,
							T1._Fld1831_TYPE,
							T1._Fld1831_L,
							T1._Fld1831_N,
							T1._Fld1831_T,
							T1._Fld1831_S,
							T1._Fld1831_RTRef,
							T1._Fld1831_RRRef,
							T1._Fld1832
							FROM dbo._Reference105_VT1828 T1
							INNER JOIN dbo._Reference105 T2
							ON (T1._Reference105_IDRRef = T2._IDRRef) AND T1._Fld521 = T2._Fld521
							WHERE ((T2._Fld521 = @P1)) AND ((T2._IDRRef = @P2))
							ORDER BY (T1._LineNo1829)',N'@P1 numeric(10),@P2 varbinary(16)',0,0xB8235404A641878611E5D6430E963A6D

	set @i =@i+1
	END 
	set @d2 = getdate()
	set @duration = datediff(ms,@d1,@d2) 
	print @duration
	

	--------------------------------------
	--- формируем критический массив записей в очередь 	
	set @i_max = 150000
	set @i=1
	WHILE @i <= @i_max
	BEGIN
	
		INSERT INTO queue ([type],[objid],[data],[tranid],[xtype],[oper],[version],[level])
		SELECT 0x00 [type],
		0x00 [objid],
		''[data],
		'test' + CAST(@i as varchar(9)) [tranid],
		100 [xtype],
		'X' [oper],
		0 [version],
		0 [level] 

		set @i = @i +1 		
	END 


	--------------------------------------
	--- цикл контрольных запросов "ПОСЛЕ"
	set @i_max = 10
	set @i=1
	--Select '_Reference105_IDRRef'
	set @d1 = getdate()
	WHILE @i <= @i_max
	BEGIN	
		-- контрольный запрос:
		exec sp_executesql N'SELECT
							T1._Reference105_IDRRef,
							T1._LineNo1829,
							T1._Fld1830RRef,
							T1._Fld1831_TYPE,
							T1._Fld1831_L,
							T1._Fld1831_N,
							T1._Fld1831_T,
							T1._Fld1831_S,
							T1._Fld1831_RTRef,
							T1._Fld1831_RRRef,
							T1._Fld1832
							FROM dbo._Reference105_VT1828 T1
							INNER JOIN dbo._Reference105 T2
							ON (T1._Reference105_IDRRef = T2._IDRRef) AND T1._Fld521 = T2._Fld521
							WHERE ((T2._Fld521 = @P1)) AND ((T2._IDRRef = @P2))
							ORDER BY (T1._LineNo1829)',N'@P1 numeric(10),@P2 varbinary(16)',0,0xB8235404A641878611E5D6430E963A6D

		set @i =@i+1
	END 
	set @d2 = getdate()
	set @duration = datediff(ms,@d1,@d2) 
	print @duration
	--------------------------------------


IF @@trancount > 0
	COMMIT TRAN
IF @@trancount > 0
	COMMIT TRAN
1 мар 16, 19:56    [18884353]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
МуМу,

Я не знаю какое отношение этот тест имеет к вопросу ТС, но проблема скорее всего в большом количестве удерживаемых блокировок в транзакции. 150 тысяч строк вставляемых по одной, тут даже эскалацию не надо выключать, у сервера все равно нету других вариантов кроме как накладывать построчную блокировку. 150К х 6 = 900 тысяч блокировок. Каким именно образом и почему это влияет на скорость выполнения последующего запроса с сортировкой я не знаю, но связь явно есть. Достаточно сделать одно из следующего чтобы тормоза пропали:
1. Вставлять 150 тысяч строк одним куском, включив эскалацию.
2. Вставлять строки с TABLOCKX хинтом.
3. Закрыть транзакцию сразу после вставки строк
1 мар 16, 22:16    [18884831]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен  [new]
invm
Member

Откуда: Москва
Сообщений: 9413
Mind
но проблема скорее всего в большом количестве удерживаемых блокировок в транзакции
+1

Пока писал скрипт Mind меня опередил :)
Собственно, модифицированный тест:
+
Use _Test;
GO


IF @@trancount > 0
	ROLLBACK

set xact_abort on;

BEGIN TRAN
	SET NOCOUNT ON

    declare @lock_queue_table bit = 1, @query nvarchar(max) = N' declare @_Reference105_IDRRef Binary (16),
	@_Fld521 numeric (7,0),
	@_KeyField Binary (4),
	@_LineNo1829 numeric (5,0),
	@_Fld1830RRef Binary (16), 
	@_Fld1831_TYPE Binary (1), 
	@_Fld1831_L Binary (1), 
	@_Fld1831_N numeric (5,0),
	@_Fld1831_T datetime ,
	@_Fld1831_S nvarchar (1024),
	@_Fld1831_RTRef Binary (4),
	@_Fld1831_RRRef Binary (16),
	@_Fld1832 nvarchar(max)

    SELECT
							@_Reference105_IDRRef = T1._Reference105_IDRRef,
							@_LineNo1829 = T1._LineNo1829,
							@_Fld1830RRef = T1._Fld1830RRef,
							@_Fld1831_TYPE = T1._Fld1831_TYPE,
							@_Fld1831_L = T1._Fld1831_L,
							@_Fld1831_N = T1._Fld1831_N,
							@_Fld1831_T = T1._Fld1831_T,
							@_Fld1831_S = T1._Fld1831_S,
							@_Fld1831_RTRef = T1._Fld1831_RTRef,
							@_Fld1831_RRRef = T1._Fld1831_RRRef,
							@_Fld1832 = T1._Fld1832
							FROM dbo._Reference105_VT1828 T1
							INNER JOIN dbo._Reference105 T2
							ON (T1._Reference105_IDRRef = T2._IDRRef) AND T1._Fld521 = T2._Fld521
							WHERE ((T2._Fld521 = @P1)) AND ((T2._IDRRef = @P2))
							ORDER BY (T1._LineNo1829)';

    declare @query1 nvarchar(max), @query2 nvarchar(max);

    declare @query_marks table (id int, mark nvarchar(50));
    insert into @query_marks values (1, newid()), (2, newid());

    select
     @query1 = N'/*' + max(case when id = 1 then mark end) + N'*/' + @query,
     @query2 = N'/*' + max(case when id = 2 then mark end) + N'*/' + @query
    from
     @query_marks
	declare @i_max int , @i int , @d1 datetime , @d2 datetime, @duration int, @x varchar(100)

	--------------------------------------
	-- Запросы "ДО"
	-- небольшой цикл контрольных запросов к табличной части справочника (используется в качестве эталона, для сравнения длительности 
	-- этих же этих запросов после интенстивной вставки записей в таблицу "очередь")
	
	set @i_max = 10
	set @i=1

	WHILE @i <= @i_max
	BEGIN	
		-- контрольный запрос:
		exec sp_executesql @query1,N'@P1 numeric(10),@P2 varbinary(16)',0,0xB8235404A641878611E5D6430E963A6D

	set @i =@i+1
	END 
	

    declare @level tinyint;

    if @lock_queue_table = 1
     select top (0) @level = level from [queue] with (tablockx)
	--------------------------------------
	--- формируем критический массив записей в очередь 	
	set @i_max = 15000
	set @i=1
	WHILE @i <= @i_max
	BEGIN
	
		INSERT INTO queue ([type],[objid],[data],[tranid],[xtype],[oper],[version],[level])
		SELECT 0x00 [type],
		0x00 [objid],
		''[data],
		'test' + CAST(@i as varchar(9)) [tranid],
		100 [xtype],
		'X' [oper],
		0 [version],
		0 [level] 

		set @i = @i +1 		
	END 


	--------------------------------------
	--- цикл контрольных запросов "ПОСЛЕ"
	set @i_max = 10
	set @i=1
	--Select '_Reference105_IDRRef'
	WHILE @i <= @i_max
	BEGIN	
		-- контрольный запрос:
		exec sp_executesql @query2,N'@P1 numeric(10),@P2 varbinary(16)',0,0xB8235404A641878611E5D6430E963A6D

		set @i =@i+1
	END 
	--------------------------------------

select count(*) as locks_count from sys.dm_tran_locks where request_session_id = @@spid;

select
 qp.query_plan, t.text, qs.execution_count, qs.total_elapsed_time
from
 sys.dm_exec_query_stats qs cross apply
 sys.dm_exec_sql_text(qs.sql_handle) t cross apply
 sys.dm_exec_query_plan(qs.plan_handle) qp join
 @query_marks qm on t.text like N'%' + qm.mark + N'%' 
order by
 qm.id;

IF @@trancount > 0
	ROLLBACK TRAN

Выполнить с @lock_queue_table = 0 и @lock_queue_table = 1
1 мар 16, 22:31    [18884888]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Мне в тесте интересует каким образом добавление индекса влияет на то что запросы перестают тормозить? Каким он образом этот индекс связан с блокировками? При этом можете сами проверить что планы одинаковые. Я бы все понял и не задавал бы вопросов если бы не этот ньюанс.
1 мар 16, 23:15    [18885033]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
Задача имеет практическое значение. Отключение эскалации используется в репликаторе. Если этого не сделать то пойдут блокировки. Как решить понятно, но хотелось бы разобраться в причине, а также может быть решить малой кровью.
1 мар 16, 23:18    [18885042]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен  [new]
invm
Member

Откуда: Москва
Сообщений: 9413
МуМу
Мне в тесте интересует каким образом добавление индекса влияет на то что запросы перестают тормозить?
Проверено - никак не влияет. Что с индексом, что без, поведение одинаково. Исключение сортировки так же никакого влияния не оказывает.
1 мар 16, 23:36    [18885096]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
А вот это уже интересно. Сейчас проверим на разных версиях MSSQL, с разным объемом памяти сравнивая с порогом изменений когда начинается деградация. Точные условия данного эксперимента выложу через пару часов.
2 мар 16, 08:34    [18885584]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
МуМу
Member

Откуда:
Сообщений: 1134
То Invm. А вы именно этот тест проверяли? У нас ситуация стабильно воспроизводится. Попрошу коллегу который тесты проводит отписаться в ветку.
Если не сложно кому нибудь проверьте пожалуйста у себя данный тест. Интересует в первую очередь каким образом наличие индекса может влиять на "включение-отключение" деградации.
2 мар 16, 14:18    [18887670]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
leng
Member

Откуда:
Сообщений: 6
invm, добавление индекса CREATE INDEX IND1 on dbo._Reference105_VT1828 (_Fld521,_Reference105_IDRRef,_LineNo1829) либо исключение сортировки --ORDER BY (T1._LineNo1829) в контрольном запросе "ПОСЛЕ" решает проблему. Проверено.
2 мар 16, 15:05    [18887928]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
o-o
Guest
скрипт МуМу без индекса:
3
103
после создания индекса:
0
13
потом дроп индекс и снова тест:
0
13
ну и еще разок тест для проверки (индекса нет, он дропнут):
0
13
вывод: все фигня!!!
ну т.е. вообще ВСЕ ФИГНЯ
Microsoft SQL Server 2008 R2 (SP3) - 10.50.6000.34 (Intel X86)   Aug 19 2014 12:21:07   Copyright (c) Microsoft Corporation  Developer Edition on Windows NT 5.2 <X86> (Build : ) 
2 мар 16, 15:34    [18888058]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
o-o
Guest
потом убираю order by, получаю
0
0
а теперь ничего не трогаю, order by уже нет, запускаю еще пару раз и получаю
0
13
--
0
10
--------
вывод: см. предыдущий пост
2 мар 16, 15:44    [18888113]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
o-o
Guest
нет, ну уж я завершу мысль.
возвращаю order by. индекса нет.
и снова
0
13
----
теперь вывод уже более капитальный: какой же ***ак эту ***** придумал?
господи, а я еще в этом участвую
2 мар 16, 15:48    [18888129]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
leng
Member

Откуда:
Сообщений: 6
o-o,
ВАЖНО: перед запуском тестового скрипта необходимо настроить сбор событий Profiler-ом: собирать события SQL:BatchCompleted и SQL:StmtCompleted, фильтр по столбцу TextData - %Reference105%, собираемые количественные показатели - Duration, Reads, CPU, RowCount. Основное назначение трасса - показать нам длительность выполнения (Duration) каждого отдельного контрольного запроса ДО и ПОСЛЕ. Дело в том, что хотя в тестовом скрипте и имеется контроль общего времени выполнения блока контрольных запросов, но он слишком грубый и ориентироваться на него не следует.
2 мар 16, 16:35    [18888431]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
o-o
Guest
я одно не пойму: если разница во времени выполнения такая незначительная,
что ее НЕ ВИДНО в ms, то на кой все это надо?
вот я понимаю искоренить курсоры и скалярщину, истребив часы выполнения,
вернувшись к минутам.
но каких-то блох ловить , это точно не ко мне, извините
2 мар 16, 17:05    [18888611]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
leng
Member

Откуда:
Сообщений: 6
o-o,
Цитирую:

"скрипт МуМу без индекса:
3
103"

и чуть ниже

"потом убираю order by, получаю
0
0"


Разница между 0 и 103 незначительная?
И у меня стабильно все воспроизводится при переключении режимов.
2 мар 16, 17:11    [18888634]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
o-o
Guest
капец какой.
доношу еще раз, доходчиво:
тормозило всего 1 (один) раз из 100 (ста) запусков,
потому что все последующие с индексами/без, с сортировкой/без,
и даже без/без, все как было и в первый раз, но только не в первый раз, а во все последующие 99
НЕ БЫЛО БОЛьШЕ НИ РАЗУ 103.
ТОЛьКО 13, максимум.
причем и с индексом, и без, и с сортировкой, и без, 13 или 10
2 мар 16, 17:37    [18888756]     Ответить | Цитировать Сообщить модератору
 Re: а может ли план запроса быть построен / перестроен в зависимости от доступных ресурсов?  [new]
leng
Member

Откуда:
Сообщений: 6
o-o,
У кого проблема с воспроизведение см. скриншот.
Приведено 3 "прогона": без индекса, с индексом и еще раз без.
Результат: 260-0-283.
автор
Почувствуйте разницу


К сообщению приложен файл. Размер - 11Kb
2 мар 16, 17:37    [18888758]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить