Dépanner le pilote go-mssqldb

Cet article propose des solutions aux erreurs courantes et aux problèmes de connectivité avec le go-mssqldb pilote.

Commencez par les vérifications les plus simples

Avant d’activer la journalisation détaillée ou de modifier les paramètres du pool, parcourez la liste suivante :

  1. Vérifiez la portée de base : nom du serveur, port, règles du pare-feu, et si SQL Server ou Azure SQL accepte les connexions.
  2. Vérifiez les entrées d’authentification : nom du pilote, nom d’utilisateur, mot de passe, format de domaine ou fedauth configuration.
  3. Vérifiez les paramètres TLS : encrypt, les chemins de certificat, hostnameincertificate, et si TrustServerCertificate cela est approprié pour l’environnement.
  4. Ce n’est qu’une fois la connexion correctement configurée que vous n’examinez l’épuisement du pool, les connexions périmées, la logique de nouvelle tentative et le diagnostic des requêtes lentes ou bloquées.

Utilisez les premières sections de cet article pour les défaillances de configuration de connexion. Utilisez les sections suivantes seulement après que les connexions réussissent au moins parfois, puis échouent sous charge, après un temps d’inactivité ou lors du basculement.

Erreurs de connexion

Les sections suivantes traitent des messages d’erreur courants liés à la connexion et de leurs solutions.

Impossible d’ouvrir la connexion TCP

Message d’erreur: unable to open tcp connection with host 'localhost:1433': dial tcp 127.0.0.1:1433: connectex: No connection could be made because the target machine actively refused it.

Causes et solutions :

  • SQL Server ne tourne pas. Démarrez le service SQL Server.
  • TCP/IP n’est pas activé. Ouvrez Gestionnaire de configuration SQL Server et activez TCP/IP dans lesprotocoles> réseau SQL Server.
  • Mauvais port. Vérifiez le port dans Gestionnaire de configuration SQL Server ou utilisez SQL Server Browser pour les instances nommées.
  • Le pare-feu bloque le port. Ajoutez une règle d’entrée pour le port 1433 (ou votre port configuré).

Échec de la connexion pour l’utilisateur

Message d’erreur: mssql: login error: Login failed for user '<user>'.

Causes et solutions :

  • Nom d’utilisateur ou mot de passe incorrect. Vérifiez les références.
  • L’authentification SQL Server est désactivée. Activez SQL Server et le mode authentification Windows dans les propriétés du serveur.
  • La connexion n’existe pas. Créez la connexion dans SQL Server.
  • L’identifiant de connexion n’a pas accès à la base de données cible. Accorder l’accès à la base de données avec CREATE USER.

Erreurs de validation de certificat

Message d’erreur: TLS Handshake failed: x509: certificate signed by unknown authority

Causes et solutions :

  • Le serveur utilise un certificat auto-signé. Fournir le chemin du certificat avec le certificate paramètre ou, serverCertificate ou définir TrustServerCertificate=true uniquement pour le développement.
  • Le certificat de l’autorité de certification n’est pas dans le magasin de certificats de confiance du système. Ajoutez le certificat d’AC au magasin de confiance du système d’exploitation ou spécifiez-le avec le certificate paramètre.
  • Non-correspondance du nom d’hôte. Utilisez hostnameincertificate pour spécifier le nom attendu dans le certificat.

Pour plus d’informations, voir Chiffrement et certificats.

Délai d’attente de la connexion expiré

Message d’erreur: unable to open tcp connection with host '<server>:1433': dial tcp: i/o timeout

Causes et solutions :

  • Problèmes de connectivité réseau. Vérifiez que vous pouvez accéder au serveur en utilisant telnet <server> 1433 ou Test-NetConnection -ComputerName <server> -Port 1433.
  • Défaillance de la résolution DNS. Vérifiez que le nom d’hôte se résout correctement.
  • Augmentez dial timeout ou connection timeout dans la chaîne de connexion.

Erreurs d’authentification

Les sections suivantes traitent des messages d’erreur d’authentification.

Échecs d’authentification NTLM

Message d’erreur: NTLM authentication failed

Causes et solutions :

  • Format de domaine incorrect. Utilisez DOMAIN\user dans le paramètre user id. Au format URL, encodez la barre oblique inverse comme %5C.
  • Mauvais mot de passe. Vérifiez le mot de passe du domaine.

