La réduction automatique de SQL Server est-elle sécurisée?

Réponses:

70

(Au départ, je posais régulièrement une question, mais je trouvais la bonne méthode - merci BrentO)

Non jamais.

Je suis tombé sur cette question à plusieurs reprises sur ServerFault et je souhaite atteindre un large public avec de bons conseils. Si les gens désapprouvent cette façon de faire les choses, votez vers le bas et je retirerai cela volontiers.

La réduction 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 «administrateurs de base de données involontaires» (pensez à TFS, SharePoint, BizTalk ou simplement à un ancien serveur SQL Server ordinaire) qui ne savent peut-être pas que la réduction automatique est une mauvaise chose.

Chez Microsoft, j’étais propriétaire de SQL Server Storage Engine et j’ai essayé de supprimer la fonction de réduction automatique, mais elle devait rester pour des raisons de compatibilité ascendante.

Pourquoi le rétrécissement automatique est-il si grave?

La base de données est susceptible de croître à nouveau, alors pourquoi la réduire?

  1. Shrink-grow-shrink-grow provoque la fragmentation au niveau du système de fichiers et utilise beaucoup de ressources.
  2. Vous ne pouvez pas contrôler quand ça entre en jeu (même si c'est régulier)
  3. Il utilise beaucoup de ressources. Déplacer des pages dans la base de données prend de la CPU, beaucoup d'E / S et génère beaucoup de journal des transactions.
  4. Voici le vrai stimulant: la réduction de fichier de données (qu'elle soit automatique ou non) entraîne une fragmentation massive de l'index, ce qui entraîne une baisse des performances.

Il y a quelque temps, j’ai écrit un article de blog avec un exemple de script SQL qui montre les problèmes qu’il pose et explique un peu plus en détail. Voir Réduction automatique - désactivez-le! (pas de publicité ou de bric-à-brac 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.

Rendez-vous donc service: examinez les paramètres de votre base de données et désactivez la réduction automatique. Vous ne devez pas non plus réduire vos projets de maintenance pour la même raison. Passez le mot à vos collègues.

Edit: Je devrais ajouter ceci, rappelé par la deuxième réponse - il existe une idée fausse commune selon laquelle l'interruption d'une opération de réduction peut entraîner une corruption. Non ça ne va pas. J'avais l'habitude de posséder le code de contraction dans SQL Server - il annule le déplacement de la page en cours s'il est interrompu.

J'espère que cela t'aides!

— Paul Randal
source
Y a-t-il un moyen de réindexer juste après un psy?
— Lance Roberts
4
Non pas réindexer car cela fera croître le fichier (construira un nouvel index avant de supprimer l'ancien), mais une réorganisation (soit via mon ancien DBCC INDEXDEFRAG, soit avec le nouveau ALTER INDEX ... REORGANIZE) résoudra la fragmentation, aux dépens de plus IO, cpu, journalisation ...
— Paul Randal
J'ai remarqué qu'après suppression de la réduction automatique, l'utilisation de la mémoire du serveur de stockage est supérieure.
— user193655
4

Bien sûr, Paul a raison.

Voir toutes les bases de données et leur paramètre de réduction automatique. Si vous avez beaucoup de bases de données, l'une d'entre elles se faufilera.

sp_msforeachdb  @command1 = 'Select ''[?]'',DATABASEPROPERTYEX(''?'',''IsAutoShrink'')'

Est-ce que le dmv est quelque part ... Je me le demande.

— Sam
source
2
sys.databases a un champ is_auto_shrink (et is_auto-close, is_auto_update_stats, etc.)
— Paul Randal
merveilleuse im googler: comment ai-je un rapport nous aidant à savoir quels dbs sont configurés en tant que autoshrink et votre code fonctionne bien et génère un bon rapport de tous les db pour nous
— sabre tabatabaee yazdi
2

Ce n'est pas "dangereux" - cela n'endommagera rien.

Cependant, il n'est pas recommandé pour les environnements de production où la base de données peut décider de démarrer un exercice de réorganisation coûteux, juste avant qu'une pile de demandes n'arrive, ce qui prend plus de temps pour être traitée. Vous feriez bien mieux d’utiliser des opérations de réduction de la planification avec d’autres opérations de maintenance telles que des sauvegardes (en fait, après les sauvegardes - c’est davantage à partir du journal des transactions). Ou tout simplement, ne réduisez pas du tout sauf en cas de problème de croissance - vous pouvez toujours configurer un moniteur pour vous avertir lorsque l'espace alloué inutilisé dépasse un certain ratio ou une taille fixe.

L'option IIRC est désactivée par défaut pour toutes les bases de données de toutes les éditions MSSQL sauf Express.

— David Spillett
source
2
Les rétrécissements ne doivent pas être programmés - il doit s'agir d'opérations très rares en raison des problèmes qu'elles provoquent. Je ne comprends pas votre commentaire sur la réduction après la sauvegarde: les enregistrements de journal générés par l'opération de réduction seront récupérés lors de la prochaine sauvegarde du journal des transactions, quel que soit le moment où vous le faites ou quelles autres sauvegardes vous effectuez. Merci
— Paul Randal
1

Un livre blanc disponible sur TechNet explique la maintenance SQL plus en détail.

http://technet.microsoft.com/en-us/library/cc262731.aspx

— Jeremy Thake
source
Malheureusement, ce livre blanc ne vise que les installations SharePoint et contient en réalité des erreurs. Je viens de passer du temps à enseigner la classe SharePoint MCM actuelle à l'auteur de ce livre blanc, Bill Baer.
— Paul Randal
3
Mon article de TechNet Magazine sur la maintenance efficace des bases de données constitue une bonne introduction à la maintenance des bases de données - technet.microsoft.com/en-us/magazine/cc671165.aspx .
— Paul Randal
1

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 de faire grossir les fichiers de la base de données. Autoshrink peut être utile, mais je recommanderais deux choses:

  1. Désactiver la réduction automatique par défaut.
  2. Documentez les configurations de votre serveur afin que vous sachiez où Autogrow et Autoshrink sont activés et où ils ne le sont pas.
— Carl C
source
1

La seule fois où j'ai été contraint de réduire une base de données a été d'actualiser une copie sur un serveur de test avec moins d'espace disque (insuffisant pour contenir la base de production).

Le fichier (s) de la base de données de production avait un espace libre important. Malheureusement, vous devez restaurer une base de données avec la même taille de fichier (s) que celle avec laquelle vous l'avez sauvegardée. Nous n’avions donc pas d’autre choix que de réduire notre production avant de la sauvegarder. (La réduction a pris beaucoup de temps, de nombreuses ressources ont été consommées et la croissance du journal des transactions qui en a résulté a été problématique.)

— SuperCoolMoss
source
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.