La requête Delete est annulée automatiquement sur la base de données SQL Azur.

Question

J'ai un problème avec l'exécution des instructions delete sur la base de données SQL Azure avec une grande quantité de données. J'ai une table des ventes avec ~ 5 millions d'enregistrements sur la base de données SQL Azure. Lorsque j'exécute une procédure stockée pour supprimer toutes les données de cette table, elle s'exécute pendant un certain temps, puis un nouveau processus est généré avec un nouvel identifiant et le processus existant commence à revenir en arrière et après l'annulation lorsque le nouveau processus commence à supprimer les données, puis le nouveau processus génère à nouveau un autre processus et commence le rollback et cette même répétition continue pour toujours. Enfin, après plusieurs heures, la procédure stockée échoue et les données ne sont pas supprimées. Je possède la base de données SQL Azure avec 100 unités de connexion en mode point.

Est-ce que quelqu'un sait ce qui peut arriver?

Answer 1

Il semble que vous soyez confronté à une limitation. You can read more about that he re. Vous pouvez également vérifier le sys.event_log pour voir s'il y a des événements de limitation. La meilleure solution serait de diviser la suppression en plus petits morceaux en utilisant une forme de requête de pagination.

Answer 2

Le processus de suppression peut atteindre les limites de ce niveau. Vous pouvez confirmer cela en exécutant la requête suivante pendant que le processus de suppression est en cours d'exécution.

SELECT 
    (COUNT(end_time) - SUM(CASE WHEN avg_cpu_percent > 80 THEN 1 ELSE 0 END) * 1.0)/COUNT(end_time) AS 'CPU Fit Percent' 
    ,(COUNT(end_time) - SUM(CASE WHEN avg_log_write_percent > 80 THEN 1 ELSE 0 END) * 1.0)/COUNT(end_time) AS 'Log Write Fit Percent' 
    ,(COUNT(end_time) - SUM(CASE WHEN avg_data_io_percent > 80 THEN 1 ELSE 0 END) * 1.0)/COUNT(end_time) AS 'Physical Data Read Fit Percent' 
FROM sys.dm_db_resource_stats 

objectif de niveau de --service (SLO) de 99,9% < = aller à niveau suivant

Hope this helps ..

Cordialement,

Alberto Morillo