10204 catalog database 112 target database and OEM

catalog database is 10.2.0.4 on server CSERV
OEM server is 10.2.0.4 OSERV
target database is 11.2 on server TSERV
I ran the RMAN command from RSERV (v10204) and registered target database (v112) without error
I went into OEM->TARGET page ->Maintenance->Recovery Catalog Settings->
     selected Use recovery catalog
     (the correct catalog was listed in the drop down (CSERV:1521:RMANUSER-rman_schema1
     added the OS username/password for TSERV
     pressed 'OK'
The error that was returned was:
"Recovery catalog scheme version 10.02 is not compatible with this version of RMAN."
I'm sure i'm doing something stupid, but would really appreciate any help.....
Regards,
Susan

Hi Susan,
Probably you used a 10g rman client on the command line to connect to both the target (11.2) and the catalog (10.2.0.4) during registration.
(according to the compatibilty matrix this works).
Be aware:
When using an older version of the RMAN client with a newer version of the database, you do not get the features of the newer version.According to your own information Grid uses the 11gr2 software.
added the OS username/password for TSERVWhich is incompatible with the 10.2 catalog.
Unfortunately, we can't upgrade the catalog at this time.You can upgrade the catalog schema without upgrading the catalog rdbms (but probably you do not want to execute any change during xmas and new year).
Please check:
http://download.oracle.com/docs/cd/B28359_01/backup.111/b28273/rcmsynta052.htm
Regards,
Tycho

Similar Messages

How to get RMAN catalog information from Target database?

Hi,
How to get RMAN catalog information from Target database because i don't know about catalog database? is it possible?
Thanks

If you run RMAN backups of a target database using a Catalog schema in another database, the target is not aware of the catalog.
The RMAN backup script would have the connection identifier for the Catalog.
Hemant K Chitale

Version Rman catalog higher than target database

Hi,
I have a database 10.1.0.2, but I couldn´t upgrade it to 10.1.0.3 or 10g R2 because this database is used by a application that needs this Oracle database version.
I have the catalog in another host with the same Oracle version, and I want to upgrade this database to 10.1.0.3 at least.
Is there any problem if I do the backups with a catalog with a version higher than the target database?
Thanks a lot.
Laura.

There should not be any problem in backup after upgrade of catalog database.
Cheers
Vignesh

Restore single datafile from source database to target database.

Here's my issue:
Database Release : 11.2.0.3 across both the source and targets. (ARCHIVELOG mode)
O/S: RHEL 5 (Tikanga)
Database Storage: Using ASM on a stand-alone server (NOT RAC)
Using Oracle GG to replicate changes on the Source to the Targets.
My scenario:
We utilize sequences to keep the primary key in tact and these are replicated utilizing GG. All of my schema tables are located in one tablespace and datafile and all of my indexes are in seperate tablespace (nothing is being partitioned).
In the event of media failure on the Target or my target schema being completely out of whack, is there a method where I can copy the datafile/tablespace from my source (which is intact) to my target?
I know there are possibilites of
1) restore/recover the tablespace to a SCN or timestamp in the past and then I could use GoldenGate to run the transactions in (but this could take time depending on how far back I need to recover the tablespace and how many transactions have processed with GG) (This is not fool-proof).
2) Could use DataPump to move the data from the Source schema to the Target schema (but the sequences are usually out of order if they haven't fired on the source, get that 'sequence is defined for this session message'). I've tried this scenario.
3) I could alter the sequences to get them to proper number using the start and increment by feature (again this could take time depending on how many sequences are out of order).
I would think you could
1) back up the datafile/tablespace on the source,
2)then copy the datafile to the target.
3) startup mount;
4) Newname the new file copied from the source (this is ASM)
5) Restore the datafile/tablespace
6) Recover the datafile/tablespace
7) alter database open;
Question 1: Do I need to also copy the backup piece from the source when I execute the backup tablespace on the source as indicated in my step 1?
Question 2: Do I need to include "plus archivelog" when I execute the backup tablespace on the source as indicated in my step 1?
Question 3: Do I need to execute an 'alter system switch logfile' on the Target when the recover in step 6 is completed?
My scenario sounds like a Cold Backup but running with Archivelog mode, so the source could be online while the database is running.
Just looking for alternate methods of recovery.
Thanks,
Jason

