Rman repository and target

Hi,
my RMAN repository is in 10g R2, and target is in 8.1.7.4. I want to know when I backup by RMAN what would be the RMAN version executing the job ? RMAN 8.1.7 or RMAN 10g ? Thanks and regards.

Yo would be using the RMAN executable in the target ORACLE_HOME (ie, RMAN would be 'local' to the database).

Similar Messages

One schema for OWB Design repository, runtime repository and target schema

Currently we have contents of OWB Design schema, runtime schema and target schema all combined into one schema of the same database in OWB 9.0.2 as well as OWB3i. We like to move to OWB10g in very near future. Can we keep the same structure for convenience of migration in OWB10g? Is it mandatory that OWB design repository (and components) must be separate from OWB run time repository (and components) and target schema? In other words is it possible and workable to use only one schema to contain OWB design repository, OWB run time repository and target schema in OWB10g environment with repositories to be situated on Oracle v9.2.0.1.0? Also what special considerations should be taken to create the database v9.2.0.1.0 and installation of OWB10g. What are the problems/side-effects to have all in one schema?
Also please let me know how to install Oracle Workflow server to be used along with OWB. Will OWB10g work with repository on Oracle database v9.2.0.1.0?
Your prompt advice will be very well appreciated.
Sankar

The design repo is a metadata repo that stores all the design-time objects and so forth.
It is an architectural decision that you or your team need to decide on. There are many flexible ways to architect an OWB infrastructure.
Also, your repository users will be using the design repository on the the other DB instance to do their design work...potentially less people always hitting the target database all the time.
-Greg

RPE-01011 target location incompatible / repository and target are same 11g

I got systematically error RPE-01011 signaling my target location is incompatible. My repository and my target are the same instance and i didn't change anything in the settings. The instance is an 11g database. I don't understand what the problem is. All scripts are execting correctly when i install then manually.

I am having the same problem trying to deploy objects created as per Oracle by Example: Oracle Warehouse Builder 11g. The database version is 11g Release 11.1.0.6.0 and all locations have 11.1 version. This is the second time I am running this tutorial, this time I modified the setup scripts to replace 10.2 by 11.1 but after rerunning all previous tutorials I got the same error.

Informatica Repository and Target database

I have a scenario in which the repository database is DB1 and target database is DB2. How is that possible? I mean isnt the target database stored in the repository? Is it still alright?

Hi,
Informatica repository tables generally referred as OPB tables and which has all the data related to your mappings and by using these tables informatica will refer the mappings.
Thanks,
Navin Kumar Bolla

RMAN catalog and Target database

Hi All,
Please clarify my below doubts.
We have one server "server1" with oracle (catalog database) version 10.2.0.1
I have server "server2", and we have four oracle homes with four oracle users.Each oracle home consist of one database. all database are with 10.2.0.3 version.
All these databases registered with the above catalog database.
1 -> Can we register databases with a lower catalog database.
2 -> Now we are upgrading one database to 10.2.0.5 (in server2), in upgrade step we need to action step -: catalog upgrade. If we run this command actually what will be the result?
3 -> We are upgrading only one database in server2. remaining 3 database are in the version 10.2.0.3, upgrade catalog command will upgrade catalog database to 10.2.0.5 version, am I right?
4 -> Here do I need to run upgrade catalog ?
Thanks,
Asim
Edited by: user229955 on Feb 25, 2012 4:18 PM

Please refer this MOS document *RMAN Compatibility Matrix [ID 73431.1]*
You would surely get your answers if you mark your previous questions as answered rather than keeping it open.

PSU level of RMAN Catalog DB version and Target DBs

Catalog DB Version: 11.2.0.2.3
Target DBs : 11.2.0.2.3
Currently our Catalog DB and Target DBs ( 15 of them) are of the same PSU level.
We are going to apply PSU 5 (11.2.0.2.3) on some of the target DBs . Should we apply PSU 5 (11.2.0.2.3) on the Catalog DB first before we apply this PSU on the target DBs?

Hi TeslaMan,
Probably you mean the rdbms version of the catalog is version 11.2.0.2.3.
If you upgrade target databases with a cpu you might need to upgrade the catalog schema to an equal or higher level.
Please check the current catalog schema version with the following sql.
select * from RCVER;Maybe you can create a dummy catalog schema with the patched up rdbms rman cli (maybe you tested the cpu already?) and check the new version with the same sql.
Regards,
Tycho

