Thursday 10 July, 2008 - 23:41
Had a problem with the startup of the padstow cluster:
Msg_Question:
[msg.disk.scaryWithNoLostSectors] The disk "C:\Users\douglas\Documents\Virtual Machines\Padstow Shared\data1.vmdk" has internal consistency errors that may be caused by partial corruption of the disk file. It is recommended that you restore a backup of this virtual machine. If you do not have a backup, VMware Workstation can repair the disk, but there is a possibility that the data on the disk may be corrupt and affect the stability of the guest.
Do you wish to repair the disk and continue?----------------------------------------
Msg_Question: msg.disk.scaryWithNoLostSectors reply=0
When I tried to do a backup, RMAN reported too many block corruptions in the SYSAUX tablespace.
Since I did not have a backup of the example database and there was no user data added, I decided to throw away the data and recreate the whole database from scratch.
Used dbca from the OraDBHome1 to delete the database.
On padstow2, connected to +ASM2 and dismounted the DATA disk group:
ALTER DISKGROUP data DISMOUNT;
On padstow1, connected to +ASM1 and deleted the DATA disk group:
DROP DISKGROUP data INCLUDING CONTENTS;
Used /etc/init.d/oracleasm deletedisk for DATA1 and DATA2 on both nodes. Shut down both nodes and removed the old vmdk files from the settings. Deleted the vmdk files off disk. Used VMware to recreate the vmdk files and add them to the settings of both images.
Started padstow1 image. Used fdisk to partition the new disks, and used /etc/init.d/oracleasm createdisk to format them as ASM disks. Connected to +ASM1 and created the disk group
CREATE DISKGROUP data NORMAL REDUNDANCY DISK 'ORCL:DATA1' DISK 'ORCL:DATA2';
Started the padstow2 image and connected to +ASM2 and mounted the disk group
ALTER DISKGROUP data MOUNT;
Unfortunately in my haste to delete the database, I forgot to clean out the entries in the RMAN catalogue. Had to use:
sqlplus rman@rmancat
select * from rc_database;
The query results were:
DB_KEY DBINC_KEY DBID NAME RESETLOGS_CHANGE# RESETLOGS ---------- ---------- ---------- -------- ----------------- ---------
1 2 655165041 EXAMPLE 446075 02/JUL/08
Once I had the DBID, I could then unregister the database from the RMAN catalogue
rman catalog rman@rmancat
set dbid 655165041;
executing command: SET DBID
database name is "EXAMPLE" and DBID is 655165041
unregister database;
database name is "EXAMPLE" and DBID is 655165041
Do you really want to unregister the database (enter YES or NO)? yes
database unregistered from the recovery catalog