La mayoría de DBAs conocen este término y lo asocian inmediatamente con el porcentaje de llenado de las páginas de los índices. Un error habitual es presuponer que este porcentaje se mantiene automáticamente durante las operaciones de inserción, borrado y actualización de las filas de nuestra tabla/índice. La razón de esto es muy sencilla: si tuviéramos que realizar todas las operaciones necesarias para mantener ese porcentaje intacto continuamente deberíamos realizar más Page Splits de los que generaríamos con un fillfactor del 100% con lo que el fillfactor perdería toda razón de ser.

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.

 

0 Shares:
Deja una respuesta

Tu dirección de correo electrónico no será publicada.

You May Also Like

Mantenimiento de SQL Server para Dummies

Cuando tomamos control de un servidor SQL Server en Flex Services, nosotros como operadores tenemos que sentirnos seguros con lo que estamos asumiendo. Para ello, hacemos un análisis del servidor donde revisamos elementos importantes del servidor como configuración del SQL, planes de mantenimiento, etc. En esta sesión, te enseñaremos lo importante de los diversos elementos básicos que revisamos para asegurarnos que tomamos el control de un servidos SQL Server que no nos va a dar sorpresas.