Urgent! Device containing archive logs full

[Frannie]

Hi people. Our young system was tuned some weeks ago, then the guy changed to ARCHIVELOGS mode but didn't tell us the moving files to tape strategy.
So, today the device containing archive logs has reached the 100% of space full. We stopped our application and have launched a "shutdown immediate", that hasn't currently finished...
Could you somebody give us some advices of what to do in such cases? We could perform a backup just after shutdown will finish, but don't know exactly what other actions could be necessary.
Thanks to everybody!

[Frannie]

I don't know even if the "shutdown immediate" is a good option or not... It's midnight here, so no users in the system. But I don't know what to do. Could anybody help?
Thanks a lot!

[sambavan]

After the shutdown completes, take a cold backup including the logs and then remove the archive logs that are of more than two weeks old (For the safty) then bring up the instance and make sure that it comes up. Then check the archive log number that was started after the bounce from the alert_log and then you can go ahead and remove the logs that are older than that.

Sam

[Frannie]

Thank you very much! I supposed the usual was to perform a shutdown immediate, but I even started to doubt about it, because it started from about 2 hours ago and hasn't finished. Have you got idea of what can be a "normal" time for it finishing?
Thanks again!

[Kishore]

From next time if this happens, don't hurry up to shutdown the database. Simply delete the old archive logs after taking the backup of them and you should be O.K.

[dwfink]

Your shutdown immediate is waiting for the system to rollback the changes that were not committed. In order to properly rollback, blocks will have to be written to the database. This generates redo...

Until the archivelog destination is cleared, the database will not write redo from the log buffer to the redo logs. If you look in the alert log, you should see a message about the database halted. It is not down, it is temporarily stopped, not allowing any new transactions.

The solution is to move some of the oldest archive logs off to another device, which will allow the archiver to begin working again, thus clearing the 'logjam'. Once this is done, the database will perform it's shutdown. Then you can perform your backup.

By the way, you do not need to have the database down to backup archived redo logs. They can run as an independent process.

[sambavan]

When the archive log gets filled, what the measure you too was not the correct one. My earlier suggestion to you was based upon that you have successfully shut down the system.

If it is still sitting at the shutdown, then, as Kishore suggested move some of the archive log files to the disk that can accomodate, and see whether it would go through. IF it goes through, then take a cold backup, including the logs there and the ones you moved out. Then remove logs that are of more than 2 weeks old and try starting the system. If it comes up that is a good sign.

Good luck.
Sam

[Frannie]

Thank you very much! First step has been successful! We could have been the whole night waiting for it finishing!
Now the "hard" part of it has just began... It's our first Oracle backup in our lifes... Pray for us!
(any advice? :-)
Thanks!

[sambavan]

What is your platforum? Database version? Were you successfull in shuting down the system? What kind of backup you are doing? etc

Check your alert_SID.log file and make sure that the shutdown was successful. It can be found under $ORACLE_BASE/admin/SID/bdump/alert_SID.log

Probably some of us may be able to help you, so, keep posting things on your status until every thing starts to roll up.

Good luck,
Sam

[Edited by sambavan on 06-21-2001 at 06:54 PM]

[Frannie]

Please, just another question: we're thinking about the next "emergency solution":
Saving (to a tape) all tablespaces, control files, redo logs, and finally the archive logs. Then, we would like to remove all those archive logs which shouldn't be necessary for the next startup of Oracle (we know that Oracle will start from a concrete number of archive logs, but have no idea of how to know what will be the first # of archive log necessary, so the previous ones are not useful). Do you understand what we pretend? Is it a crazy idea?

In other words how many archive.logs should be left in place
for ensure next startup, we fear some mesage like
"Oracle could not found archive log number..."

Tnx to everybody!!!!