Let me take another stab at sticking a fork into this myth about separating tables and indexes.
Let's assume you have a production Oracle database environment with multiple users making multiple requests and the exact same time. This assumption mirrors reality everywhere except in a classroom where a student is running a simple demo.
Let's further assume that the system looks anything like a real Oracle database system where the operating system has caching, the SAN has caching, and the blocks you are trying to read are split between memory and disk.
Now you want to do some simple piece of work and assume there is an index on the ename column...
SELECT * FROM emp WHERE ename = 'KING';The myth is that Oracle is going to, in parallel, read the index and read the table segments better, faster, whatever, if they are in separate physical files mapped by separate logical tablespaces somehow to separate physical spindles.
Apply some synapses to this myth and it falls apart.
You issue your SQL statement and Oracle does what? It looks for those index blocks where? In memory. If it finds them it never goes to disk. If it does not it goes to disk.
While all this is happening the hundreds or thousands of other users on the database are also making requests. Oracle is not going to stop doing work while it tries to find your index blocks.
Now it finds the index block and decides to use the ROWID value to read the block containing the row with KING's data. Did it freeze the system? Did it lock out everyone else while it did this? Of course not. It puts your read request into the queue and, again, first checks memory to see if it needs to go to disk.
Where in here is there anything that indicates an advantage to having separate physical files?
And even if there was some theoretical reason why separate files might be better ... are they separate in the SAN's cache? No. Are they definitely located on separate stripes or separate physical disks? Of course not.
Oracle uses logical mappings (tables and tablespaces) and SANS use logical mappings so you, the DBA or developer, have no clue as to where anything physically is located.
PS: Ouija Boards don't work either.

Rman backup to be stored on other machine than catalog and Target database

I have target database on machine A, catalog on machine B. I am executing RMAN from machine B but want to store RMAN backup on machine C. is it possible.

Recovery Manager: Release 9.2.0.1.0 - Production
Copyright (c) 1995, 2002, Oracle Corporation. All rights reserved.
connected to target database: NEFT (DBID=3608824086)
connected to recovery catalog database
RMAN> run{
2> allocate channel c1 device type disk format '\\bobfs\f\RMAN\data\neft\Rman_NEFT_%U';
3> backup full database;
4> backup current controlfile;
5> }
6>
allocated channel: c1
channel c1: sid=16 devtype=DISK
Starting backup at 15-OCT-08
channel c1: starting full datafile backupset
channel c1: specifying datafile(s) in backupset
input datafile fno=00011 name=F:\DATABASE\NEFT\DATABASENEFT_DATA1.DBF
input datafile fno=00015 name=F:\DATABASE\NEFT\UNDOTBS.DBF
input datafile fno=00013 name=F:\DATABASE\NEFT\DATABASENEFT_ARCH_DATA1.DBF
input datafile fno=00002 name=F:\DATABASE\NEFT\UNDOTBS01.DBF
input datafile fno=00001 name=F:\DATABASE\NEFT\SYSTEM01.DBF
input datafile fno=00014 name=F:\DATABASE\NEFT\DATABASENEFT_ARCH_NDX1.DBF
input datafile fno=00005 name=F:\DATABASE\NEFT\EXAMPLE01.DBF
input datafile fno=00012 name=F:\DATABASE\NEFT\DATABASENEFT_NDX1.DBF
input datafile fno=00010 name=F:\DATABASE\NEFT\XDB01.DBF
input datafile fno=00006 name=F:\DATABASE\NEFT\INDX01.DBF
input datafile fno=00009 name=F:\DATABASE\NEFT\USERS01.DBF
input datafile fno=00003 name=F:\DATABASE\NEFT\CWMLITE01.DBF
input datafile fno=00004 name=F:\DATABASE\NEFT\DRSYS01.DBF
input datafile fno=00007 name=F:\DATABASE\NEFT\ODM01.DBF
input datafile fno=00008 name=F:\DATABASE\NEFT\TOOLS01.DBF
channel c1: starting piece 1 at 15-OCT-08
released channel: c1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command on c1 channel at 10/15/2008 10:45:38
ORA-19504: failed to create file "\\bobfs\f\RMAN\data\neft\Rman_NEFT_7qjt6tat_1_1"
ORA-27040: skgfrcre: create error, unable to create file
OSD-04002: unable to open file
O/S-Error: (OS 5) Access is denied.
Recovery Manager complete.
I am executing rman from catalog machine,
WHen i give path \\bobfs\f\RMAN\data\neft\ in start-> run it is accessible from there.
I cant understand why rman is not abl to create file there.
full rights are given to user. and user on rman catalog and network machine is same having same password

