Each instance of Caché keeps a journal, a set of files that keeps a time-sequenced log of updates that have been made to databases since the last backup. The process is redundant and logical and does not use the Caché write daemon
Following my previous post, some urged me to get to the point – ok, so I found my "star" journaling globals, the ones that take up the most space – but how do I avoid this? How do I minimize the journal's size?
[DISCLAIMER: Some might still be disappointed after this post as well but wait till the next one... ]
In this article I'd like to share with you a phenomena that is best you avoid - something you should be aware of when designing your data model (or building your Business Processes) in Caché or in Ensemble (or older HealthShare Health Connect Ensemble-based versions).
I am still working on a generic task where I need to apply journal file records to another database. Initially I didn't want to use Journal.Restore class methods as I need to perform some data transformation, and it seemed that the clearest way to achieve it was to read journal file record by record using %SYS.Journal.Record API.
My fantasy didn't go beyond periodically running %SYS.Journal.System:Progress() class query, while I'd prefer to use an event handler of some kind. Any ideas?
We have Mirroring established between NODE 1 & Node 2 . We have set the "cachesys" database enabled for Journalling. But we dont see the User Accounts , Roles, Resources created on Node 1 ( favoured Primary) reflected on Node 2 . Is creating them manually again is the only option for this ? . Is there any way to sync them or would adding %SYS to MIRROR a possible solution. Would it be great if anyone has faced this as we have an issue that during failovers Team is locked out .
There are two types of journaling built into Caché and Ensemble to help insure data integrity. The Write Image Journal and database Journaling protect the integrity of your data from both a Caché and application perspective.
For I=1:1:200 Set ^ABC(I)="" For I=1:1:200 Set ^XYZ(I)="" For I=1:1:100 Kill ^ABC(I)
2. create ZJRNFILT
ZJRNFILT(jid,dir,glo,type,restmode,addr,time) /*Filter*/ Set restmode=1 /*Return 1 for restore*/ If glo["^ABC",type="K" Set restmode=0 /*except if a kill on ^ABC*/ Quit ;
Just wondering if anyone knows if there is a way to get daily emails or alerts about changes to a cache database. I know that all of that information is contained within the journal files, just wondering if there is a way to bundle it up each day and send it off for auditing, etc.
Any solution where a plain-text/readable format of changes to the cache database could be sent or stored for review would solve the issue.
I'm a DBA and support Caché databases on AIX. I coded shell scripts for monitoring journaling status, databases size, license end date.
We recently got a new instance of Caché on Windows. I'm just curious to know whether anyone coded database monitoring scripts on Windows using PowerShell or any other scripting language.
I'm purging a lot of management data from an Ensemble production, which is creating 100s of GBs of journals. Has anybody succeeded in disabling journaling on an Ensemble purge? The user interface doesn't have an option for this, but I'm thinking you might be able to identify the process and externally disable journaling on it.
We are using CACHE 2017.2.1, I would like to retrieve data from Journal for killed global. Let say we have global name ^ EMP(123) with data and also have some child nodes and it has been killed by using cache kill command for some reason and we don't know who has executed this and when. My questions are below.
1) Can we get back the data of killed global from journal files,Is it possible or not ?
Currently, we are running 2014.1 on two different servers (OpenVMS, RHEL). The plan is to transition from OpenVMS to RHEL, but our Write Daemon is in a Troubled state on both servers.
On the OpenVMS server, we have a WIJ file that's 26G and can grow to 40G (size of database cache). Since it hasn't grown to 40G, we don't believe the size of the WIJ file to be the issue.
What else should we be looking at regarding the performance of the Write Daemon?
I have noticed that my backup mirror is warning that the MirrorDatabaseLatencyTime is having a bad time (time in ms is 3000, and warnvalue is 3000). While I look into what may be causing this latency between the two servers, I was considering if reducing the size of the journal files would improve this value in any way.
My assumption is that reducing the file size would mean that the frequency of the journal files being created would be increased, but the reduced size would mean that the transfer and application of each file would be reduced.
I'm working on a task where I need to apply journal file records to another database. I can't use Journal.Restore class methods as I need to perform some data transformation, therefore I'm reading journal file record by record using %SYS.Journal.Record API.
It seems that there are only few journal records that I need to process, namely:
Part 2/3 in the Intro to Caché System Management functionality series, this presentation discusses Journaling, including the WIJ and the JRN. The journal settings and journal switching is then demoed.
I've stumbled on some unexpected behavior, and decided to check with you if this is normal. Basically, I'm rebuilding indices and the result is not journaling (which leads to missing indices at shadow server).
The $ZV is "Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2015.2.1 (Build 705U) Mon Aug 31 2015 16:53:38 EDT"
I have an example class
Class tmp.A As %Persistent;
Index IP1 On P1;
Property P1 As %String;
for example there is one object which have P1 = 1, so
By likes
1m read
but wait till the next one... 
]
