[9i] re-dimension des datafiles

Version imprimable

05/02/2007, 14h29
sygale

[9i] re-dimension des datafiles

Bonjour, je dois "purger" notre base de donnée.

Pour cela j'ai sélectionner les tables les plus volumineuse :
- je supprime les données des tables (delete / truncate)
- je lance une analyze [...] statistics

Ensuite, je dois re-dimensionner les datafailes des tablespaces impactés.
Je connais les TBS, je connais donc les Datafiles,

Cependant comment bien redimensionner ces datafiles au plus juste?

Quelle est votre méthode ?

Merci d'avance

J'ai un doute mais en
Code:

1 2 Oracle9i Enterprise Edition Release 9.2.0.3.0 - 64bit Production PL/SQL Release 9.2.0.3.0 - Production
Nous pouvons bien re dmensionner les datafiles en les augmentant ou les diminuant ??
Code:

1 2 ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf' RESIZE 100M;

05/02/2007, 15h58
cquilgars
Bonjour,

Je confirme que cette commande est correcte.
Dans le cas d'une augmentation, il n'est pas nécessaire de purger la table ...
Dans le cas d'une diminution, je ne connais pas les effets de bord :oops:

Que veux-tu par

Citation:

Envoyé par sygale

Cependant comment bien redimensionner ces datafiles au plus juste?

J'ai quelques questions :
- Est-ce que la volumétrie évolue sensiblement ?
- Dois-tu augmenter globalement le volume de ta base ?
- Est-ce qu'il y a une forte activité transactionnelle ?
- Quel est ton mode de gestion des tablespaces ?
- Ton MPD possède-t-il des tables à fort volume ?

Tu peux lancer ceci connecté SYSDBA :

Code:

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
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
 
set verify off
column file_name format a50 word_wrapped
column smallest format 999,990 heading "Smallest|Size|Poss."
column currsize format 999,990 heading "Current|Size"
column savings  format 999,990 heading "Poss.|Savings"
break on report
compute sum of savings on report
 
column value new_val blksize
select value from v$parameter where name = 'db_block_size'
/
spool resize.sql
select file_name,
       ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) smallest,
       ceil( blocks*&&blksize/1024/1024) currsize,
       ceil( blocks*&&blksize/1024/1024) -
       ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) savings
from dba_data_files a,
     ( select file_id, max(block_id+blocks-1) hwm
         from dba_extents
        group by file_id ) b
where a.file_id = b.file_id(+)
/
 
column cmd format a90 word_wrapped
 
