Re: Oracle Server will write continually to control files.

>
> there are none, it works the way it works. seems this would be an issue
of the
> backup software here, that is cannot backup any files on a disk where any
> activity is taking place?
>

You are correct, we tried to adjust the parameters of the backup software to the minimun. Sill the accumulated IO
from all database instance to their control files will not allow for even 1 second of quiet time. BE OFO requires at least 1 second to create a snapshot.
So I'm thinking maybe I can adjust Oracle to do this updates less often. If that fails, we'll just have to repartition and separate this more.

> Exclude the database stuff and veritas with the "open file option" should
be
> happy as a clam.
>

Again, this is for the backup of non oracle related files. Unfortenatly, BE OFO will take into account all IO to the complete drive, not just to the selected files.
If we take the files to a different drive, then we resolve this, but that requires re-partition and we are trying to prevent that, if possible.

Thanks for the feedback.

"Thomas Kyte" <tkyte_at_oracle.com> wrote in message news:115552381.00006992.037_at_drn.newsguy.com...
> In article <cs3kt30mg8_at_news3.newsguy.com>, Orlando Amador says...
> >
> >
> >"Thomas Kyte" <tkyte_at_oracle.com> wrote in message
> >news:115545437.0001662e.017_at_drn.newsguy.com...
> >> In article <cs3h0f0ja3_at_news3.newsguy.com>, Orlando Amador says...
> >> >
> >> >We have a Oralce 9.2 Standard database server with multiple database
> >> >instances. Each instance has 2 control files, although in the same
> >> >directory.
> >> >
> >> >Using a file monitor we find that the server will write a block of 8K
to
> >> >offset 24576 of the control files every 3 seconds. I wonder if this
some
> >> >kind of synchronization, locking, or heartbeat function in the
database.
> >> >The accumulated IO from the writes from a single database is not a
> >problem,
> >> >but the accumulation from multiple database is creating problem for
our
> >> >backup software (Veritas BackupExec with OFO).
> >>
> >>
> >> how is this creating a program for backup software?
> >>
> >
> >Veritas BackupExec Open File Option requires a minimun quite time.
Because
> >if the constant writes it is not able to acchive the minimun quite
window.
> >
> >>
> >> file system backups of controlfiles for open database are "not
useful" --
> >they
> >> shouldn't be touching them while the database is up.
> >>
> >
> >The have agents for performing hot backup of the data, redo, and control
> >files. That is not the issue here. There are other non-Data files on
the
> >same drive we are trying to backup.
> >
> >
> >> You aren't "backing up" your databases with this stuff are you? (if
so --
> >it is
> >> probable that you have nothing valid to restore with)...
> >>
> >
> >You are correct, we are not.
> >
> >
> >Any ideas on how to reduce the frequency of this writes?
> >
>
>
> there are none, it works the way it works. seems this would be an issue
of the
> backup software here, that is cannot backup any files on a disk where any
> activity is taking place?
>
>
> You should be excluding all DATABASE related files from this sort of
backup for
> the following reasons:
>
> a) they are useless, you cannot use them for anything
>
> b) you can actually cause the databases to shutdown. I had someone say
"my
> database goes down every morning at 3am -- why?" -- turns out every
morning at
> 3am, their backup software would come along and lock the controlfile to
"back it
> up" (well, really just copy a bunch of useless bytes to a backup device).
This
> prevents us from writing to our controlfiles -- bamm, down database
>
> c) it isn't working for you (perhaps most important of all).
>
> Exclude the database stuff and veritas with the "open file option" should
be
> happy as a clam.
>
> >>
> >>
> >>
> >>
> >> >
> >> >We figure that we can repartition this server and separate the
databases
> >in
> >> >separate disk, but we are saving that as a last resort. I was hopping
> >> >someone could point me to the reason of this updates and if there is a
> >way
> >> >to configure the timing? Maybe this is a required function but it
could
> >be
> >> >slow down a bit? This updates happens constantly, even when the
database
> >is
> >> >not in use and there is no connections.
> >> >
> >> >Any suggestions?
> >> >
> >> >11:39:33 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL01.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:33 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL02.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:37 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL01.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:37 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL02.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:40 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL01.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:40 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL02.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:43 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL01.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:43 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL02.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:46 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL01.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >11:39:46 AM oracle.exe:1128 WRITE

D:\oracle\oradata\ISODEV\CONTROL02.CTL
> >> >SUCCESS Offset: 24576 Length: 8192
> >> >
> >> >Saludos
> >> >Orlando Amador
> >> >
> >> >
> >> >
> >>
> >>
> >> --
> >> Thomas Kyte
> >> Oracle Public Sector
> >> http://asktom.oracle.com/
> >> opinions are my own and may not reflect those of Oracle Corporation
> >
> >
>
>
> --
> Thomas Kyte
> Oracle Public Sector
> http://asktom.oracle.com/
> opinions are my own and may not reflect those of Oracle Corporation
Received on Thu Jan 13 2005 - 16:42:39 CST