Showing posts with label Duplication. Show all posts
Showing posts with label Duplication. Show all posts

Wednesday, October 9, 2024

Workaround for ORA-27069 attempt to do I/O beyond the range of the file during RMAN clone from active database

This is the message I received when starting an active database duplication using RMAN:
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 10/09/2024 10:40:19
RMAN-04014: startup failed: ORA-27069: attempt to do I/O beyond the range of the file
The rman script:
connect target sys/pwd@mydb1
connect auxiliary sys/pwd@mydb2
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate auxiliary channel aux1 type disk;
allocate auxiliary channel aux2 type disk;
configure device type disk parallelism 2;
debug io;
DUPLICATE TARGET DATABASE TO mydb2
FROM ACTIVE DATABASE
USING COMPRESSED BACKUPSET;
debug off;
}
Solution:
  • Usa a pfile to start the auxiliary instance, and *not* an spfile. If you do not have one, log onto the not-yet-mounted instance and create one:
    sqlplus / as sysdba
    create spfile from pfile;
    
  • Set the environment variable export ORA_RMAN_SGA_TARGET to the same (or a little more) as the auxiliary database's total SGA:
    export ORA_RMAN_SGA_TARGET=7900
    Run the rman script again and it should proceed past the mount-stage and start restoring the files.
  • Thursday, March 17, 2022

    How to use active database duplication for creating a physical standby

    When you use active database duplication for creating a physical standby database, make sure of the following:

    1. keep your pfile used to start an auxiliary instance to a minimum. Only the following lines are needed:
    db_block_size=8192
    db_name='proddb01'
    
    Of course, the db_name must be identical to the db_name of the primary database.

    2. In your duplication script, make sure you the spfile contains a correct value for db_unique name:
    run{
            allocate channel c1 type disk;
            allocate channel c2 type disk;
            allocate channel c3 type disk;
            allocate channel c4 type disk;
            allocate auxiliary channel stby type disk;
    duplicate target database for standby from active database
    spfile
    SET db_unique_name='stby01'
    SET db_domain='mydomain.no'
    SET FAL_CLIENT='stby01'
    SET FAL_SERVER='proddb01'
    SET log_archive_dest_1='location=use_db_recovery_file_dest valid_for=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=stby01'
    SET log_archive_dest_2=''
    SET control_files='/data1/oradata/stby01/control01.ctl','/data2/fra/stby01/control02.ctl'
    SET STANDBY_FILE_MANAGEMENT='MANUAL'
    SET LOG_ARCHIVE_MAX_PROCESSES='2'
    SET local_listener='stby01.skead.no'
    SET dg_broker_config_file1='/sw/oracle/product/12201/dbs/dr1stby01.dat'
    SET dg_broker_config_file2='/sw/oracle/product/12201/dbs/dr2stby01.dat'
    SET LOG_ARCHIVE_CONFIG='DG_CONFIG=(stby01,proddb01)'
    SET diagnostic_dest='/sw/oracle'
    SET db_recovery_file_dest='/data2/fra'
    SET db_file_name_convert='/data1/oradata/proddb01','/data1/oradata/stby01'
    SET log_file_name_convert='/data3/oradata/proddb01','/data3/oradata/stby01'
    NOFILENAMECHECK;
    }
    
    Note that the directive "spfile" used right before the individual SET commands does not mean "create spfile". It means "fetch spfile from primary". The SET commands, however, will be written to your local spfile which will then be used to start the auxiliary instance once more, before the actual cloning starts.

    When the duplicaton has finished, the value of "db_name" parameter will be identical to the primary database, since we are fetching the spfile from your primary database server over the network.

    Tuesday, April 13, 2021

    How to solve "RMAN-04014: startup failed: ORA-01261: Parameter db_recovery_file_dest destination string cannot be translated" during cloning

    During an attempt to clone for active database I had created pfile with my desired value for the parameter db_recovery_file_dest, which was /fradata. Excerpt from init.ora used to start the instance (nomount):
    cat initproddb01.ora |grep db_recovery_file_dest
    
    *.db_recovery_file_dest='/fradata'
    
    This directory exists on my auxilliary server and is indeed writable by the oracle software installation owner (for most installation, this user is called "oracle") After having started the instance, and executed the clone script:
    DUPLICATE TARGET DATABASE
    FOR STANDBY
    FROM ACTIVE DATABASE
    DORECOVER
    SPFILE
    SET DB_UNIQUE_NAME='STBY01' COMMENT 'Stanby db 1'
    USING COMPRESSED BACKUPSET
    NOFILENAMECHECK;
    
    This message appears:
    RMAN-00571: ===========================================================
    RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
    RMAN-00571: ===========================================================
    RMAN-03002: failure of Duplicate Db command at 04/13/2021 08:07:31
    RMAN-05501: aborting duplication of target database
    RMAN-03015: error occurred in stored script Memory Script
    RMAN-04014: startup failed: ORA-01261: Parameter db_recovery_file_dest destination string cannot be translated
    ORA-01262: Stat failed on a file destination directory
    Linux-x86_64 Error: 2: No such file or directory
    
    Cause: The spfile that is created contains the target's db_recovery_file_dest setting, not the auxiliary's:
    strings spfileproddb01.ora | grep db_recovery_file_dest
    *.db_recovery_file_dest='/FRA' <--- this is inherited from the target database, and doesn't exist on the auxiliary server
    
    Solution: Add a new spfile directive to your clone script:
    SET DB_RECOVERY_FILE_DEST='/fradata'
    
    and rerun.