Discussion :

[learn]

Salut,

l'export de la BD se fait chaque soir, il commence à 18h et se termine à 22h30.
j'ai essayé de jouer sur les paramètres de l'export pour réduire le temps mais pas de changements :
mon fichier .pre est :

Code :

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

1
2
3
4
5
6
7
 
FULL=Y
CONSISTENT=Y
OBJECT_CONSISTENT=Y
BUFFER=10240000
DIRECT=Y
RECORDLENGTH=65535

sa taille est de 23 Gig (compressé avec gzip)

Oracle 9.2.0.4 S.E. sur linux

merci pour toute lumière que vous pourrez m'apporter.

[fatsora]

Salut,

dans quel but tu fais de l'export / du full=y ?

bon, as- tu plusieurs schemas ?
si oui , peux -tu exporter en % les schemas

sinon faire une liste de tables et exporter en % les tables

-le fichier dump est il sur un ou autres disques que tes datas ?
- le disque d'export est il rapide ?

-essaie d'exporter sans gziper !

moi , j'ai constaté des changements en faisant 1 fois !!
-exec dbms_schema.gather.stats('sys')
-changer dan init.ora optimizer_mode first_rows en choose
(mais la c'était pour en finir avec zindozs et importer definitivement dans Solaris !!!)

-qu'est ce qui tourne sur ta base pendant ce temps la

-lance des analyze de waits !!!!

[LeoAnderson]

Attention... en règle générale, sauf avis express du support Oracle, il ne faut jamais calculer les stats sur les tables SYS ....

Attention... Jouer avec l'optimizer pour de "bêtes" problèmes de durée d'export, c'est prendre le risque de pourrir tout le fonctionnement de la base....

Est-ce que le zip e fait "on-the-fly" (technique avec mknod) ?
Mais 23 Go zippés, ça doit être pas loin de 120 Go non zippés, soit 120 Go de données "brutes" (taille du dump hors zip) ce qui semble correct pour une base d'environ 200 Go, non ?
Dans ce cas, les temps annoncés ne me semblent pas hallucinants... (ok, c'est une estimation du plus haut niveau pifométrique... )

Vu le volume et le consistent=Y, je suppose que vous êtes seul sur la base lorsque vous exportez... En quoi est-ce que le temps vous gêne donc ?

[learn]

Tout aller bien jusqu'au jour ou j'ai créé une table avec un champs BLOB pour contenir des images et cette table ne cesse de grossir elle fait 28 Gig à elle seule et le temps est passé du simple au double.

[LeoAnderson]

Et après ? vous avez du volume, c'est normal que ça prenne du temps... un export full va vous consommer tous les buffers, va faire des I/O du tonnerre de Zeus, ... bref, votre machine va être à fond....

mais quand je lance un scan anti-virus de mon disque dur de 30 Go sur mon PC, je sais que je peux aller prendre un graaaand café et que je peux oublier l'idée de recompiler un projet JAVA tout en convertissant en MPEG4 mon film de vacances....

[fatsora]

Tu as raison !!!


Il faut tester en test et ne rien prendre a la lettre dans la prod !!!

J'ai bien ecris je n'ai fait qu'une fois le dbms_stats de sys !!
sous oracle 9.2.0.6 et win 32 !!!!

mais je suis passé de 14h à 50 min !!! pour 24 Go d'export

de meme pour l'optimiseur , car c'etait pour abandonner definitivement
zindozs !!!!

donc c'est pas tjs des rep à toutes les situations

A+

[learn]

-Je n'ai jamais calcul les stats pour sys, je n'ai pas à y touché je m'occupe de mes objets. Pour moi Oracle devra prendre en charge ses objets sys.

-Mais avec Direct=Y le temps devra être reduit de 50% d'aprés la doc d'Oracle.

-Mon probleme c'est que les backups commencent une fois l'export terminé et des fois ça ne finit pas avant 7h du matin ce qui cause un désagrement.

[LeoAnderson]

-Je n'ai jamais calcul les stats pour sys, je n'ai pas à y touché je m'occupe de mes objets. Pour moi Oracle devra prendre en charge ses objets sys.

-Mais avec Direct=Y le temps devra être reduit de 50% d'aprés la doc d'Oracle.

-Mon probleme c'est que les backups commencent une fois l'export terminé et des fois ça ne finit pas avant 7h du matin ce qui cause un désagrement.

Ok, mais combien de temps cela met-il avec DIRECT=N ? si cela met 8h....

De plus, vous ne nous avez toujours pas communiqué la volumétrie de la base, ni l'organisation des données sur les disques, ni les caractéristiques de la machine, .....

donc c'est pas tjs des rep à toutes les situations

c'ets bien pour cela qu'il est évitable de suggérer de commencer par cela sans avoir cerner précisément le contexte !!! ;-)

[fatsora]

Bien d'accord avec vous tous

j'ai ecris au tout début

Salut,

dans quel but tu fais de l'export / du full=y ?

bon, as- tu plusieurs schemas ?
si oui , peux -tu exporter en % les schemas

sinon faire une liste de tables et exporter en % les tables

-le fichier dump est il sur un ou autres disques que tes datas ?
- le disque d'export est il rapide ?

-essaie d'exporter sans gziper !

moi , j'ai constaté des changements en faisant 1 fois !!

8)

J'ai écris j'ai constaté ca ... j'ai pas écris fais ca !!!!!

[fatsora]

Selon la doc Oracle si on a des LOB alors ca bypasse le direct =Y

There are 2 cases (from the server utilities guide) where direct path export
either will not be used by export OR export will just abort:

You cannot export certain tables using direct path. For example, you cannot
export tables using object features on LOBs. If you specify direct path for
export, tables containing objects and LOBs will be exported using conventional
path.

Direct path Export exports in the database server character set only. If the
character set of the export session is not the same as the database character
set when an export is initiated, Export displays a warning and aborts. Using the
NLS_LANG
parameter, specify the session character set to be the same as that of the
database before retrying the export.