The part of the map output you posted seems to be ok, but this:
waslv jfs2 277 477 3 open/syncd /usr/WebSphere
tells me, that not everything is ok at all. The first number - 277 - is the number of logical partitions and since every logicl partition should map to two physical partitions the second number should be 554 ^= 277*2. As this is not the case something must have fone wrong with the mirroring and a simple "syncvg" will most probably not cure it.
I would first find out what has gone wrong (nothing in your post indicates what tht could have been, just that it happened), then i would unmirror the LV, then mirror it again, taking care that whatever the reason was it doesn't happen again.
If this general advice doesn't help you, please post the complete output of "lsvg -l rootvg" and "lsvg rootvg", so that we could further help you.
The first output implies that you used three disks for your mirror. The second output seem to imply that one complete disk got missing. So you might have two mirror copies spread uneven over three disks of which you lost one. Use
# lsvg -p <yourvg>
to find out whether a PV went missing.
If that was the case a syncvg will not help as your mirror was not stale but broken. Backup your data and then repair the mirror(s). If you decide to unmirror the lv/vg let LVM sort out which copy to keep!
lsvg -p rootvg
rootvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk0 active 546 37 00..00..00..00..37
hdisk1 active 546 130 72..16..00..00..42
I dont know exactly why don�t finished correct the mirror, Im new on this job.
As you can see there are many things bad in my opinion.
Websphere was installed on rootvg.
paging space was on rootvg
Then Im going to install websphere on a external disk (san)
and the paging too
I can do this on line (about the partially mirrored) because its a cluster server (websphere part) and it�s production.
Thanks again and I hope you get the idea because my english it�s no so good yet.
The paging space (at least one paging space) should remain on rootvg, as this is the volume group activated and mounted first on boot time. The machine needs to hve access to at least one paging space during boot.
You could delete the other swapspaces and create them anew on some SAN disk. Notice that all swap spaces should be of equal size: AIX uses them in a round-robin-schema. If you want to make the swap faster create more swapspaces and put all but one of them on the SAN storage. Do NOT create one big swap on the SAN and a small one in the rootvg, as is oftenly seen.
If the Websphere LV should be on rootvg or not is a matter of taste: some claim, that binaries should go along with the OS and only data should be on SAN storage. Others claim that binaries should reside with the data they work on.
In your case it is still not clear where the error comes from, as aside from the error everything looks normal. Maybe the error report (issue "errpt" and "errpt -a" respectively) might tell you something.
If you can, back up the LV, delete it and create it anew, then restore the data. Another possibility would be to backup the LV, create a new LV somewhere else, restore the data to it, then umount the original and mount the new one - takes 1 minute and an application restart.
Don't care if this is a production machine when proposing a downtime: if the management of the data center hasn't provided for some maintenance downtime then the management has made a GRAVE CONCEPTUAL error - it is well known that machines do not run for an infinite time - period. So it is their fault, not yours. You are just pointing it out. They may wince and they may whine, but in the end you'll get your downtime.