J'ai une base Oracle qui fait 160 Go.
Je souhaiterais savoir le taille que fera l'export c'est-à-dire le .dump.
Quel est donc le taux de compression ?
Merci de votre réponse
J'ai une base Oracle qui fait 160 Go.
Je souhaiterais savoir le taille que fera l'export c'est-à-dire le .dump.
Quel est donc le taux de compression ?
Merci de votre réponse
C'est tout simplement impossible !
Au mieux, vous aurez une estimation en faisant la somme des dba_extents mais si les initial_extents sont surdimensionnés, l'estimation sera fausse.
Après, vous pouvez éventuellement, si les stats sont à jours, estimer la place réellement utilisée, mais sur une base entière de 160 Go, ça n'est pas envisageable.
Moi ce que je fais c'est que j'exporte un échantillon représentatif et après j'applique un ration au volume obtenu... Ca marche à quelques Go près...
Je ne sais pas si ça répond à la question, mais une fois que vous avez fait l'export, le fait de compresser le DMP permet couramment de diviser le volume par 5 à 7.
Il y a moyen sur Unix de connaitre la taille d'un export sans creer le fichier en redirigeant la sortie sur /dev/null. Voila la methode issue de Metalink:
J'utilise la methode sur des bases > 400G et ca marche tres bien. de plus, tu peux compresser le fichier en l'exportant, la compression etant naturellement dependante du contenu, mais sur des donnes classiques comme le dis pomalais on atteint facilement un facteur 5.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47 Doc ID: Note:106465.1 Subject: How to Estimate Export File Size Without Creating Dump File Type: BULLETIN Status: PUBLISHED Creation Date: 25-APR-2000 Last Revision Date: 21-OCT-2005 PURPOSE Estimate file size of export dumpfile without creating the actual dump file. How to estimate export dumpfile size using pipe, /dev/null, and dd This can be accomplished by using pipe to redirect exp output to dd. At the end of export, dd will report number of blocks written. This is illustrated in following steps. 1) Create a pipe called exp.pipe in /tmp directory (syntax may differ depending on platform) % cd /tmp % mknod exp.pipe p 2) Start reading from exp.pipe with dd, dump output to bit bucket (/dev/null), set blocksize to 1k and execute this process in background % dd if=/tmp/exp.pipe of=/dev/null bs=1024 & 3) Start the export, setting file=/tmp/exp.pipe % exp scott/tiger file=/tmp/exp.pipe 4) At the end of exp, look for numbers of records written Export terminated successfully without warnings. 5+0 records in 5+0 records out - '5+0 records out' shows 5 records of 1024 bytes were written to the exp dumpfile. - Step 2 specifies record size(bs) of 1024. - Size of actual dumpfile would be 1024*5 = 5120 bytes - Format of 'records out' is f+p, f=full blocks, p=partial block - For example, if step 4 returns '5+1 records out' Your actual dumpfile size will be between 5120 bytes(1024*5) and 6144 bytes(1024*6)
Si vous êtes en 10g, avec datapump vous pouvez avoir une estimation : Comment estimer l'export !![]()
Si tu as des statistiques, j'ai constaté que la somme des DBA_TABLES.BLOCKS se rapproche de la taille de l'export.
Moi on m'avait dit qu'il ne fallait pas compresser un DUMP !
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4 SELECT ROUND(((SUM(T1.BLOCKS) * 8192) / (1024*1024)),0) TOTAL_MO_UTILISES FROM SYS.DBA_TABLES T1
voir le lien :
http://oracle.developpez.com/guide/s...e/generalites/
C'est vraie ou pas ?
Vrai !Envoyé par PhPeltier
Enfin, c'est le principe général ... qui accepte donc des exceptions...
Mais de toute façon, j'exclue d'office rar ou autres.. pour ne garder que gz ou zip !
Partager