Version imprimable
Bonjour,
Si le message :apparait, alors que le tablespace mentionne autoextend on .Citation:
unable to create INITIAL extent for segment in tablespace
Est-ce que cela signifie que c'est le 1er extent qui n'arrive pas à être crée, ou l'ensemble du segment.
Dans les 2 cas cela signifie que l'espace libre du FileSystem qui abrite le .dbf, est insuffisant (autoextend on )
Merci de vos réponses
Bonjour,
un datafile de ton tablespace est en autoextension, soit, mais quelle est la taille max ?
A moins avis elle est trop petite (ou atteinte).
Oracle n'a pas trouvé d'espace contigü pour stocker l'initial de ton segment (la première extension).
Soit tu agrandis un des datafiles
Soit tu ajoutes un datafile
Soit tu réduis l'initial.
01658, 00000, "unable to create INITIAL extent for segment in tablespace %s"
// *Cause: Failed to find sufficient contiguous space to allocate INITIAL
// extent for segment being created.
// *Action: Use ALTER TABLESPACE ADD DATAFILE to add additional space to the
// tablespace or retry with a smaller value for INITIAL
j'ai oublié de préciser que la creation du tablespace notifié :
Merci de ton aideCode:
2
Bonjour,
si ce n'est pas un big tablespace la taille de ton datafile est limité à 32Go.
C'est très approximatif de présenter les choses comme ça !Citation:
Envoyé par Z3phur
Plus précisément, la taille maximale d'un fichier dépend de la taille de bloc de son tablespace. (Voir ici par exemple : http://www.developpez.net/forums/d86...nt-tablespace/)
Merci Pomalaix pour la précision car je parlais effectivement des cas de block à 8K, comme dans la plupart des cas.
Par contre je ne vois pas pourquoi tu dis dans le poste que ce n'est pas bien d'avoir trop de datafile? (des centaines par exemple)
Pour moi c'est plus facile de gérer des centaines de datafile de 5 Go que moins de 32 Go ou plus.
On est un peu hors sujet par rapport à la question initiale, mais en bref :Citation:
Envoyé par Z3phur
Le nombre de fichiers influe sur les performances des points de synchronisation (checkpoints). A cette occasion, l'en-tête de tous les fichiers doit être mis à jour, même s'il n'y a aucune modification de données à écrire.
A l'usage on constate qu'avec des centaines de fichiers, cette opération peut prendre des dizaines de secondes, contre moins d'une seconde sur une base constituée d'une dizaine de fichiers.
En temps normal, cet effet devrait être minime, car les points de synchronisation sur une base bien réglée sont censés n'avoir lieu que 3 ou 4 fois par heure. Mais en cas de modifications massives qui font tourner les journaux à un rythme très élevé, l'impact sur les performances des points de synchronisation peut devenir significatif.