EM and RMAN repository...

I need some more clarification on something.
I know Enterprise Edition allows setup of Enterprise Manager repository and RMAN repository. Can those be setup on a different box then the one where the main database is? I ask this because I want to have some redundancy by not using the same box for monitoring and backups.

Hello,
YOu can setup grid control and monitor not only one but several database server from it. On db server you just have install agent to talk to grid control and you will be in business.
Regards

RMAN repository maintenace and the availability

I have 10 production and 10 test databases in 2 servers(Test and Production). RMAN Backups have setup and add all the 20 databses in to a repository in one of the Test server database called CODP.
So my question is as all the databases added to CODP db repository and codp database also add in to the same database repository it self. If CODP database corrupted all the data in the repository will be lost and no way to recover unless there is a another backup or setup.
So my question is what would be the best approach to handle this situation?? Appriciate any comments or advices.
Regards
Karunika

Hello,
Consider RMAN repository database as one of the production database and you should have a proper backup strategy for your RMAN repository database so that in case any problem happens, you immediately restore the RMAN repository. Put your RMAN repository in archivelog mode and take backups regularly and if appropriate, you can setup replication of RMAN repository schema in another remote database.
Salman

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

Where to backup RMAN repository?

Oracle recommendation is to backup databases with RMAN using RMAN Repository Database. But how about RMAN Repository? Should it become client of the same repository(itself)? Right now I am using RMAN to backup repository database into control file.
Not sure that's right thing to do though ... I need some guidance from experienced dba's.

Hi,
Include the recovery catalog in your backup and recovery strategy. If you do not back up your recover catalog and a disk crash occurs, you may lose some or all of your data.
Make Logical Backups
Make Regular Backups
Back up the recovery catalog with the same frequency that you back up your target database. For example, if you make a weekly whole database backup of your target database, then back up your recovery catalog immediately after each target database backup. The backed up catalog will have a record of the target backup preceding it, so if you are forced to restore the catalog you will also be able to use it to restore the target database backup
see this link
http://www.pafumi.net/manage_rman_repository.htm#11.%20Backing%20Up%20and%20Recovering%20the%20Recovery

RMAN repository clean up

Hi,
I am having 10g db and backup policy uses RMAN.
Daily backup is taken by RMAN and my retention policy is default.
Now my total catalog db size is 12 GB,
but i want to remove entries before 1 months from repository because all the archives are already taken in backup and also applied to stand by db.
Is there any method to clean up RMAN repository ?
Thanks in advance

Viral,
This is what I do to reconcile the contents of the recovery catalog with the backup files on disk. Check out Oracle's documentation on RMAN commands before executing these commands.
Bill
$ su – oracle
$ export ORACLE_SID=<SID of target database>
$ rman rcvcat rman/<password>@<recovery catalog instance>
RMAN> connect target
RMAN> LIST EXPIRED BACKUP;
RMAN> CROSSCHECK BACKUP;
RMAN> LIST EXPIRED BACKUP;
RMAN> DELETE EXPIRED BACKUP;               (Respond “y” to delete objects.)
RMAN> LIST EXPIRED BACKUP;
RMAN> LIST BACKUP OF DATABASE;
RMAN> LIST BACKUP OF DATABASE SUMMARY;
RMAN> LIST EXPIRED ARCHIVELOG ALL;
RMAN> CROSSCHECK ARCHIVELOG ALL;
RMAN> LIST EXPIRED ARCHIVELOG ALL;
RMAN> DELETE EXPIRED ARCHIVELOG ALL;     (Respond “y” to delete objects.)
RMAN> LIST EXPIRED ARCHIVELOG ALL;
RMAN> LIST BACKUP OF ARCHIVELOG ALL;
RMAN> LIST BACKUP OF ARCHIVELOG ALL SUMMARY;

RMAN BACKUPS AND ARCHIVED LOG ISSUES

