Using log_full.sh for running ontape -a
Hello,
IDS 11.10 FC2W1, solaris 10 V490, 16 GB RAM, 4 dual core processors
On my test server i have set the ALARMPROGRAM to the path of log_full.sh
script and in that script i have set BACKUP_CMD="ontape -a -d" (backup using
directory feature).
i have been observing the logical log backup for some time now and every thing
seems to be working ok.
Before i implement this on to our production servers( currectly we are using
ontape -c to remote tape device) i would just like to know --
vikas:/export/home/informix> ps -aef |grep informix
informix 5261 5259 13 May 16 ? 37104:08 ontape -a
informix 5259 5258 0 May 16 ? 0:00 /bin/sh -c
/usr/informix/ids-11.10.FC2W1/etc/log_full.sh 2 23 "Logical Log 1577
"37104:08 ontape -a" is it ok to have this running for a ever.
Also from top command i observer that
PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
5261 informix 1 40 -10 33M 26M cpu/17 618.4H 12.50% ontape
Is it ok that Ontape alone continously consume 12.50% of CPU, this is on test
server with no or very less activity
The production setup is similar to the test server but with all the production
activities and very huge transaction load.
then running ontape -a periodically through a cron job is a better idea or
should i go ahead with the log_full.sh script
Pls suggest
Thanking you all in advance
Regards
vikas.
Hi,
I think the ontape process that you see running is a failed
attempt from a time when you were experimenting.
Since it does not have the "-d" option, it probably is
(actively) waiting for the prompt to be answered (or similar),
but no-one ever answered it because the prompt goes
to "nowhere".
You should kill this ontape process.
Whether you run "ontape -a -d" via cron or log_full.sh script
is more a matter of personal preference than anything else.
Both approaches have their advantages and disadvantages.
Regards,
Martin
--
Martin Fuerderer
IBM Informix Development Munich, Germany
Information Management
IBM Deutschland Entwicklung GmbH
Chairman of the Supervisory Board: Martin Jetter
Board of Management: Herbert Kircher
Corporate Seat: Boeblingen, Germany
Reg.-Gericht: Amtsgericht Stuttgart, HRB 243294
ids-bounces@iiug.org wrote on 11.06.2008 10:30:31:
> Hello,
> IDS 11.10 FC2W1, solaris 10 V490, 16 GB RAM, 4 dual core processors
>
> On my test server i have set the ALARMPROGRAM to the path of log_full.sh
> script and in that script i have set BACKUP_CMD="ontape -a -d" (backup
using
> directory feature).
>
> i have been observing the logical log backup for some time now and
> every thing
> seems to be working ok.
>
> Before i implement this on to our production servers( currectly we are
using
> ontape -c to remote tape device) i would just like to know -->
> vikas:/export/home/informix> ps -aef |grep informix
> informix 5261 5259 13 May 16 ? 37104:08 ontape -a
> informix 5259 5258 0 May 16 ? 0:00 /bin/sh -c
> /usr/informix/ids-11.10.FC2W1/etc/log_full.sh 2 23 "Logical Log 1577
>
> "37104:08 ontape -a" is it ok to have this running for a ever.
>
> Also from top command i observer that
>
> PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
> 5261 informix 1 40 -10 33M 26M cpu/17 618.4H 12.50% ontape
>
> Is it ok that Ontape alone continously consume 12.50% of CPU, this is on
test
> server with no or very less activity
> The production setup is similar to the test server but with all the
> production
> activities and very huge transaction load.
>
> then running ontape -a periodically through a cron job is a better idea
or
> should i go ahead with the log_full.sh script
>
> Pls suggest
>
> Thanking you all in advance
> Regards
> vikas.
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
Thank you Martin !
I have killed that process.
Did some transactions and checked for the logical logs. found that they are
backed up perfectly and there is no still process for ontape in ps -aef |grep
informix nor in the top.
This was the first time i had used the log_full.sh script hence could not
figure out my mistake.
killing the process and confirming for logical log backed up using log_full.sh
working very fine cleared all my doubts.
Once again Thank you very much
Regards,
vikas