Oracle PRM-DUL are last chance methods

A tool 'PRM-DUL' was used to take table data and write it to a flat file,
more info about prm-dul http://www.parnassusdata.com/en
The customer had hardware/os failure last week that led to the crash of their 
database. The customer did not take a backup of their current situation at 
that time(so PRM-DUL is not not an option), because they were relying that their 
rman backup would be sufficient to recovery with. They also had a standby 
database we could have used PRM-DUL against or tried to force open to salvage 
data, but they deleted that as well without taking a backup and attempted to 
use restore a backup on. So all they have left is rman backups which is our 
current problem.
Customer DBA's must take down and manually recover production databases when 
there is corruption in the system tablespace. This process often requires 
advanced troubleshooting skills since orapatch or PRM-DUL are last chance methods 
for recovering databases. I cannot assume customers always have successful 
backup and recovery strategies.
From PRM-DUL, we found that there was no data in LOG_TABLE11 at 05:47.
According to the application logic, we expected that
1) the LOG_TABLE11 should be truncated between 05:45 to 05:47
2) NO data was inserted into the table until 05:50:00.
3) NO update and delete on LOG_TABLE11.
Finally, we have extracted the data of LOG_TABLE11 at 05:53 by PRM-DUL.
The above rows have already disappeared in the table.
An environment is using secure file. There is no backup due to customer
ordering wrong hardware from Sun to perform the backup to. Customer tried
to add 8 disks to the diskgroup. One of the disks added was slice2 which
had the partition table for the disk on it. After the add failed and they
realized what had happened they work with System Administrators and
according to customer successfully switched slice2 and slice6. After this
they used the disks to successfully create dummy diskgroup DATA3. The
diskgroup has critical production data and it not mounting is causing the
production database not to mount resulting in significant revenue loss for
the company. As there presently is no backup of this data and they are
using secure file PRM-DUL is not an option to extract the data from the failed
diskgroup. The diskgroup will not mount because disks that were just added
cannot be discovered. Last attempt by customer to use AMDU resulted in core
dumps and no AMDU output. Customer is request that the existing disk
headers for the disk be repaired so that they can get the diskgroup mounted
and then add the correct disks to the diskgroup.
the database died, ct is using PRM-DUL and rebuild with consulting... after the
rebuild, ct will upgrade.
To salvage the data you either use PRM-DUL or clone the database and disable all events and block checking.You can then introduce corruptions but you can query the dataso you can use any method to salvage the data.
We advise to do this on a clone to protect you from unexpected side effects.
Finally customers had to abort the recovery process and then use PRM-DUL to
rebuild the database. 

Comment

*

沪ICP备14014813号

沪公网安备 31010802001379号