Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a database server that supports a single application. Sadly much of the configuration of this box is strictly controlled by the vendor. So in the event we change things they may discontinue support.

Apparently one of their scripts has stopped running, because since June 15 we have been accumulating tons of files who's names have the following format: ARCxxxxx_xxxxxxxxxx.001 They are all basically just under 25MB. What are these files? The content is binary, they appear not to change once written (looking at the backups of this server and what's in the incrementals). Can I just delete them? They appear to be some sort of transaction logging based on the number generated when compared to our work weeks?

Vendor Support has not been forthcoming and has just told me "that shouldn't happen, the script should deal with them." But they won't tell me which script. I'm not getting error logging in the event logs. Is there an oracle log that might tell me which script is failing so I can see if I can figure out why?

Server: Windows 2003 Oracle:

share|improve this question
up vote 1 down vote accepted

The ARC* files are almost certainly Archived Redo Logs. You should not delete them as they are needed for certain kinds of recovery operations. Also, if you are using RMAN for backups it is likely that RMAN will fail if it cannot find the complete series of logs since the last backup.

Be aware that Oracle will stall if the disks get filled up with these logs. You may want to MOVE these logs to another server to free space if the disks start to get full.

RMAN backup scripts can be configured to delete these files after they have been backed up. Older style backup processes will also delete these files after the database has been backed up.

I'd start looking at how the backups are done, and see if anything is writing logs. Logging for backup procedures is unfortunately very dependent on the person that wrote the backup scripts, so we can't really help you out to much there.

You should check the general Oracle alter log for anything suspicious though.

Do you have access to the database with SQLPLUS?

If so connect to the database and run the following command It will show you where Oracle is configured to place its trace files.

SQL> show parameter background_dump_dest

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
background_dump_dest                 string      D:\oracle\admin\MyDataBase\bdump

There should be a file in this directory called 'alert_DATABASENAME.log' If you don't have SQLPLUS access to the database just search the machine for 'alert_*.log'

This file should be first place to look for any Oracle weirdness.

You will probably have to beat up on the vendor for a while to get this fixed though. When will companies learn that 'embedding' Oracle in their products is a bad idea?

share|improve this answer

They are (most likely) Archived Redo Logs. They could be needed if a recovery is required.

They are not deleted by Oracle automatically. Normally, your backup process (like RMAN) will back these up from their default location and delete them.

How is this database backed up? If you do not know, I would ask the vendor. This might be a sign that something is broke with the backup process that might leave your data vulnerable.

share|improve this answer
We're using RMAN. and it is throwing ORA-19566 Exceeded limit of 0 corrupt blocks for file xxxxxx.DBF – Laura Thomas Aug 11 '09 at 18:31
What type of objects are stored in that data file? If they are indexes, you are lucky and you can just rebuild them. Or, you can move the objects to a new tablespace and drop the existing one. This link might help:… – Angelo Marcotullio Aug 12 '09 at 1:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.