[SQL Anywhere 126.96.36.19909]
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
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.