Access 2010 mdb (2003 file format) corrupts on 2008R2 Virtual Server ESXI 5.5

We migrated from a physical environment to all Virtual environment (ESXi 5.5) on HP C7000 Chassis with HP Virtual Connect, BL460c Gen 8 Blades direct connected to a 3PAR 7200 SAN last month.  Since we have migrated all of our Access 2010 mdb (and mde) database are constantly getting corrupted.  We have to get the users out and Compact/Repair sometimes 6 times a day for each of 7 production databases.  

I have one mdb that runs nightly vba code and emails out reports at 2am that has never had a corruption problem until now.  It only has 1 user and most of the linked tables are SQL Server tables.  It does however create numerous temp tables for reporting purposes.  This morning during the scheduled script, the database became unrecognizable, I did a compact / repair and then I noticed that one of the tables was completely missing!  had to restore from a backup.

We have opened tickets with Microsoft, HP Blades, HP Virtual Connect, 3Par all to no avail.

Anyone else having problems with corruption of Access mdb and mde files running on VMware ESXi 5.5?
Who is Participating?
BFanguyConnect With a Mentor Author Commented:
I can add that moving the mdb files to the local 2008R2 Remote desktop server did fix the problem, but I would rather run them form a central file server.  i.e.  it is definitely a Network Setting, whether it be at the VM level or the operating system level.
Andrew Hancock (VMware vExpert / EE MVE^2)Connect With a Mentor VMware and Virtualization ConsultantCommented:
Make sure ALL your VMs are using the VMXNET3 interface, and not the E1000 interface.
BFanguyAuthor Commented:
All the VM's are using the VMXNET3 interface.

When I am in one of the access database linking tables to SQL Server of making form changes from either my physical laptop or a 2008R2 Remote Desktop Server, I experience 30-50 second pauses all day long.    Our Virtual Environment is way under utilized so I do not believe it is a performance issue, but I know access does not like network interruptions.  We are using Symantec EndPoint Protection 12.1.5 on the 2012R2 File Server, but I have put in exceptions on the folder where the access databases are stored.
Making Bulk Changes to Active Directory

Watch this video to see how easy it is to make mass changes to Active Directory from an external text file without using complicated scripts.

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
is this a network issue?

SAN issue ?

performance issue ?

have you done any vmxnet3 tuning ?
BFanguyAuthor Commented:
We could not find any problems with the blades or the san (no logs) with the assistance of HP.  The virtual Connect support group was no help either (no errors in the logs).  I have a 3rd party troubleshooting these "pauses" for the past week, nothing they can pinpoint.

Have not done any vmxnet3 tuning,  can you be more specific?
Jim Dettman (Microsoft MVP/ EE MVE)Connect With a Mentor President / OwnerCommented:
<<is this a network issue?

SAN issue ?>>

 On these points, are the DB files local to MSACCESS.EXE (instance of Access running) or remote?

 If remote, then I would try to make them local and see if the problem disappears (at least with the one DB that runs nightly).  If it's not remote and running locally, then it's something other than network.

 My guess though would be that it's the SAN.   Access itself runs fine under VM's, but there are issues with various OS's and older versions.  2010 though should be fine.

 Other questions are:

1. Were you running under 2008R2 previously or another OS?

2. Did you change from a 32 to 64 bit OS?

BFanguyAuthor Commented:
Andrew,  I found an article on Best practices for Performance tuning of latency sensitive workloads in vmshpere vm's.
will apply the settings from the paper.

Jim,  all of the access databases reside on a 2012R2 vm file server, but they were migrated from a physical 2008R2 server to a 2008R2 VM server and then to a 2012R2 VM (we hoped moving to 2012R2 would fix our corruption problem).

We are running 32bit version of access 2010  (no change)

I like the idea of moving the "Nightly" database locally, but the server that i would be moving it to is also a VM and all of my physical server blades are SAN boots.  Still worth a try.

The other production Access database have to be stored on a File server, because they are accessed from Desktops and 5 different 2008R2 Remote Desktop Servers VMs.
BFanguyAuthor Commented:
I have tried all of the Best practices for Performance tuning.  No change.

I moved the mde files to the local drives of all of my remote desktop servers and we have not had a corrupt mde file since.  This leads me to believe it is a network issue and not a san issue (the remoted desktop servers are virtual and their drives are stored on the SAN.

I do not like having the  mde files on the C Drives of each RDS but for now i can at least take a day off.

Any suggestions on what i should try now that i have concluded it's a Virual Network issue?
Jim Dettman (Microsoft MVP/ EE MVE)Connect With a Mentor President / OwnerCommented:
Well some progress've narrowed things down a bit.   Andrew is THE VMWare expert, so I'll let him comment on the networking.

I will add though that in general with networking, I:

1. Make sure drivers are updated.
2. No diagnostic protocol's are enabled on the adapter (they sometimes will disconnect the adapter from the media, test, then reconnect, which drives JET nuts).
3. No advanced power features are enabled on the adapter (again, will drive JET nuts).
4. If a 1GB connection, fix the speed at 100mbps for a test to try and eliminate cable problems.
5. Test the cable if possible.
6. Monitor for fragmented and dropped packets.  First is tuning, second is a sign of network connection.

 JET overall is very sensitive to network timeouts and latency.   More so than anything else.   it will complain long before other apps will.

Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
Is you network performance in the VM, slow  or appear slow?

Was the network interface tuning, applied in the VM ?
BFanguyAuthor Commented:
The remote desktop servers will pause (lock up) for 20-30 seconds for no reason.  This is what usually causes the corruption.

The tuning was done at the host level.
Andrew Hancock (VMware vExpert / EE MVE^2)VMware and Virtualization ConsultantCommented:
So, you've not adjusted any VM OS parameters, e.g. TCP offload etc

I'll get some links...for you to follow.
BFanguyConnect With a Mentor Author Commented:
Yes,  i had done this about a month ago:

C:\Windows>netsh int tcp show global

TCP Global Parameters
Receive-Side Scaling State          : disabled
Chimney Offload State               : disabled
NetDMA State                        : enabled
Direct Cache Acess (DCA)            : disabled
Receive Window Auto-Tuning Level    : disabled
Add-On Congestion Control Provider  : ctcp
ECN Capability                      : disabled
RFC 1323 Timestamps                 : disabled

C:\Windows>netsh int tcp show heuristics
TCP Window Scaling heuristics Parameters
Window Scaling heuristics         : disabled
Qualifying Destination Threshold  : 3
Profile type unknown              : normal
Profile type public               : normal
Profile type private              : normal
Profile type domain               : normal

Do these look correct?
BFanguyAuthor Commented:
above is what i get from the command prompt, however, if i look at the advanced tab of the adapter i see the following:
IPv4 Checksum Offload - Rx & Tx Enabled
IPv4 TSO Offload - Enabled
Large Send Offload V2 (IPv4) - Enabled
Offload IP Options - Enabled
Offload tagged traffic - enabled
Offload TCP options - Enabled
TCP Checksum Offload (IPv4) - Rx & Tx Enabled
UPD Checksum Offload (IPv4) - Rx & Tx Enabled

not sure why they show as different.
BFanguyAuthor Commented:
any help would be appreciated
Jim Dettman (Microsoft MVP/ EE MVE)President / OwnerCommented:
Thanks for posting back again.

BFanguyAuthor Commented:
Andrew,  I was hoping for those links.
BFanguyAuthor Commented:
Removed all local tables to sql, moved .mde files to local drives on 208R2 virtual servers.

Combination of numerous items, found a workaround, not what we really wanted to do.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.