Intermittent 'Invalid argument' error reloading database

[Former Member]

[SQL Anywhere 9.0.2.3609]

Following this basic process for one of our databases:

1) use dbunload.exe to unload the database (internal unload, internal reload)
2) use dbinit.exe to create a new database
3) use dbisqlc.exe to execute the reload.sql from 1) against the database created in 2)

We sometimes get an error of the form:

Error in file "c:\\dbreload\\reload.sql" at line 1234
Cannot access file 'c:\\dbreload\\unload\\123.dat' --
Invalid argument

When the error occurs the statement in question is always a LOAD TABLE against the same table, which happens to be the largest table in the database in terms of page usage. The table is essentially a set of files from other applications stored as blobs and has a size in the order of hundreds of gigabytes when unloaded.

What's puzzling is the fact that the error doesn't always occur. The message 'Invalid argument' doesn't give us much to go on so I was wondering if anyone else had experienced this and had any suggestions of what we could look at?

[justin_willey]

Was the db un-loaded with the same ASA/SQLA version that it is being re-loaded with?

[jeff_albion]

• Which version of Windows is this on?
• What file system is the C: drive? (NTFS, FAT32)?
• How big is the file when you see this error?

[Former Member]

Yes (all steps are on the same machine)

[Former Member]

It's Windows 2003 Server, the file system is NTFS. I don't have the exact file size to hand but it's around 500GB.

[johnsmirnios]

Is it safe to assume that you have applied the service packs to your Windows 2003 system? Windows 2003 GA (pre-SP1) was particularly bad at generating WORKING_SET_QUOTA_EXCEEDED errors due to buffer leaks in certain disk drivers. We had to disable support for AWE caches on 2003 GA because the leaks were exacerbated by the use of AWE and could lead to a BSOD as well as working set errors.

[johnsmirnios · Accepted solution]

What you are seeing is consitent with the OS reporting a read error but not a common read error. In v9, all of the OS errors get translated to a POSIX equivalent if there is an equivalent but there is a large number of rarely-reported Windows errors that get translated to EINVAL (invalid argument). Newer versions of SA do not do that translation and should display the proper OS error.

You could use procmon to monitor the file activity and find out what error is being reported by the OS or try with a newer version of SA. If it is something that SA is doing incorrectly (and, if so, I think you're the first to report it) it might already be corrected in newer versions since IO for reading the input file has changed over the years since v9.

We have encountered buggy disk drivers in the past that periodically report "working set exceeded" and other oddball errors periodically. If you are on an older OS or have non-standard IO controllers, it may be worth seeing if there are patches available for your disk drivers.

[Former Member · Accepted solution]

Thank-you John, that's very helpful. We plan to get this system upgraded to a current version of SQL Anywhere at some point but in the meantime I'll make sure it is running the latest service packs and disk drivers.