Votre avis

Le
I.G.LOG
Bonjour,
Je suis en train de migrer une application WD8 -> WD12. La base est en HF
Classic partagée sur un serveur Linux (Fedora Core 3 - PS: je ne suis pas un
spécialiste Linux) sous Samba. L'application WD8 fonctionne actuellement,
mais nous avons des problèmes de lenteur, ce qui a motivé la réécriture de
l'appli en mode C/S; l'essentiel de mon travail a été de coder les accès
avec des requetes (avec SQLExec) plutot qu'avec des ordres H*.
Je dois aujourd'hui choisir entre HF C/S (que j'ai déjà installé sur le
serveur Linux pour essais) et MySQL. A votre avis, entre ces deux bases de
données, y a t il des différences importantes en terme de performance ? Par
ailleurs, PCSoft vient de sortir l'accès natif MySql. Est il plus
interressant d'avoir la base en MySQL/Linux ou sous Samba ? Je pose cette
question car je ne sais pas comment gérer les sauvegardes. Actuellement,
j'ai un serveur W2003, équipé d'un DAT, qui execute un batch de copie du
répertoire Samba puis sauvegarde sur bande (ca fonctionne bien). Dans le cas
ou la base est sur Linux, je ne sais plus faire les sauvegardes !?
Merci pour vos avis.
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses Page 1 / 2
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
mat
Le #14529071
I.G.LOG wrote:
Bonjour,
Je suis en train de migrer une application WD8 -> WD12. La base est en HF
Classic partagée sur un serveur Linux (Fedora Core 3 - PS: je ne suis pas un
spécialiste Linux) sous Samba. L'application WD8 fonctionne actuellement,
mais nous avons des problèmes de lenteur, ce qui a motivé la réécriture de
l'appli en mode C/S; l'essentiel de mon travail a été de coder les accès
avec des requetes (avec SQLExec) plutot qu'avec des ordres H*.
Je dois aujourd'hui choisir entre HF C/S (que j'ai déjà installé sur le
serveur Linux pour essais) et MySQL. A votre avis, entre ces deux bases de
données, y a t il des différences importantes en terme de performance ? Par
ailleurs, PCSoft vient de sortir l'accès natif MySql. Est il plus
interressant d'avoir la base en MySQL/Linux ou sous Samba ? Je pose cette
question car je ne sais pas comment gérer les sauvegardes. Actuellement,
j'ai un serveur W2003, équipé d'un DAT, qui execute un batch de copie du
répertoire Samba puis sauvegarde sur bande (ca fonctionne bien). Dans le cas
ou la base est sur Linux, je ne sais plus faire les sauvegardes !?
Merci pour vos avis.







Bonjour,

petite question pour commencer, pourquoi SQLExec et ne pas
hExecuteRequeteSQL ?


Je ne connais pas mySQL mais à mon avis il y a au moins deux points à
considérer:

1) Si les requêtes ont été fait pour HF, il faudra probablement les
adapter à mySQL. Ceci entraîne des vérification substantielles.

2) Par contre, si les requêtes du projet incluent les INSERT, UPDATE et
DELETE, je n'utiliserais pas HF car pour autant que je sache, les
requêtes SQL ne respectent toujours pas les contraintes définies dans
l'analyse. On peut insérer autant de fois qu'on veuille un même
enregistrement dans un fichier HF avec ID unique. Les modifs par UPDATE
on ne sait pas si elles réussissent car le retour vrai ou faux se réfère
à l'exécution de la requête (au moins avec hExecuteRequeteSQL) et ne pas
à la commande. Les suppressions ne sont non plus contrôlé par les
contraintes définies et ne fonctionne non plus en cascade avec les
requêtes SQL. Comme alternative il y a hExecuteRequete, avec paramêtre
adéquat, mais alors on perds la flexibilité.

Je pense mySQL résoud ce genre de problèmes puisque les contraintes sont
déclarées et imposées dans mySQL.

Salutations
Mat
I.G.LOG
Le #14529061
>
petite question pour commencer, pourquoi SQLExec et ne pas
hExecuteRequeteSQL ?




