[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?

asked 15 Oct '12, 12:16

Luke's gravatar image

Luke
711152336
accept rate: 40%

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

(15 Oct '12, 12:57) Justin Willey
Replies hidden
  • 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?
(15 Oct '12, 13:10) Jeff Albion
Replies hidden

Yes (all steps are on the same machine)

(15 Oct '12, 13:25) Luke

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.

(15 Oct '12, 13:29) Luke

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.

(15 Oct '12, 17:01) John Smirnios

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.

permanent link

answered 15 Oct '12, 15:11

John%20Smirnios's gravatar image

John Smirnios
11.9k396165
accept rate: 37%

edited 15 Oct '12, 15:17

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.

(16 Oct '12, 03:35) Luke
Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×17

question asked: 15 Oct '12, 12:16

question was seen: 3,073 times

last updated: 16 Oct '12, 04:06