Hiroshi,
May I ask you where did it ever work?

Here are the results of quick test in Studio Output window: 

w "*"_$zio_"*"
**
w "*"_$zutil(67,12,$j)_"*"
*MYPC*
w ##CLASS(%SYS.ProcessQuery).Open("P"_$j).ClientNodeName ; prefered (documented) way
MYPC
w ##CLASS(%SYS.ProcessQuery).Open("P"_$j).ClientIPAddress
10.8.3.37

Alternative program which supports CacheActiveX connection showed the same results, by the way, regardless of server's platform, whether it was UNIX/Linux or Windows.

IRIS for Windows (x86-64) 2021.1 (Build 215U) Wed Jun 9 2021 09:39:22 EDT

while results were similar in all previous Cache/IRIS versions I managed to run.

Standard queues provide at-least-once delivery, which means that each message is delivered at least once. FIFO queues provide exactly-once processing, which means that each message is delivered once and remains available until a consumer processes it and deletes it. Duplicates are not introduced into the queue.

..so I guess that you mean standard queue with several worker processes dequeuing items from the queue. In this case the CPU utilization would likely depend on the number of workers, wouldn't it?
 

Hi Anna,

You can look at the property CurrentSrcLine of %SYS.ProcessQuery class (guess SMP uses it showing process details on Process page). Keep in mind that there is more sense to examine the state of some other process rather than the current one as in the last case you will see the very code line where you are examining the process :).

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?

size = 83

ClassMethod Detector(a As %String, b As %String) As %Boolean
{
  f c="a","b"{s @c=$zstrip($zcvt(@c,"U"),"*W")} q $tr(a,b)=$tr(b,a)&($l(a)=$l(b))
}

To reduce the backup time, it could be interesting to move these data to a database dedicated to the archive and make a backup of this database only after an archive process

...

Copy data older than 30 days to the ARCHIVE database

Hi Lorenzo,
We had the similar problem with our largest customer's site which summary database size overgrew 2 TB those days (now the have more than 5 TB). Our solution was more complex than yours as the data move process lasted several days, so we can't stop users for such a long time. We placed a reference to the new storage of (already moved) document data instead the document itself. After the data move was finished, namespace mapping was changed. References were left in the original DB because they took much less space than the original documents.

This rather sophisticated approach allowed us to move the document data without stopping the users' activity. And what was the total win? Should the document data be backup'd? Yes. Should it be journalled / mirrored? Definitely yes. The only advantage achieved with this data separation was no more or less than the ability to deploy testing and/or learning environments without the document database. That's all.

Set LocalTimestamp=$now()