backup + aimgt

[polv]

Excuse for my bad English.
every day new process increases.
why can be what at a backup processes don't come to the end? it is possible to turn off these podvisshy processes somehow?
in log
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 6997.
Management archival UNLOCK error: Indicator 1, PID 1396.
Management archival UNLOCK error: Indicator 1, PID 6997.
Management archival UNLOCK error: Indicator 1, PID 22866.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 22866.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 24348.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 32069.


6997 Jan 27 23:09:33 2018 _mprshut -db /base/db/db -C aimgt
1396 Jan 26 23:00:03 2018 _mprshut -db /base/db/db -C aimgt
22866 Jan 28 23:08:02 2018 _mprshut -db /base/db/db -C aimgt
24348 Jan 29 23:00:02 2018 _mprshut -db /base/db/db -C aimgt
32069 Jan 30 23:08:09 2018 _mprshut -db /base/db/db -C aimgt
1775 Jan 31 23:00:03 2018 _mprshut -db /base/db/db -C aimgt

 

[Cringer]

What Progress version is this please?
In a proenv session, type "rfutil <<db>> -C aimage list" and post the output here.
Can you post the full logfile entry (original language is ok) as it will hopefully show the Progress error number and make it easier to advise. I'm not 100% sure what these errors are as I think you've translated them.

 

[polv]

10 version
In logs there is nothing, perhaps it was updated, I will look tomorrow morning, after the next backup and I will publish a conclusion.

rfutil /base/db/db -C aimage list
OpenEdge Release 10.2B07 as of Fri Sep 7 02:16:34 EDT 2012


Extent: 1
Status: Busy
Type: Fixed Length
Path: /base/db/ai/db.a1
Size: 32752
Used: 1728
Start: Wed Jan 31 23:00:02 2018
Seqno: 1

Extent: 2
Status: Empty
Type: Fixed Length
Path: /base/db/ai/db.a2
Size: 32752
Used: 0
Start: N/A
Seqno: 0

Extent: 3
Status: Empty
Type: Fixed Length
Path: /base/db/ai/db.a3
Size: 32752
Used: 0
Start: N/A
Seqno: 0

Extent: 4
Status: Empty
Type: Fixed Length
Path: /base/db/ai/db.a4
Size: 32752
Used: 0
Start: N/A
Seqno: 0

Extent: 5
Status: Empty
Type: Fixed Length
Path: /base/db/ai/db.a5
Size: 32752
Used: 0
Start: N/A
Seqno: 0

Extent: 6
Status: Empty
Type: Fixed Length
Path: /base/db/ai/db.a6
Size: 32752
Used: 0
Start: N/A
Seqno: 0

 

[Rob Fitzpatrick]

Excuse for my bad English.
every day new process increases.
why can be what at a backup processes don't come to the end? it is possible to turn off these podvisshy processes somehow?
in log
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 6997.
Management archival UNLOCK error: Indicator 1, PID 1396.
Management archival UNLOCK error: Indicator 1, PID 6997.
Management archival UNLOCK error: Indicator 1, PID 22866.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 22866.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 24348.
Management archival UNLOCK error: Indicator 0, PID 0.
Management archival UNLOCK error: Indicator 1, PID 32069.


6997 Jan 27 23:09:33 2018 _mprshut -db /base/db/db -C aimgt
1396 Jan 26 23:00:03 2018 _mprshut -db /base/db/db -C aimgt
22866 Jan 28 23:08:02 2018 _mprshut -db /base/db/db -C aimgt
24348 Jan 29 23:00:02 2018 _mprshut -db /base/db/db -C aimgt
32069 Jan 30 23:08:09 2018 _mprshut -db /base/db/db -C aimgt
1775 Jan 31 23:00:03 2018 _mprshut -db /base/db/db -C aimgt

It looks like you have multiple AI management daemon processes for a single database (each started around 23:00 on successive days), which you should not. I have never seen the error "Management archival UNLOCK error" before and I can't find any mention of it in the knowledge base.

I suggest you open a case with Progress technical support.

 

[Cringer]

My suspicion is that the OP tried to translate the actual error message, hence the inability to find KB articles.

 

[Cringer]

Please can you show us what your backup script is doing?

 

[polv]

Please can you show us what your backup script is doing?

#!/bin/sh

DATE=`date +%Y%m%d`
DBSARCDIR="/backup/db"
LOG="/var/log/backup.log";
NUM=`printf "%s_%04d_%s_mid" $DATE $N /base/db/db`

rfutil /base/db/db -C aimage aioff

probkup online \
/base/db/db \
$DBSARCDIR/$NUM \
enableai enableaiarchiver \
-aiarcdir /backup/ai/db \
-aiarcdircreate \
-com >> $LOG

 

[polv]

/var/log/backup.log

OpenEdge Release 10.2B07 as of Fri Sep 7 02:16:34 EDT 2012

After-image Extent Management has been disabled for the database. (13292)
After-image was switched off online. (10019)
umped. (6686)
1024 BI blocks will be dumped. (6688)
Backup requires an estimated 754.3 MBytes of media. (9285)
Restore would require an estimated 193098 db blocks using 752.8 MBytes of media. (9286)
After-image block size set to 16 kb (16384 bytes). (644)
After-image has been enabled online successfully. (13781)
The After-image Archiver has been enabled. (13918)
The After-image Management Daemon will begin in a few moments. (13920)
Backed up 189637 db blocks in 00:00:22
Wrote a total of 4710 backup blocks using 625.5 MBytes of media. (13625)

