¿Cuánto ocupan mis tablas y mis índices en Sql Azure (y no Azure)?

El tamaño de la base de datos, siempre es importante, en Sql Azure más si cabe, pues afecta directamente a nuestro bolsillo.

Hace bastante tiempo publiqué un script, que se volvió bastante popular, que permite responder la pregunta ¿Cuanto ocupan mis tablas y mis vistas indexadas en Sql Server?, este script hace uso del procedimiento almacenado del sistema sp_spaceused que por desgracia no está disponible en SQL Azure, haciendo que el script anterior no funcione. Así que me he puesto manos a la obra y he hecho una versión similar que si que funciona en SQL Azure (por su puesto en un SQL Server ‘on premise’).

SELECT   

      sys.objects.name AS Name, SUM(reserved_page_count) * 8.0 / 1024 AS [Reserved in MB], SUM(used_page_count) * 8.0 / 1024 AS [Used in MB], MAX(row_count) AS [Number of rows]

FROM   

      sys.dm_db_partition_stats, sys.objects

WHERE   

      sys.dm_db_partition_stats.object_id = sys.objects.object_id

GROUP BY sys.objects.name

UNION ALL

SELECT 

    sys.indexes.name AS Name, SUM(reserved_page_count) * 8.0 /1024 AS [Reserved in MB], SUM(used_page_count) * 8.0 / 1024 AS [Used in MB], MAX(row_count) AS [Number of rows]

FROM

    sys.dm_db_partition_stats, sys.indexes

WHERE

    sys.dm_db_partition_stats.object_id = sys.indexes.object_id

    AND sys.dm_db_partition_stats.index_id = sys.indexes.index_id

    AND sys.dm_db_partition_stats.index_id > 0

GROUP BY sys.indexes.name

ORDER BY 2 DESC

Espero que os sea útil, un saludo.

3 comentarios sobre “¿Cuánto ocupan mis tablas y mis índices en Sql Azure (y no Azure)?”

  1. Un apunte y algo a lo que habitualmente no le prestamos mucha atención, tendrá importancia también la definición de los campos de nuestras tablas, campos nchar que muchas veces utilizamos sin necesidad, inclusión de campos de longitud variable varchar o la longitud de algunos campos que por defecto utilizan mucha mas longitud de la que realmente necesitan nuestras aplicaciones como campos decimales, float y otros.

    Un saludo.

  2. Cierto es Juan. Buen punto punto, mucha gente está dejando de prestar cuidado a elegir los tipos de datos adecuados cuando diseña sus tablas pensando: ¿Qué más da? Con lo barato que es el disco…

    Pero elegir buenos tipos de datos no solo es importante por lo que estos vayan a ocupar sino por el rendimiento. No es lo mismo a la hora de leer un registro de la base de datos leer N bytes, que nN bytes.

    Y no solo es importante por la lectura de los datos desde disco. Cuanto más ajustado sea el tamaño de nuestros registros, ¡más caben en la caché! y por tanto más probabilidad habrá de que les leamos más eficientemente.

    Un saludo.

Responder a rcorral Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *