Showing posts with label RMAN. Show all posts
Showing posts with label RMAN. Show all posts

2018-06-06

How To DB Restore an Oracle DB on Another Host


Precondition on the host where the DB will be restored to (called test host / TEST_DB):
  • this description is valid for Linux
  • an own installed test DB, so that the binaries and directory structure are ready
  • enough storage like the original DB to be restored

The original DB to be restored on a different host (test host) will be called:
SID           : ORIG_DB
DB_UNIQUE_NAME: ORIG_DB_SITE1

All steps are performed on the test host.
If running stop your test DB.

Go to the admin directory
cd /u00/app/oracle/admin

Perhaps delete not log files that are not needed in order to save place, if your /u00 is not big enough
cd TEST_DB
find . \( -name "*.log" -o -name "*.aud" \) -exec rm {} \;

Create Oracle admin/SID directory as copy of your TEST_DB with the name of the DB 
cd ..
cp -R TEST_DB ORIG_DB

Insert the following line in file /etc/oratab 
ORIG_DB:/u00/app/oracle/product/12.2.0.1:N

Re-Logon as OS oracle user.
For example:
exit
sudo -u oracle sudosh

Set your Linux environment.
For example (using Baseenv from Triivadis):  
ORIG_DB

Two variants how to prepare the DB init file:
A) copy the init file from the ORIG_DB to your test host
B) edit the init file of your TEST_DB (if you do not have access to the original DB init file any more)

For both variants, here is the target directory where the DB init files are located:
cd /u00/app/oracle/admin/${ORACLE_SID}/pfile
A) the copy variant should be clear

B) edit variant
Rename the init file of your TEST_DB in order to match your ORIG_DB
mv initTEST_DB.ora initORIG_DB.ora
vi initORIG_DB.ora

In the initORIG_DB.ora, replace all TEST_DB by ORIG_DB substrings.
The following parameters are concerned:
    • control_files
    • db_name
    • db_unique_name
    • audit_file_dest

Perhaps delete other non used init*.ora, spfile*.ora and pfile.ora from this directory in order to avoid confusion.
ATTENTION: do not delete your prepared initORIG_DB.ora file

Create a symbolic link to your new initORIG_DB.ora file
cd $ORACLE_HOME/dbs
ln -s /u00/app/oracle/admin/${ORACLE_SID}/pfile/init${ORACLE_SID}.ora init${ORACLE_SID}.ora
  
Result. For Example:
oracle@test_host [ORIG_DB] ll
. . .
lrwxrwxrwx  1 oracle dba        49 Jun  5 11:22 initORIG_DB.ora -> /u00/app/oracle/admin/ORIG_DB/pfile/initORIG_DB.ora
. . .

Now you are ready to perform your restore.

Here is an example of an RMAN command files.
You will need to adapt:
  • how you connect to your RMAN-Catalog DB
  • the number of RMAN channels
  • the RMAN channels type and parameters (PARMS) (look at the RMAN log files of the ORIG_DB)
  • adapt the DBID
  • adapt the SCN for your needs / or use a time instead of SCN

You should be able to find the DBID in the logs of the RMAN backups of the ORIG_DB.
For example:
. . .
RMAN>
connected to target database: ORIG_DB (DBID=767753736)
. . .

You can also query the real ORIG_DB (not the new temporary DB on the test host) for the DBID (if available).
For example:
SQL> SELECT dbid FROM v$database;

      DBID
----------
 767753736

Startup the DB in nomount mode
SQL> startup nomount

Copy the controlfile of the ORIG_DB to the test host ***  . . .
(Assuming you have this controlfile in ASM file sytem or backup of the file system)
. . . and "restore" this controlfile:
rman TARGET/ NOCATALOG
SET DBID=767753736
RESTORE CONTROLFILE FROM "<Path to *** from above>";

ALTER DATABASE MOUNT;

Or, if you need to use the RMAN catalog (which will cause RMAN problems with the "original DB"):
RMAN command file that restore the DB control and start the DB in mount mode.
connect target /
connect catalog /@<Your RMANCATALOG>

SET DBID 767753736;

run {
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' PARMS="SBT_LIBRARY=/opt/hds/Base/libobk.so";
  SET UNTIL SCN=1815512098911;
  RESTORE CONTROLFILE;
  RELEASE CHANNEL CH1;
}
ALTER DATABASE MOUNT;

Or, if you need to use the RMAN catalog (which will cause RMAN problems with the ORIG_DB)

