[MYSQL] mysqldump reduit la taille de ma bdd ...

mysqldump reduit la taille de ma bdd ... [MYSQL] - SQL/NoSQL - Programmation

Marsh Posté le 30-12-2003 à 13:08:32    

Salut,
 
J'utilise un herbergement dédié (ace-host) qui me permet de faire des cron jobs
 
Un truc que je comprends pas : le fichier de sauvegarde obtenu avec mysqldump en cron, est plus petit (1.5 mo) que celui obtenu par exportation avec phpmyadmin (4,5 Mo) :??:  Le nombre de lignes de texte n'est pas le meme non plus, mias le nombre d'enregistrements principaux me parait pas altéré
 
-> VOus pouvez m'expliquer ?
 
Lulu

Reply

Marsh Posté le 30-12-2003 à 13:08:32   

Reply

Marsh Posté le 30-12-2003 à 13:10:59    

Gzippé peut etre ?

Reply

Marsh Posté le 30-12-2003 à 13:15:47    

mum a écrit :

Gzippé peut etre ?


 
j'ai pas mis d'option sans la syntaxe dans ce sens  :??:  
 

Code :
  1. mysqldump -u**mon nom d'utilisateur** -p**mon mot de pass** **nom de ma bdd**> mabase_par_cron.sql

Reply

Marsh Posté le 30-12-2003 à 13:16:59    

et lorsque tu remet tes info dans la bdd, as tu toute les informations ?

Reply

Marsh Posté le 30-12-2003 à 13:18:44    

pas essayé pour l'instant : je prefererai savoir de quoi il retourne avant ... ;)

Reply

Marsh Posté le 30-12-2003 à 13:19:17    

lulu_merlan a écrit :

pas essayé pour l'instant : je prefererai savoir de quoi il retourne avant ... ;)

et tes 4.5 mo, ca represente quoi? un fichier.sql ?

Reply

Marsh Posté le 30-12-2003 à 13:20:30    

lulu_merlan a écrit :

pas essayé pour l'instant : je prefererai savoir de quoi il retourne avant ... ;)

ben faudrait peut etre savoir si ya toutes les données avant de faire d'autre hypothese.Car là le seul truc logique c'est qu'il te manque des données.


Message édité par fabien le 30-12-2003 à 13:20:45
Reply

Marsh Posté le 30-12-2003 à 13:25:04    

fabien a écrit :

et tes 4.5 mo, ca represente quoi? un fichier.sql ?
 


 
oui c un fichier sql
 
Pour comparer les données ... C'est du boulot !!
Ce que j'ai fait, comme il s'agit d'un annuaire en ligne php, c'est que j'ai compté le nombre de ligne de la table principale, celle qui contient les enregistrement des sites inscrits dans la bdd.
Le nombre de lignes est le meme pour cette table, qui est la plus importante
Edit : j'ai fait le cron tous les 20 mns, et la taille du fichier est toujours la meme


Message édité par lulu_merlan le 30-12-2003 à 13:27:49
Reply

Marsh Posté le 30-12-2003 à 13:27:33    

lulu_merlan a écrit :


 
oui c un fichier sql
 
Pour comparer les données ... C'est du boulot !!
Ce que j'ai fait, comme il s'agit d'un annuaire en ligne php, c'est que j'ai compté le nombre de ligne de la table principale, celle qui contient les enregistrement des sites inscrits dans la bdd.
Le nombre de lignes est le meme pour cette table, qui est la plus importante

pour comparer, tu met ton fichier.sql dans ta bdd en local et tu regarde si les tables on le meme nombre d'enregistrement.

Reply

Marsh Posté le 30-12-2003 à 13:29:00    

fabien a écrit :

pour comparer, tu met ton fichier.sql dans ta bdd en local et tu regarde si les tables on le meme nombre d'enregistrement.
 


 
oui oui je sais, mais je pensais que ça s'expliquait logiquement, alors j'ai attendu : je vous tiens au courant ...

Reply

Marsh Posté le 30-12-2003 à 13:29:00   

Reply

Marsh Posté le 30-12-2003 à 13:35:04    

Regarde directement ce qu'il y a dans les fichiers [:proy]

Reply

Marsh Posté le 30-12-2003 à 14:51:36    

mrbebert a écrit :

Regarde directement ce qu'il y a dans les fichiers [:proy]  


 
40 000 lignes de textes :/

Reply

Marsh Posté le 30-12-2003 à 15:01:34    

Euh... Bah c'est tout à fait normal :sarcastic:
 
Un ficher de base de données, mise à part oppération manuelle, ne peut que grossir.
 
En effet, quand tu ajoutes des données et que tu en supprimes, le SGBD génère des trous dans le fichier, qu'il ne va pas forcément re-remplir (il s'efforce d'inserrer les données de façon ordonnées selon les index pour obtenir de meilleurs perfs, et toujours pour des raisons de perfs, il passe pas son temps à remettre les donnés les unes au bout des autres dès qu'il y a un trou).
 
Hors, quand tu fait un dump, le backup ne contient plus ces trou (se serait con de backuper des zones vides...) et donc, quand tu restore la base, y'a plus de trous.
 
Fait un test :
 
- Crée une base de données avec une table vide.
=> Regarde la taille de la base.
 
Insère 100 000 lignes dans la table (des varchar(255) devraient faire l'affaire).
=> Regarde la taille de la base. Elle a grossi.
 
delete table
=> Regarde la taille de la base. Elle est de la même taille, même si elle est vide.
 
Fait un dump. Puis restore le.
=> La base a repris sa taille initiale.


Message édité par MagicBuzz le 30-12-2003 à 15:02:23
Reply

Marsh Posté le 30-12-2003 à 15:13:13    

MagicBuzz a écrit :

Euh... Bah c'est tout à fait normal :sarcastic:
 
Un ficher de base de données, mise à part oppération manuelle, ne peut que grossir.
 
En effet, quand tu ajoutes des données et que tu en supprimes, le SGBD génère des trous dans le fichier, qu'il ne va pas forcément re-remplir (il s'efforce d'inserrer les données de façon ordonnées selon les index pour obtenir de meilleurs perfs, et toujours pour des raisons de perfs, il passe pas son temps à remettre les donnés les unes au bout des autres dès qu'il y a un trou).
 
Hors, quand tu fait un dump, le backup ne contient plus ces trou (se serait con de backuper des zones vides...) et donc, quand tu restore la base, y'a plus de trous.
 
Fait un test :
 
- Crée une base de données avec une table vide.
=> Regarde la taille de la base.
 
Insère 100 000 lignes dans la table (des varchar(255) devraient faire l'affaire).
=> Regarde la taille de la base. Elle a grossi.
 
delete table
=> Regarde la taille de la base. Elle est de la même taille, même si elle est vide.
 
Fait un dump. Puis restore le.
=> La base a repris sa taille initiale.


 
ben voila, je suis rassuré et heureux :)
 
Merci à tous !!
 
lulu

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed