[9i] re-dimension des datafiles

**sygale** · 05/02/2007, 15h29

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

**sygale** · 05/02/2007, 16h26

J'ai un doute mais en

Code :

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

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 :

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

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

**cquilgars** · 05/02/2007, 16h58

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

Que veux-tu par

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 ?

**orafrance** · 05/02/2007, 17h28

Tu peux lancer ceci connecté SYSDBA :

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

**sygale** · 05/02/2007, 18h37

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 :

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

analyze table monschema.matable compute statistics

ou

Code :

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

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
?

**orafrance** · 05/02/2007, 23h05

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

**laurentschneider** · 06/02/2007, 10h47

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.

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.

**sygale** · 06/02/2007, 11h16

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

Envoyé par laurentschneider

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 !

Envoyé par laurentschneider

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

**orafrance** · 06/02/2007, 11h23

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.

**sygale** · 06/02/2007, 11h58

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 :

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

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

**orafrance** · 06/02/2007, 12h16

vérifie la taille du INITIAL.

**sygale** · 06/02/2007, 12h35

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

Merci à tous

**laurentschneider** · 06/02/2007, 13h26

Envoyé par sygale

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

c'est dans la doc :

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

[9i] re-dimension des datafiles

Administration Oracle

Discussions similaires

Partager

Partager