Échecs d’authentification Kerberos

Message d’erreur: krb5: cannot resolve KDC for realm

Causes et solutions :

  • Manquant ou mal configuré /etc/krb5.conf. Vérifiez que la [realms] section contient la bonne adresse KDC pour votre domaine.
  • Pas de billet valide. Exécutez klist pour vérifier la présence d’un ticket valide, ou exécutez kinit pour en obtenir un.
  • Fichier Keytab non trouvé. Vérifiez le chemin dans le krb5-keytabfile paramètre.

Pour plus d’informations, voir SQL Server et Authentification Windows.

Échecs de l’authentification Microsoft Entra ID

Message d’erreur : clientCredentialFromCert: error reading certificate: ... ou DefaultAzureCredential: failed to acquire a token

Causes et solutions :

  • Mauvais identifiant client, identifiant locataire ou secret client. Vérifiez les valeurs dans la chaîne de connexion ou les variables d’environnement.
  • L’identité gérée n’est pas configurée sur l’hôte. Vérifiez l’identité dans le portail Azure.
  • Import de package azuread manquant. Importez github.com/microsoft/go-mssqldb/azuread et utilisez le nom du pilote azuresql.

Pour plus d’informations, consultez l’authentification d’ID Microsoft Entra.

Connexion échouée pour l’utilisateur » (nom d’utilisateur vide)

Message d’erreur: mssql: login error: Login failed for user ''.

Cause : Tu as utilisé sql.Open("sqlserver", ...) avec un fedauth paramètre. L’authentification Entra ID nécessite le azuresql nom du conducteur enregistré par le azuread paquet. Avec le pilote standard sqlserver , le fedauth paramètre est ignoré et le pilote tente une authentification SQL sans nom d’utilisateur.

Solution : Importez le paquet azuread et utilisez le nom de pilote azuresql :

import _ "github.com/microsoft/go-mssqldb/azuread"

db, err := sql.Open("azuresql",
    "sqlserver://<server>.database.windows.net?database=AdventureWorks2025&fedauth=ActiveDirectoryDefault&encrypt=true&TrustServerCertificate=false")
if err != nil {
    panic(err)
}

Pour plus d’informations, consultez l’authentification d’ID Microsoft Entra.

Erreurs de requête

Les sections suivantes traitent des messages d’erreur d’exécution des requêtes.

LastInsertId non pris en charge

Message d’erreur: LastInsertId is not supported. Please use the OUTPUT clause or add 'select ID = convert(bigint, SCOPE_IDENTITY())' to the end of your query.

Solution : Le go-mssqldb pilote ne prend pas en charge LastInsertId(). Utilisez une clause ou une OUTPUT requête SCOPE_IDENTITY() séparément.

Tableau temporaire non trouvé

Message d’erreur: mssql: Invalid object name '#TempTable'.

Cause: Les tables temporaires sont propres à chaque connexion. Si vous créez une table temporaire dans un appel et l’interrogez dans un autre, il se peut que des connexions différentes du pool soient utilisées.

Solution : utiliser db.Conn(ctx) pour épingler sur une seule connexion, ou encapsuler des opérations dans une transaction.

Pour plus d’informations, consultez Procédures stockées.

Azure SQL errors

Les sections suivantes traitent des erreurs spécifiques à Azure SQL Database.

Numéros d’erreur de connexion transitoires

Utilisez la liste partagée suivante comme référence pour les erreurs transitoires d’établissement de connexion et les échecs de transport de chemin de requête éligibles à une tentative bornée :

Les erreurs suivantes sont temporaires lorsqu’elles se produisent pendant l’établissement de la connexion ou lors de l’envoi d’une demande au serveur. Réessayez après une courte temporisation limitée. Les erreurs qui persistent au-delà de quelques nouvelles tentatives indiquent généralement un problème de configuration (serveur incorrect, autorisations manquantes, quota épuisé) qui n’est pas résolu.

