datafile is not getting backed up

[rony25]

error :
./aaamnncd.t04: file changed size
Fri Dec 11 03:23:50 2009 E_DM1101_CPP_WRITE_ERROR Error writing checkpoint.
Fri Dec 11 03:23:50 2009 E_DM110B_CPP_FAILED Error occurred checkpointing the database.

looks like that specific file has corruption.

I want to know what all tables are residing in this perticular file(aaamnncd.t04)

so that i can query an select statement to know whether it reads the data from this perticular file.

Please assist


ingres version 2.0
HP-UX B.10.20 U 9000/869

[daryl.monge]

A physical database file is changing its actual size while the Unix "tar" command is processing it as part of the checkpoint. Some OS vendor "tar" commands do not like this and report and error rather than a warning. The solution is to either use a version of tar which will not abort when it detects this problem or write a wrapper script for your checkpoint.
Reference: Checkpoint template documentation
Ingres ServiceDesk document id 415384 (provides a wrapper script)

[rony25]

Thanks Daryl,

The physical file is not getting copied to another location as well "bad copy to /tmp/aaamnncd.t04: read: I/O error".

Is there any way that we can find out what all tables data resides in this datafile,so that i can query an select statement to know whether it reads the data from the tables resinding in this file.
If that is know we can actually go for an restore before the users access those tables and avoid the yearly stats fail.
Please suggest

[denjo02]

The physical files relate one-to-one with database tables - with one file in each database location across which a table is spread.

The iifile_info catalog will show you the relationship:

select table_name, owner name from iifile_info
where file_name='aaamnncd'

[rhann]

There is no point in copying the data files of actively updated tables anywhere.

Ingres uses a fast commit protocol that pretty much guarantees that the image of the table on disk is incomplete pretty much all the time. (This means the database on disk is logically corrupt most of the time; the cache and the locking and logging system work together to give you a consistent image of the database.) The checkpoint/rollforwarddb utility knows how to keep track of the file mutations so that it can restore a consistent image of the table; nothing else knows how to do that.

If you need to copy data files you have to first shut Ingres down in an orderly fashion so that what is physically on disk is logically complete and consistent.

[rony25]

Thanks Denjo/Rhann.
Your suggestions sounds sensible.
Thanks somuch for your quick support.