Did follow the instructions from Milbo and did set the upDelCols=0 on all possible cfg files for virtuemart. Did truncate the config entry in the database and did restore it by the backend function. So in the database the upDelCols=0 was integrated. I am using two servers, a MAMP localhost and a live server. So the first thing was to try the live update on the localhost. Result: additional database fields were deleted after the update. Did backup the database on the live test server and tried there the live update: result: no update because xml file was not found.
So for users with individual database changes by adding additional rows I just can recommend not to update a live shop. You may loose your data. I my case I would loose the sync rows for the distributor import. While for the products it should not be a problem, the sync rows can be added as custom fields. But there are no custom fields for categories.
So what to do? The way I did was to clone the database on the live server with plesk to have a backup. Did download the vm 2.0.8, unpacked it and did upload the unpacked files to the tmp folder of the server main webpage directory. Did choose the standard install way from joomla and everything worked. But as already told, the additional database fields were deleted. VM 2.0.8 does not seem to change database entries, so the database structure remains the same as in VM 2.0.6. The update procedure just reported, that it did delete some rows (i.e. everythting what was user added). So it does not matter to use the upDelCols=0 or not. VM will delete everything what was added by a user into the database.
Still asking myself why such a nasty installation procedure is needed? It would obviously be better, if necessary, to just update the database if new entries are necessary. I do not understand why the developers use a function (by default) to delete rows. The proposed way to add upDelCols=0 obviously does not work. It did not work with MAMP on a Mac and it did not work with RedHat/Centos on my life server. And I am pretty shure that it does not work too with a Debian server.
And what will happen if a VM update needs to change database entries to extend something? The cloning method is possible with VM 2.0.8 but maybe not with a newer VM version.