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

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 - 00:13:38 CST