Blocking session in hot backup mode?
In 8.1.7.4 Some time While in hot backup mode, blocking session occuring by checkpoint session background process. Can we issue the alter system checkpoint command in this
Situation ? how to handle this?
best way is to try and see but checkpointing frequently wont help in my opinion, a better workaround may be ensuring you only place one tablepspace at a time in backup mode and bring the tablespace out of backup mode as soon as you have backed it up.
Similar Messages
-
Performance effect during HOT backup mode
Dear Experts,
Oracle 10gR2, Windows Server 2003 ,I.4TB database size
Our backup team put database in hot backup mode (alter tablespace begin......).
Is it cause some performance issue in the database ?
Thanks & Regards
Sunil Kumarsunil kumar wrote:
Dear Aman,
As I told you I just joined and same thing I told to upper level, I need some definite proof so that I can prove my point because it always happens here: Database always put in hot backup mode and application here went very slow. I am a new DBA, so I need some some proof(what kind I don't know :)
Aman, hot backup with RMAN is more preferable as compare to alter tablespace begin backup...... command.
Why ?
and if so why we still using OS commands to take backup;
Thanks & Regards
Sunil Kumar
:)You have the answers to your other questions. As to "why we still using OS commands to take backup"? Well, um..... ;-) You'd have to ask you're organization that question. I can tell you there is no defensible reason to do so ..... ;-) -
The Consequences of putting a tablespace into Hot Backup mode--Link to Doc
http://www.dizwell.com/prod/node/10
This article will help beginners who want to know what exactly happens when the Tablespace is put in Backup modeGood point.
If we only know Enterprise Manager, we will be stuck when confronted with a telnet session. In like manner, if we only know RMAN, we will never know half of why it is so useful and efficient.
Besides which, there is a lot of use for manual recovery techniques, even in a world of RMAN doing all the backups, so knowing the entire backup/recovery universe is a Good Thing. -
How to take a Hot backup of Oracle database
1: put the db in archive log mode
2: set the db_sid to correct one
3: login to sqlplus
4: verify the name of the db that you are connected to
select name from v$database;
5: check if the db is in archive log made
select log_mode from v$database;
if not in archive log mode
another command to check
archive log list;
6: find where on disk oracle writes archive log when it is in archive log mode
sql> show parameter log_archive_dest_1;
if the value is found to be 0, that means no values will be recorded, so we need to change it
sql> alter system set log_archive_dest_1='LOCATION=c:\database\oradata\finance\archived_logs\'
scope=spfile;
7: shutdown immediate; < this is done just to prepare the db for hot backups >
8: startup the db in mount mode
startup mount;
( 3 startup types : nomount - just starts the instance, mount - locates the control files and open up according to the values, open - finds the datafiles from the control files and opens up the db )
9: put the db in archive log mode
alter database archivelog;
10: open the database
alter database open;
11: check the status of the db
select log_mode from v$database;
SQL> archive log list;
12: create a directory for archived log
check if its empty, if empty we need to switch
sql> alter system archive log current;
run it 5 times < need to put / and enter > , then check the archive log dir , we will find files
13: make a table in the database and insert data in it
create table employees (fname varchar(2));
check the table
desc employees;
insert values
insert into employees values ('Mica');
14: tablespace must be in hot backup mode
check the status
select * from v$backup;
if found not active, then we need to change
we cannot put the db in hot backup mode, unless it is archive log mode
change to hot backup mode
alter database begin backup;
check the status
select * from v$backup;
15: now we can only COPY DBF FILES
copy *dbf <distination location>
16: need to take the db out to hot backup mode
alter database end backup;
17: need to make another archive log switch
alter system archive log current;
18: need to copy control files now, need to do a binary bckup
alter database backup controlfile to '<location>\controlbackup';
19: insert more values to the table
insert into employess values ('NASH')
COMMIT;
make another archive log switch : alter system archive log current;
do the same process for more values
20 : backup all the archive logs to a new location
21: shutdown the db and simulate a hw error, delete all the files from the database folder
22: try to start the sqlplus and db ::: error
23: copy all the backups to the db dir
need to copy the control files, rename the binary backup of the control file and make the copies as needed
24: try to mount the db, error < must use reset logs or noreset logs >
25: need to do a recovering of the database
shutdown
restore the archive logs
startup mount;
recover database until cancel using backup controlfile;
it will ask for a log file :
yes for recovery
cancel for cancelling recovery
26: check status: open the database in readonly
alter database open read only;
check the tables to see the data
shutdown immediate
shartup mount;
recover again : recover database until cancel using backup controlfile;
if oracle is asking for a log that do nto exist , all we have to do is type cancel
27: open the database
alter database open;
need to do reset logs
alter database open resetlogs;
28: check the db that you are connected, check the tables
thanks and regards
VKN
site admin
http://www.nitrofuture.comA very long list ... let me make it shorter.
SQL> archive log list;If I see this:
Database log mode No Archive ModeI put the database into archivelog mode and leave it there forever.
If it is in archivelog mode:
RMAN> TARGET SYS/<password>@<service_name> NOCATALOG
RMAN> BACKUP DATABASE PLUS ARCHIVELOG;Though there are a lot of things one could do better such as incrementals with block change tracking, creating an RMAN catalog, etc. -
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 AMThe 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. -
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.
kumareshFrom 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. -
Hi Guys,
If I put my database in backup mode and perform the backup (hotbackup/online) of the database.
When I need to do restoration, do I need any archive logs at all? (not necessary to recover up to point in time) Can i just restore the datafiles and do a alter database open resetlogs?
Will the database be inconsistent and can't startup without applying any archive logs at all? as the datatabase is not shutdown when doing the backup.
thanksdbaing wrote:
Hi Guys,
If I put my database in backup mode and perform the backup (hotbackup/online) of the database.
When I need to do restoration, do I need any archive logs at all? (not necessary to recover up to point in time) Can i just restore the datafiles and do a alter database open resetlogs?Yes, even if you won't be required to do an point in time recovery, you need the archive logs to make the database consistent which it won't be in a hot backup mode.
Will the database be inconsistent and can't startup without applying any archive logs at all? as the datatabase is not shutdown when doing the backup.Yep.
That said, use RMAN to do the same thing. It would be much better to use it than using the backup mode .
HTH
Aman.... -
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 .. -
Hi,
i have a doubt in hot backup concept. when we perform hot backup and put the tablespace in begin backup mode the headers are freezed and all the entries for the headers are stored in redlogs. My doubt is if the redolog is archieved will the database applies the entries from archived log on the headers after end backup mode of tablespace???
Regards,
007Hi,
i have a doubt in hot backup concept. when we perform hot backup and put the tablespace in begin backup mode the headers are freezed and all the entries for the headers are stored in redlogs. My doubt is if the redolog is archieved will the database applies the entries from archived log on the headers after end backup mode of tablespace??? Putting a tablespace INTO hot backup mode does indeed cause a checkpoint to take place for that tablespace. But when the tablespace is out of hot backup mode does NOT. The SCNs in the headers of that tablespace will re-synchronize next time there is a system-wide checkpoint, but not until then.
Refer to thread : User managed hot backup
where HJR provided the demo.
- Pavan Kumar N
Edited by: Pavan Kumar on Jul 6, 2011 12:48 AM -
Hot backup on NOARCHIVELOG mode?
DB version:10gR2, 11G
Why is it not possible to do a Hot Backup in NOARCHIVELOG mode? What role does archived redo log files have in a Hot backup?Because it takes more than zero seconds to backup a database.
Say your database consists of 1 single datafile of 10MB. This datafile, at the OS filesystem level, consists of 2,560 blocks of 4KB each.
If you start a backup of the datafile, the OS utility (tar, cp, cpio, whatever command) reads the first 4KB block and copies it out. It then, after a certain time, reads the next block. And so on till it gets to the last block of the file.
However, since the database is "open" transactions may have updated blocks in the datafile.
Therefore, at time t0, block 1 may have been copied out. At time t5, block 128 may have been copied out. At time t32, block 400 may have been copied out. Unfortunately, some user may have updated block 1 at time t3 and block 128 at time t8.
What would happen if these blocks, having been copied out at different times were restored ? They would be inconsistent !!
It is the ArchiveLog mechanism that allows Oracle to know that a datafile was "active" when it was being backed up. Oracle has to "re-play" all changes that occurred on the datafile from the time the datafile backup began (at t0) till it ended (at the 2,560th block). -
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/ -
Why we cannot take hot backup if database is in noarchive log mode
Hi,
I am aware that if database is in noarchive log mode, we cannot take hot backups and only cold backup is possible.
I would like to know the technical reason behind this restriction?
Thank You
SarayuHot backups are fuzzy backups, inconsistent, in other words, since something is always happening in the database. When you recover, you restore data files and then apply redo to make the transactions consistent. You can do a complete recovery or recover to a point in time. So where does the redo come from? That's what we call archiving redo logs. When the online redo gets full, it gets archived.
In the case of an instance crash, the redo is there in the online redo logs, so Oracle can recover automatically. Anything beyond that, having to do with storage media, is a media recovery, and requires those archived logs. So unless you have some other way to get your data back, always run in archivelog mode.
It is really important to understand the concepts. Please read the docs.
http://docs.oracle.com/cd/E11882_01/server.112/e25789/cncptdba.htm#CNCPT031
http://docs.oracle.com/cd/E11882_01/backup.112/e10642/rcmintro.htm#i1005488
It may be worth your while to get a third party backup and recovery book too. -
Hi all,
i have a question related to hot backup
If we take a hot backup ie. alter tablespace tbs begin backup....then it freezed the datafile and all the entries happen to the redo log files.....if we a two log groups and and hot backup happens to continue from BOD(beginning of day) to EOD,then there might be a situation in which log switch happen it means it will archive the same,so how the datafile will recover the same...
here it freezed the whole datafile or only datafile header.....user00726 wrote:
Hi all,
i have a question related to hot backup
If we take a hot backup ie. alter tablespace tbs begin backup....then it freezed the datafile and all the entries happen to the redo log files.....if we a two log groups and and hot backup happens to continue from BOD(beginning of day) to EOD,then there might be a situation in which log switch happen it means it will archive the same,so how the datafile will recover the same...
here it freezed the whole datafile or only datafile header.....The crux of the hot backup done via manual cp command is that datafile is completely operational. So all the objects which can undergo changes like tables and all , they keep on working as like they used to do without the back up is on. As all the changed vectors are logged in the redo log files , so the same is true in this case also when the datafile goes into the backup mode. Oracle just freezes the header of teh datafile and freezes the SCN at that point for it to know where to start the recovery from in the order of a crash. When the file is put into the backup mode, the header is freezed and the checkpoint is done before putting the file into the backup mode. Makes sense as with the checkpointing , the related buffers for that file are put into the file , ensuring that the file now is a self consistent file.
There is no checkpoint that happens with the end backup though. The file is made in sync with the rest of the database files when the next full, system level checkopint will happen. All the changes required to make the file get in sync with the rest of the database is already logged in teh redo and archived files. So in the case of a crash, oracle just applies those to the respective file and the recovery is complete. So there won't be any impact on the recovery. Just there is one issue that there would be extra redo generation due to the first time logging of the whole data block in the redo stream to avoid the fractured block issue.
HTH
Aman.... -
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. -
Dataguard setup using hot backup files
Hello,
I am planning to setup dataguard using Hot backup (Not RMAN) files from the primary instance. I have a few doubt as, How shall I recover the Standby database using the archive files generated while taking hot backup of primary? Shall I directly execute the "alter database recover managed standby database" command? Will this command take care of the archives generated durring hot backup also?
Appreciate any help on the above.
DB Version:10.2.0.4
Regards.Guys by using below procedure you can rebuild your data gurad by using manual hot backup.
1) On the primary database, defer the archival of redo data .
ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=DEFER;
2)
put primary database in backup mode
copy all the datafiles from primary database to Standby database (you can copy to other location in primary server and tar&zip it and send it to stand by and unzip and untar there)
Once you copy the datafiles to another location on primary server,you can use below command for tar and zip
go to the copied datafiles location and issue below command
tar cvf - .|gzip -c > /dump/backup/drdb_backup.tar.gz
put primary database in end backup.
3) create stabdby controlfile by using below command and send it to standby server
alter database create standby controlfile as '/dump/drbackup/2standby.ctl'
4) copy all generated archive logs (from the time of database begin abckup) from primary database server to standby database log_archive_dest location.
5) on standby database once we placed all datafiles and controlfiles in place use below commands
export ORACLE_SID=standbydb
SQL> starup nomount;
SQL> alter database mount standby database;
SQL> recover standby database;
--AUTO
SQL> alter database open read only;
SQL> shut immediate
SQL> startup nomount;
SQL> alter database mount standby database;
SQL> alter database open read only;
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
6) On the primary database, issue the following statement to reenable archiving to the physical standby database:
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_2=ENABLE;
Thanks & Regards,
Satish Kumar Sadhu.
Edited by: Satish Kumar Sadhu on Apr 10, 2013 11:05 PM
Maybe you are looking for
-
so a while back i transfered my old computer files to my new computer and when i did that i tried getting my firefox books marks added when i did it it just made a file old firefox data. i went into it it has the books marks but the problem is it isn
-
Month View - all days have dots
Dear all, I just synced my iphone 3g calendar with Microsoft Outlook Calendar. the problem is that in the Month View of the Iphone 3g calendar, all days have dots including those days that do not have calendar entries. Is there a way to fix this? Tha
-
Unable to View Rendered Stills in Canvas / in QT
Hello, I've read through a variety of related threads on this and the usual RGB / Alpha type tricks have no effect. I'm basically using the Motion panel to create a Ken Burns type effect, and have keyframed everything out and dropped the images into
-
Need help for QCI ASTM routines
Hello Friends, Presently I am setting up the QCI config in our test server. I have configured the necessary settings for the Conversion group and the reading group. Now when I am testing the results using the O3QCITEST transaction, I am getting an er
-
HT1918 About the authorization hold on credit card, what if mine is a debit card?
About the authorization hold on credit card, but mine is a debit card and the bank informed me that they have already charged my bank account. What should I do? Will I receive the money back?