Drop database avec RMAN

Il y a quelques jours on m'avait demandé de supprimer une bd Oracle et j'ai bien profité pour créer un petit document que pourrait être utile à tous.

echo $ORACLE_SID
MYDB

srvctl remove database -d MYDB


rman target / catalog  user/apssword@BDCATALOG   ou rman target /
Recovery Manager: Release 12.1.0.2.0 - Production on Thu Aug 9 14:46:36 2018
Copyright (c) 1982, 2014, Oracle and/or its affiliates.  All rights reserved.
connected to target database: MYDB (DBID=2774697611)
connected to recovery catalog database


RMAN> REPORT SCHEMA ;
Report of database schema for database with db_unique_name MMYDB

List of Permanent Datafiles
===========================
File Size(MB) Tablespace           RB segs Datafile Name
---- -------- -------------------- ------- ------------------------
1    1530     SYSTEM               YES     +DATINXRWMYDB/MMYDB/datafile/system.265.870780837
2    1490     SYSAUX               NO      +DATINXRWMYDB/MMYDB/datafile/sysaux.266.870780837
3    695      UNDOTBS1             YES     +DATINXRWMYDB/MMYDB/datafile/undotbs1.261.870780837
4    5        USERS                NO      +DATINXRWMYDB/MMYDB/datafile/users.259.870780839
5    5        TBS_RO_TEST01        NO      +DATINXROMYDB/MMYDB/datafile/tbs_ro_test01.265.870780839
6    10       TBS_PDF_01           NO      +DATINXROMYDB/MMYDB/datafile/tbs_pdf_01.dbf
7    200      GGS_DATA             NO      +DATINXRWMYDB/MMYDB/datafile/ggs_data.267.870780837

List of Temporary Files
=======================
File Size(MB) Tablespace           Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- --------------------
1    100      TEMP                 100         +TEMPMYDB/MMYDB/tempfile/temp.256.870780879
2    500      TEMP_NEW             32767       +TEMPMYDB/MMYDB/TEMPFILE/temp_new.257.881479571


RMAN> SHUTDOWN IMMEDIATE ;
database closed
database dismounted
Oracle instance shut down

RMAN> STARTUP MOUNT ;
connected to target database (not started)
Oracle instance started
database mounted

Total System Global Area    5368709120 bytes

Fixed Size                     5284640 bytes
Variable Size               1895832800 bytes
Database Buffers            3456106496 bytes
Redo Buffers                  11485184 bytes


RMAN> SQL 'ALTER SYSTEM ENABLE RESTRICTED SESSION';

sql statement: ALTER SYSTEM ENABLE RESTRICTED SESSION

Si on veut tout supprimer et ne pas laisser de traces des sauvegardes prises pour cette base de données on doit ajouter le INCLUDING BACKUPS.

RMAN> DROP DATABASE INCLUDING BACKUPS;

database name is "MYDB" and DBID is 2774697611

Do you really want to drop all backups and the database (enter YES or NO)? YES

allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=69 device type=DISK

List of Backup Pieces
BP Key  BS Key  Pc# Cp# Status      Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
1371427 1371426 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/01pue54s_1_1
1371445 1371439 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/02pue54v_1_1
1371446 1371440 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/03pue55o_1_1
1371464 1371461 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/04pue55s_1_1
1371474 1371472 1   1   AVAILABLE   DISK        /bkpdskrman/MYDB/05pue55v_1_1
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/01pue54s_1_1 RECID=1 STAMP=870782108
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/02pue54v_1_1 RECID=2 STAMP=870782111
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/03pue55o_1_1 RECID=3 STAMP=870782137
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/04pue55s_1_1 RECID=4 STAMP=870782140
deleted backup piece
backup piece handle=/bkpdskrman/MYDB/05pue55v_1_1 RECID=5 STAMP=870782144
Deleted 5 objects


released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=69 device type=DISK
specification does not match any datafile copy in the repository
specification does not match any control file copy in the repository
specification does not match any control file copy in the repository
List of Archived Log Copies for database with db_unique_name MMYDB
=====================================================================

Key     Thrd Seq     S Low Time
------- ---- ------- - ---------
1371361 1    1       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_1.312.870781535

1371362 1    2       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_2.311.870781733

1371416 1    3       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_3.310.870782095

1371421 1    4       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_4.309.870782107

1371559 1    5       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.321.870793853

1371438 1    5       A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.308.870782139

1371602 1    67      A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_67.320.870793939