Error Message Résolution des problèmes
64 A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) La connexion TCP est interrompue pendant l’établissement de la connexion. Ce n’est pas un échec d’identification. S’il persiste, recherchez l’instabilité du réseau côté client ou un appareil intermédiaire qui supprime les connexions semi-établies.
233 The client was unable to establish a connection because of an error during connection initialization process before login. Échec du transport ou du protocole TLS avant connexion. Le serveur le retourne généralement lorsqu’il ne peut pas accepter la connexion (épuisement des ressources, connexions maximales atteintes ou client non pris en charge). Ce n’est pas un échec d’identification. Vérifiez l’intégrité du serveur, puis vérifiez le délai d’expiration de connexion du client, les paramètres TLS et la compatibilité des versions du client/serveur TLS.
4060 Cannot open database "%.*ls" requested by the login. The login failed. La connexion s’authentifie, mais ne peut pas ouvrir la base de données demandée. Les causes transitoires incluent le fait que la base de données soit en transition (basculement, restauration, mise à l’échelle) ou qu’elle soit en pause automatique. Les causes persistantes (la base de données n’existe pas, la connexion n’a pas accès) ne seront pas corrigées par nouvelle tentative ; vérifiez le nom de la base de données, le mappage de connexion et l’état de la base de données.
4221 Login to read-secondary failed due to long wait on 'HADR_DATABASE_WAIT_FOR_TRANSITION_TO_VERSIONING'. Le réplica n’est pas disponible pour la connexion, car les versions de ligne sont manquantes pour les transactions qui étaient en cours de vol lorsque le réplica a été recyclé. Annulez ou validez les transactions actives sur le serveur principal pour résoudre le problème. Réduisez en évitant les transactions d’écriture longues sur le serveur principal.
10053 A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An established connection was aborted by the software in your host machine.) Le côté local abandonne la connexion. Vérifiez l’intégrité du réseau côté client et tout pare-feu local ou client VPN.
10054 A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.) Le côté distant envoie une réinitialisation TCP. Causes courantes : le processus homologue s’est bloqué, un pare-feu a injecté une réinitialisation ou la passerelle Azure SQL a fermé une connexion inactive. Pour les scénarios de réinitialisation après inactivité, activez TCP keepalive côté client ou réduisez le délai d’inactivité du pool de connexions.
10928 Resource ID: %d. The %s limit for the database is %d and has been reached. See 'http://go.microsoft.com/fwlink/?LinkId=267637' for assistance. La base de données dépasse une limite de gouvernance des ressources Azure SQL. L’ID de ressource 1 indique la limite de travail ; L’ID de ressource 2 indique la limite de session. Identifiez le type de limite du message, puis réduisez l’accès concurrentiel, augmentez la base de données ou raccourcissez les opérations longues contenant la ressource.
10929 Resource ID: %d. The %s minimum guarantee is %d, maximum limit is %d, and the current usage for the database is %d. However, the server is currently too busy to support requests greater than %d for this database. La base de données dépasse sa garantie minimale et le serveur sous-jacent est limité. Une nouvelle tentative réussit généralement lorsque la charge du voisin tombe. Les occurrences soutenues indiquent que vous avez besoin d’un niveau de service supérieur ou d’un environnement moins bruyant.
40020, 40143, 40166, 40540 Signalé dans le slot Error code %d de l’erreur 40197 lors du basculement. Sous-codes intégrés dans un message de basculement 40197 qui, dans certains cas, apparaissent comme le numéro d’erreur principal. Traitez-les comme 40197.
40197 The service has encountered an error processing your request. Please try again. Error code %d. Mise à niveau logicielle, défaillance matérielle ou autre événement de basculement dans Azure SQL. La reconnexion vous redirige vers une réplique intègre. Le code d’erreur intégré identifie le type de basculement. Si l’erreur persiste, capturez l’ID de suivi de session et contactez le support technique.
40501 The service is currently busy. Retry the request after 10 seconds. Incident ID: %ls. Code: %d. Limitation du débit du moteur SQL Azure. Le minimum recommandé est un délai de temporisation de 10 secondes. Une limitation prolongée indique que la charge de travail a dépassé l’allocation de ressources de la base de données ; augmentez le niveau de service ou réduisez la concurrence.
40613 Database '%.*ls' on server '%.*ls' is not currently available. Please retry the connection later. If the problem persists, contact customer support, and provide them with the session tracing ID of '%.*ls'. La base de données n’est pas disponible, en général pendant un basculement ou brièvement lors d’une opération de mise à l’échelle. Réessayez après un délai croissant ; si le problème persiste au-delà de quelques minutes, relevez l’ID de traçage de la session et ouvrez un ticket d’assistance.
42108 Can not connect to the SQL pool since it is paused. Please resume the SQL pool and try again. Le pool SQL dédié (Synapse) est dans un état suspendu. Une nouvelle tentative réussit uniquement une fois le pool repris. Reprenez explicitement le pool, ou planifiez la charge de travail pour qu’elle s’exécute une fois le pool repris.
42109 The SQL pool is warming up. Please try again. Le pool SQL dédié reprend. Réessayez en augmentant progressivement le délai jusqu’à ce que le pool soit en ligne ; la phase de préchauffe prend généralement quelques minutes.
49918 Cannot process request. Not enough resources to process request. The service is currently busy. Please retry the request later. Le serveur ne peut actuellement pas allouer suffisamment de ressources pour répondre à la demande. Réessayez sur un backoff. Si l’erreur persiste, effectuez un scale-up de la base de données ou du pool élastique.
49919 Cannot process create or update request. Too many create or update operations in progress for subscription "%ld". Limite de concurrence au niveau de l’abonnement sur les opérations de gestion. Réduisez les appels de création/mise à jour parallèles ou les décaler.
49920 Cannot process request. Too many operations in progress for subscription "%ld". Limite de concurrence au niveau de l’abonnement sur les opérations en cours de vol. Réduisez le parallélisme ou attendez que les opérations en cours se terminent.

