Фрагментация индекса

khourshed
Дата: 11.02.2013 09:16:55
Добрый день!
Имеется такая табличка:
USE [ViewCacheDb]
GO

/****** Object: Table [dbo].[cms_tblViewCache] Script Date: 02/11/2013 09:08:21 ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[cms_tblViewCache](
	[VIEW_CACHE_ID] [uniqueidentifier] NOT NULL,
	[WEBPROJECT_COMPONENT_ID] [uniqueidentifier] NOT NULL,
	[CREATE_DATE] [datetime] NOT NULL,
	[LAST_UPDATE] [datetime] NOT NULL,
	[XML_PARAMS] [xml] NOT NULL,
	[XML_CACHE] [xml] NOT NULL,
	[HTML_CACHE] [nvarchar](max) NULL,
	[CACHE_IS_ACTUAL] [bit] NOT NULL,
	[CACHE_LIFE_TIME] [int] NOT NULL,
	[XSL_TRANSFORMATION_ID] [uniqueidentifier] NULL,
	[CHECK_SUM] [int] NOT NULL,
	[GENERATION_TIME] [time](7) NULL,
	[ASYNC_UPDATE] [bit] NULL,
	[INSTANCE_STATE_ID] [uniqueidentifier] NULL,
	[LOCK_DATE] [datetime] NULL,
 CONSTRAINT [PK_cms_tblViewCache] PRIMARY KEY NONCLUSTERED 
(
	[VIEW_CACHE_ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
) ON [PRIMARY]

GO


А также индексы:
USE [ViewCacheDb]
GO

/****** Object:  Index [PK_cms_tblViewCache]    Script Date: 02/11/2013 09:09:17 ******/
ALTER TABLE [dbo].[cms_tblViewCache] ADD  CONSTRAINT [PK_cms_tblViewCache] PRIMARY KEY NONCLUSTERED 
(
	[VIEW_CACHE_ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON, FILLFACTOR = 80) ON [PRIMARY]
GO

USE [ViewCacheDb]
GO

/****** Object:  Index [IX_InstanceStateId]    Script Date: 02/11/2013 09:09:32 ******/
CREATE NONCLUSTERED INDEX [IX_InstanceStateId] ON [dbo].[cms_tblViewCache] 
(
	[INSTANCE_STATE_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 = 80) ON [PRIMARY]
GO

USE [ViewCacheDb]
GO

USE [ViewCacheDb]
GO
CREATE UNIQUE NONCLUSTERED INDEX [IX_CheckSum] ON [dbo].[cms_tblViewCache] 
(
	[WEBPROJECT_COMPONENT_ID] ASC,
	[CHECK_SUM] 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 = 80) ON [PRIMARY]
GO


Табличка cms_tblViewCache заполняется очень быстро и записи в ней часто обновляются по полям:
[LAST_UPDATE] [datetime] NOT NULL,
	[XML_CACHE] [xml] NOT NULL,
[GENERATION_TIME] [time](7) NULL,
	[LOCK_DATE] [datetime] NULL,

Фрагментация индексов доходит до 99% в течение 2-3 часов. Производительность падает.
Как исправить, чем лечить?
khourshed
Дата: 11.02.2013 09:19:49
Размер таблицы доходит до 12 gb количество записей 1 млн
Ennor Tiegael
Дата: 11.02.2013 09:22:01
khourshed,

А есть какая-нибудь причина, почему на таблице отсутствует кластерный индекс? Дефрагментация куч - довольно специфическое действо...
khourshed
Дата: 11.02.2013 09:26:36
Ennor Tiegael,

Причин нет. Однако делать кластерный индекс на uniqueidentifier не рискнул. Хотя может быть заблуждение.

очень активно юзается IX_TaskCheckSum
khourshed
Дата: 11.02.2013 09:31:20
khourshed
Ennor Tiegael,

Причин нет. Однако делать кластерный индекс на uniqueidentifier не рискнул. Хотя может быть заблуждение.

очень активно юзается IX_TaskCheckSum


IX_CheckSum, пардон
Ennor Tiegael
Дата: 11.02.2013 09:49:19
khourshed,

А и не надо делать его по uniqueidentifier. Особенно, если он генерится не в самой БД. Если система ваша, добавьте столбец с identity и навесьте на него уникальный кластерный индекс. При ваших объемах вполне сойдет int, но если боитесь переполнения, то можно и bigint.

Если система стороннего разработчика, то лучше переадресовать вопрос по поводу отсутствия кластерника им. Ну а потом уже добавлять int identity :)
MasterZiv
Дата: 11.02.2013 11:15:48
khourshed
Фрагментация индексов доходит до 99% в течение 2-3 часов. Производительность падает.
Как исправить, чем лечить?


А расскажи, что же такое эта фрагментация индекса и как ты её мериишь ?
И как, по твоему, оно влияет на производительность ?

К сказанному по поводу отсутствия кластерного индекса присоединяюсь -- странно выглядит в современном MSSQL, но только у тебя вроде бы индексные поля не меняются, ROW ID будет меняться только при миграции записей со страницы на страницу,
что по идее не должно быть часто, все изменяемые поля -- постоянной длины, кроме поля XML, которое по идее должно хранится off the data page, хотя не знаю по MSSQL-ю точно.

В общем, мне кажется, тут не фрагментация виновата, а просто ты не понимаешь, что тормозит.
Какие конкретно операции вызывают подозрения на плохую производительность ?

По фрагментации вот есть статья, вполне вменяемая,

http://blogs.msdn.com/b/jorgepc/archive/2007/12/09/how-to-check-fragmentation-on-sql-server-2005.aspx
khourshed
Дата: 11.02.2013 14:39:58
MasterZiv,
Под фрагментацией я понимаю то что SQL Server Management Studio показывает под заголовком total fragmentation, в терминологии статьи, которую вы мне прислали это скорее всего external fragmentation.
Если сделать Rebuild индекса, производительность увеличивается ощутимо. Но потом опять затухает по мере нарастания фрагментации.

Попробую добавить identity и посмотреть что будет.
Crimean
Дата: 11.02.2013 18:18:04
а зачем вы их с ФФ = 80 то держите? он у вас и так фрагментируется, так вы его еще и изначально полупустым держите
WarAnt
Дата: 11.02.2013 18:46:39
khourshed,

А как вы себе представляете существование индекса по полю типа [uniqueidentifier] без мгновенной дефрагметации?
Оно же не монотонно прирастающее, такие поля в индексах всегда были злом, особенно в PK.