Hello Caio,

There is no DECLARE @variable (SQL server) or DECLARE variable (Oracle) on Cache but there are few options:

1. Use a host variable(s) in embedded SQL:

SET variable = 2000
&SQL(SELECT Column FROM Table WHERE ID = :variable) 

2. Use the same with Dynamic SQL

SET variable = 2000
SET sql = "SELECT Column FROM Table WHERE ID = " _ variable
DO ##class(%SQL.Statement).%ExecDirect(, sql)

3. Writing a SP

CREATE PROCEDURE Procedure(IN variable  INT)
AS
BEGIN
    SELECT Column FROM Table WHERE ID = variable;
END

The CSP gateway has a "mirror aware" function that will always point you to the primary in a failover pair. This works most of the times, but in rare cases it keep a connection disabled after a primary swtich.

Another option is to use an external load balancer that has some kind of "health probe". Then, you could have a simple REST/API call (called by that health probe) that will return 200 for the primary and 404 (or 500) for the backup. This way going through that LB will always point you to the primary.

Hi,

You said the issue was only 1 server, and you could fail over to the mirror backup server, which could connect to LDAP from within IRIS. I assume you run the d TEST^%SYS.LDAP function to check connectivity.

If only 1 server can't connect, I would ask myself (investigate) "what was changed?" 
using REDEBUG could help to see more information re. the issue.

In any case, I recommend opening a WRC for that, if you can not find the root cause.

Hi Scott,

My remarks:

As mentioned here:

1. As already mentioned by @David.Satorres6134, global mapping for specific globals (or subscript level mapping) to different databases (located on different disks) may give you a solution for space, and also increase your overall performance.
2. Using ^GBLOCKCOPY is a good idea when there are many small globals. For a very big globals, it will be very slow (since it uses 1 process/global) so I recommend writing your own code + using the "queue manager" to do merges between databases for 1 global in parallel.

Ephraim,

When you say "corrupted" to better understand...
- Did you try to mount the DB (from the SMP of with ^MOUNT)? Sometimes if IRIS/Cache was "forced" than a *.lck file on the DB folder need to be deleted in order to allow a successful mount. 
- If the DB is mounted, did you got a <DATABASE> (or other) error? if so, then what was said using ^Integrity and ^Repair could help - but only if you fully understand how to use those tools (!) Most of the time, a corrupted DB is fixable using those tools, or at least data can be 99% recovered. Depending on the number of errors: if its huge than sometimes it is faster to recover the DB from a valid backup + journal files. 

BTW - if this is a mirrored DB than there are other considerations as well. 

Happy new year!

On a given machine any process can run "as fast" as the CPU clock rate (higher = faster = more operations/sec.)

It is true that a single process can do approx. 15-20 MB/sec. (depends on the CPU clock rate & the disk type: SSD, Premium SSD, Nvme)

The best way to overcome this limitation is do to a "heavy I/O" processes in parallel using the queue manager.
On machines with 16/32 cores, you may achieve your "infrastructure limits" (160MB/sec) easily and even more (we managed to go to a 1000MB/sec of Nvme disks)

The "write daemon" is a process that is responsible to write all new/changed data to the disk where the WIJ (write image journal) file is located. Only then, actual databases are being updated.

Sometimes, when the system is very busy with a lot of pending writes this error appears, and then after few minutes it is cleared automatically. (e.g. when you rebuild a huge index, or do some data migration process).

I would monitor the disk activity for the disk that the WIJ file is located on (by default its on the same disk you installed Cache).

One solution is to move the WIJ to a different disk, less occupied. This will give the "write daemon" more writing capabilities (you will have to restart Cache).    

As you probably know the Intersystems IRIS is capable of doing calculations on a numbers in length of up to 19 positions. This is due to the fact that it is stored as a signed 64–bit integer.

If you are using one of the latest version of IRIS which has an "embedded Python" then you will have the Python support for "bignum" or "long".
So you may have a ClassMethod like this:

ClassMethod BigNumbers1() [ Language = python ]
{
9223372036854775807
9223372036854775808
9223372036854775807123456789
print(a)
print(b)
print(c)
print(c%2)
}
 

Which will give you the output:

9223372036854775807
9223372036854775808
9223372036854775807123456789
1

SAM is executing a REST API call to http://[your-server]/api/monitor/metrics for any server included in your cluster. I'm not sure where the interval is being configured.

If your own metric is needed to be run once a day, you can schedule it with the 'task manager" have the result stored in a global, and let the "user defined" sensor read this global which will not caused any performance issue.

BTW - one thing I forgot to mention in the previous post is:
In order to have SAM run your "user defined" metrics, you need to add it to SAM:

%SYS>Set sc = ##class(SYS.Monitor.SAM.Config).AddApplicationClass("MyClass", "namespace")