# adabck dump='(213-214)' causes deadlock **URL:** \ **Category:** Forum\ **Tags:** Adabas-Natural, Adabas, Adabas-Basics-on-Linux-Unix-Windows, Adabas-on-Windows-UNIX, Adabas-on-Linux\ **Created:** [November 7, 2005, 10:10pm UTC](https://techcommunity.softwareag.com/t/adabck-dump-213-214-causes-deadlock/57815 "2005-11-07T22:10:13Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [November 7, 2005, 10:10pm UTC](https://techcommunity.softwareag.com/t/adabck-dump-213-214-causes-deadlock/57815/1 "2005-11-07T22:10:13Z")
Hello Forum! 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: ```auto 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: 1. 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. 2. Adabas obviously blocks updates on files 10-200 during a backup of file 213-214. Why? 3. Is it possible to stop a transaction that causes the ET\_SYNC? 4. What is the difference between phase 1 and phase 2 of ET\_SYNC? 5. What to do better next time? By the way: Parameter TT of the Database is set to 7200. Many thanks in advance, Matthias ---
**Author:** ![Heiko\_Kaffenberger](https://avatars.discourse-cdn.com/v4/letter/h/c0e974/32.png) [@Heiko\_Kaffenberger](https://techcommunity.softwareag.com/u/Heiko_Kaffenberger)\ **Post date:** [November 16, 2005, 6:15pm UTC](https://techcommunity.softwareag.com/t/adabck-dump-213-214-causes-deadlock/57815/2 "2005-11-16T18:15:15Z")
Hello Matthias, at first a general info to your question: 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. I hope this will help you. * * * Kind regards Heiko ---
**Author:** ![Matthias1](https://avatars.discourse-cdn.com/v4/letter/m/9fc348/32.png) [@Matthias1](https://techcommunity.softwareag.com/u/Matthias1)\ **Post date:** [November 16, 2005, 7:21pm UTC](https://techcommunity.softwareag.com/t/adabck-dump-213-214-causes-deadlock/57815/3 "2005-11-16T19:21:09Z")
First of all: Thanks for answering! > [@hkaf](#): > > 3: Why do you want to do it. 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. > [@](#): > > 4: Phase 2 is reached when all users at ET\_SYNC status. 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. > [@](#): > > 5: use “exu\_dump” in your case. I’ll do it the next time. Thanks! ---
**Author:** ![Heiko\_Kaffenberger](https://avatars.discourse-cdn.com/v4/letter/h/c0e974/32.png) [@Heiko\_Kaffenberger](https://techcommunity.softwareag.com/u/Heiko_Kaffenberger)\ **Post date:** [November 16, 2005, 9:34pm UTC](https://techcommunity.softwareag.com/t/adabck-dump-213-214-causes-deadlock/57815/4 "2005-11-16T21:34:03Z")
Hello Matthias, two additional statements: 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! Regards Heiko ---
**Author:** ![system](https://global.discourse-cdn.com/techcommunity/original/3X/c/d/cd19967bb605d28a72d77eb83a1cae22f3df2eb8.svg) [@system](https://techcommunity.softwareag.com/u/system)\ **Post date:** [April 2, 2021, 2:38pm UTC](https://techcommunity.softwareag.com/t/adabck-dump-213-214-causes-deadlock/57815/5 "2021-04-02T14:38:53Z")