This is the first article in a series discussing how to regain disk space from Caché databases at the operating system level. This introductory article discusses Caché database growth and gives an overview of various methods you can use to return unused disk space that is allocated to database files back to the file system. But before we talk about returning space to the file system, let’s first review how does it get allocated in the first place.

We are finally planning to migrate some ancient Caché applications that are run on Caché 5.0.21 to a new server with Caché 2016.2.0 or so.

I wonder if we could use Shadowing between those to keep the data on the new server up to date?

We would copy the Caché backup from the old environment to the new and do a RESTORE there and then start shadowing.

I know than 5.0.21 is no more officially supported by ISC.

This is the third article (see Part 1 and Part 2) where I continue to introduce you to the internal structure of Caché databases. This time, I will tell you a few interesting things and explain how my Caché Blocks Explorer project can help make your work more productive.

This text is a continuation of my article where I explained the structure a Caché database. In this article, I described the types of blocks, connections between them and their relation to globals. The article was purely theoretical. I made a project that helps visualize the block tree - and this article will explain how it works in great detail.

InterSystems Caché globals provide very convenient features for developers. But why are globals so fast and efficient?

Theory

Basically, the Caché database is a catalog having the same name as the database and containing the CACHE.DAT file. On Unix systems, the database can also be an ordinary disk partition.

I am looking for a database management tool I would have expected to find something like on the SMP website

Aim

show current database usage (ie size allocation) by database then table etc and allow continued drill down,

show information as a table, so can then sort by size to find the biggest item easily

also show it graphically

And then have ability to track and trend growth in size over time

identify a normal growth pattern

alert if variation (higher or lower) from normal based on recent trend

在Aix7.1上安装使用root用户安装cache2016.1.1.107，且在安装过程中创建cacheusr用户；更改操作系统上的cacheusr的umask后，通过数据库修改编译后的文件(如，js，csp等)在小机上查看权限不变（-rwxrw-r-- cacheusr cacheusr test.js）。

目的：通过数据库编译后的文件的other用户有读写权限。

Hi,

If you want to import data from a mySQL export file (exported with mysqldump), you will find here a little script that could help.

Only the INSERT commands in the sql file are executed into Caché. Indices are not computed for better performance.
%NOINDEX, %NOCHECK and %NOLOCK are generated on each INSERT line.

Currently, the file can not contain a "),(" pattern inside the values part of the INSERT command. If this is the case, the line is skipped. This feature may be implemented in the extractValuesList method.

Is there something in Cache that is equivalent to partitioning a table in Oracle? I'm trying to break some big tables into groups so that the most frequently accessed data is faster to retrieve.

Here is some information on this concept from Oracle.

https://docs.oracle.com/cd/B28359_01/server.111/b32024/partition.htm

Is the default language (i.e., $$$DefaultLanguage, which is used as the basis for localization with $$$Text/etc. at compile time) always "en" for new Caché installations, or could it be different? How is this determined? I don't see an option to select a language during Caché installation.

Also, is there a supported/preferred API for setting the default language? Looking at %occMessages.inc, one option would be:

Here is my original query:

SELECT EventType, InitiatedAt, COUNT(*) as cnt
FROM HS_IHE_ATNA_Repository.Aggregation
WHERE EventType = 'LOGIN'
AND LocalDateTime > '2016-02-16 11:00:00'
GROUP BY EventType, InitiatedAt

This gives me data like this:

Hi,

I have a client who is considering encryption options in order to comply with a tendering requirement.

Were they to encrypt the production database then what would be a reasonable expectation forthe impact on message throughput. Or possibly more easily answered: what would be the expected impact be on I/O rate and CPU utilization. Are there any benchmarks to which could support an estimate ?

How would this compare with plan B: to use disk encryption ?

Thanks