1371603 1    68      A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_68.319.870793941

1371604 1    69      A 04-FEB-15
Name: +ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_69.318.870793941

deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_1.312.870781535 RECID=1 STAMP=870781535
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_2.311.870781733 RECID=2 STAMP=870781733
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_3.310.870782095 RECID=3 STAMP=870782094
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_4.309.870782107 RECID=4 STAMP=870782106
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.321.870793853 RECID=9 STAMP=870793852
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_5.308.870782139 RECID=5 STAMP=870782139
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_67.320.870793939 RECID=9 STAMP=870793940
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_68.319.870793941 RECID=10 STAMP=870793940
deleted archived log
archived log file name=+ARCHMYDB/MMYDB/archivelog/2015_02_04/thread_1_seq_69.318.870793941 RECID=11 STAMP=870793941
Deleted 9 objects


database name is "MYDB" and DBID is 2774697611
database dropped

database name is "MYDB" and DBID is 2774697611
database unregistered from the recovery catalog

Bien sûr, il reste à faire le ménage dans les fichiers *.ora et selon le cas les policies de backup qu'auraient pu être reliés à cette base de données.

ORA-19511 - ORA-19502 RMAN Backup - Block change tracking

L'autre jour, un de mes clients m'a dit qu'il avait de backups qui ne se terminaient pas depuis deux jours, au moment de regarder je lui ai demandé si des modifications avaient été apportées avant ça. la seule chose qui était planifié c'est l'installation du dernier PSU de base de données :


En regardant le message d'erreur de son backup j'ai vu ces messages :


channel c2: starting piece 1 at 23-MAI  -2017 17:42:20
channel c3: finished piece 1 at 23-MAI  -2017 17:43:15
piece handle=/MYBD/INCR_LVL_1_MYBD_26518_1_944750196 tag=QUOTIDIEN_INCR_1_MMYBD comment=API Version 2.0,MMS Version 5.0.0.0
channel c3: backup set complete, elapsed time: 03:06:37
channel c4: finished piece 1 at 23-MAI  -2017 17:43:45
piece handle=/MYBD/INCR_LVL_1_MYBD_26519_1_944750198 tag=QUOTIDIEN_INCR_1_MMYBD comment=API Version 2.0,MMS Version 5.0.0.0
channel c4: backup set complete, elapsed time: 03:07:06
RMAN-03009: failure of backup command on c1 channel at 05/23/2017 19:39:02
ORA-27192: skgfcls : sbtclose2 a renvoy<E9> une erreur - la fermeture du fichier a <E9>chou<E9>
ORA-19511: Erreur re<E7>ue de la couche de gestionnaire de supports, texte du message d'erreur :
   Failed to process backup file </MYBD/INCR_LVL_1_MYBD_26516_1_944750196>
ORA-19502: erreur d'<E9>criture sur fichier "/MYBD/INCR_LVL_1_MYBD_26516_1_944750196", num<E9>ro de bloc 1153 (taille de bloc=16384)
ORA-27030: skgfwrt : sbtwrite2 a renvoy<E9> une erreur
channel c1 disabled, job failed on it will be run on another channel
channel c3: starting incremental level 1 datafile backup set
channel c3: specifying datafile(s) in backup set

En feuillant dans l'alertlog de la bd j'ai reculé au jour de l'installation du PSU 

Mon May 22 11:04:55 2017

RVWR I/O error (d06cc200, 59374, 131072, 1)

Errors in file /u01/app/moncompte/diag/rdbms/mmybd/MYBD/trace/MYBD_rvwr_5686.trc:

ORA-38701: Flashback database log 30 seq 14380 thread 1: "+FLASMYBD/mmybd/flashback/log_30.817.941939635"

ORA-15078: ASM diskgroup was forcibly dismounted

*************************************

RVWR encountered an error when writing flashback database logs.

See error stack in alert log.  To avoid crashing the instance,

this instance has turned off flashback database.

*************************************

Mon May 22 11:05:05 2017

Completed checkpoint up to RBA [0x4d39a.2.10], SCN: 9791752278402

Mon May 22 11:05:07 2017

CHANGE TRACKING ERROR 19754, disabling change tracking

Errors in file /u01/app/moncompte/diag/rdbms/mmybd/MYBD/trace/MYBD_ctwr_5723.trc:

ORA-19754: error reading from change tracking file

ORA-19750: change tracking file: '+FLASMYBD/mmybd/bct_11feb2015.dbf'

