Whence cometh these log backups? 
Author Message
 Whence cometh these log backups?

IDS 9.20 on HP-UX 11.0

A funny thing has started happening to three out of my four production
servers.  The Ops break continuous logging each night and do a level 0
archive.  When they come to re-start the logging, it fails saying that a log
backup is already in progress.  And so it is!  Tracing back from onstat -u
it turns out that an onbar process is running.  We do not use and never have
used ohnbar.  What is starting them up - any ideas?

Below is an onstat -u; onstat -g ses and various ps commands that identify
the backup process, in case anyone's interested.

thanks
Neil
----------------------------------------------------------------------------
---------------------------------------------------------------------------


Informix Dynamic Server 2000 Version 9.20.FC2   -- On-Line -- Up 9 days
07:41:53
 -- 300604 Kbytes

Userthreads
address          flags   sessid   user     tty      wait             tout
locks
nreads   nwrites
c00000006d95e028 ---P--D 1        informix -        0                0    0
2423     29286
c00000006d95e7c8 ---P--F 0        informix -        0                0    0
0        1170694
c00000006d95ef68 ---P--- 9        informix -        0                0    0
0        9888
c00000006d95f708 ---P--B 10       informix -        0                0    0
295      29766
c00000006d960648 ---P--D 14       informix -        0                0    0
0        0
c00000006d965a28 ------- 68806    root     -        0                0    0
309      0
c00000006d9687e8 Y--P--M 68806    root     -        c000000071638ef8 0    0
0        0
 7 active, 128 total, 49 maximum concurrent


Informix Dynamic Server 2000 Version 9.20.FC2   -- On-Line -- Up 9 days
07:42:09
 -- 300604 Kbytes

session                                   #RSAM    total      used
id       user     tty      pid   hostname threads  memory     memory
68806    root     -        3978  archer   2        741376     707544

tid      name     rstcb            flags    curstk   status
69088    ontape   c00000006d9687e8 Y--P--M  65632    c00000006d9687e8cond
wait(s
m_read)
69089    logbacku c00000006d965a28 -------  133128
c00000006d965a28sleeping(Fo
rever)

Memory pools    count 1
name         class addr             totalsize  freesize   #allocfrag
#freefrag
68806        V     c00000006e23a040 741376     33832      124        28

name           free       used           name           free       used
overhead       0          3256           scb            0          144
opentable      0          5184           filetable      0          1888
log            0          4336           temprec        0          10104
keys           0          624            gentcb         0          2496
ostcb          0          3416           net            0          646600
sqscb          0          17568          rdahead        0          352
hashfiletab    0          1128           log_backup     0          1192
osenv          0          2480           sqtcb          0          6536
fragman        0          80             sapi           0          160

Sess  SQL            Current            Iso Lock       SQL  ISAM F.E.
Id    Stmt type      Database           Lvl Mode       ERR  ERR  Vers
68806 -              -                  -   Wait 300   0    0    9.03



     UID   PID  PPID  C    STIME TTY       TIME COMMAND
    root  3978  3976  0 21:13:02 ?         0:00
/opt/informix/9.20/bin/onbar_d -
l

    root  3978  3976  0 21:13:02 ?         0:00
/opt/informix/9.20/bin/onbar_d -
l
informix  3976  3973  0 21:13:02 ?         0:00 onbar
/opt/informix/9.20/bin/onb
ar -l
informix 13633 12447  1 22:07:02 pts/tz    0:00 grep 3976

informix  3973  3972  0 21:13:02 ?         0:00 /usr/bin/sh
/opt/informix/9.20/e
tc/log_full.sh 2 23 Logical
informix  3976  3973  0 21:13:02 ?         0:00 onbar
/opt/informix/9.20/bin/onb
ar -l
informix 13635 12447  1 22:07:14 pts/tz    0:00 grep 3973

