Deseamos proponerte la mejor información que hemos encontrado online. Deseamos que te resulte de utilidad y si deseas compartir cualquier detalle que nos pueda ayudar a mejorar hazlo libremente.
Solución:
Estaba igualmente confundido al mirar el precio de esos dos niveles. 100 DTU en estándar cuestan $ 150 / mes y 125 DTU en Premium cuestan $ 465 / mes, pensé que algo más debe explicar esa disparidad. Creo que esta línea de https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu#choosing-a-service-tier-in-the-dtu-based -el modelo de compra debe explicar la diferencia:
| Standard | Premium
IO throughput (approximate) | 2.5 IOPS per DTU | 48 IOPS per DTU
IO latency (approximate) | 5 ms (read), 10 ms (write) | 2 ms (read/write)
Así que parece que una DTU Premium vale 19 veces más que una DTU estándar
El rendimiento de las bases de datos de Azure se expresa en términos de DTUS, lo que significa la cantidad de transacciones que se pueden completar por segundo. Además, también limita la cantidad máxima de memoria, CPU, IO que obtendrá su base de datos. Consulte la tabla a continuación para obtener más detalles y atentos al apartado de solicitudes de sesión..
Espero que la imagen de arriba aclare las diferencias entre los diferentes niveles de la base de datos. Más abajo está lo que dice la documentación de Azure sobre cuándo usar diferentes niveles de la base de datos.
Siempre que desee estimar el rendimiento de la base de datos de Azure, querrá consultar a continuación DMVS, que brinda más detalles sobre el uso de DTU expresado en términos de IO, registro, memoria, CPU.
–Este DMV contiene datos de solo una hora, pero se capturan cada 15 segundos
SELECT
AVG(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
MAX(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
AVG(avg_data_io_percent) AS 'Average Data IO In Percent',
MAX(avg_data_io_percent) AS 'Maximum Data IO In Percent',
AVG(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
MAX(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
AVG(avg_memory_usage_percent) AS 'Average Memory Usage In Percent',
MAX(avg_memory_usage_percent) AS 'Maximum Memory Usage In Percent'
FROM sys.dm_db_resource_stats;
–Este DMV contiene datos de 14 días con un intervalo de captura de 5 minutos
SELECT start_time, end_time,
(SELECT Max(v)
FROM (VALUES (avg_cpu_percent), (avg_physical_data_read_percent), (avg_log_write_percent)) AS value(v)) AS [avg_DTU_percent]
FROM sys.resource_stats
WHERE database_name = ''
ORDER BY end_time DESC;
Siempre que vea una métrica de DTU consistentemente al 90%, es un indicador de cuello de botella y se puede solucionar de la misma manera, solucionamos los problemas de nuestros servidores locales.
Digamos, por ejemplo, que ve una CPU constante al 90 % durante un período de tiempo a partir de los datos capturados a través del DMV, puede comenzar con la recopilación de consultas que causan una alta CPU, ver si se pueden ajustar para consumir menos CPU. Cuando todo sus esfuerzos de ajuste están agotados, entonces es posible que deba actualizar definitivamente a un nivel de nivel superior
Referencias:
https://azure.microsoft.com/en-in/documentation/articles/sql-database-performance-guidance/#monitoring-resource-use-with-sysresourcestats
Esta vez, el motivo fue que SQL Azure cambió de opinión sobre qué índice usar para una consulta que se ejecutaba con frecuencia. SQL Azure a veces decide que cambiar un índice utilizado es quizás una buena idea (según las métricas recopiladas). En el momento en que se observó el problema, este mecanismo carecía de validación: una vez que la consulta se cambiaba a otro índice, el motor de la base de datos no validaba que hubiera una mejora real. No tengo idea si esto cambió desde entonces. La forma de solucionar esta situación es utilizando WITH INDEX insinuación.
La mejora del rendimiento que observamos no se debió a cambiar el nivel de rendimiento en sí mismo, solo cuando Standard cambió a Premium, presumiblemente hubo un cambio de hardware y, por lo tanto, se borraron las estadísticas de la base de datos y el motor de la base de datos reconsideró los planes de consulta una vez más y así cuando cambiamos a Premium el motor simplemente se restableció al plan anterior, es por eso que obtuvimos la mejora del rendimiento esa vez.
Aquí puedes ver las comentarios y valoraciones de los usuarios
Más adelante puedes encontrar las ilustraciones de otros sys admins, tú además tienes la habilidad dejar el tuyo si dominas el tema.