ORA-15078: ASM diskgroup was forcibly dismounted

Block change tracking service stopping.

WARNING: Cannot delete file +FLASMYBD/mmybd/bct_ABCXYZ.dbf

Dans ce cas on voit que l'arrêt de la bd ne s'est pas fait comme d'habitude.

-Hors du message du flashback qui est aussi un autre problème-

La partie du problème de cette publication était claire : 

SELECT * FROM V$BLOCK_CHANGE_TRACKING;

   STATUS     FILENAME               BYTES

   ---------- ----------------------------

   DISABLED

On a mis sur place une autre fois le BCT, on a demandé à notre équipe de netbackup de nous accorder un timeout (  https://www.veritas.com/support/en_US/article.000020638 ) plus long temporairement et par la suite, un full backup a été lancé. 

Suite à ça le temps des backups est redevenu à la normale.

RMAN Duplicate et Netbackup - ORA-19511 - ORA-19507

Des fois RMAN a besoin de certains variables pour mieux intéragir avec Netbackup et pouvoir réussir à trouver des fichiers d'une sauvegarde

Une tentative de duplicate de base de données avec une configuration des channels de cette manière déclenchait des erreurs auprès de Netbackup

run

{

allocate auxiliary channel c1 device type SBT_TAPE ;

send 'NB_ORA_POLICY=XXXXX;NB_ORA_CLIENT=YYYY';

...

duplicate target database to .... ;

...

release channel c1;

}

Voici l'erreur affichée :

Starting restore at 12-MAY-17

channel c1: starting datafile backup set restore
channel c1: restoring control file
channel c1: reading from backup piece /SOURCE/Ctl_SOURCE_sls3fnov
channel c1: ORA-19870: error while restoring backup piece /SOURCE/Ctl_SOURCE_sls3fnov
ORA-19507: failed to retrieve sequential file, handle="/SOURCE/Ctl_SOURCE_sls3fnov", parms=""
ORA-27029: skgfrtrv: sbtrestore returned error
ORA-19511: Error received from media manager layer, error text:
   Backup file </SOURCE/Ctl_SOURCE_sls3fnov> not found in NetBackup catalog

Une fois confirmé que la configuration sur place de Netbackup était la bonne on a commencé à regarder si c'était possible d'assurer que les variables étaient vraiment prises en compte par Rman et envoyées à Netbackup on a décidé de changer l'allocate pour forcer les variables d'environnement de cette façon :

run

{

allocate auxiliary channel ch01 device type 'SBT_TAPE' parms="ENV=(NB_ORA_POLICY=XXXXX,NB_ORA_CLIENT=YYYY)";

...

duplicate target database to .... ;

...

release channel c1;

}

Avec cette configuration le restore des fchiers se fait sans problème.

Backup size/media ? - RMAN 10g - 11g - 12c

Bonjour

    Je vous laisse ici un petit script qui pourrait s'avérer utile pour déterminer la taille de vos sauvegardes.
Bien sûr si vous passez par RMAN avec un LIST BACKUP vous pouvez l'avoir pour chaque BackupSet mais il va falloir commencer à faire les calculs.

En bref, je me suis créé ce script pour une demande d'inventaire des tailles des sauvegardes que j'avais reçue. 
Pour ce faire, je devais aller valider tous les derniers FULL backup de la dernière semaine de chaque bd chez un client. 

Ce script peut vous sauver pas mal de temps lorsque un Catalog RMAN est utilisé. Je dois publier d'ici peu la version du script sans catalogue.


Je l'ai testé avec plus de 70 bases de données et le résultat semble correct lorsqu'il est comparé avec les tailles montrés par le LIST BACKUP. Cependant, rien ne vous empêche de refaire vos tests :)


J'espère que cela sera vraiment utile pour vous.


