Hi all,

I'd like to give our customers (mostly non-techies...) an easy way to check:
1. are all databases checkpointed?
2. are all databases journaled?
3. when was ckpd run the last time?
4. journaling=on for all tables in a database?

Is there any solution available for that? If not, I'll consider writing
my own tool for that and publish it on the WIKI.

Concerning 4. I could run an SQL like this
select table_name, is_journalled from iitables
where is_journalled != 'Y'
and table_type = 'T' and table_owner != '$ingres'
against each db.

Concering 1, 2, 3 it seems I'd have to parse output of infodb command,
right? Or is that information also available by querying imadb or iidbdb?

Thanks for any thoughts or suggestions regarding this topic.

Regards
Gerhard Hofmann

For 1-3, yes all of that info is in the database config file, and
parsing infodb output would probably be the best way to get at it. None
of that info is mirrored anywhere in iidbdb. (Which is probably a good
thing. The small duplication of info between the db config file and the
iidatabase row causes enough problems as it is; I'd hate to see it get
even worse.)

If you are feeling adventurous, it might not be too hard to write an
alternate infodb variation that outputs the data in an easier to parse
form, such as "field = value" down the page or something. I suspect
that such a thing would prove useful.


--
kschendel

to 4: Yes you can achieve this by sql.

I see using infodb output to get some specific info is a great idea!

infodb source is: 'Ingres RDBMS/src/back/dmf/dmf/dmfinfo.c'
(http://lxr.ingres.com/lxr/source/src.../dmf/dmfinfo.c)

I've checked in source code imadb object definitions. Their objects
have been defined as 'exp.xxx.yyy...'.
Cannot we define infodb data structure on the same way, so it can be
used within imadb too?


--
bilgihan

bilgihan;29001 Wrote:
Unfortunately I don't think that is practical. The IMA data points are
basically a way to present variables within the DBMS server (and other
components) from SQL queries. The server doesn't keep a copy of the DB
config data around at all times, not even for open databases, so there
would be nothing for IMA to point to.

There is a built-in DB procedure ii_read_config_value that lets you
read some config file values, but it was designed for upgradedb and the
range of things you can read is very small. Also, I'm not sure that
non-privileged programs can use it. It might be possible for someone
(else!) to expand ii_read_config_file to return more "stuff". However I
think it would be easier to produce an alternate parse-able infodb.


--
kschendel