Question Created Date discrepancy - how to resolve?

[Cringer]

I've been playing around with the sports2000 db to see if something is possible. We thought we had corruption on an index area yesterday (thankfully after a DBANALYS we found it was Progress misreporting). Because of a number of things the last backup was therefore broken and due to a tape issue we weren't confident in our AIs either. The plan was to bring replication over to production and use that, but that takes a while.
The corruption was in an index area so I thought I'd have a play around with something. Here is what I did.

• Created Sports2000 (and did some fiddling to make it Type II storage).
• Took a backup
• Created some records
• Imagined corruption in area 10 (index area)
• Performed crash recovery
• Restored the backup somewhere and copied the files for area 10 over the ones in "production"
• We have date/time stamp issues, so did a proutil unlock
• did idxbuild all

That all worked a treat, but now I get:

                Fri Nov 28 10:24:46 2014
[2014/11/28@10:24:46.615+0000] P-7656       T-5448  I BROKER  0: (9214)  Creation date mismatch. 
[2014/11/28@10:24:46.616+0000] P-7656       T-5448  I BROKER  0: (9212)  Extent C:\Database\s2k\s2k_10.d1 has the wrong creation date Fri Nov 28 10:22:43 2014, 
[2014/11/28@10:24:46.617+0000] P-7656       T-5448  I BROKER  0: (9216)  Control Area has a creation date of Fri Nov 28 09:26:24 2014. 
[2014/11/28@10:24:46.617+0000] P-7656       T-5448  I BROKER  0: (605)   Probable backup/restore error.

Is there anything I can do to get around that?


Yes I know it's not ideal, but I was interested to see if it would work.

11.2.1

 

[Cringer]

I decided to try running prostrct unlock again and then built the indexes again and it seems to have worked.

 

[Rob Fitzpatrick]

Personally I wouldn't want to have to rely on tape for AI extents that I care about. I've had too many tapes (and tape drives) go south on me over the years to trust them. By all means you want to back up your AI extents, DB backups, structures, etc., and have copies in more than one place including off-site, but I prefer to back them up to online storage.

I'm curious about the evidence you saw for corruption corruption and how inspection of a dbanalys report eliminated that concern.

Also, and I'm sure you realize this, it sounds like you need to revisit your backup strategy.

 

[Cringer]

Thanks Rob. Yes we need to revisit the DR strategy. Ours is pretty much non-existent. But I am not going to talk about it here because I'm likely to get angry and say something out of place.

As for the corruption - we had a dbkey error at the point the database crashed yesterday. But a DBANALYS completed successfully without crashing so as far as I'm aware that means there is no actual corruption, as a dbanalys reads every block in the db.

 

[Rob Fitzpatrick]

When you say dbkey error do you mean an (1124)?

 

[Cringer]

[2014/11/27@08:22:26.294+0000] P-18092 T-27168 I ABL 181: (9445) SYSTEM ERROR: read wrong dbkey at offset 501735424 in file F:\DATABASE\LIVE\icmasliv_26.d1
found 6361856, expected 61247, retrying. area 26

 

[Rob Fitzpatrick]

Have you followed the suggestions in the KB articles that come back from ProKB with a search on error 9445? There is one that is particular to Windows, about insufficient paged pool.

 

[Cringer]

Have you followed the suggestions in the KB articles that come back from ProKB with a search on error 9445? There is one that is particular to Windows, about insufficient paged pool.

Thanks Rob. Yes we've done a number of things, but we're still on a 32bit OS and very reticent to make too many memory affecting changes. We are also very short on disk. I don't think the paged pool change is something we've changed.
We are upgrading our server hardware/software etc early next year.