Bonjour,
J'utilise SQLExec() car, si mes souvenirs sont bons, c'est plus performant,
notamment avec MySQL.

1) Si les requêtes ont été fait pour HF, il faudra probablement les
adapter à mySQL. Ceci entraîne des vérification substantielles.




Oui, bien sur... même si j'ai essayé de rester dans les standards (il faudra
bien que je revoie les TOP et autres ordres spécifiques)

2) Par contre, si les requêtes du projet incluent les INSERT, UPDATE et
DELETE, je n'utiliserais pas HF car pour autant que je sache, les requêtes
SQL ne respectent toujours pas les contraintes définies dans l'analyse. On
peut insérer autant de fois qu'on veuille un même enregistrement dans un
fichier HF avec ID unique. Les modifs par UPDATE on ne sait pas si elles
réussissent car le retour vrai ou faux se réfère à l'exécution de la
requête (au moins avec hExecuteRequeteSQL) et ne pas à la commande. Les
suppressions ne sont non plus contrôlé par les contraintes définies et ne
fonctionne non plus en cascade avec les requêtes SQL. Comme alternative il
y a hExecuteRequete, avec paramêtre adéquat, mais alors on perds la
flexibilité.




Je n'ai pas défini de contraintes d'intégrité dans l'analyse. Je gère tout
par programmation.
Concernant les ajouts, j'ai conservé les ordres H* (HAjoute). Pour les
update, ca dépend en fait du nombre de champs que je modifie: si il y en a
peu, je privilégie la requete (pour des raisons de flux sur le réseau),
sinon l'ordre HModifie(). Pour le delete, plutot la requete.

Je pense mySQL résoud ce genre de problèmes puisque les contraintes sont
déclarées et imposées dans mySQL.




Je ne pense pas non plus définir de contraintes d'intégrité dans l'analyse
MySQL.

Ma grande question est surtout au niveau des performances: HF/CS vs MySQL.
C'est surtout la réponse qui va m'orienter sur un choix ou un autre, bien
que je sois plus à l'aise avec HF bien sur.

Merci
Daniel
Le #14529051
I.G.LOG a écrit :
petite question pour commencer, pourquoi SQLExec et ne pas
hExecuteRequeteSQL ?




Bonjour,
J'utilise SQLExec() car, si mes souvenirs sont bons, c'est plus performant,
notamment avec MySQL.

1) Si les requêtes ont été fait pour HF, il faudra probablement les
adapter à mySQL. Ceci entraîne des vérification substantielles.




Oui, bien sur... même si j'ai essayé de rester dans les standards (il faudra
bien que je revoie les TOP et autres ordres spécifiques)

2) Par contre, si les requêtes du projet incluent les INSERT, UPDATE et
DELETE, je n'utiliserais pas HF car pour autant que je sache, les requêtes
SQL ne respectent toujours pas les contraintes définies dans l'analyse. On
peut insérer autant de fois qu'on veuille un même enregistrement dans un
fichier HF avec ID unique. Les modifs par UPDATE on ne sait pas si elles
réussissent car le retour vrai ou faux se réfère à l'exécution de la
requête (au moins avec hExecuteRequeteSQL) et ne pas à la commande. Les
suppressions ne sont non plus contrôlé par les contraintes définies et ne
fonctionne non plus en cascade avec les requêtes SQL. Comme alternative il
y a hExecuteRequete, avec paramêtre adéquat, mais alors on perds la
flexibilité.




Je n'ai pas défini de contraintes d'intégrité dans l'analyse. Je gère tout
par programmation.
Concernant les ajouts, j'ai conservé les ordres H* (HAjoute). Pour les
update, ca dépend en fait du nombre de champs que je modifie: si il y en a
peu, je privilégie la requete (pour des raisons de flux sur le réseau),
sinon l'ordre HModifie(). Pour le delete, plutot la requete.

Je pense mySQL résoud ce genre de problèmes puisque les contraintes sont
déclarées et imposées dans mySQL.




Je ne pense pas non plus définir de contraintes d'intégrité dans l'analyse
MySQL.

