SQL Server inutilisés, mais alloué l'espace de la table
J'ai des bases de données ms sql qui poussent très grand. Lors de l'examen, je trouve qu'il y a un tas d'espace inutilisé dans certains tableaux. Je ne fais pas beaucoup de physique supprime, donc je ne pense pas que sa viens de supprimer des enregistrements. DBCC RÉTRÉCIR ne pas réduire la taille du fichier. Mais, si j'ai un dump de la table pour une nouvelle base de données vide, la taille descend sur les 80%. Au lieu de la 7gb j'ai dans ce tableau dans la base de données actuelle, je me retrouve avec environ 1,5 go dans la nouvelle base de données. C'est comme si sql server est d'allouer trop de mémoire. Quelqu'un a rencontré ce avant? J'aimerais être en mesure de réduire le tableau en supprimant inutilisés espace alloué sans avoir à créer une nouvelle base de données.
Informations supplémentaires:
Modèle de récupération complète utilisée. Je vais essayer de la reconstruction de l'index, je pense que sa fait un moment. ldf sont rétréci quotidien à l'aide de quelques farfelus procédure stockée qui tronque eux.
- avez-vous essayé de reconstruire l'index?
- Jetez un oeil à cet article de Base de Connaissances et voir si elle s'applique: support.microsoft.com/kb/913399
- Est-ce pertinent? L'article 924027 - SQL Server augmente de manière significative l'espace inutilisé pour certaines tables
- Il n'y a absolument AUCUN POINT en utilisant le modèle de récupération complète, si tout ce que vous faites pour le Fli est tronquer! La bonne façon de les faire rétrécir, est de faire une sauvegarde des fichiers journaux, au moment où ils vont être réduit automatiquement. Quelqu'un qui comprend journal des chaînes et de la bonne stratégie de sauvegarde est désespérément nécessaire pour intervenir et vous aider à obtenir ce droit. Rien de moins vous met à hache-risque de perte de données.
Vous devez vous connecter pour publier un commentaire.
J'ai trouvé que si vous ne prenez pas soin de faire une sauvegarde de vos transistion fichier journal (le LDF), vous obtiendrez quelque chose de ce genre de comportement. Je ne peux pas insister assez sur l'importance d'avoir une bonne sauvegarde de "l'hygiène". Non seulement il va enregistrer votre bacon si quelque chose ne va pas, mais je vais aussi aider à maintenir un beau tendu de la base de données.
que sur les mises à jour de la table, qu'est-ce que le niveau de fragmentation. exécutez DBCC SHOWCONTIG, puis de reconstruire l'index s'il est très fragmenté. Après que faire une SAUVEGARDE de JOURNAL AVEC TRUNCATE_ONLY suivie par un psy commande
Dans les options, vous pouvez spécifier de combien vous voulez grandir. Par défaut je crois que c'est 10%, de sorte donné un 200 MO de base de données, lorsque vous remplissez votre dernière page, il va allouer un autre 20 MO d'espace de la page. Au 7GB il serait d'allouer 700MO.
Je ne sais pas exactement où vous pouvez le modifier après la création d'une base de données, mais je sais que c'est le moment de créer la db. un peu de google sera plus susceptible de révéler la réponse pour vous.
NOTE: ma réponse n'est pas comment résoudre le problème, mais peut-être la façon de prévenir ou d'expliquer pourquoi vous risquez de voir tout cet espace non alloué.
J'ai eu un problème similaire une fois et je crois que j'ai trouvé que réindexer/rétrécissement de ne pas récupérer la totalité de l'espace inutilisé si il n'y a pas d'index cluster sur une table donnée.
Il est possible que le tableau a été construit avec rembourrage activé pour l'index. La raison pour laquelle les gens de bâtir un collier indice est d'éviter le fractionnement des pages.
Clic droit sur la table dans SQL Manager et sélectionnez le SCRIPT de la TABLE. Ensuite, regardez pour voir si
PAD_INDEX=OFF
. SiPAD_INDEX
est en cours d'utilisation, c'est probablement là où la table est de prendre de l'espace.Ce qui a fonctionné pour moi dans le passé