Para conocer la cantidad de Page Splits por segundo en nuestro sistema disponemos de un contador de rendimiento: “SQLServer:Access Methods” à “Page Splits/sec”. Su valor absoluto nos dirá poco (únicamente si tenemos Page Splits o no) por lo que deberemos correlacionarlos con el número de batchs por segundo y la naturaleza media de los batchs que ejecutemos (procedimientos almacenados, operaciones ad-hoc, etc.).
Como casi siempre, con un ejemplo se ve todo más claro J
Vamos a crear una tabla a la que fijaremos un fillfactor de 50% y analizaremos su comportamiento ante inserciones y reconstrucciones del índice cluster:
USE tempdb
GO
CREATE TABLE [dbo].[fill_fact](
[a] [int] NOT NULL,
[data] [char](1000) NULL,
CONSTRAINT PK_fill_fact PRIMARY KEY CLUSTERED (a) WITH (FILLFACTOR = 50)
)
exec sp_spaceused fill_fact
— 0KB
Tenemos la tabla vacía y unos registros bastante anchos de más de 1000 bytes. Insertamos 4 registros lo cual serán aproximadamente 4 KB de datos.
insert into fill_fact values (1,”)
insert into fill_fact values (3,”)
insert into fill_fact values (5,”)
insert into fill_fact values (7,”)
— ~4KB datos ~media página
exec sp_spaceused fill_fact
— 4 rows, 8 KB datos (1 página)
Podemos ver que estas 4 filas se alojan en la misma página, nos cuadra con el fillfactor por ahora. Si insertamos tres registros más ocuparíamos unos 7 KB lo cual, si se respetara el fillfactor debería producirse un Page Split:
insert into fill_fact values (9,”)
insert into fill_fact values (11,”)
insert into fill_fact values (13,”)
— ~7KB datos = una página con fill 100% => 2 páginas con fill 50%
exec sp_spaceused fill_fact
— 7 rows, 8 KB datos (1 página)
Vemos que las 7 filas siguen en la misma página de datos pues no se ha producido el Page Split. Para que el fillfactor se tenga en cuenta deberemos reconstruir el índice:
ALTER INDEX PK_fill_fact ON fill_fact REBUILD
exec sp_spaceused fill_fact
— 7 rows, 16 KB datos (2 páginas)
Ahora sí J Tenemos 7 filas en 2 páginas, respetando el fillfactor establecido. ¿Quiere decir esto que el fillfactor no es útil? En absoluto. Cuando realizamos modificaciones sobre filas ya existentes o realizamos inserciones en páginas con datos un fillfactor adecuado nos prevendrá de Page Splits perniciosos que nos aumentarían el coste de las operaciones así como la fragmentación. Por ejemplo los siguientes inserts no generarán Page Splits gracias al fillfactor del 50% y que sí se generarían con un fillfactor del 100%. Si os fijáis estamos insertando registros “entrelazados” con las filas de la primera de las páginas (IDs 1,3,5 y 7):
insert into fill_fact values (2,”)
insert into fill_fact values (4,”)
insert into fill_fact values (6,”)
exec sp_spaceused fill_fact
— 10 rows, 16 KB datos (2 páginas)
Obviamente ahora mismo tenemos la primera página prácticamente llena y la segunda a la mitad. Si volvemos a reconstruir el índice veremos cómo se añade una tercera página para poder respetar el fillfactor del 50%:
ALTER INDEX PK_fill_fact ON fill_fact REBUILD
exec sp_spaceused fill_fact
— 10 rows, 24 KB datos (3 páginas)
En conclusión diremos que el fillfactor puede ser muy útil en sistemas donde la cantidad de Page Splits sea significativa pero debe ir siempre acompañada de un plan de mantenimiento que nos permita mantener el fillfactor que determinemos apropiado.
