We are using SQLAnywherev9.02.3576 and occassionally (once every two
weeks or so) get this error (or a very similar error):

"Central01: *** ERROR *** Assertion failed: 201847 (9.0.2.3576)
Checkpoint log: write to d:\bersys\central.db failed with status 1453:
filesystem may be full or file size has exceeded system limits"

We were on ASA v9.01.2052 and I read some other newsgroup postings
that this problem may have been fixed in a v9.02 ebf, but I am still
seeing the issue.

The server has 8GB of RAM (6GB dedicated to database engine cache).
Out database is 50 GB in size and is located on the D: drive or our
server ( RAID array). There is 78 GB of free space on this volume.
Temp files are also located on this drive.

Any ideas or direction on getting this solved would be most
appreciated.

Thanks,
Brian

1) What is the size of the TEMP file when the error occurs? Is it
possible that the TEMP file has grown to something that large?

2) Have you enabled temp space checking with the TEMP_SPACE_LIMIT_CHECK
option?

3) What OS are you running on? If Windows, is there anything in the
Windows event log pertaining to the disk subsystem (transient errors?)

Glenn

bgreiman (AT) bernicks (DOT) com wrote:
--
Glenn Paulley
Director, Engineering (Query Processing)
iAnywhere Solutions Engineering

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://case-express.sybase.com

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer

1) I have not checked to see what the size of this file could be?
Could it theoretically grow to 75 GB for a 50GB database?
2) We have enabled temp space checking with the TEMP_SPACE_LIMIT_CHECK
option. It is set to ON.
3) Database is on a Windows Server 2003 box. No other issues I could
see from Event Viewer.

Brian




On Nov 26, 9:48 am, Glenn Paulley <paul... (AT) ianywhere (DOT) com> wrote:

bgreiman (AT) bernicks (DOT) com wrote:
The temp file is used, among other things, for spooling intermediate
results that do not fit into memory. Consequently the size of the temp
file can have little to do with the size of the database; rather, it is
very workload dependent.

For example, take the DEMO database that ships with the SQL Anywhere CD
- the tables are small, and the entire database is only 2.8 MB. However,
if one performs

SELECT DISTINCT *
FROM PRODUCTS CROSS JOIN SALESORDERITEMS CROSS JOINS SALESORDER .....

that will create an extremely large intermediate result in the
neighbourhood of 6 billion (or so) rows, each of which is about 1K.

One other idea that comes to mind - create an EVENT that posts a message
to the console window (say, once a minute) with the result of querying
the following properties (see the help for precisely how to do that):

extendtempwrite
temptablepages
filesize
checkpointlogpageinuse
checkpointlogsize

That may help pinpoint where the problem lies.

Glenn

--
Glenn Paulley
Director, Engineering (Query Processing)
iAnywhere Solutions Engineering

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://case-express.sybase.com

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the iAnywhere
Developer Community at www.ianywhere.com/developer

Despite the error text, free space is not likely to be the problem.

Error 1453 is almost always related to disk driver bugs. It generally
happens in systems with >4GB RAM and where either the driver or the card
itself can't handle transfers from physical memory addresses >4GB. In
that case, the OS uses a finite pool of buffers in the <4GB address
range to do the IO and when you run out, you get error 1453. Running out
can be caused by drivers that leak buffers or, conceivably, a momentary
over-demand for those buffers. In the version of software you are using,
SQL Anywhere will retry the operation 100 times so that should largely
cover momentary over-demands. I would start by looking for updated disk
drivers.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Glenn Paulley wrote:

John,

Some time ago we had problems at a customer on a server with more than
four GB of RAM which we could not reproduce on other servers.
Could that be connected?

The problem occured during LOAD TABLE for a huge table, and the error
messages were:
ODBC communication error SQLSTATE=08S01 (maybe as the server engine just
had crashed).
The db engine crashed with the message "Windows - Application error. The
instruction at "0x77f87eeb" referenced memory at "0x00000014". The memory
could not be "read".

ASA 9.0.2.3182 and 9.0.2.3169 gave similar results, and Sybase support
could not reproduce the issue either.

Frank


On Tue, 27 Nov 2007 12:32:41 +0100, John Smirnios <smirnios_at_sybase.com>
wrote:

It doesn't sound like the same problem but it does sound like the server
crashed. If it was reproducible on that machine, tech support should
have been able to get you to save a minidump so that we could see where
it was crashing.

-john.

--
John Smirnios
Senior Software Developer
iAnywhere Solutions Engineering

Whitepapers, TechDocs, bug fixes are all available through the iAnywhere
Developer Community at http://www.ianywhere.com/developer

Frank Ploessel wrote: