E
Everett
We provide a Visual Basic 6 application using an Access 2000 format database
accessed by the Jet 4.0 driver. We have 2 customers who recently purchased
high end Windows Server 2008 (one Standard 32bit w/ SP2, the other Enterprise
64bit w/ SP2) and are seeing simple select and update queries against the
main table containing less than 10,000 records take 5 minutes instead of
about a second that we see on other systems. The queries showing the behavior
include WHERE clauses on nonindexed fields. We have a Server 2008 standard w/
SP2 test system in house that does not show the behavior.
We have created 2 versions of a small application (VB6/ADO and C#/ADO.Net)
that simply opens a connection to the database and runs test queries against
this table, which still reproduces the problem on these customers' systems. A
few sample queries are "select Field1, Field2, Field3 from Table where Field4
is null or Field5 = True order by Field6" and "select count(*) From Table
where Field1 > 0 AND Field2 > 0". Without the WHERE clauses the queries
execute as expected.
We have used Process Explorer to verify the app's memory working set is not
high enough to cause disk paging or other expected performance issues. We
have used Process Monitor to record the activity during these queries. What
we're seeing are reads to the mdb file in mostly 4k blocks.
The first 10%-20% of the query executes these reads very fast:
....
"1:29:59.2200157
PM","App.exe","3380","ReadFile","H:\...\dbname.mdb","SUCCESS","Offset:
12,599,296, Length: 4,096"
"1:29:59.2200273
PM","App.exe","3380","ReadFile","H:\...\dbname.mdb","SUCCESS","Offset:
12,615,680, Length: 4,096"
"1:29:59.2200377
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 12,619,776, Length: 4,096"
....
The amount of time to execute each 4k read is about .00001 second here.
After this first part, the read time drops to about .06 seconds per 4k read:
....
"1:30:06.4564982
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 16,416,768, Length: 4,096"
"1:30:06.5189267
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 16,429,056, Length: 4,096"
"1:30:06.5812699
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 16,449,536, Length: 4,096"
....
This does not always occur in the exact same place in the full read, and not
on every query every time. We are not seeing any other processes interrupting
and causing this delay.
All Jet settings from the registry and connection string are identical
between systems showing the behavior and not. All unnecessary services have
been disabled including antivirus.
We have a log generated using BidInterface tracing but don't see anything
obviously wrong, although I'm still working to decipher this type of trace.
Any troubleshooting suggestions are appreciated, and I can provide more
information in a particular area as needed. Our next step is to have the
customer's run in safe mode to try and rule out 3rd party software/drivers,
but I thought I'd check here for possible help as we've already spent weeks
on this issue.
Thanks!
accessed by the Jet 4.0 driver. We have 2 customers who recently purchased
high end Windows Server 2008 (one Standard 32bit w/ SP2, the other Enterprise
64bit w/ SP2) and are seeing simple select and update queries against the
main table containing less than 10,000 records take 5 minutes instead of
about a second that we see on other systems. The queries showing the behavior
include WHERE clauses on nonindexed fields. We have a Server 2008 standard w/
SP2 test system in house that does not show the behavior.
We have created 2 versions of a small application (VB6/ADO and C#/ADO.Net)
that simply opens a connection to the database and runs test queries against
this table, which still reproduces the problem on these customers' systems. A
few sample queries are "select Field1, Field2, Field3 from Table where Field4
is null or Field5 = True order by Field6" and "select count(*) From Table
where Field1 > 0 AND Field2 > 0". Without the WHERE clauses the queries
execute as expected.
We have used Process Explorer to verify the app's memory working set is not
high enough to cause disk paging or other expected performance issues. We
have used Process Monitor to record the activity during these queries. What
we're seeing are reads to the mdb file in mostly 4k blocks.
The first 10%-20% of the query executes these reads very fast:
....
"1:29:59.2200157
PM","App.exe","3380","ReadFile","H:\...\dbname.mdb","SUCCESS","Offset:
12,599,296, Length: 4,096"
"1:29:59.2200273
PM","App.exe","3380","ReadFile","H:\...\dbname.mdb","SUCCESS","Offset:
12,615,680, Length: 4,096"
"1:29:59.2200377
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 12,619,776, Length: 4,096"
....
The amount of time to execute each 4k read is about .00001 second here.
After this first part, the read time drops to about .06 seconds per 4k read:
....
"1:30:06.4564982
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 16,416,768, Length: 4,096"
"1:30:06.5189267
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 16,429,056, Length: 4,096"
"1:30:06.5812699
PM","App.exe","3380","ReadFile","H:\...\dbname\AutoMail.mdb","SUCCESS","Offset: 16,449,536, Length: 4,096"
....
This does not always occur in the exact same place in the full read, and not
on every query every time. We are not seeing any other processes interrupting
and causing this delay.
All Jet settings from the registry and connection string are identical
between systems showing the behavior and not. All unnecessary services have
been disabled including antivirus.
We have a log generated using BidInterface tracing but don't see anything
obviously wrong, although I'm still working to decipher this type of trace.
Any troubleshooting suggestions are appreciated, and I can provide more
information in a particular area as needed. Our next step is to have the
customer's run in safe mode to try and rule out 3rd party software/drivers,
but I thought I'd check here for possible help as we've already spent weeks
on this issue.
Thanks!