Today I tried to backup two ADABAS-files of our Database (213-214) while many users are working. It is impossible that anybody works on that files during daytime. I thought, this backup can’t cause problems.
So I typed the following on the Linux command-line:
adabck db=11 dump='(213-214)'
But then, the Database was waiting for a so-called “ET_SYNC”. The utility adaopr said, that an “ET_SYNC (phase 1)” is in progress. I displayed the hold queue. There was only one entry: A single record of file 181. The adabck was waiting and waiting …
Meanwhile many users tried to make updates/stores (but not on file 213-214). The regarding dialogs were waiting to.
So I stopped the user that held the one record on file 181. After that, the utility adaopr told me someting about “ET_SYNC (phase 2)” and a full command queue. The hold-queue had 30 entries. But adabck and the users were still waiting. Now it was impossible to do anything. Even a shutdown of the database didn’t work (because of the full command queue?). So I killed the adabck with linux. Nothing happens. Now it was impossible to do a reset on the ucb anyway.
The only solution was to restart the whole computer.
My Questions:
It’s sure that only the adabck accessed the files 213-214 today. Why does an adabck wait for ET_SYNC? That seems completely needless to me.
Adabas obviously blocks updates on files 10-200 during a backup of file 213-214. Why?
Is it possible to stop a transaction that causes the ET_SYNC?
What is the difference between phase 1 and phase 2 of ET_SYNC?
What to do better next time?
By the way: Parameter TT of the Database is set to 7200.
Please read the documentation: Utilitie manual - ADABCK - dump, You can read there:
If the nucleus is running in parallel (online backup), ADABCK ensures that all transactions are completed by all users before ADABCK terminates. Therefore ADABCK waits at the end of dump until all users reach ET status. The nucleus doesn’t start new transactions within this period. This is called ET_SYNC.
This is also relevant for a file dump, as in your case.
As I understand your problem, you should use not “dump” but “exu_dump”.
In the “exu_dump” case only ACC users are permitted on the files to be dumped while the dump is in progress. There is no ET-synchronisation.
Now answers to your questions:
1: It is the way like the dump works to be sure to have a consistency state of the BACKUP and PLOG file. (During a ET_SYNC there starts also a new plog file)
2: similar to point (1)
3: Why do you want to do it.
4: Phase 2 is reached when all users at ET_SYNC status.
5: use “exu_dump” in your case.
The funny thing is: I did such a kind of backup several times without any problems. It seems like it takes only one unfinished transaction to cause that kind of deadlock. If ADABCK is started and there is no way back, it would be an option to stop this transaction, so ADABCK can proceed.
OK. This Phase was reached in my case, but the command queue was full then. So we run from one deadlock to the next one.
1: with "adaopr dbid=xxx stop=‘ID’ " you can terminate users!
2: with “adabck dbid=xxx dump=(x,x) et_sync_wait=number”
you can define the time that ADABCK waits for ET-logic users to come to ET.
For further information to this utilities please read the documentation!