[Info-vax] OpenVMS x64 Atom project

[Jan-Erik Söderholm]

Den 2021-06-07 kl. 15:59, skrev Stephen Hoffman:
> On 2021-06-06 06:02:43 +0000, Phillip Helbig (undress to reply said:
> 
>> In article <s9h2t7$1qvs$1 at gioia.aioe.org>, =?UTF-8?Q?Arne_Vajh=c3=b8j?= 
>> <arne at vajhoej.dk> writes:
>>
>>>> Yes, there is little point in doing a backup if you don't test the 
>>>> restore.  But imagine, say, a database of several hundred terabytes. 
>>>> Even if you can restore it, you can't necessarily tell if the data are 
>>>> somehow corrupt.  Yes, checksums and so on will catch some things, but 
>>>> not all.
> 
> At the scale some of our apps are operating at now, silent Ethernet 
> checksum failures are to be expected.
> 
>>> Traditional BACKUP only works good on a system with no activity. 
>>> BACKUP/IGNORE=INTERLOCK does not solve the problem.
>>>
>>> To get a consistent backup of a large database, without significant 
>>> downtime, then one need a snapshot capability where updates after time T 
>>> does not change what is being backed up.
>>
>> Presumably with a database one would do a database backup, e.g. 
>> RMU/BACKUP, which gives a consistent result.
> 
> That's an older approach and as is the analogous RMS journaling, and that 
> does get a consistent backup—at the cost of blocking activity.

What "cost of blocking activity"?

> 
> Basically, the quiesce function got moved from the app to the database, and 
> better tuned to app activity. But it's still present.

Right, but it is just a short activity (waiting for any running r/w
transaction to end, so it very much depends on the usage profile).
After that, there is no blocking (from the RMU backup activity).

> Both BACKUP and RMU get into trouble with the amount of data involved, and 
> how long that task takes, and how much then gets blocked or deferred.

BACKUP doesn't have any on-line mode like RMU, so it is hard to compare.
Why should anything get "blocked or deferred"?

> The BACKUP design has ~reached its theoretical I/O performance limits, and 
> I'd expect the RMU design is close to those same limits.

Maybe, but the limits are far higher for RMU. You can run a multi process
RMU backup operation where differnt processes takes care of differnt parts
of the database in parallel. The limit is how much hardware you give RMU
to work with.

> On OpenVMS, an app quiesce and app cache flush and host-based volume 
> shadowset split is (vastly) faster than BACKUP or RMU /BACKUP.

Yes, the HBVS split is fast, but you still need to backup your plit
shadow set, don't you?