/// 48 characters:
MinLength(As %String) As %Integer
 F i=1:1:$L(s){S v($L($P(s," ",i)))=i} Q $O(v(0))

Hello Stefan,

Thanks for the reference, while I'm still not sure about the step #2 as ^JRNRESTO provides the  (defaulted) option to disable journaling of updates during the restore to make the operation faster, see the step #10 of Restore Globals From Journal Files Using ^JRNRESTO. Besides, this is the only option compatible with parallel dejournaling. So the idea to switch off journaling system-wide looks excessive.


The manual says I should (in short):

  1. Stop journaling with ^JRNSTOP

Which manual does it say? Any manual I've read last 20 years says quite opposite: never stop journaling unless you want to get your system in troubles.
It seems that you should not bother on the subject at all: during the database restore it can't be involved in any users' activity, so there would not exist any journal record on its change.

Evgeniy, thank you for sharing your experience.

there is one table that contains 11,330,263 rows at the time of writing. Not so critically much, but it creates delays. Even the query to count the number of rows takes almost 30 seconds

Looking just at the number of rows, one apparently can't consider such a table to be a big one.
What was the size (in GB) of the underlining global?

Alas, it has the similar problem as my original solution: 

w ##class(z.Scratch).Detector("azazz","zaaza") ;should be 0

So, my feeling was right... It's time to quit this golf club for now, at least for me )))

Yes, it can be, while this approach can't win, as I already understood. Size = 67: 

ClassMethod Detector(As %String, As %String) As %Boolean
 a=$zu(28,a,6),b=$zu(28,b,6) $tr(a,b)=$tr(b,a)&($l(a)=$l(b))

size = 83

ClassMethod Detector(As %String, As %String) As %Boolean

This change seems to be applicable to IRIS only.
In Cache log data is still in ^%ISCLOG("Data"); just checked in Cache 2018.1.6.

If you are interested in global moving without downtime there is (live-global-mover)

Thank you, already not as new deployments of our HIS use separate document storage from the very beginning. 

Your solution is beautiful as it allows placing the ECP enabled "moved data" server to some less expensive disk storage. In our case that I've briefly described ECP & Mirror were already in use, so we couldn't place document DB on a separated data server as having several independent data servers would be a bad decision for many reasons.