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

[ukanoldai]

je mets également en place la version avec pipe, certains d'entre vous font des dumps de plusieurs centaines de go avec cette méthode? histoire de savoir si je risque de me heurter a des problemes.

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...

Je ne suis pas dba, je fais du datawarehouse, on ne me paie que pour des données de qualiteye :/

[philcero]

Plus sérieusement, j'ai expérimenté la méthode avec fichier PIPE (Qui est plus rapide car évite des I/O inutiles) sur des exports de schémas de plusieurs gigas (De tête je dirais une vingtaine au maximum) sans aucun problème (Export & import).

[Invité]

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

Pareil avec des exports de 150 Go et je n'ai pas eu de problème.

[ukanoldai]

pour le pipe j'utilise ceci: gzip < mon_pipe > mon_dump_zippé et par la suite je file le pipe a exp.
je ne sais pas trop si c'est la méthode la plus optimale.

après quelques petits dumps de 3go compressé en 200mo j'ai testé ca sur un dump estimé a 100go, au bout de 3h30 (je trouve ca extrèmement long mais je manque de repère) il m'a fait un gz de 10go.
La machine est un sun V20Z.
Je vais tester ce soir le même dump non compressé pour voir si j'ai un gain.

[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...

[laurentschneider]

on a bien compris, il porte sur le vieil export et non de Data Pump Export mais je pensais utile de préciser que l'approche avec mknod en fonctionne que pour le vieil export

[orafrance]

en effet, la précision est très judicieuse

[philcero]

Vu comme ça, je suis pas contre...

[ukanoldai]

bon, compressé ou pas la durée de l'export ne change pas trop, 3h30 pour la version compressée, 3h10 pour la non-compressée, tout cela pour un dump non-compressé de 105go, cela vous parait honorable ou juste naze? sachant que l'instance était en prod mais rien d'extrèmement lourd.

[laurentschneider]

si tu es sur UNIX, COMPRESS est beaucoup plus rapide que GZIP

[philcero]

Dans la famille précisions : COMPRESS n'est ni plus rapide, ni plus performant que GZIP.

J'avais fait des essais sur un AIX 4.3 et le ratio allait de 2 à 3 pour la taille suivant les fichiers (Essai réalisé avec un EXP 8.1.7 via fichier PIPE) et divisant le temps de backup par plus de deux (De tête on était passé à procédure égale de 2h0xm à 0h54m. Je me rappelle du 54m car j'avais fais nue belle présentation au client derrière pour justifier mon salaire...



Pour info, j'utilise toujours une commande type : gzip -c5 > madb.exp.gz

Pour être sûr, j'ai fait un petit test rapide (SOLARIS 10, fichier DBF de 100Mo).

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
$ time cat /appli/oradata08/WPSOCLE/patroltemp.dbf | gzip -c5 > patroltemp.dbf.gz
 
real    0m4.17s
user    0m3.71s
sys     0m0.70s
$ time cat /appli/oradata08/WPSOCLE/patroltemp.dbf | compress -c > patroltemp.dbf.compress
 
real    0m26.16s
user    0m25.77s
sys     0m0.65s
$ ls -l patroltemp.dbf.*
-rw-r-----   1 root     root     1323663 May 14 09:33 patroltemp.dbf.gz
-rw-r-----   1 root     root     1640575 May 14 09:34 patroltemp.dbf.compress

Toujours pareil...

[laurentschneider]

sans doute que mes tests datent aussi de aix 4.3

en tout cas merci pour la correction!

J'ai testé aussi, un fichier dump de 800Mb

AIX 5.3

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
$ time gzip -5 test1.dmp 
 
real    1m12.05s
user    1m1.59s
sys     0m1.95s
$ time compress test2.dmp
 
real    1m18.31s
user    1m8.89s
sys     0m2.10s
 
$ ls -la test*
-rw-r--r--   1 oracle   dba       228927280 May 14 09:47 test1.dmp.gz
-rw-r--r--   1 oracle   dba       382597957 May 14 09:47 test2.dmp.Z

Sur Solaris 10

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
$ time gzip -5 test3.dmp
 
real    1m51.43s
user    1m24.11s
sys     0m4.82s
$ time compress test4.dmp
 
real    1m47.99s
user    1m23.40s
sys     0m6.99s
$ ls -la test*
-rw-r--r--   1 oracle   dba      228927280 May 14 09:53 test3.dmp.gz
-rw-r--r--   1 oracle   dba      382618037 May 14 09:53 test4.dmp.Z

pas de différence significative (la différence entre Solaris et AIX n'a bien sûr pas de signification particulière, attendu que le serveur AIX est plus rapide)