informix  3973  3972  0 21:13:02 ?         0:00 /usr/bin/sh
/opt/informix/9.20/e
tc/log_full.sh 2 23 Logical
informix 13650 12447  1 22:07:49 pts/tz    0:00 grep 3972
informix  3972  2709  0 21:13:02 ?         0:00 /bin/sh -c
/opt/informix/9.20/et
c/log_full.sh 2 23 "Logical

ALARMPROGRAM    /opt/informix/9.20/etc/log_full.sh # Alarm program path



Wed, 18 Jun 1902 08:00:00 GMT
 Whence cometh these log backups?

Can you describe exactly what you mean by "break continuous logging" and
what reason that is done for anyway? Also, please describe exactly how the
archive is triggered (hopefully forground on command line, ie no background
processes - ditto for the continuous logging)

NOTE: unless you have to share a tape drive, there is now reason and a few
counter reasons for pulling the log tapes just because you are doing an
archive.

There are a few issues regarding log sizes etc but it is entirely possible
and preferable to get archiving done on a live system during business hours
(ie when there are people around!) and while the log tapes are still doing
their thing.

Assuming you don't wanna use onbar - something I admit to being too lazy to
have a go at yet!

Quote:

>IDS 9.20 on HP-UX 11.0

>A funny thing has started happening to three out of my four production
>servers.  The Ops break continuous logging each night and do a level 0
>archive.  When they come to re-start the logging, it fails saying that a
log
>backup is already in progress.  And so it is!  Tracing back from onstat -u
>it turns out that an onbar process is running.  We do not use and never
have
>used ohnbar.  What is starting them up - any ideas?



Sat, 10 May 2003 12:59:06 GMT
 Whence cometh these log backups?


Quote:
> Can you describe exactly what you mean by "break continuous logging" and
> what reason that is done for anyway?

Because there are four Informix instances on the UNIX server and we have
only four DAT drives (and a DLT stacker).  The archive of one instance goes
to DLT but the other three go to DAT, hence the need to break logging (by
that I mean interrupt the currently-running ontape -c, initiated previously
as a foreground command).

Incidentally, I also break the logging and switch tapes each night on the
instance that archives to DLT (where there is no need to do so).  This means
that I am less susceptible to a single tape failure which might contain many
days' logs, and that if I did need to do a roll-forward I wouldn't have to
wait while multiple days' logs are bypassed before the correct section of
tape is found.  I'd be interested to hear the counter-reasons for regularly
switching logical logging tapes.

Finally, at clients where there is not 24x7 Ops cover I have successfully
used scripted logging and archiving (ie not foreground command line), using
variants of the iiug archives, and have not found them particularly
troublesome (except of course using onarchive!).

Neil



Wed, 18 Jun 1902 08:00:00 GMT
 Whence cometh these log backups?

Quote:

> IDS 9.20 on HP-UX 11.0

> A funny thing has started happening to three out of my four production
> servers.  The Ops break continuous logging each night and do a level 0
> archive.  When they come to re-start the logging, it fails saying that a log
> backup is already in progress.  And so it is!  Tracing back from onstat -u
> it turns out that an onbar process is running.  We do not use and never have
> used ohnbar.  What is starting them up - any ideas?

Is this a trick question? You are using the default ALARM program
(/opt/informix/9.20/etc/log_full.sh), which is designed to fire off a
log backup using OnBar every time a log fills.

I guess before this started happening the archive was able to complete
before the current log filled.

Cheers,
--
Mark.

+----------------------------------------------------------+-----------+

| http://www.informix.com  http://www.informixhandbook.com |/////  / //|
| http://www.iiug.org  +-----------------------------------+////  / ///|
|                      |This email will self-destruct in   |///  / ////|
|                      |10 sec. If you received this email |//  / /////|
|                      |in error, sorry about the mess.    |/  ////////|
+----------------------+-----------------------------------+-----------+



Wed, 18 Jun 1902 08:00:00 GMT
 Whence cometh these log backups?