select 'alter database datafile ''' || file_name || ''' resize ' ||
       ceil( (nvl(hwm,1)*&&blksize)/1024/1024 )  || 'm;' cmd
from dba_data_files a,
     ( select file_id, max(block_id+blocks-1) hwm
         from dba_extents
        group by file_id ) b
where a.file_id = b.file_id(+)
  and ceil( blocks*&&blksize/1024/1024) -
      ceil( (nvl(hwm,1)*&&blksize)/1024/1024 ) > 0
order by tablespace_name
/ 
spool off
 
###################################################################################
###################################################################################
###################################################################################
 
REM be connected as sysdba !
REM for locally managed only
 
set linesize 500 pagesize 0 feedback off trimspool on
 
select sum(bytes)/1024/1024/1024 "Size DB in Go" from dba_data_files;
 
connect '/ as sysdba'
spool resize.sql
SELECT
  '/* '||to_char(CEIL((f.blocks-e.hwm)*(f.bytes/f.blocks)/1024/1024),99999999)||' M */ ' ||
  'alter database datafile '''||file_name||''' resize '||CEIL(e.hwm*(f.bytes/f.blocks)/1024/1024)||'M;' SQL
FROM
  DBA_DATA_FILES f,
  SYS.TS$ t,
  (SELECT ktfbuefno relative_fno,ktfbuesegtsn ts#,
  MAX(ktfbuebno+ktfbueblks) hwm FROM sys.x$ktfbue GROUP BY ktfbuefno,ktfbuesegtsn) e
WHERE
  f.relative_fno=e.relative_fno and t.name=f.tablespace_name and t.ts#=e.ts#
  and f.blocks-e.hwm > 1000
  and f.tablespace_name != (select value from v$parameter where name = 'undo_tablespace')
ORDER BY f.blocks-e.hwm DESC
/
 
spool off

cela génère le fichier resize.sql qui retaille les datafiles à la plus petite valeur possible sachant qu'il ne peut pas descendre en dessous du dernier extent allouer donc TRUNCATE au lieu de DELETE pour libérer ces extents ;)

05/02/2007, 17h37
sygale
Super merci beaucoup à vous deux je vais tester tout ceci

Dans mon cas, je souhaite gargner de la place, donc sur les tables d'archivage :
- j'exporte les tables
- TRUNCATE
- analyse
-redimension des datafiles

mais question bête la table dba_segments est mis à jour en lancant

Code:

analyze table monschema.matable compute statistics

ou
Code:

1 2 3 4 5 begin dbms_stats.GATHER_TABLE_STATS( OWNNAME=>'monschema', TABNAME=>'matable'); end;
Pour être sur de gagner le plus de place, il faut mieux re dimmensionner

- truncate
- export
- suppression tablespace + .dbf
- création tablespace + .dbf
- import
?
05/02/2007, 22h05
orafrance

export avant truncate plutôt non ? Tu veux vider la base ?
06/02/2007, 09h47
laurentschneider

:bug: Il faut faire bien attention à ce genre de pratique. En effet, export et import ne garantit pas l'intégrité de la base. Il y a des milliers de bugs/limitations avec export/import, donc tu risques de ne pas avoir la même base avant qu'après. Il faut aussi voir que si la base est ONLINE, la base peut être inconsistente, même avec CONSISTENT=Y.

:idea: Une méthode plus propre serait de créer un nouveau tablespace et de déplacer les objets vers le nouveau tablespace (alter table move, alter index rebuild, etc...). Mais ça demande temporairement de l'espace supplémentaire. Par contre l'intégrité est assurée.
06/02/2007, 10h16
sygale

Citation:

Envoyé par Fred_D

export avant truncate plutôt non ? Tu veux vider la base ?

Non je pensais en fait que lors d'un import/export, je pourrais supprimer les max extends des segements et les listes chainées donc gagner encore plus de place non ?
Bien entendu je vais faire une sauvegarde complête de la base avant cette intervention

Citation:

Envoyé par laurentschneider

:bug: Il faut faire bien attention à ce genre de pratique. En effet, export et import ne garantit pas l'intégrité de la base. Il y a des milliers de bugs/limitations avec export/import, donc tu risques de ne pas avoir la même base avant qu'après. Il faut aussi voir que si la base est ONLINE, la base peut être inconsistente, même avec CONSISTENT=Y.

Waouhhh, l'export d'un user, ne garantit pas l'intégrité des données !

Citation:

Envoyé par laurentschneider

:idea: Une méthode plus propre serait de créer un nouveau tablespace et de déplacer les objets vers le nouveau tablespace (alter table move, alter index rebuild, etc...). Mais ça demande temporairement de l'espace supplémentaire. Par contre l'intégrité est assurée.

Malheureusement, la place est trop juste pour faire cette manipulation

Merci à vous
06/02/2007, 10h23
orafrance

Citation:

Envoyé par sygale

Non je pensais en fait que lors d'un import/export, je pourrais supprimer les max extends des segements et les listes chainées donc gagner encore plus de place non ?

oui mais si tu commences par le truncate tu risques pas d'exporter grand chose :?

l'ordre c'est export -> truncate -> import.

Citation:

Envoyé par Fred_D

oui mais si tu commences par le truncate tu risques pas d'exporter grand chose :?

l'ordre c'est export -> truncate -> import.

Ah oui mais en fait :
- je veux vraiement supprimer ces lignes
- ensuite l'import/export du schéma permerttera j'espere de gagner de la place sur les autres tables.

Mais cela ne fonctionne pas comme je pensais :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 select * from dba_segments OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME HEADER_FILE HEADER_BLOCK BYTES_1 BLOCKS EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_POOL MYSCHEMA MATABLE TABLE MONTBS 20 17289 728760320 88960 130 451788800 1 2147483645 1 1 20 DEFAULT TRUNCATE MYSCHEMA.MATABLE DROP STORAGE ; ANALYSE TABLE MYSCHEMA.MATABLE COMPUTE STATISTICS ; ANALYSE INDEX de la table MYSCHEMA.MATABLE select * from dba_segments OWNER SEGMENT_NAME PARTITION_NAME SEGMENT_TYPE TABLESPACE_NAME HEADER_FILE HEADER_BLOCK BYTES_1 BLOCKS EXTENTS INITIAL_EXTENT NEXT_EXTENT MIN_EXTENTS MAX_EXTENTS PCT_INCREASE FREELISTS FREELIST_GROUPS RELATIVE_FNO BUFFER_POOL MYSCHEMA MATABLE TABLE MONTBS 20 17289 452984832 55296 97 451788800 1 2147483645 1 1 20 DEFAULT
Donc je passe de 728760320 Octets à 452984832 Octets, cependant j'ai supprrimé toutes les occurence de cette table. l'INITIAL de la table est de 441200K, c'est pour cela non ?

Comment dois je faire pour récupérer les 730M de départ ??

re créer la table, ces indexs etc ....?

06/02/2007, 11h16
orafrance

vérifie la taille du INITIAL.
06/02/2007, 11h35
sygale

Oui tu as raison les INITAL sont à xxxM, je vais donc re-créer la tables

Merci à tous
06/02/2007, 12h26
laurentschneider

Citation:

Envoyé par sygale

Waouhhh, l'export d'un user, ne garantit pas l'intégrité des données !

c'est dans la doc :

Citation:

Export of certain metadata may require the use of the SYS schema within recursive SQL. In such situations, the use of CONSISTENT=y will be ignored. Oracle recommends that you avoid making metadata changes during an export process in which CONSISTENT=y is selected.

en effet, si au milieu de ton import, un utilisateur fait un DDL comme create table ou truncate table, cela correspond à un metadata change, et la consistence n'est pas garantie. C'est pourquoi je suis contre l'utilisation systématique de exp/imp pour "réorganiser" les données. Mieux vaut gaspiller l'espace disque que d'exporter et importer :aie: