custom db has taken on main qad db schema

sbetcher

New Member
[FONT=Verdana, Arial, Helvetica, sans-serif]The custom DB has taken on the QADDB schema and backup size. The backup[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]went from 37 MB to 6.4GB in a half of a day. Even though the db files[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]appear to only be 37 MB. The database appears to be in tact but any[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]reference made to schema ie webspeed broker and Progress editor DB tools[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]shows the schema for the main qad db. [/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]The log file only shows reference to a vv_flush error and a (1068) error[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]which both seem to be fairly harmless according to the knowledge base.[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]I am unaware of any changes that have been made to the server (I should be[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]the only one to make them) for quite some time and the scripts have not[/FONT][FONT=Verdana, Arial, Helvetica, sans-serif]been modified since March.[/FONT]

I have no idea how this could happen. MFGPRO seems to be running fine, but no one would access these tables directly from MFGPRO only through webspeed brokers. I have also submitted a incident to QAD, but I was curious if anyone has seen this before? If anything maybe we will all learn something today. Is there anything I should look for?

Progress 9.1d (yes I know it is obsolete, planning the upgrade with beautiful blade servers as we speak).
 
This seems like an MFG/Pro specific question so you might have more luck on that forum.
 
I uderstand this seems like an MFGPRO issue, however this is definitely something with the database. QAD has never seen this before. I am currently on the second call with them. Nothing in the log file even looks like an issue. Promon looks like the main db, from the progress editor it looks like the main db, you can even run a query against it and get results even though the tables aren't actually in this database. There are only three tables in the db and none of which are the cm_mstr and I can write a query against the cm_mstr.

I know this seems like I am crazy. I wouldn't believe it either if I hadn't seen it for myself. I actually could create a new database and move on without a problem. Why did this happen and how do I keep it from happening again, is the million dollar question?
 
There is no process which will produce this result. DBs simply don't suddenly acquire the schema and data of another database.

Most likely, your cause is something external, like backing up the main DB and then restoring it to the custom DB. It has to be something like that.

The log is your best bet. Look for backup and create messages.
 
There is nothing in the log that is why this is so hard.

They are thinking it is a corruption within shared memory, they were actually able to find that it is somehow pointing to the main db in our test directory.

Their recommendation is to shut all of the dbs down and run proutil dbipcs and clear the shared memory. I am that far so I am just going to reboot the server instead. Once the server is backup I will enter them with pro dbname and check the schema.
 
The reboot did it. The schema now appears as it should. The interesting part and somewhat proof that it happened is when I logged into the main db for test (the database the custom db was pointing to from production) in single user mode it stated that the last backup had failed. I do not perform progress backups on my test databases, so this error is due to my custom db backup actually attempting to backup the this one.

Well I just thought everyone should know thank you to those who read the posts and tamhas for replying.:confused:
 
I hope someone understands what happened here ... I don't claim to. Getting shared memory wires crossed without crashing the database seems incredible, but how would that explain the change in size? Or, did the size not actually change?
 
I definitely can't explain it, I wish I could because then I may know how to prevent it. All I can tell you is that they ran a query on _AreaExtent which showed the extents located in /test/ when we logged into the database from /db/ which is where the db extents actually reside for production.

If someone has any ideas of how this happened I am listening (well reading anyways).
 
Hi all,

sometimes, we get the database crossover issue - connecting to one database through TCP ports that we know to be TEST and it turns out to be LIVE...

This normally occurs after a server crash (or someone pulled the plug) when the databases get started automatically at reboot, or when Linux does something odd... As I said, it is rare, and we put it down to shared memory...

We simply shutdown the DB's, (reboot to sort linux out if needed) fix the DBs and start them again...
 
Back
Top