Your ALARMPROGRAM is set to the log_full.sh script.  Unless you have
modified it, this script will automatically invoke an "onbar -l" every time
a logical log completes (fills).  Since you are already using "ontape -c" to
backup your logs continuously, I'd suggest setting your ALARMPROGRAM
parameter to "/opt/informix/9.20/etc/no_log.sh", and then bounce your
instance(s).

HTH,
Paul Mosser

Quote:
-----Original Message-----

Sent: Monday, November 20, 2000 3:32 PM

Subject: Whence cometh these log backups?

IDS 9.20 on HP-UX 11.0

A funny thing has started happening to three out of my four production
servers.  The Ops break continuous logging each night and do a level 0
archive.  When they come to re-start the logging, it fails saying that a log
backup is already in progress.  And so it is!  Tracing back from onstat -u
it turns out that an onbar process is running.  We do not use and never have
used ohnbar.  What is starting them up - any ideas?

Below is an onstat -u; onstat -g ses and various ps commands that identify
the backup process, in case anyone's interested.

thanks
Neil
----------------------------------------------------------------------------
---------------------------------------------------------------------------


Informix Dynamic Server 2000 Version 9.20.FC2   -- On-Line -- Up 9 days
07:41:53
 -- 300604 Kbytes

Userthreads
address          flags   sessid   user     tty      wait             tout
locks
nreads   nwrites
c00000006d95e028 ---P--D 1        informix -        0                0    0
2423     29286
c00000006d95e7c8 ---P--F 0        informix -        0                0    0
0        1170694
c00000006d95ef68 ---P--- 9        informix -        0                0    0
0        9888
c00000006d95f708 ---P--B 10       informix -        0                0    0
295      29766
c00000006d960648 ---P--D 14       informix -        0                0    0
0        0
c00000006d965a28 ------- 68806    root     -        0                0    0
309      0
c00000006d9687e8 Y--P--M 68806    root     -        c000000071638ef8 0    0
0        0
 7 active, 128 total, 49 maximum concurrent


Informix Dynamic Server 2000 Version 9.20.FC2   -- On-Line -- Up 9 days
07:42:09
 -- 300604 Kbytes

session                                   #RSAM    total      used
id       user     tty      pid   hostname threads  memory     memory
68806    root     -        3978  archer   2        741376     707544

tid      name     rstcb            flags    curstk   status
69088    ontape   c00000006d9687e8 Y--P--M  65632    c00000006d9687e8cond
wait(s
m_read)
69089    logbacku c00000006d965a28 -------  133128
c00000006d965a28sleeping(Fo
rever)

Memory pools    count 1
name         class addr             totalsize  freesize   #allocfrag
#freefrag
68806        V     c00000006e23a040 741376     33832      124        28

name           free       used           name           free       used
overhead       0          3256           scb            0          144
opentable      0          5184           filetable      0          1888
log            0          4336           temprec        0          10104
keys           0          624            gentcb         0          2496
ostcb          0          3416           net            0          646600
sqscb          0          17568          rdahead        0          352
hashfiletab    0          1128           log_backup     0          1192
osenv          0          2480           sqtcb          0          6536
fragman        0          80             sapi           0          160

Sess  SQL            Current            Iso Lock       SQL  ISAM F.E.
Id    Stmt type      Database           Lvl Mode       ERR  ERR  Vers
68806 -              -                  -   Wait 300   0    0    9.03



     UID   PID  PPID  C    STIME TTY       TIME COMMAND
    root  3978  3976  0 21:13:02 ?         0:00
/opt/informix/9.20/bin/onbar_d -
l

    root  3978  3976  0 21:13:02 ?         0:00
/opt/informix/9.20/bin/onbar_d -
l
informix  3976  3973  0 21:13:02 ?         0:00 onbar
/opt/informix/9.20/bin/onb
ar -l
informix 13633 12447  1 22:07:02 pts/tz    0:00 grep 3976

