#InterSystems IRIS

关键字：PyODBC，unixODBC，IRIS，IntegratedML，Jupyter Notebook，Python 3

目的

几个月前，我简单谈到了关于“将 Python JDBC 连接到 IRIS”的话题。我后来频繁提起它， 因此决定再写一篇 5 分钟的笔记，说明如何“将 Python ODBC 连接到 IRIS”。

在 Windows 客户端中通常很容易设置 ODBC 和 PyODBC，不过我每次在 Linux/Unix 风格的服务器中设置 unixODBC 和 PyODBC 客户端时，都会遇到一些麻烦。

有没有一种简单连贯的方法，可以不安装任何 IRIS，在原版 Linux 客户端中让 PyODBC/unixODBC 针对远程 IRIS 服务器运行？

IRISHealth以其完备且系统化的安全特性在医疗行业的数据库中独树一帜，这些特性包括安全认证、安全授权、安全审计、数据加密以及安全配置。其中数据传输无疑是其中最重要的一环。为此，IRISHealth采用了SSL/TLS技术来对传输的数据进行加密，有效保障了从IRIS数据平台的超级服务数据传输、Telnet服务数据传输、java/.net/Studio客户端的访问数据传输、MIRROR与DB的数据传输，到DBServer和ECPApp之间的数据传输的安全性。

本文是在两个IRISHealth2021实例之间进行ECP服务通信的示例，一个作为DBServer，一个作为ECPApp，两个实例之间通过使用SSL/TLS的ECP协议进行TCP的加密传输通信。

1.IRIS的DB和ECP环境：

InterSystems 常见问题FAQ

如果您想在InterSystems 产品启动时执行一个操作系统可执行文件，命令或者程序，可以在SYSTEM^%ZSTART routine里面写明流程 ( %ZSTART routine在 %SYS 命名空间里面创建).

在 SYSTEM^%ZSTART 里面写代码之前, 请确保他可以在任何情况下能正常工作

如果 ^%ZSTART routine 写的不对，或者没有响应或者发生错误，InterSystems 产品可能会无法启动。

更多信息，请参考一下文档。

InterSystems 常见问题系列FAQ

流程如下

1. 上传到 FTP server

迄今为止，我看到的大多数使用向量vector的示例，将它只作为 SQL 中的一种功能，尤其是围绕 VECTOR_Search 的 3 个函数。
* TO_VECTOR()
* vector_dot_product ()
* vector_cosine ()

在 iris-vector-search 演示包中隐藏着一个非常有用的摘要。
从那里，你可以通过多个链接找到所需的一切。

我还缺少更多的 VECTOR 方法，于是在 Idea Portal 上提出了相关请求。

接着，我想起每个 SQL 方法或存储过程都有一堆 ObjectScript 代码。
于是我开始搜索，下面就是我的研究的一些总结：

通过 REST API 将前端 React 应用程序与 IRIS 数据库等后端服务集成，是构建健壮网络应用程序的强大方法。但是，开发人员经常遇到的一个障碍是跨源资源共享（CORS）问题，由于网络浏览器强制执行的安全限制，该问题可能会阻止前端访问后端的资源。在本文中，我们将探讨在将 React Web 应用程序与 IRIS 后端服务集成时如何解决 CORS 问题。

创建Schema

我们首先定义一个名为 Patients 的简单Schema：

从发布InterSystems IRIS®数据平台2022.3开始，InterSystems修改了许可证强制执行机制，以包括REST和SOAP请求。由于这种变化，在升级后，使用REST或SOAP的非处理器核数的许可证环境下，用户可能会遇到更高的许可证消耗。要确定此警报是否适用于您的InterSystems许可证，请按照下面链接的FAQ中的说明进行操作。

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

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

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

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

步骤一：

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查询语句，很大的可能查询优化器已经自动使用多进程并行查询了，不再需要用户人工干预了。

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

%SYS.Journal.Record 类有一个查询(query), List, 可以列出Journal文件中记录的数据修改历史。例如，要查询谁对global节点^QP(1,2)做过修改，可以使用如下代码。它查询Journal文件（输入参数pFilePath）中的global节点（输入参数pSearchGlobal）的操作：

当我们在设计一个需要重复使用的BP时候，往往需要开发一个可配置<call>的对象的组件，我们将call的target 设置为

@process.TargetConfigName

即可实现。

下面是完整代码：

SQL性能监控是DBA最重要的日常工作。经常被问起："Caché/IRIS怎么发现慢SQL"? 答案很简单： 到管理门户的SQL页面，点开如下的“SQL语句“子页， 您能看到这个命名空间的所有执行过的SQL语句，知道每个SQL语句执行了多少次，平均执行时间是多少， 被那个客户端编译的，第一次执行是那一天等等。

请看下面的截图

图中的各个栏目基本都不需要解释，有个别的内容在这里总结一些：

• 表/视图/存储过程名称：列出这个查询使用的所有的表/视图/存储过程的名字。如果你想看某个表有关的查询，可以使用上面的过滤器。

• 位置(Location) : 对于动态查询， 列出所使用的缓存的查询的类名，对于嵌入SQL(Embedded SQL)查询，列出使用的routine名字。