Inserciones SQL rápidas sin ACTUALIZACIONES

Question

Estamos utilizando una única tabla para la auditoría en una base de datos de SQL Server 2008.

La arquitectura de tabla única funciona muy bien, es simple de consultar, se adapta a los cambios de esquema.

Pero es un cuello de botella importante para toda la base de datos. Todos los INSERTOS y ACTUALIZACIONES deben pasar por la tabla de auditoría.

Ya usamos NOLOCK HINT para las instrucciones SELECT.

Como no hay ACTUALIZACIONES en esta tabla, ¿hay alguna sugerencia para mejorar el rendimiento de las instrucciones INSERT?

Answer 1

¡Asegúrese de tener un índice agrupado primario INT (o BIGINT) IDENTIDAD sobre la mesa! Y preferiblemente no hay otros índices (si es posible) - ésos ralentizarían las inserciones.

Es un error común que dado que la tabla solo necesita INSERTAR y casi ninguna lectura, debe "guardarse" el problema de una clave principal agrupada.

como la diosa de la indización de SQL Server, Kimberly Tripp, explica en su excelente blog The Clustered Index Debate continues:

inserciones son más rápidos en un tabla agrupada (pero sólo en el "derecho" tabla agrupada) de comparado con un montón . El problema principal aquí es que las búsquedas en IAM/PFS para determinar la ubicación de inserción en un montón son más lentas que en una tabla agrupada (donde se conoce la ubicación de inserción, definida por la clave agrupada). Las inserciones son más rápidas cuando se insertan en una tabla donde se define el orden (CL) y donde esa orden es cada vez mayor.

lo tanto un derecho índice agrupado puede acelerar sus inserciones, y aquí significa estática (no cambia), único, lo más pequeña posible (INT o BIGINT) y de preferencia cada vez mayor (no hay divisiones de página y por lo tanto, no hay penalización de rendimiento).

Además, si su tabla solo recibe inserciones y no hay actualizaciones/eliminaciones, debe asegurarse de usar un 100% FILLFACTOR en el índice agrupado para llenar completamente esas páginas del servidor SQL.

Marc

Answer 2

Las únicas recomendaciones que haría que son:

• asegurarse de que está escribiendo los valores que no son cadenas tanto como sea posible
• encapsular sus escrituras en la auditoría a través de procedimientos almacenados
• agarrar ningún otro dato de llamadas a procedimientos almacenados o,
• considere usar una vista para este fin separada en su programa de auditoría. Asegúrese de que sus uniones sean lo más mínimas posible. Esta vista sería para búsquedas de PK para mensajes de auditoría, etc. al tratar de ubicar el FK para sus datos de cadena.
• no es una recomendación, pero es un hecho: menos índices significan inserciones más rápidas + selecciones más lentas.
• considere archivar las filas de auditoría "antiguas" a otra tabla. Mantenga la tabla de auditoría lo más pequeña posible. Mueva esas filas de auditoría anteriores a otra tabla. Para informes/consultas, cree una vista que join o union las auditorías 'en vivo' y 'anteriores'.

Answer 3

Si sólo está realizando adiciones a las tablas de auditoría y ejecutar informes que van a terminar siempre para la realización de los recorridos de tablas, considere la eliminación de los índices de la tabla.