SQL & PL/SQL

what's in the trace file

/opt/app/oracle/admin/gbprod01/udump/gbprod012_ora_21265.trc

Have a look here.. it might help ?

http://arjudba.blogspot.com/2008/07/database-startup-fails-with-error-ora.html

Which version of oracle are you running?

What does this show?

SQL> show parameter recovery

Your disk may have space, but what is the setting of db_recovery_file_dest_size?

Bottom line, you need to backup those archive log files then delete them. This is what rman was made to do.

SQL> show parameter recovery

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /u03/backups/
db_recovery_file_dest_size big integer 40G
recovery_parallelism integer 0


however the archive log list shows the archiving is set to go to

/u03/arch/gbprod01/gbprod011 ( shown previously) So db_recovery_file_dest should be irrelevant shouldn't it?

Thanks in advance.

rman is set to remove archives after it backs up.
However complaining though seemingly space there.

try this mate,
You need to do this in RMAN, not SQLPlus. The following commands will delete your archivelogs from your flash recovery area so please make sure that everything is backed up first:

RMAN> connect target sys/*******

RMAN> delete archivelog all;

RMAN>crosscheck archivelog all;

should help you.

The "archive log list" output indicates "/u03/arch/ddprod01/ddprod011" (ddprod) as the destination
but your "df" and "ls" listings are for "/u03/arch/gbprod01/gbprod011" (gbprod)

Are they the same directory/filesystem ?

Had enough space in directory though it was complaining about not able to write to the location log. So we tried copying a large file in the same location which worked.

So then we did a few

SQL>alter system switch logfile;
Which forced a log switch and subsequently put the redo in archive logs.

We have an archive log as of today after the log switches in the archive log location where it was previously complaining.

Hence problem resolved. Maybe it just complained in OEM temporerily, and it remains there as an error message though resolved. Need to remove error from OEM manually.

Thank You for all your suggestions anyway.

Safi

Quite possible. Any time you get an alert in OEM, you'd do well to take a look at the current situation in the alert log itself.

Also, I've seen situations in some nix systems where deleting a file didn't necessarily release the space. Never learned the details as the SA's at that company were very closed about everything, and now I don't even remember which nix it was, as we had Solaris, HP, and AIX.

Are you sure the /u03 was a file system?

When you run df -kh what was the output? It could well be that /u03 was in the path to the filesystem. Hence df -kh /u03 will point to the root filesystem usage.

Just a thought!!

Christopher Soza
Oracle BI DBA
Orix Consultancy Services Ltd

http://sozaman.blogspot.com

Probably because oracle processes still had a handle on the file descriptors.

Quite common e.g. when there's a system-wide trace going on.