Hello Mike,

I don't have a sample for scripting it, but if you haven't seen it already, the IRIS server migration guide contains a list of items and methods for exporting them. I think it's a good reference for keeping in mind the things you might want to bring over.

https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls?KEY=AMIG

Also, I might agree with Armin that doing a multi-stage upgrade could be easier - perhaps you've already identified a reason why it won't work for you though.

Hello Dustin,

There are a few things you can try to find out more about this.

1. Making an SFTP connection in terminal so you add additional debugging - https://community.intersystems.com/post/using-and-debugging-netsshsession-ssh-connections

2. Trying a different SFTP client - this will help identify if there's a problem connecting between the servers (network / firewall change, for example). If no SFTP client works, then you likely want to involve your network team / the downstream's network team (or potentially security team, different orgs might label the relevant party differently).

3. If the SFTP connection was working earlier, but nothing was changed in Ensemble, then it seems pretty apparent that something changed outside of Ensemble. You could see when the problem started and ask around internally / externally to see what might have changed.

Hello Nikhil,

What problem are you trying to solve or what exactly are you trying to do? See the below docs:

"The maximum length of a subscript is 511 encoded bytes (the corresponding number of characters depends on the characters in the subscript and the current locale)"

https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCOS_variables#GCOS_variables_subscripts

Maximum Length of a Global Reference

You can use $length to get the length of a string, but depending on what you want to do, that may determine how you can get the value of the subscript.

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

Hello Wenjie,

^oddPROC is an internal global with metadata for your BAIYAOJIREQUEST class (I think in your custom Ensemble.Ens package, not sure exactly how the characters translate). I think for this issue you may want to reach out to InterSystems support so they can look into what may have happened to "corrupt" that global and look into solutions. Do you have any ideas of whether something unusual might have happened to that class?

Is this what you mean by Rose? It's not a technology I'm familiar with, but from this page and your description it sounds like an HA cluster with shared storage:

https://www.rosedata.com/index_en.php/Prodetail/index/proid/1

Do you have any specific questions about this setup?

Can you provide more detail on what kind of disaster events you are looking to handle? What is your desired behavior? Basically, I would suggest thinking about different disaster scenarios and how this environment would react.

Failover Strategies for High Availability

Here are the docs regarding different HA strategies including HA clustering and mirroring. The main point they highlight for a HA cluster with shared storage is that the disk then becomes a single point of failure. Adding a mirror instance on separate hardware provides an option if your RoseHA disk fails.

I agree that Danny's suggestion to review where your licenses are being used is a good starting point.

Since you mention using this license across multiple servers, I would consider the different ways your developers are connecting to Caché. If a developer has Studio, the management portal, and a terminal session open, they are probably using more than 1 license. Even with a limit of 2 developers per server, if 6 developers are on the 3 servers connecting multiple ways, you could surpass a 10 user limit.

You may need a more robust license to support your team's usage patterns.

Hello again Fábio,

These errors are one part of the picture. It would probably be beneficial to open a ticket with the WRC so they can look into these errors and your performance issues to see if they are related/separate.

Do you know what queries are triggering these errors? w3wp.exe is an IIS process but I'm not familiar with EXTRService.exe or KIORAS. Perhaps the IP addresses can also help you narrow down the source.

The <READ> errors indicate something like a problem reading from the socket, but that doesn't explain the cause. There may be other logs you can review in your environment to help explain this.

Hello Fábio,

I'm just quoting the class reference I linked:

"This method is called to remove data from the %SYS.PTools.SQLStats table. It does not remove data from %SYS_PTools.SQLQuery, those rows are cleaned up when a query is compiled"

You can take a look at what's actually filling up your CACHE database to determine if this will work for you. For a complete purging, I'd go with purging cached queries, as that's the "full" solution.

Hello Fábio,

In IRIS there is a convenient SQL Runtime Statistics page where you can purge those stats.

Using the SQL Runtime Statistics Tool

On your version, the equivalent tool only offers the option to purge cached queries, so I think that's what you'll need to do. %SYS.PTools.SQLStats.Purge will purge some of the SQL stats data, though not all.

"Purging a cached query purges any related SQL Stats data. Dropping a table or view purges any related SQL Stats data."

edit: corrected, CE 2018.1.5 does not have the purge stats option that IRIS does.

Hello Alex,

Have you confirmed that the original transaction process goes away when the VPN disconnects? How are you opening the terminal in the first place?

If disconnecting the VPN leaves the original process around, it won't have a chance to rollback the transaction.

edit: perhaps this is related to your Journal Freeze on error setting?

Hello Augusto,

Please check out the mirroring documentation, which is quite robust. After joining your async to the mirror you will need to sync the databases.

"Only a local database on the current primary failover member can be added to a mirror; it is added on the primary first, then on the backup, and then on any desired async members. All mirrored databases must be journaled.

You must add the same set of mirrored databases to both the primary and backup failover members, as well as to any DR async members; which mirrored databases you add to reporting async members depends on your reporting needs. "

Add an Existing Database to the Mirror

This documentation covers some ways of syncing a database from the primary to the other members.

Hope that helps!

Martin,

This makes sense to me. Access to databases is controlled by that database resource setting, which can be customized and assigned to various roles. A role that is assigned %DB_%DEFAULT access will grant access to any databases that are controlled by that resource.

If you are concerned, you could review the other databases and make sure that you want your user to have access to the other databases secured by %DB_%DEFAULT. If you wanted more restriction, you could assign your databases a different resource other than %DB_%DEFAULT, such as having specific database resources for each database. That way, you only grant permissions for 1 specific database when granting the custom resource. 

See documentation here:

Database Resources

Hope that helps.

It's difficult to make a recommendation for how often these items should be synced. It is basically dependent on how often you make changes to these items, what types of changes you want to sync, how prepared you want to be for potential failovers, and what your recovery process during a failover would entail. If you make a change that the backup needs to take over and run your application, you should probably sync that change as soon as possible. Other changes may not be as critical.