urlaub
ab und weg

…noch die letzten cents aus harry potter raus
november und juli, naja…
aber die vorschau rockt. gibts nix.
since i was struggling these days with “reboot pending” problem i found a really handsome registry key to avoid a reboot prior installation of an application…
If you run "regedit" and delete the following keys
Key: HKLM\System\CurrentControlSet\Control\Session Manager,
Key: HKLM\System\CurrentControlSet\Control\Session Manager\FileRenameOperations
From those, delete the following keys from the registry
•”PendingFileRenameOperations”
•”FileRenameOperations”
then attempt the installation again it should work
..even if following error could have been triggered from monday…
Oracle Rac Standby:
FAL[client]: Failed to request gap sequence
GAP – thread 2 sequence 58471-58478
DBID 871049946 branch 623343130
FAL[client]: All defined FAL servers have been attempted.
————————————————————-
Check that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter is defined to a value that is sufficiently large
enough to maintain adequate log switch information to resolve
archivelog gaps.
————————————————————-
Tue Mar 23 06:43:00 2010
trigger on primary:
RMAN> restore archivelog from sequence 58471 until sequence 58478 thread 2;
Starting restore at 23.03.2010 06:42:18
using channel ORA_DISK_1
voilà
channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
Finished restore at 23.03.2010 06:42:55
you see immediatley on the standby:
Tue Mar 23 06:43:00 2010
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58471.495.714379379′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58472.496.714379381′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58473.497.714379383′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58474.498.714379383′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58475.499.714379385′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58476.500.714379385′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58477.501.714379385′
RFS[4]: Archived Log: ‘+DATA01/grzprd01stdby/archivelog/2010_03_23/thread_2_seq_58478.502.714379387′
WUHU :)
still the reason for this is during a service break a nice mistake led by booting from a firmware cd from HP for a blade HP BL 460 G1.
After booting with newest firmware, my os on the standby machine got the disks from a HP EVA 5000 in a mixed order and not in the right one it was before the firmware update.
meaning it couldn’t mount a /etc/fstab defined device properly, becuase of a bad superblock (of course because file system on there was ASM managed)
because of this mistake I thought disk was corrupted by firmware, not very likely but still possible if you have some kind of experience with HP delivered firmware ;-)
therefore I repartitioned and formated the disk since this was only archivelog destination on the standby node of the oracle rac cluster and this information will immediatley switchover from the master once the database is running again.
HA! nothing happend but:
ORA-15032: not all alterations performed
ORA-15040: diskgroup is incomplete
ORA-15042: ASM disk “8″ is missing
ORA-15042: ASM disk “6″ is missing
when trying to start the ASM instance on the standby…
woops.
well, i killed my asm by means of os tools…normally restore, but since only standby recreation of the standby…
here comes the next clue.
oracle 10g, which we have in use, is not able to drop a diskgroup if it is not mount.
Moreover it is not possible to mount the diskgroup if a disk is missing…..
as I could find out in the documentation with oracle 11g it is possible to signal the force switch to alter diskgroup
still finally managed by creating new diskgroup and forcing the working ones to join this and delete the missing disk using /etc/init.d/oracleasm deletedisk VOL8 and recreated it it finally worked…
my asm diskgroup was all cleaned ;-)
after that recreation of the standby using grid control was very neat and now everything is up and running again…
moral:
never trust disk assignments after HP firmware upgrades, they can be very dynamically ;-) doublecheck if you can mount them and check on luns if you face similar problem. worthy lesson.
open question is if metalink note 466231.1 is valid
does Asm Survive Change Of Disc Path? [ID 466231.1]
The answer is yes. ASM will scan the disks based on the parameter asm_diskstring and the
permissions. When the disk is scanned and the data is found, it does not matter the path or the
major,minor numbers.
because I lack 2 disks but killed only one..but thats another story I guess