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;
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.
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.
i removed all protocols, except TCP. but there is no change.
And there is a fail.sql. Check Databases was ok.
126.96.36.19979 -- 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.
#cur=26 #db=12 #pr=306 #ps=512000 #lk=0 lfv=0,0,0,0,0
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
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.
unload database $NUL overwrite;
Yes, the NUL only has one L and the 'everwrite' is necessary.
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.
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.
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.
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....
Who is online
Users browsing this forum: No registered users and 0 guests