Les erreurs au niveau des instructions ne figurent pas dans cette liste, car elles se produisent une fois la connexion établie et l’échec laisse la session utilisable. Les erreurs d’instruction pouvant faire l’objet d’une nouvelle tentative les plus courantes sont 1205 (victime d’interblocage) et 1222 (délai d’expiration de la demande de verrouillage). Relancez l’intégralité de la transaction plutôt que la seule instruction qui échoue.

Le texte du message d’erreur provient de Azure SQL erreurs de connexion temporaires. Les pilotes individuels conservent leurs propres listes de réessais intégrées ; ce catalogue décrit quelles erreurs sont éligibles à un réessai pour SQL Server, Azure SQL Database, Azure SQL Managed Instance, la base de données SQL de Microsoft Fabric et les pools SQL dédiés dans Azure Synapse Analytics.

Impossible d’ouvrir le serveur (pare-feu)

Message d’erreur: mssql: login error: Cannot open server '<server>' requested by the login. Client with IP address '203.0.113.42' is not allowed to access the server.

Causes et solutions :

  • L'IP de votre client n'est pas dans les règles du pare-feu Azure SQL. Ajouter une règle de pare-feu dans le portail Azure : SQL Server>Réseau>Ajouter une règle de pare-feu.
  • Si votre application fonctionne sous Azure, activez l’accès à ce serveur pour permettre aux services et ressources Azure.
  • Pour la connectivité privée, configurez un point de terminaison privé.

Limite de ressources atteinte

Message d’erreur: mssql: Resource ID: 1. The session limit for the database is 300 and has been reached.

Causes et solutions :

  • Trop de connexions concurrentes pour le niveau Azure SQL. Réduisez MaxOpenConns dans la configuration de votre pool.
  • Fuites de connexion (lignes ou transactions non fermées). Vérifiez si des appels defer rows.Close() ou defer tx.Rollback() sont manquants.
  • Plusieurs applications partageant la base de données. Divisez la limite de connexion entre tous les clients.

Pour les limites de connexion Azure SQL par niveau, voir Azure SQL Database.

Le service est actuellement occupé (limitation du débit)

Message d’erreur: mssql: The service is currently busy. Retry the request after 10 seconds. Code: 40501.

Causes et solutions :

  • La base de données est très sollicitée. Implémentez une logique de réessai avec repli exponentiel.
  • La charge de travail dépasse la capacité en DTU ou en vCore du niveau. Envisagez de passer à l’échelle.

Pour les motifs d’implémentation des réessays, voir Gestion des erreurs et patrons de réessayage.

Base de données actuellement indisponible

Message d’erreur: mssql: Database 'AdventureWorks2025' on server '<server>' is not currently available. Code: 40613.

