上一篇：
IRIS中的权限管理

在上一篇文章中，我们介绍了IRIS中的权限控制体系。在本文中我们将以一个常见的实施需求为例介绍如何使用IRIS的权限配置出一个只能使用SQL的用户。

需求的分解

和所有用户需求一样，当用户提出一个需求时，除其语义显式的含义之外，还需分析其是否具有没有明确说明的含义。
对于一个只能使用SQL的用户这样一个需求，即应当结合平台的特征分解成为功能需求：
具有一个合法，可通过用户名和密码使用IRIS的用户
该用户的数据库权限
- 确认项：可以使用SQL访问所有数据库还是某几个特定的数据库？
该用户的SQL权限
- 确认项：对于特定的数据库，是否可以执行所有的DDL？
- 确认项：对于特定的数据库，是否对每一张表都可以执行Select、Update等所有的DML
该用户的程序权限
- 确认项：用户是否可以通过Portal登录并管理IRIS？

1. 从消息查看器看到清除周期以外的消息没有被正常清除

这种情况先抽查这些消息所处的会话中是否有未完成操作周期的消息（状态为除“Completed”“Error”“Discarded”之外的状态）。如有，且定期清除任务配置了“KeepIntegrity”，且该环境并不需要保留这些消息，可通过关闭清除任务中的“KeepIntegrity”配置清除这些会话和包含的消息。如果有这类消息，但是定期清除任务未配置“KeepIntegrity”，可能是定期清除任务的逻辑或消息数据问题导致清楚任务查找的时候没有覆盖这些消息，请联系WRC帮助排查具体原因。

有关定期清除任务的更多信息请参见文档

Purging Production Data | Managing Productions | InterSystems IRIS for Health 2022.1

本文章是一个系列，主要目的是介绍给IRIS,Caché的终端用户如何方便的监控您的系统。

InterSystems系统的监控很难吗？需要学习很多技术吗？ 我的答案是还好。

关于Caché和IRIS监控，无论是那部分内容，在InterSystems的在线文档或者开发者论坛，其实都能找到相关的说明和方案。但问题是太多，太杂乱，没有一个“操作维护手册”的东西。结果是，如果您是一个新手的InterSystems产品的维护工程师或者管理员，您要花很多的时间在大量的文档里找答案。

还有一个问题是文档中很多章节的内容又太深，包含了一些开发人员才关心的内容，这是Caché或者IRIS的特性造成的，因为它首先是一个开发平台。结果是，对于管理员，很多文档的很不友好。

因此，我要写的这个文章的的目的是这样的：

• 简单。只介绍管理维护人员需要的内容。只介绍和监控相关的内容。其他比如备份恢复，扩容，修改配置等等基本不涉及。

• 易学。文章的期待读者是系统管理员，因此不需要您有编程能力或者InterSystems编程语言的基础。我系统对您的每个日常工作和关注的主题，给出最容易实现的操作步骤。

如果想快速查看锁表空间的使用情况，可以通过GetLockSpaceInfo()方法来获得。

%SYS>w ##class(SYS.Lock).GetLockSpaceInfo()
4717392,4712512,1200

返回值是 "AvailableSpace,UsableSpace,UsedSpace"，每个值的单位都是Byte。

AvailableSpace：锁表的总空间减去已用空间的大小（UsedSpace）。
UsableSpace：预估的可用空间。AvailableSpace里有一些空间是系统内部保留的，所以UsableSpace比AvailableSpace要小。UsableSpace是用户在锁表中可用的自由空间的数量。
UsedSpace：已经使用的空间。

大家好！

我想跟大家分享一个个人项目，该项目始于工作中的一个简单需求：“能否知道我们使用了多少个Caché许可证？”

在阅读社区的其他文章时，我发现了一篇David Loveluck写的非常棒的文章：APM——使用Caché History Monitor。

我根据David的这篇文章，开始使用Caché History Monitor并显示所有这些信息。

在面临“选择哪种很酷的技术”这个问题时，我决定使用简单而强大的CSP，这样我的客户可以认识到Caché不仅仅是MUMPS/终端。

在创建了页面以显示许可、数据库增长和CSP会话的历史记录后，我决定为System Dashboard和进程页面创建一个新设计。

我的Caché实例运行得良好。

但是，如果使用IRIS呢？

附件中的压缩文件包含了一些我多年来所做的Cache SQL Storage映射的例子。

如果你有现有的globals，并且想通过Objects或SQL暴露它们，你需要设置Cache SQL Storage映射。 如果你没有看到对你的情况有帮助的例子，请给我发一个例子，我可以帮你解决。

下载附件：https://community.intersystems.com/sites/default/files/post-associated-d...

我最近看到一个客户问题，是使用 Caché 数据库上运行的病毒扫描程序导致应用程序间歇性变慢和用户响应时间不佳。

出乎意料的是，这是一个常见问题，所以本帖就是提个醒，要将主要 Caché 组件排除在病毒扫描之外。

通常，病毒扫描必须排除 CACHE.DAT 数据库文件和 Caché 二进制文件。 如果防病毒软件扫描 CACHE.DAT 和 InterSystems 文件，那么系统性能将受到较大影响。

具体来说，防病毒软件必须排除的 Caché 文件包括：
* Caché 数据库 (CACHE.DAT)。
* Ensemble/bin 或 cache/bin 目录中的 Caché 可执行文件。
* 写入映像日志 (WIJ)。
* 日志目录中的日志文件。

更多详细信息，请参见在线文档。

更多 Caché 文档

现在，InterSystems 系统警报和监视（简称 InterSystems SAM）第 1 版 (v1.0) 发布了预览版本。

