InterSystems 开发者社区汇聚了 17,533 位出色的开发者
InterSystems IRIS 程序员可以在这里学习、分享、了解最新动态、成长,以及收获快乐!
文章
· 三月 25, 2021 阅读大约需 2 分钟
使用DBeaver连接IRIS数据库

在Caché时代, 比较受欢迎的IRIS数据库客户端是Sqldbx和Winsql, 这两者的共同点是提供ODBC兼容的连接,而且免费。限制也差不多:只能用于Windows环境,只能用ODBC连接。

DBeaver是我最近使用的免费SQL客户端, 推荐给各位。它有几个好处:

1 1
1 360
文章
· 四月 26, 2022 阅读大约需 4 分钟
第124章 SQL函数 SECOND

第124章 SQL函数 SECOND

返回日期时间表达式的秒数的时间函数。

大纲

{fn SECOND(time-expression)}

参数

  • time-expression - 作为列名、另一个标量函数的结果或字符串或数字文字的表达式。它必须解析为时间戳字符串或 $HOROLOG 字符串,其中基础数据类型可以表示为 %Time%TimeStamp%PosixTime

描述

SECOND 返回一个从 059 的整数,也可能返回小数秒。秒数是针对 $HOROLOG$ZTIMESTAMP 值、ODBC 格式日期字符串(没有时间值)或时间戳计算的。

1 0
0 77
文章
· 九月 8, 2022 阅读大约需 2 分钟
第二十六章 使用任务管理器(四)

第二十六章 使用任务管理器(四)

导入任务

导入任务页面(系统操作 > 任务管理器 > 导入任务)允许通过浏览到先前导出的任务文件,然后单击立即执行操作来导入和运行任务。

注意:任务只能从运行相同版本的 IRIS 的实例导入或导出。

使用 ^TASKMGR

^TASKMGR 例程允许使用终端配置任务管理器。除非另有说明,^TASKMGR 和管理门户包含用于配置任务的相同选。

  1. 打开终端。
  2. 输入 set $namespace = "%SYS" 以更改为 %SYS 命名空间。
  3. 输入do ^TASKMGR

具体类 %SYS.Task

image

1 0
0 38
文章
· 十一月 10, 2022 阅读大约需 6 分钟
Caché 字符编码自动判断

Caché 字符编码自动判断

先说几个场景:

  1. 使用文件字符流打开一个文本文档,但是我不确定是以UTF8编码的还是GB18030,所以就无法准确设置TranslateTable,就导致了中文乱码问题。
  2. 有一个文件下载的csp,其中文件名参数可能是中文,如果在一个UTF8编码的界面直接调用时,后台取到的文件名就会是乱码。
  3. 接收到字节流后需要转成字符流读取内容,但是无法确定编码格式,就无法准确的转成字符。

以上几个场景虽然大多都可以提前做好约定解决,但是可能有历史原因或者种种情况,需要我们自己能够解决,于是就有了下面的故事。

基础

首先我方系统使用GB18030编码,然后碰到的情况大多都是对方可能是UTF8编码,所以主要来解决识别字节流是不是UTF8编码的。

然后查了一个UTF8编码格式

1 0
0 196
文章
· 一月 4, 2023 阅读大约需 4 分钟
IRIS, Caché监控指导 - 介绍

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

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

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

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

因此,我要写的这个文章的的目的是这样的:

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

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

1 0
0 420
文章
· 二月 28, 2023 阅读大约需 1 分钟
【GS22 视频】如何让脑健康管理变得普惠?

这是InterSystems 2022年全球峰会上来自客户 Cognetivity Neuroscience 的分享。InterSystems IRIS 数据平台助力 Cognetivity Neurosciences 打造脑健康管理评估工具CognlCA。CognlCA 能够在正确的时间将数据提供给正确的人,推动脑健康评估、筛查和管理的节点前置,从而促进脑健康管理的普惠化。

