Re: Help with DSPJRN command

On Thu 05-May-2011 09:42 , Ashish Kulkarni wrote:

I wanted to know is there a way to filter records when creating
journal entries? For example, I have a table called PERSON, with 4
columns, NAME, LASTNAME, ID, DOB

When using command DSPJRN to journal entries, can I say populate
journal entries where NAME = 'John'

The reason I want this is because this table is populated or changed
very often and if I run DSPJRN it takes a long time to build as it
has lots of records.

Journaling is the basis for both isolation [commitment control] and recovery. There is no ability to limit\filter the data because the capability to effect both of those functions would be nullified if any filtering were allowed.

The given example seems unlikely to accurately represent data that "changed very often", so perhaps if the data is something different than the example suggests, consider that further normalization of data may enable limiting journaling for logging purposes to encompass significantly less data.

The speed of DSPJRN can be improved when the search can be and is limited to a specific receiver on the RCVRNG; optionally a TOTIME() which precludes any new entries beyond the invocation of the DSPJRN. In some scenarios there could be a means to effect a CHGJRN to generate a new receiver in coordination with the time and need to perform the DSPJRN request.

If not specifically coordinated [CHGJRN and DSPJRN], the historical results instead can be stored in a database file and only the more current [since the last] DSPJRN be added to the same database file [or another, for a UNION result] against which a query is directed. RCVJRNE or similar could be used to limit the data sent to the database file, but any selection is limited to what was filtered there. The storage and retrieval with\via the database file will, by the nature of design and purpose, allow for faster selection and retrieval than with\via the journal. Note: Like with purging old receivers that are no longer necessary, steps would need to be taken to do the same with the old data in the database file. Note: A database file is just one storage means alluded specifically because there is an existing querying capability via SQL, although any other data storage location with select\retrieve capability which should be faster than DSPJRN to locate the desired data is the point.

If the reason the database file object was journaled is merely for the "logging" of specific actions versus for purposes of isolation and\or recovery, then limit the logging to those actions within the applications [if those actions are limited only to those applications] or move that logic into the database via a TRIGGER of those actions. At that point, the logging location typically would no longer even need to be a journal. When such logging is specific to data selection, that is often referred to as having established a "subscription" to specific data; i.e. a subscription to the data based on selection NAME='JOHN', where the trigger can interrogate the established subscription(s) and to perform the desired action(s) according to the rules of any matching subscription(s).

Regards, Chuck