#全球响应中心 (WRC)

InterSystems已修复一个缺陷，该缺陷在罕见情况下会导致ECP客户端不稳定。

InterSystems 纠正了一个可能导致 InterSystems IRIS® 和 Caché 无法在 Windows 上利用大页共享内存的问题，即使这些产品得到的信息是已分配到了大页内存。这会对系统性能产生不利影响。

上线一个新的集成平台production或者组件是需要很多精力的，用户常常需要对每一个组件所满足的需求和所能提供的功能，使用到的协议，以及组件对系统资源的调用有深入细致的了解。在配置好一个production之后，您可能需要将这个production推送到测试或者正式环境，或者需要将一个写好的组件代码应用到不同的项目上。这些时候，production的导出功能可以方便您传输production或组件的配置和代码。

导出

需要导出production时，您可以移步到管理门户 - Interoperability - 相应的命名空间 - 列表 - Production 页面，选择您需要导出的production，再点击页面上的导出键进行导出。如下图1所示：

在弹出的对话框中，您可以选择在导出文件中您想包括的内容。如下图2所示：

1. 系统文件

系统文件根据版本不同，大约会占用1GB左右的空间。这部分空间是不能省略的，随意删除文件会导致实例无法正常运行。

2. 备份文件

备份文件应及时转存到另外的磁盘或磁盘分区上，不应与.DAT数据库占用相同的磁盘分区。

3. Journal日志

Journal日志文件存储路径应设置为与.DAT数据库存储路径不同的磁盘或磁盘分区上，不应与.DAT数据库占用相同的磁盘分区。

4. 消息存储

因为HSHC集成平台设计上不支持过多的消息存储，用户应该为每个有消息流量的命名空间配置定期消息清除任务。

根据日期范围查询的SQL性能让你失望？ 我有一个比较特别的技巧，可能会帮助你解决这个问题! (SQL开发人员讨厌这个!)*

如果你有一个类，在添加数据时记录时间戳，那么这些数据将与你的IDKEY值保持顺序--也就是说，当且仅当ID1<ID2时，表内所有ID和时间戳值的TimeStamp1<TimeStamp2--那么你可以利用这一知识来提高对时间戳范围的查询性能。 考虑一下下面这个表:

Class User.TSOrder extends %Persistent 
{ 

Property TS as %TimeStamp;

Property Data as %String (MAXLEN=100, MINLEN=200);

Index TSIdx on TS;

Index Extent [type=bitmap, extent];

}

用过去30天内的30,000,000条随机行来填充，每天将得到1,000,000条行。 现在，如果我们想查询某一天的信息，你可以这样写：

提示：本文包含在Java中通过JDBC Driver对Caché/IRIS数据库进行查询的示例代码。

近期有客户反应使用Java从老版本Caché中读取数据时，如果数据中包含long varchar, Caché数据库中与之对应的属性类型为%Stream.GlobalCharacter，即使实际上该流数据长度非常小，也会成十几倍的降低性能。

大家先来看一段代码,

InterSystems许可证是指InterSystems

以下示例代码可实现在Java中通过JDBC向IRIS数据库中写入Stream数据，插入的该Stream大小约为4M，对应在IRIS中字段类型为%Stream.GlobalCharacter。以下代码在IRIS2021上测试成功，供大家参考，

Java代码，

Linux内核机制OOM Killer，也即Out of Memory Killer, 顾名思义，该机制的主要职能就是当内存不足时，选择并杀掉一些进程，以使系统继续运行。

Caché/Ensemble/IRIS的多个客户曾经遇到过与此相关的系统宕机，宕机的直接原因是数据库核心写进程Write Daemon被OOM Killer选中并杀掉了，在我们的日志文件中可以看到如下信息，

06/15/21-10:50:31:035 (13579) 3 Daemon WRTDMN (pid 13588) died. Freezing system
06/15/21-10:52:25:940 (13601) 2 System Process 'WRTDMN' terminated abnormally (pid 13588)

与之对应，在操作系统的日志文件中可以看到如下记录，

照顾好我们的客户并打造伟大的产品。这是我们InterSystems自从1978年成立以来的座右铭。40多年很快过去，这始终驱动着我们前进。过去是，未来也将一直是我们的基因。

1 磁盘空间不足的常见情形
1）Journal所在磁盘空间不足。造成这种情况的原因有多种，比如，Mirror中备机未处于宕机状态，因此主机保留了Journal文件。
2）数据库所在磁盘空间不足。比如，集成平台上Ensemble/Health Connect/IRIS for Health的消息从未清除过，导致消息数据库DAT文件不断增大，直至将磁盘空间用尽。

我们可以看到以上两种情形下，Mirror都帮不上忙，也就是说一旦问题出现，主机和备机都没有办法立即承担起业务系统的运行，
第1)种，备机可能在故障出现前就已经宕机很长一段时间而没被发现，备机的数据很可能已经与主机严重不一致。实际上，主机之所以保留了大量的journal文件没有删除，就是为了让备机同步数据时使用。
第2)种，虽然配置了Mirror，但是消息主库正常情况下都是镜像库，在一个健康的Mirror中，备机和主机的镜像库数据保持同步，镜像库大小应当是相同的，假设主备机的硬件配置相同（这也是我们推荐的方式）那么磁盘空间不足在备机上同样存在。

与Windows上默认安装为服务随机自启动不同，我们在Linux上安装完InterSystems IRIS后，默认是没有配置系统服务的，需要做手动配置。本文提供使用systemd方式来配置InterSystems IRIS服务随机自启动的简单示例，供大家参考。

假设我们已经安装了InterSystems IRIS产品，安装完成后您可以通过iris list来来查看实例信息，包括安装路径，如："/intersystems/iris"

如果您在升级了系统之后，打开SMP时看到如下报错，
ERROR #5001: 对象的服务器版本与客户端发送的版本不一致: %ZEN.Component.vgroup

一般情况下，这个报错是由浏览器缓存中残留的过期信息造成的，可以通过清除浏览器缓存来解决。

如果清除浏览器缓存之后仍然未能解决此问题，请您前往系统安装目录, 如：d:\InterSystems\IRIS\CSP\broker，查看css/js文件的时间戳在本次更新安装之后是否并没有相应地更新，如果没有，请您做以下尝试，
1）在IRIS中更改数据库IRISLIB, 之前的版本是CACHELIB, 取消只读装载，方法如下，打开管理门户SMP, 系统管理->配置->本地数据库，选择要更改的数据库，取消"只读方式挂载",点击【保存】。
2）重新编译%Zen组件，
w ##class(%SYSTEM.OBJ).Compile("%ZEN.Component.vgroup")
此时，再次前往，d:\InterSystems\IRIS\CSP\broker，会看到相关的css/js文件时间戳已经更新。
3）恢复上述数据库的只读装载。

我有一个SQL查询，我想使用SQL外向适配器从Caché Ensemble针对MS SQL运行。如果我直接从MS SQL Studio运行此查询，则最多需要7秒钟的时间，并返回大约50万行。该行仅包含一列，它是一个大小均相同的数字，如果我在Ensemble生产环境中运行此查询，它将一直运行但不会返回响应。同样的查询在Enssemble环境外的caché中运行，将结果写入文件，返回的结果大约需要3分钟完成。但是如果我把结果加载到一个列表或记录图（Record Map）中，它就会一直运行下去。 能加载到记录图或列表中的数据行数是否有限制，是什么原因导致了这种情况的发生？这个查询所返回的文件大约是5.7MB。

SQL ODBC Connection query running longer than expected