Skip to Main Content
Forums

Oracle Database Discussions

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Archiver hnug log error

user5856470Sep 12 2008 — edited Sep 15 2008
I am getting this error through Oracle Enterprise Manager for my Production RAc database
It has been working fine for ages. Its just suddenly started doing this.

The archiving is hung? Please can someone help explain what I need to do to resolve or if already ersolved. I'll know if its resolved as new archiving will be written in 1 days time otherwise it complain again when it tries to write to the archiving???

SEVERITY
critical

CATEGORY
Archiver Hung Alert Log Error

TIME
11-Sep-2008 23:02:43

ALERT LOG STACK
ORA-16038: log 3 sequence# 1351 cannot be archived
ORA-19504: failed to create file ""
ORA-00312: online log 3 thread 2: '/u02/logs/gbprod01/redo03a.log'
ORA-00312: online log 3 thread 2: '/u02/logs/gbprod01/redo03b.log'
Trace File: /opt/app/oracle/admin/gbprod01/udump/gbprod012_ora_21265.trc

ALERT TRIGGERED
11-Sep-2008 23:14:15


The disk where the archiving would be written has plenty of space and full write access.
$>df -kh /u03
/dev/sdd 300G 186G 115G 62% /u03

$>ls -ltr /u03/arch/gbprod01
drwxr-xr-x 1 oracle oinstall 131072 Jun 12 2007 gbprod011



Please can someone help as to what I need to do or whether it has resolved itself.

FYI



SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /u03/arch/ddprod01/ddprod011
Oldest online log sequence 1326
Next log sequence to archive 1327
Current log sequence 1327


SQL> select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- -------------------
1 1 1327 52428800 2 NO CURRENT
7883970584 11.09.2008 23:02:38

2 1 1326 52428800 2 YES INACTIVE
7883951113 11.09.2008 22:00:40

3 2 1351 52428800 2 YES INACTIVE
7883967749 11.09.2008 23:00:35


GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
FIRST_CHANGE# FIRST_TIME
------------- -------------------
4 2 1352 52428800 2 NO CURRENT
7883970586 11.09.2008 23:02:38



I'm also getting this in the trac file however this has been happening since the 7th of Sept and the problem has happened today. So this may be another issue.

LGWR: Archivelog for thread 1 sequence 1261 will NOT be compressed
*** 2008-07-31 17:14:16.863
...
...
...
*** 2008-09-11 23:02:38.163
LGWR: Archivelog for thread 1 sequence 1327 will NOT be compressed

Thank you in addvance.

Talha

Comments

247514
what's in the trace file

/opt/app/oracle/admin/gbprod01/udump/gbprod012_ora_21265.trc
587671
Have a look here.. it might help ?

http://arjudba.blogspot.com/2008/07/database-startup-fails-with-error-ora.html
567269
Which version of oracle are you running?

What does this show? 
SQL> show parameter recovery
EdStevens
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.
user5856470
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.
user5856470
rman is set to remove archives after it backs up.
However complaining though seemingly space there.
447085
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.
26741
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 ?
user5856470
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
EdStevens
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.
221158
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
antti.koskinen
Also, I've seen situations in some *nix systems where deleting a file didn't necessarily release the space
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.
1 - 12
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Oct 13 2008
Added on Sep 12 2008
#error, #general-database-discussions, #log
12 comments
366 views