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

Откуда: столичный город кудаблин
Сообщений: 619
Дано:
Microsoft SQL Server 2005 - 9.00.4035.00 (Intel X86) 
 Nov 24 2008 13:01:59 
 Copyright (c) 1988-2005 Microsoft Corporation
 Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

узкая и длинная таблица:

CREATE TABLE [dbo].[T_DATA_DAT](
	[DAT_TRV_ID] [decimal](6, 0) NOT NULL,
	[DAT_DEF_ID] [varchar](20) NOT NULL,
	[DAT_DATE] [datetime] NOT NULL,
	[DAT_VALUE] [float] NULL
) ON [PRIMARY]

На ней индексы:
ALTER TABLE [dbo].[T_DATA_DAT] ADD  CONSTRAINT [PK_T_DATA_DAT] PRIMARY KEY CLUSTERED 
(
	[DAT_DATE] ASC,
	[DAT_TRV_ID] ASC,
	[DAT_DEF_ID] ASC
)WITH 
(
	PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, 
	IGNORE_DUP_KEY = ON, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90
) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [I_DAT_DATE] ON [dbo].[T_DATA_DAT] 
(
	[DAT_DATE] DESC
) WITH 
(
	PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, 
	DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90
) ON [PRIMARY]
GO

CREATE NONCLUSTERED INDEX [I_DAT_TRV_ID_DEF_ID] ON [dbo].[T_DATA_DAT] 
(
	[DAT_TRV_ID] ASC,
	[DAT_DEF_ID] ASC
) WITH 
( 
	PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, 
	DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 90
) ON [PRIMARY]


Всего записей 42 791 980
за вчера приросло 422 609 (1% в день)

Прирост делается через INSERT BULK, но с большим количеством самопальных проверок типа SELECT .. FROM ... WHERE field1 = @afield1... Данные приростают в конец таблицы, т.е. DAT_DATE все время текущая дата.

Maintenance plan нету никакого. раз в месяц после деплоя я произношу магическое заклинание:
ALTER INDEX ALL ON T_DATA_DAT REBUILD; 
update statistics t_data_dat with fullscan; 
Это занимает примерно 40 минут.

По ряду причин не хочется тратить много времени на создание всобъемлющего плана: в сентябре мы все это поменяем, нету времени, сервер - standart edition поэтому WITH (ONLINE=ON) не работает, на сервере крутится сервис, что раз в пять минут запихивает очередную порцию данных в таблицу. Сервис нам не принадлежит, и написан он очень хорошими людьми, у которых большие странности.

За 3 недели время выполнения репрезентативных запросов возросло с 2 секунд до 5 минут. Основная причина фрагментация индексов - та же самая база, но с обновленными индексами справляется с репрезентативными запросами за положенные 2 секунды.

Вопросы:

1. Есть ли какой-нибудь maintenance plan, что бы перестроить/обновить индексы на рабочей базе.

2. Сегодня встал вопрос о fillfactor 90. Почитав доку я подумал, что может быть его увеличить до 70, что бы было свободное место до следующего полного ребилда индексов. Сделал на тесте, репрезентативные запросы подросли до 6 секунд, и на форуме консенсус fillfactor не трогать. Вопрос: что делать - оставить fillfactor = 90 как есть; уменьшить его, что бы дать ему заполнится за время до следующего ребилда; или же поставить его на дефолтовый 0.

Помогите, я в расстерянности.




Cheers
Pete
30 июл 09, 19:55    [7481543]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
Гавриленко Сергей Алексеевич
Member

Откуда: Moscow
Сообщений: 36800
Вы бы лучше планы ваших запросов анализировали. И статистику можно почаще обновлять, при этом ничего не блокируется.
30 июл 09, 19:59    [7481551]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
B0rG
Member

Откуда: столичный город кудаблин
Сообщений: 619
Гавриленко Сергей Алексеевич
Вы бы лучше планы ваших запросов анализировали. И статистику можно почаще обновлять, при этом ничего не блокируется.


Одной статистики хватит? Хотелось бы еще и DEFRAG.

Не очень хочется тратить время на анализ текущих запросов по нескольким причинам:

* все они используют очень страшный фильр по дате: вместо того, что бы писать [DAT_DATE] is between или же [date] > date1 and [date] < date2, там делается пересчет в чистую дату без времени через пользовательскую функцию.