Ma grande question est surtout au niveau des performances: HF/CS vs MySQL.
C'est surtout la réponse qui va m'orienter sur un choix ou un autre, bien
que je sois plus à l'aise avec HF bien sur.

Merci






Bonsoir,

je réponds simplement à la dernière question, va vers MySQL surtout sur
une machine Linux. MySQL n'est en rien comparable à HF C/S, et surtout
tu as une base qui sera accessible à partir de n'importe quel outil.

La question HF C/S se pose lorsqu'on a déjà un existant sous HF, sinon
il est préférable d'aller vers des bases moins exotiques.

--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
Jacques TREPP
Le #14529001
"mat" news:
I.G.LOG wrote:
Bonjour,
Je suis en train de migrer une application WD8 -> WD12. La base est en HF
Classic partagée sur un serveur Linux (Fedora Core 3 - PS: je ne suis pas
un
spécialiste Linux) sous Samba. L'application WD8 fonctionne actuellement,
mais nous avons des problèmes de lenteur, ce qui a motivé la réécriture
de
l'appli en mode C/S; l'essentiel de mon travail a été de coder les accès
avec des requetes (avec SQLExec) plutot qu'avec des ordres H*.
Je dois aujourd'hui choisir entre HF C/S (que j'ai déjà installé sur le
serveur Linux pour essais) et MySQL. A votre avis, entre ces deux bases
de
données, y a t il des différences importantes en terme de performance ?
Par
ailleurs, PCSoft vient de sortir l'accès natif MySql. Est il plus
interressant d'avoir la base en MySQL/Linux ou sous Samba ? Je pose cette
question car je ne sais pas comment gérer les sauvegardes. Actuellement,
j'ai un serveur W2003, équipé d'un DAT, qui execute un batch de copie du
répertoire Samba puis sauvegarde sur bande (ca fonctionne bien). Dans le
cas
ou la base est sur Linux, je ne sais plus faire les sauvegardes !?
Merci pour vos avis.






Bonjour,
un simple script sous linux qui dumpe la ou les bases dans un répertoire
samba te permettra de continuer à sauvegarder comme avant.
Voici le script que nous utilisons:
#!/bin/sh -v
rm -f /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log
echo `date ` " - Rapport de sauvegarde" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log
echo `date ` " - Dump de toutes les bases dans /bureautique/basemag" >>
/home/sauve1.log

