Pour répliquer rapidement un environnement complet, nous utilisons le logiciel "ShadowImage". Cette opération permet de créer une image complet d'un serveur pour ensuite diagnostiquer des problèmes majeurs survenu sur cet environnement.
L'environnement répliqué consiste à un serveur Sun Solaris 10 sur lequel réside une base de données 10gR2 Enterprise Edition.
Pour que la cpoie répliquée de la base de données soit fonctionnelle, nous mettons celle-ci en mode "begin backup" avant de démarrer le processus de copie. Malgré cela, une fois que le processus est terminé, nous rencontrons des problèmes avec la base de données copiée. Voici les problèmes rencontrées avec leurs solutions :
Recouvrement du tablespace SYSTEM
ERROR at line 1:
ORA-01113: file 1 needs media recovery
ORA-01110: data file 1: '/uprodz2-obd001_u02/oradata/P059/system01.dbf'
Mettre la base de données en mode "mount" :
sqlplus / as sysdba
shutdown immediate
startup mount
2 scénarios possibles :
1. Recouvrement à partir d'un copie de sécurité des controlfiles
1.1 Récupérer des anciens CONTROLFILE qui furent générés par la commande :
alter database backup controlfile
to '/u01/home/dba/oracle/admin/ORCL/udump/control.2010-09-16-09:00.bkp';
prendre un copie du controlfile puis copier le backup controlfile aux 2 endroits
1.2 Recouvrer la base de données à l'aide des controlfiles récupérés
Recover database until time '2010-10-15 09:00:00' using backup controlfile;
OU
Recover database using backup controlfile until cancel;
Si nécessaire, ne pas hésiter à proposer les redofiles non archivés comme fichier d'archive afin de compléter le recouvrement
1.3 Ouvrir la base de données
alter database open resetlogs;
il est fortement conseillé de prendre une copie de sécurité de toute la base de données avant d'exécuter une ouverture de la base de données avec l'option "RESETLOGS".
2. Recouvrement à partir des controlfiles courants (actuels)
2.1 Recouvrer la base de données avec la commande suivante à partir des controlfiles actuels
Recover database until time '2010-10-15 09:00:00' using backup controlfile;
Si nécessaire, ne pas hésiter à proposer les redofiles non archivés comme fichier d'archive afin de compléter le recouvrement
2.2 Ouvrir la base de données
alter database open resetlogs;
il est fortement conseillé de prendre une copie de sécurité de toute la base de données avant d'exécuter une ouverture de la base de données avec l'option "RESETLOGS".
Corruption du tablespace UNDO
Lors du démarrage de la base de données, si celle-ci tarde beaucoup à démarrer ou que le démarrage renvoi une erreur ORA-600 avec l'argument [4194], c'est probablement occasionné par une corruption dans les segments du tablespace " undo ".
Avant de procéder tel qu'indiqué, assurez-vous que le fichier " alert_ORCL.log " contient bel et bien des lignes affichant le code d'erreur mentionné précédemment.
Compte tenu que le contenu du tablespace " undo " sert à conserver les transactions non sauvegardées (non commit), on peut détruire ces données sans danger. Voici les étapes pour recréer le tablespace " undo " :
sqlplus / as sysdba
Alter database open;
create undo tablespace undo2
datafile '/u05/oradata/ORCL/undo02.dbf' size 50 m
autoextend on;
alter system set undo_tablespace = undo2 ;
drop tablespace undo including contents and datafiles ;
create undo tablespace undo
datafile '/u05/oradata/ORCL/undo01.dbf' size 1000 m
autoextend on ;
alter system set undo_tablespace = undo ;
drop tablespace undo2 including contents and datafiles ;
Pour réaliser les commandes précédentes, il se peut que vous soyez dans l'obligation de désactiver la gestion automatique des segments " undo " :
sqlplus / as sysdba
startup mount
create pfile from spfile;
Modifier le paramètre suivant dans le fichier " initORCL.ora " :
undo_management = MANUAL
shutdown immediate
startup pfile=initORCL.ora
Une fois l'intervention terminée, n'oubliez pas de revenir en mode "spfile".
Il y a un autre cas, que l'un de mes collègues a rencontré. Il a eu à recréer les controlfiles pour ressusciter la base de données.
Aucun message portant le libellé Tablespace. Afficher tous les messages
Aucun message portant le libellé Tablespace. Afficher tous les messages
jeudi 16 septembre 2010
dimanche 1 mars 2009
Notification sur un tablespace... inexistant !
En testant la notification à propos de l'espace utilisé des tablespaces, je me suis trouvé à provoquer un dépassement de seuil pour recevoir un message électronique.
Le message concernait un tablespace qui consommait plus que 85% de l'espace alloué.
Après avoir constaté que ça fonctionnait correctement, j'ai détruit le tablespace dont le seuil a été dépassé.
À ma grande surprise, j'ai continué à recevoir des messages électroniques même si le tablespace a été complètement détruit !?!
J'ai alors décidé de recréer le tablespace pour voir comment ça allait se comporter. Après quelques minutes, je ne recevais plus de messages. Afin d'être complètement certain, j'ai attendu près de 24 heures avant de détruire à nouveau le tablespace.
Le message concernait un tablespace qui consommait plus que 85% de l'espace alloué.
Après avoir constaté que ça fonctionnait correctement, j'ai détruit le tablespace dont le seuil a été dépassé.
À ma grande surprise, j'ai continué à recevoir des messages électroniques même si le tablespace a été complètement détruit !?!
J'ai alors décidé de recréer le tablespace pour voir comment ça allait se comporter. Après quelques minutes, je ne recevais plus de messages. Afin d'être complètement certain, j'ai attendu près de 24 heures avant de détruire à nouveau le tablespace.
samedi 28 février 2009
Probleme de notification : Tablespace Space Used % sur instance RAC
Depuis quelque temps, je soupçonnais des problèmes de notification avec les instances RAC définies dans Oracle EM Grid Control.
Je me suis alors bâtit un cas d'essai. J'ai créé un tablespace contenant une seule table. Celle-ci a été remplie jusqu'au bouchon en m'aidant de la vue DBA_OBJECTS. (Insert into ... Select * from dba_objects)
La requête ci-dessous permet d'afficher les alertes que la base de données a rencontrées :
SELECT REASON
, METRIC_VALUE
, MESSAGE_TYPE
, TO_CHAR(CREATION_TIME,'DD-MON-YYYY HH24:MI:SS')
, HOST_ID
FROM SYS.DBA_OUTSTANDING_ALERTS;
J'y ai alors trouvé une alerte à propos du tablespace créé pour mon cas d'essai :
REASON
-------------------------------------------------------
METRIC_VALUE MESSAGE_TYPE TO_CHAR(CREATION_TIM HOST_ID
------------ ------------ -------------------- --------
Tablespace [TEST_OEM_EC] is [90 percent] full
90 Warning 28-FEB-2009 20:48:04 MOMSVR
Étrange! l'alerte est inscrite dans la base de données mais elle n'est pas envoyé vers Enterprise Manager ?!?
J'ai décidé de vérifier si l'agent était ble et bien enregistrer à la base de données ORCL :
select agent_name from SYSTEM.AQ$_INTERNET_AGENTS order by agent_name;
Cette requête doit retourner au minimum un enregistrement qui contient un nom d'agent dont le nom est constitué du nom de l'hôte, du port et du SID de la base de données.
Ex : MOMSRV_1830_ORCL1
Ce n'était pas mon cas... La requête m'a affiché un autre agent avec un port différent. En fait, c'était un ancien agent qui fut déjà installé auparavant.
J'ai finalement trouvé de l'information à propos d'un bug à ce sujet et Oracle recommande de faire ce qui suit et ce, même si la configuration est déjà présente dans Oracle EM Grid Control.
Dans la console EM :
1. Cliquer sur le "cluster" en question
2. Au bas de la page, cliquer sur le lien intitulé "Monitoring Configuration"
3. Parcourir les étapes de configuration même si elles ont déjà été faites
Sur chacun des noeuds :
$ emctl stop agent
$ emctl start agent
$ emctl clearstate agent
J'ai refait mon test de notification et tout à fonctionné correctement.
Pour terminer en beauté, j'ai décidé de supprimer l'ancien agent inscrit. Pour ce faire, j'ai exécuté la commande suivante :
exec dbms_aqadm.DROP_AQ_AGENT('MOMSRV_3872_ORCL1');
Je me suis alors bâtit un cas d'essai. J'ai créé un tablespace contenant une seule table. Celle-ci a été remplie jusqu'au bouchon en m'aidant de la vue DBA_OBJECTS. (Insert into ... Select * from dba_objects)
La requête ci-dessous permet d'afficher les alertes que la base de données a rencontrées :
SELECT REASON
, METRIC_VALUE
, MESSAGE_TYPE
, TO_CHAR(CREATION_TIME,'DD-MON-YYYY HH24:MI:SS')
, HOST_ID
FROM SYS.DBA_OUTSTANDING_ALERTS;
J'y ai alors trouvé une alerte à propos du tablespace créé pour mon cas d'essai :
REASON
-------------------------------------------------------
METRIC_VALUE MESSAGE_TYPE TO_CHAR(CREATION_TIM HOST_ID
------------ ------------ -------------------- --------
Tablespace [TEST_OEM_EC] is [90 percent] full
90 Warning 28-FEB-2009 20:48:04 MOMSVR
Étrange! l'alerte est inscrite dans la base de données mais elle n'est pas envoyé vers Enterprise Manager ?!?
J'ai décidé de vérifier si l'agent était ble et bien enregistrer à la base de données ORCL :
select agent_name from SYSTEM.AQ$_INTERNET_AGENTS order by agent_name;
Cette requête doit retourner au minimum un enregistrement qui contient un nom d'agent dont le nom est constitué du nom de l'hôte, du port et du SID de la base de données.
Ex : MOMSRV_1830_ORCL1
Ce n'était pas mon cas... La requête m'a affiché un autre agent avec un port différent. En fait, c'était un ancien agent qui fut déjà installé auparavant.
J'ai finalement trouvé de l'information à propos d'un bug à ce sujet et Oracle recommande de faire ce qui suit et ce, même si la configuration est déjà présente dans Oracle EM Grid Control.
Dans la console EM :
1. Cliquer sur le "cluster" en question
2. Au bas de la page, cliquer sur le lien intitulé "Monitoring Configuration"
3. Parcourir les étapes de configuration même si elles ont déjà été faites
Sur chacun des noeuds :
$ emctl stop agent
$ emctl start agent
$ emctl clearstate agent
J'ai refait mon test de notification et tout à fonctionné correctement.
Pour terminer en beauté, j'ai décidé de supprimer l'ancien agent inscrit. Pour ce faire, j'ai exécuté la commande suivante :
exec dbms_aqadm.DROP_AQ_AGENT('MOMSRV_3872_ORCL1');
vendredi 6 février 2009
Tablespace de type "bigfile"
Depuis Oracle 10g, il existe deux types de tablespace qui peuvent cohabiter dans une même base de données:
Un tablespace « bigfile » peut contenir un seul fichier de données (datafile ou tempfile) qui peut être de taille imposante. Dépendamment de la taille du bloc Oracle, le fichier de données d’un tablespace « bigfile » peut atteindre la taille de 128 téraoctets.
Les tablespaces « Bigfile » sont seulement supportés avec la gestion locale des tablespaces (locally managed) et avec ASSM (automatic segment-space management). Ces options n’ont pas à être précisées car ce sont les défauts lors de la création d’un tablespace de type « bigfile » :
CREATE BIGFILE TABLESPACE TS DATAFILE '/u01/oradata/ts01.dbf' SIZE 2T;
Lorsqu’on augmente la taille d’un fichier, il n’est pas nécessaire d’utiliser l’option « datafile », l’utilisation du nom du tablespace pour altérer la taille du fichier de données est suffisant car le tablespace « bigfile » contient seulement un fichier de données.
Avec les commandes « CREATE DATABASE » ou « ALTER DATABASE », le type de tablespace par défaut peut être changé pour « BIGFILE ».
Le tablespace Undo géré localement et le tablespace temporaire peuvent être des « bigfile », même si leurs segments sont gérés manuellement.
Les tablespaces SYSTEM et SYSAUX ne peuvent pas être créés en bigfile.
Avec les tablespaces « bigfile », il est conseillé d’utiliser ASM (automatic storage management), ou tous autres gestionnaires de volume logique qui supporte l’extension dynamique, le striping et RAID.
Avec les tablespaces « smallfile », l’administrateur de bases de données avait la latitude d’augmenter un fichier de base de données ou d’ajouter un nouveau fichier de données pour accommoder l’évolution des données des applications. Tandis qu’un tablespace « bigfile », qui ne peut pas contenir plusieurs fichiers de données, l’administrateur de base de données doit s’assurer et prévoir suffisamment d’espace pour répondre à la capacité future.
L’utilisation des tablespaces de type « bigfile » n’a rien de négatif cependant, gardez en tête que le temps de recouvrement d’un fichier de données de plusieurs téraoctets risque d’être très long.
- bigfile
- smallfile
Un tablespace « bigfile » peut contenir un seul fichier de données (datafile ou tempfile) qui peut être de taille imposante. Dépendamment de la taille du bloc Oracle, le fichier de données d’un tablespace « bigfile » peut atteindre la taille de 128 téraoctets.
Les tablespaces « Bigfile » sont seulement supportés avec la gestion locale des tablespaces (locally managed) et avec ASSM (automatic segment-space management). Ces options n’ont pas à être précisées car ce sont les défauts lors de la création d’un tablespace de type « bigfile » :
CREATE BIGFILE TABLESPACE TS DATAFILE '/u01/oradata/ts01.dbf' SIZE 2T;
Lorsqu’on augmente la taille d’un fichier, il n’est pas nécessaire d’utiliser l’option « datafile », l’utilisation du nom du tablespace pour altérer la taille du fichier de données est suffisant car le tablespace « bigfile » contient seulement un fichier de données.
Avec les commandes « CREATE DATABASE » ou « ALTER DATABASE », le type de tablespace par défaut peut être changé pour « BIGFILE ».
Le tablespace Undo géré localement et le tablespace temporaire peuvent être des « bigfile », même si leurs segments sont gérés manuellement.
Les tablespaces SYSTEM et SYSAUX ne peuvent pas être créés en bigfile.
Avec les tablespaces « bigfile », il est conseillé d’utiliser ASM (automatic storage management), ou tous autres gestionnaires de volume logique qui supporte l’extension dynamique, le striping et RAID.
Avec les tablespaces « smallfile », l’administrateur de bases de données avait la latitude d’augmenter un fichier de base de données ou d’ajouter un nouveau fichier de données pour accommoder l’évolution des données des applications. Tandis qu’un tablespace « bigfile », qui ne peut pas contenir plusieurs fichiers de données, l’administrateur de base de données doit s’assurer et prévoir suffisamment d’espace pour répondre à la capacité future.
L’utilisation des tablespaces de type « bigfile » n’a rien de négatif cependant, gardez en tête que le temps de recouvrement d’un fichier de données de plusieurs téraoctets risque d’être très long.
S'abonner à :
Messages (Atom)