not really major, still happening: the unix sysadmin who decides to clean up those pesky large logfiles on which process still have a file handle open. files gone (as seen from the sysadmin's session) but space not reclaimed... frits On Sat, Oct 10, 2009 at 10:51 AM, Howard Latham <howard.latham@xxxxxxxxx>wrote: > Rman. > > If you use rman have 2 batch jobs for each backup. > One that does crosschecks deletes etc > then a Second one that actually does the backup. > that way you can search the second log for RMAN- errors and detect when a > backup has really failed not when one > backup piece from months ago is missing or some other - while significant > not a major priority to fix. > > > > > 2009/10/10 Connor McDonald <mcdonald.connor@xxxxxxxxx> > > >> >> On Sat, Oct 10, 2009 at 2:19 AM, Jared Still <jkstill@xxxxxxxxx> wrote: >> >>> Every little bit helps. >>> Using rm * has already been dismissed as a bad idea, >>> so it would seem that rm somedir/* would also be a questionable >>> practice. >>> >>> If there's a way to screw up, all of will find it at some point. >>> >>> The idea is to mitigate the risk as much as possible. >>> >>> >>> Jared Still >>> Certifiable Oracle DBA and Part Time Perl Evangelist >>> Oracle Blog: http://jkstill.blogspot.com >>> Home Page: http://jaredstill.com >>> >>> >>> >>> On Fri, Oct 9, 2009 at 10:57 AM, Aaron Leonard <aachleon@xxxxxxxxx>wrote: >>> >>>> I'd be very wary of relying on that. It doesn't account for when you >>>> are not in the directory which contain the files your are deleting. >>>> >>>> oracle:~/adl/tmp> for i in 1 2 3 4 5 6 7; do echo 1 > file$i; done >>>> oracle:~/adl/tmp> touch -- -i >>>> oracle:~/adl/tmp> rm -f * >>>> rm: remove regular file `file1'? >>>> oracle:~/adl/tmp> rm -f * >>>> rm: remove regular file `file1'? n >>>> rm: remove regular file `file2'? n >>>> rm: remove regular file `file3'? n >>>> rm: remove regular file `file4'? n >>>> rm: remove regular file `file5'? n >>>> rm: remove regular file `file6'? n >>>> rm: remove regular file `file7'? n >>>> oracle:~/adl/tmp> n >>>> bash: n: command not found >>>> oracle:~/adl/tmp> cd .. >>>> oracle:~/adl> rm -f tmp/* >>>> oracle:~/adl> ls -l tmp >>>> total 0 >>>> oracle:~/adl> >>>> >>>> >>>> >>>> On Fri, Oct 9, 2009 at 12:44 PM, Jared Still <jkstill@xxxxxxxxx> wrote: >>>> >>>>> On Fri, Oct 9, 2009 at 10:16 AM, Fmhabash <fmhabash@xxxxxxxxx> wrote: >>>>> >>>>>> If I may add ... >>>>>> - I altered behavior of 'rm' cmd forcing it to be interactive needing >>>>>> user confirmation. Scripts coded to use non-interactive version. >>>>>> >>>>> >>>>> A trick to avoid accidentally deleting files you would rather keep. >>>>> >>>>> Create a file called '-i' in key directories. This will force rm -f to >>>>> go into interactive >>>>> mode, as the '-i' filename is interpreted as an argument. >>>>> >>>>> Create '-i' file: touch -- -i >>>>> >>>>> The double dash is used to tell rm (or any other *nix command) that >>>>> the >>>>> following stuff on the command line is not a command line option. >>>>> >>>>> Remove the file: rm -- -i >>>>> >>>>> Create a tmp directory, copy a few files into it, and try it. >>>>> >>>>> It has saved me at least once. >>>>> >>>>> >>>>> Jared Still >>>>> Certifiable Oracle DBA and Part Time Perl Evangelist >>>>> Oracle Blog: http://jkstill.blogspot.com >>>>> Home Page: http://jaredstill.com >>>>> >>>>> >>>> >>> >> >> I've already posted this in the past, but I love the approach taken at a >> client I once worked at. All production servers had a naming scheme of: >> bfc"digits" >> When I asked what "bfc" stood for... it was "be f...ing careful". They >> had adopted it in all seriousness because it >> >> a) made you pause for a chuckle every time you saw it >> b) that pause impressed the seriousness of the situation to you >> >> >> >> -- >> Connor McDonald >> =========================== >> email: connor_mcdonald@xxxxxxxxx >> web: http://www.oracledba.co.uk >> >> "Semper in excremento, sole profundum qui variat" >> > > > > -- > Howard A. Latham > > >