update.php vs. multisite shared tables

I run Drupal in a multisite environment. The default site is the "main" site and the other sites are for various subsets of the organization.
http://main.example.com
http://site1.example.com
http://site2.example.com
...
http://siteN.example.com

Each site has its own MySQL database
main
site1
site2
...
siteN

Certain tables are shared by all sites and live in the default database. Default db tables are not prefixed, other site db tables are. sites/site1/settings.php includes:

'prefix' => array (
        'default' => 'site1_',
        'role' => 'main.',
        'users' => 'main.',
  ),

When doing a major or minor core upgrade or module upgrades, it is necessary to run update.php on each site so that the db updates will be applied to each site's database. I run
http://main.example.com/update.php first, followed by
http://site1.example.com/update.php
http://site2.example.com/update.php
...
http://siteN.example.com/update.php

The run of http://main.example.com/update.php goes just fine. All of the updates are applied to the database including those tables that are shared with all the other sites. However, the http://site*.example.com/update.php runs don"t go so well. Any update to a shared table will fail because the table has ALREADY BEEN UPDATED by a previous run. I have thought of three possible solutions, so far.

1. Do nothing, let the redundant updates blow up. This is what I've done so far but this approach doesn't seem to be working out for my D6 -> D7 upgrade.

2. After updating the main site, hack the module code to comment out redundant updates. Fine, but I don't know how to do that.

3. Build a script that will undo the updates to the shared tables and run it before each site* update so that the redundant updates can reupdate the shared tables. This may turn out to be what I need to do.

If you have found a way to deal with this situation, I am eager to benefit from your experience.