Cause : Azure SQL reconfigure la base de données (opération de basculement, mise à jour ou mise à l’échelle). Cette condition est une erreur transitoire.

Solution : Retenter l’opération. La base de données devient généralement disponible en quelques secondes. Pour plus d’informations, voir Gestion des erreurs et motifs de réessayage.

Erreurs de connexion défectueuses

Une erreur signifie que le pilote a driver: bad connection détecté qu’une connexion existante n’est plus utilisable. Le database/sql pool réessaie automatiquement l’opération sur une nouvelle connexion pour les appels non transactionnels, mais les opérations au sein d’une transaction active échouent immédiatement.

Ne commencez pas par cette section si l’application ne s’est jamais connectée avec succès. driver: bad connection indique généralement une réutilisation de la connexion, un basculement, une expiration du délai d’inactivité ou des interruptions réseau après que la connexion initiale a déjà fonctionné.

Causes courantes

Cause Scénario classique Réparer
Délai d’expiration d’inactivité de la passerelle Azure SQL Connexion inactive pendant 30+ minutes derrière la passerelle Azure. Réglez db.SetConnMaxIdleTime(2 * time.Minute) pour recycler les connexions inactives avant que la passerelle ne les coupe.
Interruption du réseau Défaillance transitoire du réseau entre le client et le serveur. Implémentez la logique de retry pour les opérations non transactionnelles. Consultez Gestion des erreurs.
Terminaison de session côté serveur Le DBA a coupé la session, ou le serveur a été redémarré. Réessayez. Réglez db.SetConnMaxLifetime pour alterner les connexions.
Reconfiguration d’Azure SQL Un événement de bascule, de mise à l’échelle ou d’application de correctifs a interrompu la connexion. Réglez ConnMaxLifetime à 5 minutes ou moins. Implémentez la logique de nouvelle tentative.
Délai d’expiration de transaction de longue durée Azure SQL a terminé la session (erreur 40549). Gardez les transactions courtes. Décomposez les opérations volumineuses en lots plus petits.

Comment la base de données/SQL gère les mauvaises connexions

Pour les appels en dehors d’une transaction (db.QueryContext, db.ExecContext), le database/sql pool tente automatiquement l’opération sur une nouvelle connexion lorsque le pilote signale une mauvaise connexion. Cette nouvelle tentative est transparente pour votre code.

Pour les appels à l’intérieur d’une transaction (tx.QueryContext, tx.ExecContext), le pool ne peut pas réessayer car l’état de la transaction est perdu. Votre code doit détecter l’erreur, revenir en arrière et réessayer toute la transaction.

Configurez le pool pour gérer les délais d’attente et les failovers de la passerelle Azure :

db.SetConnMaxLifetime(5 * time.Minute)  // Rotate connections to recover from failovers.
db.SetConnMaxIdleTime(2 * time.Minute)  // Recycle before Azure gateway drops idle connections (30 min).
db.SetMaxIdleConns(10)                  // Keep warm connections for quick recovery.
db.SetMaxOpenConns(20)                  // Stay below your tier's connection limit.

Pour le SQL Server sur site, ConnMaxIdleTime c'est moins critique car il n'y a pas de délai d'attente pour la passerelle. Cependant, le définir évite les connexions périmées après des perturbations du réseau.

Pour des conseils de configuration détaillés, voir Azure SQL Database.

Épuisement du pool

L’épuisement de la piscine survient lorsque toutes les connexions sont utilisées et que les nouveaux appelants bloquent l’attente d’une connexion.

Symptoms

  • Les demandes ralentissent ou expirent sous charge.
  • db.Stats().WaitCount Grandit continuellement.
  • db.Stats().InUse est égal à MaxOpenConns.
  • La date limite de contexte dépassait les erreurs lors des pointes de trafic.

Diagnostic

Ajoutez la surveillance des pools à votre application :

stats := db.Stats()
log.Printf("Pool: open=%d inUse=%d idle=%d waitCount=%d waitDuration=%v",
    stats.OpenConnections, stats.InUse, stats.Idle,
    stats.WaitCount, stats.WaitDuration)

Causes et solutions courantes

