Tablespace and datafile hot backup

Hi,
I wanted to if there is a command to copy a datafile using sqlplus command. I making a script that will backup the database while its online.I made a script for the alter tablespace begin backup but I wanted to know how to copy the datafiles without using the OS command,instead I wanted to use a sql commands. Is there any script or procedure to do this one.
thanks
Best Regards,
Antok

RMAN is the best utility to do the backup and recover activities. It take care copy and paste itself. Bellow given script is also usefull for hot backup
spool hotbackup_PROD3.sql;
set feedback off;
set verify off;
set pagesize 2500
set linesize 132
set serveroutput on size 50000;
declare
cursor tablespace is select tablespace_name from dba_tablespaces where tablespace_name
in('RBS1',
'STORAGE',
'SYSADM_IDX2',
'SYSADM_IDX3',
'SYSADM_IDX4',
'SYSTEM');
cursor datafile(tsname varchar2 ) is select file_name from dba_data_files
where tablespace_name = tsname;
begin
dbms_output.put_line('spool hotbackup_PRODc.log;');
dbms_output.put_line('alter system switch logfile;');
dbms_output.put_line('select ''log''||sequence#,sysdate from v$log where status = ''CURRENT'';
for tsname in tablespace
loop
dbms_output.put_line('alter tablespace '||tsname.tablespace_name||' begin backup;');
dbms_output.put_line('prompt Starting Backup for '||tsname.tablespace_name||' Tablespace')
for dname in datafile(tsname.tablespace_name)
loop
dbms_output.put_line('prompt Copying File '||dname.file_name||'.....');
dbms_output.put_line('!cp '||dname.file_name||' /backup2/hotbak'||dname.file_name);
end loop;
dbms_output.put_line('alter tablespace '||tsname.tablespace_name||' end backup;');
dbms_output.put_line('prompt Finished backing up '||tsname.tablespace_name||' Tablespace')
dbms_output.put_line('alter system switch logfile;');
end loop;
dbms_output.put_line('spool off;');
dbms_output.put_line('!mailx -s "KL_PROD521_HOTBACKUP1" [email protected] < /prod1/HOTBKUP/hotbackup_PRODc.log');
dbms_output.put_line('exit');
end;
spool off;
@hotbackup_PROD3.sql
exit;

Similar Messages

  • Tablespace and datafiles

    I have 3 test databases with Oracle 11.2.3 on the same box
    data.dbf and index.dbf were deleted from 2 of the databases in SQL and now EP Manager can't get to any of the tablespaces.  when clicking on Server - Tablespace i get the following error:
    java.sql.SQLException: ORA-01116: error in opening database file 2 ORA-01110: data file 2: '/u02/oradata/LAWTEST/dev_data01.dbf' ORA-27041: unable to open file IBM AIX RISC System/6000 Error: 2: No such file or directory Additional information: 3 Additional information: 4 Additional information: 4194304
    I have tried dropping the tablespaces and refreshing the database from a Prod backup but no luck and have been searching the web for any info.
    Any help would be greatly appreciated.

    Hi,
    I would like to ask where is stored in the database
    the information regarding the tablespace and
    datafiles (for example for a tablespace which
    datafiles belong?). Is it in controlfile? I think no.
    Where is it?
    Thank you,
    MihaelaHi,
    You may query DBA_TABLESPACES or V$TABLESPACE to views to gain information on tablespaces. Similarly, DBA_DATA_FILES and V$DATAFILE views will list you the details related to the data files like tablespace name/id, file location ......etc..
    Regards

  • Tablespace and Datafiles... HELP

    Hi, I3m new to Oracle, I3m trying to install Oracle 8.1.5 under
    Tru64 UNIX, I3m having a hard time creating the Tablespace and
    Datafiles to the oracle User... I cannot find documentation
    about it, can somebody here tell me how to do it????, it3s
    urgent, Please HELP mee!!!!
    null

    Hi Ruben,
    I'm an Ora admin working under NT.
    Use oracle server manager to create datafiles & tablespaces.
    You can find the executable file name for oracle server manager
    (svrmgr??.exe for NT) under BIN irectory of ORACLE HOME.
    Hope this will be tip for you.
    Regards
    Sukumar
    Ruben Gomez (guest) wrote:
    : Hi, I3m new to Oracle, I3m trying to install Oracle 8.1.5 under
    : Tru64 UNIX, I3m having a hard time creating the Tablespace and
    : Datafiles to the oracle User... I cannot find documentation
    : about it, can somebody here tell me how to do it????, it3s
    : urgent, Please HELP mee!!!!
    null

  • Tablespace or Datafile in Backup mode

    Hi,
    Can anyone explain me what happen at the background when a tablespace or a datafile is in backup mode.
    Thanks in advance
    Regards
    Aruna
    Edited by: user11144654 on May 8, 2009 3:10 AM

    The tablespace is checkpointed, the checkpoint SCN marker in the datafile headers cease to increment with checkpoints, and full images of changed DB blocks are written to the redologs.
    Those three actions are all that is required to guarantee consistency once the file is restored and recovery is applied. By freezing the checkpoint SCN in the file headers, any subsequent recovery on that backup copy of the file will know that it must commence at that SCN. Having an old SCN in the file header tells recovery that the file is an old one, and that it should look for the redolog file containing that SCN, and apply recovery starting there. Note that checkpoints to datafiles in hot backup mode are not suppressed during the backup, only the incrementing of the main checkpoint SCN flag. A “hot backup checkpoint” SCN marker in the file header continues to increment as periodic or incremental checkpoints progress normally.
    There is a confusing side effect of having the checkpoint SCN artificially frozen at an SCN earlier than the true checkpointed SCN of the datafile. In the event of a system crash or a ‘shutdown abort’ during hot backup of a tablespace, the automatic crash recovery routine at startup will think that the files for that tablespace are quite out of date, and will actually suggest the application of old archived redologs in order to bring them back into sync with the rest of the database. It is unnecessary, in this case, to heed Oracle’s suggestion. With the database started up in mount mode, simply check v$backup and v$datafile to determine which datafiles were in backup mode at the time the database crashed. For each file in backup mode, issue an ‘alter database datafile '<file name>' end backup;’ This action will update the checkpoint SCN in the file headers to be the same as the hot backup checkpoint SCN (which is a true representation of the last SCN to which the datafile is truly checkpointed. Once this action is taken, it allows normal crash recovery to proceed during the ‘alter database open;’ command.
    By initially checkpointing the datafiles that comprise the tablespace and logging full block images to redo, Oracle guarantees that any blocks changed in the datafile while in hot backup mode will also be available in the redologs in case they are ever used for a recovery.
    It is well understood by much of the Oracle user community that during hot backup mode, a greater volume of redo is generated for changes to the tablespace being backed up than when the tablespace is not in backup mode. This is the result of the logging of full images of changed blocks in these tablespaces to the redologs. Normally, Oracle logs an entry in the redologs for every change in the database, but it does not log the whole image of the database block. By logging full images of changed DB blocks to the redologs during backup mode, Oracle eliminates the possibility of the backup containing irresolvable split blocks. To understand this reasoning, you must first understand what a split block is.
    Typically, Oracle database blocks are a multiple of O/S blocks.  For instance, most Unix filesystems have a default block size of 512 bytes, while Oracle’s default block size is 2k. This means that the filesystem stores data in 512 byte chunks, while Oracle performs reads and writes in 2k chunks, or multiples thereof. While backing up a datafile, your backup script makes a copy of the datafile from the filesystem, using O/S utilities such as copy, dd, cpio, or OCOPY.  As it is making this copy, it is reading in O/S-block sized increments. If the database writer happens to be writing a DB block into the datafile at the same time that your script is reading that block’s constituent O/S blocks, your backup copy of the DB block could contain some O/S blocks from before the database performed the write, and some from after. This would be a split block.
    By logging the full block image of the changed block to the redologs, it guarantees that in the event of a recovery, any split blocks that might be in the backup copy of the datafile will be resolved by overlaying them with the full legitimate image of the block from the redologs. Upon completion of a recovery, any blocks that got copied in a split state into the backup will have been resolved through application of full block images from the redologs.

  • User hot and Rman hot backup

    During user mode hot backup lots of redo gets generated as the entire block is written when any changes are made to a block which is in hot backup mode.But during Rman hot backup less redo are generated why is this so and whatz the logic invloved? and how oracle recovers the file that has been backed up through Rman.
    Could you please explain me regarding this in detail it will be really helpful.
    kumaresh

    From Article      Note:76736.1 RMAN FAQ: Recovery Manager -- Frequently Asked
    To understand why RMAN does not require extra logging or backup mode,
    you must first understand why those features are required for non-RMAN
    online backups.
    A non-RMAN online backup consists of a non-Oracle tool, such as cp or
    dd, backing up a datafile at the same time that DBWR is updating the
    file. We can't prevent the tool from reading a particular block at the
    exact same time that DBWR is updating that block. When that happens,
    the non-Oracle tool might read a block in a half-updated state, so that
    the block which is copied to the backup media might only have been
    updated in its first half, while the second half contains older data.
    This is called a "fractured block". If this backup needs to be restored
    later, and that block needs to be recovered, recovery will fail because
    that block is not usable.
    The 'alter tablespace begin backup' command is our solution for the
    fractured block problem. When a tablespace is in backup mode, and a
    change is made to a data block, instead of logging just the changed
    bytes to the redo log, we also log a copy of the entire block image
    before the change, so that we can reconstruct this block if media
    recovery finds that this block was fractured. That block image logging
    is what causes extra redo to be generated while files are in backup
    mode.
    The reason that RMAN does not require extra logging is that it
    guarantees that it will never back up a fractured block. We can make
    that guarantee because we know the format of Oracle data blocks, and we
    verify that each block that we read is complete before we copy it to the
    backup. If we read a fractured block, we read the block again to obtain
    a complete block before backing it up. non-Oracle tools are not able to
    do the same thing because they do not know how to verify the contents of
    an Oracle data block.
    Backup mode has another effect, which is to 'freeze' the checkpoint in
    the header of the file until the file is removed from backup mode.
    We do this because we cannot guarantee that the third-party backup
    tool will copy the file header prior to copying the data blocks.
    RMAN does not need to freeze the file header checkpoint because we
    know the order in which we will read the blocks, which enables us to
    capture a known good checkpoint for the file.

  • Database Performance (Tablespaces and Datafiles)

    Hi guys!
    What's the best for performance in database, tablespace with various datafiles distribuited in diferents filesystems or tablespaces with various datafiles in only one filesystem?
    Thanks,
    Augusto

    It depends on contents of the tablespaces, tablespace level LOGGING/NOLOGGING and env such as either OLTP or OLAP and LUN presentation to the server with RAID or without RAID and SAN Read per second and write per second.
    In general, tablespace with various datafiles distribuited in diferents filesystems/LUN's is in practice for non dev/system test databases.
    Moreover using ASM is better then standard filesystems.
    Regards,
    Kamalesh

  • Drop a tablespace and datafile when database is mounted

    I tried to import data in my oracle 11g. It failed midway. I presumed that i did not size the redolog properly. Now my database cannot go beyound the mounted mode.
    ORA-01157: cannot identify/lock data file 7 – see DBWR trace file
    ORA-01110: data file 7: ‘ /data1/owprojects/xxxxx.dbf ‘
    Its a new oracle installation and i do not need the corrupt datafile.
    I cant take the tablespace offline neither can i drop the tablespace including its contents.
    Do i drop from the Linux OS. If yes which other file to i edit to remove the pointer to this tablespace.
    Thanks and Best Regards
    J

    Try:
    alter database datafile 7 offline for drop;Example:
    SQL> startup mount;
    ORACLE instance started.
    Total System Global Area 1071333376 bytes
    Fixed Size                  1388352 bytes
    Variable Size             658505920 bytes
    Database Buffers          406847488 bytes
    Redo Buffers                4591616 bytes
    Database mounted.
    SQL>
    SQL> alter database open;
    alter database open
    ERROR at line 1:
    ORA-01157: cannot identify/lock data file 5 - see DBWR trace file
    ORA-01110: data file 5: 'C:\TEMP\TEST01.DBF'
    SQL> alter database datafile 5 offline for drop;
    Database altered.
    SQL> alter database open;
    Database altered.
    SQL> archive log list;
    Database log mode              Archive Mode
    Automatic archival             Enabled
    Archive destination            USE_DB_RECOVERY_FILE_DEST
    Oldest online log sequence     396
    Next log sequence to archive   397
    Current log sequence           397
    SQL> alter tablespace test drop datafile 5;
    alter tablespace test drop datafile 5
    ERROR at line 1:
    ORA-03261: the tablespace TEST has only one file
    SQL> drop tablespace test;
    Tablespace dropped.
    SQL>Please read http://docs.oracle.com/cd/E11882_01/server.112/e25494/dfiles004.htm#ADMIN11428.
    Edited by: P. Forstmann on 19 mars 2012 18:53

  • Hot backup cloning in ebs r12

    HI i was doing the hot backup cloning in ebsr12.
    i have backed up the control files and datafiles and the trace file also.
    i have done the steps till copying the db and apps tier.
    next is
    2) Create the target database control file manually
    Open the backed up control file
    a. remove all lines before the startup nomount statement
    b. Modify the REUSE to SET
    c. Modify Source DB SID to Target SID (Here PROD to TEST)
    d. Modify NORESETLOGS TO RESETLOGS
    e. delete all lines after the CHARACTER SET statement
    i am not sure about editing the control file ....
    I am a started in db's
    can anyone help me in this?

    HI i was doing the hot backup cloning in ebsr12.
    i have backed up the control files and datafiles and the trace file also.
    i have done the steps till copying the db and apps tier.Looks like you are doing cold backup and not hot backup! Was the database cleanly shutdown before copying the database files?
    a. remove all lines before the startup nomount statementCorrect -- Or you could leave those lines if they are commented.
    b. Modify the REUSE to SETCorrect.
    c. Modify Source DB SID to Target SID (Here PROD to TEST)Correct.
    d. Modify NORESETLOGS TO RESETLOGSCorrect.
    You will also have to change ARCHIVELOG to NOARCHIVELOG -- If your source instance is in ARCHIVELOG mode.
    e. delete all lines after the CHARACTER SET statementKeep the lines/command that open the database and create the temporary tablespace.
    Thanks,
    Hussein

  • Where is the official Oracle documentation that describes Hot Backup?

    I have used the woefully inadequate Metalink search utilities and Google but the nearest thing I have found is a description on "Ask Tom".
    I am looking for the official Oracle documentation that describes what happens internally during a Hot Backup. There are a lot of web sites and blogs out there that describe it but I am looking for the description from Oracle themselves. The only things I have found in the Oracle documentation so far is how to start and stop Hot Backup but not what happens internally. Preferably 11gR2 if it makes any difference.
    Thanks in advance.

    Thanks mseberg. This is what I was looking for. I had read this manual before but apparently glossed over this paragraph:
    "When performing a user-managed online backup, you must place your datafiles into
    backup mode with the ALTER DATABASE or ALTER TABLESPACE statement with the
    BEGIN BACKUP clause. When a tablespace is in backup mode, the database writes the
    before image for an entire block to the redo stream before modifying a block. The
    database also records changes to the block in the online redo log. Backup mode also
    freezes the data file checkpoint until the file is removed from backup mode. Oracle
    Database performs this safeguard because it cannot guarantee that a third-party
    backup tool copies the file header before copying the data blocks."
    Hot backup is still quite useful and Rman doesn't cover all cases. What we are doing with it is using storage-based replication (Shadow Image) to another set of LUNS which we then mount on another server and backup using Rman. This removes the overhead of Rman on the Production Database server and extends our backup window to almost 24 hours.

  • Use of backing up a single tablespace or datafile

    Hello,
    I am reading the RMAN manual and I'm quite familiar with backup up a tablespace or datafile, but I can find very few uses for that. Backup up a tablespace is useful for TPITR, but since that needs another instance its of very little use in most production environments. I think you cannot restore an old version of tablespace in a normal database, unless the tablespace has long been made read-only, in which case RMAN's optimizations will do the trick.
    Even less use I can find for datafile backup. I have absolutely no idea what you can do with a single datafile.
    Can you please clarify me on the uses of these RMAN features?
    Thank you.

    Dear Albi!
    Think of the following scenario:
    You have a very large (let's say 1 Terabyte) production database that is split into n tablespaces. This database is in archivelog mode and a full backup of the hole database would take more than 10 hours.
    scenario end.
    In such a scenario I think you will not take a full database backup very often. Therfore you can backup portions (tablespaces and datafiles) of your database. This will take less time then a hole DBbackup.
    If you have to restore your DB then RMAN will take all the files it needs from all your backup. RMAN uses always the most actual version of your datafiles. After the restore RMAN will take the archivelogs to recover all datafiles to the most actual point in time. And that's the point why partial backups of your db are not only usefull for TSPITR.
    I hope I could make clear what the operative point is with partial backups.
    Yours sincerely
    Florian W.

  • Hot backup getting delayed everyday

    Hi All,
    Everyday our hot backup job is getting delayed by a significant time. Before the tablespaces are placed into begin backup mode we spotted the alert log flooded with the below message ,
    Mon May 21 00:23:46 2012
    Incremental checkpoint up to RBA [0x396b.3365.0], current log tail at RBA [0x396
    b.3386.0]
    Mon May 21 00:54:03 2012
    Incremental checkpoint up to RBA [0x396b.3b81.0], current log tail at RBA [0x396
    b.3b98.0]
    Mon May 21 01:24:21 2012
    Incremental checkpoint up to RBA [0x396b.495a.0], current log tail at RBA [0x396
    b.497a.0]
    Mon May 21 01:54:47 2012
    Incremental checkpoint up to RBA [0x396b.5109.0], current log tail at RBA [0x396
    b.5137.0]
    Mon May 21 02:25:13 2012
    Incremental checkpoint up to RBA [0x396b.6771.0], current log tail at RBA [0x396
    b.67b6.0]
    Also after the tablespaces are placed into begin backup mode before the end backup occurs the altert log is also flooded with the below messages,
    Incremental checkpoint up to RBA [0x396b.24107.0], current log tail at RBA [0x39
    6b.24afe.0]
    Mon May 21 05:58:39 2012
    Incremental checkpoint up to RBA [0x396b.2569e.0], current log tail at RBA [0x39
    6b.257f2.0]
    Mon May 21 06:28:56 2012
    Incremental checkpoint up to RBA [0x396b.2815a.0], current log tail at RBA [0x39
    6b.28925.0]
    Mon May 21 06:59:14 2012
    Incremental checkpoint up to .
    Then the tablespaces are placed into end backup mode resulting in significant delay.
    Please help how we can reduce the backup time and also please throw some light on these checkpoint related messages.

    Hi Jonathon ,
    Thanks for your valuable suggestion.
    Here in our environment all the tablespaces go into hot backup mode at a time instead of one by one through a script.
    Previously when the hot backup used to work fine the number of incremental checkpoints between begin backup and end backup were significantly less. It is also evident from the excerpt of the alert log file.
    alter tablespace PROAIMIS01 begin backup
    Completed: alter tablespace PROAIMIS01 begin backup
    Mon Apr 19 01:02:47 2010
    alter tablespace SYSTEM begin backup
    Completed: alter tablespace SYSTEM begin backup
    Mon Apr 19 01:02:47 2010
    alter tablespace MAPDS01 begin backup
    Completed: alter tablespace MAPDS01 begin backup
    Mon Apr 19 01:02:47 2010
    alter tablespace ADMN01 begin backup
    Completed: alter tablespace ADMN01 begin backup
    Mon Apr 19 01:02:47 2010
    alter tablespace PACESIS01 begin backup
    Completed: alter tablespace PACESIS01 begin backup
    Mon Apr 19 01:02:47 2010
    alter tablespace CTPDS01 begin backup
    Completed: alter tablespace CTPDS01 begin backup
    Mon Apr 19 01:07:47 2010
    ***Completed checkpoint up to RBA [0x1ced.2.10], SCN: 10912956469916***
    ***Mon Apr 19 01:14:13 2010***
    ***Incremental checkpoint up to RBA [0x1ced.fd.0], current log tail at RBA [0x1ced.***
    ***10a.0]***
    ***Mon Apr 19 01:44:32 2010***
    ***Incremental checkpoint up to RBA [0x1ced.73f.0], current log tail at RBA [0x1ced***
    ***.89e.0]***Mon Apr 19 01:51:58 2010*alter tablespace CTPIS01 end backup*Mon Apr 19 01:51:58 2010
    Completed: alter tablespace CTPIS01 end backup
    Mon Apr 19 01:51:58 2010
    alter tablespace MAPDS01 end backup
    Completed: alter tablespace MAPDS01 end backup
    Mon Apr 19 01:51:58 2010
    alter tablespace SYSAUX end backup
    Completed: alter tablespace SYSAUX end backup
    Mon Apr 19 01:51:58 2010
    alter tablespace AUDT01 end backup
    Completed: alter tablespace AUDT01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace PROAIMIS01 end backup
    Completed: alter tablespace PROAIMIS01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace MAPIS01 end backup
    Completed: alter tablespace MAPIS01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace UNDO01 end backup
    Completed: alter tablespace UNDO01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace USER01 end backup
    Completed: alter tablespace USER01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace PROAIMDS01 end backup
    Completed: alter tablespace PROAIMDS01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace PACESIS01 end backup
    Completed: alter tablespace PACESIS01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace XDB01 end backup
    Completed: alter tablespace XDB01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace ADMN01 end backup
    Completed: alter tablespace ADMN01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace SYMANTEC_I3_ORCL end backup
    Completed: alter tablespace SYMANTEC_I3_ORCL end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace CTPDM01 end backup
    Completed: alter tablespace CTPDM01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace PACESDS01 end backup
    Completed: alter tablespace PACESDS01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace SYSTEM end backup
    Completed: alter tablespace SYSTEM end backup
    Mon Apr 19 01:52:01 2010
    alter tablespace CTPDS01 end backup
    Completed: alter tablespace CTPDS01 end backup
    Mon Apr 19 01:52:01 2010
    alter tablespace PERF01 end backup
    Completed: alter tablespace PERF01 end backup
    Mon Apr 19 01:52:01 2010
    alter database backup controlfile to trace
    Completed: alter database backup controlfile to trace
    Mon Apr 19 01:52:01 2010
    alter database backup controlfile to '$CTLBKPDIR/$ORACLE_SID-$dt-$tm.ctl'
    Completed: alter database backup controlfile to '$CTLBKPDIR/$ORACLE_SID-$dt-$tm.
    ctl'
    Mon Apr 19 01:52:03 2010
    Beginning log switch checkpoint up to RBA [0x1cee.2.10], SCN: 10912957698129
    Thread 1 advanced to log sequence 7406
    Completed: alter tablespace PACESDS01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace SYSTEM end backup
    Completed: alter tablespace SYSTEM end backup
    Mon Apr 19 01:52:01 2010
    alter tablespace CTPDS01 end backup
    Completed: alter tablespace CTPDS01 end backup
    Mon Apr 19 01:52:01 2010
    alter tablespace PERF01 end backup
    Completed: alter tablespace PERF01 end backup
    Mon Apr 19 01:52:01 2010
    alter database backup controlfile to trace
    Completed: alter database backup controlfile to trace
    alter tablespace ADMN01 end backup
    Completed: alter tablespace ADMN01 end backup
    Completed: alter tablespace CTPDS01 begin backup
    Mon Apr 19 01:07:47 2010
    Completed checkpoint up to RBA [0x1ced.2.10], SCN: 10912956469916
    Mon Apr 19 01:14:13 2010
    Incremental checkpoint up to RBA [0x1ced.fd.0], current log tail at RBA [0x1ced.
    10a.0]
    Mon Apr 19 01:44:32 2010
    Incremental checkpoint up to RBA [0x1ced.73f.0], current log tail at RBA [0x1ced
    .89e.0]
    Mon Apr 19 01:51:58 2010
    alter tablespace CTPIS01 end backup
    Mon Apr 19 01:51:58 2010
    Completed: alter tablespace CTPIS01 end backup
    Mon Apr 19 01:51:58 2010
    alter tablespace MAPDS01 end backup
    Completed: alter tablespace MAPDS01 end backup
    Mon Apr 19 01:51:58 2010
    alter tablespace SYSAUX end backup
    Completed: alter tablespace SYSAUX end backup
    Mon Apr 19 01:51:58 2010
    alter tablespace AUDT01 end backup
    Completed: alter tablespace AUDT01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace PROAIMIS01 end backup
    Completed: alter tablespace PROAIMIS01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace MAPIS01 end backup
    Completed: alter tablespace MAPIS01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace UNDO01 end backup
    Completed: alter tablespace UNDO01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace USER01 end backup
    Completed: alter tablespace USER01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace PROAIMDS01 end backup
    Completed: alter tablespace PROAIMDS01 end backup
    Mon Apr 19 01:51:59 2010
    alter tablespace PACESIS01 end backup
    Completed: alter tablespace PACESIS01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace XDB01 end backup
    Completed: alter tablespace XDB01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace ADMN01 end backup
    Completed: alter tablespace ADMN01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace SYMANTEC_I3_ORCL end backup
    Completed: alter tablespace SYMANTEC_I3_ORCL end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace CTPDM01 end backup
    Completed: alter tablespace CTPDM01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace PACESDS01 end backup
    Completed: alter tablespace PACESDS01 end backup
    Mon Apr 19 01:52:00 2010
    alter tablespace SYSTEM end backup
    Completed: alter tablespace SYSTEM end backup
    Mon Apr 19 01:52:01 2010
    alter tablespace CTPDS01 end backup
    Completed: alter tablespace CTPDS01 end backup
    Mon Apr 19 01:52:01 2010
    alter tablespace PERF01 end backup
    Completed: alter tablespace PERF01 end backup
    But for the last couple of days the number of incremental checkpoints seem to be higher between begin backup and end backup like below,
    Incremental checkpoint up to RBA [0x396d.3129.0], current log tail at RBA [0x396
    d.366c.0]
    Tue May 22 03:14:23 2012
    Incremental checkpoint up to RBA [0x396d.147a8.0], current log tail at RBA [0x39
    6d.15ac8.0]
    Tue May 22 03:44:45 2012
    Incremental checkpoint up to RBA [0x396d.1c679.0], current log tail at RBA [0x39
    6d.1d177.0]
    Tue May 22 04:15:08 2012
    Incremental checkpoint up to RBA [0x396d.20387.0], current log tail at RBA [0x39
    6d.205dd.0]
    Tue May 22 04:45:30 2012
    Incremental checkpoint up to RBA [0x396d.20dcf.0], current log tail at RBA [0x39
    6d.2109e.0]
    Tue May 22 05:15:48 2012
    Incremental checkpoint up to RBA [0x396d.23af5.0], current log tail at RBA [0x39
    6d.23d6a.0]
    Tue May 22 05:46:05 2012
    Incremental checkpoint up to RBA [0x396d.245e3.0], current log tail at RBA [0x39
    6d.245ef.0]
    Tue May 22 05:47:08 2012
    Also the parameter log_checkpoint_interval is set to zero here.
    log_checkpoint_interval integer 0
    And the parameter fast_start_mttr_target is set to 300
    fast_start_mttr_target integer 300
    Please suggest ..

  • Why archivelog mode is mandatory for hot backups.

    Hi,
    Why the database should be put in archivelog mode when we take hot backups. What happens actually. Why can't we put in noarchivelog mode and take hot backups?

    Suppose you are not using RMAN then you must put your tablespaces in backup mode. Otherwise the backup you can take will be unrecoverable.
    In order to recover from a Hot Backup you have to do followings
    - Restore your Hot Backup
    - Recover the database - here, the archive log files are important
    How does Oracle know what has to be recovered from archivelogs?It looks at the SCN.
    If you never put your tablespaces in backup mode then SCN would not be frozen and Oracle wouldn't know what has to be recovered.
    Talip Hakan Ozturk
    http://taliphakanozturken.wordpress.com/

  • Hot backup : Rman vs. ALTER TABLESPACE...BEGIN BACKUP

    Dear Experts,
    I'm currently using the following statements
    - ALTER TABLESPACE (...) BEGIN BACKUP
    - host ocopy (...)
    - ALTER TABLESPACE (...)END BACKUP state
    I'm going for rman now but I've got 2 questions for those who did that in the past:
    1/ Will rman reduce the size of my hotbackup ?
    2/ Does the hot backup run faster using rman ?
    Thanks.
    Best Regards,
    Jerome

    1/ Will rman reduce the size of my hotbackup ? rman backup only those blocks which get accessed by oracle, means it doesn't copy the empty blocks as a part of backup as your OS copy command does. So yeah, the size of the backup will be smaller if there are huge datafiles but with comparably less data. Moreover if you are on 10g then you can use compressed backupset feature which will compress the backupsets.
    2/ Does the hot backup run faster using rman ?
    By using rman, there is no need to put every tablespace in backup mode, you can run the backup in parallel by allocating multiple channels, on 10g you can use block change tracking feature to speed up your incremental backups AND as explained in point 1 there is no need to copy the whole datafile. These all are the benefits of RMAN and I can't make a state statement that by all this the backup will run faster but will definitely go for it.
    Daljit Singh

  • What happens to Manual Tablespace Hot Backup operation,if...?

    What happens to Tablespace Hot backup operation , if one tablespace in the database is not backedup ? .
    Suppose if my database has 15 tablespaces, I have started tablespace hotbackup by using "Alter Tablespace <tblsname> Begin Backup" command & backing up one by one tablespace.
    If I don't backup one tablespace in the database, what happens to hot backup operation? Will it complete successfully or fails ?.
    Edited by: 874458 on Nov 7, 2011 8:41 PM

    I think you meant tablespace hot backup which was being used in earlier releases ?
    ALTER TABLESPACE <tablespace> BEGIN BACKUP;
    Copy/BAckup Datafiles using OS copy command
    ALTER TABLESPACE <tablespace> END BACKUP;
    In this case, nothing special happens if you have not backed up a tablespace.
    Only problem is, if you want to restore and recover the database from the backup, that tablespace, which is skipped/not backed up, cannot be restored.
    Just wait for other experts here to comment and give you more precise answers...

  • Status of datafiles during Hot backup

    Hi All Gurus,
    I have a problem. I have read different contradictory statements about what happens to data files when they are in backup mode (during hot backup). At some places it is given that after we execute the statement "ALTER TABLESPACE xxxx BEGIN BACKUP", oracle stops writing any data changes to data files so that a consistent copy can be made and for any changes during copying, It writes whole blocks of changed data to redo log fiiles. But at some other places it is given that in backup mode oracle continues to write to the datafiles just as normal, even during copying, it only freezes the datafile header's SCN.
    Now my question is that if we consider the later case, how it is possible to make a consistent copy of a file which is being changed during the copy? Which version of file will be copied? (Because file was different at the time copying started than at time the copying ends), Also if oracle keeps writing to datafiles in the backup mode then what is the benefit of putting them in the backup mode? I mean what purpose does the "ALTER TABLESPACE xxxx BEGIN BACKUP" statement serve if file is still getting changed during backup?
    Thanks,
    Amir Siddiqui.

    Ok, you are right, but if the datafile gets changes
    during backup, how can we get a consistent copy? the
    datafile's data is different at the start and end of
    copying, so the backup copy would contain some blocks
    with older data and some with new - that is, we get
    unreliable and inconsistent copy. Any idea how to
    handle this?You're right, the copy will not be consistent. But, when you go into backup mode, any time a block is modified for the first time since backup mode began, Oracle will log that entire block to redo, rather than just the change vector. When backup mode ends, Oracle writes an end of backup mode marker to the redo log stream. Now, your backup contains datafiles which are not consistent copies. But that's ok. If you ever need to use those datafiles in a recovery, you'll copy them from backup, and then, you'll apply archived redo logs. At a minimum, the archived redo from the point in time where the backup mode began (which is recorded in the frozen datafile header) until the tablespace comes out of backup mode (which will be applied from the redo log stream where the end backup marker was recorded), is required to have a valid, consistent datafile. So, the idea is, by applying all the appropriate archived redo, you'll "repair" any inconsistencies in the datafiles.
    Hope that helps,
    -Mark

Maybe you are looking for