connect target /
connect catalog /@<Your RMAN catalog alias>

SET DBID 767753736;

run {
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' PARMS="SBT_LIBRARY=/opt/hds/Base/libobk.so";
  SET UNTIL SCN=1815512098911;
  RESTORE CONTROLFILE;
  RELEASE CHANNEL CH1;
}
ALTER DATABASE MOUNT;

ATENTION: After having used the RMAN catalog from another DB with the same DBID (here the TEST_DB), you will bee to go to the ORIG_DB and perform an RMAN crosscheck:

OS> rman target / catalog /@<Your RMAN catalog alias>

RMAN> crosscheck archivelog all;


Now the DB can be restored. (Again adapt the yellow entries)
connect target /
connect nocatalog

#SET DBID 767753736;

RUN
{
  ALLOCATE CHANNEL CH1 TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY=/opt/hds/Base/libobk.so';
  ALLOCATE CHANNEL CH2 TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY=/opt/hds/Base/libobk.so';
  ALLOCATE CHANNEL CH3 TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY=/opt/hds/Base/libobk.so';
  ALLOCATE CHANNEL CH4 TYPE 'SBT_TAPE' PARMS='SBT_LIBRARY=/opt/hds/Base/libobk.so';
  SET UNTIL SCN=1815512098911;
  RESTORE DATABASE;
  RECOVER DATABASE;
  #ALTER DATABASE OPEN RESETLOGS;
}






2018-05-02

Flashback Database After Failover: Correcting "Error ORA-38754: FLASHBACK DATABASE not started"


If the alert log file of the former primary DB contains the following error messages:
. . .
FLASHBACK DATABASE TO SCN 6693334
ORA-38754 signalled during: FLASHBACK DATABASE TO SCN 6693334...
. . .

Try to perform a flashback manually and you might get the following error:
SQL> FLASHBACK DATABASE TO SCN 6693334;
FLASHBACK DATABASE TO SCN 6693334
*
ERROR at line 1:
ORA-38754: FLASHBACK DATABASE not started; required redo log is not available
ORA-38762: redo logs needed for SCN 6691520 to SCN 6693334
ORA-38761: redo log sequence 124 in thread 1, incarnation 13 could not be accessed

In this case . . .

. . . on the new standby DB (former primary DB - before the failover),
use rman by connecting to the local DB and using the control file (NOCATALOG):
rman target=/ NOCATALOG

or (if baseenv from Triivadis is available - with history)

rmanh target=/ NOCATALOG

Since this command using the SCN did not return any archivelogs . . .
RMAN> LIST ARCHIVELOG SCN BETWEEN 6691520 AND 6693334;

. . . I searched for the backup of the archivelog with sequence 124 by guessing the time range . . .
LIST BACKUP OF ARCHIVELOG
      FROM TIME "TO_DATE('2018.05.01 20:00:00','YYYY.MM.DD HH24:MI:SS')"
      UNTIL TIME "TO_DATE('2018.05.02 12:00:00','YYYY.MM.DD HH24:MI:SS')";

. . . and was lucky and got the SCN of the desired archivelog (SCN 6691790) (but for restoring I choose the Low SCN of the previous archivelog i.e. 6689656 )
BS Key  Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ -------------------
343     60.00M     SBT_TAPE    00:00:52     2018-05-02 10:57:31
        BP Key: 343   Status: AVAILABLE  Compressed: NO  Tag: TAG20180502T105639
        Handle: 6446830_C0200Z01_c9t1sib7_1_1   Media: V_3683633_19130778

  List of Archived Logs in backup set 343
  Thrd Seq     Low SCN    Low Time            Next SCN   Next Time
  ---- ------- ---------- ------------------- ---------- ---------
. . .
  1    122     6687465    2018-05-02 10:27:49 6689656    2018-05-02 10:42:47
  1    123     6689656    2018-05-02 10:42:47 6691790    2018-05-02 10:56:38
  1    124     6691790    2018-05-02 10:56:38 6691798    2018-05-02 10:56:38


HINT
It can happen, that the needed archivelog, belongs to another incarnation of the DB.
(If this is the case - on Oracle 12c - you can use the incarnation number with the rman restore statement.)
This statement list your incarnations.
RMAN> list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       DB200Z01 2998214488       PARENT  1          2018-04-20 08:00:24
2       2       DB200Z01 2998214488       PARENT  2449245    2018-04-23 07:56:18
. . .
11      11      DB200Z01 2998214488       PARENT  5928815    2018-05-01 09:13:12
12      12      DB200Z01 2998214488       PARENT  6070931    2018-05-01 13:49:26
13      13      DB200Z01 2998214488       CURRENT 6179737    2018-05-01 14:47:30
==> Incarnation 13 is current (I do not need to use it with the restore statement)