informix  3973  3972  0 21:13:02 ?         0:00 /usr/bin/sh
/opt/informix/9.20/e
tc/log_full.sh 2 23 Logical
informix  3976  3973  0 21:13:02 ?         0:00 onbar
/opt/informix/9.20/bin/onb
ar -l
informix 13635 12447  1 22:07:14 pts/tz    0:00 grep 3973

informix  3973  3972  0 21:13:02 ?         0:00 /usr/bin/sh
/opt/informix/9.20/e
tc/log_full.sh 2 23 Logical
informix 13650 12447  1 22:07:49 pts/tz    0:00 grep 3972
informix  3972  2709  0 21:13:02 ?         0:00 /bin/sh -c
/opt/informix/9.20/et
c/log_full.sh 2 23 "Logical

ALARMPROGRAM    /opt/informix/9.20/etc/log_full.sh # Alarm program path



Wed, 18 Jun 1902 08:00:00 GMT
 Whence cometh these log backups?
Yes, I think you and Paul Mosser, plus Obnoxio privately, have identified
the source.  This still doesn't identify why it's just started.  My problem
to resolve, I think.

thanks for your help, one and all.

Neil



Sun, 11 May 2003 08:48:08 GMT
 Whence cometh these log backups?

Quote:

>I'd be interested to hear the counter-reasons for regularly
>switching logical logging tapes.

No reasons beyond possible people problems. Your reasons are well-considered
and you have a valid reason to do what you do and you sound like you know
why and how.

When I say people problems, I am mainly concerned at customer sites to get
the damned things happening regularly! So I far prefer to make it a day-time
job, ideally I get one of the really solid citizens in the clerical staff to
do the job - I jokingly say a really boring, methodical person is ideal, but
it's not really a joke. Such a person is ideal to trust with doing it
faithfully every day, faithfully writing down the log numbers etc.

In order for archives to have no impact (i'm talking freezeouts and/or
serious performance hits here), part of the background requirement is to
ensure that the physical and logical logs are of the right size and number,
and of course to pick a decent time of day, and a suitable "slow" day for
the level zero's.

In terms of when to swap the log tapes themselves, I guess the main question
is how long it would take to spin thru a day or week's worth of logs, and
you've made a decision about that.

But this of course has nothing to do with your problem! I was just checking
that you are doing the right thing before I weigh in with solemn lectures
about doing the right thing. It sounds REALLY like a bug in the engine,
doesn't it? We've only very casually touched on the 9.XX engines here, so I
can't answer, but I have noted that a few people-in-the-know are saying that
9.2X has known defects and generally you should upgrade to the later
versions. 9.3X ?? I'm not all that familiar with the numbers there.

I do know we had the odd problem with the 7.2X engine; the same problem at a
few sites, and we have upgraded them to 7.31 which is a known quantity - a
better engine which I'm very happy with. I understand that the 9.2X engines
are based on the 7.2X source, so that's a hint that it would have the same
weaknesses that people have experienced.

Have you talked directly to Informix support? That's where I'd be going with
this kind of problem. I'd really be interested to hear the final answer too.

PS - background archiving disturbs me merely because Informix tells us not
to do it (for the reasons they list in the books). We have had to ask
Informix to repair a few dead sites over the years, and I'd hate them to
wash their hands of a recovery because we didn't follow their rules. I know
they would wash their hands in certain circumstances because they are very
concerned about liability if they get involved in repair work.



Sun, 11 May 2003 08:56:03 GMT
 
 [ 7 post ] 

 Relevant Pages 

1. Backup from filegroup without transaction log backups

2. Question about Transaction log backup with Backup Exec

3. SQL DB Backup - transaction log backup?

4. Backup from filegroup without transaction log backups

5. Full backups and transaction log backups

6. Differential Backup and Log Backup

7. Removal Trans.logs backup files fails - (Backup Maintenance Plan)

8. Advantage of differencial backup over Log backup

9. diffrential backup and transaction log backup

10. Log Ship backup corrupted, unable to backup the DB anymore

11. ebu backup and online redo log backup

12. Errors 20003 and 20296: whence, what to do?


 
Powered by phpBB® Forum Software