visual - database engine sql server

¿Por qué la ejecución de una consulta en SQL Azure es mucho más lenta?

Question

SmarterAsp una cuenta de prueba en Azure e implementé mi base de datos desde SmarterAsp .

Cuando ejecuto una consulta dinámica en SmarterAsp/MyDatabase , los resultados aparecieron en 2 segundos .

Sin embargo, la ejecución de la misma consulta en Azure/MyDatabase tomó 94 segundos .

Utilizo SQL Server 2014 Management Studio (versión de prueba) para conectarme a los servidores y ejecutar la consulta.

¿Es esta diferencia de velocidad porque mi cuenta es una cuenta de prueba?

Alguna información relacionada con mi pregunta

la consulta es:

ALTER procedure [dbo].[Pivot_Per_Day]
@iyear int,
@imonth int,
@iddepartment int

as

declare @columnName Nvarchar(max) = ''''
declare @sql Nvarchar(max) =''''

select @columnName += quotename(iDay) + '',''
from (
        Select day(idate) as iDay
        from kpivalues where year(idate)=@iyear and month(idate)=@imonth
        group by idate
        )x

set @columnName=left(@columnName,len(@columnName)-1)

set @sql =''


Select * from (
select kpiname, target, ivalues, convert(decimal(18,2),day(idate)) as iDay   

from kpi

inner join kpivalues on kpivalues.idkpi=kpi.idkpi

inner join kpitarget on kpitarget.idkpi=kpi.idkpi

inner join departmentbscs on departmentbscs.idkpi=kpi.idkpi

where iddepartment=''+convert(nvarchar(max),@iddepartment)+''

group by kpiname,target, ivalues,idate)x

pivot
(
     avg(ivalues)
    for iDay in ('' + @columnName + '')
) p''

execute sp_executesql @sql

La ejecución de esta consulta en 3 servidores diferentes me dio resultados diferentes en términos de tiempo transcurrido hasta que mi tabla dinámica aparece en la pantalla:

Azure - Tiempo transcurrido = 100.165 seg.

Smarterasp.net - Tiempo transcurrido = 2.449 seg.

LocalServer - Tiempo transcurrido = 1.716 seg.

Con respecto a mi cuenta de prueba en Azure, lo hice con el objetivo principal de comprobar si tendré una velocidad mayor que la de Smarter cuando ejecute un procedimiento almacenado como el anterior. Elijo para mi base de datos Nivel de servicio: Básico, Nivel de rendimiento: Básico (5DTU) y Máx. Tamaño 2GB.

Mi base de datos tiene 16 tablas, 1 tabla tiene 145284 filas y el tamaño de la base de datos es de 11 mb. Es una base de datos de prueba para mi aplicación.

Mis preguntas son:

1. ¿Qué puedo hacer para optimizar esta consulta (sp)?
2. ¿Se recomienda Azure para bases de datos pequeñas (100 mb-1 Gb)? Me refiero a rendimiento vs costo!

Conclusiones basadas en tus aportaciones:

• Hice cambios sugeridos a la consulta y se mejoró el rendimiento en más del 50%. Gracias, Remus.
• Probé mi consulta en Azure S2 y el tiempo transcurrido para la consulta actualizada fue de 11 segundos.

• Probé de nuevo mi consulta en P1 y el tiempo transcurrido fue de 0.5 segundos :)

• la misma consulta actualizada en SmarterASP tuvo un tiempo transcurrido de 0,8 segundos.

Ahora está claro para mí cuáles son los niveles en Azure y cuán importante es tener una consulta muy buena (incluso entendí qué es un Índice y su ventaja / desventaja)

Gracias a todos, lucian

Answer 1

( Actualización : la pregunta original se ha cambiado para preguntar también cómo optimizar la consulta, lo que también es una buena pregunta. La pregunta original era por qué la diferencia es de lo que trata esta respuesta).

El rendimiento de las consultas individuales se ve muy afectado por los niveles de rendimiento. Sé que la documentación implica que los niveles se tratan de carga, eso no es estrictamente cierto.

Me gustaría volver a ejecutar su prueba con una base de datos S2 como punto de partida y continuar desde allí.

