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 Kumar

sunil 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 ..... ;-)

Similar Messages

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

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.

Long database response time during hot backup

Hello,
We are running Oracle 10g R2 on AIX 5.3. Our database is approximately 20G in size.
Our users are running applications which are highly sensitive to database response times. So any significant delay in database response time(say about more than 5 seconds) has serious impact on the user applications.
Everyday we take online backups using RMAN and we recently discovered that during the online backup process we are experiencing a serious performance problems at certain periods. For example a typical query which normally takes ~0.5 secods for database to respond takes about >30 seconds for several times during the process. to observe the problem more clearly we also wrote some test scripts which make random queries to the database to measure any delays in response times, and seen that we are getting late responses at several occasions(which normally never happen even when we run the script for a day without running RMAN online backup).
We have gone through IBM's whitepaper on "Tuning AIX for Oracle" and seen that there isn't any misconfiguration that would have bad impact on oracle performance on the AIX side.
Also we have gone throught the following:
http://www.oracle.com/technology/deploy/availability/pdf/rman_performance_wp.pdf
http://www.oracle.com/technology/deploy/availability/pdf/br_optimization.pdf
http://download-west.oracle.com/docs/cd/B19306_01/backup.102/b14191/rcmtunin.htm#sthref1057
We normally take our backups to tape drive. In order to test for any I/O bottlenecks we experimented by taking the backups to the disk drive. We have tried DURATION and MINIMIZE LOAD parameters, and also tried setting the RATE parameter to very low values(about 2M/s which normally reaches to about 100M/s) which resulted in total elapsed time for backups to increase from 30 mins to about 4-5 hours. And we came to find out that there is no improvement about the issue in any of these scenarios.
Also we ran the ADDM reports which claimed I/O bottleneck with about 20% impact on the system, so we tried decreasing I/O using the RATE parameter and then ADDM said "low I/O bottleneck".
Database responsiveness is a vital for our system. What measures can we take to avoid such slowness?
Thanks.

Hello,
Isn't there anything we can do about it? the application software is working almost real-time with the database and cannot tolerate long delays(with which I mean something longer than 5 seconds) due to the nature of the the system.
I wonder if there are any other methods to decrease the online backup load on the system.
Thanks for the response.
Edited by: Emrek on 13.Nis.2010 04:03

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 mode

Good 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.

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 in backup mode

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.
thanks

dbaing 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 concept

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,
007

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??? 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 INFORMATION

Hi,
Please provide the information for hot bakup mode
during begin backup mode what happend internally.
Regards,
satish.

892630 wrote:
Hi,
Please provide the information for hot bakup mode
during begin backup mode what happend internally.
Regards,
satish.What would happen internally where I work is that the senior dba would instruct the junior dba on the proper use of rman, which replaced the need of 'begin backup' in the last millenium.

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.com

A 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.

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 ..

DB Taken out of Backup Mode During User-Managed Backup

I was taking a user-managed backup and the DB was accidentally taken out of backup mode in the middle of the backup. The backup continued and backed up all the datafiles, but many of the datafiles were backed up after backup mode was turned off. Can I restore the DB using this backup? What are my options?

The backup might be usable and it might not. When you put a tablespace (actually all data files in the tablespace) into backup mode, Oracle continues to perform writes to those data files. However, when first modifying a block in a data file after it has been put in backup mode, Oracle will put a before image of that entire block in the redo log (instead of just the row changes). After this first data block change is written to the redo log, further changes to this data block are written as just normal. Oracle does this initial write of the whole block to prevent fractured blocks during recovery. You see, when the OS copies the files for backup, it copies in chunks that might, or might not, fall on a data block boundary. A data block may be updated on disk between two OS file copy chunks. Thus when the file is restored it is possible that part of a data block will have new data and another part have old. This is a fractured block. When applying undo, Oracle first lays down a full block, which will cure a possible fractured block, and then apply redo as normal to complete the recovery operation.
This is why it is important to make sure that your hot backup set includes all redo generated between the time you put the tablespaces in backup mode and the time you took them out of backup mode.

Is there a way to improve computer performance during TM backup?

I have a MacBook Pro 2.4GHz Intel Core 2 Duo with 2GB of RAM running 10.5.7 and every time Time Machine starts a backup (about once an hour) my computer becomes unresponsive. I can't type, copy, paste, switch applications without a huge hang up. For example, it took me a total of 7 minutes to get to this thread because Time Machine started a backup and I was stuck in the Finder trying to switch to Safari. Once Safari finally showed up, I got a beach ball.
When TM isn't running, my computer is restored to a responsive state.
I love using Time Machine, because it's a great way to backup everything. Short of turning it off, is there anything else I can do to prevent my computer from going in to lockdown once an hour?
I'm backing up wirelessly to a MyBook USB drive btw.

Just an update to those who may stumble across this thread.
This issue has not been solved. In fact, I could say it's gotten much much worse. It seems that I can't type, copy/paste or perform even the most basic of tasks while a backup is in progress.
I've downloaded the Time Machine Backup Widget, and it shows a few oddities that may/may not be significant. On one particular day the log shows a request for 1.3GB and then for the next backup (1 hour later) a request for another 2GB in size. Each of the hourly backups seemed to be of similar size requests for that day. What's unusual is that for that particular day, I wasn't really working on anything of significant size at all. I'm a web developer, so I may modify a 1MB file throughout the day, for several hours, but I'm no where near generating modifications that would equate to 8GB a day. My first thought was that Time Machine might be swapping out a weekly/monthly backup at that time - but then the same requests seem to be coming the following three days. Does it take Time Machine that long to perform a weekly backup?
At Time Machine's current rate, my hard drive is filling up pretty fast. To the tune of 8GB a day. The logs seem to also indicate that Time Machine is only copying 2.1MB a day. Again, that falls in line with what I would expect with my activity, but the hard drive seems to be dedicating the "requested" rather than the (smaller) copied amount indicated in the log files.
Backup frequency also seems to be higher than normal on some days. Today, for example, Time Machine has been backing up about once every 20 minutes or so. Right now, I'm on a backup, at various times my typing has been affected and according to the backup status it has been backing up 2.4MB of 2.5MB for the past 22 minutes. It just barely finishes and then it starts right back up again.
I've kept Activity monitor running for the past couple of weeks and as suspected, my CPU reaches maximum capacity and my disk activity goes through the roof during a backup. My external wireless mouse and anything connected to my computer seems to become unresponsive. The trackpad and keyboard go next. Then - typically - I see the beach ball and I know I'm up for an unscheduled computer break. This is most annoying when I'm trying to type an email and a backup kicks in just before I have a chance to click send. One time it took me 10 minutes for my click to be recognized and an email could be queued to send. It took another 3 full minutes for the email to actually go out.
For me, backups are essential. I have resisted turning this feature off, simply because I spent so much money to get it all to work (upgraded OS, purchased a new router and a new backup HD).
I hope Apple releases more control over the backup features and the backup frequency. I'd love to see an option to have backups happen only when CPU cycles are at idle for a few minutes, which would indicate that the user isn't on the computer. Or perhaps give users the ability to set a less aggressive backup schedule, perhaps every four hours or so, rather than the aggressive hourly backups I'm stuck with now.
Time Machine's current status: "finishing backup." has been it's status for at least 10 minutes, that combined with the outlandish 45 minute time it took to copy 2.5MB of data means I have just 5 minutes before my next backup is scheduled to start. There has to be a better way.

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).

Performance effect during HOT backup mode

Similar Messages

Maybe you are looking for