1 0
0 48
文章
· 六月 18, 2023 阅读大约需 3 分钟
医疗行业的未来--数据与人的融合

在数字化时代,数据的重要性无可置疑。数据作为新型生产要素,不仅在宏观政策层面得到党和政府的大力推动,也是医院高质量发展的关键和改变医疗行业的驱动力。随着医疗信息化的迅猛发展,我们正迈向一个数据随处可及、人人可用易用的医疗信息化时代。这一时代将数据与人的需求相结合,致力于让数据能“主动”找到需要他们的医护人员和患者,每一个行业从业者,都应致力于为医护人员和患者提供简单易用的软件解决方案,减少工作量,提高效率,推动医疗行业的进步。

数据与人的融合是实现医疗行业数字化转型的核心。当然,医疗数据的收集、存储和管理对于提供高质量的医疗服务至关重要。然而,仅仅有大量的数据并不足够,我们需要将数据与人的需求紧密结合起来。这意味着我们应该让更多的数据关联起来,并且能服务于更多的人群,让患者能够随时随地访问他们的电子病历,让医生和科研人员也能及时有效地获取病人在医院围墙内外进行治疗和健康管理的数据,并且以直观易懂的方式呈现给医护人员和患者,使他们能够快速、准确地获取所需的信息。数据的融合还包括将不同来源的数据整合起来,为医护人员提供全面、完整的视图,同时基于医疗诊断的规则,不管是通过CDSS的形式,还是通过ChatBot(聊天机器人),帮助他们做出更好的决策。

1 0
0 84
文章
· 十月 7, 2023 阅读大约需 19 分钟
国际卫生信息互操作标准发展简史

卫生信息和其它信息化一样,经历了数码化、数字化到当今的数字化转型,卫生信息互操作一直伴随左右。

数码化(digitization):国内90年代开始,HIS全面铺开,卫生信息进入数码化时代。数码化初期业务集中在HIS上,互操作需求不高,点对点接口可以满足绝大多数需求。

数字化(digitalization):在2000年之后,各种专科系统、尤其是电子病历的诞生,医保和新农合的实施,要求卫生信息共享交换,以提高流程自动化水平。互操作需求爆发,2007年集成平台开始进入市场,卫生信息化进入数字化时代。

数字化转型(digital transformation):2014年,国内正式进入移动互联网时代;次年《全国医疗卫生服务体系规划纲要(2015—2020年)》发布,卫生信息化的服务对象(服务于医护技到服务于患者)和业务形态(临床管理到患者服务)都发生了翻天覆地的变化,开始步入数字化转型的时代。它对互操作提出了更高的要求 - 利用互操作,增强全员参与,为卫生服务创造新价值、发展新业务,推动医疗机构持续数字化转型。

可以说,卫生信息互操作在整个的卫生信息产业中愈发重要。

国际卫生信息互操作发展了30年,国内也发展了20年,但卫生信息互操作依然是一个挑战。

知史而明鉴,识古而知今。我们看看国际卫生信息互操作发展的历程,对未来的卫生信息互操作有什么借鉴。

卫生信息互操作标准的要素

HIMSS把信息互操作/集成定为4个不同的级别:

基础级别,仅仅打通了系统间进行数据通讯的通道;

结构级别,在基础级别上,定义了数据交换的格式和语法;

语义级别,建立在行业通用的基础模型和数据编码上,使用标准化的行业语义来定义数据元素,使用标准的值集。因此语义级别的互操作是全行业可以理解并有确定行业意义的互操作级别。或者说语义级别的互操做才是基于标准的互操作。

组织级别,通常都是由国家、行业协和和行业标准开发组织开发的。它加入了政策、社区、法律等方面的考虑,分析了通用的业务流程和工作流,在此基础上设定了参与互操作各方的角色、权限,服务和知情同意策略等。我们的互联互通,就是组织级别的互操作。

目前的卫生信息互操作项目多数停留在结构级别。只有达到语义级别的信息互操作/集成,才是标准化的信息互操作/集成,才能降低实施成本和提高实施效率。

