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

Article
08/17/2023

Cet article vous aide à résoudre un problème dans lequel une mise à jour cumulative (CU) ou un 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 un cu ou un fournisseur de services, le programme d’installation peut signaler l’erreur suivante :

Attendez que le handle de récupération du moteur de base de données ait échoué. Vérifiez les causes potentielles dans le journal des erreurs 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 des scripts de mise à niveau dans une transaction. Ces scripts de mise à jour sont conçus avec l’hypothèse que les utilisateurs n’apportent pas de modifications aux objets système et aux autorisations associées. Si vous apportez par inadvertance des modifications aux autorisations ou objets système, 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 le 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 SQL Server avec l’indicateur de trace 902.
Ouvrez le journal des erreurs SQL Server et passez en revue les messages antérieurs à l’erreur 574 pour identifier la transaction ayant échoué (voir 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 que SQL Server démarre sans indicateur de trace 902, le script de mise à niveau est réexécuté.
- Si le script de mise à niveau SP/CU se termine correctement, vous pouvez case activée le journal des erreurs SQL Server et le dossier bootstrap à vérifier.
- Si le script de mise à niveau échoue à nouveau, case activée le journal des erreurs SQL Server pour d’autres erreurs et résoudre les nouvelles erreurs.

Exemple de modèle : Problèmes d’octroi d’autorisations à un 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 de serveur des options utilisateur pour identifier les options susceptibles de provoquer le problème et supprimez 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 parvenez 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 entraînent 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 d’utilisateurs orphelins (SQL Server).
Les travaux orphelins entraînent l’échec des transactions.

Solution : Recherchez les 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 présentant ici une valeur NULL indique que le propriétaire du travail d’agent applicable est orphelin. Modifiez le travail et remplacez le propriétaire par une connexion valide.

Partager via