Discussion :

[franchet]

Bonjour,

Je débute dans Oracle, il faut bien commencer un jour.
J'ai bien regarder les messages, mais je ne trouve pas de réponse claire sur le sujet.
Voici le "detail" de l'installation.
Oracle 9i installer sur un serveur Sun 880.
La base Oracle se trouve sur une baie de disque.
Espace disque alloué: 500 Go
Aujourd'hui, les datafile créé ont une taille de 2 Go autoextend.
Une fois que toute nos données seront rentrées, je pense que nous aurons un Datafile pour la tabespace idata de environ 4 Go.
Qu'est-il mieu de faire:
Un gros Datafile de 4 à 6 go autoextend?
Ou plusieurs Datafile de 2 à 4 Go autoextend?

Qu'est ce qui est plus rapide? En terme de requete utilisateur, accés à la donnée?

Merci pour tout vos réponses et retour d'éxperience.

[guigui_cwoco]

La seule contrainte que je connaisse sur ce sujet sont des contraintes imposées par l'OS.

Avec la 10G tu peux créer des BIGFILE TABLESPACE (1 datafile énorme par tablespace), mais est ce que du coté OS ca pose pas de problemes ?!

Personnellement je me limite a des fichiers de données de 2go pour le moment.

[orafrance]

il y a aussi la taille du bitmap en entete de fichier qu'il ne faut pas négliger. Personnellement, je prèfère faire plusieurs fichiers, ne serait qu'en cas de restauration nécessaire

[franchet]

La seule contrainte que je connaisse sur ce sujet sont des contraintes imposées par l'OS.

Nous utilisons Solaris, et à ma connaissance, il n'y pas de limite. Pas comme Windows si mes connaissance sont a jours.

Avec la 10G tu peux créer des BIGFILE TABLESPACE (1 datafile énorme par tablespace), mais est ce que du coté OS ca pose pas de problemes ?!

J'en entends beaucoup parler de la 10G. Mais ce n'est pas encore pour le moment, car l'appli qui utilise Oracle n'est pas encore avec la 10G.

En faite je me pose toutes ces questions car aujourd'hui nous avons de gros soucis de lenteur dans nos requetes. En me prenant par la main (Car je n'ai aucune formation info, ou dba) et en fouillant, je me suis rendu compte que toutes les données utilisateurs allaient dans la table systeme et non dans la table idata. Je pense que vous serez tous d'accord avec moi, ce n'est pas une situation normale. J'ai beau vider, remplir, detruire et reremplir, rien n'y fait. C'est en fait mon dump qui mer... En faite l'histoire des données. Quand je créé une une nouvelle table c'est OK, mais pas pour les 450 tables déjà existant. Quelqu'un a du mer.. un moment donné chez nous, mais je ne vois vraiment pas comment. Donc le seul moyen que j'ai trouver aujourd'hui pour m'en sortir, c'est de faire une base (ou instance) temporaire, importer un dump, jouer un sql pour passer les tables de system a data tout en "rebuildant" des index, d'en faire un dump puis de l'importer de nouveau dans la base pour voir si tout ce passe bien.

Pour info, voici d'ailleurs le petit sql que je joue (a faire pour toute les table).

ALTER INDEX "USER"."TABLE"
REBUILD
TABLESPACE "IDATA";
ALTER INDEX "USER"."INDEX_TABLE"
REBUILD
TABLESPACE "IDATA";
ALTER TABLE "USER"."TABLE"
MOVE TABLESPACE "IDATA";
ALTER INDEX "USER"."INDEX_TABLE"
REBUILD
TABLESPACE "INDX";
ALTER INDEX "USER"."TABLE"
REBUILD
TABLESPACE "INDX";

Si l'un d'entre vous a une autre idée, je suis preneur.

En ce qui concerne les taille, je vais rester comme aujourd'hui, des datafile de 2Go autoextend, et l'orqu'elle seront au alentour des 3Go, je créerai un nouveau datafile.

il y a aussi la taille du bitmap en entete de fichier qu'il ne faut pas négliger. Personnellement, je prèfère faire plusieurs fichiers, ne serait qu'en cas de restauration nécessaire

Peux-tu m'en dire plus ou me donner un lien pour les bitmap!
Je ne voie pas du tout ce que tu veux dire par la.

Merci.

[orafrance]

en locally managed les extents sont gérés dans l'entête de fichier plutôt que le dictionnaire et en ASSM c'est les FREELIST qui sont également gérés dans le fichier. Ainsi, avec un seul fichier énorme tu déplaces la contention du dictionnaire dans l'entête de fichier et ne bénéficie ainsi pas des avantages du LMT.