做到语义级别的互操作标准并不容易,首先是消除语义歧义、其次行业普遍认可、再次是要覆盖行业用例并具有适应行业不断变化需求的弹性。

图片来源:EuroVulcan Conference 2023

先说消除语义歧义。要在信息交换时消除语义歧义,需要在语言、语法、词义、句法等多方面努力,而且涉及到数据的颗粒度。尤其在医疗行业,完整、消除歧义才能保障卫生信息准确和医疗行为安全!

HIMSS认为要消除语义歧义、达到语义级互操作性,需要基于五位一体的语义标准,包含:

  • 词汇/术语标准:依靠结构化的词汇、术语、代码集和分类系统来表示健康概念。例如ICD-10SNOMED-CTLOINC RxNorm行业里典型的词汇和术语标准。
  • 内容标准:描述信息交换中,数据内容的结构和组织。而HL7 CDAHL7 V2C-CDA都是行业内容标准。
  • 传输标准:定义了计算机系统、文档架构、临床模板、用户界面和患者数据链接之间交换的消息格式和传输方式。传输方式确定了卫生信息交换的“推”和“拉”方式。DICOMIHE等都是传输标准。
  • 隐私和安全标准:是确定谁、何时、出于何种目的、使用哪种个人健康信息的权利,以及如何护健康信息的机密性、可用性和完整性的标准。美国的HIPAA和欧洲的GDPR都是关于隐私和安全的标准。
  • 标识符标准: 是用来唯一标识患者、机构、医护技、设备等实体的方法。例如咱们互联互通里用到的OID和美国的护士标识NCSBN ID …

并非消除了语义歧义的标准就能被广泛接受和认可,需要行业标准化组织的推动,实现厂商中立,毕竟互相竞争的厂商很难接受对方的企业标准。回顾一下行业里流行的标准,无论是术语标准、还是消息和文档标准,都是行业里标准化组织发布的,其中最有名的就是HL7。

从这个行业标准发展史可以看到,毫无例外的,标准先从术语标准开始,例如ICD、SNOMED,历史都非常久远。而我们常用的HL7 V2有30多年历史了,CDA和V3也20年左右了。从2014年,HL7推出了FHIR。这些标准是为何以及如何演进的?

互操作标准发展要满足不断变化的行业需求和用例

先看看90年代初的互操作的业务环境,就像下图那么简单:医疗机构还处在数码化向数字化转换的时代 - HIS等业务系统开始大规模部署以实现流程和数据的数码化,同时产生了非常有限的跨业务系统的流程自动化 – 信息集成需求。实时卫生信息交换的需求基本都在医疗机构内部(局域网,那时候WWW刚诞生),而院内的业务系统数量非常有限、且系统边界清晰,使用的用户基本就是医护技和管理人员,需要的互操作流量规模可以准确预测。而且系统互操作的技术手段非常有限,基本就是文件传输、串并口、socket,而SOAP(2000年)、RESTful(2000年)、甚至HTTP(1996年)等协议都还没有产生。

HL7 V2

这就是HL7 V2消息交换标准产生的时代,和所面临的互操作业务需求:它将业务事件和业务事件的上下文封装在消息结构中,在系统边界中传递这些消息。

业务系统边界清晰,一般用消息引擎来路由和转发这些消息,从而不打破系统边界。各个业务系统只要能接收/发送并处理这些标准化的消息即可。

近距离看一个HL7 V2消息示例,它是一个由多种分隔符分割的字符串,由区段和字段构成:区段是一组分类的数据,例如PID是患者信息区段;而字段是每个数据项,例如患者标识(在PID区段里)是“1182594^^^系联医院&1^^系联医院&1”,它本身也是一个结构,用于放标识符(1182594)和标识分配机构(系联医院)等信息。

而事件就是消息头区段里的ORM^O01,其中ORM代表业务域”通用医嘱消息”,O01代表事件“医嘱请求”。