Recovery catalog, target database.

Hello all,
I have a question concerning recovery catalog.
Can i use the same database as recovery catalog and target database?
Let us say that i have a database orcl, can this database be the target and the recovery catalog at the same time ? is there any disadvantages?
Regards,

NB wrote:
Hello all,
I have a question concerning recovery catalog.
Can i use the same database as recovery catalog and target database?
Let us say that i have a database orcl, can this database be the target and the recovery catalog at the same time ? is there any disadvantages?Yes you can use the same database as the recovery catalog but that's going to be a wrong decision. Think about this, you have lost your target database and since you had your recovery catalog also stored in it, now that's also gone! So a good thing or bad thing it would be ?
Edit:
Please read the same from the docs,
http://download.oracle.com/docs/cd/E11882_01/backup.112/e10642/rcmcatdb.htm#CHDECBEH
Do not use the target database to be backed up as the database for the recovery catalog. The recovery catalog must be protected in the event of the loss of the target database.Aman....
Edited by: Aman.... on Aug 7, 2011 4:26 PM

How to un-register target database in Catalog DB?

I am using 8.0.5. I create a Catalog database and register a target database with it for online backup. How do I un-register a target database from the Catalog DB if I do not want to continue taking backup? Is there any 'unregister' command?
Thanks in advance
- Sanchayan RoyChoudhury
Bangalore, India
null

Let me try...
If u know your dbid (which can be found out by just logging into rman with the target databasse)
login ot the catalog database throught sqlpplus as the catalog schema owner...
run the following query..
SELECT db_key, db_id FROM db WHERE db_id ="dbid just found";
then run
execute dbms_rcvcat.unregisterdatabase(db_key, db_id);
This will unregister your database from the catalog. however keep in mind that you will lose all records of your old backups..
HTH
null

Connecting to Catalog & Target Database

I am trying to register a target database with a recovery catalog. RMAN database and the catalog table space were created. When trying to connect to target with the SID set to the instance name and simply connecting as username/password, I am getting connected to the target. If I try to connect using the connect string, I get the following error
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04005: error from target database: ORA-12154: TNS:could not resolve service name
But the TNS names have been properly configured and I am able to connect from sql*plus using the connect string.
Similarly I set the SID to RMAN database and try to connect catalog with username/password I am able to connect to Catalog and if I use connect string for the target, I am getting the same error as mentioned above.
I really do not know, How to resolve this and to connect to Target and RMAN databases simultaneously.

I suggest you do the following to see if the connect strings are really working, either:
1) Change ORACLE_SID to be of the catalog database, now do:
% sqlplus "<user>/<pwd>@<target string> as sysdba"
Does that work? If as I suspect it does not work or connects you to the catalog database (not the target), then it is a missconfiguration of the network files.
2) Do the same for connection to the catalog, set ORACLE_SID to be the one of the target database and do:
% sqlplus "<user>/<pwd>"
Does that connects you to the catalog?

Views to check the catalog database name from target database.

Hi,
Please help me to find view to check the catalog database name which is connected to my target database because I am new to the current environment where I am working now and the previous DBA have done the set up having 2 catalog database. I want view to check from target database, which can show the catalog database name to which it is connected to.
We can check the catalog database name from the following ways but I want views to check it from target database.
1.TNSnames.ora
2.Any backup script connecting to catalog database.
3.From catalog database we can use rc_database view to check the databases registered with the catalog database.