Performing the restore of the archivelog (adapt the PARMS= for your needs):
RUN {
  ALLOCATE CHANNEL ch1 TYPE 'sbt_tape' PARMS="SBT_LIBRARY=/opt/hds/Base/libobk.so";
  # ALLOCATE CHANNEL ch1 TYPE disk;
  #
  RESTORE ARCHIVELOG FROM SCN 6689656;  # INCARNATION 13;
}

Output
allocated channel: ch1
channel ch1: SID=778 device type=SBT_TAPE
channel ch1: CommVault Systems for Oracle: Version 11.0.0(BUILD80)

Starting restore at 2018-05-02 13:15:52

archived log for thread 1 with sequence 125 is already on disk as file +U02/DB200Z01_HSB1/ARCHIVELOG/2018_05_02/thread_1_seq_125.759.975063515
. . .
archived log for thread 1 with sequence 133 is already on disk as file +U02/DB200Z01_HSB1/ARCHIVELOG/2018_05_02/thread_1_seq_133.741.975064009
channel ch1: starting archived log restore to default destination
channel ch1: restoring archived log
archived log thread=1 sequence=123
channel ch1: restoring archived log
archived log thread=1 sequence=124
channel ch1: reading from backup piece 6446830_DB200Z01_c9t1sib7_1_1

Now the standby DB should by able to automatically perform a flashback.

I hope it helps.

[ ]

2018-04-26

RMAN: Restoring ARCHIVELOG For Specific Database Incarnation


This description is only valid for Oracle DBs from version 11.2.x and above.

After an Oracle database has performed a failover, the former primary DB needs some archivelogs in order to become a synchronized standby DB. Sometimes test archive logs have been deleted from the DB host by the RMAN backup.

For cases, that it is not possible to simply restore the missing archivelogs for the actual DB incarnation, RMAN with Oracle 11.2.x and above offers the new syntax "RESTORE ARCHIVELOG ... INCARNATION ...".


Normally you can simply use the number of the previous incarnation. But for some "unclear" cases, this description shows how to find the correct incarnation for a needed specific archivelog.


In case the DB misses an archivelog, the DB alertlog should contain the following message after the restart of the standby DB:
. . .
2018-04-25T15:31:59.503251+02:00
Media Recovery start incarnation depth : 1, target inc# : 8, irscn : 3815571
Media Recovery Waiting for thread 1 sequence 32 branch(resetlogs_id) 974369770
. . .

Find the DB incarnation based in the resetlogs_id:
SQL>
set lines 400

select INCARNATION#, RESETLOGS_CHANGE#, RESETLOGS_TIME, STATUS, RESETLOGS_ID
  from V$DATABASE_INCARNATION
 where RESETLOGS_ID = 974369770;

INCARNATION# RESETLOGS_CHANGE# RESETLOGS_TIME      STATUS                       RESETLOGS_ID
------------ ----------------- ------------------- ---------------------------- ------------
           7           3674168 2018-04-25 10:16:10 PARENT                          974369770

Here the DB incarnations and their correspondent SCN:
RMAN>
list incarnation;

List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
1       1       X0300Z01 2998214488       PARENT  1          2018-04-20 08:00:24
2       2       X0300Z01 2998214488       PARENT  2449245    2018-04-23 07:56:18
3       3       X0300Z01 2998214488       PARENT  2450480    2018-04-23 08:03:30
4       4       X0300Z01 2998214488       PARENT  2451567    2018-04-23 08:07:43
5       5       X0300Z01 2998214488       PARENT  2798708    2018-04-24 08:31:27
6       6       X0300Z01 2998214488       PARENT  3360141    2018-04-25 09:05:27
7       7       X0300Z01 2998214488       PARENT  3674168    2018-04-25 10:16:10
8       8       X0300Z01 2998214488       CURRENT 3815572    2018-04-25 14:44:33

Here the confirmation, that the archivelog sequence number 32 shown in the alertlog is linked to the resetlogs_id 974369770 :
RMAN> LIST ARCHIVELOG SCN BETWEEN 3674168 AND 3815572;

