Re: hot backup archivelog the online-redo files and Oracle locks up

Does migrating from England 8 years ago count? I've been told I shall be a Pom forever, but I do like pie floaters and the Adelaide Crows... surely that counts???

Let me sit down and relax for an hour or so (it's been a hard day on the Performance Tuning course --"What's a Server Process???" -- and I'll look at the alert log stuff and get back to you.

Regards
HJR "obakesan" <cjeastwd_at_powerup.com.au> wrote in message news:666a787e.0202042213.5d3bc8d0_at_posting.google.com...
> HiYa
>
>
> Sensei "Howard J. Rogers" <dba_at_hjrdba.com> kaiteimashita message
> news:<3c5ee35b$0$18470$afc38c87_at_news.optusnet.com.au> ni
>
>
> > Comments below.
>
> arigatou gozaimasu
>
>
> > You might want to look at log_archive_dest. There is a default
destination
>
> most likely its related to the tiny amount of traffic that the
> database gets
> but I am seeing stuff going to (Eg)
> /u01/app/oracle/admin/$ORACLE_SID/arch
> as well as /u01/app/oracle/admin/$ORACLE_SID/bdump
>
>
> > > LOCKUPS
> > >
> > > One of the reasons why am I asking these things, is that today, when
doing
>
> ...
>
> >
> > Not an uncommon problem, and probably totally unrelated to whether you
are
> > archiving or not. Lots of people have gotten into the habit of doing a
> > shutdown abort, followed by a startup restrict, followed by a shutdown
> > immediate.
>
> interesting ... I guess that a shutdown abort will force a restore,
> which I guess happens in the startup restrict, and you have to tell
> all users to log off and finish their transactions first.
>
> I suppose that all COMMITed transactions will be written to the
> database so the database will be in a "safe" state?
>
> >
> > Can't advise further without some more detail: like, what did your alert
log
> > say?
>
> all looked rather simmilar till about
>
> Mon Feb 4 15:06:16 2002
> Thread 1 advanced to log sequence 1868
> Current log# 2 seq# 1868 mem# 0:
> /u01/app/oracle/oradata/DEV/redo02.log
> Mon Feb 4 15:06:16 2002
> ARC0: Beginning to archive log# 1 seq# 1867
> ARC0: Completed archiving log# 1 seq# 1867
> Mon Feb 4 18:16:12 2002
> Restarting dead background process EMN0 <--- HERE !!
> EMN0 started with pid=17
> Mon Feb 4 18:16:13 2002
> Shutting down instance (immediate)
> License high water mark = 8
> Mon Feb 4 18:21:40 2002
> Restarting dead background process EMN0
> EMN0 started with pid=10
> Mon Feb 4 18:21:41 2002
> Shutting down instance (immediate)
> License high water mark = 8
> Mon Feb 4 18:48:06 2002
> LGWR: terminating instance due to error 472
> Instance terminated by LGWR, pid = 20519
> Mon Feb 4 18:51:36 2002
>
>
> not knowing what to look for (apart from blinking text saying error
> ;-)
> perhaps I missed something
>
> sack the trainee?
>
> BTW Howard, are you Australian? I just dont see many others using the
> term walkabout much. ("You&#8217;d also restore the Password and
> Parameter Files if they&#8217;d gone walkabout, but not otherwise.")
>
> just wonderin, I'm from Queensland
>
>
>
> > >
> > > My present understanding of these is that I need to keep all of these
from
> > the
> > > time that the database is started in order to do recovery.
> > >
> >
> > No. You only strictly need to keep archives from the time the last
backup
> > started (hot or cold, it makes no difference).
>
> so, if I do a hot backup, is there any need of a cold backup? Will it
> make any difference in the time required to reapply the redo logs?
>
> if the redo logs needed for a recovery are only the ones since the
> last hot backup this means that I can make my life easier in terms of
> management of volumes of files by keeping the archived redo logs in
> bundles logically related to each backup episode
>
> Eg (cos I am studying too much Japanese I am starting to doubt my
> english descriptive abilitys)
>
> New database created ... nothing in it handed over the client
> all files are duplicated (initial cold backup)
>
> (a week passes)
>
> hot backup done, and switch logfile called , and all files in the
> "log_archive_dest" are included into a tar file with the datafiles to
> all me
> to any point in that week (assuming no data errors in the act of
> making the
> file) This tar file is then kept with a name that included the date
> and the
> SID.
>
> remove files in log_archive_dest
>
> (a week passes)
>
> hot backup done, and switch logfile called , and all files in the ...
> cycle as above
>
> NOTE I suspect that the archived redo files I have are more applicable
> to the previous backup as they could be applied to that set of
> datafiles to roll forward transactions to make it the same as the
> present archived datafiles.
>
>
> > But that rather assumes that
> > you will always restore from the last backup. What happens if the last
> > backup is damaged, is missing a file when it comes to be used, or is
> > discovered itself to be corrupt?
>
> the corrupt issue is the biggest snag, as then I would not
> necessarialy have the needed archived redo logs needed for a roll
> forward.
>
> it seems odd to just leave them there, making the amount needed to
> backup bigger every time?
>
>
>
> > Then you would want to restore from a
> > previous backup -but unless you've retained the archives since *that*
> > backup, you won't be able to use it. Prudence suggests keeping several
> > backups to hand, and all the archives needed to make sense of any of
them.
>
> as far as I am concerned (being a hoarder) I will keep all the
> backups, on some kind of media, perhaps after some months making them
> less available by sending them to secure storage.
>
>
>
> > Well, moving the "unwanted" archives to offline storage sounds fine.
Simply
> > deleting them is a bit brave (ie, foolish), but since that's not what
you
> > are proposing, you should be fine.
>
> when taken off the mirrored raid system, I will be advocating
> duplication or more onto off-line media
>
>
> thanks for all your comments. Ohh ... and thanks for that guide!! Best
> resource I have found on the WWW, please send me a email with your
> postal address, so I can send a thankyou postcard from Japan (where
> English Oracle books are not so cheap, even at Kinokunya)
Received on Tue Feb 05 2002 - 02:06:06 CST