Please help me to find view to check the catalog database name which is connected to my target databaseYou can check for any RMAN backup jobs that been scheduled on the server.
In the scheduled script check rman command.
You can then identify the database alias (of the catalog db) that is used in the rman backup script.
Once you have found the database alias, check for the database alias entry in tnsnames.ora file present in your target database server.
Once the entry is found, you can find the IP address and catalog db name from the tns entry.
Edited by: st. osh on Nov 22, 2012 11:38 PM

RMAN catalog fails to show target database information when in nomount mode

Hello everyone, I am trying to restore a dev. database from its own backup taken a week back. The DB is in noarchivelog mode and recently 2 of the datafiles were removed from the files system and thus the need to restore the DB from its backup. However rest of the files and control files are intact.
Now, when I put the database in mount mode and connect to the catalog then I can see the DB's incarnation;
:->rman catalog cde01_rman4/xxxxxxx@prman10g target /
Recovery Manager: Release 10.2.0.3.0 - Production on Thu Jun 11 13:54:40 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: EGVBFI2 (DBID=4238332493, not open)
connected to recovery catalog database
RMAN> list incarnation;
List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
84789 84883 EGVBFI2 4238332493 PARENT 2478183021921 17-JAN-04
84789 84790 EGVBFI2 4238332493 CURRENT 2498633332010 10-OCT-07
RMAN>
However I am not able to see DB incarnation in the RMAN catalog if I put the DB in nomount mode (which is required to recover DB);
:->rman catalog cde01_rman4/xxxxxx@prman10g target /
Recovery Manager: Release 10.2.0.3.0 - Production on Thu Jun 11 13:58:29 2009
Copyright (c) 1982, 2005, Oracle. All rights reserved.
connected to target database: egvbfi2 (not mounted)
connected to recovery catalog database
RMAN> list incarnation;
RMAN>
Please advice?
Thanks,
Jairaj

Hi,
You won't be able to see incarnation information when the DB is in "nomount" since the incarnation is written in the control file. I don't think the catalog has this information.
Anyway, in order to restore datafiles, the instance must be mounted, so you should be OK.
Mount the instance and just restore the datafiles.
Liron Amitzi
Senior DBA consultant
link: [www.dbsnaps.com]
link: [www.obriumsoftware.com]

RMAN-20001: target database not found in recovery catalog

I am practicing loss off all control files. I have rman catalog backups which are set to autobackup controlfile. So far I did this.
RMAN> startup nomount;
Oracle instance started
Total System Global Area 209715200 bytes
Fixed Size 1272864 bytes
Variable Size 155190240 bytes
Database Buffers 50331648 bytes
Redo Buffers 2920448 bytes
RMAN> restore controlfile from autobackup;
Starting restore at 08-SEP-10
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=156 devtype=DISK
recovery area destination: /u02/flash_recovery
database name (or database unique name) used for search: TEST
channel ORA_DISK_1: autobackup found in the recovery area
channel ORA_DISK_1: autobackup found: /u02/flash_recovery/TEST/autobackup/2009_12_09/o1_mf_s_705171034_5l0kgv4o_.bkp
channel ORA_DISK_1: control file restore from autobackup complete
output filename=/u02/control_files/TEST/control02.ctl
output filename=/u03/oradata/TEST/control03.ctl
Finished restore at 08-SEP-10
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of alter db command at 09/08/2010 14:54:50
RMAN-06004: ORACLE error from recovery catalog database: RMAN-20001: target database not found in recovery catalog
I am assuming this has something to do with DBID but ... I don't have it and I don't know how to find it.

