Discussion :

[CinePhil]

Bonjour,

J'ai un serveur de production où j'ai passé avec succès des patches de notre ERP Cocktail.
Et j'ai un serveur de test, qui contient plusieurs bases.

Sur la première base qui ne me sert qu'à tester les patches et qui est quasi vide de données, hors données de référence, pas de problème.

Sur la deuxième base, qui est une copie un peu ancienne de la base de production et qui a été mise à jour régulièrement, cette fois, ça coince avec ce message d'erreur :

ORA-01658: impossible de créer l'ensemble de blocs contigus INITIAL pour le segment dans le tablespace DATA_CKTL_GRH
ORA-06512: à "GRHUM.ADM_CREATE_TABLE_IFNOTEXISTS", ligne 110
ORA-06512: à ligne 18
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 cherché un peu sur Internet...

Code :

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

1
2
3
select file_name,autoextensible,increment_by,maxblocks 
from dba_data_files 
where tablespace_name = 'DATA_CKTL_GRH'

Résultat :
- FILE_NAME = /Bases/oracle/product/11.2.0/dbhome_1/dbs/MISSING00024 ;
- AUTOEXTENSIBLE = (null) ;
- INCREMENT_BY = (null) ;
- MAXBLOCS = (null).

J'ai essayé ça :

Code :

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

ALTER DATABASE DATAFILE '/Bases/oracle/product/11.2.0/dbhome_1/dbs/MISSING00024' AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED;

Mais ça plante parce que, sur le disque, il n'y a même pas de répertoire dbs sous /Bases/oracle/product/11.2.0/dbhome_1/ ; encore moins de fichier MISSING00024

Sur le serveur de prod, la requête SELECT ci-dessus donne un résultat plus cohérent :
- FILE_NAME = /Bases/Instances11g/cocktail/oradata/data_cktl_grh_01.dbf ;
- AUTOEXTENSIBLE = NO ;
- INCREMENT_BY = 0 ;
- MAXBLOCS = 0.

Le fichier /Bases/Instances11g/cktl/oradata/data_cktl_grh_01.dbf existe bien également sur le serveur de test (cktl est le nom de la base de test qui me pose problème).


Quelqu'un a t-il une explication et une solution à me donner ?

[Pomalaix]

MISSING dans le nom du fichier n'est clairement pas normal.
Je pense que qu'il y a eu un souci non détecté lors de la création de la base. Peut-être encore des infos dans le fichier d'alert s'il remonte assez loin.
Par quelle technique est-elle rafraîchie ?

Voici ce qu'en dit la doc Oracle :

"If a datafile exists in the data dictionary but not in the new control file, the database creates a placeholder entry in the control file under the name MISSINGnnnn, where nnnn is the file number in decimal. MISSINGnnnn is flagged in the control file as being offline and requiring media recovery.If the actual datafile corresponding to MISSINGnnnn is read-only or offline normal, then you can make the datafile accessible by renaming MISSINGnnnn to the name of the actual datafile. If MISSINGnnnn corresponds to a datafile that was not read-only or offline normal, then you cannot use the rename operation to make the datafile accessible, because the datafile requires media recovery that is precluded by the results of RESETLOGS. In this case, you must drop the tablespace containing the datafile.
Conversely, if a datafile listed in the control file is not present in the data dictionary, then the database removes references to it from the new control file. In both cases, the database includes an explanatory message in the alert log to let you know what was found."

Par curiosité, y a-t-il une différence entre le résultat de ces 2 requêtes ?
La première se fonde sur les tables du dictionnaire de données, la seconde sur les informations du fichier de contrôle.

Code :

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

1
2
select tablespace_name, file_name from dba_data_files order by 1;
select vts.name, vdf.name from v$datafile vdf join v$tablespace vts on vdf.ts#=vts.ts# order by 1;

Je pense que vous allez devoir recréer la base depuis la production, en vous assurant immédiatement que cela s'est bien passé :
- pas d'anomalie dans l'alert.log
- pas de fichier dont le nom comporte "MISSING"

[CinePhil]

Suite des investigations...

J'ai réussi à modifier le DATAFILE :

Code :

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

ALTER TABLESPACE DATA_CKTL_GRH RENAME DATAFILE '/Bases/oracle/product/11.2.0/dbhome_1/dbs/MISSING00024' TO '/Bases/Instances11g/cktl/oradata/data_cktl_grh_01.dbf'

Par contre, quand je veux redémarrer le tablespace avec ALTER TABLESPACE DATA_CKTL_GRH ONLINE, j'ai cette erreur :

ALTER TABLESPACE DATA_CKTL_GRH ONLINE NORMAL
Rapport d'erreur -
ORA-00933: la commande SQL ne se termine pas correctement
00933. 00000 - "SQL command not properly ended"
*Cause:
*Action:

Erreur commençant à la ligne: 1 de la commande -
ALTER TABLESPACE DATA_CKTL_GRH ONLINE
Rapport d'erreur -
ORA-01190: le fichier de contrôle ou le fichier de données 24 est antérieur au dernier RESETLOGS
ORA-01110: fichier de données 24 : '/Bases/Instances11g/cktl/oradata/data_cktl_grh_01.dbf'
01190. 00000 - "control file or data file %s is from before the last RESETLOGS"
*Cause: Attempting to use a data file when the log reset information in
the file does not match the control file. Either the data file
or the control file is a backup that was made before the most
recent ALTER DATABASE OPEN RESETLOGS.
*Action: Restore file from a more recent backup.

Et là, je coince parce que je ne sais pas depuis quand le problème est apparu. J'ai constaté qu'une autre base de test est dans le même état alors que je n'y ai pas encore passé les patches qui m'ont fait détecter le problème.

Je laisse tomber et je vais faire une copie de la base de production sur les bases de test.

Mais je suis quand même curieux de savoir ce qui a bien pu se passer !