- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- LVM vx VXVM for Oracle datafiles
Operating System - HP-UX
1748183
Members
3583
Online
108759
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Go to solution
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-08-2006 06:14 AM
06-08-2006 06:14 AM
Solution
Namaste Sri,
(1) Advocating for more LUNs to house the database in EVA6k (considering the advantage of EVA6k).
Single 2TB Filesystem Storage:
-difficulty in being able to effectively and efficiently backup by any conventional and even "in-array" means.
-single volume/filesystem - loose that volume/filesystem - you loose everything
-you will still get some performance advantages by using smaller vdisks/luns and striping them - specially if they're from different "diskgroups" inside your array OR different luns from different EVA6000s (if you've lots of them).
Smaller LUNS: (say 50 to 100 GB luns striped):
- better manageability during backups, etc.
- ability to build storage volumes to suite your needs.
(2) A more pricise point to prove that VXVM is much more preferred solutions
If HP's direction of adopting VxVM/Veritas solution over the technology they've acquired from teh Comapq/Tru64 acquisition is not enough proof for you - then I have really nothing to say except my current client and its parent organization (Fortune 50 Company) - they used to be on LVM, they're close on completing migrating to VxVM. How's that?
(1) How will the storage layout be far better performing than layered volume of LVM.
You can build storage volumes that LVM cannot possibly do that can exact the most out of your storage arrays. Please google "VxVM Layered Volumes"
2) Regarding mirroring, what is avoiding vendor locking to "in-array" meant by please.
You will possibly be tempted to buy into hardware based mirroring/snapshot solutions - in the case of EVAs -- it's BusinessCopy - which works on HP's EVA arrays only. And that is "vendor lock in". If you switched arrays - whatever processes you have for snapshot/split-mirrors, etc. will have to be revamped. With VxVM - you won't have that issue. Sure it is host/software based but I am pretty sure it can work in any organization/setting.
(3) If you are an HP-UX Veteran - then you are aware perhaps that if the members of an LVM VOlumeGroup had a change in hawrware address (meaning change in CxTyDz values) - then if you do not have "map" files - you're screwed. With VxVM, you do not need map files. The disks can come up as any cXtYdZ so you need not worry anymore your storage group might change presentations, lun renumbering, chnages to SAN ports etc - VxVM will survive that as long as it sees all the disk members.
Hope this helps.
Shukria.
(1) Advocating for more LUNs to house the database in EVA6k (considering the advantage of EVA6k).
Single 2TB Filesystem Storage:
-difficulty in being able to effectively and efficiently backup by any conventional and even "in-array" means.
-single volume/filesystem - loose that volume/filesystem - you loose everything
-you will still get some performance advantages by using smaller vdisks/luns and striping them - specially if they're from different "diskgroups" inside your array OR different luns from different EVA6000s (if you've lots of them).
Smaller LUNS: (say 50 to 100 GB luns striped):
- better manageability during backups, etc.
- ability to build storage volumes to suite your needs.
(2) A more pricise point to prove that VXVM is much more preferred solutions
If HP's direction of adopting VxVM/Veritas solution over the technology they've acquired from teh Comapq/Tru64 acquisition is not enough proof for you - then I have really nothing to say except my current client and its parent organization (Fortune 50 Company) - they used to be on LVM, they're close on completing migrating to VxVM. How's that?
(1) How will the storage layout be far better performing than layered volume of LVM.
You can build storage volumes that LVM cannot possibly do that can exact the most out of your storage arrays. Please google "VxVM Layered Volumes"
2) Regarding mirroring, what is avoiding vendor locking to "in-array" meant by please.
You will possibly be tempted to buy into hardware based mirroring/snapshot solutions - in the case of EVAs -- it's BusinessCopy - which works on HP's EVA arrays only. And that is "vendor lock in". If you switched arrays - whatever processes you have for snapshot/split-mirrors, etc. will have to be revamped. With VxVM - you won't have that issue. Sure it is host/software based but I am pretty sure it can work in any organization/setting.
(3) If you are an HP-UX Veteran - then you are aware perhaps that if the members of an LVM VOlumeGroup had a change in hawrware address (meaning change in CxTyDz values) - then if you do not have "map" files - you're screwed. With VxVM, you do not need map files. The disks can come up as any cXtYdZ so you need not worry anymore your storage group might change presentations, lun renumbering, chnages to SAN ports etc - VxVM will survive that as long as it sees all the disk members.
Hope this helps.
Shukria.
Hakuna Matata.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-08-2006 09:44 PM
06-08-2006 09:44 PM
Re: LVM vx VXVM for Oracle datafiles
Hi Nelson,
Thanks very much indeed. Your response has been absolutely superb. We are making use of serviceguard that we will be happy to make use of single volume group.
We will still have quiet lot of mount points within the single volume group and ensure that there are mirrored at the level of plexes and backed up as file system.
This will ensure that at the time of failover all of the mount points get mounted on the new system.
Thanks,
Srikanth
Thanks very much indeed. Your response has been absolutely superb. We are making use of serviceguard that we will be happy to make use of single volume group.
We will still have quiet lot of mount points within the single volume group and ensure that there are mirrored at the level of plexes and backed up as file system.
This will ensure that at the time of failover all of the mount points get mounted on the new system.
Thanks,
Srikanth
- « Previous
-
- 1
- 2
- Next »
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
News and Events
Support
© Copyright 2024 Hewlett Packard Enterprise Development LP