消息头区段 MSH|^~\&|HIS|系联医院|系联实验室|系联医院|202302160002||ORM^O01|demo22903||2.5|382|||||UTF8

患者区段 PID||1182594^^^系联医院&1^^系联医院&1|||李小明||19570320|M|||北京市朝阳区建国门外大街乙12号2702

就诊区段 PV1|22903|O|心内科||||35030099^唐^南|||MED|||||||35019964^郑^顾樽||22903|||||||||||||||||||||||||202302160002^M

保险区段 IN1|1|65110116^城镇职工医保|

医嘱区段 ORC|NW|MS:1182594:1|||SC||||202302160002^M||||||||||||||||||||LAB

医嘱明细区段 OBR|1|MS:1182594:1||4548-4^糖化血红蛋白^loinc

为什么HL7 V2会是这种难读的格式?因为它是窄带时代的产物,当时通讯带宽有限,数据格式需要紧凑,通常仅用分隔符分割,以减少传输的数据量(相较与XML,通常能减少80%以上的数据),如今在一些检验检查设备的通讯协议中还能看到类似的设计。同时,从早期直到现在,多数HL7 V2消息是通过socket交换的。这些特征都是90年代互操作的历史印记。

HL7 V2是按模式复用的角度设计的颗粒度,也就是说它的颗粒度是信息区段。但并不是所有的信息区段都有独立的含义和复用的价值,例如区段TQ1、TQ2定义服药时间和用药途径,没有单独存在的可能和直接复用的价值。

另外,V2消息的字段随意性很大,相同内容可以放在不同的字段甚至区段里面;用户还被鼓励创建自定义的Z区段进行消息体扩展。也就是说它标准化程度不高,需要实施的双方事先约定好数据具体怎么放才能实现信息交换。同时V2术语约束机制很弱。

HL7 V3 和 CDA

世纪之交,卫生信息化发展提速,电子病历和各种专科系统崛起,更极大推动了卫生信息的交换和流程自动化的需求,同时对交换的语义标准化程度有了更高的要求。这需要更严谨的互操作业务抽象和术语约束。卫生信息正式进入数字化时代,也正是在这一时期,诞生了包括IHE、CDA、HL7 V3在内的众多互操作标准。

从模型抽象的角度看,应该全面包含用例模型、信息模型和交互模型,但V2的关注点基本在交互层面,对其它层面的抽象很弱。

由此,携着其著名的参考信息模型(RIM)方法论,V3在2005年横空出世,对业务场景进行分析,抽象交互逻辑,从参考信息模型到领域信息模型,再到精细化消息信息模型,最终产生需要的消息模型。模型以XML进行序列化,相较于V2,进步了许多。

这套方法论产生的V3消息标准化程度很高。但为了覆盖所有业务需求,RIM是高度抽象的(难于理解的);同时V3方法论是“按约束设计”(design by constraint),试图涵盖所有应用场景,避免自定义扩展,这使其越来越复杂、越来越庞大,而且用户没有RIM基础很难自己对其扩展,从一个极端走向另一个极端。

V3的高复杂性和高使用门槛,造成了它事实上的失败,没有成为V2的替代者,就像一些专家评论的 – “RIM创建了语义互操作性,但没有创建临床互操作性“。

注意,国内有一些实践中,甚至没有严格遵循V3发布的XML schema,直接用代码拼出XML字符串,也不做消息校验,这不算标准的V3。

同样在世纪之交,很多业务需要即时性不那么强、但数据更完整的交换 - 小结性质的临床文档交换。在这个领域,最主流的是CDA临床文档架构标准。CDA源于 1996 年就开始的临床文档中结构化标记工作,并在1997年并入HL7,随后使用V3参考信息模型来完善和发展。大家可能注意到前面的图上CDA早于V3发布,就是这个原因。

