MUPIP> backup
Region: DEFAULT
Backup Directory: /zappy1/backup
%GTM-E-BACKUP2MANYKILL, Too many large kills in progress to start operation. Try again later.
All the databases have been rundown so I'm not sure what is causing this to happen. As far as I know there shouldn't be any large kills (how big is a large kill?) happening in this application anyway.
GTM>w $zv
GT.M V5.3-000 Linux x86
Any ideas?
George
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is because the database file header has a counter "Kills in Progress" (can be seen with DSE DUMP -FILE) with a non-zero value. Likely if you could have killed processes that were in the midst of a KILL operation or have killed a MUPIP REORG command.
The safest way to fix this would be for you to run a MUPIP INTEG on this database. That should fix this counter if there are no other integrity errors.
GT.M V5.3-003 has enhancements in this area that differentiate between kills that are in progress currently versus kills that are abandoned (incomplete because the process was killed before it could finish it). Because of this, in GT.M V5.3-003, MUPIP BACKUP would have run fine in your case (without issuing the BACKUP2MANYKILL error). So upgrading is a good idea.
Hope this helps.
Narayanan.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm getting this:
MUPIP> backup
Region: DEFAULT
Backup Directory: /zappy1/backup
%GTM-E-BACKUP2MANYKILL, Too many large kills in progress to start operation. Try again later.
All the databases have been rundown so I'm not sure what is causing this to happen. As far as I know there shouldn't be any large kills (how big is a large kill?) happening in this application anyway.
GTM>w $zv
GT.M V5.3-000 Linux x86
Any ideas?
George
This is because the database file header has a counter "Kills in Progress" (can be seen with DSE DUMP -FILE) with a non-zero value. Likely if you could have killed processes that were in the midst of a KILL operation or have killed a MUPIP REORG command.
The safest way to fix this would be for you to run a MUPIP INTEG on this database. That should fix this counter if there are no other integrity errors.
GT.M V5.3-003 has enhancements in this area that differentiate between kills that are in progress currently versus kills that are abandoned (incomplete because the process was killed before it could finish it). Because of this, in GT.M V5.3-003, MUPIP BACKUP would have run fine in your case (without issuing the BACKUP2MANYKILL error). So upgrading is a good idea.
Hope this helps.
Narayanan.
One clarification. You need to run the following command to fix the bad counter.
MUPIP INTEG -FILE <dbfile>
Running MUPIP INTEG -REG (which does not require standalone access to the database) will not fix the issue.
Narayanan.