The option to not use the Recovery Database

[Jon Blanchard]

Version 6.1

16GB RAM

300GB disk space

AIX (8 processors @ 3GHz)

I just learned that ADTs from Epic will include three markets in a single interface from Bridges.  That may or may not add up to much, since ADTs from two of our three markets to the engine don’t come close to taxing the current interface builds.  All interfaces for the third will be built on Cloverleaf, as part of the Epic build.

Thinking five years ahead, if Ardent adds two more markets to the production Epic system, then the engine may receive ADTs from five facilities that, by themselves would not overtax the engine. Multiple that total times three and a single inbound thread may begin feeling the pressure to keep up.

In trying to create a well-greased inbound thread that simply acks, detects the market trxid and shoots the message through, what is the impact of not using the Recovery DB and using only inbound and outbound message history storage?  Is there any substantial performance improvement or is the Recovery DB use not an issue for other Epic users?

Thanks in advance for your response.

Migration Consultant
Coffee Regional Medical Center
Eastern Time Zone

Topic

[Michael Hertel]

If you don’t use recovery database, and there are queued messages and you stop the interface, you will lose the messages.

I wouldn’t go there. IMHO   😛

[Russ Ross]

Look at turning off SMAT to reduce the disk I/O bottlenecks, especially if some of the SMAT is redundant like with local interfaces from one process to another or from one site to another.

Also if you didn’t already know this, recovery DB turned on typically only makes sense for receiving interfaces and not for sending interfaces.

Turn off recovery DB for sending interfaces, but not for listening interfaces, because like mentioned earlier messages will be lost if an interface with messages queued or in flight is cycled.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies