Running AIX6.1 with oracle 10.2g. I am currently using aixpert to harden the OS. The high settings have been applied (with all the usual precautions i.e. not locking root), however there is one sticky point - using 'shun' host/port with the IPSec element of the 'high' level configuration.
As I understand it the shun config protects various ports, that is ok - but it seems to stop oracle working. I am not a DBA, but understand that oracle uses port 1521 (maybe others as an increment on this port) and not any of the ports that are configured to be protected by the 'shun' setting.
Any thoughts of how I may overcome this?
I guess I could potentially drop the IPSec config altogether, but I would like to understand why Oracle reacts as it does.
I suggest exportvg then importvg. Never seen anything like that either - hangs with locks yes, but not straight back to the prompt with no further error. Why is it apparently getting locked, not rootvg I assume, is it being shared in some way, is there a process running in cron say that kicks off to lock it when you leave the machine idle ?
No appology necessary, we like quick the to answer questions.
Everything there appears to be mirrored - Copies 2, as well as the fact of double the PPs for the LPs. But to prove it as to where the mirroring is exactly, run the map option:
lslv -m LVNAME
That will show you up to three columns of output, one for each possible physical PP copy of each logical LP in the LV. What you want to see is hdisk0 all in one column and hdisk1 say in the next column and no mixing of hdisks in a column - that would then show strict mirroring.
hd5 you mention specifically is just 1 LP big and so has 2 PPs to mirror it, each other one has X LPs and X*2 PPs too.
smit mirrorvg - one way to create a mirroring in rootvg
Note if you have physically the ability to attach the new disk as well as the existing ones, you might want to create the third copy on to the new disk, before you remove the going bad copy on the bad disk to drop back to 2 copies. smit mklvcopy - to add copies LV by LV, smit rmlvcopy - to remove a copy one by one.
smit unmirrorvg - to remove a complete VG mirror copy (make sure it's the good disk copy you keep of course)
Take the steps to remove all the data logically from the bad disk before you remove the bad disk physically, i.e. get it out of the volume group and completely remove all logical devices before physically doing anything with it.
The LV or LVs with those two STALE partitions are the ones affected of course,
I apologize for asking basic questions but am currently over my level of expertise and could use some help. I am taking errors on hdisk0 and IBM has sent me a new drive, but before i get into those instructions, I am trying to validate the system configuration. I believe that rootvg is mirrored but some of the things I look at make me think otherwise.
I thought if the volume group was mirrored that the quorum would be set to 2. This is what a current lsvg rootvg looks like.
# lsvg rootvg VOLUME GROUP: rootvg VG IDENTIFIER: 000cbc6d00004c00000000e c3bf304a5 VG STATE: active PP SIZE: 32 megabyte(s) VG PERMISSION: read/write TOTAL PPs: 1084 (34688 megabytes MAX LVs: 256 FREE PPs: 694 (22208 megabytes) LVs: 10 USED PPs: 390 (12480 megabytes) OPEN LVs: 9 QUORUM: 1 TOTAL PVs: 2 VG DESCRIPTORS: 3 STALE PVs: 1 STALE PPs: 2 ACTIVE PVs: 2 AUTO ON: yes MAX PPs per PV: 1016 MAX PVs: 32 LTG size: 128 kilobyte(s) AUTO SYNC: no HOT SPARE: no
Yet if I look at a list of the LVs, I clearly see that there are 2 PPs for every LP.
Does this mean that the volume group is not mirrored but that a copy of each LV in the rootvg was made. I thought that when you mirrored a volume group, all it did was make a copy of every LV that was in the volume group at that time, so basically they were both doing the same thing anyway.
Here is the problem, since I need to replace hdisk0, I need to know that everything I need is on hdisk1 before I attempt to remove hdisk0. Everything appears the same except for 1 thing and that is hd5 the boot partition. You can see from the list above that like the others there are 2 PPs for the 1 LP but if I look at the output from a lslv and compare it to another LV, there is a difference that I do not understand.
# lslv hd4 LOGICAL VOLUME: hd4 VOLUME GROUP: rootvg LV IDENTIFIER: 000cbc6d00004c00000000ec3bf304a5.4 PERMISSION: read/write VG STATE: active/complete LV STATE: opened/syncd TYPE: jfs WRITE VERIFY: off MAX LPs: 512 PP SIZE: 32 megabyte(s) COPIES: 2 SCHED POLICY: parallel LPs: 2 PPs: 4 STALE PPs: 0 BB POLICY: relocatable INTER-POLICY: minimum RELOCATABLE: yes INTRA-POLICY: center UPPER BOUND: 32 MOUNT POINT: / LABEL: / MIRROR WRITE CONSISTENCY: on/ACTIVE EACH LP COPY ON A SEPARATE PV ?: yes
# lslv hd5 LOGICAL VOLUME: hd5 VOLUME GROUP: rootvg LV IDENTIFIER: 000cbc6d00004c00000000ec3bf304a5.1 PERMISSION: read/write VG STATE: active/complete LV STATE: closed/syncd TYPE: boot WRITE VERIFY: off MAX LPs: 512 PP SIZE: 32 megabyte(s) COPIES: 2 SCHED POLICY: parallel LPs: 1 PPs: 2 STALE PPs: 0 BB POLICY: relocatable INTER-POLICY: minimum RELOCATABLE: no INTRA-POLICY: edge UPPER BOUND: 32 MOUNT POINT: N/A LABEL: None MIRROR WRITE CONSISTENCY: on/ACTIVE EACH LP COPY ON A SEPARATE PV ?: yes
Why is there only 1 LP in hd5 when there is 2 in every other LV in the volume group? Is this because there was never a bosboot done on hdisk1 and even though it is a copy of hdisk0, it is not a bootable disk? Just trying to understand the layout before I attempt the instruction set for replacing the drive.
I am not sure if anyone has seen this before. It certainly has got me stumped....
After the system is left idle for 12 or so hours, I come back to it, login as root and all looks good. EXCEPT, the Volume Group details are not accessible.
lsvg <vgname> returns no output, just goes to next prompt same for lsvg -l or lsvg -p. It is as if the VG's are lovked, but insteag of waiting, the prompt returns back with no output and no errors.
I can "wake up" the VG with: chvg -u <vgname> That works. Nothing in error log.
This is a H70 running AIX 5.3 TL-11 (latest) It was converted from AIX.4.3 by a Migration Installation.
Has anyone seen this before? After 20+ years of AIX admin work, I have never experienced this.
I have a Power6 with multiple AIX LPARs all are oslevel 6100-03-01-0921
I have a NIM Master as one of the LPARs, and room enough to install RedHat EL5.4. "I am trying to create the linux_source with the following command - /usr/sbin/OS_install -o define_resource -a location=/nimages/RHELRES -a source=/mnt -a type=linux_source -a version=RedHat RHEL54"
but receive an error message about linux_source not being a valid type. "ERROR: linux_source is not a valid type attribute"
Anyway, I still don't get it: why would rootvg want to be linked to the proposed IRC chat-room ? I'm certainly not hosting any of it. However, please don't be discouraged, we wish you well with your own thing there in any case. By "tone" I mean that I don't like the rules set out there, it doesn't seem to match the philosophy of openness and inclusivity I'd like to think we have here, but seems to be rather erring on the side of shall I say elitist technical and even covert operations, but that's just a first impression from the text there.
CDE is one of those few things that doesn't like having the hostname changed under it. If you've run it up with one hostname, it will save that in files and then may fail as you've found. Assuming you don't mind trashing any CDE configuration you had done (custom icon arrangements in the menus say), the best thing is to delete all user's CDE customisation files and try again when the hostname is set as it should be. For example for root (carefully with the typing!):
