Re: safe to delete 'old' archive logs?

"Howard J. Rogers" <hjr_at_dizwell.com> wrote in message news:<40a933fc$0$31676$afc38c87_at_news.optusnet.com.au>...
> Paul Drake wrote:
>
> > "Tom" <tomNOSPAM_at_teameazyriders.com> wrote in message news:<1084787189.18929.0_at_lotis.uk.clara.net>...
> >
> >>Oracle 9.2.0.4
> >>Linux AS
> >>
> >>Hi,
> >>
> >>I have my retention policy set to 5 days, they actualy end up on tape each night as well as disk, and every couple of weeks or so i
> >>issue a delete obsolete.
>
> [snip]
>
>
> >>-rw-r----- 1 oracle oinstall 104857088 Mar 18 17:44 1_57.dbf
> >>
> >>Am i OK to just issue an rm to get rid of these or is there something more elegent?
> >>
> >>thanks
> >
> >
> > 1. oinstall is for installing software. reset the default group of the
> > oracle account to dba so that such files are created under the
> > ownership of the dba group. change the ownership of the existing
> > files.
>
> Now, I am ready to bow to superior knowledge on Linux at any stage, but
> I rather think that the group displayed for his archives depends on what
> group he specified when installing Oracle in the first place. You know,
> that screen in the installer where it says "Unix Group Name ... please
> enter a group name that will have permission to update Oracle software
> on this system"?
>
> Most people stick "dba" in there, it is true. It's not actually advised
> to do that in the 10g installation notes (they recommend "oinstall"...
> Lord knows what the 9i installation doco advises, but I would expect it
> to be vaguely similar). My web pages likewise suggest "oinstall". So it
> is quite possible, is it not, that the right group is there all along?
>
> Chowning these things would just make things all the more complicated in
> that case, surely.
>
> Regards
> HJR
Howard,

My point was to have ownership of binaries separated from ownership of database files. Binaries only need to be updated/overwritten during an install, upgrade or patchset. Separate accounts and separate groups would be better than one account and 2 groups.

This is not the least bit specific to *nix. Some of our systems (in win32) have been configured where cloning of a production database to a testing environment is common, separate accounts and groups are used that have ownership of specific database's files, so that the testing database's account can access (read) hot backup sets and archived redo logs used for cloning, but cannot access live files from the source database. it does add some complexity to properly configure filesystem permissions but it prevents errors such as where a user is logged into the wrong database, and issues a shutdown command, especially when the same server houses both prod and test. Lets just say that I only got clearance to put in such a configuration after production was shutdown by accident (by others).

Ideally such databases would reside on separate servers, but that is not always economically or politically feasible.

But if this is just a database on a laptop, its overkill.

Paul Received on Mon May 17 2004 - 21:39:48 CDT