| Blogs | Classifieds | Downloads | FlashChat | Gallery | Googlemap | Invite Friends | Links | Projects | Reviews | Wiki |
| |||||||||
Welcome to the pSeries Tech Forums,
our free peer-based support site for administrators, engineers and architects working with IBM pSeries servers and software. You are currently viewing our site as a guest which gives you limited access to view most discussions, articles, tutorials and access our other free features. By joining our community you will be able to collaborate with administrators, engineers and architects charged with designing, delivering or maintaining IBM pSeries server environments. Founded by a recognized IBM pSeries consultant and IBM Redbook author, pSeries Tech Forums was developed with the single mission of bringing IBM pSeries professionals together into a single self-help community. Registration is fast, simple and absolutely free to all IT professionals with responsibility for or interest in IBM pSeries servers. We invite you to join our community today! If you have any problems with the registration process or your account login, please contact contact support. |
| Our Sponsors | |
| | |
| Want to advertise? | |
![]() |
| | LinkBack | Thread Tools |
|
#1
| ||||
| ||||
We did a resize of two volume groups, and that was the end of them. Firstly we extended the logical volumes on the VIO. On the client LPAR, ran "chvg -g dsvg0x". The first voume group we did was small 36Gb, and did not extend by much, but was effectively useless. The second volume group is a big one of 270Gb. The size of the extents on the large volume are 33400 in 8mb extents. Each of these VGs run Oracle. What happened, was the whole system froze, and we could not access anything. A reboot was the only way out. Howevee on reboot, the two file systems failed to mount, and LVM reported that both VG were varyd on. A varyoff did not work, syncing the ODM di not work, and core dumped, exporting core dump. The two VGs had to be rebuilt. Or path level is 5300-04-01 This is something we have done before on other partitions, and has worked, but on this partition, it corrupted these two VGs. One thought though, the customer came back and said they were running very intensive database jobs at the time, and whether this had a bearing I do not know. Any thoughts? |
|
#2
| ||||
| ||||
Hi Hmm, not an easy one. In fact some operations like modifying VG sizes or migrating PV to another storage subsystems are recomended not to be done while RDBMS are running due to the heavy I/O access patterns such appls might have, no matter what AIX man pages said about concurrency of those operations. In fact they are not such concurrent cause a lock is placed in the VGDA area of the disks. On the other hand keep in mind that AIX has been suffering a lot of changes and you need to keep your systems updated, so before doing such tasks involving use of both AIX and VIOS OS please try to apply latest available fixes. One sample could be: IBM - IY67833: POSSIBLE DATA LOSS OR CORRUPTION AFTER USING CHVG -B OR -G Best recommendation: keep your system at the latest level available, or al least to the latest-1 available. And of course keep backup of everything just before any major update. You can keep lspv, lsvg, lslv output in files or paper, keep savevg backups on tapes or TSM, keep directories and files data using your backups clients (if exists), keep RDBMS in backups using rman if Oracle, and so on. Hope this helps
__________________ cd3lgad0p |
|
#3
| ||||
| ||||
Problem was the sizing of the VG. It was using 8Mb PP sizes, and the max PPs being 32500. For some reason the system did not respond when requesting a volume greater than 32500, and just sort of hung up. We have started migrasting our large volumes to larger PP sizes 256Mb and making them scaleable. |
![]() |
| Bookmarks |
| Tags |
| damaged, resize, volumegroup |
| Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
| Thread Tools | |
| |