Customer dropped important large table....
Surfer! reported a customer dropped a crucial table of about 18 million rows; restoring its dbspace from Monday's level 0 left the catalogs unaware of the table. Rudy Fernandes first suggested a dbspace restore to current, but Sally Woolrich noted logs would replay the drop. Rudy agreed and advised a level 0 point-in-time restore to just before the drop, possibly on another machine, then copying the table over.
Auto-generated by Claude from the posts below — may be imperfect; read the full thread.
One of our customers has managed to drop a large (~18,000,000 rows) table which is crucial to their database. Of course it's always a crucial table when this sort of thing happens... We are looking for advice on how to put it back. The table is in it's own dbspace and they attempted to restore that dbspace, which went fine from Monday nights level 0 archive - Tuesdays is kn*ck*r*d as the machine rebooted partway through. However (of course) the system catalogues no longer know about the table! Can we do a level 0 restore & put back all the log files until the last one before the nasty event? Any clues how, if this is possible? Naturally this is urgent! NB I'm posting from my private account. I wish to protect the guilty - it wasn't me as I was in a meeting (with the same customer!) at the time. Phew! -- Surfer!
You should be able to carry out a dbspace restore to current using Monday night's Level 0 and all subsequent logical log backups. Rudy "Surfer!" wrote: > One of our customers has managed to drop a large (~18,000,000 rows) > table which is crucial to their database. Of course it's always a > crucial table when this sort of thing happens... > > We are looking for advice on how to put it back. > > The table is in it's own dbspace and they attempted to restore that > dbspace, which went fine from Monday nights level 0 archive - Tuesdays > is kn*ck*r*d as the machine rebooted partway through. > > However (of course) the system catalogues no longer know about the > table! > > Can we do a level 0 restore & put back all the log files until the last > one before the nasty event? Any clues how, if this is possible? > > Naturally this is urgent! > > NB I'm posting from my private account. I wish to protect the guilty - > it wasn't me as I was in a meeting (with the same customer!) at the > time. Phew! > > -- > Surfer!
On Wed, 18 Oct 2000 20:20:28 +0100, Rudy Fernandes <rferdy@americasm01.nt.com> wrote: >You should be able to carry out a dbspace restore to current using Monday >night's Level 0 and all subsequent logical log backups. > >Rudy Surely this would include dropping the table - database changes get included in the logs for IDS? > >"Surfer!" wrote: > >> One of our customers has managed to drop a large (~18,000,000 rows) >> table which is crucial to their database. Of course it's always a >> crucial table when this sort of thing happens... >> >> We are looking for advice on how to put it back. >> >> The table is in it's own dbspace and they attempted to restore that >> dbspace, which went fine from Monday nights level 0 archive - Tuesdays >> is kn*ck*r*d as the machine rebooted partway through. >> >> However (of course) the system catalogues no longer know about the >> table! >> >> Can we do a level 0 restore & put back all the log files until the last >> one before the nasty event? Any clues how, if this is possible? >> >> Naturally this is urgent! >> >> NB I'm posting from my private account. I wish to protect the guilty - >> it wasn't me as I was in a meeting (with the same customer!) at the >> time. Phew! >> >> -- >> Surfer!
Sally Woolrich wrote: > On Wed, 18 Oct 2000 20:20:28 +0100, Rudy Fernandes > <rferdy@americasm01.nt.com> wrote: > > >You should be able to carry out a dbspace restore to current using Monday > >night's Level 0 and all subsequent logical log backups. > > > >Rudy > > Surely this would include dropping the table - database changes get > included in the logs for IDS? > That's right. A dbspace restore would not work as it always get done to current. Looks like a Level 0 restore to the point in time just before the drop is one way to go. Alternatively, if you need the table and need to stay current, the point-in-time restore to just-before-drop could be done on a different box (identical chunks, etc), and the table copied over to Production. Rudy