PostgreSQL et Oracle ont des architectures qui se ressemblent. Tous les deux offrent des fonctionnalités similaires tel que le partitionnement, les vues matérialisées, le parallélisme, des mécanismes de réplications qui se nomment "Data Guard" chez Oracle et "Streaming Replication" et "Hot Standby" du côté de ProgreSQL. À noter qu'il n'y a pas d'équivalent d'Oracle RAC dans le monde de PostgreSQL.
Pour les sauvegardes et le recouvrement, il existe un outil de sauvegarde et de récupération qui se nomme "Barman". N'ayez crainte, ça n'a rien à voir avec les établissements où l'on consomme de l'alcool, Barman est plutôt l'acronyme pour "Backup And Recovery MANager".
Pour en connaitre davantage : https://lnkd.in/dKmWeH3
Aucun message portant le libellé RMAN. Afficher tous les messages
Aucun message portant le libellé RMAN. Afficher tous les messages
mercredi 21 mars 2018
jeudi 18 novembre 2010
À ne pas mettre avant la commande "BACKUP"
En voulant prendre une copie de la commande de création du "Controlfile" de la base de données dans un script RMAN, je me suis aperçu que la série de commandes n'était pas générée dans le fichier de trace.
Après quelques essais, je me suis rendu compte que si la commande "BACKUP..." suit directement la commande "ALTER DATABASE BACKUP CONTROLFILE...", le fichier de trace se créer sans contenir les commandes SQL.
Donc. j'ai tout simplement déplacé la commande SQL à la toute fin :
run
{
BACKUP DATABASE FILESPERSET 1 PLUS ARCHIVELOG;
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
SQL "ALTER DATABASE BACKUP CONTROLFILE TO TRACE";
}
Ceci a été observé en effectuant une sauvegarde d'une base de données Oracle 10G Express Edition (XE) sous Linux RHEL4 sans catalogue RMAN.
Après quelques essais, je me suis rendu compte que si la commande "BACKUP..." suit directement la commande "ALTER DATABASE BACKUP CONTROLFILE...", le fichier de trace se créer sans contenir les commandes SQL.
Donc. j'ai tout simplement déplacé la commande SQL à la toute fin :
run
{
BACKUP DATABASE FILESPERSET 1 PLUS ARCHIVELOG;
CROSSCHECK BACKUP;
CROSSCHECK ARCHIVELOG ALL;
DELETE NOPROMPT OBSOLETE;
DELETE NOPROMPT EXPIRED BACKUP;
DELETE NOPROMPT EXPIRED ARCHIVELOG ALL;
SQL "ALTER DATABASE BACKUP CONTROLFILE TO TRACE";
}
Ceci a été observé en effectuant une sauvegarde d'une base de données Oracle 10G Express Edition (XE) sous Linux RHEL4 sans catalogue RMAN.
mercredi 22 septembre 2010
OOW 2010 - Jour 3
Trop souvent les entreprises négligent complètement la prise de copie de sécurité et, ceux qui en prennent, négligent les essais de recouvrement. Pourquoi les gens aiment tant jouer avec le risque ? Personnellement, ça me renverse! Jamais je ne pourrais avoir la conscience tranquille tant et aussi longtemps que je n'aurais pas effectué des copies de sécurité et réaliser des scénarios de recouvrement. Ceci devrait être la ou l'une des premières règles qu'un DBA devrait suivre. D'autant plus, pouvez-vous bien me dire pourquoi qu'il y a tant d'entreprises qui n'utilisent pas RMAN ? Cet utilitaire a fait ses preuves depuis plusieurs années et aucun autre utilitaire ne peut être aussi fiable que lui.Je vous parle de sauvegarde et de recouvrement car aujourd'hui, j'ai eu l'opportunité d'assister à des conférences au sujet de " Recovery Manager ". Le premier conférencier nous à présenter une multitude de scénarios de recouvrement. Certains dont je classifierais de classique et d'autres plutôt tordus qui ne sont pas supporté par Oracle. Ces derniers sont plutôt pratiques quand nous n'avons vraiment pas le choix et qu'il faut ressusciter une base de données. Voici ce qui peut être utile pour effectuer un recouvrement incomplet et forcer l'ouverture de la base de données :
- _ALLOW_RESETLOGS_CORRUPTION=TRUE
- _CORRUPTED_ROLLBACK_SEGMENTS=(RBS1,RBS2,..)
- UNDO_MANAGEMENT=MANUAL
- EVENT = "10015 TRACE NAME ADJUST_SCN LEVEL 1"
Quand il n'y a vraiment plus de possibilité alors vous pouvez vous en remettre au support d'Oracle puis utiliser " Data Unloader (DUL) ". Cet utilitaire permet de lire les données directement dans les fichiers de données sans passer par le noyau d'Oracle.
Autres points d'intérêt abordés lors des conférences :
- Il est possible de recréer un fichier de paramètre (pfile) à partir de la mémoire. Il suffit d'exécuter la commande " CREATE PFILE " et spécifier à la toute fin " FROM MEMORY ".
- DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER() retourne le SCN en cours de la base de données.
- Il est possible de restaurer un fichier de données lors de la perte de celui-ci et que vous n'avez pas de sauvegarde de ce fichier. Si le fichier de données est inscrit dans le fichier de contrôle, la commande RESTORE créée le fichier de données dans l'emplacement d'origine et la commande RECOVER applique les journaux nécessaires pour le fichier de données.
- Si vous soupçonnez une corruption de blocs de données, DBVERIFY est un utilitaire qui effectue une vérification de l'intégrité de la structure des données physiques sur une base de données.
- La commande BLOCKRECOVER peut restaurer et récupérer des blocs individuels au sein d'un fichier de données. Cette procédure est utile quand seulement un petit nombre de blocs sont corrompus.
- Le package DBMS_BACKUP_RESTORE est utilisé comme une interface PL/SQL en ligne de commande pour le remplacement des commandes natives RMAN.
Oracle ORION
Oracle ORION est un outil pour vérifier les performances de type I/O pour les systèmes de stockage qui sont destinés à être utilisés pour les bases de données Oracle. Les résultats obtenus sont utiles pour comprendre les capacités de performance d'un système de stockage, soit pour découvrir les causes qui pourraient influer sur le rendement d'une base de données Oracle. ORION est un outil autonome, on n'a pas à créer et d'exécuter une base de données Oracle pour l'utiliser.
Pour le plaisirs, je vous invite à regarder les vidéos suivants sur youtube.com :
- Iron Man: Man. Machine. Hero. Oracle. Software. Hardware. Complete. (http://www.youtube.com/watch?v=L5cO2R-b39M)
- Exadata Iron Man display at Oracle Open World 2010 (http://www.youtube.com/watch?v=nzZs2SlJuGA)
- As we waited to enter Hall D for the Welcome Keynotes we were entertained by a display of the Iron Man / Oracle teaser trailers plus the actual suits from the movie. (http://www.youtube.com/watch?v=pBW5napyM80)
- Highlights from Oracle CEO Larry Ellison's welcome keynote at Oracle OpenWorld 2010 on Sunday September 19 (http://www.youtube.com/watch?v=tWB0fR-buJ4)
- OpenWorld's 2010 Welcome Keynote ended with Larry's announcement. Leaving Hall D (http://www.youtube.com/watch?v=mYEmjp3Bpdc)
jeudi 25 février 2010
Statut de la capture « INITIALIZING » ou « DICTIONNARY INITIALIZING »
En effectuant la commande suivante pour vérifier le processus de capture :
select * from v$streams_capture;
Si le statut (STATE) indique "INITIALIZING" ou "DICTIONARY INITIALIZATION", assurez-vous que tout les fichiers d'archive nécessaire au fonctionnement de Stream sont présent. Pour ce faire, exécuter le script "Health Check" (Streams Configuration Report and Health Check Script [ID 273674.1]) .
Suite à l'exécution du script, chercher la section intitulé "++ Minimum Archive Log Necessary to Restart Capture ++". Cette section vous indiquera quel fichier d'archive vous devez avoir sur disque pour que la capture puisse reprendre.
Voici un extrait du résultat du script "Health Check" :
==========================================================================
++ Minimum Archive Log Necessary to Restart Capture ++
Note: This query is valid for databases where the capture processes exist for the same source database.
Capture will restart from SCN 17548223670 in the following file:
/uhm004_u04/home/dba/oracle/admin/R002/arch/R002_723971581073678.arc (04:53:41 02/15/10)
PL/SQL procedure successfully completed.
==========================================================================
Si vous remarquez qu'il vous manque des fichiers d'archive, vous devrez procéder à une restauration des fichiers d'archive via Recovery Manager.
Voici comment procéder :
rman target sys/xxxx@BD_CIBLE catalog rman/xxxx@BD_CATALOG
RMAN> run {
allocate channel ch01 type 'SBT_TAPE';
restore archivelog sequence between 72390 and 72414;
}
Dans le cas présent, la restauration s'est effectué en précisant des numéros de séquences mais plusieurs autres types de restauration sont possibles tels que par date, par # scn, etc...
Suite à la restauration des fichiers d'archive, le processus de capture reprendra graduellement. Vérifier à quelques reprises le statut du processus de capture, il changera de valeurs, puis il restera dans l'état "CAPTURING CHANGES".
select * from v$streams_capture;
Assurez-vous qu'il n'y a pas d'erreur sur l'ensemble des processus impliqué dans la réplication Oracle Streams :
SELECT CAPTURE_NAME, STATUS, ERROR_MESSAGE, ERROR_NUMBER
FROM DBA_CAPTURE;
SELECT PROPAGATION_NAME, STATUS, ERROR_MESSAGE, ERROR_DATE
FROM DBA_PROPAGATION;
SELECT APPLY_NAME, STATUS, ERROR_MESSAGE, ERROR_NUMBER
FROM DBA_APPLY;
SELECT APPLY_NAME, SOURCE_DATABASE, LOCAL_TRANSACTION_ID,
ERROR_NUMBER, ERROR_MESSAGE, MESSAGE_COUNT
FROM DBA_APPLY_ERROR;
select * from v$streams_capture;
Si le statut (STATE) indique "INITIALIZING" ou "DICTIONARY INITIALIZATION", assurez-vous que tout les fichiers d'archive nécessaire au fonctionnement de Stream sont présent. Pour ce faire, exécuter le script "Health Check" (Streams Configuration Report and Health Check Script [ID 273674.1]) .
Suite à l'exécution du script, chercher la section intitulé "++ Minimum Archive Log Necessary to Restart Capture ++". Cette section vous indiquera quel fichier d'archive vous devez avoir sur disque pour que la capture puisse reprendre.
Voici un extrait du résultat du script "Health Check" :
==========================================================================
++ Minimum Archive Log Necessary to Restart Capture ++
Note: This query is valid for databases where the capture processes exist for the same source database.
Capture will restart from SCN 17548223670 in the following file:
/uhm004_u04/home/dba/oracle/admin/R002/arch/R002_723971581073678.arc (04:53:41 02/15/10)
PL/SQL procedure successfully completed.
==========================================================================
Si vous remarquez qu'il vous manque des fichiers d'archive, vous devrez procéder à une restauration des fichiers d'archive via Recovery Manager.
Voici comment procéder :
rman target sys/xxxx@BD_CIBLE catalog rman/xxxx@BD_CATALOG
RMAN> run {
allocate channel ch01 type 'SBT_TAPE';
restore archivelog sequence between 72390 and 72414;
}
Dans le cas présent, la restauration s'est effectué en précisant des numéros de séquences mais plusieurs autres types de restauration sont possibles tels que par date, par # scn, etc...
Suite à la restauration des fichiers d'archive, le processus de capture reprendra graduellement. Vérifier à quelques reprises le statut du processus de capture, il changera de valeurs, puis il restera dans l'état "CAPTURING CHANGES".
select * from v$streams_capture;
Assurez-vous qu'il n'y a pas d'erreur sur l'ensemble des processus impliqué dans la réplication Oracle Streams :
SELECT CAPTURE_NAME, STATUS, ERROR_MESSAGE, ERROR_NUMBER
FROM DBA_CAPTURE;
SELECT PROPAGATION_NAME, STATUS, ERROR_MESSAGE, ERROR_DATE
FROM DBA_PROPAGATION;
SELECT APPLY_NAME, STATUS, ERROR_MESSAGE, ERROR_NUMBER
FROM DBA_APPLY;
SELECT APPLY_NAME, SOURCE_DATABASE, LOCAL_TRANSACTION_ID,
ERROR_NUMBER, ERROR_MESSAGE, MESSAGE_COUNT
FROM DBA_APPLY_ERROR;
mardi 24 mars 2009
RMAN ne veut rien savoir, "Incarnation is not current"
Hier après-midi, je m’apprêtais à faire des essais de sauvegarde/récupération sur un serveur Unix.
Après avoir enregistré les bases de données MIG10203 et MIG10204 au catalogue RMAN, j’ai eu un problème lors d’une tentative de sauvegarde.
J’obtenais l’erreur suivante :
RMAN-20011: target database incarnation is not current in recovery catalog
Après quelques recherches, je me suis rendu compte que l’identifiant unique de la base de données (DBID) était le même pour les 2 bases de données.
C’est normal car la base de données MIG10204 a été créée en dupliquant manuellement la base de données MIG10203.
Donc, pour corriger le tout, j’ai désinscrit les 2 bases de données :
RMAN> unregister database;
Puis, j’ai suivi les étapes ci-dessous pour changer le DBID d’une des bases de données :
1. Prendre une copie de sécurité de la base de données
2. Fermer la base de données
shutdown immediate
3. Démarrer en mode « mount »
startup mount
4. démarrer une session Unix et exécuter "NID" avec les privilèges SYSDBA
$ nid TARGET=SYS/password@MIG10204
5. Fermer la base de données
shutdown immediate
6. si non fait, initialiser le paramètre "db_name" au nom désiré
7. créer un fichier de mot de passe
orapwd file=/juliet_u01/home/dba/oracle/product/10.2.0.4.0/dbs/orapwmig10204 password= entries=20
8. Démarrer et ouvrir la base de données en réinitialisant les journaux
startup mount
alter database open resetlogs
Après avoir enregistré les bases de données MIG10203 et MIG10204 au catalogue RMAN, j’ai eu un problème lors d’une tentative de sauvegarde.
J’obtenais l’erreur suivante :
RMAN-20011: target database incarnation is not current in recovery catalog
Après quelques recherches, je me suis rendu compte que l’identifiant unique de la base de données (DBID) était le même pour les 2 bases de données.
C’est normal car la base de données MIG10204 a été créée en dupliquant manuellement la base de données MIG10203.
Donc, pour corriger le tout, j’ai désinscrit les 2 bases de données :
RMAN> unregister database;
Puis, j’ai suivi les étapes ci-dessous pour changer le DBID d’une des bases de données :
1. Prendre une copie de sécurité de la base de données
2. Fermer la base de données
shutdown immediate
3. Démarrer en mode « mount »
startup mount
4. démarrer une session Unix et exécuter "NID" avec les privilèges SYSDBA
$ nid TARGET=SYS/password@MIG10204
5. Fermer la base de données
shutdown immediate
6. si non fait, initialiser le paramètre "db_name" au nom désiré
7. créer un fichier de mot de passe
orapwd file=/juliet_u01/home/dba/oracle/product/10.2.0.4.0/dbs/orapwmig10204 password=
8. Démarrer et ouvrir la base de données en réinitialisant les journaux
startup mount
alter database open resetlogs
S'abonner à :
Messages (Atom)