Hallo Btrivieans!

we observed an odd behavior of Backup-Agent (may be we do something wrong?)

Its on a Windows 2003-Server, running Pervasive SQL 8.6 und Backupagent 1.0.

We run a Batch like the following (via taskmanager, every day at 22:00 o clock)


1 if not exist C:\PVSW\PBA\bin\ohnedats.txt goto error
2 C:\PVSW\PBA\bin\pvbackup.exe -on
3 xcopy f:\projekt\dats\*.dat g:\backup\projekt\dats\ /E /V /Y /R
4 xcopy f:\projekt\logs\*.log g:\backup\projekt\logs\ /E /V /Y /R
5 xcopy f:\projekt\*.dat g:\backup\projekt\ /V /Y /R
6 C:\PVSW\PBA\bin\pvbackup.exe -off
7 xcopy f:\projekt\*.* g:\backup\projekt\
/EXCLUDE:C:\PVSW\PBA\bin\ohnedats.txt /E /V /Y /R
8 :error

ohnedats.txt contains:
--------schnipp-------------
\dats\
alllog.dat
msglog.dat
lastlog.dat
\logs\
--------schnapp-------------


Usually this works fine, but sometimes (no systematic recognizable) the xcopy in
line 7 still finds *.^^^-files.
This is strange, because the "pvbackup.exe -off" is logged as completes sucessfully.

It looks like, that the command "pvbackup.exe -off" returns too early (before
compeeting its job).

We helped ourselfs by inserting some delay (using somthing like
"ping -n 1 -w 60000 1.1.1.1" = waite 60 Sec) after lines 2 and 7, but this is
not satisfactory.

Does anyone know, why pvbackup returns so early or if one can tell it not to
return befor finishing?

Any comment will be wellcome!

Best reagrds from Jena,

M. Malarski

The Backup Agent is simply using the "Continuous Operations Mode" of
the database. When the ENDBU is received by the engine, the engine
confirms that all files will start the roll-in process (wherein all
changes are rolled out of the delta files into the live files again).

The problem is that this process is ALSO running in tandem with a live
system. While the changes are being rolled back to the live files, new
changes may be recorded at the Delta file -- making the process take
longer. In fact, this roll-in process can easily take in excess of
minutes and even hours in some very busy systems. (Indeed, I've seen
cases of heavily-written files that NEVER can catch up!)

Because of this, the PVBACKUP -OFF cannot be tied to the completion of
the roll-in process, and the only way to ensure that the roll-in is
complete is to wait until all deltas disappear.

Having said that, there are two solutions:

1) Exclude the Delta files from your last XCOPY. This is MUCH easier.
BTW, you may also wish to experiment with XXCOPY or ROBOCOPY -- two
XCOPY replacements that are much more powerful, and that only copy
files that have been changed. These tools can complete the copy job
much faster, with less wear & tear on the HD.

2) Add code in the batch file to loop on the delta files. Something
like:
:Loop
SLEEP 10
IF EXIST *.^^^^^^ GOTO Loop
Note that you must have the SLEEP command in your search path. Also,
note that since the ^ is an escape character for DOS, you must double
it. You can see this if you try a simple "DIR *.^^^" command, which
doesn't work.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Sydney: Pervasive.SQL Service & Support Class - 02/27/06 ***
*** Chicago: Pervasive.SQL Service & Support Class - 03/27/06 ***


nmm wrote:

Thank you! I think I will exclude the Delta files from XCOPY.

I think, that it will not be necessary to use robocopy or xxcopy, because th
xopy-process lasts usually not longer than 10 minutes, which is aceptable...

Regards
M. Malarski

This posting has been simmering in the back of my head for ... it
looks like two weeks now.

First it appears from the batch file that you start backup mode, make
a backup, stop backup mode then make another copy of the data ON TOP
OF the backup that was just made thus wiping out the good backup.

Second, even if I didn't figure out the paths correctly on the first
point, you should not make a backup, particularly with a plain OS file
copy while the data files are not in backup mode. It can can cause
file locking issues with the database engine.

Leonard

On Sun, 05 Feb 2006 10:16:53 -0600, "Bill Bach"
<goldstar (AT) speakeasy (DOT) net> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

thanks for comment.

The batches are not wrong I think:
all databasefiles are located in dats\ and logs\ (with exactly 3 exceptions:
alllog.dat, msglog.dat, lastlog.dat)
They have only extension *.dat or *.log.
So while backupmode is ON, all these files are in backup-mode.
After switching backup mode off, I copy only files that are not affected by the
PSQL engine (excluded via the commandline-option
/EXCLUDE:C:\PVSW\PBA\bin\ohnedats.txt and the content of ohnedats.txt (which is
given)).

so I think, that Bill's answer will do.

Regards
M. Malarski



Leonard schrieb:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (MingW32)
Comment: GnuPT 2.7.6

iD8DBQFD9y9zjJri453BSEQRAieUAKDvXnOYdSah0cJS2BwL9L 7JlKwWUgCfZ6CQ
YYvDa2l8SXUh1/wZMWLGdj8=
=aoVw
-----END PGP SIGNATURE-----