Hello Sachin,

Can you provide the version of your product from the about page in the management portal or "w $zv" from the terminal? This behavior varies across versions so you can probably find more information in the relevant version of our documentation.

Also, please be clear about whether you are referring to namespaces or databases.

This documentation may be what you are referring to:

Where Ensemble Stores Temporary Data
 

Hello,

First of all I wonder what version of Caché you are using as ^MSU has been replaced by ^DATABASE for a long time.

That being said, I can't imagine there being any problems with interrupting using ctrl+c. In fact, as you didn't get an <INTERRUPT> error it seems likely that ^MSU/^DATABASE has accounted for a user trying to ctrl+c out and so just returns you to the previous menu.

Hello Daniel,

As Kenneth mentioned, outside of shadowing/mirroring journaling could still be very important depending on your usage.

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_journal

For example, journals are needed in a disaster recovery scenario in order to bring your instance more up to date than the time of the backup itself. If you are not journaling and restore a backup your data will be current as of the time the backup was taken. Replaying journals would be necessary to proceed beyond that. You would only need the journals created after the time of the backup.

Also note that I would recommend testing your backup restore procedure and regularly taking integrity checks to confirm the validity of your backups. I would go so far as to say a backup that has not passed an integrity check is not a valid backup.

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_backup

While I suspect this is related to the read-only / mirrored-ness of the backup failover member, I would recommend reaching out to the WRC for a more thorough investigation.

Alex and Alexey suggested a nice workaround as well.

I'm not sure exactly what your steps were - where did you see that error? I have no problem opening objects without locking in a mirrored database on a backup failover member:

MIR>s x= ##class(Sample.Person).%OpenId(1,0)

MIR>w x
1@Sample.Person

Hello Jeffrey,

You're absolutely right that normal read only databases and mirrored databases operate differently. It is not possible to take out locks for a mirrored database on a backup failover member as locks would prevent the member from taking over as primary.

If you have a DR async and take out a lock on a mirrored database, then when you try to promote to failover member you'll see a message like this:

Unfortunately, that means I don't have a workaround for you unless you have a DR where you can dump the messages instead.

Thanks to @Pete Greskoff who I talked to about this behavior.

Hello Sergey,

Can you confirm if you are getting that kit from the Download Caché button in the sidebar here in the Developer Community? If so, then that alleviates my primary concern that it might actually be a threat.

Beyond that, the question would be one of setting up an anti-virus exclusion or disabling it briefly. This is something you might need to do for any software kit that is improperly flagged by your antivirus, which is not really a question of InterSystems technology but of whatever antivirus you are using.

Further down the line you may want to add some additional exclusions so Caché can operate properly per this documentation:

https://cedocs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?K...