SET LINESIZE 450
SET PAGESIZE 1000
COL BACKUP_TYPE             FORMAT A20
COL STATUS                  FORMAT A5
COL SESSION_RECIDSTAMP      FORMAT A20
COL START_TIME              FORMAT A18
COL COMPRESSED              FORMAT A6  HEAD "Compre"
COL CONTROLFILE_INCLUDED    FORMAT A10 HEAD "Inc |Ctrlf"
COL INCREMENTAL_LEVEL       FORMAT 99  HEAD "Inc |Level"
COL OUTPUT_MBYTES           FORMAT 999,999,999,999.99
COL OUTPUT_GBYTES           FORMAT 999,999,999.99
COL MEDIA                   FORMAT A10
BREAK ON SESSION_RECIDSTAMP SKIP 1
COMPUTE SUM LABEL TOTAL OF OUTPUT_MBYTES OUTPUT_GBYTES ON SESSION_RECIDSTAMP
ACCEPT BD PROMPT 'DatabaseName: '

 SELECT TO_CHAR(C.SESSION_RECID)||'-'||TO_CHAR(C.SESSION_STAMP) SESSION_RECIDSTAMP,
        A.DB_KEY,
        A.NAME,
        TO_CHAR(B.START_TIME,'YYYY/MM/DD HH24:MI') START_TIME,
        C.BS_KEY,
        DECODE(B.BACKUP_TYPE,'D','FULL OR LEVEL_0','I','INCREMENTAL','L','ARCHIVES' ) BACKUP_TYPE,
        C.CONTROLFILE_INCLUDED,
        B.INCREMENTAL_LEVEL, B.STATUS, B.BLOCK_SIZE, C.COMPRESSED,
        ROUND(C.OUTPUT_BYTES/1024/1024,2)         OUTPUT_MBYTES,
        ROUND(C.OUTPUT_BYTES/1024/1024/1024,2)     OUTPUT_GBYTES,
        D.MEDIA
   FROM RC_DATABASE A, RC_BACKUP_SET B, RC_BACKUP_SET_DETAILS C, RC_BACKUP_PIECE D
  WHERE A.NAME             = '&BD'        AND
        A.DB_KEY         = B.DB_KEY       AND
        A.DBID           = B.DB_ID        AND
        B.BACKUP_TYPE   IN ('D','I')      AND  
        B.DB_KEY         = C.DB_KEY       AND
        B.INPUT_FILE_SCAN_ONLY = 'NO'     AND
        B.BS_KEY         = C.BS_KEY       AND
        A.DB_KEY        = D.DB_KEY        AND
        B.BS_KEY        = D.BS_KEY
        AND B.START_TIME >= SYSDATE - 7
UNION ALL       
SELECT  TO_CHAR(C.SESSION_RECID)||'-'||TO_CHAR(C.SESSION_STAMP) SESSION_RECIDSTAMP,
        A.DB_KEY, A.NAME,
        TO_CHAR(B.START_TIME,'YYYY/MM/DD HH24:MI') START_TIME,
        B.BS_KEY,
        DECODE(B.BACKUP_TYPE,'D','FULL OR LEVEL_0','I','INCREMENTAL','L','ARCHIVES' ) BACKUP_TYPE,
        '' CONTROLFILE_INCLUDED,
        B.INCREMENTAL_LEVEL, B.STATUS, B.BLOCK_SIZE, '-' COMPRESSED,
        ROUND(C.MBYTES,2) OUTPUT_MBYTES,
        ROUND(C.GBYTES,2) OUTPUT_GBYTES,
        D.MEDIA
   FROM RC_DATABASE A, RC_BACKUP_SET B,
        (SELECT AA.DB_KEY, AA.SESSION_RECID, AA.SESSION_STAMP, AA.BTYPE_KEY BS_KEY, SUM(AA.FILESIZE)/1024/1024 MBYTES, SUM(AA.FILESIZE)/1024/1024/1024 GBYTES
           FROM RC_BACKUP_ARCHIVELOG_DETAILS AA
          WHERE AA.DB_NAME = '&BD'    
        GROUP BY AA.DB_KEY, AA.SESSION_RECID, AA.SESSION_STAMP, AA.BTYPE_KEY
        ) C, RC_BACKUP_PIECE D
  WHERE A.NAME           = '&BD'         AND
        A.DB_KEY         = B.DB_KEY      AND
        A.DBID           = B.DB_ID       AND
        B.BACKUP_TYPE   = 'L'            AND  
        B.DB_KEY         = C.DB_KEY      AND
        B.INPUT_FILE_SCAN_ONLY = 'NO'    AND
        B.BS_KEY         = C.BS_KEY      AND
        A.DB_KEY        = D.DB_KEY       AND
        B.BS_KEY        = D.BS_KEY
        AND B.START_TIME >= SYSDATE - 7
ORDER BY 4, 5 ;


Voici un exemple du résultat, bien sûr j'ai supprimé les données de deux colonnes par sécurité.