InterSystems SAM v1.0 为基于 InterSystems IRIS 的产品提供现代化的监视解决方案。 其可对集群进行高级别查看，并且能够以单节点方式可视化深入探视指标，同时提供警报通知。 该第 1 个版本提供对一百多个 InterSystems IRIS 内核指标的可视化，并且用户可以根据自己的喜好扩展默认提供的 Grafana 模板。

V1.0 旨在成为简单直观的基准。 请进行尝试并向我们发送反馈，帮助我们使其变得更棒！

从版本 2019.4 开始，SAM 可以显示来自基于 InterSystems 的实例中的信息

SAM 仅以容器格式提供。 您将需要 SAM 管理器容器，以及一小组额外的开源组件（Prometheus 和 Grafana），它们由组合文件自动添加。

可从以下位置获取 SAM 组件和 SAM 管理器社区版

• WRC 预览页面：分别为“SAM 组件”和“SAM 管理器”
• 如果您要在 docker-compose 运行之前下载，可通过外部源SAM 组件 Github repo & Docker Hub 上的 SAM 管理器（后一个链接可能在几个小时内不可用，但容器是可获取的）

如果您正在旅行，或偏爱通过语音收听有关什么是 SAM 方面的提问与回答，我们为您准备了以下播客：

大家好!

我正在创建一个脚本，从Ensemble Production中删除一个项目（Component），我知道有手动的方法，但由于有几个Component，我想用一个脚本来更快。

我试着用%Delete()并在Ens.Config.Item上做选择，但这最终在生产中产生了几个错误。有谁知道我怎样才能简单地做到这一点？

答案参见：https://community.intersystems.com/post/delete-item-production

我们有用SQL写的messages.log / cconsole.log吗？

Google Cloud Platform (GCP) 为基础架构即服务 (IaaS) 提供功能丰富的环境，其作为云提供完备的功能，支持所有的 InterSystems 产品，包括最新的 InterSystems IRIS 数据平台。 与任何平台或部署模型一样，必须留心以确保考虑到环境的各个方面，例如性能、可用性、操作和管理程序。 本文将详细阐述所有这些方面。

(ECP) Caché 出色的可用性和扩展特性之一是企业缓存协议 (ECP)。 在应用程序开发过程中，如对使用 ECP 的分布式处理加以考虑，可以横向扩展 Caché 应用程序的架构。 应用程序处理可以调整为非常高的速率，处理能力从单个应用程序服务器扩展到最多 255 个应用程序服务器，并且不需要任何应用程序更改。

在我参与的 TrakCare 部署中，ECP 已广泛使用多年。 十年前，主要供应商之一的一台“大型”x86 服务器可能总共只有八个核心。 对于大型部署来说，ECP 是横向扩展商业服务器处理能力的方式，不适合单台昂贵的大型企业服务器。 即使是高核心数的企业服务器也有限制，因此 ECP 也用于扩展这些服务器上的部署。

如今，大多数的新 TrakCare 部署或升级到当前硬件不需要 ECP 即可扩展。 目前的双插槽 x86 生产服务器可以拥有数十个核心和巨大容量的内存。 我们看到，在最近的 Caché 版本中，TrakCare 以及许多其他 Caché 应用程序具有可预测的线性扩展能力，能够随着单台服务器中 CPU 核心数量和内存的增加而支持逐渐增多的用户和事务。 在现场，我看到大多数的新部署都是虚拟化的，即使如此，虚拟机也可以根据需要扩展到主机服务器的规模。 如果资源需求超过单个物理主机可以提供的资源，则使用 ECP 进行横向扩展。

这次我想谈一谈不专门针对 InterSystems IRIS 的东西，不过如果你想使用 Docker，并且你工作环境是安装了 Windows 10 专业版或企业版的 PC 或笔记本电脑，那么我认为这个很重要。

你可能知道，容器技术基本上来自于 Linux 世界，如今在 Linux 主机上发挥出最大潜能。 那些平常使用 Windows 的人会看到，Microsoft 和 Docker 在过去的几年做出了重要的努力，让我们可以在 Windows 系统上以非常简单的方式运行基于 Linux 映像的容器... 但是生产系统不支持这种方式，这是个大问题，如果我们要将持久性数据保留在主机系统中的容器之外，这样做非常不可靠... 这主要是由于 Windows 和 Linux 文件系统之间的巨大差异导致的。 最终，Docker for Windows 自身使用了一个小型 linux 虚拟机 (_MobiLinux) 来运行容器... 此操作对于 Windows 用户是透明的，而且效果完美，只要你不需要你的数据库比容器存活的时间更长...

供应商或内部团队要求说明如何为 VMware vSphere 上运行的大型生产数据库进行 CPU 容量规划。

总的来说，在调整大型生产数据库的 CPU 规模时，有几个简单的最佳做法可以遵循：

• 为每个物理 CPU 核心规划一个 vCPU。
• 考虑 NUMA 并按理想情况调整虚拟机规模，以使 CPU 和内存对于 NUMA 节点是本地的。
• 合理调整虚拟机规模。 仅在需要时才添加 vCPU。

通常，这会引出几个常见问题：

• 由于使用超线程技术，VMware 创建的虚拟机的 CPU 数量可以是物理 CPU 数量的两倍。 那不就是双倍容量吗？ 创建的虚拟机不应该有尽可能多的 CPU 吗？
• 什么是 NUMA 节点？ 我应该在意 NUMA 吗？
• 虚拟机应该合理调整规模，但我如何知道什么时候合理？

我以下面的示例回答这些问题。 但也要记住，最佳做法并不是一成不变的。 有时需要做出妥协。 例如，大型生产数据库虚拟机很可能不适合 NUMA 节点，但我们会看到，其实是没问题的。 最佳做法是指必须针对应用程序和环境进行评估和验证的准则。