Suppress proutil idxfix message

[KlausErichsen]

Progress 9.1E03, AIX, Enterprise db

I truncated an area with one table and therefore the indexe become inactive.

I now want to idxfix the indexes to reclaim the space which is now used by the indexes.

I started proutil MyDB -C idxfix | tee idxfix.log
Then I selected one index in the table and the process started.

I got an message
Index 284 (PUB.OrdStat_old, OrdStatID): Deleted key 0 recid 161466383. (8828)
for any record in the table where the index entry is deleted.
I had 300 million records, so I will get 300 million lines in my db.lg file, the resulting logfile is a little bit bigger than 2 GB...

Is there any way to suppress these message?

I tried "-verbose" as parameter, which is somewhere stated to bring the messages only to the screen and not to the db.lg file, but that doesn't work.

Best Regards
Klaus

 

[TomBascom]

Why not drop the indexes?

Then re-add them.

 

[KlausErichsen]

Hello Tom,
I can not drop them. The table is tool large, the drop will take more than a whole weekend. To work around this problem, we replicated the table.

Then I truncated the old table area, but I can not truncate the index area, because there are other indexes in that area.

Regards
Klaus

 

[bulklodd]

Why not drop the indexes?

Then re-add them.

Oh, I've done this thing recently (PROGRESS 9.1D) and my bi file exceeded 2GB. Fortunately I had enterprise licence and I was able to enable large files to solve this problem otherwise it would have been big PITA.
It's difficult to explain why progress have no ways to delete an index without bi growth.

 

[TomBascom]

How about:

1) rename the old table

2) since it was empty, create it's schema from scratch (including the indexes) (and this time put the indexes in an area of their own :awink: )

3) deal with the old indexes at your leisure

-- or --

If the indexes are mixed in with stuff that is much smaller move the small stuff out of that area and then truncate it.

-- or --

If this 300M row table is the bulk of your database then perhaps a dump & load would be faster.

 

[KlausErichsen]

Hello Tom,
thanks for your suggestions. Was at the PTW, so my answer is late

How about:
1) rename the old table

Did this already.

2) since it was empty, create it's schema from scratch (including the indexes) (and this time put the indexes in an area of their own :awink: )

I do not believe that Progress will forgot the old indexes if you recreate the table.

If the indexes are mixed in with stuff that is much smaller move the small stuff out of that area and then truncate it.

That was one of our ideas, but although the other stuff is small, the indexmove will take long, because of the Storage Area Type I - need a full Area scan for move.

If this 300M row table is the bulk of your database then perhaps a dump & load would be faster.

Unfortunately there is another 300M Table...

But we will go to V10 next month and then I will try the multithreaded D/L feature :biggrin:

 

[TomBascom]

2) since it was empty, create it's schema from scratch (including the indexes) (and this time put the indexes in an area of their own )
I do not believe that Progress will forgot the old indexes if you recreate the table.

No it won't -- but since you're building a new table you can ignore the old ones. They will have the same index name but that doesn't matter -- it's sort of like having the same field name in more than one table except that there is never a situation where it could be aqmbiguous.

 

[azfmc]

Hello,

Can I please ask a question regarding multithreaded D/L feature? We are moving next month too . And I just started researching this. Have you seen any code for such an operation out there? Are you going to move data directly between databases? Thanks a lot.

But we will go to V10 next month and then I will try the multithreaded D/L feature :biggrin:

 

[TomBascom]

There is a new feature in OE10 that supports multi-threaded d&l directly. But you have to be running OE10 in order to use it... You can, of course, do a conv910 to quickly get to OE10 and then do the d&l but a lot of the benefits don't work as well with type 1 areas as they do with type 2 areas (in other words a simple conversion won't do a whole lot of good -- you need to dump & load and get to type 2 areas before this stuff works well...)

If you're stuck with something less than OE10 I did a presentation at Exchange on the topic. You can get that presentation and the scripts used at Greenfield Technologies.