Backup complete. (3740)



I think a problem not in the backup.
the script does a backup of two bases, processes are multiplied only on this. the second operates normally.
Management archival UNLOCK error: Indicator 1, PID 6997. it is copied from the logs original.

[2018/02/02@08:08:23.815+0500] P-11541 T-47497143602096 I AIMGT 17: (-----) AI Management archival UNLOCK error: Indicator 1, PID 10403.

 

[Rob Fitzpatrick]

You should change your script.

The options "enableai" and "-aiarcdir" are intended for one-time use, to enable AI on a database where it is currently disabled, without having to shut down and restart. They aren't intended for daily use. There is no need to disable and re-enable AI every night. My guess is you've found a bug that makes it is possible to start multiple AI daemons against one database.

 

[polv]

You should change your script.

The options "enableai" and "-aiarcdir" are intended for one-time use, to enable AI on a database where it is currently disabled, without having to shut down and restart. They aren't intended for daily use. There is no need to disable and re-enable AI every night. My guess is you've found a bug that makes it is possible to start multiple AI daemons against one database.

Do you have an offer as to correct it what to replace with?

 

[polv]

in documentation it is written that it includes AI after creation of a full backup copy

enableai
указывает утилите, что необходимо включить after-imaging после выполнения online резервной копии. Для включения механизма, копирование должно быть полным и выполняться в online.

enableai
specifies to the utility that it is necessary to include after-imaging after performance of online of a backup copy. For turning on of the mechanism, copying has to be full and be carried out in online.

 

[Cringer]

Maybe the Russian is ambiguous, but as Rob says, it's a one-time only action. Once AI is on, it is on.

probkup online /base/db/db $DBSARCDIR/$NUM -com >> $LOG

That is all you need.

 

[Rob Fitzpatrick]

A little advanced tip: add "-Bp 10" after the backup parameters. To use Cringer's example, that would be:
probkup online /base/db/db $DBSARCDIR/$NUM -com -Bp 10 >> $LOG

This is a performance enhancement. It won't help the performance of probkup at all, but it will help applications that run after probkup. You won't find the -Bp parameter ("Private Read-Only Buffers") in the prorest documentation. It is a client startup parameter (documented here) so it is valid, as probkup is a database client.

Using the startup parameter -Bp 10 on a client specifies that the client does its reads in a small region of the database buffer pool. That region is of fixed size, in this case 10 buffers.

Ordinarily (i.e. without -Bp), probkup replaces the contents of many of the buffers in the buffer pool. This is because prokbup reads every block in the database. Let's say there are n blocks in the database and the size of the buffer pool is B buffers. If n > B, then at the end of probkup, the buffer pool will contain the contents of the last B blocks read by probkup. That means the previous contents of those buffers, which were blocks useful to the application clients were evicted. The next time they are accessed they will have to be read back into the buffer pool from disk, causing application latency.

When you add -Bp 10 to the probkup command, it doesn't use the entire buffer pool for its reads. It just uses a region of 10 buffers for its reads, leaving the contents of the other B - 10 buffers intact and available for application clients.

 

[Cringer]

To confirm, this behaviour does not happen in 11.7 or in 10.2B08. You should certainly fix your backup script, but you should also upgrade because I suspect you are not on 10.2B08. Anything earlier than 10.2B08 is ancient, obsolete and unsupported. 10.2B08 will be going that way this year too.

 

[Rob Fitzpatrick]

I suspect you are not on 10.2B08

rfutil /base/db/db -C aimage list
OpenEdge Release 10.2B07 as of Fri Sep 7 02:16:34 EDT 2012

 

[Cringer]

lol thanks Rob.

 

[polv]

A little advanced tip: add "-Bp 10" after the backup parameters. To use Cringer's example, that would be:
probkup online /base/db/db $DBSARCDIR/$NUM -com -Bp 10 >> $LOG

This is a performance enhancement. It won't help the performance of probkup at all, but it will help applications that run after probkup. You won't find the -Bp parameter ("Private Read-Only Buffers") in the prorest documentation. It is a client startup parameter (documented here) so it is valid, as probkup is a database client.

Using the startup parameter -Bp 10 on a client specifies that the client does its reads in a small region of the database buffer pool. That region is of fixed size, in this case 10 buffers.

Ordinarily (i.e. without -Bp), probkup replaces the contents of many of the buffers in the buffer pool. This is because prokbup reads every block in the database. Let's say there are n blocks in the database and the size of the buffer pool is B buffers. If n > B, then at the end of probkup, the buffer pool will contain the contents of the last B blocks read by probkup. That means the previous contents of those buffers, which were blocks useful to the application clients were evicted. The next time they are accessed they will have to be read back into the buffer pool from disk, causing application latency.

When you add -Bp 10 to the probkup command, it doesn't use the entire buffer pool for its reads. It just uses a region of 10 buffers for its reads, leaving the contents of the other B - 10 buffers intact and available for application clients.

Thanks. We will try.