* все эти запросы в сентябре, мы поменяем на другие уже правильно написанные, добавим перенос аггрегированных данных в другую базу и в этой базе будем хранить данные только за текущий месяц.
30 июл 09, 20:13    [7481591]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
ererererer1
Guest
я думаю вам надо каждый раз после массовой заливки данных - или можно каждый день в низкий перид активности - например ночью запускать джоб. в этом джобе должно быть следующее

reorganize индексов - эта операция не блокирует таблицу, она удаляет internal и external фрагментацию - так как она не лочит всю таблицу - то она может не всю фрагментацию удалить. после этой операции надо обновить статистику. применяется если фрагментация небольшая
ИЛИ
rebuild индексов - операция блокирует всю таблицу, но зато полностью перестраивает весь индекс и обновляет статистику. применяется если сильная фрагментация.
30 июл 09, 20:34    [7481643]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
ererererer1
Guest
я думаю филфактор особо не поможет - у вас варчар в индексе. оставьте его 0
30 июл 09, 20:42    [7481651]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
ererererer1
Guest
либо по филфактору искать золотую середину - чтобы и филфактор был и чтения не страдали при этом
30 июл 09, 20:46    [7481658]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
B0rG
Member

Откуда: столичный город кудаблин
Сообщений: 619
ребилд в стандартной версии работает только в однопользовательском режиме, и для этого придется на время пришибать сервис, вставляющий данные, а этого хотелось бы избежать.

остается только
ALTER INDEX ALL ON dbo.T_DATA_DAT REORGANIZE

попробуем...
30 июл 09, 20:57    [7481678]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
ererererer1
Guest
неужели надо базу переводить в однопользовательский режим - чтоб индекс перестроить?
или вы имеет в виду просто блокировку? если таблица постоянно используется, то согласен во всремя перестройки индексов никто не сможет до неё достучаться. можно не все индексы сразу перестраивать, а например - один индекс в день. тогда у вас операция быстрее ьудет работать. статистику тоже можно обновлять без фулскана. вам очень важно статистику почаще обновлять - так как у вас за один раз добавляется 1 процент данных - за месяц данные изменятся до не узнаваемости - старые планы не будут отражать этих изменений. и еще не обязательно все индексы перестаивать - надо выделить лишь те, которые имеют достаточную фрагментацию например больше 30 процентов

SELECT
ps.OBJECT_ID AS objectID
, ps.index_id AS indexID
, ps.partition_number AS partitionNumber
, ps.avg_fragmentation_in_percent AS fragmentation
, ps.page_count
FROM sys.dm_db_index_physical_stats (NULL, NULL, NULL , NULL, N'Limited') ps
WHERE ps.index_id > 0
AND ps.page_count > 1000
AND ps.avg_fragmentation_in_percent > 30
31 июл 09, 00:07    [7482111]     Ответить | Цитировать Сообщить модератору
 Re: FillFactor & Maintenance Plan  [new]
B0rG
Member

Откуда: столичный город кудаблин
Сообщений: 619
ererererer1
неужели надо базу переводить в однопользовательский режим - чтоб индекс перестроить?
или вы имеет в виду просто блокировку? если таблица постоянно используется, то согласен во всремя перестройки индексов никто не сможет до неё достучаться. можно не все индексы сразу перестраивать, а например - один индекс в день. тогда у вас операция быстрее ьудет работать. статистику тоже можно обновлять без фулскана. вам очень важно статистику почаще обновлять - так как у вас за один раз добавляется 1 процент данных - за месяц данные изменятся до не узнаваемости - старые планы не будут отражать этих изменений. и еще не обязательно все индексы перестаивать - надо выделить лишь те, которые имеют достаточную фрагментацию например больше 30 процентов


Беда в том, что талбичка прирастает раз в 5 минут, т.е. этот процент растянут на день по капле. По сему если затеять перестройку индекса то сервис, заливающий данные, не сможет работать. Уже не говоря о том, что сервис сам проверяет наличие данных не самым оптимальным способом...
4 авг 09, 13:45    [7495570]     Ответить | Цитировать Сообщить модератору
Все форумы / Microsoft SQL Server Ответить