CDA临床文档架构,用于描述结构化文档,同时允许插入供人类解读的非结构化部分。它产生的文档具有上下文完整、可持久保存、可管理、可认证等特性。CDA文档和衍生的CCD文档广泛用于医疗机构边界间和医疗系统边界间的文档交换,或作为具有法律效力的临床文档依据保存在文档仓库。

CDA是成功的,可能是V3基础上唯一成功的部分,但它不能解决细数据颗粒度访问的需求。

IHE

虽然RIM基于业务场景、角色、触发事件等分析,但它的交付物 – 消息模型并无法执行流程与角色的约束。

服务用于业务场景里流程、角色的表达,功能内聚,可以通过企业服务总线(ESB)来协同,比消息路由规则更直观、更灵活,更适合实现业务流程的自动化。通常服务是比较大尺度的业务表达,服务标准广泛采纳的难度在于它实际上是规范业务流程和业务方法,而实际上多数机构的业务并不那么一致。

IHE(Integrating the Healthcare Enterprise)是国际上比较流行而成功的卫生信息交换服务规范。它是1998年,由HIMSS 和RSNA(北美放射学协会)发起,由一帮放射学和IT技术专家创建的。它最初为放射影像信息共享提供技术框架,以解决即便有了DICOM后在不同厂商系统间放射影像信息交换的标准和流程上的困难,后面逐步涵盖了越来越多的业务场景。IHE使用已经发布的卫生信息内容标准和术语标准,例如DICOM、HL7、LOINC等,来构建自己的服务框架,利用企业服务总线来协同这些服务,可以实现比消息交互更功能内聚的互操作架构:

• 服务本身封装了事件、上下文

• 服务针对于场景定义了流程和角色

• 适合跨清晰的业务系统边界间信息交换

• 服务有多种互操作模式:

• Web 服务本身是可互操作的,这意味着任何客户端都可以直接调用 Web 服务

• 服务可以通过企业服务总线(ESB)来协同,比消息路由规则更直观、更灵活

IHE分析每个业务场景(Profile),将业务场景中参与方定义为角色(Actors),场景中角色的交互定义为事务(Transactions)。例如跨机构的文档共享业务场景中,有4个不同的角色:文档源、文档注册器、文档使用者和文档仓库。而交互事务有注册、查询、获取等

IHE能在服务标准上取得成功,在于它先在参与的用户基础上规范业务,然后再基于规范的业务发布相应的服务,也就是说,使用IHE需要先认同它的规范出的业务。

IHE一直随着业务、技术和互操作标准的发展而不断演进,从最初使用DICOM + HL7 V2,到最新基于FHIR;从最初的影像信息交换到最近的患者穿戴设备的数据交换。例如在2007年,IHE创建了基于HL7 V3的跨机构档案共享的Profile – XDS.b,之后又推出了基于FHIR的诸多移动端服务。

1 0
0 211
文章
· 三月 18 阅读大约需 4 分钟
IRIS/Caché SQL优化经验分享 - Tune Table

TuneTable(调整表)收集数据库中表的统计信息,用来为SQL引擎制定最优的执行计划。在其他数据库产品里,这个动作被称为“gather stats job"或者类似的名字,相比较TuneTable不是那么直白,但作用是一样的。

TuneTable是否要人工执行

一定要。

在IRIS 2023版本, 第一次加入了TuneTable的自动执行功能,在此之前的所有IRIS/Caché版本, 如果没有人工执行TuneTable, SQL引擎无法保证给出最好的查询计划。 即使是IRIS2023有了自动执行功能,也还需要人工执行TuneTable的操作,后面解释。

1 0
0 20
文章
· 四月 11, 2022 阅读大约需 8 分钟
InterSystems 数据平台与三级等保 - 第一篇

数据平台不仅要安全,还要合规,三级等保是我们要符合的主要安全规范。InterSystems的数据平台和集成平台产品都和三级等保有关。如果没有正确配置它们的安全选项,就会影响到整个系统的安全,影响到合规性。

在生产环境上,如何配置安全的InterSystems的数据平台,并达到三级等保的要求?

