Link to home
Create AccountLog in
Avatar of arktech
arktech

asked on

ORA-00257; want to safely clean out rman directory in Solaris clustered environment

We are getting a ORA-00257 error, which I know means no more disk space.  Sure enough, the 70GB disk is full.  Given that the entire database exports into a 245MB file, I went looking for culprits.  (This is a machine we acquired during a recent corporate acquisition, then repurposed.)  The most obvious culprit is the rman/ directory which contains five .dbf files and a snotload of log_tnnnnnnnnn_snnnn_p1 files.  In this case, "snotload" is a technical term meaning approximately 18GB worth.  The .dbf files are consuming another 22GB of disk space.  None of these files shows a date more recent than March 20th.  Obviously, I'd like to nuke these.  Here are my concerns:

1) What are these files?  If I'm not mistaken, RMAN is Oracle Replication Manager, and I'm pretty certain we're not using that (which would explain why it hasn't been touched since March 20th.)
2) This database is on a clustered Sun configuration running Solaris.  I know enough about Unix to know that if there is an open file handle on the files, removing them won't do anything until the handle is closed.  What might have these files open, and what do I need to do to make it let go?
3) Given that it's clustered, are there any other gotchas I should be aware of before I nuke these files?

Thanks!
ASKER CERTIFIED SOLUTION
Avatar of yuzh
yuzh

Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
See answer
RMAN stands for Recovery Manager. This is an application that
males easier to backup and restore the databases after crash.
So if you delete some of the fails the planned backup/recovery
strategy will be useless.  
Avatar of arktech
arktech

ASKER

Thanks for the quick feedback!  Given the guidance, we proceeded to gzip all of the files and let the system run for 24 hours to ensure that nothing failed.  It does indeed appear that these were old, leftover files from the previous Oracle database (we repurposed this machine in March).  We do not use RMAN for backup purposes.  Rather, we run a periodic exp of the entire database and back that up nightly.  (If anybody wants to continue the discussion thread, I'd be curious to know why RMAN would be preferable to exp, given that the export of the old database was about half the size of just the .dbf files generated by RMAN.)  

Again, thank you very much!  We have managed to free up 40GB on a 70GB disk, without perturbing anything.
SOLUTION
Link to home
membership
Create a free account to see this answer
Signing up is free and takes 30 seconds. No credit card required.
Avatar of arktech

ASKER

Got it, thanks!  I think we're in pretty good shape -- the database is on RAID, managed by a clustered pair of Sun servers.  The exp dump is mirrored to an off-site SAN within five minutes of completion, so it would take a pretty ugly combination of events for us to lose more than a day's worth of data with our current strategy.
Avatar of arktech

ASKER

Thank you very much!  While neither of you directly answered my questions about open file handles and related processes, yuzh gave me pointers to lots of background information -- enough to make an informed decision.  I also appreciate schwertner's simple, concise explanation of the difference between exp and RMAN, hence the point split.