RE: ORA-00230 during RMAN backup
- From: "Crisler, Jon" <Jon.Crisler@xxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 28 Sep 2007 15:34:51 -0400
Although we have seen increased CPU time for compressed backup sets, it
has not been a problem, and the reduced file sizes are worth the
expense. My testing shows that overall RMAN compression seems similar
to a gzip -6 on the same files. Most of these backups occur on systems
with 4 or more CPU's, so the extra cpu time is not an issue, especially
for off-hours backups.
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Jack van Zanen
Sent: Thursday, September 27, 2007 7:24 AM
To: 'Ian Cary'
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: ORA-00230 during RMAN backup
Hi All,
Found the problem (most likely)
Since the problem happened when I was nowhere near a PC I was too late
to
find out which program had the lock. This morning I asked my colleagues,
and
around the time of failure my colleague was registering this database in
the
newly created catalog (now it's controlfile) but the registering was
hanging. I can only assume (w/o testing it) that this caused the problem
,
as it was the only other thing happening around the time.
I ran some tests today on compressed backups and was very impressed that
on
our UAT environment *pretty close to production) we got about a 8x
reduction
in backup size. Since we had severe I/O problems on this system today as
well the compressed backup finished quicker than the normal backup,
which is
not what I expected.
I also tried to restore just for good measure and that worked too.
We did notice quite a big difference in CPU load on the system where
compressing obviously needs CPU.
Anyone found the increased CPU load a problem in their environment?
Brgds
jack
-----Oorspronkelijk bericht-----
Van: Ian Cary [mailto:Ian.Cary@xxxxxxxxxxxxxx]
Verzonden: Wednesday, September 26, 2007 11:21 PM
Aan: jack@xxxxxxxxxxxx
CC: oracle-l@xxxxxxxxxxxxx; oracle-l-bounce@xxxxxxxxxxxxx
Onderwerp: Re: ORA-00230 during RMAN backup
The most common reason I've seen for this is having two rman processes
running simultaneously against the same database - you didn't happen to
have a scheduled backup running at the same time did you?
The 10g compressed backupsets work fine and we are seeing files about
1/8th
of their previous size. Unfortunately despite the I/O reduction the
elapsed
times have hardly reduced as our cpu's don't seem to be able the
compression too well.
Cheers,
Ian
|---------+----------------------------->
| | jack@xxxxxxxxxxxx |
| | Sent by: |
| | oracle-l-bounce@fr|
| | eelists.org |
| | |
| | |
| | 26/09/2007 12:15 |
| | Please respond to |
| | jack |
| | |
|---------+----------------------------->
>-----------------------------------------------------------------------
----
-----------------------------------|
|
|
| To: oracle-l@xxxxxxxxxxxxx
|
| cc:
|
| Subject: ORA-00230 during RMAN backup
|
>-----------------------------------------------------------------------
----
-----------------------------------|
Hi All,
I'm doing an RMAN backup that includes automatic backup of controlfile.
The script has been working fine sofar but today I got this ORA message.
I looked up the message and basically it means that another process has
a
lock on the controlfile while RMAN tries to back it up.
Now I did check what other processes are suppose to be running at that
time
and there is just no other processes around the time that I got this
message. There is not even a lot of activity on the database causing
excessive log switching or anything.
Backup script:
Run
{
Delete noprompt backup;
Backup database format 'OraBackups/application/DB_%d_%U';
Backup archivelog all format 'OraBackups/application/AL_d%_%U' delete
all
input;
}
We do not back up to tape directly.
Configured:
Controlfile autobackup on
Controlfile autobackup format ??
Default device type disk
Device type disk parallelism 10 backup type to backupset
Snapshot controlfile name to '???'
These scripts are leftover from previous DBA and will be changed after I
have convinced the powers that be that we are better off with backup
database plus archivelogs. Hopefully next week.
The deletes are needed as there is a shortage of backup space on disk so
we
can not hold 2 days worth of backups on disk.
We are going to be testing compressed backups (10G) any bad experience
with
it?
Brgds
Jack
This email was received from the INTERNET and scanned by the Government
Secure Intranet Anti-Virus service supplied by Cable&Wireless in
partnership with MessageLabs. (CCTM Certificate Number 2006/04/0007.) In
case of problems, please call your organisation's IT Helpdesk.
Communications via the GSi may be automatically logged, monitored and/or
recorded for legal purposes.
For the latest data on the economy and society consult National
Statistics
at http://www.statistics.gov.uk
************************************************************************
****
*****
Please Note: Incoming and outgoing email messages are routinely
monitored
for compliance with our policy on the use of electronic communications
************************************************************************
****
*****
Legal Disclaimer : Any views expressed by the sender of this message
are
not necessarily those of the Office for National Statistics
************************************************************************
****
*****
The original of this email was scanned for viruses by the Government
Secure
Intranet Anti-Virus service supplied by Cable&Wireless in partnership
with
MessageLabs. (CCTM Certificate Number 2006/04/0007.) On leaving the GSi
this
email was certified virus free.
Communications via the GSi may be automatically logged, monitored and/or
recorded for legal purposes.
--
//www.freelists.org/webpage/oracle-l
--
//www.freelists.org/webpage/oracle-l
Other related posts:
