Using Standby for cloning
DBAsupport.com Forums - Powered by vBulletin
Page 1 of 4 123 ... LastLast
Results 1 to 10 of 34

Thread: Using Standby for cloning

  1. #1
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510

    Using Standby for cloning

    OracleDoc gave me a great idea (in that 'why RAC' thread) that I had not thought about. Taking my standby database and using that for creating a clone!

    What am I missing here? I shutdown the standby and scp all the files (online redo, control included) from standby box to qa box - essentially a cold backup copy, rename the instance and opening. Perhap use 9i feature to rename the database (or am i confusing the DBID?). And I'm done.

    The standby is 563.15 KMs from production and 'on the wire' with qa and dev.

  2. #2
    Join Date
    Jun 2001
    Location
    Helsinki. Finland
    Posts
    3,938

    Re: Using Standby for cloning

    Why not just use the duplicate command?
    Oracle Certified Master
    Oracle Certified Professional 6i,8i,9i,10g,11g,12c
    email: ocp_9i@yahoo.com

  3. #3
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439

    Re: Using Standby for cloning

    Originally posted by gopi
    What am I missing here? I shutdown the standby and scp all the files (online redo, control included) from standby box to qa box - essentially a cold backup copy, rename the instance and opening. Perhap use 9i feature to rename the database (or am i confusing the DBID?). And I'm done.
    You would actualy need a controlfile from your primary, not from your standby. Standby's controlfile can not be used for cloning unless you actually want to add another standby database to your DataGuard configuration (ie one primary and several standbys).

    This is also a normal method to use standby for daily backups to offload the primary - you back up databfiles on the standby site and controlfile on the primary - that makes a valid and complete backup set.
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  4. #4
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510
    Jurij,
    Due to wide area network constraints I am not using Dataguard features such as log_transport/apply. I am simply have a 'mounted standby' and i manually (with a script) transport and apply each log. So this is not failover (if it matters).

    My follow up questions are:
    1. If i use the standby control file, why can't I simply
    ALTER DATABASE OPEN RESETLOGS;
    manual open of a database mounted in standby ?

    2. In obtaining and using the production control files, do i just follow the usual clone process, such as:
    a) ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;
    b) edit it:
    CREATE CONTROLFILE REUSE set DATABASE "QA" RESETLOGS ARCHIVELOG
    - change directory names where necessary
    c) STARTUP NOMOUNT
    d) use the script in b) to rebuild the control file
    e) ALTER DATABASE OPEN RESETLOGS

    Julian...I need to purchase the Veritas MML Oracle extension in order to use rman to backup to tape (not enought disk) - my management has been warned many times. Once I have rman backups I can duplicate. thanx

  5. #5
    Join Date
    Oct 2002
    Posts
    807
    1. It's a standby controlfile. You can't issue "alter database open resetlogs" with a standby controlfile. Read documentation on how to activate a standby.
    2. That's fine. You're just creating a new controlfile. That'll do the job.

  6. #6
    Join Date
    Dec 2000
    Location
    Ljubljana, Slovenia
    Posts
    4,439
    Originally posted by gopi
    My follow up questions are:
    1. If i use the standby control file, why can't I simply
    ALTER DATABASE OPEN RESETLOGS;
    manual open of a database mounted in standby ?
    Because the standby controlfile differs from the one that is used in your primary. It has some flags set that indicate that this is not the normal controlfile but the one used with the standby database only. You can easily find some of the diferences between your primary and standby controlfiles by isuing some queries on V$views that obtain their information directly from controlfiles. For example, check the values of CONTROLFILE_TYPE and DATABASE_ROLE in V$DATABASE fromboth of your instances and you'll se the difference.

    When you open the database, the instance checks the contents of the controlfile to see if it can actualy open the database. That's why you can't mount the standby database with the "normal" controlfile, you must create standby controlfile first during standby setup. That's also why you can't open a physical standby database in read-write mode, you can only open it in read-only mode. That's also why you can put standby database in managed recovery mode while you can't do the same with the primary database. In short, the contents of the primary and standby database is not the same.

    When you use a standby controlfile you are not able to open it with or without the resetlogs, Oracle simply doesn't allow you to open the database except in read-only mode.

    Originally posted by gopi
    2. In obtaining and using the production control files, do i just follow the usual clone process, such as:
    a) ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;
    b) edit it:
    CREATE CONTROLFILE REUSE set DATABASE "QA" RESETLOGS ARCHIVELOG
    - change directory names where necessary
    c) STARTUP NOMOUNT
    d) use the script in b) to rebuild the control file
    e) ALTER DATABASE OPEN RESETLOGS
    No. You would not backup the primary controlfile to trace at all. You would:
    a) ALTER DATABASE BACKUP CONTROLFILE (create a binary backup of your controlfile on your primary)
    b) STARTUP MOUNT the cloned database with that backup copy of the primary database and the datafiles from standby datase
    c) RECOVER DATABASE USING BACKUP CONTROLFILE; (applying the needed archlogs backed up on your standby)
    d) ALTER DATABASE OPEN RESETLOGS
    Jurij Modic
    ASCII a stupid question, get a stupid ANSI
    24 hours in a day .... 24 beer in a case .... coincidence?

  7. #7
    Join Date
    Oct 2002
    Posts
    807
    If his/her standby is in-sync, step 2 is fine.

  8. #8
    Join Date
    Dec 2001
    Location
    Keene, NH
    Posts
    510
    Thank you very much for your detailed explanation!

    I've been thinking about all you said and Axr2's statement. Correct me if I'm wrong Jurij, but my way would work because this would have been the only way prior to 9.2 (to hand edit the control file and rebuild). With 9.2 the binary CF now makes sense and I will use the DBNEWID utility to change the dB name and ID.

    Axr2,
    I would love for Axr2 to define 'in sync'. In sync with what? Perform a checkpoint so that the CF and data files are the same? Or, that the last archive log from prod be applied?

    - Frank

  9. #9
    Join Date
    Oct 2002
    Posts
    807
    I don't know what your requirement is. As long as your standby has caught-up with the primary 'sufficiently' is what I meant by 'in-sync'. Be that a SCN, the last archivelog, or a point in time.

    I have some scripts that exactly do that on a daily basis. (Since I can't be bothered refreshing a database manually everyday, i prefer to script). I refresh a Test database from Production every morning. I have a standby on production. What I essentially do is exactly what you mentioned - copy standby files. Check last logs applied. Issue a 'alter datbasse bakup ctl file' production. Massage the tracefile (ctlfile) with awk/sed. Move it over, run/issue 'create ctlfile on TEST' and issue a alter database open resetlogs. It works just fine. This particular case is on a 7.3.4. No matter what version, this will work.

    PS : I need to awk/sed and move controlfiles everyday..since Prod is volatile. Lots of Datafiles are constantly added, moved around etc.
    Last edited by Axr2; 06-16-2004 at 03:19 PM.

  10. #10
    Join Date
    Oct 2002
    Posts
    807
    As for Jurij's method, it'll work - Depends if you don't mind retaining the same dbname.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Click Here to Expand Forum to Full Width