Are you actually trying to run the database from both sides of a SAN at the same time? Is this a "standard" SAN such as, say, EMC-square or Fujitsu or IBM or one of the other commercial SAN boxes? This is a true SAN, right? In the sense that the remote side of the SAN doesn't even have to have a computer running to have an update complete? It is just a big file server with a secondary internal networked pathway to a partner SAN some distance away, right?
If this is what you have, you cannot do this. I can think of NO case in which this will work reliably without somehow coordinating this. Tell your folks who said "NO LAN" that The_Doc_Man, who works with SANs running from New Orleans to San Diego (a bit more than 190 miles) daily, has told you that you cannot do this. I'm serious. Invite them to provide questions for this thread.
Here is the problem: SANs usually don't understand file systems. They are per-track devices that (typically) send a track at a time from point A to point B. The problem is, the file system at point B never sees the changes made by SAN transfer from point A. Note carefully that I said "File System" and not "Disk." This leads to the problem known as destructive interference.
On a SAN, one side is typically the "master" and the other is the "slave" - which then establishes a preferred direction of data transfer. For sake of discussion, call these sites Primary and Backup sites. (Admittedly, this is just a conventional name for discussion. But there is a hint of experience in making the choice.)
Here is what happens mechanically. The Primary-side SAN hosts disks. Your server modifies files on those disks. The SAN notes that a write occurred to at least one block on a specific track. This causes a "track discrepancy" between the primary and backup sites. So either as a continuous or a scheduled action, the primary side SAN sends a copy of the modified track to the backup-side SAN equivalent disk. Given the distance is 120 miles, I sincerely doubt you have the network infrastructure to provide the "hot network" required for true, "continuous mirror" data replication. You are probably running in a mode that either does burst-mode updates every few minutes, or you run updates on a daily basis only.
OK, let's say that whichever way you are running, an update just occurred. Now, if you are running the database on the backup-side SAN disk, what has just happened is that the data cached in memory no longer matches the data on the disk, because the SAN has a non-system data path for updates. So the file system and its associated caches in the CPU no longer "knows" what is on the disk. And the SAN, being track oriented, is unlikely to know how to properly invalidate the file system cache for the affected tracks. This is the exact moment at which your corruption occurs, and the flaw cannot be corrected as long as you want to run this way.
The problem gets worse. Did you want the machine on the backup-side SAN to make a change that will reach the primary-side SAN? Unlikely because for most SANs I've run into, that direction always loses. If there IS a primary/backup configuration, daily data transfer is one-way. So changes made at site 1 are immediately lost the moment that site 2 runs an update. Or vice versa.
It is database suicide to run active databases on both sides of a SAN at the same time unless you are doing it the way ORACLE wants you to do it - don't replicate the database host disk. Instead, send transaction files separately and apply them. Even with that, if the backup-side Access was making changes, they will be lost.
I cannot stress how dangerous it is to run both sides of a SAN at the same time. Tell the bosses that they can't do this. You can't even run the database in read-only mode from that SAN drive. It just cannot be made to work reliably.
Don't get me wrong. I need my SANs to work correctly so that we can flip function between our New Orleans and San Diego sites when required. But one side is always the master and the other side is always the slave no matter HOW we are running our SAN. It is just the nature of the technology.
