Setting up the root volume group

[David Ratliff]

I have been doing system admin for about 8 yrs now and have always been told that it is a good practice to keep the root volume group and user data separated. We are setting up a new Superdome and our DBA wants us to put the Oracle Application files on the same drives as the root volume group. I am looking for something that documents the need to keep root and user data separated. Does anyone know of any such documentation?

[Mark Greene_1]

The short answer is that if the root file systems fill-up, you are going to have all sorts of performance issues. Also, putting a db on the root drive is going to shorten the lifespan of the drives because they will be incurring more headmovement than they otherwise would have.

Did your dba give any compelling reason why he's asking this? And what is the configuration of the system in question?

mark

[S.K. Chan]

Take a look at the HP-UX 10.0 File System Layout White Paper .. though not specifically mention about having to separate root VG from data VG. In short it just makes a lot of sense to keep 'em separated.

http://docs.hp.com/hpux/onlinedocs/5963-8942/5963-8942.html

[Christopher McCray_1]

From my prospective, I do not have any SuperDomes, and as a result, not as much disk space as I suspect you have with such a purchase. For this reason, we have the oracle application itself on the root vg. We haven't had any problems at this point. I say that if you have the room, you should keep the root vg clear of applications for the reasons above as well as keeping you OS activities separate from the application activities by keeping them on different controllers. He must have a real good reason for wanting this, or he is a control freak (your DBA).

Good Luck

Chris

[Jeff Schussele]

As Mark mentioned you will certainly be exercising the heads on the disk if they (definitely mirror!!!) contain both the root & Oracle binaries.

But you MUST keep them on separate FSs. DO NOT let them force you into creating /opt under the / FS. /opt MUST be separate for if it caues corruption - you'll have boot trouble.

I would fight, long & hard, to create /opt on a SEPARATE disk - mirrored as well.

I know of no documentation, per se, but this is just good old common SA "street sense". My argument would be that if you kill the boot disk any other "benefits" are pretty much moot.

Rgds,
Jeff

[Darrell Allen]

Hi David,

Unless there is a overwhelming reason to do otherwise, I'd keep vg00 just for the OS. If you have to rebuild the system you don't have to worry about the reloading the databases or other apps. You simply restore vg00 your from you Ignite backup and import everything else.

Without a VERY good reason, I'd keep Oracle separate from vg00.

Darrell

[MANOJ SRIVASTAVA]

Hi David

Here is o/p of bdf of one of our good produciton systems , I believe that Superdome will be hosting atleast HPUX 11.00 or greater so this can be a good point of refernce for laying FS sizes.


Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 143360 44784 92469 33% /
/dev/vg00/lvol1 83733 32629 42730 43% /stand
/dev/vg00/lvol8 1064960 568060 466524 55% /var
/dev/vg00/lvol9 524288 54465 440520 11% /var/opt/perf
/dev/vg00/lvol10 524288 1294 490378 0% /var/adm/crash
/dev/vg00/lvol7 1236992 594487 602395 50% /usr
/dev/vg00/lvol4 524288 141174 359777 28% /tmp
/dev/vg00/lvol6 1572864 652761 862668 43% /opt
/dev/vg01/lvol1 8400896 1487138 6697712 18% /opt/web
/dev/vg00/lvol11 1024000 1357 958735 0% /opt/utilities
/dev/vg01/lvol2 9338880 2001922 7107942 22% /opt/sunscreens
/dev/vg01/lvol3 3680000 3217038 434029 88% /opt/oracle
/dev/vg00/lvol5 1048576 206350 789991 21% /home
/dev/vgora/lvol1 5242880 2321144 2898920 44% /sunsc_u01
/dev/vgora/lvol2 10737664 8057776 2658960 75% /sunsc_u02
/dev/vgora/lvol3 6291456 4112440 2162064 66% /sunsc_u03
/dev/vgora/lvol5 1048576 141493 852852 14% /opt/oracle/admin
/dev/vgora/lvol4 3145728 653048 2473336 21% /opt/oracle/admin/sunsc/arch
/dev/vgora/lvol6 11485184 10055620 1384892 88% /hot


Manoj Srivastava

[Scott_14]

Hi David:

Well, so far I beleive keeping root on its own vg is the ideal. Where I am at, they did set up some oracle stuff on the same vol groul as root, and in time it did cause problems, cause things and ideals change, so room was the bigest issue. I guess when they orginal set up some systems like that, at the time the idea to them made sence, but changes in the enviroment, and needs, created more data and stuff on the root's group which made it more difficult to manage.

Only thing I can think of is maybe they thought if root was mirrored, why not also have oracle on that mirrored group as well, instead of created a separate set disk vols to mirror.

It may depend on your own enviroment, if this is good or not, here where things can and will change, it was a bad ideal.

scot

[Kelli Ward · Accepted solution]

Absolutely,
I would stay away from using the root vg for something as extensive as a database. You and the db admins may be asking for a lot of headaches down the line from the admin and performance monitoring aspect.
Sweet talk your managers and you'll win.
OK, maybe you'll win. ;)
Best of luck to you,
Kel

[David Ratliff]

Thanks everyone for the great comments. I have printed everyones out and plan to hand them to our DBA.....wish me luck.

[Kelli Ward]

Hey David,
If that doesn't work, just tell them a huge panic story of how long it will take to get the system back on line in the event of a catastrophic failure, since you might have to repair the entire root file system.
When all else fails, fear is a great motivator.
Did I say that? ;)
Hope all goes well,
Kel

[David Ratliff]

Thanks Kel,

I'll pass on some horror stories. See how important the systems is to them.