Unable to fix corrupted table (No of Records around 55 lakhs)

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

yogha - 03 Jun 2007 09:12 GMT

Dear All,

I am facing a problem while fixing a table which is corrupted.
Before try to fix the problem (through verifydb), I want to secure the
data
by means either copydb -c option or create table as select * from option.
however I am unable to do so.
While running the above two methods, I am getting following
error when I tried CTAS (Create table as select)

E_US1264 The query has been aborted.

While trying by copydb with copyout.
====================================

E_SC0206 An internal error prevents further processing of this query.
Associated error messages which provide more detailed information
about
the problem can be found in the error log, II_CONFIG:errlog.log
(Fri Apr 6 02:16:59 2007)

E_CO0048 COPY: Copy terminated abnormally. 0 rows successfully copied
because either all rows were duplicates or there was a disk full
problem.

(0 rows)
continue
*
Ingres Version II 2.0/0001 (su4.us5/00) logout
Fri Apr 6 02:16:59 2007

Also the server is old and there is space constraint.

I can run the query as select count(*) and getting the output.

┌─────────────┐
│col1 │
├─────────────┤
│ 5584690│
└─────────────┘

But while running the query by

Select count(1) from the table;
Executing . . .

E_QE007C Error trying to get a record.
Associated error messages which provide more detailed information
about
the problem can be found in the error log (errlog.log)

Please help in this regard.

Reply to this Message

John Dennis - 03 Jun 2007 11:18 GMT

> Dear All,
>
> I am facing a problem while fixing a table which is corrupted.
> Before try to fix the problem (through verifydb), I want to
> secure the data

...

> I can run the query as select count(*) and getting the output.
>
[quoted text clipped - 15 lines]
>
> Please help in this regard.

Yogha,

I suspect that your table will either be BTREE or have a secondary
index. A select count(*) will use the index pages in a BTREE, or a
secondary index because it is a faster way to count. When you say
select (1) you are forcing every page in the table to be read, and you
obviously have a corruption in the table.

What errors are being reported in the errlog.log ?

If your table has a secondary, it may be possible to retrieve all (or
most) of the rows by explicitly joining with the secondary.

However, the best (and only supported) course of action is to recover
from a checkpoint and journals. Any other form of recovery is
something which is only done as a last resort, and cannot be
guaranteed to recover all of your data.

John

Reply to this Message

Chip Nickolett - 04 Jun 2007 04:48 GMT

You should copy the underlying data file(s) before running verifydb.
You can find the file name using the query "select * from iifile_info
where table_name = '<table name>';" This way you can always restore
the base table to the point you are at now, although you will want to
drop any secondary indexes and make sure that you don't otherwise
alter the table (e.g., modifying from btree to heap).

Reply to this Message

Raghavan - 05 Jun 2007 17:20 GMT

> Dear All,
>
[quoted text clipped - 48 lines]
>
> Please help in this regard.

Hello!
Read the errlog.log file. See if it is terminated due to log file
full.
U can try
1. increase the transaction log file with cbf.
2. in case ur journaling is ON then stop it and try again.

Raghavan

Reply to this Message