Cause Comment identifier Réparer
rows.Close() non appelé InUse Elle grandit avec le temps, ne diminue jamais. Ajouter defer rows.Close() après chaque QueryContext.
Transactions de longue durée InUse reste élevé pendant le traitement par lots. Gardez les transactions courtes. Traitez de grandes quantités en petits morceaux.
MaxOpenConns trop bas WaitCount Ça croît régulièrement sous charge normale après avoir écarté les ressources bloquées et les fuites. Augmenter MaxOpenConns.
MaxOpenConns non défini Des centaines de connexions ouvertes en cas de pic de charge. Fixé MaxOpenConns à une valeur bornée.
Fuite de goroutine lors de l’appel à db.Conn InUse augmente sans augmentation correspondante du nombre de requêtes. Assurez-vous que chaque db.Conn() résultat est fermé par defer conn.Close().

Pour des conseils détaillés sur la configuration des pools, voir Connexion pooling.

Diagnostic de requêtes lentes ou bloquées

Définir les délais d’attente des requêtes

Utilisez les délais contextuels pour identifier les requêtes lentes et empêcher les appels SQL bloqués de bloquer les connexions et de bloquer les appelants :

ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)
defer cancel()

rows, err := db.QueryContext(ctx, "SELECT * FROM LargeTable WHERE Status = @s",
    sql.Named("s", "active"))
if err != nil {
    // Check if the error was a timeout.
    if ctx.Err() == context.DeadlineExceeded {
        log.Println("Query exceeded 5-second timeout")
    }
    return err
}
defer rows.Close()

Pour un flux de travail complet d’investigation de performance, incluant le Magasin des requêtes, les DMV, l’analyse des indices manquants et le benchmarking, voir Performance tuning.

Diagnostic des blocages

Message d’erreur: mssql: Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Numéro d’erreur : 1205

Solution : Les blocages se produisent dans les systèmes concurrents. Implémentez la logique de tentative automatique pour l’erreur 1205. Pour une fonction wrapper de nouvelle tentative en cas d’interblocage, voir Transactions.

Stratégies de prévention :

  • Accédez aux tables dans le même ordre pour toutes les requêtes.
  • Limitez les transactions et évitez toute interaction utilisateur pendant les transactions.
  • Utilisez l’isolation READ COMMITTED SNAPSHOT pour réduire la contention de verrouillage.

Des blocages répétés sur la même requête indiquent un problème de conception. Utilisez le graphique de blocage (capturé via les événements étendus ou la session de santé système) pour identifier les instructions concurrentes et les types de verrous. Pour une explication détaillée, consultez le guide Deadlocks. Pour les stratégies de gestion des interblocages dans Go, voir Gestion des interblocages et Gérer les interblocages.

Erreurs de certificat avec les conteneurs (Go 1.23 et versions ultérieures)

Message d’erreur: x509: negative serial number

Cause : Go 1.23 applique strictement la RFC 5280. Le certificat auto-signé que SQL Server génère dans les conteneurs Docker utilise un numéro de série négatif, que Go rejette.

Solutions :

  • Pour un environnement de test, ajoutez TrustServerCertificate=true pour ignorer la validation des certificats, ou encrypt=disable pour désactiver complètement le chiffrement.
  • Pour CI/CD, réglez la GODEBUG=x509negativeserial=1 variable environnement pour restaurer le comportement pré-Go 1.23 sans changer votre chaîne de connexion.
  • Dans go.mod (Go 1.23 et versions ultérieures), ajoutez une godebug x509negativeserial=1 directive pour appliquer la dérogation au moment de la compilation.

Attention

N'utilisez pas TrustServerCertificate=true ni encrypt=disable en production. Ces options désactivent les contrôles de sécurité. Pour la production, utilisez un certificat dûment signé.

Erreurs de certificat SHA-1 (Go 1.24 et versions ultérieures)

Message d’erreur : tls: handshake failure ou TLS Handshake failed: EOF lors de la connexion à d’anciennes instances de SQL Server.

Cause : Go 1.24 interdit par défaut les algorithmes de signature SHA-1 dans les certificats TLS. Les anciennes versions de SQL Server et certaines installations sur site utilisent des certificats signés avec SHA-1.