List of Archived Log Copies for database with db_unique_name C0200Z01_HSB2
=====================================================================
Key     Thrd Seq     S Low Time
------- ---- ------- - -------------------
1217    1    32      A 2018-04-25 14:34:32
        Name: +U02/X0300Z01_SIT2/ARCHIVELOG/2018_04_26/thread_1_seq_32.783.974446349 (TERMINAL)

Examples how to restore the archive logs for DB incarnation 7
RUN {
  ALLOCATE CHANNEL ch1 TYPE 'sbt_tape' PARMS="XXXXXXXXXXXXXXXX";
  # ALLOCATE CHANNEL ch1 TYPE disk;
  #
  RESTORE ARCHIVELOG SEQUENCE 32 INCARNATION 7;
  # RESTORE ARCHIVELOG FROM SEQUENCE 32 INCARNATION ALL;
  # RESTORE ARCHIVELOG FROM SEQUENCE 32 INCARNATION 7;
  # RESTORE ARCHIVELOG SEQUENCE BETWEEN 32 AND 35 INCARNATION 7;
  # RESTORE ARCHIVELOG FROM SCN 3674168 INCARNATION 7;
  # RESTORE ARCHIVELOG SCN BETWEEN 3674168 AND 3815572 INCARNATION 7;
  #
  # Syntax OK, but does not restore from other DB incarnations (non current DB incarnation)
  # The syntax diagram shows, that it is not possible to restore by TAG from a
  # non current DB incarnation.
  #   RESTORE ARCHIVELOG ALL FROM TAG 'TAG20180425T145639';  
}






2016-07-07

Registering an Oracle DB into the RMAN Catalog


PROBLEM

If the Database ID changed (I described this in a previous post) and the RMAN catalog is used, RMAN will output the following error stack:

RMAN-03002: failure of backup command at 07/05/2016 03:56:13
RMAN-03014: implicit resync of recovery catalog failed
RMAN-06004: ORACLE error from recovery catalog database:
RMAN-20001: target database not found in recovery catalog



As the last error line says, the database can not be found in the RMAN catalog, because the DB ID is used in order to identify the catalog records belonging your DB.

SOLUTION

Logon as oracle on your DB host.
Logon with RMAN to your DB and your RMAN catalog (here TNS-Alias RMANCAT):

OS> rman target / catalog /@RMANCAT


Then register your DB into the RMAN catalog:

RMAN> REGISTER DATABASE;


PROBLEM 

If you are trying to register a standby DB and get this error:

RMAN> REGISTER DATABASE;
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20001: target database not found in recovery catalog

SOLUTION

First: make sure, that the primary DB is already registered in the RMAN catalog.
Then logon with the standby DB on the RMAN catalog and execute the following statement:

RUN {
  ALLOCATE CHANNEL FOR MAINTENANCE DEVICE TYPE sbt;
  CROSSCHECK BACKUP;
}

2016-07-05

Remove DB from RMAN Catalog


If using the Oracle password wallet, it is also possible to logon to the DB with rman without password.
(For this, before logon with rman, make sure that the environment variable TNS_ADMIN "points" to the Password wallet directory.)
In this example, the TNS-Alias of the RMAN-Catalog DB is "RMANCAT"
OS> rman catalog /@RMANCAT
Get the ID of your DB:
RMAN> list db_unique_name of database 'DB1_SID';
List of Databases
DB Key  DB Name  DB ID            Database Role    Db_unique_name
------- ------- ----------------- ---------------  ------------------
281963  DB1_SID 1738134485        PRIMARY          DB1_SITE1
  281963  DB1_SID 1738134485        STANDBY          DB1_SITE2
  394582  DB1_SID 5396830648        PRIMARY          DB5_SITE1
Set the DBID of the DB to be removed in the RMAN environment:
RMAN> set dbid 1738134485
executing command: SET DBID
database name is "DB1_SID" and DBID is 1738134485
Execute the unregister statement using the SID of your DB:
RMAN> unregister database DB1_SID;

database name is "DB1_SID" and DBID is 1738134485

Do you really want to unregister the database (enter YES or NO)?
YES
database unregistered from the recovery catalog
The unregistered DBs with ID 1738134485 are now gone:
RMAN> list db_unique_name of database 'DB1_SID';
List of Databases
DB Key  DB Name  DB ID        Database Role    Db_unique_name
------- ------- ------------- ---------------  ------------------
394582  DB1_SID 5396830648    PRIMARY          DB5_SITE1
.
.