Operating System - OpenVMS
1753534 Members
4945 Online
108795 Solutions
New Discussion юеВ

Re: RDB Database on old VAX ver 6.2

 

RDB Database on old VAX ver 6.2

I need to replace a table with a version a previous version of a table without overwriting the whole database. There is no one in my office that knows how to do this. I cannot find how to do this. Can anyone help. The table was updated incorrectly through a com process.
3 REPLIES 3
Hoff
Honored Contributor

Re: RDB Database on old VAX ver 6.2

I'm going to presume you don't have an RMU /BACKUP archive of the database here made proximate to the errant DCL command procedure and (I presume) the errant SQL contained within, and it's likely that journaling wasn't enabled here.

If that's the case, we're going to need a look at what the unspecified command procedure did to the unspecified table. How the table and the database are configured. Also some idea of what was in the data prior to the update.

SQL changes to a table can range from simple to massive, and AFAIK there's not a "rollback my database to look like it did last Thursday" mechanism within Rdb.

You can roll forward using an RMU copy and a journal, but that's dependent on the database configuration.
Richard J Maher
Trusted Contributor

Re: RDB Database on old VAX ver 6.2

RMU will let you restore just one storage area (or even a single page) and then roll-forward the AIJs if you like. Was this table the only thing in it's storage area?

Otherwise do you have an old/useful copy of the database or the particular table anywhere? RMU/[UN]LOAD may help.

Restoring the whole database is usually the way to go.

Cheers Richard Maher

PS. There are "logminer" products out there but I think they're only good for "after" images?
Brad McCusker
Respected Contributor

Re: RDB Database on old VAX ver 6.2

We provide DBA services for lots of Rdb sites. Below are the steps that I would follow to recover your table:

1. Restore/recover a COPY of the database to a point BEFORE the errant changes were made to the database.
2. Unload the table from this COPY of the database.
3. Truncate the table in the production database
4. Load the table using the unload file created in step #2.

This assumes that you have a valid backup from some point before the erroneous updates were made to the table, and that AIJs are enabled. You may not need the AIJs to perform this task, if the content of the table at the time of the backup is not corrupted.

Hope this helps,

Brad McCusker
Software Concepts International, LLC
www.sciinc.com
Brad McCusker
Software Concepts International