RE: db_recovery_file_dest_size
- From: <Joel.Patterson@xxxxxxxxxxx>
- To: <mfontana@xxxxxxxxxxx>, <robertgfreeman@xxxxxxxxx>, <Brandon.Allen@xxxxxxxxxxx>
- Date: Mon, 22 Dec 2008 09:52:14 -0500
I suppose that is just something else to monitor like disk space, or
tablespace free space, or datafile size. With LMT and ASSM and auto
extend, you can trade monitoring tablespace free space, and most object
storage for flashback, (cool trade off).
I used to have set datafile sizes and monitor consecutive free space
remaining in the tablespaces. Now I let them grow and monitor how big
they get. Two completely different approaches which of course was
dictated by two completely different companies, setups, (and time
frames, ie versions of oracle).
Really something is going to run out of free space, it used to be
objects like tables extending automatically inside a tablespace, now it
is filesize approaching max file size for that blocksize.
Nifty Idea checking the flash dest size before backup to avoid
unnecessary failure. I'd say with a little awk you could determine
whether to continue? Say: find ${directory} | xargs ls -ld | awk
'{total += $5} END {print "Directory total size: " total}' (double
check before using).
P.S. if it's wrong, it is probably listing double size. Using -prune
should rein it in to the correct amount. Let me know though... :-)
Joel Patterson
Database Administrator
joel.patterson@xxxxxxxxxxx
x72546
904 727-2546
________________________________
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Fontana
Sent: Friday, December 19, 2008 5:02 PM
To: 'Robert Freeman'; 'Allen, Brandon'
Cc: oracle-l@xxxxxxxxxxxxx
Subject: RE: db_recovery_file_dest_size
________________________________
From: Robert Freeman [mailto:robertgfreeman@xxxxxxxxx]
>> but that just reinforces my point about the parameter's lack of
purpose.
>>>I disagree, the parameter has purpose. If you have a server with many
databaes on it, it serves to prevent one database from mindlessly
filling up a shared file system thus preventing all the databases
>>>from archiving and as a result bringing the whole world to a
screatching halt.
I would emphatically agree, were this universally true. However,
there's nothing forcing anyone to maintain FRAs for every database on a
server in the same location. In fact, most agree it would be a bad
practice. There's inevitably going to be a database process on ONE of
the databases that is going to generate archivelogs and fill a shared
FRA. It therefore makes the whole concept of a shared FRA a very bad
idea. Even short of using one, though, my experience in consulting is
that almost everyone, when confronted with the mandatory nature of this
parameter, will simply 'set and forget' it. As time goes by, their
database(s) grow, and they have problems with FRA. The natural
inclination is to add more space, and forget about that nuisance
parameter anyway. Eventually, a backup blows up as a result.
>>>I would agree that an option to IGNORE or some such thing would be
nice.
Maybe in Oracle 13?
Other related posts:
