La mise à niveau de SQL Server échoue avec le code d’erreur 574 lors de l’exécution de scripts de base de données de mise à jour

Article
12/14/2024

Cet article vous aide à résoudre et à résoudre un problème où une mise à jour cumulative (CU) ou Service Pack (SP) pour SQL Server signale l’erreur 574 lors de l’exécution de scripts de mise à niveau de base de données.

Symptômes

Lorsque vous appliquez une cu ou un fournisseur de services, le programme d’installation peut signaler l’erreur suivante :

Échec de l’attente du handle de récupération du moteur de base de données. Pour connaître les causes potentielles, consultez le journal des erreurs de SQL Server.

Lorsque vous passez en revue le journal des erreurs SQL Server, vous pouvez remarquer les messages d’erreur suivants :

Error: 574, Severity: 16, State: 0.
CONFIG statement cannot be used inside a user transaction.
Error: 912, Severity: 21, State: 2.
Script level upgrade for database 'master' failed because upgrade step 'sqlagent100_msdb_upgrade.sql' encountered error 574, state 0, severity 16.
This is a serious error condition which might interfere with regular operation and the database will be taken offline.
If the error happened during upgrade of the 'master' database, it will prevent the entire SQL Server instance from starting.
Examine the previous errorlog entries for errors, take the appropriate corrective actions and re-start the database so that the script upgrade steps run to completion.
Error: 3417, Severity: 21, State: 3.
Script level upgrade for database 'master' failed because upgrade step 'msdb110_upgrade.sql' encountered error 15173, state 1, severity 16

Cause

Le processus de mise à jour peut exécuter certains scripts de mise à niveau au sein d’une transaction. Ces scripts de mise à jour sont conçus avec une hypothèse selon laquelle les utilisateurs n’apportent pas de modifications aux objets système et aux autorisations associées. Si vous apportez par inadvertance des modifications aux objets système ou autorisations, certains de ces scripts peuvent échouer et la transaction associée peut devenir orpheline et rester ouverte. Dans ce scénario, lorsque le programme d’installation exécute ultérieurement un script de mise à niveau qui utilise sp_configure pour définir certaines valeurs de configuration, l’erreur 574 se produit. La cause réelle de l’échec de l’installation doit être déterminée en examinant les entrées enregistrées avant l’erreur 574.

Par exemple, un script comme celui suivant peut entraîner l’erreur 574 :

BEGIN TRAN
USE MASTER;
GO
EXEC sp_configure 'recovery interval', '4';
RECONFIGURE WITH OVERRIDE;
COMMIT TRAN

Résolution

Pour résoudre le problème, procédez comme suit :

Démarrez SQL Server avec l’indicateur de trace 902. Pour plus d’informations, consultez Étapes de démarrage de SQL Server avec l’indicateur de trace 902.
Ouvrez le journal des erreurs SQL Server et passez en revue les messages avant l’erreur 574 pour identifier la transaction ayant échoué (consultez l’exemple de modèle suivant).
Corrigez la transaction ayant échoué en fonction des informations de la section Causes et solutions potentielles .
Supprimez l’indicateur de trace 902 de l’élément Paramètres de démarrage et redémarrez SQL Server.

Une fois SQL Server démarré sans indicateur de trace 902, le script de mise à niveau sera réexécuté.
- Si le script de mise à niveau sp/CU se termine correctement, vous pouvez vérifier le journal des erreurs SQL Server et le dossier de démarrage pour vérifier.
- Si le script de mise à niveau échoue à nouveau, vérifiez le journal des erreurs SQL Server pour d’autres erreurs et résolvez les nouvelles erreurs.

Exemple de modèle : Problèmes d’octroi d’autorisations au rôle système

2020-08-17 09:38:12.09 spid11s Adding user 'hostname\svc_sqlagent' to SQLAgentUserRole msdb role...
2020-08-17 09:38:12.09 spid11s
2020-08-17 09:38:12.09 spid11s Granting login access'##MS_SSISServerCleanupJobLogin##' to msdb database...
2020-08-17 09:38:12.10 spid11s A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
2020-08-17 09:38:12.10 spid11s A problem was encountered granting access to MSDB database for login '(null)'. Make sure this login is provisioned with SQLServer and rerun sqlagent_msdb_upgrade.sql
2020-08-17 09:38:12.10 spid11s
2020-08-17 09:38:12.10 spid11s Adding user '##MS_SSISServerCleanupJobLogin##' to SQLAgentUserRole msdb role...

Causes et solutions potentielles

Les options utilisateur entraînent l’échec des transactions.

Solution : Connectez-vous à SQL Server, utilisez la documentation de l’option de configuration du serveur d’options utilisateur pour identifier les options susceptibles de provoquer le problème et supprimer le paramètre en conflit.

Par exemple, le support Microsoft a vu des instances où le paramètre de IMPLICIT_TRANSACTIONS provoque l’échec de l’installation. Sinon, si vous ne pouvez pas identifier l’option utilisateur en conflit, supprimez toutes les options utilisateur à l’aide du script suivant dans SQL Server Management Studio (SSMS) :
```
EXEC sp_configure 'user options', '0'
GO
RECONFIGURE WITH OVERRIDE;
GO
```
Les utilisateurs orphelins provoquent l’échec des transactions.

Solution : recherchez les utilisateurs orphelins à l’aide d’une requête comme celle-ci :
```
SELECT dp.type_desc, dp.SID, dp.name AS user_name
FROM sys.database_principals AS dp
LEFT JOIN sys.server_principals AS sp
     ON dp.SID = sp.SID
WHERE sp.SID IS NULL
     AND authentication_type_desc = 'INSTANCE';
```
Pour plus d’informations sur la résolution des utilisateurs orphelins, consultez Résoudre les problèmes liés aux utilisateurs orphelins (SQL Server).
Les travaux orphelins provoquent l’échec des transactions.

Solution : recherchez des travaux orphelins à l’aide d’une requête comme celle-ci :
```
SELECT sj.name AS Job_Name,
     sl.name AS Job_Owner
FROM msdb.dbo.sysjobs_view sj
LEFT JOIN master.dbo.syslogins sl ON sj.owner_sid = sl.sid
WHERE sl.name <> 'sa'
ORDER BY sj.name
```
Tout enregistrement affichant une valeur NULL ici indique que le propriétaire du travail agent applicable est orphelin. Modifiez le travail et remplacez le propriétaire par une connexion valide.

Partager via