这个系列文章,针对InterSystems 数据平台的安全架构,围绕对三级等保的合规性展开,介绍如何配置出一个安全、合规的数据平台。

1 0
2 381
文章
· 九月 21, 2022 阅读大约需 3 分钟
第三十九章 连接到远程服务器(一)

第三十九章 连接到远程服务器(一)

可以从 Telnet 会话、WindowsIRIS® 启动器上的远程系统访问子菜单或从 Web 服务器和实例信息生成的 URI 控制远程实例。

要为远程实例使用远程系统访问子菜单上的实用程序:
1. 定义远程服务器连接以将服务器添加到首选服务器列表。
2. 单击 IRIS 启动器并指向远程系统访问。
3. 指向启动器实用程序,然后单击服务器名称。

还可以从 Telnet 会话连接到 IRIS 的远程实例:

  1. 单击 IRIS 启动器并指向远程系统访问。

  2. 单击 IRIS Telnet,连接到远程服务器,并使用用户名和密码登录 IRIS 系统。或者,如果服务器在首选服务器列表中,请指向终端,然后单击服务器名称。

1 0
0 75

2022年9月5日-10月24日(北京时间),我们正在举办🏆InterSystems开发者社区中文版首届技术征文大赛🏆(点击链接进入参赛页面,浏览所有参赛文章!投票截止至10月23日,你的支持与喜爱,是优秀作品获得“开发者社区奖”的关键!我们先来看看目前作品排名情况吧!

1 0
0 98
文章
· 十二月 9, 2022 阅读大约需 7 分钟
基于 IRIS SQL高级功能实现 CI/CD的技术原理和指导

在数量众多、形形色色的 SQL 数据库市场中,InterSystems IRIS 作为一个超越 SQL 的平台脱颖而出,它提供无缝的多模型体验,支持丰富的开发范式。 特别是,先进的对象-关系引擎已经帮助组织为其数据密集型工作负载的每个方面使用了最适合的开发方式,例如在通过对象获取数据并同时通过 SQL 查询数据。 持久类与 SQL 表相对应,其属性与表中的各列相对应,可以使用用户定义的函数或存储过程轻松访问业务逻辑。 在这篇文章中,我们将深入了解表面之下的一点底层技术,讨论它可能如何影响您的开发和部署方式。 这是我们计划发展和改进的产品领域,因此请不要犹豫,在下面的评论区分享您的观点和体验。

保存存储定义 {Saving the Storage Definition}

编写全新的业务逻辑很容易,而且假如您有定义明确的 API 和规范,那么调整或扩展通常也很容易。 但是,当它不仅仅是业务逻辑,还涉及持久化数据时,从初始版本更改的任何内容都将需要能够妥善处理通过早期版本获取的数据。

1 0
0 82

正如之前在 2022 年全球峰会上宣布的那样,InterSystems 将停止交付或安装基于 Apache 的web服务器(通常称为私有web服务器或 PWS);此更改目前计划用于 InterSystems IRIS 2023.2。


使用这种新方法,您可以完全控制选择最适合您目的的 Web 服务器,以及如何配置、维护和更新它。这一变化的一个主要好处是您将不再需要等待 InterSystems 的更新套件来获得最新版本,这在安全漏洞情况下尤其重要。 InterSystems 将提供可用于帮助配置 Apache 或 IIS 的工具。 (请注意,InterSystems IRIS Community Edition 将继续安装 PWS。)


安装 Web 服务器是一个常见的过程,通常很容易 - 各个 Web 服务器供应商都有详细的文档记录。

以下是适用于 Ubuntu、Windows 和 macOS 的示例。它们演示了快速安装,因此您可以看到当 InterSystems 产品不包含或安装 Web 服务器时的新行为。 (请注意,此代码按原样提供,不受支持,也不足以托管关键任务或数据敏感的应用程序。)

1 0
0 125
文章
· 三月 28, 2023 阅读大约需 1 分钟
安装本地 FHIR 服务器的最快最简单的方法!

嗨大家好!

最近我需要使用 IRIS For Health 设置本地 FHIR 服务器,我认为我找到了有史以来最简单的方法!

只需在终端中运行以下两行:

 docker run --rm --name my-iris -d --publish 9091:1972 --publish 9092:52773 intersystemsdc/irishealth-community

docker exec -it my-iris iris session iris -U "USER" '##class(%ZPM.PackageManager).Shell("install fhir-server")'

您将在 http://localhost:9092/fhir/r4 本地运行 FHIR 服务器。

就是这么简单!

FHIR 服务器将使用最新版本的 InterSystems IRIS for Health Community Edition,并将通过 FHIRSERVER 命名空间中的 IPM 包从该应用程序部署 FHIR 服务器

这是针对 Mac OS的,所以请在评论中添加它在 Windows 中的工作方式。

这是一篇非常短的文章,因为使用 InterSystems IRIS for Health 和IPM Package Manager 设置本地 FHIR 服务器真的很容易。

1 0
0 144

第六十一章 镜像中断程序 - 计划故障转移到提升的 DR 异步

计划故障转移到提升的 DR 异步

如果在镜像中包含一个或多个 DR 异步以提供灾难恢复功能,则最好通过计划的故障转移到每个 DR 异步来定期测试此功能。要执行此测试,或者当出于任何其他原因(例如包含故障转移成员的数据中心计划停电)而想要故障转移到 DR 异步时,请使用以下过程:

  1. IRIS C 提升为故障转移成员;因为 IRIS A 可用,所以不会要求您选择故障转移伙伴。 IRIS C 成为备份, IRIS B(如果存在)降级为 DR 异步。

注意:如果镜像仅包含一个故障转移成员,则过程相同;不需要选择故障转移伙伴, IRIS C 成为备份,因此镜像现在有两个故障转移成员。

1 0
1 50
公告
· 二月 22, 2021
版主招募进行时

大家好!

InterSystems开发者社区中文版正在招募版主,以更好地推动中文社区建设,期待每一位开发者的积极参与,共同打造一个高效沟通的技术社区!

欢迎点击报名(或扫描下方二维码),审核通过后,我们会与您详细沟通版主权益及义务。

1 2
1 196
文章
· 四月 18, 2021 阅读大约需 5 分钟
IRIS Docker的安装

IRIS相比Caché在部署上的一个进步是支持docker。即便不是云部署, 使用docker也带来非常多的便利。 尤其是在开发测试环节,由于docker的使用更便捷,除非要模拟客户的环境或者做规定的性能测试,我在测试中基本已经不再使用本机的实例或者虚机。IRIS的联机文档有详细的IRIS docker安装使用指导,本文只是一个简单的,快速上手的在测试环境安装IRIS docker的简单步骤,尤其适合初学者。

注意Windows上docker可能会遇到这样那样的问题,因此通常还是推荐在Linux或者Mac OS上使用。正式的生产环境的IRIS docker container也是不支持Windows系统的。

1 0
1 386

FHIR是快速医疗互操作资源(Fast Healthcare Interoperability Resources)的缩写,所以FHIR的核心是资源模型。它的颗粒度和结构都优于之前的V2 、V3、CDA标准,而且能够灵活扩展。另外一个优势就是它的API,它不仅提供了针对于资源模型本身的原子化的CRUD(创建、读取、更新、删除的这样一些原子化操作),而且提供了查询这种更复杂操作的能力,同样API是可以扩展的。

1 0
1 335

亲爱的开发者们,我们很高兴地跟大家分享一个好消息!

我们的社区全球注册会员突破10000名!中国开发者社区不到一年时间突破270人!增速全球第一!这是一个了不起的成就!感谢大家的支持🎊

在InterSystems,我们相信社区的力量。所以我们非常感谢你们在过去六年里所做的贡献,并期待未来的道路!

1 0
0 63