Home | The Company | Publications | Products | Links | Tips |
---|
Fast copy of data processes in two steps:
The update nucleus will be switched to read-only, the update requests are queued for a pre-defined time window, and the snapshot then will take place. After that, the nucleus switches back into the update mode, the suspended/queued commands will be resumed, all open transactions will be finished, and data are transferred to the disk. This read-only mode during the "SNAPSHOT" should only take seconds, as users reported. The copy process itself can take minutes or hours and does not (should not?) influence the continued update mode of the ADABAS nucleus.
This fast copy will be integrated into ADABAS Delta Save and handled via the ADABAS Manager in a later ADABAS version, probably version 8.
ADA742 has the ability to suspend and resume transactions so you might be able to use this feature to stop ADABAS updates for a few seconds during the snapshot to copy pointers, for example
ADADBS TRANSACTIONS SUSPEND,TTSYN=60,TRESUME=120
The SUSPEND function will held new transactions in the command queue, the buffers are flushed, and a SYNC-73 checkpoint is written. If the copy pointers process completes before the TRESUME timeout and the RESUME function is issued, the nucleus writes a SYNS-74 checkpoint, leaves the suspended state and resumes update processing. For a complete handling of processes, please see Utilities Manual, Version 7.4, Volume 1, pp. 209. The question will be whether the DBA's have to increase dramatically the number of command queue elements (NC), 192 bytes per element, to queue all commands during the read-only time (TRESUME)? To increase the number of command queue elements (NC) to the same amount of number of users (NU) should be sufficient, as discussed at the Roundtable event during the Natural Conference 2004 in Boston.
I think it is very dangerous to use FlashCopy 2 even with the option "consistency group" and to not bring ADABAS down or putting it into a read-only mode, as one system programmer recommanded. Updated blocks in the ADABAS buffer pool or partly written blocks from the buffer pool during a buffer flush are candidates for later problems.