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

Откуда:
Сообщений: 230
Есть сервер:

Microsoft SQL Server 2000 - 8.00.2055 (Intel X86) Dec 16 2008 19:46:53 Copyright (c) 1988-2003 Microsoft Corporation Developer Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

Поле ряда операций:

exec sp_updatestats
exec sp_MSforeachtable N'DBCC DBREINDEX (''?'')'
DBCC UPDATEUSAGE (0);
dbcc freeproccache

Начала тормозить (на вскидку по времени раз в 5) база

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

  update ibbw 
    set CountBlockRepeat= (
      select count(*) 
      from Blocks B, 
	--with (index = blkBlk_IDX),  
	Issues I with (index = Iss_IDX1)
      where 
        B.blkBlockPTR=blkID and 
        blkIssuePTR = I.ID and
        issChnlPTR  = @cnlID)
    from #IBBW_tmp ibbw
    where 
      blkID>0 and 
      isnull(blkBlockPTR,0)=0
    option (loop join)


Индексы
NONCLUSTERED INDEX [blkBlk_IDX] ON [dbo].[Blocks]
(
[blkBlockPTR] ASC
) ON [INDEXES]

UNIQUE NONCLUSTERED INDEX [Iss_IDX1] ON [dbo].[Issues]
(
[ID] ASC
) ON [INDEXES]

Складывается ощущение (расставлял тайм метки по телу процы), что резко возрасло время работы с временными таблицами.

Подскажите, с чего можно начать копать, буду рад любым предположения.

Готов представить любую доп. информацию.

Сообщение было отредактировано: 24 янв 15, 11:49
30 дек 09, 11:19    [8136329]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
aleks2
Guest
1. Оптимизатор ГОРАЗДО лучше умеет оптимизировать запросы, чем средний чайник. Поэтому главная задача чайника: НЕ МЕШАТЬ ОПТИМИЗАТОРУ.

2. Если очень хоцца хинт поставить - см. п.1.
30 дек 09, 11:32    [8136411]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Miles
Member

Откуда:
Сообщений: 230
aleks2
1. Оптимизатор ГОРАЗДО лучше умеет оптимизировать запросы, чем средний чайник. Поэтому главная задача чайника: НЕ МЕШАТЬ ОПТИМИЗАТОРУ.

2. Если очень хоцца хинт поставить - см. п.1.


Правильное замечание.

Только база не моя.
30 дек 09, 11:34    [8136420]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
aleks2
Guest
Miles
aleks2
1. Оптимизатор ГОРАЗДО лучше умеет оптимизировать запросы, чем средний чайник. Поэтому главная задача чайника: НЕ МЕШАТЬ ОПТИМИЗАТОРУ.

2. Если очень хоцца хинт поставить - см. п.1.


Правильное замечание.

Только база не моя.


Ну и чо ты хочешь? Шоб посочувствовали?


1. Нахер коррелированный запрос?
2. Уж ежели начали пользовать времянки - нехча на них экономить.

Короче, ежели вы удосужитесь обьяснить: какие поля
		B.blkBlockPTR=blkID and 
		blkIssuePTR = I.ID and
		issChnlPTR = @cnlID)
относятся к какой таблице (а заодно и привыкнете писать ПОЛНОЕ имя поля ВСЕГДА), то этот запрос можно переписать...
30 дек 09, 11:45    [8136487]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Miles
Member

Откуда:
Сообщений: 230
aleks2
Miles
aleks2
1. Оптимизатор ГОРАЗДО лучше умеет оптимизировать запросы, чем средний чайник. Поэтому главная задача чайника: НЕ МЕШАТЬ ОПТИМИЗАТОРУ.

2. Если очень хоцца хинт поставить - см. п.1.


Правильное замечание.

Только база не моя.


Ну и чо ты хочешь? Шоб посочувствовали?


1. Нахер коррелированный запрос?
2. Уж ежели начали пользовать времянки - нехча на них экономить.

Короче, ежели вы удосужитесь обьяснить: какие поля
		B.blkBlockPTR=blkID and 
		blkIssuePTR = I.ID and
		issChnlPTR = @cnlID)
относятся к какой таблице (а заодно и привыкнете писать ПОЛНОЕ имя поля ВСЕГДА), то этот запрос можно переписать...


Я еще раз говорю, я не писал ни запрос ни базу.
Запрос привел лишь в качестве того, что до того как выполнили работы с индексами он отрабатывал хорошо, после нет. А отключение хинта лишь ускорило его но не вернула прежнюю скорость выполнения.

Основной вопрос как перестройка индексов могла повлиять на скорость в сторону ее уменьшения.
30 дек 09, 12:09    [8136699]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
aleks2
Guest
Miles

Основной вопрос как перестройка индексов могла повлиять на скорость в сторону ее уменьшения.


1. Кэшированные данные былы сброшены из ОЗУ - позапускайте пару-десяток разиков...
2. Статистика была обновлена неудачно - не на полной выборке - оказалось дальше от истины чем было. Обновите на ALL.
30 дек 09, 12:16    [8136756]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Fire83
Member

