SQL Server ne démarre pas au démarrage de Windows mais démarre manuellement
Le service de mon instance SQL Server (SQL Server 2008 R2 Express) a Type de démarrage = Automatique. Les deux dernières fois, j'ai redémarré mon ordinateur, le service n'a pas pu démarrer de lui-même, mais il démarre très bien lorsque je démarre manuellement le service.
L'Observateur d'événements montre que le service ne démarre pas en raison d'un délai de connexion. Il y a 2 entrées concernant ce délai:
Entrée 1
Un délai d'attente a été atteint (30000 millisecondes) lors de l'attente de la connexion du service SQL Server (SQLEXPRESS).
Entrée 2
Le service SQL Server (SQLEXPRESS) n'a pas pu démarrer en raison de l'erreur suivante: Le service n'a pas répondu à la demande de démarrage ou de contrôle en temps opportun.
J'ai vérifié les fichiers ERRORLOG et aucune erreur n'a été consignée au moment de ces entrées de l'Observateur d'événements.
Avez-vous des idées sur la cause de ce problème ou comment puis-je approfondir mes recherches?
Ce problème se produit car SQL Server a perdu les informations d'identification de connexion ou utilisé un compte sans droits pour démarrer les services.
Pour démarrer automatiquement vos services, SQL Server a besoin d'un compte avec des droits pour démarrer les services lors du démarrage du système d'exploitation.
Pour résoudre ce problème, vous devez aller dans Outils d'administration> Services> SQL Server (MSSQLSERVER ou le nom de vos instances)> Clic droit> Propriétés> Déplacer pour ouvrir une session> Définir l'option de connexion à l'aide d'un compte système local
Si vous avez choisi cette option, appuyez sur le bouton Parcourir et recherchez le compte de service local ou le compte de service réseau là-bas> Cliquez sur Appliquer.
Redémarrez votre ordinateur et vous pourrez démarrer votre SQL Server.
Avez-vous essayé de vous connecter en tant qu'administrateur local?
J'ai eu exactement le même problème avec SQL 2014 Express sur Windows 10. Je voulais créer un nouvel utilisateur qui n'était pas l'administrateur local intégré, j'ai donc créé un nouvel utilisateur, l'ai ajouté au groupe Administrateurs, définissez cet utilisateur se connecter automatiquement au démarrage et le tour est joué! Le service SQL Server ne démarre pas automatiquement. J'ai essayé le démarrage différé, essayé le service local, essayé le service réseau, essayé le nouvel utilisateur administrateur, essayé le paramètre de stratégie de groupe Toujours attendre ... Rien n'a fonctionné.
Même désinstallé SQL Server 2014 Express, redémarré, supprimé manuellement tous les fichiers/dossiers restants et redémarré et réinstallé sous le nouvel utilisateur administrateur. Toujours pas.
Revenu à la connexion automatique en tant que compte administrateur intégré et le tour est joué! Le service SQL Server démarre maintenant automatiquement.
C'est évidemment une solution de contournement pour moi, donc je fais toujours des recherches.
** MISE À JOUR **
En fait, mon problème était enraciné dans la machine ayant été renommée précédemment. Une fois que j'ai modifié la valeur "OriginalMachineName" dans le registre, le problème a été résolu!
Le service SQL Server (SQLEXPRESS) n'a pas pu démarrer en raison de l'erreur suivante: Le service n'a pas répondu à la demande de démarrage ou de contrôle en temps opportun.
Cela ressemble à un simple délai d'attente. Windows essaie de démarrer de nombreux services au démarrage, et tous ces services peuvent parfois provoquer des conflits de ressources, ce qui ralentit le démarrage d'autres services. Un service ne dispose que d'un temps limité pour répondre au gestionnaire de contrôle des services.
La solution la plus simple consiste à définir le service dont vous vous souciez sur Automatique (démarrage différé). Windows ne le démarrera pas tant que tous les autres services automatiques n'auront pas démarré.
Juste une réflexion rapide sur quelque chose à examiner, dans un environnement de type domaine, certains systèmes d'exploitation vous permettent de vous connecter au serveur avant que la connectivité réseau complète ne soit établie. Vous souhaiterez peut-être vérifier les paramètres de stratégie de groupe au niveau local ou de domaine pour ne pas autoriser l'ouverture de session ou le démarrage du système d'exploitation jusqu'à ce que la connectivité réseau complète soit établie.
Juste au cas où vous le remarqueriez lorsque vous vous connectez au serveur après le redémarrage, il se connecte réellement au système d'exploitation avec les informations d'identification mises en cache avant qu'il puisse atteindre les contrôleurs de domaine pour s'authentifier (connectivité réseau non entièrement établie) avec les informations d'identification de connexion s'il s'agit d'une information d'identification de domaine le compte de service SQLExpress s'exécute en tant que.
Je ne sais pas si c'est exactement applicable dans votre cas, mais c'est quelque chose au moins simplement enquêter et essayer de tester au moins juste au cas où.
J'ai trouvé cela dans un article que j'ai enregistré il y a longtemps quand j'ai eu un problème similaire avec un répertoire de base AD (pas via un script de connexion) pour mapper le répertoire de base d'un PC de poste de travail:
La valeur de stratégie pour Configuration ordinateur -> Modèles d'administration -> Système -> Ouverture de session "Toujours attendre le réseau au démarrage et à l'ouverture de session de l'ordinateur" sera définie sur "Activé".
Si la valeur de registre suivante n'existe pas ou si sa valeur n'est pas définie sur 1, il s'agit d'une constatation:
Registre Hive: HKEY_LOCAL_MACHINE Sous-clé:\Software\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon\Value Nom: SyncForegroundPolicy Type: REG_DWORD Valeur: 1
Dans mon cas (Windows Server 2019 et SQL Server 2019), cela était dû au fait que l'utilisateur responsable de l'exécution en tant que service n'a pas le droit de se connecter en tant que service.
De Correction: le service n'a pas démarré en raison d'un échec de connexion par Milan Stanojevic:
Si le droit de se connecter en tant que service est révoqué pour le compte d'utilisateur, restaurez-le sur un contrôleur de domaine ou un serveur membre (autonome) en fonction de votre situation.
Comment restaurer le droit de l'utilisateur sur un contrôleur de domaine
Voici comment procéder si l'utilisateur se trouve dans un domaine Active Directory:
- Cliquez avec le bouton droit sur Démarrer
- Cliquez sur Panneau de configuration
- Tapez Outils d'administration et sélectionnez-le
- Cliquez sur Utilisateurs et ordinateurs Active Directory
- Cliquez avec le bouton droit sur l'unité d'organisation dans laquelle le droit d'utilisateur de se connecter en tant que service a été accordé (unité d'organisation des contrôleurs de domaine par défaut)
- Cliquez avec le bouton droit sur le conteneur souhaité, puis cliquez sur Propriétés
- Accédez à l'onglet Stratégie de groupe
- Cliquez sur Stratégie de contrôleurs de domaine par défaut
- Cliquez sur Modifier pour démarrer le gestionnaire de stratégie de groupe
- Développer la configuration de l'ordinateur
- Développez les paramètres Windows
- Développez Paramètres de sécurité.
- Développer les politiques locales
- Cliquez sur Attribution des droits utilisateur
- Cliquez avec le bouton droit sur Ouvrir une session en tant que service dans le volet droit
- Cliquez sur Ajouter un utilisateur ou un groupe.
- Tapez le nom que vous souhaitez ajouter à la stratégie dans la zone Noms d'utilisateurs et de groupes
- Cliquez sur OK.
- Quitter le gestionnaire de stratégie de groupe
- Fermez les propriétés de la stratégie de groupe,
- Quitter le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory Microsoft Management Console (MMC)
Comment restaurer le droit de l'utilisateur sur un serveur membre (autonome)
Voici comment procéder si un utilisateur est membre d'un serveur membre autonome:
- Démarrer les paramètres de sécurité locaux MMC snap-in.
- Développez les stratégies locales.
- Cliquez sur l'attribution des droits utilisateur.
- Cliquez avec le bouton droit sur Ouvrir une session en tant que service dans le volet droit.
- Cliquez sur Ajouter un utilisateur ou un groupe.
- Tapez le nom que vous souhaitez ajouter à la stratégie dans la zone Noms d'utilisateurs et de groupes.
- Cliquez sur OK.
- Quittez les paramètres de sécurité locaux MMC.
Je suis allé au service local et j'ai changé
SQL Server (MSSQLSERVER Agent SQL Server (MSSQLSERVER)
Définissez-les sur Automatic Delayed et le type de connexion sur
Compte système local Cochez (Autoriser le service à interagir avec le burea)
Et ça démarre automatiquement