conv910 problems with corrupt indexes: is there a standard procedure?

[palthe]

Hi fellow Progress fans,

In the last few weeks we had 4 separate cases in which a proutil conv910 leads to (assumably) corrupt indexes and even corrupt database blocks.
(9.1E sp4 > OE 101C sp3).

Is there an explanation for this and a standard procedure for conv910 which is 100% bullet proof?
My guess: do an idxbuild before AND after the conv910.

(and yes, of course a dump reload is the best way to go but this is very time consuming)

 

[rstanciu]

Hi,
in my opinion, "corrupt indexes" or "corrupt database blocks"
are more linked to hadware problems or "intensive use" of kill -9
You have to quick migrate you database. If the dump&load time is very big
or you database have to be up all teh time, there is a method.
If this is the case, give me a "beep" to rstanciu@operamail.com and I'll send the procedure.

 

[TomBascom]

Have you opened a case with tech support?

Index corruption is certainly not an expected outcome of conv910.

Obviously if you have databases lying around with corrupt indexes you have big operational problems. Use of kill -9 would certainly be on my list of probable causes. Hardware mismanagement would be too.

A dump & load does not have to be overly time-consuming. You should be planning on doing one post conversion anyway so that you can start using type 2 storage areas.

How big is the db?

 

[palthe]

Have you opened a case with tech support?

Index corruption is certainly not an expected outcome of conv910.

Obviously if you have databases lying around with corrupt indexes you have big operational problems. Use of kill -9 would certainly be on my list of probable causes. Hardware mismanagement would be too.

A dump & load does not have to be overly time-consuming. You should be planning on doing one post conversion anyway so that you can start using type 2 storage areas.

How big is the db?

Hardware mismanagement is excluded; this happened in 4 totally different cases. kill -9 is from the UNIX era isn't it? This all happened in Windows environments. I haven't opened a tech case with Progress yet, 'cause I want to be very sure it has something to do with the conv910. The case right now is that we had 4 different databases which were running fine in 9.1E. After the conversion, all kinds of troubles began to surface.
So it could very well be the case that the corrupt data already was in the db, but it surfaced on behalf of the conversion to 10.1C. I want to do some deduction on the case before submitting it @Progress.

 

[tamhas]

I'd go straight to tech support.

"Unix era" ... like it was over?

 

[GregTomkins]

Yeah, the Windows Era seems more likely to end, someday, than the Unix Era. Check out the Google OS announcement. Long Live Google!

 

[palthe]

I'd go straight to tech support.

"Unix era" ... like it was over?

Whoops, didn't mean to step on anybody's toe there .
Well, to be honest with you, in our line of business it seems that more and more customers are migrating to windows environments.
Not because of any downsides to UNIX, but yes there are not that many UNIX experts compared to windows experts, to be honest. So migrating seems a more or less economic decision (which isn't?) in our line of business.
Whole different thread, whole different discussion... Consider it a slip of tongue which really hasn't got anything to do with the topic, other than the fact that the problems did occur on windows machine, not on UNIX machines.

I really need a case before going to tech support. I was probing the Progress community to see if our case is isolated. It really seems so, and I want to be sure the data wasn't corrupt before the conv910.
Thanks for the reply

 

[palthe]

Yeah, the Windows Era seems more likely to end, someday, than the Unix Era. Check out the Google OS announcement. Long Live Google!

Yes, well...
Long live character based and so on.

 

[TomBascom]

The Windows equivalent of kill -9 is to use the task manager to end a process.

And rebooting a server with the database still running would be pretty bad too.

Both events are distressingly common in the Windows shops that I'm familiar with

It sounds to me like these are databases that have not had much attention over the years so it seems likely that the events described above could well have occurred. You might want to proactively rebuild indexes and maybe do a db scan prior to conversion just to clean them up.

BTW -- if I'm right about the lack of attention then it is also likely that you have multiple years worth of history in the .lg files. You might want to scan those files for evidence of using -F and doing mock index rebuilds. There is no better way to corrupt a database while preserving the illusion of integrity.