Valor correcto para el factor de relleno para índices agrupados con claves de identidad sustitutas

Tengo una tabla grande que tiene un índice agrupado con una clave primaria de identidad. Estoy decidiendo el valor correcto para el factor de relleno de esta tabla para minimizar las divisiones de página. Mantenemos índices utilizando un script que se ejecuta diariamente, que mide la fragmentación y toma las medidas adecuadas. La tabla contiene columnas de longitud variable.

Lo primero que pensé fue establecerlo en 100 (ya que los registros solo deberían escribirse hasta el final de la tabla), pero supongo que los cambios en las columnas de longitud variable también podrían causar divisiones de página, por lo que ahora me estoy desviando hacia 90.

Cualquier consejo apreciado.

Depende

Es un acto de equilibrio. Si su tabla es de lectura intensiva, sin muchas actualizaciones o eliminaciones, entonces el valor predeterminado (que es 100) debería estar bien.

Si su tabla es muy intensiva en escritura, con muchas actualizaciones, entonces un valor por debajo de 80 podría ser más apropiado.

No hay una fórmula mágica para estas cosas. (AFAIK, si lo hay, hágamelo saber) Lo mejor que puede hacer es tener un entorno de prueba, tener algo de carga de trabajo para probar. Realice los cambios y vea cómo funciona su base de datos con la carga de trabajo.

Nick es bastante correcto.

Si realiza actualizaciones que aumentan el tamaño de un registro en páginas empaquetadas, provocará divisiones de página, pero aparte de eso, con una clave primaria de identidad, nada causará divisiones de página en el índice agrupado.

(A pesar de decir eso, hay 5 tipos de divisiones de página que puede hacer el motor de almacenamiento, y no todas causan fragmentación y movimiento de datos; el que se obtiene al insertar valores de identidad que aumentan monatónicamente es una división al final de la página. Pero Me estoy desviando ...)

He ayudado a muchos clientes con esto y escribí el BOL en torno a todo: si desea elegir un valor como la participación en el terreno, el 70% ha tenido el mayor éxito. Como dice Nick, supervisa y modifica según corresponda.

Elegir un factor de relleno para cualquier índice es un acto de equilibrio de cuánta actividad ocurre que empuja la plenitud de la página hacia el 100% y con qué frecuencia puede tomar medidas correctivas para restablecer el factor de relleno. Debe pensar cuánto espacio se 'desperdiciará' inicialmente en las páginas si establece el factor de relleno realmente bajo, como 50%, pero nuevamente he visto que esto es apropiado en algunos casos.

También debe considerar cómo se usará el índice. Si es solo para búsquedas simples, es posible que se salga con un factor de relleno más bajo y más tiempo entre la reconstrucción / desfragmentación, ya que no va a desperdiciar demasiadas E / S por tener una gran cantidad del índice agrupado escasamente poblado en la memoria. Para realizar escaneos de gran alcance, querrá tener el factor de relleno un poco más alto, para aumentar la E / S y la eficiencia de la memoria.

También está la pregunta OLTP vs DW: por lo general, un DW no cambia, por lo que los índices tendrían un factor de relleno del 100%. OLTP es la parte difícil.

Después de haber resuelto el índice agrupado, recuerde que los no agrupados también necesitarán atención, ya que lo más probable es que se fragmenten.

Al restablecer el factor de relleno, recuerde que puede elegir entre reconstruir y desfragmentar. DBCC INDEXDEFRAG / ALTER INDEX ... REORGANIZE puede restablecer el factor de relleno en algunos casos para índices que no están muy fragmentados.

¡Espero que esto ayude!

(Perdón por la 'respuesta excesiva' - uno de mis botones de acceso rápido, después de haber escrito el código :-)