D'ailleurs, Oracle a inventer le BIGFILE pour pallier à ces contentions

A proos du bitmap : http://www.freelists.org/archives/or.../msg00625.html

[franchet]

en locally managed les extents sont gérés dans l'entête de fichier plutôt que le dictionnaire et en ASSM c'est les FREELIST qui sont également gérés dans le fichier. Ainsi, avec un seul fichier énorme tu déplaces la contention du dictionnaire dans l'entête de fichier et ne bénéficie ainsi pas des avantages du LMT.

D'ailleurs, Oracle a inventer le BIGFILE pour pallier à ces contentions

Je sens que j'ai encore des terme a acquerir:
locally managed, dictionnaire pour oracle, ASSM, FREELIST, LMT.
Mais bon, j'ai un bon challenge a relever. Apprendre a me servir d'Oracle sans avoir de formation. Je sens qu'il va encore falloir que je donne de ma personne. (J'ai l'habitude et je pense que je ne suis pas le seul)
A propos, j'ai l'impression qu'il y a un probléme d'heure sur un serveur quelque part. Les messages on 1 heure de décallage.
Merci pour le lien je vais regarder ca.

[orafrance]

ASSM = Automatic Segment Space Managment = parametre SEGMENT SPACE MANAGEMENT à AUTO dans la création du tablespace

FREELIST = liste des blocks libres du tablespace c'est aussi un de ses paramètres

LMT = Locally Managed Tablespace : http://oracle.developpez.com/guide/a...e/tablespaces/

Vérifie ton profile pour le décalage de l'heure

[pifor]

FREELIST = liste des blocks libres du tablespace c'est aussi un de ses paramètres

Je crois que les free lists gèrent plutôt l'espace libre à l'intérieur d'un segment d'après le Concepts Guide ici et là.

[pifor]

En faite je me pose toutes ces questions car aujourd'hui nous avons de gros soucis de lenteur dans nos requetes. En me prenant par la main (Car je n'ai aucune formation info, ou dba) et en fouillant, je me suis rendu compte que toutes les données utilisateurs allaient dans la table systeme et non dans la table idata

Le lien entre la localisation des objets dans un tablespace donné et les performances n'est pas forcément évident même s'il n'est pas recommendé d'utiliser le tablespace SYSTEM pour stocker des données applicatives. Il faudrait analyser en détail les performances des requêtes pour en savoir plus, par exemple avec la trace SQL et TKPROF.

Pour créer les bons objets dans le bon tablespace, si vous avez accès à Metalink, consultez la note:

Subject: Moving Tables Between Tablespaces Using EXPORT/IMPORT
Doc ID: Note:1012307.6 Type: BULLETIN
Last Revision Date: 25-OCT-2005

Sinon donnez le plus de détails possible: ligne de commandes complètes des commandex exp/imp et caractéristiques des comptes utilisateurs propriétaires des objets dans les bases source et cible (tablespaces par défaut et quota sur tablespaces).

NB: un tablespace est un groupe de fichier physiques de la base (datafiles). Ce n'est pas une table: une table est stockée physiquement dans un tablespace.

[orafrance]

Je crois que les free lists gèrent plutôt l'espace libre à l'intérieur d'un segment d'après le Concepts Guide ici et là.

en effet, mais c'est paramétré au niveau du tablespace... je me suis mal exprimé

[laurentschneider]

Qu'est-il mieux de faire:
Un gros Datafile de 4 à 6 go autoextend?
Ou plusieurs Datafile de 2 à 4 Go autoextend?

6Go ce n'est vraiment pas "gros". Ce qui compte, c'est les IO, si ton fichier de 6Go est strippé sur plusieurs disques, pas de problème.

Oracle peut créer des fichiers de 32To avec des blocs 8k.

NTFS avait une limite de 16To, mais d'après l'excellent article que Nicolas Gasparotto m'a un jour recommandé, Microsoft Storage: Fact and Fiction , la limite est de plusieurs Eo avec Win2K3SP1
Comparé au système de fichier Microsoft FAT12 et ses 32Mo, c'est bien

Concernant le backup, RMAN propose le blockrecovery.

Concernant la maintenance, c'est génial avec bigfile, tu peux augmenter la taille du tablespace sans avoir à connaitre le nom du fichier

Code :

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

alter tablespace data01 resize 100G;

alors pourquoi s'en priver

la limite de 2G, qui date d'Oracle 7, n'a plus de raison d'être...