2009-10-15 34 views
9

¿Hay alguna manera de encontrar estadísticas sobre el recuento de lectura y escritura de tablas en SQL Server 2005/2008?¿Cómo averiguar las estadísticas de lectura/escritura de la tabla SQL Server?

Estoy buscando específicamente DMVs/DMFs sin usar desencadenantes o auditorías.

El objetivo aquí es averiguar factor de relleno adecuado para los índices - ¿Tienes una idea de este artículo (Fill Factor Defined).


[ACTUALIZACIÓN] Hay una pregunta de seguimiento en ServerFault
How to determine Read/Write intensive table from DMV/DMF statistics

+0

El enlace en la pregunta actual redirige a lo que parece ser un virus. –

Respuesta

8

Recuerde 'tabla' significa el índice agrupado o el 'montón'.

+0

@Remus: Después de un poco de investigación, la combinación de todos los DMV/DMF antes mencionados era lo que necesitaba para averiguar qué valores de Factor de relleno establecer. Haré una pregunta de seguimiento más tarde para ver si lo que he encontrado es correcto o no. Gracias, Remus. – Sung

3

Para determinar un factor de relleno adecuado para los índices de una tabla, debe observar el número de divisiones de página que se producen. Esto se muestra en sys.dm_db_index_operational_stats:

Cuenta de asignación de hoja: Número total de divisiones de página en el nivel de hoja del índice.

Cuenta de asignación no hoja: Número total de divisiones de página por encima del nivel de hoja del índice.

Número de páginas fusionadas: Número total de páginas fusionadas en el nivel de hoja del índice.

Después de investigar un poco, he visto algunas publicaciones que dicen que los números de división de la página del DMV no son útiles (no lo he confirmado personalmente), pero también hay una página de contador de rendimiento splits/sec "(pero está solo en el nivel de instancia de SQL Server).

Utilizo la regla de oro de que las tablas ordinarias usan el factor de relleno predeterminado del 90%, las tablas de inserción altas en algún lugar entre el 70 - 85% (dependiendo del tamaño de la fila). Las tablas de solo lectura pueden utilizar un factor de relleno del 100%

+0

@Mitch: Permítame ver si "los números de división de página del DMV no son tan útiles" después de actualizar el factor de relleno en algunas tablas muy actualizadas con recuento de asignación de hoja alta y sin hoja y le responderemos sobre ese problema. Gracias por señalar eso por mí. – Sung

17

La siguiente consulta se puede utilizar para encontrar el número de lecturas y escrituras en todas las tablas de una base de datos. Este resultado de consulta se puede exportar a un archivo CSV y luego, al usar las fórmulas de Excel, puede calcular fácilmente la relación de lectura/escritura. Muy útil en la planificación de índices en una tabla

DECLARE @dbid int 
SELECT @dbid = db_id('database_name') 

SELECT TableName = object_name(s.object_id), 
     Reads = SUM(user_seeks + user_scans + user_lookups), Writes = SUM(user_updates) 
FROM sys.dm_db_index_usage_stats AS s 
INNER JOIN sys.indexes AS i 
ON s.object_id = i.object_id 
AND i.index_id = s.index_id 
WHERE objectproperty(s.object_id,'IsUserTable') = 1 
AND s.database_id = @dbid 
GROUP BY object_name(s.object_id) 
ORDER BY writes DESC 
+0

¿Podemos tener un filtro de fecha? –

+0

No, no podemos tener un filtro de fecha @PhilipMorris –

1

Si usted tiene un buen índice agrupado (es decir, cada vez mayor, único, estrecho), entonces las verdaderas cuestiones determinantes para el factor de relleno son la forma en que se actualiza la mesa y los tipos de datos de las columnas Si las columnas son de tamaño fijo (por ejemplo, entero, decimal, flotante, Char) y no admiten nulos, una actualización no puede aumentar el almacenamiento requerido para una fila.Dado el buen índice agrupado, debe elegir un factor de relleno de 90+ incluso 100 ya que las divisiones de página no ocurrirán. Si tiene algunas columnas de longitud variable (por ejemplo, un Varchar para guardar el nombre de usuario) y las columnas rara vez se actualizan después de la inserción, puede conservar un factor de relleno relativamente alto. Si tiene datos de una longitud muy variable (por ejemplo, rutas UNC, campos de comentarios, XML), entonces el factor de relleno debe reducirse. Particularmente si las columnas se actualizan con frecuencia y crecen (como columnas de comentarios). Los índices no agrupados generalmente son los mismos, excepto que la clave de índice puede ser más problemática (no única, quizás no siempre en aumento). Creo que sys.dm_db_index_physical_stats ofrece las mejores métricas para esto, pero es después del hecho. Observe el tamaño de registro avg/min/max, el tamaño de fragmentación medio, el espacio de página avg utilizado para obtener una imagen de cómo se utiliza el espacio de índice. HTH.

Cuestiones relacionadas