Est-il sûr d'activer la réduction automatique de SQL Server?
Il existe de nombreuses options SQL Server qui peuvent être activées pour les bases de données, et l'une des plus mal comprises est la réduction automatique. Est-ce sûr? Sinon, pourquoi pas?
(Au départ, je posais une question régulière, mais j'ai ensuite découvert la bonne méthode - merci BrentO)
Non jamais.
Je l'ai rencontré plusieurs fois sur ServerFault et je souhaite toucher un large public de Nice avec de bons conseils. Si les gens froncent les sourcils sur cette façon de faire les choses, votez contre et je supprimerai cela volontiers.
Le rétrécissement automatique est un paramètre de base de données très courant à avoir activé. Cela semble être une bonne idée - supprimez l'espace supplémentaire de la base de données. Il existe de nombreux "DBA involontaires" (pensez à TFS, SharePoint, BizTalk ou tout simplement un ancien serveur SQL ordinaire) qui ne savent peut-être pas que le rétrécissement automatique est vraiment mauvais.
Pendant mon séjour chez Microsoft, je possédais le moteur de stockage SQL Server et j'ai essayé de supprimer la fonction de rétrécissement automatique, mais elle devait rester pour une compatibilité descendante.
Pourquoi le rétrécissement automatique est-il si mauvais?
La base de données est susceptible de croître à nouveau, alors pourquoi la réduire?
- Shrink-grow-shrink-grow provoque une fragmentation au niveau du système de fichiers et prend beaucoup de ressources.
- Vous ne pouvez pas contrôler quand il entre en jeu (même si c'est normal)
- Il utilise beaucoup de ressources. Le déplacement des pages dans la base de données nécessite du processeur, beaucoup d'E/S et génère de nombreux journaux de transactions.
- Voici le vrai truc: la réduction du fichier de données (automatique ou non) provoque une fragmentation massive de l'index, ce qui entraîne de mauvaises performances.
J'ai fait un article de blog il y a quelque temps qui a un exemple de script SQL qui montre les problèmes qu'il provoque et explique un peu plus en détail. Voir rétrécissement automatique - désactivez-le! (pas de publicité ou de déchets comme ça sur mon blog). Ne confondez pas cela avec la réduction du fichier journal, ce qui est utile et nécessaire à l'occasion.
Faites-vous donc plaisir - regardez dans les paramètres de votre base de données et désactivez le rétrécissement automatique. Vous ne devriez pas non plus avoir de retrait dans vos plans de maintenance, pour exactement la même raison. Passez le mot à vos collègues.
Edit: Je devrais ajouter ceci, rappelé par la deuxième réponse - il y a une idée fausse commune selon laquelle l'interruption d'une opération de rétrécissement peut provoquer une corruption. Non, ce ne sera pas le cas. J'avais l'habitude de posséder le code de réduction dans SQL Server - il annule le déplacement de page en cours s'il est interrompu.
J'espère que cela t'aides!
Bien sûr, Paul a raison.
Voir toutes les bases de données et leur paramètre de rétrécissement automatique. Si vous avez beaucoup de bases de données, une s'introduira.
sp_msforeachdb @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'
Est-ce quelque part dans le dmv ... Je me demande.
Ce n'est pas "dangereux" - cela n'endommagera rien.
Mais il n'est pas recommandé pour les environnements de production où la base de données peut décider de démarrer et de commencer un exercice de réarrangement coûteux juste avant qu'une pile de demandes ne parvienne à rendre ces demandes plus longues à traiter. Il vaut mieux utiliser la planification des opérations de réduction avec d'autres opérations de maintenance telles que les sauvegardes (en fait, après les sauvegardes - cela ira plus du journal des transactions de cette façon). Ou tout simplement ne pas rétrécir du tout, sauf en cas de problème de croissance - vous pouvez toujours configurer un moniteur pour vous informer lorsque l'espace alloué inutilisé augmente au-delà d'un certain rapport ou d'une taille fixe.
IIRC l'option est désactivée par défaut pour toutes les bases de données dans toutes les éditions MSSQL sauf Express.
Un livre blanc disponible sur TechNet explique plus en détail la maintenance SQL.
J'ai vu un serveur SQL avec Autogrow et Autoshrink activés. Ce serveur (relativement puissant) était terriblement lent, car tout ce qu'il faisait toute la journée était de réduire et d'augmenter les fichiers de base de données. Le rétrécissement automatique peut être utile, mais je recommanderais deux choses:
- Désactivez le rétrécissement automatique par défaut.
- Documentez vos configurations de serveur afin de savoir où la croissance automatique et la réduction automatique sont activées et où elles ne le sont pas.
La seule fois où j'ai été contraint de réduire une base de données était de rafraîchir une copie sur un serveur de test avec moins d'espace disque (insuffisant pour contenir la base de données de production).
Le ou les fichiers de la base de données de production disposaient d'un espace libre généreux, malheureusement vous devez restaurer une base de données avec les mêmes tailles de fichier que celles que vous avez sauvegardées. Nous n'avions donc pas d'autre choix que de réduire la production avant de la sauvegarder. (La réduction a pris du temps, beaucoup de ressources ont été consommées et la croissance du journal des transactions qui a suivi a été problématique.)
Consultez également ce didacticiel vidéo ....
Regardez Paul Randal démontrer comment le rétrécissement et le rétrécissement automatique peuvent causer de graves problèmes de fragmentation pour votre base de données http://wtv.watchtechvideos.com/topic194.html