rm /bureautique/basemag/* -r -f
/usr/bin/mysqldump -u root --opt castres2 >
/bureautique/basemag/castres2.sql
/usr/bin/mysqldump -u root --opt cr_albi > /bureautique/basemag/cr_albi.sql
/usr/bin/mysqldump -u root --opt cr_gaill >
/bureautique/basemag/cr_gaill.sql
/usr/bin/mysqldump -u root --opt cr_lisle >
/bureautique/basemag/cr_lisle.sql
/usr/bin/mysqldump -u root --opt graulhet >
/bureautique/basemag/graulhet.sql
/usr/bin/mysqldump -u root --opt jmdo > /bureautique/basemag/jmdo.sql
/usr/bin/mysqldump -u root --opt lanuejou >
/bureautique/basemag/lanuejou.sql
/usr/bin/mysqldump -u root --opt rodez > /bureautique/basemag/rodez.sql
/usr/bin/mysqldump -u root --opt magasin > /bureautique/basemag/magasin.sql
/usr/bin/mysqldump -u root --opt p1 > /bureautique/basemag/p1.sql
/usr/bin/mysqldump -u root --opt p2 > /bureautique/basemag/p2.sql
/usr/bin/mysqldump -u root --opt p5 > /bureautique/basemag/p5.sql
/usr/bin/mysqldump -u root --opt p6 > /bureautique/basemag/p6.sql
/usr/bin/mysqldump -u root --opt pcx > /bureautique/basemag/pcx.sql
/usr/bin/mysqldump -u root --opt rachedi > /bureautique/basemag/rachedi.sql
/usr/bin/mysqldump -u root --opt thomas > /bureautique/basemag/thomas.sql
/usr/bin/mysqldump -u root --opt villefra >
/bureautique/basemag/villefra.sql
/usr/bin/mysqldump -u root --opt xtest > /bureautique/basemag/xtest.sql
/usr/bin/mysqldump -u root --opt gestcom > /bureautique/basemag/gestcom.sql
/usr/bin/mysqldump -u root --opt es_coach >
/bureautique/basemag/es_coach.sql
/usr/bin/mysqldump -u root --opt limayrac >
/bureautique/basemag/limayrac.sql
/usr/bin/mysqldump -u root --opt rocefran >
/bureautique/basemag/rocefran.sql
/usr/bin/mysqldump -u root --opt 000001 > /bureautique/basemag/000001.sql
/usr/bin/mysqldump -u root --opt 000002 > /bureautique/basemag/000002.sql
/usr/bin/mysqldump -u root --opt 000003 > /bureautique/basemag/000003.sql
/usr/bin/mysqldump -u root --opt 000030 > /bureautique/basemag/000030.sql
/usr/bin/mysqldump -u root --opt 000100 > /bureautique/basemag/000100.sql
echo `date ` " - Fin du Dump" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log

cordialement

--
Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)
I.G.LOG
Le #14528981
> Bonjour,
un simple script sous linux qui dumpe la ou les bases dans un répertoire
samba te permettra de continuer à sauvegarder comme avant.
Voici le script que nous utilisons:
#!/bin/sh -v
rm -f /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log
echo `date ` " - Rapport de sauvegarde" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log
echo `date ` " - Dump de toutes les bases dans /bureautique/basemag" >>
/home/sauve1.log

rm /bureautique/basemag/* -r -f
/usr/bin/mysqldump -u root --opt castres2 >
/bureautique/basemag/castres2.sql
/usr/bin/mysqldump -u root --opt cr_albi >
/bureautique/basemag/cr_albi.sql
/usr/bin/mysqldump -u root --opt cr_gaill >
/bureautique/basemag/cr_gaill.sql
/usr/bin/mysqldump -u root --opt cr_lisle >
/bureautique/basemag/cr_lisle.sql
/usr/bin/mysqldump -u root --opt graulhet >
/bureautique/basemag/graulhet.sql
/usr/bin/mysqldump -u root --opt jmdo > /bureautique/basemag/jmdo.sql
/usr/bin/mysqldump -u root --opt lanuejou >
/bureautique/basemag/lanuejou.sql
/usr/bin/mysqldump -u root --opt rodez > /bureautique/basemag/rodez.sql
/usr/bin/mysqldump -u root --opt magasin >
/bureautique/basemag/magasin.sql
/usr/bin/mysqldump -u root --opt p1 > /bureautique/basemag/p1.sql
/usr/bin/mysqldump -u root --opt p2 > /bureautique/basemag/p2.sql
/usr/bin/mysqldump -u root --opt p5 > /bureautique/basemag/p5.sql
/usr/bin/mysqldump -u root --opt p6 > /bureautique/basemag/p6.sql
/usr/bin/mysqldump -u root --opt pcx > /bureautique/basemag/pcx.sql
/usr/bin/mysqldump -u root --opt rachedi >
/bureautique/basemag/rachedi.sql
/usr/bin/mysqldump -u root --opt thomas > /bureautique/basemag/thomas.sql
/usr/bin/mysqldump -u root --opt villefra >
/bureautique/basemag/villefra.sql
/usr/bin/mysqldump -u root --opt xtest > /bureautique/basemag/xtest.sql
/usr/bin/mysqldump -u root --opt gestcom >
/bureautique/basemag/gestcom.sql
/usr/bin/mysqldump -u root --opt es_coach >
/bureautique/basemag/es_coach.sql
/usr/bin/mysqldump -u root --opt limayrac >
/bureautique/basemag/limayrac.sql
/usr/bin/mysqldump -u root --opt rocefran >
/bureautique/basemag/rocefran.sql
/usr/bin/mysqldump -u root --opt 000001 > /bureautique/basemag/000001.sql
/usr/bin/mysqldump -u root --opt 000002 > /bureautique/basemag/000002.sql
/usr/bin/mysqldump -u root --opt 000003 > /bureautique/basemag/000003.sql
/usr/bin/mysqldump -u root --opt 000030 > /bureautique/basemag/000030.sql
/usr/bin/mysqldump -u root --opt 000100 > /bureautique/basemag/000100.sql
echo `date ` " - Fin du Dump" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log



Bonjour,

Tout d'abord merci pour votre réponse (j'ai encore des progrès à faire avec
Linux)
mysqldump doit se faire sur chaque table ?
Ne peut on pas utiliser la commande "mysql -u root -p pw techavia >
/BaseSVG/techavia.sql" qui sauvegarde entièrement la base ?
Par ailleurs, peut on lancer ce script à une heure donnée (la nuit) ?!

Je reviens sur ma question de performance. A votre avis, il vaut mieux une
base MySQL "pure Linux" ou sous Samba ? (dans ce cas, ca règlerai ce
problème de sauvegarde puisque je peux lire la partition samba depuis un
poste windows)
Enfin, a t on des comparatifs de performances entre MySQL/Linux et HF/CS ?

Encore merci
Daniel
Le #14528961
I.G.LOG a écrit :
Bonjour,
un simple script sous linux qui dumpe la ou les bases dans un répertoire
samba te permettra de continuer à sauvegarder comme avant.
Voici le script que nous utilisons:
#!/bin/sh -v
rm -f /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
/home/sauve1.log




echo `date ` " - Rapport de sauvegarde" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
/home/sauve1.log




echo `date ` " - Dump de toutes les bases dans /bureautique/basemag" >>
/home/sauve1.log

rm /bureautique/basemag/* -r -f
/usr/bin/mysqldump -u root --opt castres2 >
/bureautique/basemag/castres2.sql
/usr/bin/mysqldump -u root --opt cr_albi >
/bureautique/basemag/cr_albi.sql
/usr/bin/mysqldump -u root --opt cr_gaill >
/bureautique/basemag/cr_gaill.sql
/usr/bin/mysqldump -u root --opt cr_lisle >
/bureautique/basemag/cr_lisle.sql
/usr/bin/mysqldump -u root --opt graulhet >
/bureautique/basemag/graulhet.sql
/usr/bin/mysqldump -u root --opt jmdo > /bureautique/basemag/jmdo.sql
/usr/bin/mysqldump -u root --opt lanuejou >
/bureautique/basemag/lanuejou.sql
/usr/bin/mysqldump -u root --opt rodez > /bureautique/basemag/rodez.sql
/usr/bin/mysqldump -u root --opt magasin >
/bureautique/basemag/magasin.sql
/usr/bin/mysqldump -u root --opt p1 > /bureautique/basemag/p1.sql
/usr/bin/mysqldump -u root --opt p2 > /bureautique/basemag/p2.sql
/usr/bin/mysqldump -u root --opt p5 > /bureautique/basemag/p5.sql
/usr/bin/mysqldump -u root --opt p6 > /bureautique/basemag/p6.sql
/usr/bin/mysqldump -u root --opt pcx > /bureautique/basemag/pcx.sql
/usr/bin/mysqldump -u root --opt rachedi >
/bureautique/basemag/rachedi.sql
/usr/bin/mysqldump -u root --opt thomas > /bureautique/basemag/thomas.sql
/usr/bin/mysqldump -u root --opt villefra >
/bureautique/basemag/villefra.sql
/usr/bin/mysqldump -u root --opt xtest > /bureautique/basemag/xtest.sql
/usr/bin/mysqldump -u root --opt gestcom >
/bureautique/basemag/gestcom.sql
/usr/bin/mysqldump -u root --opt es_coach >
/bureautique/basemag/es_coach.sql
/usr/bin/mysqldump -u root --opt limayrac >
/bureautique/basemag/limayrac.sql
/usr/bin/mysqldump -u root --opt rocefran >
/bureautique/basemag/rocefran.sql
/usr/bin/mysqldump -u root --opt 000001 > /bureautique/basemag/000001.sql
/usr/bin/mysqldump -u root --opt 000002 > /bureautique/basemag/000002.sql
/usr/bin/mysqldump -u root --opt 000003 > /bureautique/basemag/000003.sql
/usr/bin/mysqldump -u root --opt 000030 > /bureautique/basemag/000030.sql
/usr/bin/mysqldump -u root --opt 000100 > /bureautique/basemag/000100.sql
echo `date ` " - Fin du Dump" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
/home/sauve1.log







Bonjour,

Tout d'abord merci pour votre réponse (j'ai encore des progrès à faire avec
Linux)
mysqldump doit se faire sur chaque table ?



Non.

Si tu es en innodb (moteur transactionnel) et pour garder la cohérence
des data lors d'une sauvegarde à chaud il faut ajouter --single-transaction


commande pour une sauvegarde totale
mysqldump --single-transaction -u Mysql_User -h Mysql_host -pMysql_Paswd
db | gzip -6 > db.gz

gzip permet de compresser la sauvegarde car le fichier peut devenir très
volumineux.

Ne peut on pas utiliser la commande "mysql -u root -p pw techavia >
/BaseSVG/techavia.sql" qui sauvegarde entièrement la base ?



Oui
Par ailleurs, peut on lancer ce script à une heure donnée (la nuit) ?!*




Oui par exemple pour faire une sauvegarde à 5h16 tous les jours et
envoyé le compte rendu par mail faire

crontab -e
16 5 * * * /root/cron/backup_mysql_ftp.sh | mail -s
"Sauvegarde Serveur MySQL"




Je reviens sur ma question de performance. A votre avis, il vaut mieux une
base MySQL "pure Linux" ou sous Samba ? (dans ce cas, ca règlerai ce
problème de sauvegarde puisque je peux lire la partition samba depuis un
poste windows)


Pas de rapport, Samba est simplement un partage qui est accessible par
Windows.

On n'a pas besoin d'avoir des répertoires partagés pour faire
fonctionner Mysql (tout comme HF C/S)

Dans mon cas mes sauvegardes sont faites tous les jours en automatique
sur un autre serveur par ftp, et sur le serveur de sauvegarde j'ai
toujours les 15 dernières sauvegardes (jours) en ligne.


Enfin, a t on des comparatifs de performances entre MySQL/Linux et HF/CS ?




Aucun intérêt de faire ce type de comparatif car les bases sont
incomparables.

HF a simplement une légitimité par rapport à Windev.



Encore merci






--
suivre ce lien pour répondre:
http://cerbermail.com/?2KrV3YZXnn
Daniel
;-)
I.G.LOG
Le #14528951
Merci beaucoup à vous tous pour vos réponses éclairées !!
Phil
Jacques TREPP
Le #14528931
"I.G.LOG" news:47da5156$0$859$
Bonjour,
un simple script sous linux qui dumpe la ou les bases dans un répertoire
samba te permettra de continuer à sauvegarder comme avant.
Voici le script que nous utilisons:
#!/bin/sh -v
rm -f /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log
echo `date ` " - Rapport de sauvegarde" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log
echo `date ` " - Dump de toutes les bases dans /bureautique/basemag" >>
/home/sauve1.log

rm /bureautique/basemag/* -r -f
/usr/bin/mysqldump -u root --opt castres2 >
/bureautique/basemag/castres2.sql
/usr/bin/mysqldump -u root --opt cr_albi >
/bureautique/basemag/cr_albi.sql
/usr/bin/mysqldump -u root --opt cr_gaill >
/bureautique/basemag/cr_gaill.sql
/usr/bin/mysqldump -u root --opt cr_lisle >
/bureautique/basemag/cr_lisle.sql
/usr/bin/mysqldump -u root --opt graulhet >
/bureautique/basemag/graulhet.sql
/usr/bin/mysqldump -u root --opt jmdo > /bureautique/basemag/jmdo.sql
/usr/bin/mysqldump -u root --opt lanuejou >
/bureautique/basemag/lanuejou.sql
/usr/bin/mysqldump -u root --opt rodez > /bureautique/basemag/rodez.sql
/usr/bin/mysqldump -u root --opt magasin >
/bureautique/basemag/magasin.sql
/usr/bin/mysqldump -u root --opt p1 > /bureautique/basemag/p1.sql
/usr/bin/mysqldump -u root --opt p2 > /bureautique/basemag/p2.sql
/usr/bin/mysqldump -u root --opt p5 > /bureautique/basemag/p5.sql
/usr/bin/mysqldump -u root --opt p6 > /bureautique/basemag/p6.sql
/usr/bin/mysqldump -u root --opt pcx > /bureautique/basemag/pcx.sql
/usr/bin/mysqldump -u root --opt rachedi >
/bureautique/basemag/rachedi.sql
/usr/bin/mysqldump -u root --opt thomas > /bureautique/basemag/thomas.sql
/usr/bin/mysqldump -u root --opt villefra >
/bureautique/basemag/villefra.sql
/usr/bin/mysqldump -u root --opt xtest > /bureautique/basemag/xtest.sql
/usr/bin/mysqldump -u root --opt gestcom >
/bureautique/basemag/gestcom.sql
/usr/bin/mysqldump -u root --opt es_coach >
/bureautique/basemag/es_coach.sql
/usr/bin/mysqldump -u root --opt limayrac >
/bureautique/basemag/limayrac.sql
/usr/bin/mysqldump -u root --opt rocefran >
/bureautique/basemag/rocefran.sql
/usr/bin/mysqldump -u root --opt 000001 > /bureautique/basemag/000001.sql
/usr/bin/mysqldump -u root --opt 000002 > /bureautique/basemag/000002.sql
/usr/bin/mysqldump -u root --opt 000003 > /bureautique/basemag/000003.sql
/usr/bin/mysqldump -u root --opt 000030 > /bureautique/basemag/000030.sql
/usr/bin/mysqldump -u root --opt 000100 > /bureautique/basemag/000100.sql
echo `date ` " - Fin du Dump" >> /home/sauve1.log
echo
"--------------------------------------------------------------------------------"
>> /home/sauve1.log



Bonjour,

Tout d'abord merci pour votre réponse (j'ai encore des progrès à faire
avec
Linux)
mysqldump doit se faire sur chaque table ?
Ne peut on pas utiliser la commande "mysql -u root -p pw techavia >
/BaseSVG/techavia.sql" qui sauvegarde entièrement la base ?
Par ailleurs, peut on lancer ce script à une heure donnée (la nuit) ?!



Pardon. Mon script est un peu long. En fait, chaque ligne sauvegarde
entièrement une base . Chacune des bases représente un point de vente, d'où
la multiplicité des bases.

cordialement
--
Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)
Jacques TREPP
Le #14528921
"Daniel" news:47da5c98$0$9570$


Si tu es en innodb (moteur transactionnel) et pour garder la cohérence
des data lors d'une sauvegarde à chaud il faut
ajouter --single-transaction


commande pour une sauvegarde totale
mysqldump --single-transaction -u Mysql_User -h Mysql_host -pMysql_Paswd
db | gzip -6 > db.gz

gzip permet de compresser la sauvegarde car le fichier peut devenir très
volumineux.




Merci Daniel, pour cette indication.
Je vais modifier mon script

--
Jacques TREPP
Albygest
3, rue Jean Mermoz
81160 ST-JUERY
(enlevez 'pasdespam' pour me joindre)
J.B.
Le #14528901
Le Fri, 14 Mar 2008 14:12:58 +0100, Jacques TREPP a écrit:

"Daniel" news:47da5c98$0$9570$


Si tu es en innodb (moteur transactionnel) et pour garder la cohérence
des data lors d'une sauvegarde à chaud il faut ajouter
--single-transaction


commande pour une sauvegarde totale
mysqldump --single-transaction -u Mysql_User -h Mysql_host
-pMysql_Paswd db | gzip -6 > db.gz

gzip permet de compresser la sauvegarde car le fichier peut devenir
très volumineux.




Merci Daniel, pour cette indication.
Je vais modifier mon script




bzip2 -9 compresse plus.

--
J.Bratières
Publicité
Poster une réponse
Anonyme