MS SQL Server
  1. MS SQL Server
  3. Procédure stockée longue durée sans garder la connection ouverte à la database Azure
Intereting Posts
Comparaison de strings dans SQL Server Grouper par une list dans la clause where et ensuite montrer à la ligne si elle a une valeur ou est nulle Obtenir la plage de nombres à partir de la table dans MSSQL Puis-je empêcher SQL Server Management Studio 2017 de préfixer des scripts avec des "parameters de script"? Impossible de grouper par colonne Comment afficher une colonne de date d'aujourd'hui, une colonne d'heure, une colonne de date précédente, une colonne d'heure Nombre maximal d'occurrences consécutives d'une valeur dans SQL Server Cette instruction de table UPDATE est-elle correcte dans un sujet msdn? PowerBI – Comment améliorer la requête envoyée à SQL Server lors de l'utilisation de DirectQuery? Script SQL pour modifier toutes les references de table dans toutes les procédures stockées Erreur Open DataReader avec SqlConnection Comment puis-je déterminer si le text peut être converti en date? J'ai besoin de déployer mon logiciel sur d'autres machines avec la database SQL / T-SQL court-circuit L'utilisation de IS NOT NULL pour plusieurs colonnes

Procédure stockée longue durée sans garder la connection ouverte à la database Azure

Nous avons une procédure stockée très longue exécutant le travail ETL afin de charger datatables de la table brute dans le schéma en écanvas (Fact – Dimensions) dans la database Azure.

Cette procédure stockée prend environ 10 heures à 20 heures sur plus de 10 millions de lignes (en utilisant l'instruction MERGE).

Pour le moment, nous exécutons la procédure stockée à partir du code C # (ADO.NET) en conservant CommandTimeout = 0 (pour toujours). Mais parfois, la connection est abandonnée car la connection à la database Azure est instable.

Est-il possible d'exécuter une procédure stockée au niveau de la database sans maintenir la connection ouverte en permanence, puis de consigner le process de la procédure stockée dans le tableau Progression pour suivre la progression?

Je vois quelques recommandations:

  1. Le travail de l'agent ne semble pas possible sur la database Azure car il ne prend pas en charge pour le moment.

  2. SqlCommand.BeginExecuteNonQuery : Je ne suis pas sûr que 100% BeginExecuteNonQuery garde la connection ouverte sous le capot ou non.

Y a-t-un autre moyen de faire ça?

Azure Data Factory a une tâche de procédure stockée qui pourrait le faire. Il a une propriété timeout dans la section policy qui est facultative. Si vous le laissez, il est par défaut infini: 

 "policy": { "concurrency": 1, "retry": 3 },

Si vous spécifiez le timeout d'expiration à 0 lors de la création de l'activité, vous verrez disparaître lorsque vous provisionnez la tâche dans le portail. Vous pouvez également essayer de spécifier le timeout à 1 jour (24 heures), par exemple "timeout": "1.00:00:00" , bien que je ne l'ai pas testé expire correctement.

Vous pouvez également définir le timeout à 0 dans la string de connection bien que je n'ai pas encore testé cette option, par exemple 

 { "name": "AzureSqlLinkedService", "properties": { "type": "AzureSqlDatabase", "typeProperties": { "connectionSsortingng": "Server=tcp:<servername>.database.windows.net,1433;Database=<databasename>;User ID=<username>@<servername>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=0" } } }

Je considérerais ceci comme plus simple qu'Azure Automation mais c'est un choix personnel. Peut-être essayer les deux options et voir ce qui fonctionne le mieux pour vous.

Je suis d'accord avec certains des autres commentaires qui ont été faits au sujet du MERGE prendrait trop de time pour ce volume de documents. Je soupçonne que votre table n'a pas d'indexing appropriée pour prendre en charge le MERGE ou que vous utilisez un niveau de service trop bas. Sur quel niveau de service travaillez-vous, par exemple Basic, Standard, Premium (P1-P15). Pensez à soulever une question distincte avec le DDL de votre table, y compris les index et quelques exemples de données, l'instruction MERGE et le niveau de service, je suis sûr que cela peut aller plus vite.

En tant que test / solution rapide, vous pouvez toujours refactoriser le MERGE comme INSERT / UPDATE / DELETE – je parie que ça va plus vite. Laissez nous savoir.

La connection entre Azure Data Factory et la database Azure doit être stable. Si ce n'est pas le cas, vous pouvez get des tickets de support. Cependant, pour l'architecture de cloud (et en fait toute architecture), vous devez prendre de bonnes décisions de design qui permettent la possibilité de choses qui vont mal . Cela signifie architecturellement, vous devez concevoir pour la possibilité de la chute de la connection, ou l'échec du travail. Par exemple, assurez-vous que votre travail est relancé depuis le sharepoint défaillance, assurez-vous que le rapport d'erreur est bon, etc.

Aussi, par expérience, count tenu de vos volumes de données (que je considère comme faibles), ce travail prend beaucoup trop de time. Il doit y avoir un problème avec lui ou le design. C'est ma plus forte recommandation que vous essayiez de résoudre ce problème.

Vous pouvez utiliser le runbook Azure Automation.

https://azuree.microsoft.com/en-us/blog/azuree-automation-your-sql-agent-in-the-cloud/?cdn=disable

https://gallery.technet.microsoft.com/scriptcenter/How-to-use-a-SQL-Command-be77f9d2

https://azuree.microsoft.com/en-us/blog/azuree-automation-runbook-management/?cdn=disable

http://www.sqlservercentral.com/articles/Azure+SQL+database/117804/

J'espère que cela t'aides.

Cordialement,

Alberto Morillo