Discussion :

[ukanoldai]

Bonjour,
en plus des snapshot pris au niveau du san par mon cher administrateur je voudrais faire un dump par schema, le snapshot fait +/- 2T donc ca devient monstrueux a restaurer, par schema les plus gros font dans les 300go une fois dumpé.
Mais évidemment ca fait qques centaines de go au total et donc je voudrais compresser mes dump, mais ils semblent avoir des contrindications au format zip, j'ai fais la recherche sur le forum et cela ne semblait (?) toucher que le zippage sous windows. En tout cas c'est difficile de se faire un avis tranché au vu des commentaires sur le net.

mais concrètement, qui a déja eu, jamais eu de soucis lors d'une restauration d'un dump compressé? parceque j'ai un peu de mal a voir al différence entre un dump et un iso par exemple, et donc une compression qui changerait le fichier décompressé ca me parait assez dingue, mais concevable (quand on bosse en info on se fait petit a petit a presque tout).


dans ce post ci c'est finalement le tar qui en ressort: http://www.developpez.net/forums/sho...light=dump+zip

bref, dur dur de se faire un avis sans se casser les dents une premiere fois sur ce probleme. Précision éventuelle, je suis en 9.2.0.7 sur du redhat

Merci de votre aide

[orafrance]

il semblerait qu'une compression convenablement effectuée ne corromps pas le dump, le problème dont certains se sont fait l'echo était probablement causé par un bug de l'outil de compression.

Donc, tu n'as rien à craindre

[philcero]

Pour avoir expérimenté le problème de multiples fois, les outils de compression ont souvent des tailles limites au niveau des fichiers décompressés. sous UNIX il ne faut pas hésiter à faire de la compression/décompression en mode chaîné (PIPE en ligne de commande ou fichier PIPE).

Pour ma part j'utilise GZIP mais attention, il y a plusieurs versions et il faut bien faire gaffe à laquelle on prends. Les premières étaient limitée (Je pense 2Go par fichier).

De plus, ne surtout pas hésiter à TESTER le fichier compressé une fois celui-ci efefctué (gzip -t, ...) afin de garantir le contenu.

[ukanoldai]

merci des conseils, je vais essayer de faire un truc super carré.

le gzip installé est le 1.3.3, je vais voir ce qu'il a dans le ventre.

pas mal de refaire l'exercice de se réintéresser a ses dump, c'est fou le nombre de tables d'un ptit giga qu'on peut retrouver et qui ne servent plus a rien

[philcero]

c'est fou le nombre de tables d'un ptit giga qu'on peut retrouver et qui ne servent plus a rien

Si on considère que l'importance du DBA est liée au volume d'informations brassées et stockées dans la société, on peut dire que ces petits gigas sont autant de parties de ton salaire. Les garder ça n'a jamais fait de mal à personne...

[scheu]

Perso j'ai toujours utilisé gzip, chaîné avec des pipe/fifo, je n'ai jamais eu de problème

[laurentschneider]

sous UNIX il ne faut pas hésiter à faire de la compression/décompression en mode chaîné (PIPE en ligne de commande ou fichier PIPE).

ça ne marche que dans le vieil export, ne fais jamais ça avec data pump

Avec un outil récent, oublie gzip et utilise EXPDP COMPRESSION=ALL

[scheu]

ça ne marche que dans le vieil export, ne fais jamais ça avec data pump

Avec un outil récent, oublie gzip et utilise EXPDP COMPRESSION=ALL

D'ailleurs créer une fifo et l'utiliser pour exporter en datapump ne marche pas : on tombe sur une erreur "ORA-27038 file to create already exists" qui n'est apparemment pas contournable, d'après ce sujet

[philcero]

Vous éloignez pas du sujet, il porte sur EXPORT et non DATA PUMP...