Estar en una suscripción de prueba no afecta en sí al rendimiento, pero con la cuenta gratuita probablemente esté usando un nivel B que no es realmente utilizable por nada real, ciertamente no para una consulta que demora 2 segundos en ejecutarse localmente.

Incluso moviéndose entre, digamos, S1 y S2 mostrará una diferencia notable en el rendimiento de una consulta individual. Si desea experimentar, recuerde que se le cobra un día por "cualquier parte del día", lo que probablemente esté bien para el nivel S, pero tenga cuidado al probar el nivel P.

Para el fondo; Cuando Azure presentó los nuevos niveles el año pasado, cambiaron el modelo de alojamiento para SQL. Solía ​​ser que muchas bases de datos se ejecutarían en un sqlserver.exe compartido. En el nuevo modelo, cada base de datos obtiene efectivamente su propio sqlserver.exe que se ejecuta en un entorno limitado de recursos. Así es como controlan el "uso de DTU", pero también afecta el rendimiento general.

Answer 2

Esta es, ante todo, una cuestión de rendimiento. Está tratando con un código de bajo rendimiento de su parte y debe identificar el cuello de botella y solucionarlo. Estoy hablando de la mala actuación de 2 segundos ahora. Siga las pautas en Cómo analizar el rendimiento de SQL Server . Una vez que obtenga esta consulta para que se ejecute de forma localmente aceptable para una aplicación web (menos de 5 ms), puede hacer la pregunta de portarla a Azure SQL DB. En este momento, su cuenta de prueba solo está resaltando las ineficiencias existentes.

Después de la actualización

...
@iddepartment int
...
iddepartment=''+convert(nvarchar(max),@iddepartment)+''
...

¿así que qué es lo? ¿Es la columna iddepartment un int o un nvarchar ? ¿Y por qué usar (max) ?

Esto es lo que deberías hacer:

• parametrizar @iddepartment en el SQL dinámico interno
• dejar de hacer la conversión nvarchar(max) . Hacer que los tipos iddepartment y @iddertment coincidan
• Asegurar índices en iddepartment y todos los idkpi s

Aquí es cómo parametrizar el SQL interno:

set @sql =N''
Select * from (
select kpiname, target, ivalues, convert(decimal(18,2),day(idate)) as iDay   
from kpi
inner join kpivalues on kpivalues.idkpi=kpi.idkpi
inner join kpitarget on kpitarget.idkpi=kpi.idkpi
inner join departmentbscs on departmentbscs.idkpi=kpi.idkpi
where iddepartment=@iddepartment
group by kpiname,target, ivalues,idate)x
pivot
(
     avg(ivalues)
    for iDay in ('' +@columnName + N'')
) p''

execute sp_executesql @sql, N''@iddepartment INT'', @iddepartment;

Los índices de cobertura son, por lejos, la solución más importante. Eso obviamente requiere más información de la que está aquí presente. Lea los Índices de Diseño incluyendo todos los subcapítulos.

Como comentario más general: este tipo de consultas se columnstores a los almacenes de columnstores más que a los almacenes de filas, aunque creo que el tamaño de los datos es, básicamente, pequeño. Azure SQL DB es compatible con los índices de almacén de columnas agrupados y actualizables, puede experimentar con ellos en previsión de un tamaño de datos serio. Requieren Enterprise / Development en el cuadro local, es cierto.

Answer 3

No tiene nada que ver con el hecho de que su cuenta sea de prueba, se debe al menor nivel de rendimiento que ha seleccionado.

En otro servicio (SmarterAsp) y en la instancia local en ejecución, probablemente no tenga restricciones de rendimiento sino restricciones de tamaño.

En este punto, es imposible reunir lo que realmente significa DTU / qué tipo de número de DTU está asociado con un servidor Sql instalado en su máquina local o en cualquier otro proveedor de alojamiento.

Sin embargo, hay algunos buenos análisis ( https://cbailiss.wordpress.com/2014/09/16/performance-in-new-azure-sql-database-performance-tiers/ ) realizado con respecto a esto, pero nada oficial.