NB : 
Avec les catalogues 11g le temps de réponse est bon (moins de 3 sec), pour ceux qui ont toujours une bd 10g, cela c'est plus long (beaucoup plus long, entre 40 et 90 sec.)
Je n'ai pas eu de temps de vérifier la raison de cette différence.

ORA-17628: Oracle error 19505

Si jamais vous avez ce message d'erreur lors d'un duplicate de base de données avec RMAN 

Ci-dessous j'ai reproduit le problème avec une petite base de données d'essai.


$ rman target sys@test_p auxiliary sys@test_s


Recovery Manager: Release 11.2.0.1.0 - Production on Thu Apr 23 21:36:37 2015
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

target database Password:
connected to target database: TEST (DBID=2174328171)
auxiliary database Password:

connected to auxiliary database: TEST (not mounted)

RMAN> DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE ;

...

...

...

Starting backup at 23-APR-2015 20:14:38
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile copy
copying standby control file
RMAN-00571: =======================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===========
RMAN-00571: =======================================================
RMAN-03002: failure of Duplicate Db command at 04/23/2015 20:14:46
RMAN-03015: error occurred in stored script Memory Script
RMAN-03009: failure of backup command on ORA_DISK_1 channel at 04/23/2015 20:14:46
ORA-17628: Oracle error 19505 returned by remote Oracle server



C'est presque sûr que le problème soit relié à un répertoire manquant.

Dans mon cas, j'ai regardé le spfile utilisé pour la base de données auxiliaire -celle à créer- et j'ai pu constater qu'un des répertoires des controlfile n'existait pas. 


$cat initTEST.ora

*.audit_file_dest='/DISK2/oracle/admin/TEST/adump'
*.audit_trail='db'
*.compatible='11.2.0.0.0'
*.control_files='/DISK2/oracle/oradata/TEST/control01.ctl','/DISK2/oracle/flash_recovery_area/TEST/control02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_flashback_retention_target=1440
*.db_name='TEST'
*.db_recovery_file_dest='/DISK2/oracle/flash_recovery_area'
*.db_recovery_file_dest_size=3145728000
*.db_unique_name='TEST_S'
*.diagnostic_dest='/DISK2/oracle'
*.dispatchers='(PROTOCOL=TCP) (SERVICE=TESTXDB)'
*.log_archive_dest_1='LOCATION=/DISK2/oracle/archives/dest1'
*.log_archive_format='%t_%s_%r.arc'
*.memory_target=606076928
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='EXCLUSIVE'
*.undo_tablespace='UNDOTBS1'

Une fois ajouté le répertoire vous pouvez relancer le DUPLICATE et tout devrait bien fonctionner.

La bonne technique de récupération ( "Recovery" )

Bonjour à tous.

       L'autre jour on m'a posé une question que j'aimerais partager avec vous. On m'a demandé de savoir quelles sont les meilleures techniques de récupération selon la situation.

Voici ce que j'ai peux vous dire  :

• Media Recovery
• Si vous avez perdu du matériel, soit les disques ou les datafiles. La meilleure alternative c'est d'utiliser RMAN, mais encore là cela dépendra de la situation.
• À ne pas confondre avec le Crash Recovery qui se fait tout seul par Oracle lorsque un arrêt non planifié est survenu et au moment de repartir il commence à récupérer ses transactions. 

• Flashback ou Point-in-time Recovery
• Si jamais la situation dans laquelle un utilisateur à commis une erreur, comme la suppression de données ou des objets de la base de données ou une mise à jour accidentelle de données.
• Bien sûr cela dépend de la situation, si quelqu'un a supprimé une table laquelle n'a pas changé depuis un dernier export, probablement cela serait une bonne alternative aussi.
• Flashback Table
• En cas des dommages limités à une ou quelques tablesen se servant de l'information contenue dans les UNDO
• Avec 12c, il y a maintenant un "Recover table", lequel vous donne aussi la possibilité de récupérer  la table comme un fichier "dump" lequel vous pouvez importer ultérieurement avec "impdp".
• Flashback Database 
• En cas qu'un modification accidentelle ait été faite sur une grande partie de la bases de données. 
• Bien sûr il y a d'autres flashback mais chacun aide pour une situation particulière mais cela sera un bon sujet pour une autre publication :)

• Block Media Recovery
• Si jamais vous retrouvez quelques blocs de données corrompus. Dans ce cas, effectuer juste la récupération des blocs serait conseillé plutôt que recouvrir la base de données au complet.  

A+