Solutions :

  • Réémettez le certificat serveur avec SHA-256 ou une version ultérieure (recommandé).
  • Réglez la variable d’environnement GODEBUG=tlssha1=1 pour réactiver temporairement le support SHA-1.
  • Dans go.mod (Go 1.23 et versions ultérieures), ajoutez une godebug tlssha1=1 directive.

Quand utiliser encrypt=disable ou TrustServerCertificate=true

Réglage Qu’est-ce que cela fait ? Quand utiliser
TrustServerCertificate=true Chiffre le trafic mais saute la validation des certificats. Développement local et tests où le serveur utilise un certificat auto-signé.
encrypt=disable Envoie du trafic en clair (sans TLS). Environnements hérités où TLS n’est pas disponible. Non recommandé.
encrypt=strict TDS 8.0 avec validation TLS complète depuis le premier octet. Production sur SQL Server 2022 ou Azure SQL.

Pour plus d’informations, voir Tests et chiffrement et certificats.

Problèmes d’encodage et de collation

Avertissements de conversion implicite

Si vous transmettez des paramètres string (envoyés sous la forme nvarchar) à des colonnes varchar, SQL Server effectue une conversion implicite qui peut empêcher l’utilisation d’un index.

Cet exemple reprend la database/sql mise mssql en place des extraits précédents de cet article.

Solution : Utiliser mssql.VarChar pour les colonnes varchar :

db.QueryContext(ctx, "SELECT * FROM Production.Product WHERE ProductNumber = @p1",
    mssql.VarChar("FR-R92B-58"))

Erreur CharsetToUTF8 avec des caractères non latins

Message d’erreur : CharsetToUTF8: ... lors de l’interrogation varchar de colonnes contenant des caractères chinois, japonais ou autres caractères non latins stockés dans une collation comme SQL_Latin1_General_CP1_CI_AS.

Cause : Le pilote tente de convertir la page de codes de la colonne en UTF-8, mais les octets stockés ne correspondent pas à l’encodage attendu de la collation.

Solutions :

  • Utilisez nvarchar à la place de varchar pour les colonnes qui stockent du texte non latin. nvarchar stocke les données sous forme UTF-16 et évite la conversion de pages de codes.
  • Si vous ne pouvez pas changer le type de colonne, vérifiez que la compilation de la base de données prend en charge le jeu de caractères que vous stockez.

Activer la journalisation des diagnostics

Utilisez le log paramètre de connexion pour activer la journalisation au niveau du pilote :

sqlserver://<user>:<password>@<server>?database=AdventureWorks2025&log=63

Les indicateurs de journalisation sont des valeurs de masque de bits : 1 (erreurs), 2 (messages), 4 (lignes), 8 (SQL), 16 (paramètres), 32 (transactions), 64 (débogage). Combinez les valeurs en les additionnant (par exemple, 63 = tous sauf débogage, 127 = tous).

Pour la journalisation programmatique, utilisez SetLogger ou SetContextLogger. Consultez journalisation et diagnostics.

Liste de contrôle pour la résolution des problèmes

Symptôme Première étape
Connexion refusée Vérifiez que SQL Server fonctionne et que TCP/IP est activé.
Échec de la connexion Vérifiez les identifiants et le mode d’authentification.
Erreur de certificat Vérifiez le certificat du serveur ou définissez TrustServerCertificate=true (réservé au développement).
Délai d’expiration de la connexion Vérifiez le chemin réseau avec Test-NetConnection. Vérifiez les règles de pare-feu.
pare-feu Azure SQL Ajoutez votre IP aux règles du pare-feu Azure SQL.
Erreurs de régulation Implémentez une réévaluation avec un recul exponentiel. Augmentez le niveau.
Mauvaise connexion Définissez ConnMaxIdleTime en dessous de 30 minutes pour Azure SQL. Implémentez la logique de nouvelle tentative.
Épuisement du pool Surveiller db.Stats(). Corrigez les lignes/transactions non fermées. Augmenter MaxOpenConns.
Requêtes lentes Fixez des délais contextuels. Interrogez les DMV pour identifier les requêtes les plus coûteuses.
Interblocages Mettez en place une nouvelle tentative sur l’erreur 1205. Accédez aux tables dans un ordre cohérent.
Conversion implicite Utilisez mssql.VarChar pour les colonnes varchar.

Contenu connexe

  • Last updated on