Have u checked the error in Metalink?
Here it is:
Problem Explanation:
====================

There are a few possible causes:
- The standby database is down or was bounced.
- The listener on the remote host is down
- There was a network problem.

The standby database must be mounted, open in read only, or operating in a
standby database recovery mode for the remote archival functionality to work.
The ARCH process on the primary has lost the Remote File Server
process on the remote host.

Solution Description:
=====================

You need to reactivate the failed destination to resume the automatic archival
process to the standby host. The RFS process will be re-started at the standby
host during the initial connect phase of the archivelog operation.

1) Make sure the standby database is mounted as a standby.

sqlplus> startup nomount pfile="/xx/xx/initSID.ora"
sqlplus> alter database mount standby database


2) Make sure the listener is up on the standby host and listening
for the standby database.

$ lsnrctl start
$ lsnrctl services


3) Reactivate the failed destination.

Reactivate the failed destination by resetting the corresponding destination
state to ENABLE (default). The following will manually reactive a failed
destination that does, or does not have a specified REOPEN value. For example:

sqlplus> alter system set log_archive_dest_state_n = enable


4) Designate a REOPEN value for future destination failures.

REOPEN is an attribute of a LOG_ARCHIVE_DEST_n parameter defined in the primary's
init.ora file. The REOPEN value designates the amount of time (in seconds)
that must elapse before an archivelog operation will attempt to archive to a
failed destination. If a failed destination has no REOPEN attribute value
specified in the LOG_ARCHIVE_DEST_n parameter, then no further attempts to
archive to it will be made, and user action is required to manually reactivate
the failed destination, as described in step 3 above. The following will not
reactivate a failed destination. It will designate a REOPEN value for use
should the destination fail in the future. It's a good idea to have a REOPEN
value set.

sqlplus> alter system set log_archive_dest_n = 'service=XXXX reopen=120'

If a REOPEN attribute value is already set in the primary's LOG_ARCHIVE_DEST_n
parameter, errors against this particular _n destination will be cleared, and
automatic archiving to the destination will continue with no user intervention.

Whether automatically or manually reset, any subsequent log switches on the
primary should now result in successful remote archival. Tail the alert_SID.log
on the primary host to make sure this is happening.


5) Since remote archival has been restarted, redo logs now archived on the
primary will be sent to the standby host. There may however, be one or more
archive logs missing on the standby database; a "gap" in the sequence. You must
use manual recovery on the standby to bridge the gap, then resume sustained
recovery.

a) Review v$log_history of both primary and standby or look in the archive
destinations to see what archive logs are missing.

b) Manually transfer the missing archive logs to the standby host.

c) Apply the missing archive logs manually using:

sqlplus> recover standby database;

NOTE: You must use manual recovery because the remote archival process
has not updated the standby database controlfile for the missing archive
logs, so sustained recovery mode would not "see" the archive files.

d) When application of the missing archive logs is complete, resume sustained
recovery:

sqlplus> recover managed standby database;