제품 : RMAN
작성날짜 : 2004-02-17
RMAN BACKUPS AND ARCHIVED LOG ISSUES
=====================================
Scenario #1:
1)RMAN이 모든 archived log들을 삭제할 때 실패하는 경우.
database는 두 개의 archive destination에 archive file을 생성한다.
다음과 같은 스크립트를 수행하여 백업후에 archived redo logfile을 삭제한다.
run {
allocate channel c1 type 'sbt_tape';
backup database;
backup archivelog all delete input;
Archived redo logfile 삭제 유무를 확인하기 위해 CROSSCHECK 수행시 다음과
같은 메시지가 발생함.
RMAN> change archivelog all crosscheck;
RMAN-03022: compiling command: change
RMAN-06158: validation succeeded for archived log
RMAN-08514: archivelog filename=
/oracle/arch/dest2/arcr_1_964.arc recid=19 stamp=368726072
2) 원인분석
이 문제는 에러가 아니다. RMAN은 여러 개의 arhive directory중 하나의
directoy안에 있는 archived file들만 삭제한다. 그래서 나머지 directory안의
archived log file들은 삭제되지 않고 남게 되는 것이다.
3) 해결책
RMAN이 강제로 모든 directory안의 archived log file들을 삭제하게 하기 위해서는
여러 개의 채널을 할당하여 각 채널이 각 archive destination안의 archived file을
백업하고 삭제하도록 해야 한다.
이것은 아래와 같이 구현될 수 있다.
run {
allocate channel t1 type 'sbt_tape';
allocate channel t2 type 'sbt_tape';
backup
archivelog like '/oracle/arch/dest1/%' channel t1 delete input
archivelog like '/oracle/arch/dest2/%' channel t2 delete input;
Scenario #2:
1)RMAN이 archived log를 찾을 수 없어 백업이 실패하는 경우.
이 시나리오에서 database를 incremental backup한다고 가정한다.
이 경우 RMAN은 recover시 archived redo log대신에 incremental backup을 사용할
수 있기 때문에 백업 후 모든 archived redo log를 삭제하기 위해 OS utility를 사용한다.
그러나 다음 번 backup시 다음과 같은 Error를 만나게 된다.
RMAN-6089: archive log NAME not found or out of sync with catalog
2) 원인분석
이 문제는 OS 명령을 사용하여 archived log를 삭제하였을 경우 발생한다. 이때 RMAN은
archived log가 삭제되었다는 것을 알지 못한다. RMAN-6089는 RMAN이 OS 명령에 의해
삭제된 archived log가 여전히 존재하다고 생각하고 백업하려고 시도하였을 때 발생하게 된다.
3) 해결책
가장 쉬운 해결책은 archived log를 백업할 때 DELETE INPUT option을 사용하는 것이다.
예를 들면
run {
allocate channel c1 type 'sbt_tape';
backup archivelog all delete input;
두 번째로 가장 쉬운 해결책은 OS utility를 사용하여 archived log를 삭제한 후에
다음과 같은 명령어를 RMAN prompt상에서 수행하는 것이다.
RMAN>allocate channel for maintenance type disk;
RMAN>change archivelog all crosscheck;
Oracle 8.0:
RMAN> change archivelog '/disk/path/archivelog_name' validate;
Oracle 8i:
RMAN> change archivelog all crosscheck ;
Oracle 9i:
RMAN> crosscheck archivelog all ;
catalog의 COMPATIBLE 파라미터가 8.1.5이하로 설정되어 있으면 RMAN은 찾을 수 없는
모든 archived log의 status를 "DELETED" 로 셋팅한다. 만약에 COMPATIBLE이 8.1.6이상으로
설정되어 있으면 RMAN은 Repository에서 record를 삭제한다.

Very strange, I issue following command in RMAN on both primary and standby machine, but it they don't delete the 1_55_758646076.dbf, I find in v$archived_log, this "/home/oracle/app/oracle/dataguard/1_55_758646076.dbf" had already been applied.
RMAN> connect target /
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
old RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
new RMAN configuration parameters:
CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;
new RMAN configuration parameters are successfully stored
RMAN>
----------------------------------------------------------------------------------

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.

RMAN backup and restore for Disaster Recovery

Hi Guys,
I am very new to Oracle and have a question about RMAN backup and restore feature. I am simulating a disaster recovery scenario by having two VMs running oracle 11g, say hosta and hostb, hosta is sort of production db and the other a disaster recovery db (one that will be made primary when disaster occurs). My goal is to backup production db using RMAN and restore it on the other machine. For some reason when I restore the db on hostb, the command restores the previous backup but not the most recent one e.g. I took a backup yesterday (09/20) and applied it to the hostb that worked fine, but when I try to apply a fresh backup from today (09/21) it always picks up the old backup. Here's a dump of the screen:
Starting restore at 21-SEP-11
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /oracle/app/dev/oradata/forums/s
ystem01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /oracle/app/dev/oradata/forums/s
ysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /oracle/app/dev/oradata/forums/u
ndotbs01.dbf
channel ORA_DISK_1: restoring datafile 00004 to /oracle/app/dev/oradata/forums/u
sers01.dbf
channel ORA_DISK_1: reading from backup piece /oracle/app/dev/flash_recovery_are
a/FORUMS/backupset/o1_mf_nnnd0_TAG20110920T040950_77jx3zk7_.bkp
channel ORA_DISK_1: piece handle=/oracle/app/dev/flash_recovery_area/FORUMS/back
upset/o1_mf_nnnd0_TAG20110920T040950_77jx3zk7_.bkp tag=TAG20110920T040950
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:01:05
Finished restore at 21-SEP-11
Notice that it reads the backup piece from this location /oracle/app/dev/flash_recovery_are
a/FORUMS/backupset/
whereas my latest backups are stored at a different location.
I am executing following steps at the RMAN prompt on hosta and hostb:
hosta (production site)
backup as compressed backupset database plus archivelog
backup current controlfile format'/oracle/oracle_bkup/ctl_%U'
backup spfile
hostb (Disaster site)
set dbid=13732232063
startup force nomount
restore spfile to '/oracle/app/dev/product/11.2.0/dbhome_1/dbs/spfileforums.ora' from '/export/home/dev/restore_db/backupset/2011_09_21/o1_mf_nnsnf_TAG20110921T114945_77ndg9ys_.bkp'
shutdown immediate
/* create a init<db_name>.ora file with SPFILE= /oracle/app/dev/product/11.2.0/dbhome_1/dbs/spfileforums.ora */
startup force pfile='/export/home/dev/restore_db/initforums.ora' nomount
restore controlfile from '/export/home/dev/restore_db/backupset/2011_09_21/ctl_1hmn3mic_1_1'
/* restart rman here */
quit
alter database mount;
catalog start with '/export/home/dev/restore_db/backupset/2011_09_21' noprompt;
/* call the next two commands on run */
restore database;
recover database;
alter database open resetlogs
quit
Any help will be greatly appreciated.
Thanks,
Rajesh

Thanks guys, I really appreciate all your help here. I redid everything all over again to get all the information you guys wanted. Since I noticed that more eyes are looking into this I am going to reiterate my steps one more time followed by specific answers to questions. My first backup on Host B is located under ..../restore_db/backupset whereas the subsequent one is under .../restore_db/backupset/backupset2.
I take backup on Host A using:
rman target /
backup as compressed backupset database plus archivelog;
backup spfile;
quit;
I restore the backup on Host B using:
set dbid=13732232063;
startup force nomount;
restore spfile to '/oracle/app/dev/product/11.2.0/dbhome_1/dbs/spfileforums.ora' from '/export/home/dev/restore_db/backupset/o1_mf_nnsnf_TAG20110928T171830_787gbpxh_.bkp'
shutdown immediate;
startup force nomount;
restore controlfile from '/export/home/dev/restore_db/backupset/o1_mf_ncsnf_TAG20110928T171638_787gbkxn_.bkp'
quit;
/* restart rman here */
alter database mount;
catalog start with '/export/home/dev/restore_db/backupset' noprompt;
restore database;
recover database;
alter database open resetlogs;
quit;
I take another backup on Host A using (notice no spfile backup this time):
backup as compressed backupset database plus archivelog;
quit;
I restore the database on Host B using:
alter database mount;
catalog start with '/export/home/dev/restore_db/backupset/backupset2' noprompt;
recover database;
alter database open;
quit;
Output of List Backup of database (I have done this after I recovered the second time, also note that it is referring to backupset2 which is were my second backup is stored)
RMAN> list backup of database;
using target database control file instead of recovery catalog
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
89 Full 261.87M DISK 00:01:37 28-SEP-11
BP Key: 91 Status: AVAILABLE Compressed: YES Tag: TAG20110928T171638
Piece Name: /export/home/dev/restore_db/backupset/o1_mf_nnndf_TAG2011092
8T171638_787g77rx_.bkp
List of Datafiles in backup set 89
File LV Type Ckp SCN Ckp Time Name
1 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/system01.dbf
2 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/sysaux01.dbf
3 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/undotbs01.dbf
4 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/users01.dbf
BS Key Type LV Size Device Type Elapsed Time Completion Time
97 Full 259.16M DISK 00:00:00 28-SEP-11
BP Key: 100 Status: AVAILABLE Compressed: YES Tag: TAG20110928T18352
7
Piece Name: /export/home/dev/restore_db/backupset/backupset2/o1_mf_nnndf
TAG20110928T183527787lv0nb_.bkp
List of Datafiles in backup set 97
File LV Type Ckp SCN Ckp Time Name
1 Full 1816853 28-SEP-11 /oracle/app/dev/oradata/forums/system01.dbf
2 Full 1816853 28-SEP-11 /oracle/app/dev/oradata/forums/sysaux01.dbf
3 Full 1816853 28-SEP-11 /oracle/app/dev/oradata/forums/undotbs01.dbf
4 Full 1816853 28-SEP-11 /oracle/app/dev/oradata/forums/users01.dbf
Output of list backup (done after restoring the control file)
RMAN> list backup;
BS Key Size Device Type Elapsed Time Completion Time
87 89.20M DISK 00:00:26 28-SEP-11
BP Key: 87 Status: AVAILABLE Compressed: YES Tag: TAG20110928T171526
Piece Name: /oracle/app/dev/flash_recovery_area/FORUMS/backupset/2011_09
_28/o1_mf_annnn_TAG20110928T171526_787g50bm_.bkp
List of Archived Logs in backup set 87
Thrd Seq Low SCN Low Time Next SCN Next Time
1 34 1302253 20-SEP-11 1306439 20-SEP-11
1 35 1306439 20-SEP-11 1307647 20-SEP-11
1 36 1307647 20-SEP-11 1307701 20-SEP-11
1 37 1307701 20-SEP-11 1311393 20-SEP-11
1 38 1311393 20-SEP-11 1311511 20-SEP-11
1 39 1311511 20-SEP-11 1332479 20-SEP-11
1 40 1332479 20-SEP-11 1344418 20-SEP-11
1 41 1344418 20-SEP-11 1350409 20-SEP-11
1 42 1350409 20-SEP-11 1350449 20-SEP-11
1 43 1350449 20-SEP-11 1350854 21-SEP-11
1 44 1350854 21-SEP-11 1350895 21-SEP-11
1 45 1350895 21-SEP-11 1353114 21-SEP-11
1 46 1353114 21-SEP-11 1353254 21-SEP-11
1 47 1353254 21-SEP-11 1353865 21-SEP-11
1 48 1353865 21-SEP-11 1353988 21-SEP-11
1 49 1353988 21-SEP-11 1375403 21-SEP-11
1 50 1375403 21-SEP-11 1376149 21-SEP-11
1 51 1376149 21-SEP-11 1376206 21-SEP-11
1 52 1376206 21-SEP-11 1376246 21-SEP-11
1 53 1376246 21-SEP-11 1379990 21-SEP-11
1 54 1379990 21-SEP-11 1380229 21-SEP-11
1 55 1380229 21-SEP-11 1380266 21-SEP-11
1 56 1380266 21-SEP-11 1380528 21-SEP-11
1 57 1380528 21-SEP-11 1380724 21-SEP-11
1 58 1380724 21-SEP-11 1380861 21-SEP-11
1 59 1380861 21-SEP-11 1381033 21-SEP-11
1 60 1381033 21-SEP-11 1381077 21-SEP-11
1 61 1381077 21-SEP-11 1402243 22-SEP-11
1 62 1402243 22-SEP-11 1423341 22-SEP-11
1 63 1423341 22-SEP-11 1435456 22-SEP-11
1 64 1435456 22-SEP-11 1454415 23-SEP-11
1 65 1454415 23-SEP-11 1490903 23-SEP-11
1 66 1490903 23-SEP-11 1491266 23-SEP-11
1 67 1491266 23-SEP-11 1491347 23-SEP-11
1 68 1491347 23-SEP-11 1492761 23-SEP-11
1 69 1492761 23-SEP-11 1492891 23-SEP-11
1 70 1492891 23-SEP-11 1493678 23-SEP-11
1 71 1493678 23-SEP-11 1493704 23-SEP-11
1 72 1493704 23-SEP-11 1494741 23-SEP-11
1 73 1494741 23-SEP-11 1494790 23-SEP-11
1 74 1494790 23-SEP-11 1510154 23-SEP-11
1 75 1510154 23-SEP-11 1514286 23-SEP-11
1 76 1514286 23-SEP-11 1531967 24-SEP-11
1 77 1531967 24-SEP-11 1543266 24-SEP-11
1 78 1543266 24-SEP-11 1558427 24-SEP-11
1 79 1558427 24-SEP-11 1566924 24-SEP-11
1 80 1566924 24-SEP-11 1578292 24-SEP-11
1 81 1578292 24-SEP-11 1596894 25-SEP-11
BS Key Size Device Type Elapsed Time Completion Time
88 84.03M DISK 00:00:30 28-SEP-11
BP Key: 88 Status: AVAILABLE Compressed: YES Tag: TAG20110928T171526
Piece Name: /oracle/app/dev/flash_recovery_area/FORUMS/backupset/2011_09
_28/o1_mf_annnn_TAG20110928T171526_787g63s9_.bkp
List of Archived Logs in backup set 88
Thrd Seq Low SCN Low Time Next SCN Next Time
1 82 1596894 25-SEP-11 1609028 25-SEP-11
1 83 1609028 25-SEP-11 1622303 25-SEP-11
1 84 1622303 25-SEP-11 1626430 25-SEP-11
1 85 1626430 25-SEP-11 1634486 25-SEP-11
1 86 1634486 25-SEP-11 1648398 25-SEP-11
1 87 1648398 25-SEP-11 1669259 26-SEP-11
1 88 1669259 26-SEP-11 1686820 26-SEP-11
1 89 1686820 26-SEP-11 1686959 26-SEP-11
1 90 1686959 26-SEP-11 1689168 26-SEP-11
1 91 1689168 26-SEP-11 1704759 26-SEP-11
1 92 1704759 26-SEP-11 1719597 27-SEP-11
1 93 1719597 27-SEP-11 1740407 27-SEP-11
1 94 1740407 27-SEP-11 1750125 27-SEP-11
1 95 1750125 27-SEP-11 1765592 27-SEP-11
1 96 1765592 27-SEP-11 1781498 28-SEP-11
1 97 1781498 28-SEP-11 1802311 28-SEP-11
1 98 1802311 28-SEP-11 1811009 28-SEP-11
1 99 1811009 28-SEP-11 1813811 28-SEP-11
BS Key Type LV Size Device Type Elapsed Time Completion Time
89 Full 261.87M DISK 00:01:37 28-SEP-11
BP Key: 89 Status: AVAILABLE Compressed: YES Tag: TAG20110928T171638
Piece Name: /oracle/app/dev/flash_recovery_area/FORUMS/backupset/2011_09
_28/o1_mf_nnndf_TAG20110928T171638_787g77rx_.bkp
List of Datafiles in backup set 89
File LV Type Ckp SCN Ckp Time Name
1 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/system01.dbf
2 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/sysaux01.dbf
3 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/undotbs01.dbf
4 Full 1813849 28-SEP-11 /oracle/app/dev/oradata/forums/users01.dbf

Standby Database on a Source and target of different endian formats

Hi
I have a this well know case where the source server and target server are with different endian formats. I want to implement a Data guard 11g in this enviroment. How can I do to implementing having the issue of the different endian formats.
Thanks

Here is the answer.... for your learning....
Checking the Database Before Cross-Platform Database Conversion
As explained in "Basic Concepts of Cross-Platform Data Transportation", you can use the RMAN CONVERT DATABASE command to automate the copying of an entire database from one platform to another.
Before converting the database, see the list of CONVERT DATABASE command prerequisites described in Oracle Database Backup and Recovery Reference. Confirm that you meet all these prerequisites before attempting the procedure in this section.
One prerequisite is that both the source and destination platform must share the same endian format. For example, you can transport a database from Microsoft Windows to Linux for x86 (both little-endian), or from HP-UX to AIX (both big-endian), but not from HP-UX to Linux for x86 (big-endian to little-endian).
Note:
If you cannot use the CONVERT DATABASE command because the platforms do not share endian formats, then you can create a new database on a destination platform manually and transport needed tablespaces from the source database with cross-platform transportable tablespaces.

Rman repository and target

Similar Messages

Maybe you are looking for