ERRRRRRRRRRR, trouble with updating my big moodle instance

I am being a good boy and practicing the upgrade of my largest of our moodle instances, by creating a test instance and upgrading it.  Good thing, or my stress level would be through my nose.

The site I am updating is at present 2.2.  I have created a test DB and have a script that restores the nightly backup to the test DB.

Restoring the nightly DB to the  test_DB

*** open a command window and change to the mysql bin directory
c:\> cd\wamp\bin\mysql\mysql5.5.24\bin

**** start a mysql session that connects to the test_DB to restore to
**** use an account defined in the sqlserver (I use phpMyAdmin)

c:\wamp\bin\mysql\mysql5.5.24\bin>mysql -u root -p test_DB

**** specify the password for the account
 *** from the mysql prompt:
mysql> source pathtobackupfile\backupfilename.sql


I am following the recommended process of upgrading through each moodle increment, which means after I restore the DB, I am upgrading  5 times.

2.2 - 2.11, 2.11 - 2.3.11, 2.3.11 - 2.4.9, 2.4.9 - 2.5.5, 2.5.5 - 2.6.2.

That is a lot of work.  But, I understand why we should do this.  Each incremental upgrade changes the DB, if you skip an upgrade, you may miss a tweak to the DB that is needed in the next increment.  Im sure that is not intentional, but it makes sense.

My DB is about 515 MB.  So everything is slow.  I should say each DB upgrade step of the upgrade is slow.

The current problem I am having is the instance basically timing out during the upgrade.  I can get past the 2.11 step easy enough, not a ton of changes there, but when I get to 2.3.11, where there are a lot more DB changes, the upgrade starts, steps through the predictable steps of announcing the new code in place and how the DB will be updated, then to the server check, then the plugins check, then......the DB updates.  After about 3-5 minutes, the page stop responding, so I force a browser re-read of the page and it jumps back a step to the plugins, I kick it off again, and so the cycle continues......

ERRRRRRRRRRRRR - after a while, I end up punting, which means restoring the 2.2 DB again to the test DB, removing the 2.3 code from the instance root, re-deploying the 2.2.11 code and trying again.

I should mention that I have downloaded each moodle instance and upzipped to a sage location on my server so I am at least not having to download and unzip the moodle code again.  BUT, restoring the DB and starting back at the beginning of the line (2.2.11) is very frustrating.

The last time I did this, and completed the 2.2.11 update - I removed a bunch of courses from the DB that we wont be using in the fall, hoping this will help the overall process by reducing the size of the DB.  Before I kick off the next upgrade to 2.3.11 - I backed up the *updated test DB, so if i have to start over again, I don't have to manually delete the 40 courses again.

I did this by going to the command line and using mysqldump, like this

c:\> cd\wamp\bin\mysql\mysql5.5.24\bin
c:\wamp\bin\mysql\mysql5.5.24\bin> mysqldump -uroot -pmypassword --result-file= "path_to_file\newDBname.sql" test_dbname

Mysqldump took about 5 minutes to create the file, but upon completion, there it was.

While attempting the 2.2.11 to 2.3.11 upgrade, i encountered this error

Really?, a field not defined in the mdl_files_reference table?

Come on  Man!

This is the other error I can not see to get around.  I have encountered it in almost every upgrade scenario I have tried.  Meaning upgrading from current version to 2.4, 2.5, 2.6 including skipping 2.4, 2.5.

When I did the upgrade in place a couple weeks ago for one of the instances, I did not see this error.  That was going from 2.3.2 - 2.6.  When I upgraded my 5 other sites from 2.3 or 2.4 to 2.6, I did not see this error (thankfully, since I was updating the live instances).  At least now I am experiencing these problems with test instances. 

MAKES ME THINK MY TEST INSTANCES ARE THE PROBLEM, however, one of the three test instances upgraded fine!

Man, this is frustrating stuff.  BUT, I am glad to be experiencing this in my test instances and not when upgrading a live instance.  At least now, once I resolve this, if i encounter something like it during the live upgrade, I have a point of reference or a workaround. 

THIS IS WHY YOU SHOULD ALWAYS TEST AN UPGRADE FIRST, before upgrading a live instance.