Instance number changing?

[Krishna Prasad]

OK. Here is a stange one.

At a off-site DR test.

We restore omniback ....restore the operating system, create our filesystems, restore our database. We reboot the box and then.......

the drives that we restored the database on changed address. We were told of no hardware changes done to the box. Which I do believe because of the output from I/O scan still should the same Hardware Path but the instance number changed which changed the device files.

Prior to the reboot the ioscan looked like this. ( I will only show a one disk examble)

Class I H/W Path driver S/W State
###############################################

disk 3 0/8/0/0.0.0 sdisk claimed
/dev/dsk/c3t0d0

after the reboot
Class I H/W Path driver S/W State
###############################################

disk 5 0/8/0/0.0.0 sdisk claimed
/dev/dsk/c5t0d0

I don't know of what OS files I restored or didn't restore that could change the instance number? Does anyone else? I am running HP-UX11.00 on a N-class box in production. The off-site box was a N-class box.

The only thing I could think of to fix it in the short term was a vgexport and vgimport. However, I want to know what could cause this to happen in the first place?

[S.K. Chan]

I think the ioconfig file did not get restored and as a result it created a new one which then changes the instance number. I'm attaching the process of changing instance number and you can see somewhere it mentioned about the ioconfig file.

----------------------------------------------
Changing Instance Number (HP-UX 10.x/11.x)
==========================================
o Build yourself the "infile" from the extisting configuration.

# ioscan -kf|grep -e INTERFACE -e DEVICE|awk '{printf
"%s %s %s\n",$3,$1,$2}'>infile

o The "infile" should look something like this :-

......
0/0/2/0 ext_bus 2
0/0/2/0.2 target 3
0/0/2/0.2.0 disk 1
0/0/2/0.7 target 4
0/0/2/0.7.0 ctl 2
0/0/2/1 ext_bus 3
0/0/2/1.2 target 5
0/0/2/1.2.0 disk 2
0/0/2/1.7 target 6
0/0/2/1.7.0 ctl 3
0/4/0/0 ext_bus 4
0/4/0/0.0 target 7
0/4/0/0.0.0 disk 3
0/4/0/0.0.1 disk 6
......

o Now edit "ext_bus" line and change the instance number to the
one you wanted. Be careful not to duplicat the instance numbers
or leave anything out. Move the "infile" to root directory.

o Test the file :-

# ioinit -f infile 2>&1|more

==> Look for errors with any of the changed lines. If no diagnostic
message is displayed for that line then it is good. All other
lines that do not change will say something like ..

ioinit: Input identical to kernel, line ignored
Input line 1: 0/0/2/0 ext_bus 0

o Rename /etc/ioconfig and /stand/ioconfig with extension say ".save"

o Reboot the system. It will come up to ioinitrc and give this message:-

/sbin/ioinitrc /etc/ioconfig missing. Restore it from backup or
invoke /sbin/ioinit -c to recreate it from kernel.
(in ioinitrc) #

o Run this :-

(in ioinitrc) # /sbin/ioinit -f /infile -r
(in ioinitrc) # ^d

o You should get back all your instance numbers after system reboots.

[Volker Borowski]

Hi Ron,

well to restore the operating system was the thing that restored /dev which I guess was not so good. You should have done the OS recovery with ignite.

If you reinstall the OS, you might get rearangements with all devices the work with logical instance numbers (like /dev/rmt/0m, or the SCSI-controllers like in your case).

I.e if you have a scsi-controller at 52.0.0.0 and install the OS all disks will get /dev/dsk/c0xxxx as a path.
If you put in a second controller to 40.0.0.0 this one will become c1xxxx.
But if you reinstall the system now, the 40.0.0.0 will be the c0xxxx controller due to its lower hardware-path-id.

Hope this help
Volker

[James R. Ferguson]

Hi Ron:

First, it is not uncommon for instance numbers to change upon a cold-install. Instance number assignements are based on the order in which hardware is scanned. Changed instance numbers most commonly a problem for tape drives where /dev/rmt/0m (instance 0) is assumed to be the default device.

Since you were dealing with disk devices, the use of a 'vgimport' was quite appropriate.

Since you don't mention Ignite recovery, I am going to presume that your D/R test had an OS loaded upon which you overlaid your configuration. In that case, the configuration of the server was already set anyway.

Regards!

...JRF...

[A. Clay Stephenson]

This is very common. It happens because the i/o interfaces were 'discovered' in a different order on the two boxes. You might also run into this problem if moving between machine classes. That is something your DR plan should take into account. Typically this occurs because on your old box, a card was added or moved to another slot after the OS was originally loaded. There are two ways to fix this: 1) nore the major/minor device nodes of the current devices and simply remove the nodes with rm and remake them with the desired names and major/minor device numbers via mknod - a bit messy. 2) Neat and also works across machine types: DON'T USE THE DEVICE NODES DIRECTLY. Do this instead: Make your oracle data files something like: /u01/oradata/file01.dbf. Next symbolically link this file to your raw device: ln -s /dev/rdsk/c2t5d0 /u01/oradata/file01.dbf. If you use indirection like this, then you only need to set the symbolic links and the instance numbers don't matter.


Food for thought, Clay

[Duncan Edmonstone]

If hardware is added to a box after the initial install, instance numbers can be different from a system which has just been installed -

instance numbers are incremented as new hardware is discovered, so a (simplified) example might look like this:

bus 0/1
|--disk1
|--disk2

bus 0/2
|--disk3
|--disk4

If I now add a disk to bus 0/1 it takes instance number 5 :

bus 0/1
|--disk1
|--disk2
|--disk5 **

bus 0/2
|--disk3
|--disk4

But if I were to *completely* re-install the OS after adding the new disk, the disk instance numbers would look like this:

bus 0/1
|--disk1
|--disk2
|--disk3

bus 0/2
|--disk4
|--disk5


So this might explain the change...

HTH

Duncan

[Tom Geudens]

Hi,
Just an assumption. Did you (for the recovery)
attach a tapedrive or any device that is not normally there ? That could explain the hardwarepath remaining the same, but the instance number changing ...
If the total number of devices (not only disks but all of them) has not changed this is strange indeed ...

Kind Regards,
Tom Geudens

[Krishna Prasad]

Wrong use of Instance #.

I was refering to the instance number of the controller i.e.

c3t0d0 to c5t0d0

I assumed the "I" in the ioscan was for the controller. looking at that again...I relize this instance # has nothing to do with the controller.

Sorry I wasn't clear ......

Whey would the c# change after a reboot.

Also......we did not restore /dev at all.

We didn't use ignite becuase we were trying to restore two production servers to one DR server becuase our Cell server and DB server are different.

[S.K. Chan]

ioscan -fn|grep ext_bus
will show you the instance number (2nd column)

[Sridhar Bhaskarla · Accepted solution]

Ron,

Did you restore /etc/ioconfig also from the backup?. If so, the previous instance numbers (3) would have been lost.

-Sri