Version imprimable
Bonjour,
je me demandais pourquoi ce n'était pas bon de compresser (gzip) un fichier dump?
Car je viens d'arriver en poste et mon prédécesseur faisait des compressions de dump, dois-je abandonner cette méthode et mieux gérer autrement mon espace disque pour mes sauvegardes?
Merci d'avance
je ne vois aucune raison de ne pas pouvoir compresser un dump.
Personnellement, je n'ai jamais eu aucun problème en le faisant.
Je connais bien ce genre de problèmes, en fait c'est avant tout de la politique (Dans le sens technique du terme).
Il faut se poser avant tout les questions suivantes :
1. En cas de gros pépin et où Oracle en personne devrait intervenir sur la base de mon boss (Qui perd 1000€ pour chaque minute d'indisponibilité) suis-je capable de fournir dans une arborescence annexe le double de ma base à J-A de manière à ce qui puisse être sauvé le soit ?
2. La base, son dump donc, est-elle suffisamment grosse pour justifier une compression (Gagner 10Mo ça rime à rien aujourd'hui).
3. Mes scripts de compression/décompression prennent-t'ils en charge une vérification des fichiers compressés qui garantissent qu'aucune altération pour raison X ou Y soit indétectable ?
Pour ma part je suis pour, mais faut quand même se poser les questions qui fachent avant tout :)
Réponse de murphy :
1 - En cas de gros pépin, ton dump ne te sauveras pas ; (il sera altéré:lol:) si tu ne peux pas restaurer très vite la structure de ta table, ton dump sera inutile.
2 - Si c'est très gros, ta compression risque de foirer.....:king:
3 - Rien n'est jamais garanti en informatique. Le mieux étant de tester, pour voir ; c'est le plus sûr !
La compression (gzip par exemple) permet quasiment de diviser par 10 la taille, ce n'est pas négligeable
A chaque dump, le plus sûr est de tester ça validité en lançant l'import avec show=y, pour en fait juste voir le contenu du dump
Si l'import avec show=y ne renvoie pas d'erreur, on peut considérer que le dump est bon et réutilisable en cas de soucis
Tout d'abord merci pour vos réponses, en fait je posais la question car j'ai vu cela sur le lien suivant qui vient de ce site :
http://oracle.developpez.com/guide/s...alites/#L1.3.a
Sinon actuellement dans mon entreprise avec gzip nous passons d'un dump de 50Go à un fichier .tar.gz de 8Go donc gros gain de place mais je viens de faire plusieurs test d'import sur une base miroir et l'importation se termine toujours avec des erreurs.
Je vais refaire d'autre test et je vous tiens au courant.
Merci
avec quelles erreurs?
Des erreurs du type :
Code:IMP-00041: Attention : objet créé avec erreurs de compilation
voici deux exemples car je ne comprends pas pourquoi il ne compile pas????Code:
2
C'est parce que tu importes une table dépendant de FK et pour lesquelles les clés référencées ne sont pas trouvées, ça n'a rien à voir avec la compression de ton dump
Quand tu importes, il faut importer un ensemble de tables indépendantes des autres d'un point de vue des contraintes de clés étrangères, sinon tu auras des données incohérentes
Le plus simple étant encore d'exporter/importer un schéma complet si aucune de ces tables n'a de dépendances sur des tables d'un autre schéma
Ce que je ne comprends pas c'est que c'est un export full database et un import full database donc il devrait trouver la dépendance, non???
Sauf si pendant ton export full database, des tables étaient en cours de modification, dans ce cas tu peux avoir une sauvegarde incohérente ...
ok merci mais j'ai encore une question comme le dump se fait à chaud j'aurais toujours des problèmes d'incohérences alors comment faire pour éviter cela?
Encore merci de tes éclaircissements.
Deux choses :
1. Tu fais un export consistent (En une seule transaction) en utilisant l'option consistent=Y donc pas d'incohérence.
2. Tu fais ton import en DEUX passes, une première avec les tables et les données (rows=y constraints=n), une deuxième avec les contraintes (rows=n constraints=y) et tout cela avec un jolie (ignore=y).
Merci à vous tous, je vais essayer comme cela alors et je vous tiens au courant.
Bien vu le consistent=Y, je ne connaissais pas ! :king:Citation:
Envoyé par philcero
Je préconise cela plutôt que l'import en 2 fois, car ce dernier ne changerait rien à l'incohérence potentielle des données, c'est juste que les contraintes concernées ne seraient pas réactivées, donc danger futur ...
faut quand même juste faire attention à la taille du UNDO avec le consistent=y.
si l'export est long une fois qu'il a commencé et que les tables continuent à évoluer de par les utilisateurs, il y a une forte consommation de UNDO pour garder la double cohérence entre la version "figée" l'export et la version "live" des utilisateurs...
donc éventuellement penser à adapter le tablespace UNDO en fonction...