当系统发生严重危机，一般错误，以及其他需要管理员关注的其他事件发生时， 管理员必须及时的收到系统发出的警告信息。

上篇文章中介绍了控制台日志。这是个文本文件，包含几乎所有的系统级别的错误信息，并且有严重级别的标识，那么使用工具来监控控制台日志文件，并给管理员发送通知是可行的方案吗？

当然。实际上，有些用户正是这样来管理Caceh'/IRIS的。他们有自己熟悉的监控工具，实时读取控制台日志，分析内容，并完成警告通知的发送。

这篇文章我来介绍的是Cache'/IRIS内置的处理警告的机制和配置方法。 通过把严重的错误和事件写入另一个文本文件alert.log，并配置邮件，SNMP, API接口发送通知，可以基本的实现caceh'/IRIS系统的警告通知工作。

Alerts.log

控制台日志中最严重的两个级别(级别2和3)， 的记录会被写入另一个文本文件，名字是Alert.log。 默认存储于\installDir\mgr\路径。

• 在操作门户中“系统>系统日志>控制台日志” ，你会发现 Alerts.log的内容会以红色的字体显示在最上方。比如下图中有2个严重级别的Alert。

IRIS 中支持的四种方式：

SQL、Objects、REST 和 GraphQL

卡济米尔·马列维奇，《运动员》(1932)

>

> “你当然无法理解！ 习惯了坐马车旅行的人怎么可能理解乘坐火车或者飞机旅行的人的感受和印象？”
>

> >

> 卡济米尔·马列维奇 (1916)
>

## 引言

我们已经讨论过为什么在主题领域建模使用对象类型优于使用 SQL。 当时得出的结论和总结的事实如今依然适用。 那么，我们为什么要退后到对象和类型之前的时代，讨论将对象的操作拖回到使用global的技术？ 我们又为什么要鼓励面条式代码？难道是为了用它难以跟踪的错误考验开发者的技能熟练度？

目前有几种观点支持通过基于 SQL/REST/GraphQL 的 API 传输数据，而不是将其表示为类型/对象：

• 这些技术经过深入研究，相当易于部署。
• 知名度非常高，已在便捷的开源软件中广泛实现。
• 您通常别无选择，只能使用这些技术，尤其是在网络和数据库中。
• 最重要的是，API 仍然使用对象，因为它们提供了在代码中实现 API 的最适途径。

在讨论实现 API 之前，我们先来看一下底层的抽象层。 下图显示了数据在永久存储位置与处理并向应用程序用户呈现的位置之间的移动方式。

SQL查询优化器一般情况下能给出最好的查询计划，但不是所有情况都这样，所以InterSystems SQL还提供了一个方式， 也就是在查询语句里加入optimize-option keyword（优化关键字）, 用来人工的修改查询计划。

比如下面的查询：

SELECT AVG(SaleAmt) FROM %PARALLEL User.AllSales GROUP BY Region

其中的%PARALLEL, 就是最常用的优化关键字， 它强制SQL优化器使用多进程并行处理这个SQL。

您可以这样理解： 如果查询优化器足够聪明，那么绝大多数情况下，根本就不需要优化关键字来人工干预。因此，您也一定不奇怪在不同的IRIS/Caché版本中， 关键字的表现可能不一样。越新的版本，应该是越少用到。比如上面的%PARALLEL， 在Caché的大多数版本中， 在查询中加上它一般都能提高查询速度，而在IRIS中，尤其是2023版本以后， 同样的SQL查询语句，很大的可能查询优化器已经自动使用多进程并行查询了，不再需要用户人工干预了。

因此，先总结有关优化关键字的要点：

Hi 亲爱的开发者们，你是否精通多门语言并希望与世界各地的非英语用户分享你的知识？

我们为你提供了闪光的机会！ 🤩

最近有某国内三甲医院为满足评级和飞行检查要求，希望提升HIS和IRIS的SQL查询效率，客户和实施工程师整理了一个慢查询的SQL列表， 有一些查询比较慢， 查询时间在甚至大于60分钟。

在我们和厂商共同努力下，对整个库的SQL查询做了优化。 下表是记录了我们在进行了大部分优化工作后的结果，您可以看到大多查询从几十分钟减少到了几十秒甚至1秒以内。其中有几个慢到几分钟的查询，最后经过细调， 也把查询耗时减少到了一分钟以内。 优化的效果还是很明显的。

这里我分享一下操作的要点，以便给其他有同样问题的客户一个思路。

其实如果您看过我前面的帖子，应该已经有了基本的概念。我就把工作流程总结一下，其实就这么几个步骤：

步骤一：

1. 通用RESTful业务服务和业务操作

InterSystems IRIS 提供了一组通用的RESTful 业务服务和业务操作类，用户无需开发自定义的业务服务和业务操作类，就可以直接向外提供RESTful服务和调用外部的RESTful API。