Hi BelMan,
Here is output
BS Key Type LV Size Device Type Elapsed Time Completion Time
56869 Full 11.20M DISK 00:00:00 08-SEP-10
BP Key: 56871 Status: AVAILABLE Compressed: NO Tag: TAG20100908T135312
Piece Name: /u01/oracle/product/10.2.0/db_1/dbs/cf_c-549414289-20100908-00
Control File Included: Ckp SCN: 125665520 Ckp time: 08-SEP-10
BS Key Type LV Size Device Type Elapsed Time Completion Time
56993 Full 11.20M DISK 00:00:00 08-SEP-10
BP Key: 56995 Status: AVAILABLE Compressed: NO Tag: TAG20100908T142547
Piece Name: /u01/oracle/product/10.2.0/db_1/dbs/cf_c-549414289-20100908-01
Control File Included: Ckp SCN: 125668490 Ckp time: 08-SEP-10

Query to identify the recovery catalog database name from target database

Hi,
How to get the recovery catalog database name from the registered target database?
i dont know my recovery catalog database for my target database.
I know we can use the query
select * from rc_database;
from recovery catalog database to know all the registered database with the recovery catalog but I want to know is there any way or query to identify the recovery catalog database name from target database to which the target database is registered
With Regards
Boobathi P

You can check the backup scripts which you use to backup your target database to get the catalog database name.
And check the corresponding connect string in TNSNAMES.ORA file or tnsping to get the server details of the catalog database.
Edited by: gopal on Apr 12, 2013 12:59 PM

OEM 10g DBControl: no information in Database Instance. Listener and Agent

Hi,
we hat a Database Crash, after recovering the Database the OEM is not working completely.
There are no informations about Database Instance, Listener and Agent.
The emoms.trc :
2006-01-23 17:40:29,409 [EMUI_17_40_29_/console/database/instance/sitemap] ERROR rt.DbMetricCollectorTarget _getListenerTarget.366 - oracle.sysman.emSDK.emd.comm.CommException: IOException in sending Request :: Connection refused
oracle.sysman.emSDK.emd.comm.CommException: IOException in sending Request :: Connection refused
at oracle.sysman.emSDK.emd.comm.EMDClient.getResponseForRequest_(EMDClient.java:1308)
at oracle.sysman.emSDK.emd.comm.EMDClient.getResponseForRequest(EMDClient.java:1212)
at oracle.sysman.emSDK.emd.comm.EMDClient.getTarget(EMDClient.java:826)
at oracle.sysman.emSDK.emd.comm.EMDClient.getTarget(EMDClient.java:834)
at oracle.sysman.emo.perf.metric.rt.DbTargetDown._getListenerTarget(DbTargetDown.java:346)
at oracle.sysman.emo.perf.metric.rt.DbTargetDown.getData(DbTargetDown.java:159)
at oracle.sysman.emo.perf.metric.eng.MetricCollectorThread.getMetricResult(MetricCollectorThread.java:993)
at oracle.sysman.emo.perf.metric.eng.MetricCollectorTarget.getMetricResult(MetricCollectorTarget.java:564)
at oracle.sysman.db.uix.DBUtil.getMetricResult(DBUtil.java:249)
at oracle.sysman.emo.smap.TargetDownBean.initialize(TargetDownBean.java:89)
at oracle.sysman.db.adm.inst.SitemapController.setRequestAttributes(SitemapController.java:1043)
at oracle.sysman.db.adm.BaseController.handleEvent(BaseController.java:848)
at oracle.sysman.emSDK.svlt.PageHandler.handleRequest(PageHandler.java:376)
at oracle.sysman.db.adm.RootController.handleRequest(RootController.java:169)
at oracle.sysman.db.adm.DBControllerResolver.handleRequest(DBControllerResolver.java:114)
at oracle.sysman.emSDK.svlt.EMServlet.myDoGet(EMServlet.java:688)
at oracle.sysman.emSDK.svlt.EMServlet.doGet(EMServlet.java:291)
at oracle.sysman.eml.app.Console.doGet(Console.java:285)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:740)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at com.evermind.server.http.ResourceFilterChain.doFilter(ResourceFilterChain.java:65)
at oracle.sysman.emSDK.svlt.EMRedirectFilter.doFilter(EMRedirectFilter.java:101)
at com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:16)
at oracle.sysman.db.adm.inst.HandleRepDownFilter.doFilter(HandleRepDownFilter.java:138)
at com.evermind.server.http.EvermindFilterChain.doFilter(EvermindFilterChain.java:20)
at oracle.sysman.eml.app.ContextInitFilter.doFilter(ContextInitFilter.java:269)
at com.evermind.server.http.ServletRequestDispatcher.invoke(ServletRequestDispatcher.java:600)
at com.evermind.server.http.ServletRequestDispatcher.forwardInternal(ServletRequestDispatcher.java:317)
at com.evermind.server.http.HttpRequestHandler.processRequest(HttpRequestHandler.java:793)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:270)
at com.evermind.server.http.HttpRequestHandler.run(HttpRequestHandler.java:112)
at com.evermind.util.ReleasableResourcePooledExecutor$MyWorker.run(ReleasableResourcePooledExecutor.java:192)
at java.lang.Thread.run(Thread.java:534)
any ideas?
thanks Wolfgang

