Discussion :

[lecharcutierdelinux]

Bonjour à tous,
Nous venons de passer de la version 8 à la 9 au boulot et je me suis empressé d'acheter le livre Oracle 9i dba.

Cependant j'ai un doute sur l'utilité de mettre mes datafiles en mode autoextend? Quelle est l'utilité de créer des tablespaces qu'avec des datafiles en autoextend puisque qu'une condition maxsize doit être mise?
Voir grossir le fichier sur le disque????

De plus cela ajoute la confusion a la taille réelle utilisé par le tablespace. Car il y a l'occupation des données de la somme POSSIBLE des fichiers (si max atteint) et l'occupation des données de la somme actuelles des fichiers.... vraiment c'est trop étrange.

Encore deux choses,
Est-il possible de créer un Tablespace avec à la fois des fichiers en autoextend et d'autre non?
Quel est l'avantage de passer en mode local?


Je me demande vraiment si c'est une évolution...

Merci!

[orafrance]

l'intérêt c'est de ne s'occuper de l'espace disque physique. Ainsi il n'y a plus qu'une surveillance systéme au lieu d'une double surveillance Oracle (pour le tablespace) + systéme (sur le file system). Ceci étant, personnellement je n'aime pas laisser Oracle sans surveillance, je ne l'utilise donc pas
En plus, un fichier de 100Go c'est pas évident à caser sur une bande pour la sauvegarde

Si je ne m'abuse le MAXSIZE n'est pas obligatoire

Pour le mode LOCAL, il permet une meilleur gestion de l'allocation d'espace et moins de contention sur les tablespaces en stockant les infos dans les entêtes de fichier plutôt que dans le dictionnaire de données... bref, c'est mieux

pour info : http://oracle.developpez.com/guide/a...e/tablespaces/

[Jaouad]

Il faut effectivement surveiller Oracle. Aprés cela dépend réellement de la méthode de travail de chacun.

Je m'explique : Un datafiles ne pourrat jamais avoir une taille de plusieurs centaines de GIGA . La taille max d'un datafiles se détermine ainsi :

DBA_DATA_FILES.MAXBYTES , ou alors on peut la déterminer en faisant

DBA_DATA_FILES.MAXBLOCKS * BLOCKSIZE

que l'on retrouve ainsi :

Code :

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

1
2
 
SELECT name , value FROM V$PARAMETER where name = 'db_block_size'

Donc pour une 8i avec un block_size de 8Ko la taille max d'un datafiles est de 32 GO.

Moi mes TBS sont toujours en auto extend , avec des alertes de seuil sur les FS. Car si un progiciel, un ERP ou autre logiciel remplit la base de données , on ne peut que détecter la cause et remonter l'information au plus vite. On ne pourrat en aucun cas proclamer que le fichier est assez remplit.

Cependant Fred a soulevé un probléme crucial, la base de données étant en interaction avec d'autres univers il faut penser systématiquement à la manipulation des fichiers ( sauvegardes, copies d'environnement , déplacement des fichiers ... )

On peut avoir pour un seul TBS différents fichiers de données l'un en auto extend l'autre pas.

Un TBS en mode locally managed , est mieux qu'en dictionnary managed ( c'est option existe déja en 817 ) tout simplement parce que les informations sont contenus dans le header de fichier et non plus dans le TBS system. Ce qui diminue les ordres récurisifs et de facto diminue les éventuels goulots d'étranglements

Bon courage à toi

[lecharcutierdelinux]

Super,
Merci pour vos réponses.
Cependant j'aimerais que vous m'éclaireriez sur un point:

Admetons le tables TBS, ce tablespace est composé de 3 datafiles:
tb1s.dbf (maxsize 2000M) = taille actuelle 1000M avec un next à 100M.
tbs2.dbf (maxsize 2000M) = taille actuelle 1000M avec un next à 100M.
tbs3.dbf (maxsize 2000M) = taille actuelle 1000M avec un next à 100M.

J'ai donc dans ce tablespace TBS 3000M de données actuellement mais un total potentiel de 3x2000=6000M, on est d'accord?

Le problème c'est que le taux d'occupation du tablespace est proche de 100% d'après l'ERP que j'utilise (SAP l'usine à gaz). En effet sur les 3000M actuellement de données, il doit réelement y en avoir 2900M.

Comment avoir une vraie vision de l'état d'occupation du tablespace sachant que normalement il devrait être environ à 50%. (environ 3000 sur 6000M si les 3 datafiles sont à leur max).
C'est quasiment impossible d'administrer avec les infos que renvoit SAP, je suis toujours proche des 100% et je ne sais jamais si ils sont réelement saturés.



Question 2 : Est-ce que ce principe de datafile en autoextend évite la gestion des tables et segment en général "next" "maxextend"...? logiquement oui?

D'avance merci!!!! Heureux de voir qu'il y est des dba sur le forum!

[Pomalaix]

Le problème c'est que le taux d'occupation du tablespace est proche de 100% d'après l'ERP que j'utilise (SAP l'usine à gaz). En effet sur les 3000M actuellement de données, il doit réelement y en avoir 2900M.

Comment avoir une vraie vision de l'état d'occupation du tablespace sachant que normalement il devrait être environ à 50%. (environ 3000 sur 6000M si les 3 datafiles sont à leur max).
C'est quasiment impossible d'administrer avec les infos que renvoit SAP, je suis toujours proche des 100% et je ne sais jamais si ils sont réelement saturés.

Vous n'êtes pas dans la bonne logique.
Le principe même du tablespace autoextensible, c'est de friser en permanence une occupation de 100%, tout en s'agrandissant autant que nécessaire.
Ce que SAP vous donne, c'est le pourcentage d'espace occupé par rapport à l'espace alloué (3000 Mo), alors que vous cherchez à connaître le pourcentage d'espace occupé par rapport à l'espace allouable (6000 Mo).

Avec le tablespace autoextensible, l'idée est de privilégier une vue externe (OS). On ne se préoccupe plus du taux d'espace vide dans le tablespace, car il n'y a plus de vide ; on se contente de regarder combien de place les fichiers prennent sur disque, et surtout combien il en reste.
A ce titre, on peut tout à fait mettre tous les tablespaces en extension illimitée (sauf les temporaires quand même, une explosion incontrôlée est vite arrivée), dès lors qu'on a un dispositif de surveillance qui peut générer une alerte si l'espace libre sur le disque passe en-deçà d'un plancher fixé, par exemple 20%.

[pifor]

Question 2 : Est-ce que ce principe de datafile en autoextend évite la gestion des tables et segment en général "next" "maxextend"...? logiquement oui?

Non, ce sont 2 notions différentes: la gestion des clauses de stockage au niveau segment (dictionary management tablespace=DMT) ou au niveau du tablespace (locally managed tablespace=LMT) se gère au niveau de la création du tablespace. Voir les options de la commande CREATE TABLESPACE: http://oracle.developpez.com/guide/a...lespaces/#L1.2