Booter sur un spot en mode debug

Passer le spot en mode debug :
nim -Fo check -a debug=yes spot_53_tl8

parametrer nim pour booter le serveur en mode maintenance :
nim -o maint_boot -a spot=spot_53_tl8 monserveur

booter le serveur en mode SMS et le faire booter en réseau sur l'adresse du serveur nim
Aller sur la console :
 (le serveur doit avoir booté en mode debug)

et taper :

mw enter_dbg
>42
>.
>g

... la suite est explicite...


Pour rebasculer le spot en mode normal :   nim -Fo check spot_53_tl8

which ipc is holding a file open

If you cant unmount a fs due to an ipc :

Problem:
server DB2 unmount file system
IPCS process still running ID instance is owned by DB2
ipcrm 0515-020 shmid ( was not found idnumber)
m 2097169 0xffffffff D-rw-rw-rw- udbpd030 db2iadm1

[root@mbhop5pdb2]/> ipcrm -m 2097169
ipcrm: 0515-020 shmid(2097169) was not found.


1) Use the new -S option on ipcs to obtain the shared memory segment ID.

# ipcs -mS

m 131075 0x00001a4c --rw------- root system
SID :
0x2b85

2) Verify that the svmon command is installed on the system. If not,install from the AIX installation CDs.

$ lslpp -l perfagent.tools

3) Use the svmon command to find all processes attached to the shared memory segment.

# svmon -S 0x2b85 -l

Vsid Esid Type Description LPage Inuse Pin Pgsp Virtual
2b85 3 work shared memory segment - 656 0 0 656
pid(s)=10862

This shared memory segment has only one process attached.

To remove this shared memory segment, you must first kill the process that is attached to the segment.
# kill 10862
# ipcrm -m 131075

Verify maxdata value with dump command....

# dump -X64 -o /machine/oracle/ora10203/bin/oracle

Problem determination PowerHA / HACMP

Collect logs : clsnap -d '/tmp' -p2 -n 'node1,node2'

or

snap -e

If cspoc pb : /tmp/cspoc.log <= more details

If Vg configuration is inconstitent between nodes :

1) Validate that all disks in a VG are know, on both nodes

node1 # lspv grep vg1

hdisk3 005a2b2a4dc045f3 vg1 active

hdisk4 005a2b2ab58a59b2 vg1 active

node 2 # lspv grep vg1

hdisk3 005a2b2a4dc045f3 vg1

hdisk4 is missing ....

if HACMP is > 5.4, and VG are not ehanced concurrent (which is not the case, since the vg is not "concurrent" but "active" then :

node 2 # lspv grep 005a2b2ab58a59b2

hdisk4 005a2b2ab58a59b2 None

2) Integrate it in the vg correctly

node1 # lqueryvg -p hdisk3 -T > /usr/es/sbin/cluster/etc/vg/vg1 <= this is to save the good timestamp for the cluster

node1 # varyonvg -ub vg1 <= From now on, NO MORE manipulation on vg1, on node 1, must occur...

node2 # importvg -L vg1 hdisk3

vg1

node2 # lqueryvg -p hdisk3 -T > /usr/es/sbin/cluster/etc/vg/vg1 <= This way, the timestamp is correct on both nodes.

node1 #varyonvg vg1 <= Things are back to normal, now.

This is the simplest way to refefine correctly the vg on backup node... But, this is when things are going smooth.... its not always that way....

First, if the pvid is not known on node 2... First, is it's zoning correctly defined ? if yes, you MUST have a disk in "none None" on your backup node. If you want it to be correctly defined on you second node, you must do a "rmdev/cfgmgr" while vg1 is in mode 'unlocked' on node 1, via the varyonvg -ub command.

If it has been known, and now, it is no more, it means you have 'phantom' disks. Some disks must be "Defined" on node 2, as others are defined in place, with no definition (None = no pvid none = no vg defined). The good way to define them correctly, is to remove the "None none" disk, and to "mkdev" the Defined one, again.

For the timestamp definition, since HACMP 5.4, the timestamp is synchronised via the clveryfy command.

Beware of the storm...

While configuring two vio server the other day, i wanted to transform both vio server SEA cards into SEA failover mode. I fell into the following trap :

If one Vio server is configured as followed :

1 virtual ethernet in vlan / pvid 1 with external network access yes, and trunk pri 1

SEA created between the adapter and this card, and, an internal adress configured on the SEA.

While configuring the other VIO server, in the same way than the first one, in order to transform it in failover mode, later, when you create the SEA adapter (with the virtual adapter on the same Vlan / pvid than the first vio server), you generate a biiig arp storm / broadcast storm, that can put your vlan, and more, down.

So, the good way to do it is to make directly the failover mode, as you create the SEA, or, to transform it before creating the second SEA on the second VIO server.

NOT : mkvdev -sea ent1 -vadapter ent4 -default ent4 -defaultid 3

but directly

mkvdev -sea ent1 -vadapter ent4 -default ent4 -defaultid 3 ha_mode=auto ctl_chan=ent3

Before, you should have the virtual adapter ent3 created, on vlan 3.

OR : if you just need to modify your existing SEA into failover mode :

chdev -dev ent3 -attr ha_mode=auto ctl_chan=ent4

there seems also to be a bypass at the switch level, which could be helpful : its the BPDU guard setting, which disables the port if bridging loop or packet storm occurs.

This is what it looks like at the end (2 differents networks for every partition)

tester les perfs réseau entre 2 serveurs

ftp
bin
put " [pipe symbol] dd if=/dev/zero bs=2000b count=1 " /dev/null

installp en mode debug

export INST_DEBUG=y

permet d'avoir le mode debug en installp