If you recovered only the database ensure that
Database Name and Instance Name remains unchanged.
Listener name and ports is the same
Ensure they all services can start successfully. If not, recreate the services.
If you recovered any other thing other than the database, ensure that you followed the correct recovery procedure for both the database and directory structures
e.g
Directory names and structures are recreated as before Crash
Oracle and Agent Homes remain the same as before crash
IP Address and Ports remain unchanged
Then restart both the database and db control
In short, the important thing is to keep all all before crash especially for DB Control to work immeiodiately.

Issue in OWB mapping - when changing source and target database

Hi,
I need help for resolution of the issue I am facing when moving mapping from development environment to QA.
Here is situation,
We develop ETL using one source, one staging and one target database.
In development we use one control_center for Source to staging and another control center staging to target.
All works fine in development.
Now I have created new runtime repository and imported all OWB projects (with full dependencies, exact replica of development). Now I need to change source and staging and target as different database.
I have created new database location connections and defined/attached DB connectors with stage and target location.
Now issues are
1.     Two Staging mapping are not able to bound with source table (giving different error
a.     One mapping show error for source synonym translation no longer valid when deploying this mapping , but validation comes without any issue)
b.     Other mapping show error for source table/object not bound to repository
2.     All the target mapping show validation successful, but when deploying says “table or view does not exist”. But tables are exists on source stage and target. (also permission are set correctly for target user to read from staging tables).
Not sure how to proceed from here.
I have recreated new repository and re-imported all project/mappings and defined all connection but still same issue.
Thanks in advance,
Vipin

1. Two Staging mapping are not able to bound with source table (giving different error
a. One mapping show error for source synonym translation no longer valid when deploying this mapping , but validation comes without any issue)
b. Other mapping show error for source table/object not bound to repository
The above error were resolved when re-synchronized the table (for few I have to reimport the table) and mapping.
2. All the target mapping show validation successful, but when deploying says “table or view does not exist”. But tables are exists on source stage and target. (also permission are set correctly for target user to read from staging tables).
The above error still pending. My target mapping are not able to deployed/compiled.
For the above I have defined one Staging location to one target target location and target location have connector to staging (not sure if I have to define connector name same as staging location, as I have created DB connector with different name but reference database is same as staging location).
Mapping are assoicated with desired data locatoin and meta data.
control center is also have that data location.
Mapping are configured for the desired location.

How to read the source file and copy the entire content to the target Database field

Hi All,
PI system extracts the actual business content from the incoming attachment file and copy the entire format to the target Database field which is a blob data type field.
Sender Adapter: SOAP
Receiver Adapter: JDBC
JDBC Structure
Can we achived the above requirement by using UDF with out Java Mapping?
Thanks,
Mahi.

Ok, in this case yo can use the conten converion of the file adapter. Therefore you first need to create a Datatype in ESR with the required structure
Then in your file adapter you need to use this datatype and its required fields:
The Datatype then can be used as usual within you mapping.
regards
Christian

10204 catalog database 112 target database and OEM

Similar Messages

Maybe you are looking for