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!
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
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
Again, thank you very much! We have managed to free up 40GB on a 70GB disk, without perturbing anything.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
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.
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.
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.