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
midrange.com
