[Info-vax] OpenVMS x64 Atom project

[kemain.nospam at gmail.com]

>-----Original Message-----
>From: Info-vax <info-vax-bounces at rbnsn.com> On Behalf Of Arne Vajhøj via
>Info-vax
>Sent: June-06-21 8:58 PM
>To: info-vax at rbnsn.com
>Cc: Arne Vajhøj <arne at vajhoej.dk>
>Subject: Re: [Info-vax] OpenVMS x64 Atom project
>
>On 6/6/2021 12:45 PM, Jan-Erik Söderholm wrote:
>> Den 2021-06-06 kl. 17:36, skrev Arne Vajhøj:
>>> But the rule is still that either the database will be unavailable
>>> for significant time or one need a snapshot capability where updates
>>> can be done but the backup sees the snapshot data at the time of the
>>> snapshot.
>>>
>>> Storage or file system or database - the basic problem is the same.
>>
>> Yes. Rdb solves that using a "quiet point". As can be seen from the
>> log file above, that took 2 sec (freezing and waiting for active
>> transactions to finish). EFter that 2 sec delay, all update activity
>> are back to normal while the backup continues to run. The data backed
>> up is the data that was there at the point in time of the "quiet point
lock
>release".
>>
>> And any "snapshot" data is only saved to the "snapshot file" in the
>> case that some process request to update it. If not, there is no
>> reason to copy any data, of course. 99% of the database will be
>> untouched during the backup and thus not copied to the snapshot file.
>>
>> So most of the data backed up is "real" data, not snapshot data.
>
>Yes.
>
>I think that is common as well.
>
>I believe that SpiraLog would have worked similarly - if anyone still
remembers
>that.
>
>Arne
>

Fyi - Spiralog technical overview:
<https://www.hpl.hp.com/hpjournal/dtj/vol8num2/vol8num2art1.pdf>

Regards,

Kerry Main
Kerry dot main at starkgaming dot com





-- 
This email has been checked for viruses by AVG.
https://www.avg.com