Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!drn.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.icl.net!newsfeed.fjserv.net!newshosting.com!nx01.iad01.newshosting.com!diablo.voicenet.com!in.100proofnews.com!in.100proofnews.com!newscon06.news.prodigy.com!prodigy.net!newsmst01a.news.prodigy.com!prodigy.com!postmaster.news.prodigy.com!newssvr17.news.prodigy.com.POSTED!a25fe021!not-for-mail
From: Mladen Gogala <gogala@sbcglobal.net>
Subject: Re: ORA-16014: log 3 sequence# 492 not archived
User-Agent: Pan/0.14.2 (This is not a psychotic episode. It's a cleansing moment of clarity.)
Message-ID: <pan.2005.03.04.04.42.43.576702@sbcglobal.net>
Newsgroups: comp.databases.oracle.server
References: <1109862869.945939.30610@l41g2000cwc.googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Lines: 54
NNTP-Posting-Host: 69.182.45.211
X-Complaints-To: abuse@prodigy.net
X-Trace: newssvr17.news.prodigy.com 1109911364 ST000 69.182.45.211 (Thu, 03 Mar 2005 23:42:44 EST)
NNTP-Posting-Date: Thu, 03 Mar 2005 23:42:44 EST
Organization: SBC http://yahoo.sbc.com
X-UserInfo1: FKPGW][DRJVKRVH]]RKB_UDAZZ\DPCPDLXUNNHLHEQR@ETUCCNSKQFCY@TXDX_WHSVB]ZEJLSNY\^J[CUVSA_QLFC^RQHUPH[P[NRWCCMLSNPOD_ESALHUK@TDFUZHBLJ\XGKL^NXA\EVHSP[D_C^B_^JCX^W]CHBAX]POG@SSAZQ\LE[DCNMUPG_VSC@VJM
Date: Fri, 04 Mar 2005 04:42:44 GMT
Xref: dp-news.maxwell.syr.edu comp.databases.oracle.server:237451

On Thu, 03 Mar 2005 07:14:29 -0800, ejsanchez wrote:

> 
> after that everything is working again, the problem is that I can't
> issue a full import because of the redologs got out of space or
> something...
> Also, yesterday we didn't tried a full import, nobody is using the
> database and
> today we are facing the same problem, but with the log 2
> any advice on this?
> thanks in advance...

Well, defining parameters like log_archive_dest_1...10 and reading about 
them in the reference manual is very complicated. To avoid that nuisance,
you can also do the following:

1) alter database backup controlfile to trace as '/tmp/create_ctl.sql'; 
2) Modify the file /tmp/create_ctl.sql to look something like this:

CONNECT / AS SYSDBA
STARTUP FORCE NOMOUNT
CREATE CONTROLFILE REUSE DATABASE "ORACLE" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 16
    MAXLOGMEMBERS 3
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 454
LOGFILE
  GROUP 1 '/oradata/10g/oracle/redo01.log'  SIZE 64M,
  GROUP 2 '/oradata/10g/oracle/redo02.log'  SIZE 64M,
  GROUP 3 '/oradata/10g/oracle/redo03.log'  SIZE 64M
DATAFILE
  '/oradata/10g/oracle/system01.dbf',
  '/oradata/10g/oracle/undotbs01.dbf',
  '/oradata/10g/oracle/sysaux01.dbf',
  '/oradata/10g/oracle/users01.dbf',
  '/oradata/10g/ORACLE/datafile/o1_mf_lobs_0szv1bfw_.dbf',
  '/oradata/10g/ORACLE/datafile/o1_mf_indx_0szv4dbg_.dbf',
  '/oradata/10g/ORACLE/datafile/o1_mf_statspac_0t032zh4_.dbf'
CHARACTER SET WE8ISO8859P1
;
ALTER DATABASE OPEN RESETLOGS;

Don't forget to add "connect / as sysdba" and the keyword "FORCE" to
startup. Also, make sure that you have both "RESETLOGS" and "NOARCHIVELOG" 
in "CREATE CONTROLFILE" statement. At the end, you will have to add 
"ALTER DATABASE OPEN RESETLOGS;"

All you need to do is to execute this little SQL file as oracle and
you will no longer have any trouble with the unavailable destinations.

-- 
A clean tie attracts the soup du jour.