Snapshot Backup

[andlas63]

Hello everybody,

we switch from to SQLBase 11.0.2 on Win Server 2008 R2 to 12.0/64Bit on Win Server 2012 R2.

Everything seems to work fine, but SQLBase chrashes, when running our backup job.

The backup ran over years with 11.0.2 without errors. We've multiple databases and do the backup with a batch wich calls the following script for each database:

set server SERVER1/***;
connect database sysadm/***;
backup snapshot from database to E:\SQLBASE120\backup\database;
backup logs from database to E:\SQLBASE120\backup\database;
disconnect database;

Are there any known issues about that? Do I have to use a specific Isolation level?

We working 24/7, so i need a solution with logged in users.

Best regards,

Andreas Laschet

[FRBhote]

Any FAIL.SQL?

[Mike Vandine]

Hi,

Can I see your server's sql.ini file?

Do you use RC isolation level?

Best regards,

[andlas63]

Hi Mike,

i send you a mail with the sql.ini.

Our newer programs use RC. Setting autorc=1 result in problems, so i turned it off.

As you see, we've multiple databases. The BatchJob backup them up one after the other. It is not always the same database, where the server crashes.

And there is no fail.sql.

Best regards,

Andreas laschet

[andlas63]

Hi all,

i removed all protocols, except TCP. but there is no change.

And there is a fail.sql. Check Databases was ok.


12.0.0.10579 -- 2015-09-24-12.04.29.895000
00803 Fatal SQLBase System Failure (ROW UEP)



Reason: This is a Fatal Error.



Remedy: Stop all database operations and run a CHECK DATABASE operation.

If a FAIL.SQL file is available, then save it. Attempt to

reproduce the problem via a SQL script, scenario, or using the

NETLOG utility (see the DBA Guide for how to produce a NETLOG).

Contact your local Gupta certified technical support center.
System data
#cur=26 #db=12 #pr=306 #ps=512000 #lk=0 lfv[]=0,0,0,0,0
Databases
fnm=GF141 dfd=1 tfd1=0 tfu1=0
lpa=879268 lpw=879197 nat=0 use=0 flg=524288
lfd=2, clf=28 lfs=10000 cti=1 flg=12 nlb=24 nsl=0 spn=0
cpp 28:2560 cpl 28:3584 ftp 0:0 fap 28:2560 fbl=22 lbl=22
......

[Mike Vandine]

Does the entry in the fail.sql file match the time that the failure occurred with the backup?

You've got a corruption on one of the databases in your list that a check database is not picking up.

You need to try unloading these databases. You can do that using a 'dummy' output device and not actually do a 'real' unload.

connect <dbname>;
unload database $NUL overwrite;

Yes, the NUL only has one L and the 'everwrite' is necessary.

Best regards,

[andlas63]

Hi Mike,

i unload every database in the way you described. No Problems and no errormessages. Every unload completed successfully.

Yes, the entry match the time of a backup failure.. I'll have a next try to backup today.

Best regards,

[FRBhote]

Advisable to Unload and load the failed database.

[andlas63]

Hi all,

yesterday, i unload/load the database. And as i expected, without other user logged in, the backup completed successfully. Today i tried to backup again. Result: Server Crash without fail.sql, while backing up the same database. All other database-backups are fine.

Best Regards,

Andreas Laschet

[Mike Vandine]

Hi Andreas,

That is really strange. So this is only an issue with someone else logged into the database.

Do you have the CrashReporter turned on to send a dump to Gupta on crash? That might be worthwhile to do as well. Just run it and make sure you tick the box about producing the dump for a service. Also untick the box to delete the dump file, since you may need to send that to me if the email doesn't work.

Best regards,

[andlas63]

Hi Mike,

are there any new findings with the dump file, which i sent to you?

Best regards

Andreas

[Mike Vandine]

Hi,

I sent the dump to the Developers to have a look at. They would like to have a bit more info in the dump. It was pretty basic. What level of dump do you have specified with the crashreporter? Can you up that one level to get a bit more info?

The dump just said that the thread tried to read or write to a virtual address that they didn't have permissions to.

The fail.sql file showed a ROW UEP error, indicating that there was a corrupted row in the database. I don't see how that could have occurred unless the corrupted page was the database control page, since that is the only page that is read during a backup. Everything else is done somewhat externally, i.e. the .dbs file is copied to the backup directory as a .bkp file and the DB control page updated to say that it's a backup.

So I suspect that the 803 error is a red herring.

If you get another dump and we still can't figure this out, we might need to do a netlog to see everything that gets passed to and from the server during the backup.

Best regards,

[Plasti]

Dear all,

we have the same problem, snapshot backup crash our dataBase.
Any solutions?

My company works 24h/24h and we cannot ask to all users to logoff from the system in order to have a copy everyday.....

[Mike Vandine]

Hi Mauro,

What error are you getting? Does this crash the whole server or does just the backup job crash?

Are you trying to do a segmented backup?
How big is your database?

Best regards,

[Plasti]

Dear Mike,

we cannot use the simple "backup Snapshot" from SQLtalk because every time that the BCK is running the DataBase crash itself.
We tried to use another copy of the DB and if we launch the bck snapshot and we try to launch a Query the results is that the db crash and the table involved in our query Table is corrupted.

We launched, after this crash, the Check DB and "magically" the DB is checked without problems and the table is not corrupted....