Comment puis-je réduire ma base de données SQL Server?
J'ai une base de données de près de 1,9 Go de base de données, et MSDE2000 n'autorise pas les bases de données supérieures à 2,0 Go.
J'ai besoin de réduire cette base de données (et beaucoup d'autres comme celle-ci chez différents clients).
J'ai trouvé et supprimé plusieurs centaines de milliers d'enregistrements considérés comme inutiles: Ces enregistrements représentent un pourcentage élevé de certaines des tables principales (les plus grandes) de la base de données. Par conséquent, il est raisonnable de supposer qu'une grande partie de l'espace doit maintenant être récupérée.
Alors maintenant, je dois réduire la base de données pour prendre en compte les enregistrements manquants.
- J'exécute
DBCC ShrinkDatabase('MyDB')...... Aucun effet. - J'ai essayé les diverses installations de rétraction fournies dans MSSMS ... Toujours aucun effet.
- J'ai sauvegardé et restauré la base de données ... Toujours aucun effet.
Toujours 1.9Gb
Pourquoi?
Quelle que soit la procédure que je trouve éventuellement, il faut pouvoir la rejouer sur une machine cliente n’ayant accès qu’à OSql ou similaire.
ALTER DATABASE MyDatabase SET RECOVERY SIMPLE
GO
DBCC SHRINKFILE (MyDatabase_Log, 5)
GO
ALTER DATABASE MyDatabase SET RECOVERY FULL
GO
Cela peut paraître bizarre, mais cela a fonctionné pour moi et j'ai écrit un programme C # pour automatiser cela.
Étape 1: tronquer le journal des transactions (ne sauvegarder que le journal des transactions, en activant l'option permettant de supprimer les transactions inactives)
Étape 2: Exécuter une réduction de la base de données en déplaçant toutes les pages au début des fichiers
Étape 3: Tronquez à nouveau le journal des transactions, car l'étape 2 ajoute des entrées au journal.
Étape 4: exécutez à nouveau une réduction de la base de données.
Mon code simplifié, qui utilise la bibliothèque SQL DMO, est le suivant:
SQLDatabase.TransactionLog.Truncate();
SQLDatabase.Shrink(5, SQLDMO.SQLDMO_SHRINK_TYPE.SQLDMOShrink_NoTruncate);
SQLDatabase.TransactionLog.Truncate();
SQLDatabase.Shrink(5, SQLDMO.SQLDMO_SHRINK_TYPE.SQLDMOShrink_Default);
C'est une vieille question, mais je suis tombé dessus.
La réponse très courte et correcte est déjà donnée et compte le plus grand nombre de votes. C’est comment vous réduisez un journal de transactions, et c’était probablement le problème des OP. Et lorsque le journal des transactions est devenu incontrôlable, il est souvent nécessaire de le réduire, mais il convient de veiller à éviter que le journal ne devienne hors de contrôle. Cette question sur dba.se explique cela. Fondamentalement - Ne le laissez pas prendre une telle ampleur grâce au modèle de récupération approprié, à la maintenance du journal des transactions, à la gestion des transactions, etc.
Mais la plus grande question dans mon esprit lorsque je lis cette question sur la réduction du fichier de données (ou même du fichier journal) est pourquoi? et quelles sont les mauvaises choses qui se passent lorsque vous essayez? Il semble que des opérations de réduction aient été effectuées. Dans ce cas, cela a du sens, car les éditions MSDE/Express sont limitées à la taille maximale de la base de données. Mais la bonne réponse peut être de chercher la bonne version pour vos besoins. Et si vous tombez sur cette question qui cherche à réduire votre base de données de production et que ce n’est pas la raison, vous devriez vous demander le pourquoi? question.
Je ne veux pas que quelqu'un cherche "comment réduire une base de données" sur Internet et pense que c'est une chose cool ou acceptable à faire.
Réduire les fichiers de données est une tâche spéciale qui doit être réservée pour des occasions spéciales. Considérez que lorsque vous réduisez une base de données, vous fragmentez effectivement vos index. Considérez que lorsque vous réduisez une base de données, vous enlevez l'espace libre qu'une base de données pourrait éventuellement retrouver, ce qui vous ferait perdre du temps et engendrerait les conséquences d'une opération de réduction pour que la base de données grossisse à nouveau.
J'ai écrit à propos de ce concept dans plusieurs articles de blog sur la réduction des bases de données. Celui-ci appelé " Ne touchez pas ce bouton de réduction " vient à l’esprit en premier. Je parle de ces concepts décrits ici - mais aussi du concept de "Redimensionnement" de votre base de données. Il est de loin préférable de choisir la taille de votre base de données, de planifier votre croissance future et de l’affecter à ce montant. Avec l'initialisation instantanée des fichiers disponible dans SQL Server 2005 et versions ultérieures pour les fichiers de données, le coût de la croissance est moins élevé - mais je préfère tout de même disposer d'une application initiale appropriée - et j'ai beaucoup moins peur des espaces dans une base de données rétrécissement en général sans aucune pensée en premier. :)
DBCC SHRINKDATABASE fonctionne pour moi, mais c'est sa syntaxe complète:
DBCC SHRINKDATABASE ( database_name, [target_percent], [truncate] )
où target_percent est le pourcentage souhaité d'espace libre dans le fichier de base de données après que la base de données a été réduite.
Et le paramètre truncate peut être:
NOTRUNCATE
Force l'espace de fichier libéré à être conservé dans les fichiers de base de données. S'il n'est pas spécifié, l'espace de fichier libéré est libéré sur le système d'exploitation.
TRUNCATEONLY
L'espace non utilisé dans les fichiers de données est libéré sur le système d'exploitation et réduit le fichier à la dernière étendue allouée, ce qui réduit la taille du fichier sans déplacer aucune donnée. Aucune tentative n'est faite pour déplacer des lignes vers des pages non allouées. target_percent est ignoré lorsque TRUNCATEONLY est utilisé.
... et oui, non, on a raison, réduire la base de données n’est pas une très bonne pratique car, par exemple:
la réduction des fichiers de données constitue un excellent moyen d’introduire une fragmentation logique importante, car elle déplace les pages de la fin de la plage allouée d’un fichier de base de données vers un emplacement situé au début du fichier ...
réduire la base de données peut avoir beaucoup de conséquences sur la base de données, le serveur, ... réfléchissez-y bien avant de le faire!
sur le Web, il existe de nombreux blogs et articles à ce sujet.
Réponse tardive mais pourrait être utile pour quelqu'un d'autre
Si ni DBCC ShrinkDatabase/ShrinkFile ni SSMS (Tasks/Shrink/Database) n’aident pas, il existe des outils de Quest et ApexSQL qui peuvent exécuter le travail et même planifier une réduction périodique si vous en avez besoin.
J'ai utilisé ce dernier logiciel en essai gratuit pour le faire il y a quelque temps, en suivant la brève description figurant à la fin de cet article:
Tout ce que vous avez à faire est d’installer ApexSQL Backup, de cliquer sur le bouton "Réduire la base de données" dans le ruban principal, de sélectionner la base de données dans la fenêtre qui s’ouvrira et de cliquer sur "Terminer".
Vous devrez également réduire les fichiers de données individuels.
Ce n'est cependant pas une bonne idée de réduire les bases de données. Par exemple, voir ici
Tu devrais utiliser:
dbcc shrinkdatabase (MyDB)
Le fichier journal sera réduit (gardez un explorateur Windows ouvert et voyez-le se produire).
Voici une autre solution: utilisez le Publication de base de données Wizard pour exporter votre schéma, votre sécurité et vos données dans des scripts SQL. Vous pouvez alors déconnecter votre base de données actuelle et la recréer avec les scripts.
Cela semble idiot, mais il y a quelques avantages. Tout d'abord, il n'y a aucune chance de perdre des données. Votre base de données d'origine (tant que vous ne supprimez pas votre base de données lorsque vous la supprimez!) Est sécurisée, la nouvelle base de données sera aussi petite que possible et vous obtiendrez deux instantanés différents de votre base de données actuelle, l'un prêt à l'emploi. pour rouler, un minified - vous pouvez choisir de sauvegarder.
"Par conséquent, il est raisonnable de supposer qu'une grande partie de l'espace devrait maintenant être récupérable."
Toutes mes excuses si j’ai mal compris la question, mais êtes-vous sûr que ce sont la base de données et non les fichiers journaux qui occupent l’espace? Vérifiez le modèle de récupération de la base de données. Il est probable qu'il soit complet, ce qui signifie que le fichier journal n'est jamais tronqué. Si vous n'avez pas besoin d'un enregistrement complet de chaque transaction, vous devriez pouvoir passer à Simple, ce qui tronquera les journaux. Vous pouvez réduire la base de données au cours du processus. En supposant que les choses se passent bien, le processus est le suivant:
- Sauvegardez la base de données!
- Passer à la récupération simple
- Réduire la base de données (cliquez avec le bouton droit sur la base de données, choisissez toutes les tâches> réduire la base de données -> définissez 10% d’espace libre)
- Vérifiez que l'espace a été récupéré, sinon vous devrez peut-être effectuer une sauvegarde complète.
Si cela ne fonctionne pas (ou si vous recevez un message disant "le fichier journal est plein" lorsque vous essayez de changer de mode de récupération), essayez ceci:
- Sauvegarde
- Tuez toutes les connexions à la base de données
- Détacher la base de données (clic droit> Détacher ou clic droit> Toutes les tâches> Détacher)
- Supprimer le fichier journal (ldf)
- Rattachez la base de données
- Changer le mode de récupération
etc.
Je suis tombé sur ce post même s'il me fallait SHRINKFILE sur la version MSSQL 2012 qui est un peu plus compliquée depuis les versions 2000 ou 2005. Après avoir pris connaissance de tous les risques et problèmes liés à ce problème, j'ai fini par tester. En résumé, les meilleurs résultats que j'ai obtenus proviennent de l'utilisation de MS SQL Server Management Studio .
Right-Click the DB -> TASKS -> SHRINK -> FILES -> select the LOG file
Je ne sais pas si cela serait pratique, et en fonction de la taille de la base de données, du nombre de tables et d’autres complexités, mais je:
- défragmenter le lecteur physique
- créer une nouvelle base de données en fonction de mes besoins, de l'espace, de la croissance en pourcentage, etc.
- utilisez la tâche ssms simple pour importer toutes les tables de l'ancienne base de données vers la nouvelle base de données
- écrivez les index de toutes les tables de l'ancienne base de données, puis recréez les index de la nouvelle base de données. développer au besoin pour les clés étrangères, etc.
- renommer les bases de données si nécessaire, confirmer avec succès, supprimer les anciennes
Vous devez également modifier la taille minimale des fichiers de données et des journaux. DBCC SHRINKDATABASE réduira les données inside les fichiers que vous avez déjà alloués. Pour réduire la taille d'un fichier à une taille inférieure à sa taille minimale, utilisez DBCC SHRINKFILE et spécifiez la nouvelle taille.
J'ai récemment fait ça. J'essayais de créer une version compacte de ma base de données pour la tester sur la route, mais je ne pouvais tout simplement pas la réduire, quel que soit le nombre de lignes que j'avais supprimées. Finalement, après de nombreuses autres commandes de ce fil de discussion, j'ai constaté que mes index en cluster n'étaient pas reconstruits après la suppression de lignes. La reconstruction de mes index l'a fait pour que je puisse réduire correctement.
Supprimez les données, assurez-vous que le modèle de récupération est simple, puis passez à skrink (soit la réduction de la base de données, soit la réduction des fichiers). Si le fichier de données est toujours trop volumineux ET si vous utilisez des tas pour stocker des données (c'est-à-dire, pas d'index clusterisé sur des tables volumineuses), vous risquez d'avoir ce problème pour supprimer des données de tas: http://support.Microsoft .com/kb/913399
Je pense que vous pouvez supprimer tout votre journal avec le passage de la récupération complète à la récupération simple. Faites un clic droit sur votre base de données et sélectionnez Properties et sélectionnez Options et modifier
Recovery modeàSimpleContainment typeàNone