Откуда: Гомель-Минск
Сообщений: 474
Miles,
А с чего вы взяли что виновата перестройка индексов?
у вас там
dbcc freeproccache 
т.е. вы все планы для процедур очистили.
30 дек 09, 12:19    [8136782]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Now password
Guest
А вы уверены, что перестройка индекса прошла успешно? Вы уверены в том, что статистика не слетела? Как часто она обновляется? Вы видели план запроса до этого случая и то, что происходит сейчас? В чём раздница? Какая сейчас нагрузка на сервер и какая была в "прошлый" момент выполнения скрипта. Вы выдали очень мало данных и хотите получить полный ответ. Это порождает только вопросы к вам. Да, и как показывает практика - count(*) - зло. Читайте по primary key.
30 дек 09, 12:20    [8136791]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
aleks2
Guest
Now password
А вы уверены, что перестройка индекса прошла успешно? Вы уверены в том, что статистика не слетела? Как часто она обновляется? Вы видели план запроса до этого случая и то, что происходит сейчас? В чём раздница? Какая сейчас нагрузка на сервер и какая была в "прошлый" момент выполнения скрипта. Вы выдали очень мало данных и хотите получить полный ответ. Это порождает только вопросы к вам. Да, и как показывает практика - count(*) - зло. Читайте по primary key.


Рази можно быть в чем-то уверенным?

PS:
1. Ежели у тредстартера не было вопля об ошибке - канешно прошла.
2. Куда улетают статистики?
3. Только што обновили.
4. Планов "до" уже никто не увидит - чо шуметь?
5. В чем зло count(*)? Веруете, шо count(1) быстрее? Аминь!
30 дек 09, 12:28    [8136853]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Miles
Member

Откуда:
Сообщений: 230
Fire83
Miles,
А с чего вы взяли что виновата перестройка индексов?
у вас там
dbcc freeproccache 
т.е. вы все планы для процедур очистили.



С этим понятно. Но это должны быть временные тормоза, после суток то работы планы должны уже создаться.
30 дек 09, 12:50    [8137035]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Miles
Member

Откуда:
Сообщений: 230
exec sp_updatestats
exec sp_MSforeachtable N'DBCC DBREINDEX (''?'')'
DBCC UPDATEUSAGE (0);
dbcc freeproccache

В принципе последовательность команд правильная?

Как я понял нужно попробовать еще раз, до этого стоит ли еще что нибудь выполнить, порекомендуйте пожалуйста?
30 дек 09, 12:57    [8137077]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Now password
Guest
Лично я статистику обновлял бы после пересоздания индекса, т.к. не вижу смысла делать это заранее, а потом его изменять.
30 дек 09, 13:30    [8137277]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Now password
Guest
Да, по поводу count(*) Во время этой операции сканируется таблица целиком, что приводит к нагрузке на дисковый массив. Если таблица в третей нормальной форме и имеет primary key, то select count(primary_key_column) пройдёт по кластерному индексу - что намного дешевле и на больших объёмах таблицы легче и быстрее.
30 дек 09, 13:33    [8137290]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
Now password
Да, по поводу count(*) Во время этой операции сканируется таблица целиком, что приводит к нагрузке на дисковый массив. Если таблица в третей нормальной форме и имеет primary key, то select count(primary_key_column) пройдёт по кластерному индексу - что намного дешевле и на больших объёмах таблицы легче и быстрее.

Неправда. План все покажет.
30 дек 09, 13:35    [8137303]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Now password
Guest
create table #table (id int identity(1,1),
						name varchar(10), adress varchar(10) )

create clustered index IX_table on #table(id)
			
declare @i int
set @i = 1			

while @i <=1000
begin						
	insert into #table (name, adress) values ('Test', 'Moscow')
	set @i = @i+1
end

set statistics io on
go
select count(*) from #table 
go
set statistics io off
go
set statistics io on
go
select count(1) from #table 
go
set statistics io off
go

Scan count 1, logical reads 6, physical reads 0, read-ahead reads 8, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
30 дек 09, 13:49    [8137381]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Glory
Member

Откуда:
Сообщений: 104760
count(*) идет по индексу наименьшей длины
30 дек 09, 13:53    [8137423]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
Now password

Scan count 1, logical reads 6, physical reads 0, read-ahead reads 8, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Scan count 1, logical reads 6, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

И что?
30 дек 09, 14:02    [8137497]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Now password
Guest
А что непонятного тут было написано?
30 дек 09, 17:23    [8138730]     Ответить | Цитировать Сообщить модератору
 Re: Тормоза после DBCC DBREINDEX  [new]
Ray D
Member

Откуда: from the middle of nowhere
Сообщений: 3598
Блог
Мне непонятно, что вы этим хотели сказать.

ЗЫ dbcc dropcleanbuffers еще добавьте перед выполнение обоих select'ов и планы посмотрите.
30 дек 09, 18:13    [8138938]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить