Database Migration To ASM

Hi i am using oracle 10.2 in windows 2003 server in test environment
when i tried to migrate the database from os file system to ASM
it give me the following error
Error
Examine and correct the following error(s), then retry the operation.
Remote Operation Error - ERROR: Wrong password for user
though i have provided the correct details
thanks & regard

hi !
i tried it
but still same problem.
Error
Migrate Database To ASM: ASM Instance
Database Migrate Host asm
Logged In As SYS
An ASM instance should exist on host asm and be managed as an Enterprise Manager target. If the ASM instance already exists, add it as an Enterprise Manager target by providing connection information and clicking the Continue button. Otherwise, please use DBCA to create an ASM instance on this host before adding it as an Enterprise Manager target.
Add ASM Instance As An EM Target
* Target Name :+ASM_asm
* Oracle Home :C:\oracle\product\10.2.0\db_1
* SYS Username :sys
* SYS Password :migrate
* Role :SYSDBA
* Port :1521
* SID :+ASM
Host Credentials
Enter the credentials of the user who owns the database Oracle server installation.
* Username :administrator
* Password :pipl?123
Save as Preferred Credential
real error is
Examine and correct the following error(s), then retry the operation.
Remote Operation Error - ERROR: Wrong password for user
thanks & Regard

Similar Messages

  • Database Migration using ASM

    Hello All,
    We are using oracle database 10g on AIX. We are using asm for storage on a shared location.
    Now we want to move our database from old servers to new servers.
    I want to know if we could use the same asm based datafiles for new database to avoide database data migration. Can we switch our database from one server to another and use the same datafiles??? or we have to migrate our database by RMAN or expdp etc???

    we want to move 9 Tb database from tru64 and filesystem to solaris and asm on 10.2.0.3, we will be testing RMAN with CONVERT;
    http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/dbxptrn.htm#sthref1379
    and physical dataguard options.
    so do you have any experience with the source and the target OS different case, like source as Tru64 and destination as Solaris;
    SQL> SELECT a.platform_name, a.endian_format
      2    FROM v$transportable_platform a
      3   WHERE a.platform_id IN (2, 5)
      4  ;
    PLATFORM_NAME                                                                    ENDIAN_FORMAT
    Solaris[tm] OE (64-bit)                                                          Big
    HP Tru64 UNIX                                                                    Littleor is there any similar step by step reference like Howard's article for same OS case?
    Thank you, best regards.

  • Restore Database to non-ASM Storage - Issue with Bigfile Tablespace

    I have been testing a restore of my prod database that uses ASM (and oracle managed files) for storage to a different server and non-ASM storage. Oracle version is 10g EE. My database has one bigfile tablespace and it's datafile is about 250GB. The restore fails and it has something to do with the bigfile tablespace.
    Here is the rman restore script:
    run
    set newname for datafile 1 to '/ora01/db/ehr/system01.dbf';
    set newname for datafile 2 to '/ora01/db/ehr/undotbs01.dbf';
    set newname for datafile 3 to '/ora01/db/ehr/sysaux01.dbf';
    set newname for datafile 4 to '/ora01/db/ehr/undotbs02.dbf';
    set newname for datafile 5 to '/ora01/db/ehr/users01.dbf';
    set newname for datafile 6 to '/ora01/db/ehr/apolloaud01.dbf';
    set newname for datafile 7 to '/ora01/db/ehr/apollohist01.dbf';
    set newname for datafile 8 to '/ora01/db/ehr/apolloidx01.dbf';
    set newname for datafile 9 to '/ora01/db/ehr/apollotab01.dbf';
    set newname for datafile 10 to '/ora01/db/ehr/apollotab02.dbf';
    set newname for datafile 11 to '/ora02/db/ehr/apollolob01.dbf';
    set newname for datafile 12 to '/ora01/db/ehr/apollofdb01.dbf';
    set newname for datafile 13 to '/ora01/db/ehr/apolloidx02.dbf';
    set newname for datafile 14 to '/ora01/db/ehr/apolloidx03.dbf';
    set newname for datafile 15 to '/ora01/db/ehr/apolloaud02.dbf';
    set newname for datafile 16 to '/ora01/db/ehr/apollotab03.dbf';
    set until sequence 60298 thread 2;
    restore database;
    switch datafile all;
    recover database;
    Datafile 11 is the datafile in the bigfile tablespace. Here are the weird things about the restore:
    1. The restore output shows this:
    creating datafile fno=11 name=/ora02/db/ehr/apollolob01.dbf
    channel ORA_DISK_1: starting datafile backupset restore
    channel ORA_DISK_1: specifying datafile(s) to restore from backup set
    restoring datafile 00001 to /ora01/db/ehr/system01.dbf
    restoring datafile 00002 to /ora01/db/ehr/undotbs01.dbf
    restoring datafile 00003 to /ora01/db/ehr/sysaux01.dbf
    restoring datafile 00004 to /ora01/db/ehr/undotbs02.dbf
    restoring datafile 00005 to /ora01/db/ehr/users01.dbf
    restoring datafile 00006 to /ora01/db/ehr/apolloaud01.dbf
    restoring datafile 00007 to /ora01/db/ehr/apollohist01.dbf
    restoring datafile 00008 to /ora01/db/ehr/apolloidx01.dbf
    restoring datafile 00009 to /ora01/db/ehr/apollotab01.dbf
    restoring datafile 00010 to /ora01/db/ehr/apollotab02.dbf
    restoring datafile 00012 to /ora01/db/ehr/apollofdb01.dbf
    restoring datafile 00013 to /ora01/db/ehr/apolloidx02.dbf
    restoring datafile 00014 to /ora01/db/ehr/apolloidx03.dbf
    restoring datafile 00015 to /ora01/db/ehr/apolloaud02.dbf
    restoring datafile 00016 to /ora01/db/ehr/apollotab03.dbf
    Why at the beginning is it "creating" datafile 11? Then it doesnt even say it is "restoring" that datafile. Only restoring datafiles 1,2,3,4,5,6,7,8,9,10,12,13,14,15, and 16.
    When it creates datafile 11 it is only 26GB, that is much smaller than it should be according to v$datafile view on source prod database. Also even though it says it is creating datafile 11 as /ora02/db/ehr/apollolob01.dbf it actually creates it as an oracle managed file at /ora02/db/ehr/EHR/datafile/o1_mf_apollolo_6crxyqs2_.dbf
    After the datafiles are restored the "switch datafile all" command fails:
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of switch command at 10/18/2010 13:58:37
    ORA-19625: error identifying file /ora02/db/ehr/apollolob01.dbf
    ORA-27037: unable to obtain file status
    Linux-x86_64 Error: 2: No such file or directory
    Additional information: 3
    So my question is how do I get this database restored to non-ASM (and non omf)?

    So I tried using a different scn with my "set until scn #####" then the restore created 2 datafiles. The datafile for apollolob and apollotab02.dbf. So I think I have narrowed the problem to be that I am not using the correct scn number so RMAN can successfully restore those datafiles and recreates them instead. How do I find the correct scn to use to do a successful restore of the entire database? I have seen different methods on the web, but cant figure it out. Ive used "select archivelog_change#-1 from v$database;" and I also did "list backup of archivelog all" and used the latest sequence number. How can I find the correct scn to use so the entire database will restore?
    Here is the output of "list backup":
    List of Backup Sets
    ===================
    BS Key Size Device Type Elapsed Time Completion Time
    19724 41.12M DISK 00:00:10 14-OCT-10
    BP Key: 65840 Status: AVAILABLE Compressed: YES Tag: TAG20101014T210022
    Piece Name: /mnt/migrate/rman/EHR_dbid3632734257_set113195_piece1_copy1_20101014
    List of Archived Logs in backup set 19724
    Thrd Seq Low SCN Low Time Next SCN Next Time
    1 50439 3230234843 14-OCT-10 3230268282 14-OCT-10
    1 50440 3230268282 14-OCT-10 3230286806 14-OCT-10
    2 60280 3230234852 14-OCT-10 3230251419 14-OCT-10
    2 60281 3230251419 14-OCT-10 3230268263 14-OCT-10
    2 60282 3230268263 14-OCT-10 3230286809 14-OCT-10
    BS Key Type LV Size Device Type Elapsed Time Completion Time
    19725 Full 126.40G DISK 09:11:51 15-OCT-10
    List of Datafiles in backup set 19725
    File LV Type Ckp SCN Ckp Time Name
    1 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/system.625.609259453
    2 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/undotbs1.620.609259461
    3 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/sysaux.768.609259463
    4 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/undotbs2.632.609259467
    5 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/users.257.609259471
    6 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloaud.316.619537285
    7 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollohist.629.619538155
    8 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.312.619538169
    9 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.276.619538487
    10 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.576.619539331
    11 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollolob.570.619539593
    12 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollofdb.750.645974339
    13 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.429.651171265
    14 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloidx.705.688680793
    15 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apolloaud.747.699632315
    16 Full 3230287009 14-OCT-10 +DATA/ehr/datafile/apollotab.330.715622123
    Backup Set Copy #1 of backup set 19725
    Device Type Elapsed Time Completion Time Compressed Tag
    DISK 09:11:51 20-OCT-10 YES TAG20101014T210039
    List of Backup Pieces for backup set 19725 Copy #1
    BP Key Pc# Status Piece Name
    65851 1 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece1_copy1_20101014
    65862 2 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece2_copy1_20101014
    65873 3 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece3_copy1_20101014
    65884 4 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece4_copy1_20101014
    65895 5 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece5_copy1_20101014
    65901 6 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece6_copy1_20101014
    65902 7 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece7_copy1_20101014
    65903 8 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece8_copy1_20101014
    65904 9 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece9_copy1_20101014
    65841 10 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece10_copy1_20101014
    65842 11 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece11_copy1_20101014
    65843 12 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece12_copy1_20101014
    65844 13 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece13_copy1_20101014
    65845 14 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece14_copy1_20101014
    65846 15 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece15_copy1_20101014
    65847 16 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece16_copy1_20101014
    65848 17 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece17_copy1_20101014
    65849 18 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece18_copy1_20101014
    65850 19 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece19_copy1_20101014
    65852 20 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece20_copy1_20101014
    65853 21 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece21_copy1_20101014
    65854 22 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece22_copy1_20101015
    65855 23 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece23_copy1_20101015
    65856 24 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece24_copy1_20101015
    65857 25 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece25_copy1_20101015
    65858 26 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece26_copy1_20101015
    65859 27 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece27_copy1_20101015
    65860 28 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece28_copy1_20101015
    65861 29 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece29_copy1_20101015
    65863 30 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece30_copy1_20101015
    65864 31 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece31_copy1_20101015
    65865 32 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece32_copy1_20101015
    65866 33 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece33_copy1_20101015
    65867 34 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece34_copy1_20101015
    65868 35 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece35_copy1_20101015
    65869 36 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece36_copy1_20101015
    65870 37 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece37_copy1_20101015
    65871 38 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece38_copy1_20101015
    65872 39 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece39_copy1_20101015
    65874 40 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece40_copy1_20101015
    65875 41 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece41_copy1_20101015
    65876 42 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece42_copy1_20101015
    65877 43 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece43_copy1_20101015
    65878 44 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece44_copy1_20101015
    65879 45 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece45_copy1_20101015
    65880 46 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece46_copy1_20101015
    65881 47 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece47_copy1_20101015
    65882 48 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece48_copy1_20101015
    65883 49 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece49_copy1_20101015
    65885 50 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece50_copy1_20101015
    65886 51 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece51_copy1_20101015
    65887 52 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece52_copy1_20101015
    65888 53 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece53_copy1_20101015
    65889 54 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece54_copy1_20101015
    65890 55 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece55_copy1_20101015
    65891 56 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece56_copy1_20101015
    65892 57 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece57_copy1_20101015
    65893 58 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece58_copy1_20101015
    65894 59 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece59_copy1_20101015
    65896 60 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece60_copy1_20101015
    65897 61 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece61_copy1_20101015
    65898 62 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece62_copy1_20101015
    65899 63 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece63_copy1_20101015
    65900 64 AVAILABLE /mnt/migrate/rman/EHR_dbid3632734257_set113196_piece64_copy1_20101015
    BS Key Size Device Type Elapsed Time Completion Time
    19726 228.10M DISK 00:00:49 15-OCT-10
    BP Key: 65905 Status: AVAILABLE Compressed: YES Tag: TAG20101015T061242
    Piece Name: /mnt/migrate/rman/EHR_dbid3632734257_set113197_piece1_copy1_20101015
    List of Archived Logs in backup set 19726
    Thrd Seq Low SCN Low Time Next SCN Next Time
    1 50441 3230286806 14-OCT-10 3230331993 14-OCT-10
    1 50442 3230331993 14-OCT-10 3230401945 14-OCT-10
    1 50443 3230401945 14-OCT-10 3230469794 15-OCT-10
    1 50444 3230469794 15-OCT-10 3230555010 15-OCT-10
    1 50445 3230555010 15-OCT-10 3230618396 15-OCT-10
    1 50446 3230618396 15-OCT-10 3230695020 15-OCT-10
    2 60283 3230286809 14-OCT-10 3230304858 14-OCT-10
    2 60284 3230304858 14-OCT-10 3230330891 14-OCT-10
    2 60285 3230330891 14-OCT-10 3230354275 14-OCT-10
    2 60286 3230354275 14-OCT-10 3230366292 14-OCT-10
    2 60287 3230366292 14-OCT-10 3230399805 14-OCT-10
    2 60288 3230399805 14-OCT-10 3230423577 14-OCT-10
    2 60289 3230423577 14-OCT-10 3230446176 15-OCT-10
    2 60290 3230446176 15-OCT-10 3230469756 15-OCT-10
    2 60291 3230469756 15-OCT-10 3230496786 15-OCT-10
    2 60292 3230496786 15-OCT-10 3230524710 15-OCT-10
    2 60293 3230524710 15-OCT-10 3230554981 15-OCT-10
    2 60294 3230554981 15-OCT-10 3230583802 15-OCT-10
    2 60295 3230583802 15-OCT-10 3230610465 15-OCT-10
    2 60296 3230610465 15-OCT-10 3230617887 15-OCT-10
    2 60297 3230617887 15-OCT-10 3230673207 15-OCT-10
    2 60298 3230673207 15-OCT-10 3230695022 15-OCT-10

  • Oracle 10g RAC Database Migration from SAN to New SAN.

    Hi All,
    Our client has implemented a Two Node Oracle 10g R2 RAC on HP-UX v2. The Database is on ASM and on HP EVA 4000 SAN. The database size in around 1.2 TB.
    Now the requirement is to migrate the Database and Clusterware files to a New SAN (EVA 6400).
    SAN to SAN migration can't be done as the customer didn't get license for such storage migration.
    My immediate suggestion was to connect the New SAN and present the LUNs and add the Disks from New SAN and wait for rebalance to complete. Then drop the Old Disks which are on Old SAN. Exact Steps To Migrate ASM Diskgroups To Another SAN Without Downtime. (Doc ID 837308.1).
    Clients wants us to suggest alternate solutions as they are worried that presenting LUNs from Old SAN and New SAN at the same time may give some issues and also if re-balance fails then it may affect the database. Also they are not able to estimate the time to re-balance a 1.2 TB database across Disks from 2 different SAN. Downtime window is ony 48 hours.
    One wild suggestion was to:
    1. Connect the New SAN.
    2. Create New Diskgroups on New SAN from Oracle RAC env.
    3. Backup the Production database and restore on the same Oracle RAC servers but on New Diskgroups.
    4. Start the database from new Diskgroup location by updating the spfile/pfile
    5. Make sure everything is fine then drop the current Diskgroups from Old SAN.
    Will the above idea work in Production env? I think there is a lot of risks in doing the above.
    Customer does not have Oracle RAC on Test env so there isn't any chance of trying out any method.
    Any suggestion is appreciated.
    Rgds,
    Thiru.

    user1983888 wrote:
    Hi All,
    Our client has implemented a Two Node Oracle 10g R2 RAC on HP-UX v2. The Database is on ASM and on HP EVA 4000 SAN. The database size in around 1.2 TB.
    Now the requirement is to migrate the Database and Clusterware files to a New SAN (EVA 6400).
    SAN to SAN migration can't be done as the customer didn't get license for such storage migration.
    My immediate suggestion was to connect the New SAN and present the LUNs and add the Disks from New SAN and wait for rebalance to complete. Then drop the Old Disks which are on Old SAN. Exact Steps To Migrate ASM Diskgroups To Another SAN Without Downtime. (Doc ID 837308.1).
    Clients wants us to suggest alternate solutions as they are worried that presenting LUNs from Old SAN and New SAN at the same time may give some issues and also if re-balance fails then it may affect the database. Also they are not able to estimate the time to re-balance a 1.2 TB database across Disks from 2 different SAN. Downtime window is ony 48 hours.Adding and removing LUNs online is one of the great features of ASM. The Rebalance will be perfomed under SAN. No downtime!!!
    If your customer is not entrusting on ASM. So Oracle Support can answer all doubt.
    Any concern .. Contat Oracle Support to guide you in the best way to perform this work.
    >
    One wild suggestion was to:
    1. Connect the New SAN.
    2. Create New Diskgroups on New SAN from Oracle RAC env.
    3. Backup the Production database and restore on the same Oracle RAC servers but on New Diskgroups.
    4. Start the database from new Diskgroup location by updating the spfile/pfile
    5. Make sure everything is fine then drop the current Diskgroups from Old SAN.
    ASM Supports many Terabytes, if you need to migrate 3 Database with 20TB each using this way described above would be very laborious .. .. So add and remove Luns online is one feature that must work.
    Take the approval from Oracle support and do this work using the ASM Rebalance.
    Regards,
    Levi Pereira

  • Migrating Non ASM, Non RMAN to New Server with ASM and RMAN - Possible?

    We currently have a database ( Oracle 10g R1 ) on a Sun Solaris server that is NOT using ASM or RMAN. The database is about 300GB. We are getting a new server and we want to install Oracle 10g R2 with ASM and RMAN and migrate the database.
    I have seen the documentation on migrating non ASM to an ASM server but the methods all use RMAN. Is it possible to migrate to an ASM database without using RMAN? Would datapump import/export work if I created a new database on the new server with all the same tablespaces? Or, do I have to bite the bullet, install RMAN on the old server and do the backup?
    Thanks.

    If you're not using RMAN that doesn't mean you can't use it to perform a single backup, rman is contained in every oracle RDBMS installation version 10G or higher.
    this is only a sample of how to do it
    RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '<file_system_path>/%U.DBF';
    --first we allocate the channel default channel.
    RMAN>RUN
    ALLOCATE CHANNEL DEFAULTCHANNEL TYPE DISK;
    SHUTDOWN IMMEDIATE;
    STARTUP MOUNT;
    BACKUP DATABASE;
    SHUTDOWN
    }then once you have it, you can do what you want.
    It should also be possible to manually restore the database from the original datafiles but it's better to follow the solution involving RMAN.
    Bye Alessandro

  • RAC Migration non ASM to ASM

    Hi
    I have to perform a migration project
    of a 4node RAC cluster to new hardware,
    this RAc cluster has a 2 node DR
    The new hardware will have the same os as
    the current one .The catch is that the database is
    currently using a unix file system and it has to be
    migrated to ASM. Can some1 please guide me with best
    possible way to achieve this....any links or documentations
    appreciated....If any1 has more questions on this please let me know
    Thankyou

    Check metalink note 252219.1
    or
    http://www.oracle.com/technology/deploy/availability/pdf/MAA_WP_10gASMMigration.pdf

  • RE: Creation of two oracle database in Single ASM Disk group

    IS it possible to create two oracle database in Single ASM Disk group. if it is possible how?.
    Giri

    All you have to do is to create a tablespace at the most minimumlevel and your db would become a client of the disk group. Other than that, you can migrate your db tothe disk group and it would be then start using the same disk group shared by another database for its use also.
    HTH
    Aman....

  • Migrating to ASM

    Hi.
    I tried migrate to ASM.
    I used migrate assistant in EM.
    To migrate database files, a working directory is required to store recovery files.
    When I choose directory and click "next", I have this error:
    "Working Directory Location - 153 MB temporary free space under location D:\oracle\product\10.2.0\db_1\database is required to hold all online logs for operation recovery purpose in case of failure."
    On disk, when directory is chosen, there is 60 GB of free space.
    What's wrong?
    Thanx.
    Petr

    The disk space might be an issue. Do you have a tape device on the Linux box? Do you have enough disk space on the Solaris box for a 2nd copy of the DB?
    You may need to do this in several steps.
    1. RMAN CONVERT DATABASE
    2. Finish conversion on Linux to File System
    3. RMAN backup to tape of File System based linux db
    4. Create ASM in place vacated by File System
    5. Restore backup into ASM
    I didn't find it documented, but you may be able to shortcut the step 1 above directly to tape (assuming the tape device works on both platforms). Then it would be step 1, (2&5).

  • Migrate to ASM

    Hi all,
    I am using Oracle 10gR2 on Solaris 10.
    The size of my database is 13TB, I want to migrate to ASM.
    Following is my understanding.
    Stop Application using the DB
    Take complete backup using RMAN.
    Migrate to ASM.
    Restore backup from RMAN.
    Is it right?
    Regards.....

    Hi Tiger's Roar,
    This is the right steps:
    1 - Back up your database files as copies to the ASM disk group.
    2 - Create a copy of the SPFILE in the ASM disk group. In this example, the SPFILE for the migrated database will be stored as +DISK/spfile.
    3 - If this is standby database, stop managed recovery mode.
    4 - At this point, if you want the option of easily returning the database to non-ASM storage later, make copies of your current control file and all online logs. This command backs up the current control file to a non-ASM location:
    5 - Now create an init.ora specifying the location of the new SPFILE, and start the instance with it.
    6 - The next step is to migrate the control file to ASM.
    7 - Now specify the location of the flash recovery area by setting DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE.
    8 - Shut down and startup in NOMOUNT again, so that the changed parameters take effect.
    9 - Switch database to copy;
    10 -Recover database;
    11 - The next step is to migrate your tempfiles to ASM. You must use a SET NEWNAME command for each tempfile to direct it to ASM, then a SWITCH to make the new names take effect.
    12 - Disable logging for Flashback Database, and then re-enable it again to start creating flashback logs in the new ASM flash recovery area.
    13 - The change tracking file cannot be migrated. You can only disable change tracking, then re-enable it, specifying an ASM disk location for the change tracking file.
    14 - At this point, if the database is a primary database, then open the database.
    More details refer to:
    http://download.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmasm001.htm#i1016547
    Cheers,
    Francisco Munoz Alvarez

  • Oracle E-business suite database migrate from AIX to Linux

    Oracle 11i application database migration from single Aix instance to oracle Linux cluster RAC.
    What is the easy way to migrate?
    Migrate single instance from aix to linux cluster.
    OR
    Migrate single instance from aix to linux cluster RAC.
    We have installed oracle Linux cluster.
    Please help me which way I can go with RAC.
    Thanks
    Prince

    Migrating to a single instance will be the simplest. The migration itself will not be much different between the two because you're migrating from one platform to another. The options you have available are, the traditional IMP/EXP, datapump, and RMAN to migrate to either a standalone or RAC environment. The difficulty will be in creating a RAC environment and a little a few extra steps in the RMAN restore. Working with RAC will make things harder, but the actual migration is similar. The steps to IMP/EXP, whether it's traditional or Datapump will be no different. However, standing up a RAC database will be.

  • Configuring Standby Database from non ASM to ASM

    Hi All,
    i am trying to configure a standby database from non ASM file system to ASM file system.
    my primary database having datafiles in /u02,/u03,/u04 etc, and my Standby database having filesystem in ASM diskgroup DATA.
    can anyone of you help me in setting up of parameters db_file_name_convert and log_file_name_convert etc,;
    thanks in Advance,
    TEJAS

    Hi,
    You can check this. May it help you
    http://gavinsoorma.com/2010/04/creating-an-asm-duplicate-database-from-a-non-asm-database/

  • Logical Standby Database with 10g+ASM on both sides??

    Hi out there,
    is there a known way to establish a logical standby database on 10g, if both
    sides are running with an ASM setup?
    I've tried to create one out of a physical standby database (which is set up
    and running w/o any problems), like a book suggested me to do.
    The procedure was:
    1. switch on supplemental logging
    2. prepare initiation parameters (for archive logging etc.) on both sides for
    logical stb.
    3. shut down the phyiscal standby
    4. alter database create logical standby controlfile as '<path>'; on the
    primary, transfer the controlfile to the standby db. Here I had to use RMAN
    to copy the controlfile into the ASM System, and modify the initfile/spfile
    in order to use the controlfile. No problem so far.
    5. mount the standby database, alter database recover managed standby database
    disconnect; -> At this point, the alert log complained about non-available
    datafiles.
    6. alter database activate standby database; --> fails ("needs recovery") due
    to last point.
    The trouble is, the controlfile created at point 4 cointains wrong paths to
    the datafiles. Since I can not have the same disk group name on the standby
    system, and since ASM renames the stored datafiles by its own, the complaints
    of point 5 are comprehensible, but nevertheless annoying.
    I tried to backup a controlfile to trace and change the paths, but at after
    mounting the standby with this controlfile and proceeding at point 5, the
    system says "<path> is not a standby controlfile"
    Is there a different way of creating a "Logical Standby Database with 10g+ASM
    on both sides"? Metalink said nothing about LogStby and ASM.
    Best regards and thanks in advance,
    Martin

    I'm not sure if this will work but try:
    1. create trace control file (you did it)
    2. change paths (you did it)
    3. recrate control file (you did it)
    ... there was error occured during mount before
    so mount database (not as standby)
    4. create standby control file (from recreated control file)
    5. shutdown instance, replace control file with new standby control file or replace the control filename in parameter file.
    6. mount as standby
    What happend?
    Update: Tested on my side and it has worked fine... How about you?
    Message was edited by:
    Ivan Kartik

  • Best practice for database migration in 11g

    Hello,
    Database migration is required due to OS change.  Here, I have two database instances say A and B in the old server where RDBMS_VERSION is 11.1.0.7.0. They need to be migrated into a new OS where the oracle has been installed with version 11.2.0.2.0.
    Since all data + objects need to be migrated into the new server, I want to know what the best practice is and how to do that. Thanks in advance for your necessary guidance.
    Thanks and Regards,
    Prosenjit

    Hi Prosenjit,
    you have some options.
    1. RMAN Restore: you can restore your database via rman to the new host, and then upgrade it.
        Please follow instruction from MOS Note: RMAN Restore of Backups as Part of a Database Upgrade (Doc ID 790559.1)
    2. Data Guard: check the MOS Note: Mixed Oracle Version support with Data Guard Redo Transport Services (Doc ID 785347.1)
    3. Full Export / Import (DataPump)
    Borys

  • Problem while Pro*C compilation on Unix after 10g database migration.

    I am getting the following error while compiling Pro*C code after 10g Database migration,
    ld: 0706-006 Cannot find or open library file: -l trace10
    ld:open(): A file or directory in the path name does not exist.
    I am using a Makefile for compilation and this makes direct reference to library -ltrace10
    The $LIBPATH value is : /oracle/app/oracle/product/10.2.0/ora10gdb/lib:/usr/lib:/lib
    Please guide.
    Thanks in advance
    Kaustubh

    I am getting the following error while compiling Pro*C code after 10g Database migration,
    ld: 0706-006 Cannot find or open library file: -l trace10
    ld:open(): A file or directory in the path name does not exist.
    I am using a Makefile for compilation and this makes direct reference to library -ltrace10
    The $LIBPATH value is : /oracle/app/oracle/product/10.2.0/ora10gdb/lib:/usr/lib:/lib
    Please guide.
    Thanks in advance
    Kaustubh

  • Oracle Database Migration Verifier - Can it be used for diff table structur

    Hello,
    We have re-engineered the existing sybase tables to a new structure in Oracle for few of the tables.For example a table in sybase is normalized to two tables in oracle.In these cases can the "Oracle Database Migration Verifier" be mapped such that the columns in one table in sybase be mapped to two table is Oracle with their respective column names.
    In a gist can the tool be used even if the structure is not the same in the source and targer databases.
    Please let me know if you need more clarifications regarding my query.
    Regards,
    Ramanathan.K

    not really. The DMV was a simple tool for verifiying that what you now had in Oracle was what you had in Sybase. It does not do what you are expecting.
    B

Maybe you are looking for