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

Wednesday, February 27, 2019

Oracle : RMAN-06004: ORACLE error from recovery catalog database: RMAN-20001: target database not found in recovery catalog


The backups were failing with below error after a DB refresh was done


RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of show command at 02/26/2019 18:31:13
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20001: target database not found in recovery catalog

Fix : 

We had to register the database by connecting to the catalog


$ rman target /

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Feb 27 14:58:42 2019

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

connected to target database: ABSPD2 (DBID=3485384910)

RMAN> connect catalog rman_s2rom1d2/Apr_of_2016@p1nbu1d5.db.att.com;

connected to recovery catalog database

RMAN> register database;

database registered in recovery catalog
starting full resync of recovery catalog
full resync complete


This fixed the issue and the backups started running again. 

Wednesday, January 30, 2019

Oracle :Cross Platform DB migration; Checking Endian Format

Doing cross platform migration using RMAN


Starting from 10gR2, Oracle introduced the next magical feature of RMAN its ability to convert the database from one platform to a different one which shares the same endian format.  This feature is called Cross-Platform Database Migration.  

To convert the database from one platform to another, the endian format of both databases should be the same

To know if we can use RMAN for the migration, We cam query v$transportable_platform view which shows the endian format for almost all Oracle platforms: 


SQL> select * from v$transportable_platform;

PLATFORM_ID PLATFORM_NAME                  ENDIAN_FORMAT
----------- ------------------------------ --------------
1           Solaris[tm] OE (32-bit)          Big
2           Solaris[tm] OE (64-bit)          Big
7           Microsoft Windows NT             Little
10          Linux IA (32-bit)                Little
6           AIX-Based Systems (64-bit)       Big
3           HP-UX (64-bit)                   Big
5           HP Tru64 UNIX                    Little
4           HP-UX IA (64-bit)                Big
11          Linux IA (64-bit)                Little
15          HP Open VMS                      Little
8           Microsoft Windows IA (64-bit)    Little
9           IBM zSeries Based Linux          Big
13          Linux 64-bit for AMD             Little
16          Apple Mac OS                     Big
12          Microsoft Windows 64-bit for AMD Little




The v$database data dictionary view also adds two columns, platform ID and platform name:


select  name, platform_id, platform_name from v$database;

NAME      PLATFORM_ID PLATFORM_NAME
--------- ----------- ---------------------

P3OMS1D5           13 Linux x86 64-bit





To transport a tablespace from one platform to another, datafiles on different platforms must be in the same endian format (byte ordering).
The pattern for byte ordering in native types is called endianness. There are only two main patterns, big endian and little endian. Big endian means the most significant byte comes first, and little endian means the least significant byte comes first.

Wednesday, September 7, 2016

ORA-00245: control file backup failed; target is likely on a local file system

Error : ORA-00245: control file backup failed; target is likely on a local file system

Cause : the control file is saved on local file system., in case of RAC databases the control file snapshot should be saved on the shared location.

Solution : Make change in RMAN to point the control file snapshot to be saved under shared location

RMAN> CONFIGURE SNAPSHOT CONTROLFILE NAME TO '+DB4_ORADATA/snapcf_db4.f';